Содержание
- Пример расследования инцидента с помощью KUMA
- Условия возникновения инцидента
- Шаг 1. Предварительная подготовка
- Шаг 2. Назначение алерта пользователю
- Шаг 3. Проверка на соответствие между сработавшим правилом корреляции и данными событий алерта
- Шаг 4. Анализ информации об алерте
- Шаг 5. Проверка на ложное срабатывание
- Шаг 6. Определение критичности алерта
- Шаг 7. Создание инцидента
- Шаг 8. Расследование
- Шаг 9. Поиск связанных активов
- Шаг 10. Поиск связанных событий
- Шаг 11. Запись причин инцидента
- Шаг 12. Реагирование на инцидент
- Шаг 13. Восстановление работоспособности активов
- Шаг 14. Закрытие инцидента
Пример расследования инцидента с помощью KUMA
Выявление атаки на IT-инфраструктуру организации с помощью KUMA состоит из следующих шагов:
- Предварительная подготовка
- Назначение алерта пользователю
- Проверка на соответствие между сработавшим правилом корреляции и данными событий алерта
- Анализ информации об алерте
- Проверка на ложное срабатывание
- Определение критичности алерта
- Создание инцидента
- Расследование
- Поиск связанных активов
- Поиск связанных событий
- Запись причин инцидента
- Реагирование
- Восстановление работоспособности активов
- Закрытие инцидента
В описании шагов приводится пример действий по реагированию, которые мог бы выполнить аналитик при обнаружении инцидента в IT-инфраструктуре организации. Вы можете посмотреть описание и пример для каждого шага, перейдя по ссылке в его названии. Примеры относятся непосредственно к описываемому шагу.
Условия инцидента, для которого приводятся примеры, см. в разделе Условия возникновения инцидента.
Более подробную информацию о способах и инструментах реагирования вы можете посмотреть в документе Руководство по реагированию на инциденты информационной безопасности. На сайте Securelist "Лаборатории Касперского" вы также можете ознакомиться с дополнительными рекомендациями по выявлению инцидентов и реагированию.
Условия возникновения инцидента
Параметры компьютера (далее также "актива"), на котором произошел инцидент:
- ОС актива – Windows 10.
- Программное обеспечение актива – Kaspersky Endpoint Agent, Kaspersky Endpoint Security.
Параметры KUMA:
- Настроена интеграция с Active Directory, Kaspersky Security Center, Kaspersky Endpoint Detection and Response.
- Установлены правила корреляции SOC_package из комплекта поставки программы.
Злоумышленник, заметив не заблокированный компьютер администратора, выполнил следующие действия на этом компьютере:
- Скачал вредоносный файл со своего сервера.
- Выполнил команду для создания ключа реестра в ветви
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. - Добавил скачанный на первом шаге файл в автозапуск с помощью реестра.
- Очистил журнал событий безопасности Windows.
- Завершил сессию.
Шаг 1. Предварительная подготовка
Предварительная подготовка включает следующие этапы:
- Мониторинг событий.
Когда в KUMA создан и настроен коллектор, программа записывает события информационной безопасности, зарегистрированные на контролируемых элементах IT-инфраструктуры организации, в базу событий. Вы можете найти и просмотреть эти события.
- Создание коррелятора и правил корреляции.
При обнаружении последовательности событий, удовлетворяющих условиям правила корреляции, программа создает алерты. Если для нескольких событий срабатывает одно и то же правило корреляции, все эти события привязываются к одному алерту. Вы можете использовать правила корреляции из комплекта поставки и создавать их вручную.
- Настройка отправки уведомлений об алерте на один или несколько адресов электронной почты.
Если отправка уведомлений настроена, при получении нового алерта KUMA отправляет на указанный адрес или адреса электронной почты уведомление. В уведомлении отображается ссылка на алерт.
- Добавление активов.
Вы можете выполнить на активе действия по реагированию (например, заблокировать запуск файла), только если актив добавлен в KUMA.
Для выполнения действий по реагированию необходима интеграция KUMA с Kaspersky Security Center и Kaspersky Endpoint Detection and Response.
Пример
В рамках предварительной подготовки аналитик выполнил следующие действия:
- Установил и привязал к коррелятору правила корреляции SOC_package из комплекта поставки.
- Настроил отправку уведомлений об алертах на свой адрес электронной почты.
- Импортировал в KUMA активы из Kaspersky Security Center.
Согласно условиям инцидента, после того, как администратор выполнил вход в свою учетную запись, был запущен вредоносный файл, который злоумышленник добавил в автозапуск Windows. От актива в KUMA поступили события из журнала событий безопасности Windows. Для этих событий сработали правила корреляции.
В результате в базу алертов KUMA были записаны следующие алерты:
- R223_Сбор информации о процессах.
- R050_Очистка журнала событий Windows.R295_Манипуляции с системой непривилегированным процессом.
- R097_Манипуляции с загрузочным скриптом.
- R093_Изменение критичных веток реестра.
В информации об алерте указаны названия правил корреляции, по которым были созданы алерты, и время первого и последнего событий, созданных при повторном срабатывании правил.
На адрес электронной почты аналитика пришли уведомления об алертах. Аналитик перешел по ссылке на алерт R093_Изменение критичных веток реестра из уведомления.
Шаг 2. Назначение алерта пользователю
Вы можете назначить алерт себе или другому пользователю.
Пример В рамках рассматриваемого инцидента аналитик назначает алерт себе. |
Шаг 3. Проверка на соответствие между сработавшим правилом корреляции и данными событий алерта
На этом этапе вам нужно просмотреть информацию об алерте и убедиться, что данные событий алерта соответствуют сработавшему правилу корреляции.
Пример В названии алерта указано, что была изменена критичная ветвь реестра. В информации об алерте, в разделе Связанные события отображается таблица событий, относящихся к алерту. Аналитик видит, что в таблице записано одно событие, где указан путь к измененному ключу реестра, исходное и новое значение ключа. Следовательно, правило корреляции соответствует событию. |
Шаг 4. Анализ информации об алерте
На этом этапе вам нужно проанализировать информацию об алерте, чтобы определить, какие данные требуется для дальнейшего анализа алерта.
Пример Из информации об алерте аналитик узнает следующие данные:
Эту информацию можно просмотреть в информации о событии, вызвавшем создание алерта (Алерты → алерт R093_Изменение критичных веток реестра → Связанные события → событие 2022-08-23 17:27:05), в полях FileName, DeviceHostName, SourceUserName соответственно. |
Шаг 5. Проверка на ложное срабатывание
На этом этапе вам нужно убедиться, что активность, по которой сработало правило корреляции, не является нормальной для IT-инфраструктуры организации.
Пример На этом этапе аналитик проверяет, может ли обнаруженная активность быть легитимной в связи с нормальной работой системы (например, обновлением). В информации о событии видно, что под учетной записью пользователя с помощью утилиты reg.exe был создан ключ реестра. Также ключ реестра был создан в ветви |
Шаг 6. Определение критичности алерта
При необходимости вы можете изменить уровень критичности алерта.
Пример Аналитик присваивает алерту высокую степень критичности. |
Шаг 7. Создание инцидента
Если в ходе выполнения шагов 3–6 становится понятно, что алерт требует расследования, вы можете создать инцидент.
Пример Для проведения расследования аналитик создает инцидент. |
Шаг 8. Расследование
Этот этап включает просмотр информации о связанных с инцидентом активах, учетных записях, алертах в информации об инциденте.
Информация о затронутых активах и учетных записях отображается на вкладке Связанные активы и Связанные пользователи в информации об инциденте.
Пример Аналитик открывает информацию о затронутом в рамках инцидента активе (Инциденты → необходимый инцидент → Связанные алерты → необходимый алерт → Связанные активы → необходимый актив). В информации об активе видно, что актив привязан к категориям Business impact/HIGH и Device type/Workstation, которые являются критичными для IT-инфраструктуры организации. Также в информации об активе могут быть полезны следующие данные:
Аналитик открывает информацию о связанной учетной записи пользователя (Инциденты → необходимый инцидент → Связанные алерты → ссылка с необходимым алертом → Связанные пользователи → учетная запись). В информации об учетной записи могут быть полезны следующие данные:
|
Шаг 9. Поиск связанных активов
Вы можете просмотреть алерты, которые происходили на связанных с инцидентом активах.
Пример Аналитик проверяет другие алерты, которые происходили на связанных с инцидентом активах (Инциденты → необходимый инцидент → Связанные алерты → необходимый алерт → Связанные активы → необходимый актив → Связанные алерты). В окне с алертами можно настроить фильтрацию по времени или статусу, чтобы исключить устаревшие или уже обработанные алерты. По времени, в которое были записаны алерты актива, аналитик определяет, что эти алерты связаны между собой, поэтому их можно привязать к инциденту (отметить флажками необходимые алерты → Привязать → необходимый инцидент → Привязать). Также аналитик находит связанные алерты для учетной записи и привязывает их к инциденту. Все связанные активы, которые были в новых алертах, также проверяются. |
Шаг 10. Поиск связанных событий
Вы можете расширить расследование, выполнив поиск событий из связанных алертов.
События можно найти в базе событий KUMA вручную или выбрать любой из связанных алертов и в информации о нем нажать на кнопку Найти в событиях (Инциденты → необходимый инцидент → Связанные алерты → необходимый алерт → Связанные активы → Найти в событиях). Найденные события можно привязать к выбранному алерту, предварительно отвязав алерт от инцидента.
Пример В результате поиска аналитику удалось найти событие A new process has been created, в котором была записана команда для создания нового ключа реестра. Исходя из данных события, аналитик обнаружил, что родительским процессом для
В результате поиска аналитик обнаружил, что файл был скачан из внешнего источника с помощью процесса Произведя поиск связанных событий для каждого алерта инцидента, аналитик выявил всю цепочку атаки. |
Шаг 11. Запись причин инцидента
Вы можете внести необходимую для расследования информацию в журнал изменений инцидента.
Пример По результатам, полученным в ходе поиска связанных с инцидентом событий, аналитик выявил причины инцидента и записал результаты анализа в поле Журнал изменений в информации об инциденте, чтобы передать информацию другим аналитикам. |
Шаг 12. Реагирование на инцидент
Вы можете выполнить следующие действия по реагированию:
- Выполнить сетевую изоляцию актива.
- Запустить антивирусную проверку.
- Запретить запуск файла на активах.
Перечисленные действия доступны при интеграции KUMA с Kaspersky Security Center и Kaspersky Endpoint Detection and Response.
Пример
У аналитика есть информация о связанных с инцидентом активах и об индикаторах компрометации, которая поможет в выборе действий по реагированию.
В рамках рассмотренного инцидента рекомендуется выполнить следующие действия:
- Запустить внеплановую антивирусную проверку актива, на котором был добавлен файл в автозапуск.
Задача антивирусной проверки запускается через Kaspersky Security Center.
- Изолировать актив от сети на время антивирусной проверки.
Изоляция актива выполняется с помощью Kaspersky Endpoint Detection and Response.
- Поместить файл ChromeUpdate.bat в карантин и создать правила запрета на запуск этого файла на других активах организации.
Правило запрета на запуск файла создается с помощью Kaspersky Endpoint Detection and Response.
- Запустить внеплановую антивирусную проверку актива, на котором был добавлен файл в автозапуск.
Шаг 13. Восстановление работоспособности активов
После того как IT-инфраструктура будет очищена от следов присутствия злоумышленника, вы можете отключить правила запрета и сетевой изоляции активов в Kaspersky Endpoint Detection and Response.
Пример После выполнения действий по расследованию, реагированию и очистке IT-инфраструктуры организации от следов атаки можно приступить к восстановлению работоспособности активов. Для этого можно отключить правила запрета на запуск файла и правила сетевой изоляции активов в Kaspersky Endpoint Detection and Response, если они не были отключены автоматически. |
Шаг 14. Закрытие инцидента
После того как были приняты меры по очистке IT-инфраструктуры организации от следов присутствия злоумышленника, вы можете закрыть инцидент.
В начало