Описание процесса работы c инцидентами в KUMA
Ниже приведено описание основного функционала KUMA задействованного в управлении инцидентами.
Алерты
Создание алерта
Алерт создается в результате сработки корреляционного правила на основе поступивших событий, он является подозрением на инцидент. Чтобы создать алерт, необходимо настроить корреляционное правило и в секции Actions не включать опцию Do not create alert, в таком случае при срабатывании этого правила, создастся новый алерт.
Оповещение об алерте
При появлении алерта есть возможность настроить оповещение на почту. Для этого необходимо перейти в Settings -> Alerts -> Notification rules. При создании нового правила оповещения можно указать свой шаблон для письма. С помощью правил оповещения есть возможность настроить разные сценарии в зависимости от того какое корреляционное правило сработало, и исходя из этого оповещение уйдет разным получателям.
Назначение ответственного на алерт
Обнаружив новый алерт, аналитик может взять его в обработку, назначив на себя, для этого в окне алерта необходимо на верхней панели в поле Assigned to выбрать Me, либо выбрать другого пользователя, чтобы назначить алерт на него.
Связанные активы
В рамках алерта в зависимости от событий могут быть связанные активы (хосты или аккаунты). Для автоматической актуализации активов можно настроить интеграцию, например, с Active Directory и Kaspersky Security Center. Если в событии встречается актив, то система автоматически связывает само событие с активом, а затем и алерт с активом. Список связанных активов находится в карточке алерта в полях Related endpoints и Related users.
История изменений и ведение журнала
Для отслеживания всех действий, в карточке алерта есть раздел Change log, куда записываются все изменения алерта. Также для удобного взаимодействия внутри команды аналитиков, есть возможность оставлять записи в Change log, чтобы фиксировать ход расследования или записывать важную информацию.
Связанные события
При срабатывании одного и того же правила новых алертов не создается, а наполняется существующий до тех пор, пока он не будет закрыт, либо если не создано правло сегментации для этого првила корреляции. В одном алерте может быть несколько вложенных событий, которые указаны в поле Related events. Для удобства расследования связанные события раскрываются в иерархическое дерево в зависимости от цепочки сработавших правил. Детали каждого события можно просмотреть прямо из карточки алерта, нажав на само событие.
Детализированный анализ
При необходимости детального анализа и изучения событий, которые произошли до и после инцидента, можно перейти ко всем событиям из алерта, нажав кнопку Find in events в разделе Related events. Перейдя во вкладку Events в результатах поиска, будут отображены все связанные события. Для отображения всех событий, которые были в данные промежуток времени, нужно сменить выбор с Related to alert, на All events. В результате отобразятся все события, среди которых можно выполнить поиск новых связанных событий и привязать их к алерту. Для этого выберете событие и в появившемся окне с детальной информацией нажмите Link to alert. Таким образом можно обогатить алерт новыми связанными событиями.
Закрытие алерта
В случае ложного срабатывания или, если нет необходимости создавать инцидент, есть возможность закрыть алерт. При закрытии алерта необходимо указать одну из трех причин: Отработан, Неверные данные, Неверное правило корреляции.
Создание инцидента
В случае необходимости повышения алерта до уровня инцидента, это можно сделать с помощью кнопки Create incident.
Привязка алерта к инциденту
В случае, если алерт является частью активности, расследуемой в рамках уже существующего инцидента, его можно привязать его с помощью кнопки Link.
Привязанный алерт становится недоступен для изменения – при необходимости изменения алерта (например добавления в него событий), нужно отвязать (unlink) алерт от инцидента, внести изменения, и привязать его обратно.
Инциденты
Создание инцидента
Инцидент можно создать на основе алерта или вручную с помощью кнопки Create incident во вкладке Incidents. При создании вручную необходимо заполнить обязательные поля, также при необходимости, есть возможность прикрепить к инциденту алерты или связанные активы.
Объединение инцидентов
Если в ходе расследования потребовалось объединить несколько инцидентов в один – это можно сделать с помощью функционала объединения. Для этого в окне инцидента нужно на верхней панели нажать на Merge и выбрать инцидент, с которым необходимо выполнить объединение.
Назначение ответственного на инцидент
При создании нового инцидента, аналитик может взять его в обработку, назначив на себя, для этого в окне инцидента необходимо на верхней панели в поле Assigned to выбрать «Me», либо выбрать другого пользователя, чтобы назначить инцидент на него.
Пример процесса реагирования на инциденты
Рассмотрим пример плана реагирования на инцидент, в рамках которого можно выделить стадии:
- Мониторинг – сбор и анализ событий, выявление аномалий и подозрительной активности с помощью правил корреляции или threat hunting.
- Триаж – первичный анализ алертов с целью выявления инцидентов, ложных срабатываний и ошибок в рамках процесса мониторинга.
- Расследование – сбор информации об активах и вредоносной активности с целью определения скоупа, причин инцидента и всей цепочки атаки.
- Реагирование – противодействие вредоносным действиям с целью предотвратить дальнейшее продвижение злоумышленника и сократить влияние на инфраструктуру
- Восстановление – приведение инфраструктуры в первоначальное состояние и проверка работоспособности
- Закрытие – заключение или отчет об инциденте и закрытие инцидента
Пример реагирования на инцидент с помощью KUMA
Рассмотрим пример реагирования на инцидент с помощью Kaspersky Unified Monitoring and Analysis Platform. Для примера будет взят стенд со следующими параметрами:
- Рабочая станция на Windows 10
- доменная авторизация
- KES
- KEA
- KEDR
- KSC
- KUMA
- Установлен пакет правил SOC_package (см. пресейл пак или ссылку с архивом установки KUMA)
- Настроена интеграция с AD
- Настроена интеграция с KSC
- Настроена интеграция с KEDR
В рамках стенда условный нарушитель, заметив незаблокированный компьютер администратора, воспользовался случаем и выполнил зловредные действия:
- Скачал вредоносный файл со своего сервера
- Выполнил команду для создания ключа реестра в ветке Microsoft\Windows\CurrentVersion\Run
- Добавил скаченный файл в автозапуск с помощью реестра
- Выполнил очистку событий в журнале Security
- Вышел из сессии, чтобы владелец учетной записи ничего не заподозрил
- Владелец учетной записи вошел в систему, послу чего запустился вредоносный файл
Процесс мониторинга
В процессе мониторинга с рабочей станции поступили события из журнала Security, после чего сработали правила корреляции из пакета SOC_package.
Каждый алерт имеет название правила корреляции, которое его породило. При повторном срабатывании правила в поле First seen будет время первого события, а в Last seen последнего.
Triage
При появлении нового алерта срабатывает правило оповещения и отправляется письмо на почту группе реагирования или конкретному аналитику.
Аналитики из L1 переходит по ссылке из письма и попадает сразу на карточку первого алерта:
Взятие в работу L1
Аналитик берет в работу алерт, назначая его на себя.
Анализ алерта
При анализе алерта аналитик обращает внимание на то какое правило сработало и соответствуют ли данные из событий с самим правилом. Как видно из названия правила алерт сработал на изменение какой-то критичной ветки реестра, в поле Related events в событии присутствуют путь до ключа реестра, есть старое и новое значение ключа реестра, отсюда можно сделать вывод, что правило соответствует произошедшему событию и аналитик обладает достаточной экспертизой, чтобы продолжить реагирование. Иначе же аналитик может перевести алерт на L2, назначив его на другого аналитика.
Проверка достаточности данных
На данном этапе аналитик должен определить каких данных ему будет достаточно для дальнейшего расследования. Чтобы продолжить расследование в рамках алерта по несанкционированному изменению ветки реестра, необходимо точно знать какой ключ был изменен и на каком хосте это было сделано. Дополнительными полезными данными будет информация о том, кто это сделал и новое значение ключа реестра. Раскрыв дерево событий от верхнеуровневого правила до самого события, можно увидеть детали, нажав на интересующее событие.
Проверка на False Positive
В рамках проверки на ложное срабатывание аналитик должен проверить верно ли сработало правило, может ли быть такая активность легитимной в связи с нормальной работой системы (например, обновление). Проанализировав детали события, видно, что персональная учетная запись talankin выполнила создание ключа реестра с помощью утилиты reg.exe, а также ключ реестра был создан в ветке \Microsoft\Windows\CurrentVersion\Run, отвечающей за автозапуск программ при входе пользователя в систему. Эти данные дают понять, что алерт скорее всего является True Positive и можно продолжить анализ дальше.
Определение критичности
На стадии определения критичности нужно валидировать критичность, которая была проставлена автоматически либо скорректировать её. Исходя из данных алерта имеет смысл выставить высокую критичность для данного алерта:
Создание инцидента
Проведя действия в рамках триажа, аналитик может эскалировать алерт до инцидента, чтобы начать расследование. Для этого в карточке инцидента необходимо нажать Create incident, в появившемся окне заполнить необходимые поля и нажать Save:
Расследование
Сбор информации о затронутых активах
Информация о затронутых активах автоматически выделяется в поля инцидента Related endpoints и Related users в том случае, если данные об этих активах загружены в KUMA с помощью интеграции с KSC, AD или внесены вручную. В изображении ниже видно, что в рамках инцидента были затронуты хост windows-kedr и учетная запись пользователя igor talankin.
Сразу можно отметить, что хост находится в категориях Business impact/HIGH и Device type/Workstation, то есть мы имеем дело с рабочей станцией, которая является критичной для нашей инфраструктуры (по легенде рабочая станция принадлежит администратору).
Если нажать на хост, то появятся детали актива. Детали содержат довольно подробную информацию, куда входит:
- FQDN, IP адрес, MAC адрес, время создания и обновления информации
- Количество алертов с разделением по критичности, с которыми этот актив связан. Также есть возможность сразу перейти к этим алертам, для поиска дополнительной информации в рамках инцидента.
- Категории, к которым относится актив
- Уязвимости на хосте
- Информация об установленном ПО
- Информация о hardware
- Другая дополнительная информация
Если нажать на связанную учетную запись, то можно изучить данные о ней по информации из Active Directory:
- Имя пользователя
- Имя учетной записи
- Группы, в которых состоит учетная запись
- Дата истечения пароля, дата создания и время последнего неверного ввода пароля
- Другая информация из AD
Как видно из списка групп, учетная запись состоит в группе доменных администраторов, что подтверждает высокую критичность инцидента.
Определение скоупа
Для определения скоупа инцидента необходимо произвести расследование и выявить по возможности другие события и алерты, которые относятся к этой злонамеренной активности.
Привязка события к инциденту возможна только через алерт (при этом алерт перед изменениями в т.ч. добавления новых событий в него, необходимо отвязать от инцидента).
Поиск связанных алертов
Первым делом имеет смысл проверить другие алерты, которые происходили с затронутыми активами.
Для этого достаточно выбрать актив и в разделе со связанными алертами нажать Find in alerts.
В окне с алертами можно сделать фильтрацию по времени или статусу, чтобы исключит уже обработанные алерта или устаревшие:
Как видно, с данным активом связаны и другие алерты. Судя по времени, в которое сработали алерты, мы можем сделать вывод, что все они так или иначе связаны друг с другом. Чтобы связать алерты с инцидентом, отмечаем интересующие алерты и нажимаем в нижней части панели Link, в появившемся окне отмечаем инцидент, с которым мы хотим связать алерты и снова нажимаем Link:
Перейдя обратно в карточку инцидента, мы можем убедиться, что все отмеченные алерты привязаны:
Ту же самую операцию мы можем провести с учетной записью и найти связанные алерты. В случае, если в новом алерте будут новые связанные активы, то мы можем продолжать поиск связанных алертов и по ним, тем самым расширяя скоуп расследования.
В случае, если мы обнаружили, что уже есть инцидент в работе, с которым мы можем объединить текущий инцидент, чтобы вести процесс реагирования в рамках одного инцидента, мы можем склеить их с помощью функции Merge. Для этого в карточке инцидента нужно нажать в верхней части на Merge, а затем выбрать инцидент, с которым мы хотим выполнить склеивание.
Threat hunting
После поиска связанных активов и алертов, можно приступить к более детальному расследованию и углубиться в поиск связанных c инцидентом IOC по всей инфраструктуре.
Для поиска связанных событий можно воспользоваться вкладкой Events и произвести поиск вручную или выбрать любой из связанных алертов и в его карточке нажать Find in events. Данный функционал называется Drilldown analysis:
В появившемся окне с событиями мы можем искать события и сразу же связывать их с выбранным алертом (для привязки алерта он должен быть отвязан от инцидента). Для этого необходимо в верхней части выбрать Search events -> All events:
В результате поиска, нам удалось найти команду, которую выполнил злоумышленник, чтобы создать новый ключ реестра. Исходя из данных события, мы можем найти какой процесс был родительским для reg.exe, им окажется cmd.exe, то есть злоумышленник запустил командную строку и выполнил команду в ней.
Из этого события появляется информация о некотором файле ChromeUpdate.bat. Чтобы узнать происхождение этого файла, мы можем продолжить процесс поиска, выполнив поиск по FileName = ‘C:\\Users\\talankin\\Downloads\\ChromeUpdate.bat’ и по маске доступа %%4417 (тип доступа WriteData (or AddFile)). В результате поиска мы найдем, что файл был создан процессом msedge.exe, чтобы говорит о том, что файл был скачен из внешнего источника, для дальнейшего анализа уже потребуются события с proxy сервера или NGFW. Это событие мы также привязываем к нашему алерту.
В ходе расследования мы можем выявить новые индикаторы компрометации такие как имя файла, URL, IP адрес и т.д., по этим данным также стоит выполнить поиск ретроспективный анализ, в результате которого можно выявить новые затронутые активы и обнаружить новые следы присутствия злоумышленника. В данном инциденте имеет смысл выполнить поиск файла ChromeUpdate.bat в событиях за последние пару недель.
Произведя Threat hunting для каждого алерта, мы должны выявить всю цепочку атаки.
Определение причин инцидента
По результатам поиска связанных событий мы выявили причины инцидента и можем записать результаты нашего анализа в журнал в карточке инцидента, чтобы передать информацию другим аналитикам или для полноты описания всего процесса реагирования. В разделе Change log мы можем указать важную информацию:
Реагирование
После расследования, у нас есть информация о затронутых активах, а также об индикаторах компрометации, которая поможет в сдерживании. Исходя из типа инцидента требуется определить список действий, которые нужно выполнить, чтобы остановить ход атаки. В данном случае имеет смысл:
- Запустить внеплановое антивирусное сканирование затронутых систем
- Изолировать хост от сети до момента, пока мы не убедимся в безопасности данного хоста
- Добавить файл ChromeUpdate.bat в карантин и создать правила предотвращающее его запуск на других хостах в инфраструктуре
Антивирусной сканирование
Для запуска сканирования в рамках этого инцидента необходимо перейти в карточку инцидента, выбрать затронутый хост и в верхней части информации об активе выбрать KSC Response и отметить заранее пред настроенную задачу по сканированию, а затем нажать Start.
Сетевая изоляция хоста
Для изоляции хоста, необходимо повторить действия для выбранного хоста, но выбрать KEDR Response, затем в Task type выбрать Enable network isolation и заполнить дополнительный параметры при необходимости, например, уточнить время изоляции или исключения в случае необходимости иметь доступ к хосту во время изоляции.
Предотвращение запуска вредоносного файла
Для добавления файла в карантин и создания превентивного правила с запретом запуска данного файла (в случае, если файл исполняемый) нужно повторить действия и выбрать KEDR Response -> Task type: Add preventive rule, в поле File hash указать хэш файла. В поле Asset имеет смысл указать All assets, так как нам необходимо застраховаться от дальнейшего распространения вредоносного файла.
Восстановление
После выполнения всех действий по расследованию и сдерживанию инцидента, а также после очистки инфраструктуры от следов злоумышленника, можно приступить к восстановлению нормальной работоспособности всех систем. Для это может понадобиться отключить какие превентивные правила на EDR или убрать сетевую изоляцию, если она не отключится автоматически. Чтобы выполнить эти действия, необходимо повторить действия подобные тем, что были произведены на предыдущем этапе, только выбрать задачи Disable network isolation и Delete prevention rule.
Закрытие инцидента
В конце процесса реагирования мы можем закрыть инцидент, выбрав один из вариантов заключения: approved или not approved. Чтобы закрыть инцидент, необходимо в верхней части карточки инцидента выбрать Close incident, в появившемся окне отметить нужный вариант и выбрать Close:
Закрытый инцидент нельзя «пере»-открыть.
No Comments