Мониторинг и реагирование на инциденты информационной безопасности
Мы продолжаем синхронизировать представления о работе SOC-отдела в компании. В этой статье опишем процессы мониторинга и реагирования, которые составляют основу рабочей деятельности SOC-аналитика. Конечно, от компании к компании детали реализации этих процессов будут разниться, тем не менее полезно выделить основные этапы и позиции, по которым ИБ-сообщество пришло плюс-минус к единому представлению.
Жизненный цикл инцидентов ИБ
Каждый инцидент ИБ внутри SOC-отдела проходит 7 этапов, составляющих жизненный цикл инцидента.
Рассмотрим, что происходит на каждом из этапов реагирования на инциденты.
Модель жизненного цикла инцидента помогает организациям не только эффективно реагировать на угрозы безопасности, но и улучшать свою общую стратегию безопасности на основе опыта прошлых событий.
Имея в виду жизненный цикл инцидента, компания разрабатывает плейбуки, в которых описывает желаемое поведение сотрудников в случае возникновения нежелательных событий.
- Обнаружение. Этот этап чаще всего реализуется с помощью систем мониторинга, анализа логов, сигналов тревог и других источников данных. В этап обнаружения также входит регистрация найденных инцидентов ИБ в IRP/SOAR и уведомление всех ответственных о случившемся инциденте ИБ. Здесь же начинается первичный сбор доказательств и первичный учёт события для дальнейшей обработки и аудита.
- Идентификация. В этап входят классификация и приоритизация инцидента. Инцидент классифицируется по типу, серьёзности и потенциальным последствиям для организации. Оценивается приоритетность реагирования на инцидент. На этом этапе принимается решение о запуске процесса управления инцидентом и начале формальной обработки инцидентов в соответствии с плейбуком.
- Локализация. На этом этапе команда SOC проводит более глубокий анализ инцидента, выявляет его характеристики и масштаб, разрабатывает стратегию и принимает меры для устранения угрозы. При необходимости проводится эскалация на руководство организации для принятия решений и сбора более широкой рабочей группы.
- Уничтожение. На этом этапе команда SOC проводит работы по масштабному удалению всей вредоносной составляющей в инфраструктуре.
- Восстановление. Это этап, на котором принимаются меры для восстановления нормального функционирования системы или услуг, пострадавших от инцидента.
- Документирование. Все действия и процессы, выполненные в ходе реагирования на инцидент, заносятся в IRP/SOAR или оформляются в виде отчётов. Фиксируется описание инцидента, предпринятые шаги, использованные ресурсы и результаты.
- Действия после инцидента (постанализ). После завершения инцидента проводится анализ его хода, причин возникновения и эффективности принятых мер. На основе анализа инцидента и его последствий вносятся изменения в политики безопасности, процессы мониторинга и защиты, чтобы предотвратить подобные инциденты в будущем. Этот этап усиливает общую кибербезопасность организации
Модель жизненного цикла инцидента помогает организациям не только эффективно реагировать на угрозы безопасности, но и улучшать свою общую стратегию безопасности на основе опыта прошлых событий.
Имея в виду жизненный цикл инцидента, компания разрабатывает плейбуки, в которых описывает желаемое поведение сотрудников в случае возникновения нежелательных событий.
Playbook
-
Playbook (плейбук) — это набор и порядок действий в случае типовых инцидентов ИБ, которые могут случиться в вашей организации. Именно в плейбуке каждая организация описывает порядок действий для идентификации и дальнейшего реагирования.
Плейбук может содержать:
- Описания угроз: информация о различных видах угроз, таких как вирусы, атаки DDoS, внутренние угрозы и т. д.
- Критерии для идентификации угрозы: шаги для определения того, является ли возникший алерт инцидентом ИБ.
- Шаги по реагированию: последовательность действий и процедур, которые должны быть выполнены при обнаружении определённой угрозы или инцидента. Например, какие команды или индивидуумы должны быть оповещены, какие системы должны быть отключены и т. д.
- Инструкции по восстановлению: рекомендации по возвращению к нормальному функционированию систем и процессов после того, как угроза была устранена.
- Сценарии обучения и упражнения: планы для тренировочных сценариев или упражнений, которые помогают персоналу развивать навыки реагирования на киберугрозы.
Мониторинг и выявление инцидентов ИБ
Процесс мониторинга — это первичная точка входа всех событий ИБ и потенциальных инцидентов ИБ для первой линии сотрудников SOC. И состоит он из следующих шагов:
1. Сбор данных. Первым этапом для построения процесса мониторинга будет сбор данных из различных источников выявления инцидентов. На этом этапе у SOC-аналитика должен быть список одобренных в компании источников, которые требуется мониторить.
1. Сбор данных. Первым этапом для построения процесса мониторинга будет сбор данных из различных источников выявления инцидентов. На этом этапе у SOC-аналитика должен быть список одобренных в компании источников, которые требуется мониторить.
Источники выявления инцидентов
SIEM + IRP/SOAR — это основной инструмент, из которого мы будем узнавать о случившихся событиях ИБ. SIEM генерирует события ИБ и регистрирует их в IPR/SOAR. В SIEM же будут попадать события со всех присутствующих в организации средств защиты информации.
Электронная почта — ещё один сильный инструмент. В каждой организации у SOC есть групповой почтовый ящик, и все сотрудники этой организации должны быть уведомлены, что в случае выявления подозрений на инцидент ИБ необходимо сообщать на него.
Любые другие средства коммуникации, которые могут быть организованы для получения различных событий ИБ, например телефон горячей линии, социальные сети.
Внешние организации ИБ — если у вас есть платные услуги от компаний, занимающихся информационной безопасностью.
Регуляторы, такие как ЦБ, ФСТЭК, ФСБ, ГосСОПКА, тоже могут сообщать нам об инцидентах. Обязательно нужно настроить с ними канал коммуникации и мониторить его. На практике он реализуется через почту или личный кабинет регулятора.
Другое — объединю всё остальное в один пункт. У вашей организации могут быть реализованы различные другие процессы, такие как TI, TH, VM. В рамках этих процессов будет находиться много событий ИБ, которые нужно будет проверять.
Электронная почта — ещё один сильный инструмент. В каждой организации у SOC есть групповой почтовый ящик, и все сотрудники этой организации должны быть уведомлены, что в случае выявления подозрений на инцидент ИБ необходимо сообщать на него.
Любые другие средства коммуникации, которые могут быть организованы для получения различных событий ИБ, например телефон горячей линии, социальные сети.
Внешние организации ИБ — если у вас есть платные услуги от компаний, занимающихся информационной безопасностью.
Регуляторы, такие как ЦБ, ФСТЭК, ФСБ, ГосСОПКА, тоже могут сообщать нам об инцидентах. Обязательно нужно настроить с ними канал коммуникации и мониторить его. На практике он реализуется через почту или личный кабинет регулятора.
Другое — объединю всё остальное в один пункт. У вашей организации могут быть реализованы различные другие процессы, такие как TI, TH, VM. В рамках этих процессов будет находиться много событий ИБ, которые нужно будет проверять.
2. Агрегация и хранение данных. Собранные данные агрегируют в централизованное хранилище, где они могут быть удобно хранимы и использованы для дальнейшего анализа.
3. Анализ и обработка. Здесь данные проходят через процесс анализа, включая сравнение с шаблонами нормального поведения, выявление аномалий, распознавание угроз и определение потенциальных инцидентов безопасности. Процесс анализа происходит с помощью правил корреляции.
3. Анализ и обработка. Здесь данные проходят через процесс анализа, включая сравнение с шаблонами нормального поведения, выявление аномалий, распознавание угроз и определение потенциальных инцидентов безопасности. Процесс анализа происходит с помощью правил корреляции.
- Правило корреляции — это логическое условие (или несколько условий), при выполнении которого генерируется алерт.
Примеры
Выделяют простые, корреляционные и комбинированные правила корреляции.
Простое правило: например, происходит обнаружение ВПО. Как только это случается, у нас генерируется событие ИБ. Корреляционное правило: например, если происходит 5 неуспешных попыток подключиться по RDP в течение 5 минут, то генерируется алерт.
Комбинированное правило: мы можем использовать простые и корреляционные правила вместе, например простым правилом мы генерируем алерт с неуспешными событиями входа и записываем результаты во временное хранилище в SIEM (их обычно называют листами), а корреляционным правилом смотрим на неуспешные попытки в листе и считаем количество алертов с каждого уникального хоста. Это позволит растянуть алерты по времени и ловить очень медленные переборы паролей внутри инфраструктуры.
Простое правило: например, происходит обнаружение ВПО. Как только это случается, у нас генерируется событие ИБ. Корреляционное правило: например, если происходит 5 неуспешных попыток подключиться по RDP в течение 5 минут, то генерируется алерт.
Комбинированное правило: мы можем использовать простые и корреляционные правила вместе, например простым правилом мы генерируем алерт с неуспешными событиями входа и записываем результаты во временное хранилище в SIEM (их обычно называют листами), а корреляционным правилом смотрим на неуспешные попытки в листе и считаем количество алертов с каждого уникального хоста. Это позволит растянуть алерты по времени и ловить очень медленные переборы паролей внутри инфраструктуры.
4. Обнаружение угроз. После анализа система мониторинга может обнаружить угрозы или аномалии, которые требуют дальнейшего расследования и реагирования.
5. Генерация тревог и уведомлений. При обнаружении аномалий или потенциальных угроз система мониторинга генерирует тревоги и уведомления, чтобы персонал SOC мог оперативно приступить к реагированию. По результатам данного этапа требуется завести карточку инцидента, разослать уведомления и пуши.
А точно ли надо генерировать пуши и уведомления? А может это False positive? Может быть, произошло легитимное событие? Ответы дают критерии для идентификации угрозы.
5. Генерация тревог и уведомлений. При обнаружении аномалий или потенциальных угроз система мониторинга генерирует тревоги и уведомления, чтобы персонал SOC мог оперативно приступить к реагированию. По результатам данного этапа требуется завести карточку инцидента, разослать уведомления и пуши.
А точно ли надо генерировать пуши и уведомления? А может это False positive? Может быть, произошло легитимное событие? Ответы дают критерии для идентификации угрозы.
Идентификация угрозы в ИБ
Давайте разберём типовые критерии, с которыми сталкиваются сотрудники SOC для определения, является ли обнаруженное событие значимым для организации инцидентом:
Критерии определяет каждая организация индивидуально в зависимости от события ИБ, особенностей инфраструктуры и других факторов в организации.
- Выполнение детектирующей логики алерта. Нужно проверить, все ли условия для срабатывания алерта выполнены и выполнены ли они корректно. Если видим ошибку в логике правила, алерт можно закрывать как ложное срабатывание (False positive).
- Подтверждение ещё одним СЗИ. Средства защиты тоже ошибаются, и нам нужно обязательно проверить вердикт средств защиты. Сделать это можно несколькими способами: проверить выявленную угрозу ещё одним средством защиты или обратиться в вендорскую поддержку для установления точного вердикта сработки.
- Подтверждение владельцами процесса, на котором произошла сработка. Требуется определить источник инцидента и запросить подтверждение о легитимности действий у пользователей или администраторов участка, на котором произошла сработка. Ошибки пользователей, собственные разработки, проведение работ по настройке инфраструктуры, по мониторингу инфраструктуры будут генерировать события, очень похожие на инциденты, и с таким типом алертов придётся сталкиваться довольно часто.
Критерии определяет каждая организация индивидуально в зависимости от события ИБ, особенностей инфраструктуры и других факторов в организации.
Заметки на полях:
Если плейбук вашей организации не требует выполнения всех критериев, а только нескольких, или требует стремительных действий, значит, следует верить плейбуку.
После того как угроза идентифицирована, необходимо присвоить ей классификатор и приоритет. А теперь давайте посмотрим, что следует делать, если необходимые критерии выполнены и вы убеждены, что это реальный инцидент ИБ.
Реагирование на инциденты ИБ. Пошаговый план
Когда всё-таки это инцидент, необходимо следующее:
1
Локализация текущей угрозы для инфраструктуры:
- Изоляция заражённого или скомпрометированного хоста от локальной сети организации.
- Изоляция сетевого сегмента в сети организации.
- Отключение доступа в интернет, как точечно, так и глобально, по ситуации.
- Отключение учётной записи.
- Блокировка найденных индикаторов компрометации (IP, hash, DNS-name, URL).
- Важно!
Одна из дополнительных целей этого этапа — не допустить уничтожения следов атаки, которые потребуются при расследовании.
2
Ликвидация найденной угрозы:
- Удаление вредоносных файлов.
- Удаление фишинговых писем из почтовых ящиков сотрудников.
- Смена паролей от затронутых учётных записей.
- Подготовка бэкапов по утраченным данным.
- Переустановка ОС на затронутых хостах (если отсутствует возможность точечно удалить вредоносную составляющую).
3
Восстановление работоспособности пострадавшей инфраструктуры:
- Включение изолированных и отключённых частей инфраструктуры (хосты, сегменты, учётные записи, интернет).
- Восстановление утраченных данных.
- Переустановка операционных систем на затронутых хостах или восстановление данных из бэкапов.
4
Профилактика повторения этого инцидента:
- Постановка найденных индикаторов компрометации на мониторинг.
- Сканирование инфраструктуры для поиска и устранения найденных уязвимостей.
- Доработка правил для выявления инцидентов.
- Доработка средств защиты для предотвращения подобных инцидентов.
Мы разобрали основные критерии в жизненном цикле инцидента. Давайте посмотрим, как же этот процесс выглядит на практике.
Практический пример инцидента ИБ
Ситуация: рассылка писем с вредоносным вложением на сотрудников организации. Мы зафиксировали несколько алертов на средствах антивирусной защиты. Файл детектировался сигнатурой ransomware и не был удалён. Также мы получили три сообщения от случайных сотрудников на почту о подозрительном письме с вложением «Документы на подпись.exe", а один сотрудник пожаловался, что у него появился баннер на весь экран.
Задача: разобрать инцидент с точки зрения процесса мониторинга и реагирования.
Решение:
Задача: разобрать инцидент с точки зрения процесса мониторинга и реагирования.
Решение:
Обнаружение. Мы задетектировали инцидент ИБ сразу двумя способами: средствами антивирусной защиты и уведомлениями от сотрудников на почту.
Идентификация. В результате анализа, понятно, что вредоносное ПО попало на компьютеры пользователей через почту, значит, инцидент можно классифицировать как фишинговую рассылку ВПО. Критичность инцидента очень высокая, потому что письма получило большое количество людей и файл успешно и корректно детектируется средствами антивирусной защиты. Следовательно, реагировать нужно незамедлительно.
Локализация. Для локализации угрозы нам потребуется отключить от локальной сети все компьютеры, на которых был зафиксирован успешный запуск вредоносного вложения, чтобы предотвратить распространение вредоносного ПО. И во избежание получения новых писем блокируем почтовый ящик отправителя.
Уничтожение. Нам нужно почистить все почтовые ящики пользователей от вредоносных писем, а также удалить вредоносные файлы с отключённых компьютеров.
Восстановление. Затем нужно провести проверку других устройств на предмет заражения, а заражённые компьютеры нужно отформатировать или восстановить из резервной копии и подключить обратно к сети.
Документирование. Все действия, проведённые командой SOC, записать в журнале инцидентов, включая временные тайм-марки, ход событий, принятые меры и результаты.
Действия после инцидента (постанализ). После завершения инцидента провести анализ причин атаки. В данной ситуации решено, что письма с такими вложениями лучше блокировать автоматически. То есть нужно заблокировать возможность получения писем, которые содержат файлы с расширением .exe, а также поменять настройки средств антивирусной защиты и поставить автоматическое удаление при нахождении подобных файлов.
Идентификация. В результате анализа, понятно, что вредоносное ПО попало на компьютеры пользователей через почту, значит, инцидент можно классифицировать как фишинговую рассылку ВПО. Критичность инцидента очень высокая, потому что письма получило большое количество людей и файл успешно и корректно детектируется средствами антивирусной защиты. Следовательно, реагировать нужно незамедлительно.
Локализация. Для локализации угрозы нам потребуется отключить от локальной сети все компьютеры, на которых был зафиксирован успешный запуск вредоносного вложения, чтобы предотвратить распространение вредоносного ПО. И во избежание получения новых писем блокируем почтовый ящик отправителя.
Уничтожение. Нам нужно почистить все почтовые ящики пользователей от вредоносных писем, а также удалить вредоносные файлы с отключённых компьютеров.
Восстановление. Затем нужно провести проверку других устройств на предмет заражения, а заражённые компьютеры нужно отформатировать или восстановить из резервной копии и подключить обратно к сети.
Документирование. Все действия, проведённые командой SOC, записать в журнале инцидентов, включая временные тайм-марки, ход событий, принятые меры и результаты.
Действия после инцидента (постанализ). После завершения инцидента провести анализ причин атаки. В данной ситуации решено, что письма с такими вложениями лучше блокировать автоматически. То есть нужно заблокировать возможность получения писем, которые содержат файлы с расширением .exe, а также поменять настройки средств антивирусной защиты и поставить автоматическое удаление при нахождении подобных файлов.
Итоги
- Жизненный цикл инцидента включает обнаружение, идентификацию, локализацию, уничтожение, восстановление, документирование и постанализ.
- Чтобы проверить, что событие является инцидентом, нужно убедиться в выполнении детектирующей логики алерта, подтвердить обнаружение ещё одним СЗИ и валидировать у администратора участка, на котором произошла сработка, легитимность события.
- Подробный план действий при подверженном инциденте описан в плейбуке организации.
Курс Аналитик SOC в Inseca
Освойте для себя SOC за 3 месяца и получите навыки, необходимые для выявления киберугроз и оперативного реагирования на инциденты информационной безопасности. Курс включает практику в реальных кейсах. Подходит Аналитикам 1 линии для расширения, систематизации знаний, чтобы перейти на 2 и 3 линию, а также системным администраторам, инженерам сетей, чтобы перейти на должность SOC-аналитика.
