На VPN фиксируется серия неудачных входов. На файловом сервере — множество обращений к папкам, которыми пользователь раньше не интересовался. На сетевом шлюзе наблюдаем большой объем исходящего трафика.
Каждая система видит свой фрагмент. Аналитику нужно выяснить, относятся ли эти события к одной истории и требует ли она вмешательства.
Для этого используют SIEM — систему, которая собирает события безопасности из разных источников, приводит их к сопоставимому виду и помогает обнаруживать связи между ними.
Приведем пример периодически встречающегося кейса, который показывает, как SIEM помогает выстраивать такие связи.
Предположим, от разных департаментов или сотрудников вы получаете информацию о трех срабатываниях: запуск потенциально вредоносного ПО на хосте, аномальный сетевой трафик внутри инфраструктуры и попытка подключения к внешнему адресу на периметре.
В целом — три часто встречающихся срабатывания, ничего необычного.
Но во всех трех событиях мог участвовать один и тот же хост. И может оказаться, что прямо сейчас произошло закрепление с помощью вредоносного ПО и установка связи с внешним сервером управления — C2.
Да, в этом примере связь можно увидеть самостоятельно. Но цепочки бывают значительно длиннее и сложнее. SIEM с помощью правил корреляции ищет такие связи автоматически и снижает зависимость от человеческого фактора.
Какие данные нужны SIEM
В SIEM могут поступать события от рабочих станций и EDR, сетевых средств защиты, систем аутентификации, почтовых шлюзов, серверов, бизнес-приложений и облачных сервисов.
Список легко продолжить. Но сам по себе длинный перечень подключенных систем мало говорит о качестве обнаружения.
Полезнее начать со следующего вопроса: какие действия мы хотим видеть?
Например, использование чужой учетной записи, подозрительный запуск программ или доступ к критичным данным. Затем определить, какие события позволят увидеть и проверить эти действия.
Для расследования подозрительного входа могут понадобиться журналы VPN, сведения об аутентификации и данные с устройства. Если нужный журнал не собирается или в нем отсутствует важное поле, часть вопросов останется без ответа.
Необходимо определить критичный перечень источников, релевантный именно вашей инфраструктуре. Для этого нужно выделить важные бизнес-процессы, декомпозировать их до информационных систем, а системы, в свою очередь, до людей и оборудования.
Помимо этого, существуют Best Practices по перечню базовых источников, которые необходимы практически в любой инфраструктуре: DNS, Active Directory, ядро сети, прокси-серверы, различные СЗИ.
События от всех источников SIEM должна обработать и нормализовать.
Зачем нужна нормализация
Источники передают события в разных форматах и по-разному называют одни и те же сущности.
Нормализация позволяет привести записи к общей структуре: кто выполнил действие, когда, откуда, с каким объектом и с каким результатом.
Возьмем пользователя Иванова. В одном журнале он записан как ivanov, в другом — DOMAINivanov, в третьем — ivanov@company.ru.
Чтобы сопоставить его действия, нужно не только разобрать записи на поля, но и установить, относятся ли эти обозначения к одной учетной записи. Для этого могут потребоваться дополнительные сведения из каталога пользователей.
Есть и менее заметные проблемы. Например, два источника фиксируют время в разных часовых поясах или часы на сервере отстают. Тогда последовательность действий может выглядеть иначе, чем происходила на самом деле.
Поэтому качество данных — это часть работы по обнаружению. Если события приходят с задержкой, теряются или неверно разбираются, даже хорошее правило корреляции может не сработать.
Одна из частых проблем — синхронизация времени и часовых поясов.
Событие произошло в одном часовом поясе, SIEM работает в другом. В результате аналитику становится сложнее построить потенциальный kill chain для инцидента, а время расследования увеличивается.
По опыту разные SIEM-системы здесь ведут себя по-разному. Одни отображают события во времени, установленном на рабочей станции, где открыт интерфейс SIEM. Другие используют параметры сдвига timestamp или дополнительные поля таксономии, чтобы сохранить исходное время обнаружения события на источнике.
В следующей части — как из нормализованных событий SIEM собирает цепочку атаки и что аналитик делает после срабатывания.
Наши соцсети:
