SIEM умирает? Нет, но склад логов больше не защищает

Фото (с) АРПП «Отечественный софт»
Денис Корбаков. Фото (с) АРПП «Отечественный софт»

Об авторе: Денис Корбаков, технический директор компании «Смарт-Софт», участник АРПП «Отечественный софт»

Мне регулярно приходится слышать фразу «SIEM умер» (SIEM, от «Security information and event management» – управление событиями ИБ – ред.). Чаще всего от людей, которые только что закончили его внедрение. Я их понимаю: источники подключены, события поступают, отчёты строятся, а служба информационной безопасности всё равно живёт в режиме пожарной команды.

Мне доводилось разбирать инцидент, где мониторинг зафиксировал все этапы атаки, но среди тысяч ежедневных предупреждающих сообщений («алертов») аналитик просто не заметил цепочку. Атаку обнаружили спустя недели.

В этом и состоит кризис классической модели SIEM. Проблема не в самой технологии, а в ожидании, что склад событий однажды сам превратится в систему принятия решений.

Современная целевая атака — не событие, а сериал с паузами между сериями: фишинг, закрепление, кража учётных данных, перемещение по сети и лишь затем финальное воздействие. Каждый эпизод отдельно выглядит почти безобидно.

NGFW (Next-Generation Firewall) видит разрешённое TLS-соединение (Transport Layer Security). EDR (Endpoint Detection and Response) замечает запуск легитимной административной утилиты. IDS/IPS (Intrusion Detection System / Intrusion Prevention System) не находит известной сигнатуры в зашифрованном трафике. Система контроля учётных записей фиксирует успешный вход с правильным паролем. Формально все отработали штатно. Практически атака прошла через пространство между средствами защиты.

Поэтому защита от сложных многоэтапных атак не может строиться как набор независимых продуктов. Обнаружение APT-атак (Advanced Persistent Threat) требует понимания последовательности действий: кто, с какого устройства, каким процессом и к какому ресурсу обратился.

Долгое время отрасль отвечала на эту проблему просто: отправим все события в SIEM, а там разберёмся. Но «все события» быстро превращаются в миллиарды записей, растущую стоимость хранения и очереди алертов. Логи разных систем говорят на разных языках: в одном источнике пользователь — это «user», в другом — «account», в третьем — «SID» (Security Identifier, идентификатор Windows для участников обеспечения ИБ – ред.), который ещё надо снаблить правильными разрешениями. Корреляционные правила приходится постоянно переписывать, а при оптимизации первыми отключаются наиболее «шумные» источники. По неприятной иронии именно в них позднее находят следы атакующего.

Поэтому SIEM не умирает. Умирает архитектура, в которой он играет роль пассивного приёмника syslog, а аналитик должен вручную собирать инцидент из цифровых опилок.

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

NGFW с системой анализа сетевого трафика обнаруживает обращение к подозрительному ресурсу. EDR сообщает, какой процесс открыл соединение, кто его запустил и что происходило до этого. Аналитическое ядро сопоставляет сетевую активность, поведение устройства и учётной записи. Если риск подтверждён, контур защиты автоматически блокирует соединение, изолирует узел или ограничивает сессию.

Три слабых сигнала должны складываться в одно решение не за время, необходимое для чтения трёх консолей, а за секунды.

Для автоматического предотвращения кибератак мало соединить продукты и назвать результат экосистемой. Нужны общая модель данных, единый словарь объектов, двусторонние API (Application Programming Interface), синхронизация контекста угроз и сценарии автоматизированного реагирования. Пользователь, устройство, процесс и сетевое соединение должны оставаться частями одной истории, а не независимыми записями.

Отсюда следует неудобный вывод: таблица функций отдельного продукта всё меньше говорит о реальной защищённости. Два решения могут иметь одинаковые галочки напротив слов «корреляция», «машинное обучение» и «автоматическое реагирование», но радикально различаться по способности работать совместно.

Интеграция эффективна, будь то продукты одного вендора или нескольких, когда она проектируется как архитектурная задача, а не как галочка в техническом задании.

Импортозамещение нередко понимают как последовательную замену иностранных продуктов отечественными. В результате старый «зоопарк» сохраняется, меняются только таблички на клетках с «животными». Вместе с зоопарком остаются несовместимые форматы, разрывы в телеметрии и ручное реагирование.

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

Российские NGFW, SIEM, EDR, IDS/IPS и средства анализа сетевого трафика нужно оценивать не только по функциям, но и по качеству интеграции. Насколько быстро они обмениваются контекстом? Поддерживают ли открытые интерфейсы? Способны ли запускать согласованные действия? Сохраняется ли интеграция после обновлений?

Поэтому при выборе системы кибербезопасности стоит задавать поставщикам не только вопрос «что умеет ваш продукт?», но и менее комфортные вопросы.

Что произойдёт после обнаружения подозрительной активности? Какими данными она автоматически обогатится? Кто свяжет сетевое событие с процессом и пользователем? За сколько секунд система примет решение? И кто отвечает за работу интеграции после очередного обновления?

Ответы на эти вопросы важнее длины перечня функций.

Атакующие давно действуют как единая система: разведка передаёт сведения операторам, инструменты закрепления помогают горизонтальному перемещению [по атакуемой сети], украденные учётные данные используются на следующих этапах атаки.

Защита, построенная как набор изолированных инструментов, против такого противника обречена постоянно опаздывать. Именно здесь SIEM остаётся незаменимым. Он способен стать тем самым интеграционным звеном, которое собирает разрозненные события в единую картину. Он жив, потому что без него невозможно обеспечить централизованный сбор и долгосрочное хранение данных, необходимых для расследования инцидентов и выполнения регуляторных требований. Но чтобы он действительно работал, а не просто хранил логи, нужны три изменения.

  1. Переход от пассивного приёмника событий к активному анализатору, обогащённому контекстом от других систем.
  2. Внедрение единой модели данных и унифицированных форматов для всех источников.
  3. Автоматизация реагирования — от сигнала к блокировке.

С этими изменениями SIEM перестаёт быть архивом и становится координатором защиты — нервной системой, связывающей все элементы безопасности.

Источники и материалы по теме:

  1. MITRE ATT&CK. Enterprise tactics, этапы и тактики современных атак: https://attack.mitre.org/tactics/enterprise/
  2. MITRE ATT&CK. Lateral Movement, методы горизонтального перемещения внутри инфраструктуры: https://attack.mitre.org/tactics/TA0008/
  3. NIST SP 800-92. Guide to Computer Security Log Management, рекомендации по управлению журналами событий безопасности: https://csrc.nist.gov/pubs/sp/800/92/final
  4. NIST SP 800-61 Rev. 3. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: https://csrc.nist.gov/pubs/sp/800/61/r3/final
  5. CISA. Advanced Persistent Threat Activity Targeting Energy and Other Critical Infrastructure Sectors, пример многоэтапной APT-кампании: https://www.cisa.gov/news-events/alerts/2018/03/08/advanced-persistent-threat-activity-targeting-energy-and-other
Чтобы не пропустить самое интересное, читайте нас в Max и Телеграм

Поделиться: