Что дает SIEM, или как собрать из отдельных сигналов историю атаки

На VPN фиксируется серия неудачных входов. На файловом сервере — множество обращений к папкам, которыми пользователь раньше не интересовался. На сетевом шлюзе — большой объем исходящего трафика.

Каждая система видит свой фрагмент. Аналитику нужно понять, относятся ли эти события к одной истории и требует ли она вмешательства.

Для этого используют SIEM — систему, которая собирает события безопасности из разных источников, приводит их к сопоставимому виду и помогает обнаруживать связи между ними.

Приведем пример периодически встречающегося кейса.

Предположим, от разных департаментов или сотрудников поступает информация о трех срабатываниях: запуск потенциально вредоносного ПО на хосте, аномальный сетевой трафик внутри инфраструктуры и попытка подключения к внешнему адресу на периметре.

В целом — три частых срабатывания, ничего необычного.

Но во всех трех событиях мог участвовать один и тот же хост. И может оказаться, что произошло закрепление с помощью вредоносного ПО и установка связи с внешним сервером управления — C2.

Да, в этом примере связь можно увидеть самостоятельно. Но цепочки бывают значительно длиннее и сложнее. SIEM с помощью правил корреляции ищет такие связи автоматически и снижает зависимость от человеческого фактора.

Какие данные нужны SIEM
В SIEM могут поступать события от рабочих станций и EDR, сетевых средств защиты, систем аутентификации, почтовых шлюзов, серверов, бизнес-приложений и облачных сервисов.

Но сам по себе длинный перечень подключенных систем мало говорит о качестве обнаружения.

Полезнее начать с вопроса: какие действия мы хотим видеть?

Например, использование чужой учетной записи, подозрительный запуск программ или доступ к критичным данным. Затем определить, какие события позволят увидеть и проверить эти действия.

Для расследования подозрительного входа могут понадобиться журналы VPN, сведения об аутентификации и данные с устройства. Если нужный журнал не собирается или в нем нет важного поля, часть вопросов останется без ответа.

Необходимо определить критичный перечень источников, релевантный вашей инфраструктуре. Для этого нужно выделить важные бизнес-процессы, декомпозировать их до информационных систем, а системы — до людей и оборудования.

Помимо этого, есть базовые источники, которые нужны практически в любой инфраструктуре: DNS, Active Directory, ядро сети, прокси-серверы, различные СЗИ.

События от всех источников SIEM должна обработать и нормализовать.

Зачем нужна нормализация
Источники передают события в разных форматах и по-разному называют одни и те же сущности.

Нормализация позволяет привести записи к общей структуре: кто выполнил действие, когда, откуда, с каким объектом и с каким результатом.

Возьмем пользователя Иванова. В одном журнале он записан как ivanov, в другом — DOMAIN\ivanov, в третьем — ivanov@company.ru.

Чтобы сопоставить его действия, нужно установить, относятся ли эти обозначения к одной учетной записи.

Есть и менее заметные проблемы. Например, два источника фиксируют время в разных часовых поясах или часы на сервере отстают. Тогда последовательность действий может выглядеть иначе, чем происходила на самом деле.

Поэтому качество данных — часть работы по обнаружению. Если события приходят с задержкой, теряются или неверно разбираются, даже хорошее правило корреляции может не сработать.

Одна из частых проблем — синхронизация времени и часовых поясов.

Если событие произошло в одном часовом поясе, а SIEM работает в другом, аналитику становится сложнее построить потенциальный kill chain, а время расследования увеличивается.

Разные SIEM-системы решают это по-разному: одни отображают события во времени рабочей станции, другие используют сдвиг timestamp или дополнительные поля, чтобы сохранить исходное время события.

В следующей части — как из нормализованных событий SIEM собирает цепочку атаки и что аналитик делает после срабатывания.

#SIEM #SOC #ПрактикаИБ