Учет ИТ-активов и инцидентов с помощью Alertix

Учет инцидентов ИБ и обнаруженных признаков атак можно признать необходимым гигиеническим минимумом процессов ИБ. Этого требуют отраслевые стандарты и регуляторы от субъектов КИИ, включая кредитно-финансовые организации. Остальные участники рынка: компании, создающие собственный 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-системы, в рамках которых мы оптимизируем и обновляем инструменты для своевременного выявления и предотвращения инцидентов ИБ.

Спикер: Сергей Кривошеин, директор центра развития продуктов NGR Softlab.