SIEM не умер: почему склад логов больше не защищает и что делать

В августе на профильном ресурсе d-russia.ru вышла моя экспертная колонка «SIEM умирает? Нет, но склад логов больше не защищает». Она вызвала живой отклик в профессиональном сообществе, и это неудивительно. Тема эволюции SIEM-систем, интеграции средств защиты и перехода от «склада логов» к активной защите сегодня как никогда актуальна.

В этом материале я поделюсь тем, как мы в Смарт-Софт анализируем поднятые вопросы, какие выводы делаем для развития наших продуктов и что это означает для заказчиков и партнеров.

  

Проблема: SIEM как «склад логов» не работает

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

Современная целевая атака — не событие, а сериал с паузами между сериями:

• фишинг;
• закрепление в системе;
• кража учетных данных;
• перемещение по сети;
• финальное воздействие.

Каждый эпизод по отдельности выглядит почти безобидно. NGFW видит разрешенное TLS-соединение, EDR замечает запуск легитимной утилиты, IDS/IPS не находит известной сигнатуры в зашифрованном трафике. Формально все отработали штатно. Практически атака прошла через пространство между средствами защиты.

 

Почему интеграция — не просто «галочка в ТЗ»

Долгое время отрасль отвечала на эту проблему просто: отправим все события в SIEM, а там разберемся. Но «все события» быстро превращаются в миллиарды записей, растущую стоимость хранения и очереди алертов. Логи разных систем говорят на разных языках.

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

Для этого нужны:

• Общая модель данных — единое понимание того, что такое «пользователь», «устройство», «процесс», «сетевое соединение».
• Единый словарь объектов, чтобы пользователь не был в одном источнике «user», в другом «account», а в третьем «SID».
• Двусторонние API для обмена не только событиями, но и контекстом угроз.
• Сценарии автоматизированного реагирования — от сигнала к блокировке.

 

Что это означает для выбора ИБ-решений

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

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

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

 

Как мы в Смарт-Софт подходим к этой задаче

Мы убеждены, что защита от сложных многоэтапных атак не может строиться как набор независимых продуктов. Именно поэтому мы проектируем наши решения (NGFW Traffic Inspector Next Generation (TING) и другие продукты) с акцентом на открытость и глубокую интеграцию.

Наш подход строится на нескольких принципах:

1. Открытые интерфейсы как стандарт

TING поддерживает интеграцию с Syslog, Wazuh, DLP, EDR/XDR, ФинЦЕРТ, LDAP/AD/RADIUS/SSO/TOTP, REST API, ICAP, зеркалирование трафика, NetFlow и внешние системы отчетности. Мы сознательно строим экосистему, в которой продукт легко вписывается в существующий ландшафт заказчика, а не пытается быть «все в одном» в ущерб интеграциям.

2. Единая модель данных

Мы работаем над тем, чтобы пользователь, устройство, процесс и сетевое соединение оставались частями одной истории, а не независимыми записями. Это позволяет SIEM-системе не просто хранить логи, а стать координатором защиты — нервной системой, связывающей все элементы безопасности.

3. Готовность к автоматизации реагирования

Переход от пассивного приемника событий к активному анализатору, обогащенному контекстом от других систем, — это не просто техническая задача, а архитектурный принцип. Мы понимаем, что будущее за автоматизированными сценариями, где время от обнаружения до блокировки будет измеряться секундами. Поэтому наши продукты, в первую очередь Traffic Inspector Next Generation, строятся с открытыми API и поддержкой стандартных протоколов интеграции. Это позволяет заказчикам и партнерам выстраивать собственные цепочки реагирования с использованием любых SOAR-решений или систем оркестрации, которые они сочтут подходящими. Мы обеспечиваем надежный фундамент для такого взаимодействия, а конкретные сценарии автоматизации развиваем совместно с пилотными заказчиками, опираясь на их реальные инфраструктуры и задачи.
 

Что дальше?

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

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

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

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

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

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

Протестируйте бесплатно