Прежде чем мы пойдем в глубь выбранной темы — приведу трактование из большого энциклопедического словаря.

ИНЦИДЕНТ (от лат. incidens, родительный падеж incidentis — случающийся) , случай, происшествие (обычно неприятное); столкновение, недоразумение.

Поэтому давайте сегодня рассмотрим инцидент, который возникает сплошь и рядом между мужчиной и женщиной — через призму столкновения их интересов. И здесь совсем неважно был ли этот инцидент между мужем и женой, парнем и девушкой, подчиненной(женщиной) и начальником (мужчиной).

Просто я хочу показать, что суть такого конфликта у всех его проявлений остается общей. Чтобы не быть голословной и не размазывать кашу по тарелке начну с практических примеров.

Муж и жена.

Она приходит счастливая домой (ей удалось сделать все задуманное и даже больше). Переступает порог собственной квартиры и по обыкновению ждет знака внимания со стороны своего мужа.

Но! Вместо традиционной и шутливой реакции с его стороны — КТО ТАМ? Она слышит затянувшееся молчание.

Недоумение, непонимание и прочие реакции мигом пронеслись в ее голове и теле одновременно.

Три коротких шага из прихожей в зал показались ей вечностью. А ее бурные фантазии успели розыграться не на шутку.

Следующий миг оказался еще более удивительным, когда она увидела своего благоверного мирно восседающим в кресле с газетой в руках.

Жене, совсем наоборот, хотелось не просто общения, а еще и внимания и благодарности в свой адрес по-поводу ее результатов.

Вот вам две полярности, две планеты, два разных уровня пребывания сознания, два разных желания.

И сколько не изучай теорий, практик по-поводу того, как вести себя в подобной ситуации — нюансы таких инцидентов оказываются всегда сильнее. А посему определеный тупик в виде непонимания , как быть в подобной ситуации обеспечен.

Но прежде чем я покажу выход из данной ситуции. Давайте рассмотрим еще один пример.

Начальник, подчиненная.

Ей было дано производственное задание, которое нужно было сделать к определенному сроку. В силу разных обстоятельств (а главное благодаря своему бессознательному выбору) — сроки были упущены, а задание ни сделано во — время.

В глубине души она надеялась не некоторое снисхождение со стороны начальника, а посему на очередную оперативку шла спокойно и уверенно.

Для начальника встреча с исполнительцей данного задания определяла успех его компании на целый год. Считанные часы отделяли его от долгожданного договора на поставки в другой город. Дело оставалось за малым — получить необходимые расчеты от подчиненной.

Идя на оперативку он и мысли не допускал о том, что оно может быть просрочено.

А теперь пустите в ход свое воображение и представьте какой произошел инцидент в этот день. К вашим фантазиям добавлю только один факт — эта девушка была уволена с работы.

Безусловно сейчас можно очень долго рассуждать по- этому поводу.

Но я думаю, что вы в своей жизни уже достаточно анализировали подобные ситуации. А посему не буду забирать ваше драгоценное время и сразу перейду к сути.

С одной стороны кажется, что это совсем разные ситуации и объединить их нельзя.

И я с вами соглашусь, в том случае, если подойти к их рассмотрению с внешней стороны.

Я же хочу вам показать суть данных конфликтов и убедить вас в том, что она у них единая.

И так для начала рассмотрим причину конфликта .

Как в первом, так и во втором случае, причиной таких инцидентов стали — НЕ ОПРАВДАННЫЕ ОЖИДАНИЯ.

Да именно они являются охилесовой пятой в рассмотренных конфликтах (и не только).

Что здесь важно понять?

Как только мы выстраиваем определенный план действий (своих, другого человека) перед встречей с ним, то автоматически (этот механизм работает без сбоя) мы включаем у себя чувство ожидания и надежды.

А какие программы лежат в этих словах (осмелюсь вам еще раз напомнить)?

О (ум) — ЖИД — дАН . НАД —ад -Е- ДА .

Вот и все!

Сначала мы запускаем остановку (Оум ЖИД) своей творческой энергии. А потом лелеем себя надеждой и начинаем играть в игру — пройти (НАД -Адом через ДА т.е. согласие).

Как в первом (у жены и у мужа), так и во — втором случае (у начальника и подчиненной), каждый игрок лелеял свои ожидания.

В итоге разность энергий вложенная в их ожидания вызвала взрыв (конфликт) «на макоронной» фабрике.

В задачке спрашивается, а как можно было избежать данного инцидента?

С одной стороны, все очень просто — нужно научиться слушать слышать себя и человека, с которым ты общаещься здесь и сейчас. Только при этом условии, игра становится осознанной и будет напоминать игру на фортепьяно. Слушание и слышание одной музыкальной клавиши, включает четкое понимание какую из них нажать в следующий момент, чтобы музыка звучала органичнно.

Но чтобы получать свои результаты от такого общения — конечно же требуются определенные умения и навыки. Понятно что в один момент мы не становимся мастерами, а это значит их можно развивать только постепенно.

Главное было бы желание.

Однако мой ответ был бы не полным если бы я не сказала о главном.

О ключе, который позволяет вырабатывать осознанный подход к любой коммуникации, с любым человеком или коллективом и избегать подобных инцидентов.

Сутью такого КЛЮЧА является формирование у себя стратегического мышления или подхода. В переводе на русский язык — это означает, что перед любой встречей с кем бы то нибыло (с мужем, женой, начальником…), вы всегда заранее определяете суть своей игры (мы все здесь на Земле играем — это нужно понимать), в которой четко формулируете свой конечный результат.

Сейчас вы мне можете возразить и сказать: «Вот завернула! Это какой я еще должна (ен) определять результат при общении с мужем (женой)! Ведь каждый день замучаешься это делать!».

И тем ни менее, как подтверждает мой личный и опыт моих клиентов —

Осознанный подход к своей жизни, четкое понимание того, чего ты хочешь в каждом жизненном миге (с этим или иным человеком) открывает пространство для успешной и безконфликтной жизни.

Поэтому мне не надо верить — это можно только проверить.

P.S. Сейчес самое благодатное время для изменения своих деструктивных программ.

Дело утопающих, дело рук самих утопающих.

С вами была Пеняйчева Любовь .

Первопричиной наступления события инцидента информационной безопасности является потенциальная способность злоумышленника получить необоснованные привилегии для доступа к активу организации. Оценить риск подобной возможности и принять правильное решение о защите, составляет основную задачу команды реагирования.

Каждый риск должен быть приоритезирован и обработан, в соответствии с политикой оценки рисков принятой в организации. Оценка рисков рассматривается как перманентный процесс, целью которого является достижение приемлемого уровня защиты, иными словами, должны быть внедрены достаточные меры защиты актива от необоснованного или неправомочного использования. Оценка рисков способствует классификации активов. Критичные, с точки зрения рисков активы, в подавляющем большинстве случаев, также являются критичными для бизнеса организации.

Специалисты команды реагирования анализируют угрозы и способствуют поддержанию в актуальном состоянии, принятой службой информационной безопасности организации, модели нарушителя.

Для эффективной работы команды реагирования в организации должны быть предусмотрены процедуры, обеспечивающие описание процессов функционирования подразделений. Особое внимание должно уделяться наполнению документарной базы службы информационной безопасности.

Обнаружение и анализ инцидентов информационной безопасности

Инциденты информационной безопасности могут иметь различные источники происхождения. В идеале, организация должна быть готова к любым проявлением вредоносной активности. На практике это неосуществимо.

Служба реагирования должна классифицировать и описать каждый инцидент, произошедший в организации, а также классифицировать и описать возможные инциденты, предположения о которых были сделаны на основе анализа рисков.

Для расширения тезауруса о возможных угрозах и связанных с ними возможных инцидентов хорошей практикой является использование постоянно обновляемых открытых источниках сети Internet.

Признаки инцидента информационной безопасности

Предположение о том, что в организации произошёл инцидент информационной безопасности, должно базироваться на трёх основных факторах:

• сообщение об инциденте информационной безопасности поступают одновременно из нескольких источников (пользователи, IDS, журнальные файлы)
• IDS сигнализируют о множественном повторяющемся событии
• Анализ журнальных файлов автоматизированной системы даёт основание для вывода системным администраторам о возможности наступления события инцидента

В общем случае, признаки инцидента делятся на две основные категории, сообщения о том инцидент происходит в настоящий момент и сообщения о том, что инцидент, возможно, произойдёт в скором будущем. Ниже перечислены некоторые признаки совершающегося события:

• IDS фиксирует переполнение буфера
• уведомление антивирусной программы
• крах WEB – интерфейса
• пользователи сообщают о крайне низкой скорости при попытке выхода в Internet
• системный администратор фиксирует наличие файлов с нечитабельными названиями
• пользователи сообщают о наличие в своих почтовых ящиках множества повторяющихся сообщений
• хост производит запись в журнал аудита об изменении конфигурации
• приложение фиксирует в журнальном файле множественные неудачные попытки авторизации
• администратор сети фиксирует резкое увеличение сетевого трафика, и.т.д.

Примерами событий, которые могут послужить источниками информационной безопасности могут служить:

• журнальные файлы сервера фиксируют сканирование портов
• объявление в СМИ о появлении нового вида эксплойта
• открытое заявление компьютерных преступников об объявлении войны вашей организации и.т.д.

Анализ инцидентов информационной безопасности

Инцидент не является очевидным свершившимся фактом, напротив, злоумышленники стараются сделать всё чтобы не оставить в системе следов своей деятельности. Признаки инцидента содержит незначительное изменение в файле конфигурации сервера или, на первый взгляд, стандартная жалоба пользователя электронной почты. Принятие решения о наступлении события инцидента во многом зависит от компетентности экспертов команды реагирования. Необходимо отличать случайную ошибку оператора от злонамеренного целенаправленного воздействия на информационную систему. Факт отработки “в холостую” инцидента информационной безопасности также является инцидентом информационной безопасности, поскольку отвлекает экспертов команды реагирования от насущных проблем. Руководство организации должно обратить внимание на данное обстоятельство и предоставить экспертам команды реагирования известную свободу действий.

Составление диагностических матриц служит для визуализации результатов анализа событий, происходящих в информационной системе. Матрица формируется из строк потенциальных признаков инцидента и столбцов – типов инцидентов. В пересечении даётся оценка событию по шкале приоритетов “высокий”, “средний”, ”низкий”. Диагностическая матрица призвана документировать ход логических заключений экспертов в процессе принятия решения и, наряду с другими документами, служит свидетельством расследования инцидента.

Документирование инцидента информационной безопасности

Документирование событий инцидента информационной безопасности необходимо для сбора и последующей консолидации свидетельств расследования. Документированию подлежат все факты и доказательства злонамеренного воздействия. Различают технологические свидетельства и операционные свидетельства воздействия. К технологическим свидетельствам относят информацию, полученную от технических средств сбора и анализа данных (сниферы, IDS), к операционным – данные или улики, собранные в процессе опроса персонала, свидетельства обращений на service desk, звонки в call center.

Типичной практикой является ведение журнала расследования инцидента, который не имеет стандартной формы и разрабатывается командой реагирования. Ключевыми позициями подобных журналов могут служить:

• текущий статус расследования
• описание инцидента
• действия, производимые командой реагирования в процессе обработки инцидента
• список акторов расследования с описанием их функций и процентом занятости в процедуре расследования
• перечень свидетельств (с обязательным указанием источников), собранных в ходе обработки инцидента

В России сложилась интересная ситуация с расследованием инцидентов в сфере информационной безопасности. Большинство инцидентов замалчивается - если, конечно, дело не касается банковских счетов и финансовых транзакций. Администраторы и служба ИБ (если она есть) пытаются предпринять какие-то меры, затем все отчитываются перед руководством и об инциденте забывают. О полноценном расследовании речи, как правило, не идет, потому что либо безопасностью заниматься в компании просто некому, либо есть отдел, который разработал политику безопасности, внедрил современные технические средства, но этим и ограничивается. Ликвидация последствий сводится к смене чувствительной информации, такой как пароли и ключи, переустановке пары-тройки операционных систем (не всегда тех, которые необходимо).

Если следовать букве закона, когда обнаруживается инцидент информационной безопасности, нужно обращаться в государственные органы правопорядка. Но коммерческие структуры редко на это идут: мало того что приходится открыто признаться в собственном косяке, так еще и возникает множество вопросов - лицензионный ли софт, обеспечиваются ли меры, требуемые регуляторами… Потому у плохих ребят складывается ложное ощущение абсолютной безопасности, особенно если эти ребята занимаются взломом ради морального удовлетворения, а не ради коммерческой выгоды. Об одном таком случае я и расскажу в этой статье.

ТТХ

Компания N достаточно прогрессивна в своей сфере, поэтому внутреннее обеспечение службы ИТ на высоте: хорошие средства коммуникации, современное оборудование, приличные зарплаты. В свое время была создана служба безопасности, курирующая вопросы информационной, экономической и физической безопасности. Приглашенный подрядчик помог построить защищенную ИТ-инфраструктуру и ввести режим коммерческой тайны.

IT-инфраструктура представляет собой следующее:

• серверы располагаются в демилитаризованной зоне, доступ по сети в ДМЗ ограничивается межсетевыми экранами;
• повсеместно введена виртуализация серверов;
• присутствует сегментация сети с ограничением доступа между сегментами. Рабочие станции разнесены по VLAN’ам, с фильтрацией трафика между ними, в соответствии с внутренней иерархией;
• права доступа пользователям выделяются по принципу минимальных привилегий;
• централизовано софт обновляется только для продуктов Microsoft;
• ведется централизованный мониторинг серверов, правда, в основном с позиции доступности.

Инцидент

В начале года костяк топ-менеджмента компании N отправился на корпоративный выезд в далекие страны. Поездка предполагала не только развлечения, но и рабочие моменты, однако им не суждено было состояться: материал, который планировали презентовать и обсудить по-современному - с мобильного планшета, был утерян.

Прекрасное солнечное утро омрачилось: смартфоны и планшеты всех собравшихся в отеле на берегу океана (и не только их) оказались девственно чисты.

Данная информация была доведена до службы безопасности, которая разумно предположила, что тут не обошлось без внешнего вмешательства. Очевидно, что у всех сразу аккаунты iCloud взломать не могли, и служба безопасности заподозрила, что угроза исходит из корпоративной сети. Удаленно очистить мобильные устройства можно только через соответствующий сервис, например через корпоративный сервер Microsoft Exchange. Команда, позволяющая очистить устройство пользователя с адресом [email protected], выглядит следующим образом:

Clear-MobileDevice -Identity WM_TonySmith -NotificationEmailAddresses "[email protected]"

ИТ-службе поставили задачу проверить журналы сервера OWA: не было ли подозрительной активности в отношении аккаунтов пострадавших и компрометации пароля администратора сервера MS Exchange. Администраторы обнаружили зацепку - доступ к аккаунтам пострадавших в предшествующие инциденту дни неоднократно осуществлялся с нескольких нетипичных для них IP-адресов. Как я позже выяснил, засвеченные IP-адреса были выходными Tor-нодами.

Анализ логов OWA

Логи OWA хранятся по умолчанию в %SystemRoot%\System32\logfiles\w3svc1 . Структура логов - обычные текстовые файлы, изучать которые без вспомогательного инструмента, особенно при большом количестве пользователей, утомительно. На помощь придет Log Parser - очень ценный инструмент, который пригодится не только в подобной ситуации.

Для удобства преобразуем все имеющиеся логи в один файл формата CSV:

C:\Program Files\Log Parser 2.2>LogParser.exe -i:iisw3c "select * into d:\temp\alllog.log from %SystemRoot%\System32\logfiles\w3svc1\*" -o:csv

После чего составим список событий, отражающих доступ пользователей к OWA:

C:\Program Files\Log Parser 2.2>LogParser.exe -i:csv "select cs-username, date,time, c-ip, cs-uri-stem, cs(User-Agent) FROM d:\temp\alllog.log to d:\temp\access.csv" -o:csv

Выясняем, кто обращался к функциям OWA, отвечающим за удаление данных с устройства:

C:\Program Files\Log Parser 2.2>LogParser.exe -i:csv "select cs-username, date, time, c-ip, cs-uri-stem, cs-uri-query, cs(User-Agent) FROM d:\temp\alllog.log to d:\temp\access2.csv WHERE cs-uri-query LIKE "%wipe%"" -o:csv

Судя по системным логам, аккаунт администратора сервера OWA скомпрометирован не был. Целый день админы читали логи серверов, а служба безопасности тем временем беседовала со всеми админами по очереди, предполагая, что диверсант внутри компании. Однако это ни к чему не привело. Тогда они обратились по старому знакомству ко мне.

Поставили они такие задачи:

• установить источник угрозы - внутренний или внешний;
• выяснить сценарий атаки;
• определить последствия - скомпрометированные аккаунты и системы;
• определить дальнейшие действия для ликвидации угрозы.

Оказавшись на месте, я опросил ИТ-персонал. По итогам составил схему сети, определил расположение серверов и сервисов, собрал информацию об используемых операционных системах, настройке межсетевых экранов, парольной политике, политике обновления софта, персональных зонах ответственности администраторов.

Перепроверил результаты анализа логов администраторами. С помощью ntfswalk проанализировал MFT на наличие удаленных в последнее время файлов. Сервер OWA был чист и нетронут.

Так как скомпрометированы были пароли нескольких сотрудников сразу, я решил, что начать надо с того места, где хранятся пароли. Любой хакер, попадая в корпоративную сеть, сперва спешит полакомиться хешиками. Вопрос этот избитый, и детали получения хешей, думаю, знают все. Такой сценарий надо отработать первым - как наиболее вероятный. В данном случае доменная авторизация была настроена почти на всех устройствах, за исключением сетевого оборудования и Linux-серверов. Исходя из этого, я решил обследовать контроллеры домена.

Первым делом настроил отдельный сервер, на который стали зеркалировать трафик с потенциально скомпрометированных узлов и трафик, циркулирующий через шлюзы, в интернет. Подобные данные могут пригодиться в дальнейшем для выявления несанкционированного доступа.

Я получил актуальные копии виртуальных машин и начал с ними разбираться. Подключив виртуальные жесткие диски к своей системе, запустил процесс восстановления данных - есть вероятность обнаружить удаленные логи файлов, которые использовал злоумышленник. Для этого можно взять любой удобный софт для восстановления данных, результат будет примерно одинаков. Я предпочитаю R-Studio.

Так как у меня в исследовании были только образы виртуальных машин, процедура несколько упрощалась - не нужно тратить время на снятие образов жесткого диска и оперативной памяти. Файлы жестких дисков виртуальных машин можно либо конвертировать в raw , либо монтировать как есть, с помощью соответствующих утилит. Образ RAM и файл сохраненного состояния можно сконвертировать в «сырой» образ. Не стоит забывать и про файлы подкачки - в них тоже порой находится много интересного. Volatility версии 2.3 умеет все это разбирать и конвертировать в случае необходимости.

Отличия работы с физической системой от виртуальной в том, что образ памяти заполучить сложнее - это связано с риском повредить текущее состояние и потерять данные, которые могут оказаться существенными. Также при исследовании физической системы необходимо применять дополнительные инструменты и методики для определения скрытых областей (например, Host Protected Area - HPA и Device Configuration Overlay - DCO).

Обследовать Windows-машины в моем случае я решил по следующему сценарию:

Помимо этого, можно извлечь содержимое процесса в файл для дальнейшего исследования.

След найден

В оперативной памяти одного из контроллеров домена обнаружились явные признаки компрометации:

• процесс svchost.exe запущен из C:\Windows\WOW64 , а не из System32 , как ему полагается;
• исходящие сетевые соединения, на IP-адрес частного хостинга в Штатах;
• неизвестный процесс запущен с PPID , не отображающимся в списке процессов.

Процесс был идентифицирован с помощью утилиты vol.exe .

Vol.exe pslist -f image.vmem --profile=Win2008R2SP1x64 >pslist Offset(V) Name PID PPID 0xfffffa801996cb30 spintlx64.exe 2820 1388 ....

Но PID 1388 больше нигде не значился, что всегда очень подозрительно. В первую очередь необходимо было извлечь тело этого процесса и проверить хотя бы антивирусом.

vol.exe dumpfiles -r spintlx64 -f image.vmem —profile=Win2008R2SP1x64 -D ./

При проверке на VirusTotal показатель выявления был 34/50. При поверхностном анализе обнаружилось, что дата компиляции и сборки бинарника 1992-06-19 22:22:17 , а найденный при офлайн-анализе образа диска файл имел типичные для малвари изменения в атрибутах. Дата создания, изменения, последнего обращения были одинаковы и гораздо старше остальных системных файлов. Файл имел небольшой вес, создавал логи в зашифрованном виде и отправлял их по сети посредством HTTPS. С виду - типичный кейлоггер. Интересно, теперь предстоит разобраться, откуда и когда он попал в систему.

После восстановления данных все лог-файлы были загружены в Event Log Explorer для дальнейшего анализа. Штатные средства в такой ситуации не подходят: они не так поворотливы при поиске, а размеры логов очень большие (>30 Гб).

Отсортировав события по сетевому адресу источника, я получил несколько записей логов, показывающих, что осуществлялся сетевой вход (тип 3) одного из администраторов с сервера Zabbix . По событию входа была определена дата установки кейлоггера. Ее подтвердило время появления первых файлов, создаваемых кейлоггером, - они удалялись, но их получилось восстановить вместе с атрибутами. Больше ничего подозрительного ни в логах, ни в памяти, ни в реестре обнаружено не было. Дополнительно я проанализировал домашние каталоги пользователей сервера, но это не принесло новых результатов.
Завершив работу с контроллером домена, я переключил внимание на сервер Zabbix - именно с него осуществлялся доступ к контроллеру домена по сети.

Обследование Linux-системы концептуально не отличается от обследования Windows-системы. Ищем все то же самое: историю действий, производимых с системой. Если копнуть глубже, то исследовать можно все, от аппаратного уровня до истории запуска Microsoft Paint или набранных текстов. Но к счастью, обычно такой задачи не стоит. Зачастую задача достаточно конкретна и нет необходимости тратить время на то, что не принесет результата.

В данном случае предстояло обследовать Linux-систему на предмет несанкционированного доступа. О сервере предварительно было известно следующее: установлен Suse Linux , Apache + PHP + MySQL + Zabbix с сопутствующим программным обеспечением - всем знакомым LAMP . Выяснилось, что сотрудник, ответственный за сервер, с ОС Linux общается на «вы». Установил и обслуживал сервер его предшественник, который давно ушел из компании.

Для виртуального образа диска сервера был запущен поиск удаленных файлов. Стоит заметить, что, когда имеешь дело с образами, всегда лучше работать с копией, а полученный оригинал хранить отдельно. Естественно, желательно протестировать работоспособность любого программного обеспечения до того, как приступать к исследованию. Приходилось сталкиваться с тем, что образы памяти, созданные разными способами, выдавали при исследовании разный результат. Хотя не стоит исключать вариант, что в систему исследователя закрался вирус, - может быть и такое.

Изучать образ содержимого оперативной памяти системы Linux можно тем же комплектом Volatility, желательно последнего стабильного релиза, хотя после версии 2.0 он вполне справляется. Существует некоторая разница в сравнении с анализом образов RAM семейства Windows - в Volatility нет и в принципе не может быть шаблонов структуры памяти для каждого ядра. Поэтому шаблон придется создать. Для этого необходимо:

• запустить копию исследуемой системы;
• скопировать туда директорию volatility/tools/linux ;
• собрать проект, получив в результате файл module.dwarf , и скопировать его вместе с актуальным /boot/System.map того ядра, на котором работала система при снятии образа RAM, обратно на систему исследователя;
• упаковать оба файла, например в Linux.zip , и поместить архив в volatility/plugins/overlays/linux/ .

Теперь при запуске Volatility с ключом --info созданный тобой профайл будет виден в списке и с ним уже можно начать работу над образом. Без этого ничего не получится, потому что Volatility необходимо знать структуры данных ядра (module.dwarf) и иметь имена переменных, функций и их адреса в памяти (System.map).

Вернемся к исследованию. У меня было подозрение, что система, на которой установлен Zabbix, был скомпрометирована. Осталось понять, как и кто это сделал. Лишних ключей для SSH, посторонних учетных записей в системе не обнаружилось. Я предположил, что в системе есть backdoor , а возможно, и руткит. Для установки подобного рода софта зачастую требуются максимальные привилегии. Это очевидно, достаточно вспомнить основные принципы работы более-менее передовых руткитов в Linux-системах:

скрытие процессов, входов пользователей, модулей ядра, файлов, сетевых соединений;

подмена системных файлов.

В первую очередь необходимо было проверить самые простые вещи, а именно историю выполненных команд: vol -f image.vmem -profile=Linux,x86 linux_bash

История команд была совсем небольшой, и первое, что бросилось в глаза, - это insmod rt.ko . Кстати, в файле истории на диске, конечно, ничего подобного не было, более того, восстановить какие-либо данные из файла истории также не удалось - содержимое уже было перезаписано быстро генерирующимися логами. Так что без образа памяти эти данные были бы неизвестны. Далее предстояло найти упомянутый в истории команд модуль ядра. Модуль был обнаружен на диске в директории PHP-скриптов интерфейса Zabbix.

Последующий анализ этого файла показал, что он прячет сам себя, маскирует при необходимости файлы, предоставляет привилегии root по команде. Управление ведется через файловую систему /proc/rt . С сетью не взаимодействует.

Просмотр сетевых соединений в образе памяти показал, что веб-сервер с Zabbix доступен из интернета. Конечно, я об этом не спрашивал, но подразумевал, что систему мониторинга в сеть никто не выставляет. Позже я выяснил у администраторов, что они так следят за системой, когда находятся вне офиса (несмотря на наличие VPN-аккаунта у каждого). Удобно, ничего не скажешь.

Я обратил внимание на Zabbix и пожалел, что не присмотрелся к нему раньше, - версия была подозрительно старая - 1.8.4 . Поиск по exploit-db.com показал, что в данной версии в скрипте popup.php присутствует SQL-инъекция, позволяющая получить хеши пользователей (CVE: 2011-4674). Проверка уязвимости показала ее полную работоспособность.

Схема подключения злоумышленника стала очевидна: через веб-шелл запускался back connect , предоставляющий интерактивный шелл, после чего привилегии повышались с помощью руткита. При такой схеме злоумышленник использовал этот хост как промежуточный для передачи зловреда на контроллер домена, а также для передачи базы ntds.dit и SYSTEM . Для эффективного поиска с помощью утилиты md5deep была создана база MD5-хешей всех файлов, восстановленных с образа сервера, после чего среди них произведен поиск хеша кейлоггера. Как результат - искомый файл был найден (правда, не с тем именем), а рядом лежал psexec и другие сопутствующие утилиты, которые были удалены.

Теперь можно было точно сказать, как произошел инцидент: злоумышленник, воспользовавшись уязвимостью Zabbix, получил и подобрал хеш пароля администратора Zabbix. С помощью скриптов Zabbix был загружен и запущен вспомогательный инструмент, в частности ncat для создания обратного соединения, с помощью которого был загружен и запущен локальный эксплойт, - версия ядра была полуторагодовалой давности.

Кстати говоря, Zabbix хранит скрипты в БД, и их следы были обнаружены в файле ibdata1.

После повышения привилегий злоумышленник использовал данную систему и подобранные пароли, которые у одного из админов оказались одинаковыми как в домене, так и в Linux-системе, для проникновения на контроллер домена. Получив доступ к контроллеру домена с правами администратора домена, злоумышленник завладел базой данных хешей паролей пользователей. Так как правила генерации паролей пользователями были весьма простые, а пароли не менялись по несколько лет, они были подобраны без особого труда. Обладая учетными данными большинства пользователей, злоумышленник мог читать их почту.

Ради эксперимента я попробовал сбрутить хеши пользователей домена. Легко и непринужденно за пару часов были вскрыты 90% паролей.

По всей видимости, когда злоумышленнику надоело просто читать почту, он решил ее удалить - тем самым развлечься, или отомстить, или выполнить заказ конкурентов? Его мотивация мне неизвестна.

В итоге система Zabbix была переведена в изолированный сегмент, сетевой трафик поставлен на запись, настроена IDS. Я ждал подключений хулигана, но это уже совсем другая история…

Как защитить свой iDevice

Любой iDevice общается с корпоративным сервером Exchange при помощи протокола ActiveSync. С позиции пользователя - защититься по умолчанию никак нельзя. Политика сервера Exchange подразумевает, что если устройство подключено к корпоративной сети, то администратор должен иметь возможность когда угодно управлять этим устройством для прекращения доступа к конфиденциальной информации. Помимо этого, пользователь, в случае утери или кражи, может зайти в OWA через любой браузер и запустить процесс удаленной очистки.

Если в организации имеется понимающий администратор Exchange - обратиться к нему и попросить убрать права на выполнение данной операции, а еще лучше - убрать доступ к пункту «Мобильные устройства» из веб-интерфейса OWA.

Вердикт

Настало время подвести итоги. К сложившейся ситуации привели ошибки администрирования сети и систем:

• слабая парольная политика - не установлена сложность пароля, не установлен срок действия пароля;
• отсутствует патч-менеджмент - кроме продуктов Microsoft, завязанных на WSUS, системы и софт не обновляется;
• не везде установлено антивирусное ПО - например, на контроллере домена антивирус, скорее всего, помог бы предупредить кражу хешей пользователей;
• отсутствует единая политика по доступу в интернет, доступ разграничивается без внятных правил;
• сеть не сегментирована;
• не осуществляется лог-менеджмент;
• лень.

Данную книгу можно назвать практической энциклопедией. В ней дан максимальный охват проблематики обеспечения информационной безопасности, начиная с современных подходов, обзора нормативного обеспечения в мире и в России и заканчивая рассмотрением конкретных направлений обеспечения информационной безопасности (обеспечение ИБ периметра, противодействие атакам, мониторинг ИБ, виртуальные частные сети и многие другие), конкретных аппаратно-программных решений в данной области. Книга будет полезна бизнес-руководителям компаний и тем, в чью компетенцию входит решение технических вопросов обеспечения информационной безопасности.

Все права защищены. Никакая часть этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети Интернет и в корпоративных сетях, а также запись в память ЭВМ для частного или публичного использования, без письменного разрешения владельца авторских прав. По вопросу организации доступа к электронной библиотеке издательства обращайтесь по адресу

mailto:%[email protected]

[email protected]

Кроме того, 26 ноября 2004 г. были задержаны остальные шестеро подозреваемых, в числе которых были трое сотрудников абонентской службы самой компании «Вымпелком». В ходе следствия выяснилось, что сайт был создан бывшим студентом Московского государственного университета, не работавшим в данной компании.

Делопроизводство по данному инциденту стало возможным благодаря вынесенному в 2003 г. определению Конституционного суда, признавшего, что в детализации вызовов содержится тайна телефонных переговоров, охраняемая законом.

Возможности инсайдера

Двое из числа выявленных среди участников инцидента сотрудников компании «Вымпелком» работали операционистами в компании, а третий являлся бывшим сотрудником и на момент преступления работал на Митинском рынке.

Работа в самой компании операционистами свидетельствует о том, что данные сотрудники имели непосредственной доступ к информации, предлагаемой к продаже на сайте www.sherlok.ru. Кроме того, так как бывший сотрудник компании уже работал на Митинском рынке, то можно предположить, что со временем одним из каналов сбыта данной информации или какой-либо еще информации из баз данных компании «Вымпелком» мог стать и данный рынок.

Последствия

Основными последствиями для компании «Вымпелком» от данного инцидента могли быть удар по репутации самой компании и потеря клиентов. Однако данный инцидент был предан огласке непосредственно благодаря активным действиям самой компании.

Кроме того, предание огласки данной информации могло негативным образом сказаться на клиентах компании «Вымпелком», так как детализация разговоров позволяет сделать вывод о текущей деятельности абонента, его сфере интересов и круге знакомств.

В марте 2005 г. Останкинский районный суд города Москва приговорил подозреваемых, в числе которых трое сотрудников компании «Вымпелком», к различным штрафам . Так, организатор группы оштрафован на 93 000 рублей. Однако работа сайта www.sherlok.ru была прекращена на неопределенный срок только с 1 января 2008 г.

Крупнейшая утечка персональных данных за всю историю Японии

Аннотация

Летом 2006 г. произошла самая крупная утечка персональных данных за всю историю Японии: сотрудник полиграфического и электронного гиганта Dai Nippon Printing украл диск с приватными сведениями почти девяти миллионов граждан.

Описание инцидента

Японская фирма Dai Nippon Printing, специализирующаяся на выпуске полиграфической продукции, допустила крупнейшую утечку в истории своей страны. Хирофуми Йокояма, бывший сотрудник одного из подрядчиков компании, скопировал на мобильный винчестер и украл персональные данные клиентов фирмы. В общей сложности под угрозу попали 8,64 млн человек, так как похищенная информация содержала имена, адреса, телефоны и номера кредитных карт. В похищенной информации содержались сведения о клиентах 43 различных компаний, например о 1 504 857 клиентах компании American Home Assurance, 581 293 клиентах компании Aeon Co и 439 222 клиентах NTT Finance .

После похищения данной информации Хирофуми открыл торговлю приватными сведениями порциями от 100 000 записей. Благодаря стабильному доходу инсайдер даже покинул постоянное место работы. К моменту задержания Хирофуми успел продать данные 150 000 клиентов крупнейших кредитных фирм группе мошенников, специализирующихся на онлайн-покупках. Кроме того, часть данных уже была использована для мошенничества с кредитными картами.

Более половины организаций, данные клиентов которых были похищены, даже не были предупреждены об утечке информации.

Последствия

В результате данного инцидента убытки граждан, которые пострадали из-за мошенничества с кредитными картами, ставшего возможным только вследствие этой утечки, составили несколько миллионов долларов. Всего пострадали клиенты 43 различных компаний, в том числе Toyota Motor Corp., American Home Assurance, Aeon Co и NTT Finance. Однако более половины организаций даже не были предупреждены об утечке.

В 2003 г. в Японии был принят закон Personal Information Protection Act 2003 (PIPA), но прокуратура не смогла его применить в реальном судебном разбирательстве по данному делу в начале 2007 г. Обвинение не смогло инкриминировать инсайдеру нарушение закона PIPA. Его обвиняют лишь в краже винчестера стоимостью 200 долларов.

Не оценили. Запорожский хакер против украинского банка

Аннотация

Бывший системный администратор одного из крупных банков Украины перевел через банк, в котором раньше работал, со счета региональной таможни на счет несуществующей днепропетровской фирмы-банкрота около 5 млн гривен.

Описание инцидента

Карьера системного администратора началась после того, как он окончил техникум и был принят на работу в один из крупных банков Украины в отдел программного и технического обеспечения. Спустя некоторое время руководство заметило его талант и решило, что он больше принесет пользы банку в качестве начальника отдела. Однако приход нового руководства в банке повлек за собой и кадровые перестановки. Его попросили временно освободить занимаемую должность. Вскоре новое руководство начало формировать свою команду, а его талант оказался невостребованным, и ему предложили несуществующую должность заместителя начальника, но уже в другом отделе. В результате таких кадровых перестановок он стал заниматься совершенно не тем, в чем разбирался лучше всего.

Системный администратор не мог мириться с таким отношением руководства к себе и уволился по собственному желанию. Однако ему не давала покоя собственная гордость и обида на руководство, кроме того, ему хотелось доказать, что он лучший в своем деле, и вернуться в отдел с которого началась его карьера.

Уволившись, бывший системный администратор решил вернуть у бывшего руководства интерес к своей персоне посредством использования несовершенства применяемой практически во всех банках Украины системы «Банк-Клиент» . План системного администратора состоял в том, что он решил разработать свою программу защиты и предложить ее банку, вернувшись на свое прежнее место работы. Реализация плана заключалась в проникновении в систему «Банк-Клиент» и внесении в нее минимальных изменений. Весь расчет был сделан на то, что в банке должны были обнаружить взлом системы.

Для проникновения в указанную систему бывший системный администратор воспользовался паролями и кодами, которые узнал еще в процессе работы с данной системой. Вся остальная информация, необходимая для взлома, была получена с различных хакерских сайтов, где в подробностях были расписаны различные случаи взломов компьютерных сетей, методики взлома и размещалось все необходимое для взлома программное обеспечение.

Создав в системе лазейку, бывший системный администратор периодически проникал в компьютерную систему банка и оставлял в ней различные знаки, пытаясь привлечь внимание к фактам взлома. Специалисты банка должны были обнаружить взлом и забить тревогу, но, к его удивлению, проникновения в систему никто даже не замечал.

Тогда системный администратор решил изменить свой план, внеся в него коррективы, которые бы не смогли остаться незамеченными. Он решил подделать платежное поручение и перевести по нему через компьютерную систему банка крупную сумму. С помощью ноутбука и мобильного телефона со встроенным модемом системный администратор около 30 раз проникал в компьютерную систему банка: просматривал документы, счета клиентов, движение денежных средств - в поисках подходящих клиентов. В качестве таких клиентов им были выбраны региональная таможня и днепропетровская фирма-банкрот .

Получив в очередной раз доступ к системе банка, он создал платежное поручение, в котором с лицевого счета региональной таможни снял и перечислил через банк на счет фирмы-банкрота 5 млн гривен. Кроме того, им целенаправленно было сделано несколько ошибок в «платежке», что в свою очередь должно было еще больше способствовать привлечению внимания со стороны специалистов банка. Однако даже такие факты были не замечены специалистами банка, обслуживающими систему «Банк-Клиент», и они спокойно перечислили 5 млн гривен на счет уже не существующей фирмы.

В действительности системный администратор рассчитывал на то, что денежные средства не будут переведены, что факт взлома будет обнаружен до перевода средств, но на практике все оказалось по-другому и он стал преступником и его липовый перевод перерос в кражу.

Факт взлома и хищения денежных средств в особо крупных размерах были обнаружены только через несколько часов после перевода, когда работники банка позвонили на таможню - подтвердить перевод. Но там сообщили, что такую сумму никто не перечислял. Деньги в срочном порядке были возвращены назад в банк, а в прокуратуре Запорожской области заведено уголовное дело.

Последствия

Банк не понес никаких потерь, так как деньги были возвращены владельцу, а компьютерная система получила минимальные повреждения, вследствие чего руководство банка отказалось от каких-либо претензий в адрес бывшего системного администратора.

В 2004 г. указом президента Украины была усилена уголовная ответственность за компьютерные преступления: штрафы от 600 до 1000 не облагаемых налогом минимумов, лишение свободы - от 3 до 6 лет. Однако бывший системный администратор совершил преступление до вступления в силу указа президента.

В начале 2005 г. состоялся суд над системным администратором. Его обвинили в совершении преступления по части 2 статьи 361 Уголовного кодекса Украины - незаконное вмешательство в работу компьютерных систем с нанесением вреда и по части 5 статьи 185 - кража, совершенная в особо крупных размерах. Но так как руководство банка отказалось от каких-либо претензий в его адрес, то статью за кражу с него сняли, а часть 2 статьи 361 поменяли на часть 1 - незаконное вмешательство в работу компьютерных систем.

Бесконтрольный трейдинг в банке Societe Generale

Аннотация

24 января 2008 г. Societe Generale объявил о потере 4,9 млрд евро из-за махинаций своего трейдера Жерома Кервьеля . Как показало внутреннее расследование, в течение нескольких лет трейдер открывал сверхлимитные позиции на фьючерсы на европейские фондовые индексы. Общая сумма открытых позиций составила 50 млрд евро.

Описание инцидента

С июля 2006 по сентябрь 2007 г. компьютерная система внутреннего контроля 75 раз (именно столько раз Жером Кервьель осуществлял несанкционированные операции либо его позиции превышали допустимый лимит) выдавала предупреждение о возможных нарушениях. Сотрудники отдела мониторинга рисков банка не осуществляли детальных проверок по этим предупреждениям .

Впервые экспериментировать с неавторизованным трейдингом Кервьель начал уже в 2005 г. Тогда он занял короткую позицию на акции Allianz, ожидая падения рынка. Вскоре рынок действительно упал (после террористических акций в Лондоне), так были заработаны первые 500 000 евро. О своих чувствах, которые он испытал от своего первого успеха, Кервьель впоследствии рассказал следствию: «Я уже знал, как закрыть мою позицию, и был горд за полученный результат, но вместе с тем и удивлен. Успех заставил меня продолжать, это было как снежный ком… В июле 2007 г. я предложил занять короткую позицию в расчете на падение рынка, но не встретил поддержки со стороны своего руководителя. Мой прогноз оправдался, и мы получили прибыль, на этот раз она была вполне легальной. Впоследствии я продолжал проводить такого рода операции на рынке либо с согласия начальства, либо при отсутствии его явного возражения… К 31 декабря 2007 г. моя прибыль достигла 1,4 млрд евро. В тот момент я не знал, как объявить об этом моему банку, так как это была очень большая, нигде не задекларированная сумма. Я был счастлив и горд, но не знал, как объяснить своему руководству поступление этих денег и не навлечь на себя подозрение в проведении несанкционированных сделок. Поэтому решил скрыть мою прибыль и провести противоположную фиктивную операцию…» .

В действительности в начале января того же года Жером Кервьель вновь вступил в игру с фьючерсными контрактами на три индекса Euro Stoxx 50, DAX и FTSE, помогавшими ему обыгрывать рынок в конце 2007 г. (правда, тогда он предпочитал занимать короткую позицию). По подсчетам, в его портфеле накануне 11 января было 707, 9 тыс. фьючерсов (каждый стоимостью по 42,4 тыс. евро) на Euro Stoxx 50, 93,3 тыс. фьючерсов (192,8 тыс. евро за 1 штуку) на DAX и 24,2 тыс. фьючерсов (82,7 тыс. евро за 1 контракт) на индекс FTSE. В целом спекулятивная позиция Кервьеля равнялась 50 млрд евро, т. е. была больше стоимости банка, в котором он работал .

Зная время проверок, он в нужный момент открывал фиктивную хеджирующую позицию, которую позже закрывал. В результате проверяющие никогда не видели ни одной позиции, которую можно было назвать рискованной. Их не могли насторожить и крупные суммы сделок, которые вполне обычны для рынка фьючерсных контрактов по индексам. Подвели его фиктивные сделки, проводимые со счетов клиентов банка. Использование счетов различных клиентов банка не приводило к видимым для контролеров проблемам. Однако по истечении определенного времени Кервьель начал использовать счета одних и тех же клиентов, что привело к «ненормальной» активности, наблюдаемой за данными счетами, и, в свою очередь, привлекло внимание контролеров . Это стало концом аферы. Выяснилось, что партнером Кервьеля по мультимиллиардной сделке был крупный немецкий банк, якобы подтвердивший астрономическую транзакцию по электронной почте. Однако электронное подтверждение вызвало у проверяющих подозрения, для проверки которых в Societe Generale была создана комиссия. 19 января в ответ на запрос немецкий банк не признал эту транзакцию, после чего трейдер согласился дать признательные показания .

Когда удалось выяснить астрономические размеры спекулятивной позиции, генеральный директор и председатель совета директоров Societe Generale Даниэль Бутон заявил о своем намерении закрыть открытую Кервьелем рискованную позицию . На это ушло два дня и привело к убыткам в 4,9 млрд евро.

Возможности инсайдера

Жером Кервьель проработал пять лет в так называемом бэк-офисе банка, т. е. в подразделении, которое непосредственно никаких сделок не заключает. В нем занимаются только учетом, оформлением и регистрацией сделок и ведут контроль за трейдерами. Данная деятельность позволила понять особенности работы систем контроля в банке.

В 2005 г. Кервьеля повысили. Он стал настоящим трейдером. В непосредственные обязанности молодого человека входили элементарные операции по минимизации рисков. Работая на рынке фьючерсных контрактов на европейские биржевые индексы, Жером Кервьель должен был следить за тем, как меняется инвестиционный портфель банка. А его основной задачей, как объяснил один из представителей Societe Generale, было сокращать риски, играя в противоположном направлении: «Грубо говоря, видя, что банк ставит на красное, он должен был ставить на черное». Как у всех младших трейдеров, у Кервьеля был лимит, превышать который он не мог, за этим следили его бывшие коллеги по бэк-офису. В Societe Generale существовало несколько уровней защиты, например трейдеры могли открывать позиции только со своего рабочего компьютера. Все данные об открытии позиций автоматически в реальном времени передавались в бэк-офис. Но, как говорится, лучший браконьер - бывший лесничий. И банк совершил непростительную ошибку, поставив бывшего лесничего в положение охотника. Жерому Кервьелю, имевшему за плечами почти пятилетнюю практику контроля за трейдерами, не составило большого труда обойти эту систему. Он знал чужие пароли, знал, когда в банке проходят проверки, хорошо разбирался в информационных технологиях .

Причины

Если Кервьель и занимался мошенничеством, то не в целях личного обогащения. Это говорят его адвокаты, это же признают и представители банка, называя действия Кервьеля иррациональными. Сам Кервьель говорит, что действовал исключительно в интересах банка и хотел только доказать свои таланты трейдера .

Последствия

Его деятельность по итогам 2007 г. принесла банку около 2 млрд евро прибыли. Во всяком случае так говорит сам Кервьель, утверждая, что руководство банка наверняка знало, чем он занимается, но предпочитало закрывать глаза до тех пор, пока он был в прибыли .

Закрытие открытой Кервьелем рискованной позиции привело к убыткам в 4,9 млрд евро.

В мае 2008 г. Даниэль Бутон покинул пост генерального директора Societe Generale, на этой должности его сменил Фредерик Удеа . Год спустя он был вынужден уйти и с поста председателя совета директоров банка. Причиной ухода стала острая критика со стороны прессы: Бутона обвиняли в том, что подконтрольные ему топ-менеджеры банка поощряли рискованные финансовые операции, осуществляемые сотрудниками банка.

Несмотря на поддержку совета директоров, давление на господина Бутона усиливалось. Его отставки требовали акционеры банка и многие французские политики. Президент Франции Никола Саркози также призвал Даниэля Бутона уйти с поста, после того как стало известно, что в течение полутора лет до скандала компьютерная система внутреннего контроля Societe Generale 75 раз, т. е. всякий раз как Жером Кервьель осуществлял несанкционированные операции, выдавала предупреждение о возможных нарушениях .

Сразу после обнаружения потерь Societe Generale создал специальную комиссию по расследованию действий трейдера, в которую вошли независимые члены совета директоров банка и аудиторы PricewaterhouseCoopers. Комиссия пришла к выводу, что система внутреннего контроля в банке была недостаточно эффективной. Это привело к тому, что банк не смог предотвратить столь крупное мошенничество. В отчете говорится, что «сотрудники банка не проводили систематических проверок» деятельности трейдера, а сам банк не располагает «системой контроля, которая могла бы предотвратить мошенничество» .

В отчете о результатах проверки трейдера говорится, что по итогам расследования принято решение «существенно укрепить процедуру внутреннего надзора за деятельностью сотрудников Societe Generale». Это будет сделано при помощи более строгой организации работы различных подразделений банка и координации их взаимодействия. Также будут приняты меры, позволяющие отслеживать и персонифицировать трейдерские операции сотрудников банка посредством «укрепления системы ИТ-безопасности и разработки высокотехнологичных решений по персональной идентификации (биометрии)».