Учет инцидентов ИБ и обнаруженных признаков атак можно признать необходимым гигиеническим минимумом процессов ИБ. Этого требуют отраслевые стандарты и регуляторы от субъектов КИИ, включая кредитно-финансовые организации. Остальные участники рынка: компании, создающие собственный SOC (Security operations center) или корпоративный центр ГосСОПКА, а также поставщики услуг мониторинга и реагирования сталкиваются с необходимостью учета инцидентов из соображений измерения и повышения эффективности собственных процессов. Это ложится в повсеместно применяемые ИТ-практики управления обращениями и инцидентами, например, ITIL (IT Infrastructure Library).
Учет ИТ-активов и ресурсов традиционно считается задачей ИТ, а не ИБ и входит в семейство процессов управления конфигурациями (Change Management) того же ITIL. Вместе с тем такие ИБ-практики, как управление уязвимостями, обнаружение и управление инцидентами ИБ требуют понимания контролируемого ИТ-ландшафта. «Недопустимые события» ─ активно обсуждаемое в ИБ-сообществе понятие, которое обычно касается конкретного ИТ-актива или ресурса. Сведения об ответственных, степени критичности ресурсов и другая информация помогает тонко настроить системы выявления и ускорить работу по расследованию и ликвидации последствий инцидентов.
Практики, о которых пойдет речь в статье, с одной стороны, классические ИТ-процессы, но изрядно «приправлены» спецификой ИБ. Для их автоматизации рынку доступно множество специализированных решений: CMDB, ITAM, Service Desk, IRP, SOAR, ─ требующих интеграции между собой и с другими системами, обеспечивающими более высокоуровневые процессы. Построение архитектуры и реализация процессов мониторинга и расследования на базе множества специализированных средств требует нескольких лет.
При проектировании, развивая SIEM-систему Alertix, мы стараемся обеспечить компании набором инструментов, позволяющим выстроить процесс без использования дополнительных средств. В данной статье рассмотрим, какие возможности и инструменты предоставляет Alertix для учета ИТ-активов и инцидентов ИБ.
Инвентаризационная информация в Alertix помогает аналитикам:
· Понимать необходимый контекст при расследовании подозрений на инциденты и свободном поиске признаков инцидентов.
· Приоритизировать подозрения и инциденты в зависимости от критичности ИТ-актива или ресурса.
· Маркировать события для фильтрации и использования в корреляции, формируя произвольные множества: события от определенных отделов или комплексных автоматизированных систем.
· Автоматически заполнять необходимую информацию в формах уведомления НКЦКИ (ЛК ГосСОПКА)
· Оценивать покрытие инфраструктуры сборщиками событий, находить неподключенные источники.
Схема хранения инвентаризационной информации иерархическая с поддержкой связей. Количество полей сущности различно и варьируется от 3 до 10 полей. Пример используемых сущностей и связей приведен на схеме:
Сущность «Теги» используется для группировки событий от разнородных активов и ресурсов, а также для приоритезации. Тег — произвольная строка и приоритет от 1 до 5. Любому ресурсу, а также некоторым объединяющим сущностям может быть назначено несколько тегов. Допустим в инфраструктуре используется серверный сегмент сети с ограниченным доступом 192.168.2.0/24, входящий в более крупный сегмент виртуализации, и бизнес-критичный сервер в этой сети NGR-Exchange01.ngrsoftlab.ru. Сеть в организации доменная, на сервере обладает полномочиями сервисная учетная запись HealthMailboxe032a69.
Все указанные сущности добавляем в инвентаризационную информацию и присваиваем им теги:
· «Серверы» с приоритетом 3 для IP-сети
· «Виртуализация» с приоритетом 2 для IP-сети
· «Почтовый сервер» с приоритетом 5 для сервера
· «Сервисные учетки» с приоритетом 4 для учетных записей
С момента присвоения все поступающие события будут промаркированы тегами, например, событие аутентификации пользователя HealthMailboxe032a69 на сервере NGR-Exchange01.ngrsoftlab.ru будет промаркировано всеми четырьмя тегами, т.к. в событии содержится информация об имени пользователя, хосте и его IP-адресе. Просмотреть результат присвоения тегов можно в обзоре:
Присвоенные теги можно использовать как условие в правилах корреляции, при работе с обзором и построении дашбордов. При этом максимальный из приоритетов, соответствующих присвоенным тегам, будет использован коррелятором для расчета риска подозрения на инцидент. Подробнее об этом расскажу далее.
Пополнение инвентаризационной информации возможно не только вручную. Доступен классический импорт из текстовых файлов, а также функционал автоинвентаризации. Загружаемая информация из различных источников проходит процедуру дедубликации. Автоматически пополнять данные инвентаризации можно:
· На основе поступающих событий, выделяя в них уникальные IP-адреса и имена хостов.
· Синхронизацией с LDAP-совместимой службой каталогов.
· Из данных сканеров уязвимостей (в настоящий момент поддерживается xspider, список поддерживаемых решений будет расти).
При синхронизации сведений с LDAP-каталогом поддерживается загрузка из нескольких доменов. В результате синхронизации, кроме создания объектов, осуществляется автоматическое создание связей. Например, при загрузке сведений о пользователе будут созданы объекты «Учетная запись», «Контакт», «Локация» и «Отдел», сведения о которых присутствуют в соответствующих атрибутах учетной записи. Эти объекты будут связаны между собой для дальнейшего использования.
При этом информация, загружаемая из LDAP, используется не только для пополнения данных инвентаризации, но и при контекстном обогащении по клику в обзоре:
Для учета сведений об объектах КИИ в карточке объекта «Локация» предусмотрен дополнительный набор полей, соответствующий полям в ЛК ГосСОПКА:
Сведения об уязвимостях (при условии подключения к сканеру) доступны как из списка ресурсов, так и на отдельной странице, с которой можно просмотреть детальную информацию об уязвимости и список ресурсов на которых она была обнаружена:
Итак, инвентаризационная информация, как уже было продемонстрировано, может использоваться при поиске информации в обзоре, но не менее полезно ее использование при учете инцидентов.
Главная страница модуля учета содержит статистические срезы за неделю и список инцидентов. На самом деле в момент создания совершенно не факт, что событие является инцидентом, корректнее использовать разные термины, в зависимости от статуса: подозрения, подтвержденные инциденты, атаки или ложные подозрения. Но для удобства далее я буду называть все «инцидентами».
Модуль обеспечивает необходимый функционал для учета, контроля соблюдения сроков обработки, распределения задач и приоритезации работы.
Инциденты могут быть созданы как коррелятором автоматически, так и вручную или из любого события при свободном поиске: из обзора, при проведении ретроспективного поиска по правилам корреляции или индикаторов компрометации.
Жизненный цикл инцидента представлен статусами «создан», «назначен», «квалифицирован» и др. Модуль фиксирует изменения статуса и позволяет осуществлять контроль соблюдения сроков обработки (расследования, решения и т.д.). На ключевых стадиях (квалификация, решение и закрытие) есть возможность направить уведомления.
На вкладке базовой информации модуль позволяет фиксировать факты, свидетельствующие об инциденте или атаке в виде ссылок на конкретные события. Область «Базовые сведения» используется для классификации, приоритизации инцидента.
Область предпринятых действий автоматически заполняется изменениями статуса и может использоваться для постановки и учета задач аналитику, назначенному ответственным за инцидент:
Расчет приоритетов инцидентов (в терминологии Alertix — «риска») производится перемножением коэффициентов «Достоверность», «Приоритет» и «Критичность ИТ-актива». Инциденты, выявляемые коррелятором, получают эту оценку автоматически, т.к. значения коэффициентов задаются для каждого правила, а в качестве критичности ИТ-актива используется наибольшее из значений, присвоенных тегами, о которых упоминалось выше. Таким образом инциденты в результате сработки одного и того же правила, например, на тестовой машине и бизнес-критичном сервере, получат разный расчет риска.
Модуль поддерживает выстраивание иерархических зависимостей между инцидентами уровня «Оригинатор» и «Последствия». Если какие-то инциденты признаны последствиями более высокоуровневого инцидента, они более не будут рассматриваться в перечне как самостоятельные (останутся доступны через просмотр последствий):
В области атаки или инцидента фиксируются все ИТ-активы и ресурсы, задействованные в нем. Если инцидент создан автоматически коррелятором и в инвентаризационной информации есть сведения о ресурсах, фигурирующих в событиях, информация о них отобразится в области. Сведения могут быть добавлены и вручную.
Если в организации есть подключение к НКЦКИ, модуль предоставляет возможности отправки сведений с использованием API ЛК ГосСОПКА. При этом большая часть полей уведомления заполняется автоматически, в том числе информация об объекте КИИ, если область атаки содержит записи, связанные с локацией, которая была отмечена как объект КИИ.
Отдельно хочу обратить внимание на инструмент «Блокнот аналитика», который может быть использован в ходе расследования инцидента или свободного поиска. Блокнот содержит «листы» ─– чаще всего временные наборы данных, которые необходимо записать в ходе изучения взаимосвязанных событий. Инструмент позволяет сохранять и быстро воспроизводить результаты поисковых запросов в обзоре, сохранять любую текстовую информацию с поддержкой гиперссылок, файлы и отдельные индикаторы, которые можно проверить в публичных сервисах: virustotal, abuseIPDB, whois. Мы будем расширять список поддерживаемых сервисов в т.ч. публичными отечественными. Каждый «лист» может быть прикреплен к инциденту, выполняя роль черновых записей расследования.
В статье мы рассмотрели, каким образом модули Alertix, отвечающие за управление инвентаризационной информацией и инцидентами, интегрированы между собой и встроены в сквозной конвейер мониторинга. Регулярно выходят новые версии SIEM-системы, в рамках которых мы оптимизируем и обновляем инструменты для своевременного выявления и предотвращения инцидентов ИБ.
Статья на CISO Club по ссылке.
Статья на CISO Club по ссылке.