С какой целью проводится расследование инцидентов

ВЗК РФ Статья 95. Цели и порядок расследования авиационного происшествия или инцидента

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

(в ред. Федерального закона от 18.03.2023 N 65-ФЗ)

(см. текст в предыдущей редакции)

2. Целями расследования авиационного происшествия или инцидента являются установление причин авиационного происшествия или инцидента и принятие мер по их предотвращению в будущем.

Установление чьей-либо вины и ответственности не является целью расследования авиационного происшествия или инцидента.

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

(в ред. Федерального закона от 22.08.2004 N 122-ФЗ)

(см. текст в предыдущей редакции)

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

Готовимся к расследованию инцидентов

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

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

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

Классический цикл реагирования на инциденты по методике SANS

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

Формирование версий, объясняющих причины возникновения инцидента (например, «вредоносное ПО установилось на хост, потому что пользователь запустил его из фишингового письма» или «инцидент — ложная тревога, потому что пользователь посетил легитимный сайт, располагающийся на том же хостинге, что и сервер управления вредоносным ПО»).
Приоритизация версий по степени вероятности. Вероятность рассчитывается (а скорее — прикидывается) на основе статистики прошлых инцидентов, критичности инцидента или системы, а также на базе собственного опыта.
Проработка каждой версии, поиск фактов, доказывающих или опровергающих ее.

Сценарий 1

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

В рамках проработки этой версии следует выполнить три простых действия:

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

Во-первых, стандартная настройка аудита Windows не логирует факты запуска процессов (событие 4688), поэтому его надо включить заблаговременно в доменной групповой политике. Если же так получилось, что этот аудит не был включен заранее, можно попробовать получить список исполняемых файлов из других артефактов Windows, например, из реестра Amcache. Извлечь данные из этого файла реестра можно с помощью утилиты AmcaheParser.

Пример извлечения фактов запуска процессов из Amcache.hve

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

Во-вторых, свидетельства запуска таких процессов, как cmd.exe, powershell.exe, wscript.exe и других интерпретаторов, принесет мало пользы без информации о командной строке, с которой процессы были запущены, т.к. в ней содержится путь к потенциально вредоносному файлу-скрипту.

Запуск интерпретатора скриптов без информации о том, что за скрипт был запущен

Еще одна особенность Windows заключается в том, что аудит командной строки запускаемого процесса производится отдельной настройкой доменной групповой политики: Computer Configuration -> Policies -> Administrative Templates -> System -> Audit Process Creation -> Include command line in process creation events. При этом довольно популярная Windows 7/2008 не логирует командную строку без установленного обновления KB3004375, поэтому поставьте его заранее.

Если же так получилось, что вы заранее ничего не настроили или забыли про обновление, можно попытаться узнать расположение скрипта в файлах Prefetch (утилита в помощь). В них содержится информация о всех файлах (в основном DLL), загруженных в процесс в первые 10 секунд жизни. И скрипт, содержащийся в аргументах командной строки интерпретатора, наверняка будет присутствовать там же.

Пример поиска «потерянного» аргумента командной строки в Prefetch

Но и этот метод совсем не надежен — при очередном запуске процесса кеш Prefetch перезатрется.

Включите расширенный аудит создания и завершения процессов.
Включите логирование аргументов командной строки процессов.
Установите обновление KB3004375 на Windows 7/Server 2008.

Сценарий 2

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

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

Существует много способов узнать, какой процесс инициировал соединение: можно запустить netstat и увидеть текущие сокеты или собрать дамп памяти и потом натравить на него volatility, которая может показать в том числе уже завершенные соединения. Но все это долго, не масштабируемо и самое главное — не надежно. Намного надежнее получать всю необходимую информацию из security-журнала Windows.

Корреляция события «обращение к вредоносному IP-адресу» в SIEM-системе HPE Arcsight и соответствующий обращению процесс в security-логе Windows

Подготовка к расследованию

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

При этом журнал может начать быстро забиваться, поэтому увеличьте его размер до 2-3 Гб. По нашему опыту, на обычном пользовательском хосте такого объема хватает примерно на 3 дня записи всех сокетов, а этого срока вполне достаточно для успешного расследования.

На высоконагруженных серверах, вроде контроллеров домена, web-серверов и т.п., так делать не стоит, журнал переполнится намного быстрее.

Сценарий 3

Ваша NG/ML/Anti-APT система детектирования аномалий сообщает, что с 30 хостов происходит разведка с целью получения одних и тех же учетных записей.

При попадании в новую сеть злоумышленники, как правило, пытаются узнать, какие сервисы присутствуют в ней и какие учетные записи используются — это очень помогает в процессе дальнейшего движения по инфраструктуре. В частности, эту информацию можно получить из самой Active Directory с помощью команды net user /domain.

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

Разведка зафиксирована на 30 хостах в отношении одних и тех же объектов AD, потому что команду net запустил один и тот же легитимный пользователь — администратор.
Разведка зафиксирована на 30 хостах в отношении одних и тех же объектов AD, потому что это сделало одно и тоже легитимное ПО.

Подготовка к расследованию

Необходимо организовать долговременное хранение, как минимум, следующих данных из журналов общих сервисов сети:

Контроллеры домена — входы, выходы учетных записей и выдача билетов Kerberos (категория Account Logon в расширенных настройках аудита).
Прокси-серверы — адреса, порты источника и внешнего сервера, а также полный URL.
DNS-серверы — успешные и неуспешные DNS-запросы и их источник внутри сети.
Периметровые маршрутизаторы — Built и Teardown для всех TCP/UDP-соединений, а также соединений, пытающихся нарушить правила логического доступа: например, попытки отправить DNS-запрос наружу напрямую, минуя корпоративный DNS-сервер.

Сценарий 4

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

Реагирование на такой инцидент включает в себя очень большой пласт работ, в том числе анализ всех действий, совершенных из-под этой учетной записи. Часть подобного расследования можно провести, используя только журналы контроллера домена. Например, можно изучить события, связанные выдачей тикетов Kerberos, чтобы понять, куда ходили из-под этой учетки. Или же можно проанализировать события, связанные с изменением критичных объектов AD, чтобы проверить, не изменялся ли состав высокопривилегированных групп (тех же доменных администраторов). Естественно, все это требует заранее настроенного аудита.

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

Суть ее заключается в том, что злоумышленник сам представляется контролером домена, вносит изменения в AD и затем реплицирует (синхронизирует) эти изменения с легитимными контроллерами, таким образом обходя настроенный на них аудит изменений объектов. Результатом подобной атаки может быть добавление пользователя в группу доменных администраторов или более хитрые закрепления через изменение атрибута SID History либо модификацию ACL-объекта AdminSDHolder.

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

Удаление неизвестного контроллера домена из репликации AD

Подготовка к расследованию:

Для расследования действий, совершенных скомпрометированной учетной записью, необходимо заранее включить:
- Аудит входов, выходов учетной записи и выдачу билетов Kerberos (категория Account Logon в расширенных настройках аудита).
- Аудит изменений учетных записей и групп (категория Account Management).
- Включить подробный аудит репликации службы каталогов.
- Организовать долговременное хранение событий 4928/4929, в которых источник событий не является легитимным контроллером домена (признак DCShadow).
Заключение

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

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

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

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

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

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

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

В рамках ГОСТ Р ИСО/МЭК 27001:2006 выделяются следующие виды инцидентов:
- утрата услуг, оборудования или устройств;
- системные сбои или перегрузки;
- ошибки пользователей;
- несоблюдение политики или рекомендаций по ИБ;
- нарушение физических мер защиты;
- неконтролируемые изменения систем;
- сбои программного обеспечения и отказы технических средств;
- нарушение правил доступа.
Для выявления каждой разновидности требуются специализированные программные или программно-аппаратные комплексы, а для расследования – эксперты, которые обладают практическим опытом применения широкого комплекса методик.

Расследование инцидентов состоит из нескольких этапов.

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

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

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

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

Сбор и анализ доказательств

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

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

Выявление виновных и установление причин

На этой стадии устанавливаются следующие факты:
1. что и когда произошло;
2. цель атаки;
3. источник атаки;
4. цели и мотивация атакующего;
5. соучастники на стороне жертвы;
6. уязвимости и инструменты атакующих.
Ликвидация последствий инцидента

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

Результаты и недопущение повторений

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

Порядок расследования аварий и инцидентов на ОПО: пять новшеств

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

Расследование причин аварий и инцидентов на ОПО регулируется:

• ст. 12 Федерального закона от 21 июля 1997 г. № 116-ФЗ[1];• ст. 11.1 Федерального закона от 21 июля 1997 г. № 117-ФЗ[2];

• Порядком проведения технического расследования причин аварий, инцидентов и случаев утраты взрывчатых материалов промышленного назначения[3].

Приказом Ростехнадзора от 14 апреля 2022 г. № 126[4] внесены поправки в Порядок. Поправки преследовали три цели:

1. Конкретизировать срок проведения технического расследования причин аварии на ОПО (аварии ГТС) комиссией по техническому расследованию причин аварии.

2. Дать Ростехнадзору законную возможность обязывать эксплуатирующую ОПО организацию расследовать аварии, информацию о которых служба получила не из официального оперативного сообщения, а иными способами (из обращений граждан, общественников, СМИ, социальных сетей).

3. Уточнить отдельные формулировки Порядка и исправить ошибки.

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

❶ Уточнены сроки проведения технического расследования аварии.

Действующий Порядок — «постгильотинный» нормативный акт. Он вступил в силу 1 января 2021 г. Сразу выяснилось, что применение ряда его требований делает невозможной работу комиссии в силу того, что нарушена логика определения сроков отдельных этапов расследования. Эту проблему благодаря одному из постоянных подписчиков мы поднимали на страницах журнала[5]. Напомним ее суть.

Специалисты Ростехнадзора в процессе пересмотра нормативки «вместе с водой выплеснули и ребенка», сделав формулировку по сроку технического расследования аварии в п. 12 Порядка неопределенной. В старом Порядке[6] была корректная четкая формулировка: 30 календарных дней с момента подписания приказа о создании комиссии и до момента подписания акта. В пришедшем ему на смену документе срок расследования не установлен, зато установлен период от завершения расследования и до составления акта – не более 30 календарных дней:

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

25 мая 2022 г. был опубликован Приказ № 126 о внесении изменений в Порядок[7]. Он вступит в силу 1 сентября 2022 г. и будет действовать до 1 января 2027 г.

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

В алгоритме используем обозначения:
фиолетовым цветом — регламентированы Порядком;
серым цветом— процедура регламентирована ЛНА ЭО — Положением (регламентом) по техническому расследованию причин инцидентов.
1 Список организаций:
- Территориальное управление РТН;
- администрация муниципального образования страховую организацию, с кото-
- рой заключен договор обязательного страхования гражданской ответственности;
- профсоюзное объединение по субъекту федерации, территориальное управ-
- ление Росприроднадзора;
- комиссия по предупреждению и ликвидации чрезвычайных ситуаций и обе-
- спечению пожарной безопасности субъекта федерации (при авариях);
- главное управление МЧС России по субъекту федерации;
2 Форма квартального отчета не регламентирована НПА. Обычно подают
краткую информацию о том, где, когда произошел инцидент, и прикладывается
акт его расследования с материалами к нему.
3 См. п. 32 Порядка.
4 Ранее Порядок предусматривал возможность участия представителя тер-
риториального управления РТН, теперь все дано на откуп ЭО.

❷ Уточнены цели технического расследования аварии.

Новая редакция Порядка обязывает с 1 сентября в ходе расследования установить не тех, кто виновен в аварии, а тех, кто допустил нарушения требований промышленной безопасности или требований к обеспечению безопасности ГТС, и суть нарушений:

Обратите внимание!

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

Итак, после 1 сентября 2022 г. комиссия в ходе проведения технического расследования причин аварии на ОПО или ГТС должна установить:

• обстоятельства и причины аварии;

• размер причиненного вреда;

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

• лиц, допустивших эти нарушения;

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

• меры по предупреждению подобных аварий

и зафиксировать эти выводы в материалах дела: акте расследования аварии и других документах.

❸ Техническое расследование причин аварий может начаться по итогам проверки.

До 1 сентября 2022 г. единственным основанием для назначения комиссии, с которого начинается любое расследование аварии, было оперативное сообщение о случившемся.

Но не все эксплуатанты добросовестны. Бывает, что единственным источником информации о случившейся аварии является пост в соцсети или сообщение, пересылаемое в мессенджере.

С 1 сентября все изменится. Закон о госконтроле[8] гармонизирован с Порядком, и Ростехнадзор получил законное право инициировать расследование аварии после получения информации не только из оперативного сообщения, но и из других источников:

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

[1] Федеральный закон от 21 июля 1997 г. № 116-ФЗ «О промышленной безопасности опасных производственных объектов» (в ред. от 11 июня 2021 г.; далее — Федеральный закон № 116-ФЗ).

[2] Федеральный закон от 21 июля 1997 г. № 117-ФЗ «О безопасности гидротехнических сооружений» (в ред. от 11 июня 2021 г.; далее — Федеральный закон № 117-ФЗ).

[3] Утв. Приказом от 8 декабря 2020 г. № 503 (далее — Порядок).

[4] Приказ Ростехнадзора от 14 апреля 2022 г. № 126 «О внесении изменений в Порядок проведения технического расследования причин аварий, инцидентов и случаев утраты взрывчатых материалов промышленного назначения, утвержденный приказом Федеральной службы по экологическому, технологическому и атомному надзору от 8 декабря 2020 г. № 503» (далее — Приказ № 126).

[5] Подберезина С. Г. О сроках расследования причин аварий // Промышленная безопасность. Разъяснения. Вопросы. Ответы — 2021. — № 6. — С. 65.

[6] Порядок проведения технического расследования причин аварий, инцидентов и случаев утраты взрывчатых материалов промышленного назначения на объектах, поднадзорных Федеральной службе по экологическому, технологическому и атомному надзору, утв. Приказом Ростехнадзора от 19 августа 2011 г. № 480; далее — старый Порядок.

[8] Федеральный закон от 31 июля 2020 г. № 248-ФЗ «О государственном контроле (надзоре) и муниципальном контроле в Российской Федерации» (в ред. от 6 декабря 2021 г.; далее — Закон о госконтроле).

Т. Н. Гордюшина,
специалист по охране труда ООО «СтройИндустрия»

Материал публикуется частично. Полностью его можно прочитать в журнале «Промышленная безопасность» № 4, 2022.
Похожие публикации: