Top.Mail.Ru
РБК Компании
Заморозили скидки: делитесь новостями бизнеса и читайте эксклюзивы на РБК
Успеть до 14.12
Заморозили скидки:
делитесь новостями бизнеса
и читайте эксклюзивы на РБК
Успеть до 14.12
Главная VK Tech 27 ноября 2025

Почему бизнесу не стоит отказываться от SIEM: ИБ без слепых зон

В статье разберемся, в чем преимущества SIEM по сравнению с альтернативами и как снизить расходы на информационную безопасность
Почему бизнесу не стоит отказываться от SIEM: ИБ без слепых зон
Источник изображения: Личный архив VK Tech
Дмитрий Куколев
Дмитрий Куколев
Руководитель SOC VK

Руководитель SOC VK

Подробнее про эксперта

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

На этом фоне бизнес начинает присматриваться к EDR и XDR — они кажутся более простыми, экономичными и воспринимаются как перспективное направление в ИБ. Однако по факту такие системы лишь дополняют SIEM, а не заменяют его, поскольку не способны охватить всю инфраструктуру компании. 

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

Чем EDR и XDR отличаются от SIEM и какие задачи решают

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

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

EDR (Endpoint Detection and Response) отслеживает действия на конкретном устройстве — например, на ноутбуке сотрудника или сервере. Если пользователь открыл фишинговое письмо и запустил вредоносный файл — система отследит процесс и заблокирует подозрительную активность.

XDR (Extended Detection and Response) объединяет сигналы из нескольких заранее заданных источников: конечных устройств, почтовых сервисов, облачных платформ. XDR коррелирует события и показывает более широкую картину атаки, чем EDR, но ее возможности ограничены экосистемой вендора.

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

Ключевое отличие SIEM (Security Information and Event Management) от EDR и XDR в том, что она адаптируется под любую модель инфраструктуры. SIEM собирает огромный объем событий безопасности в реальном времени, находит связи между ними, определяет источники угроз и собирает данные из всех систем.

Как большие объемы логов влияют на работу SIEM и что с этим делать

Чем масштабнее инфраструктура, тем больше данных нужно структурировать и сопоставлять. Системы SIEM проектируются с расчетом на обработку сотен тысяч и миллионов событий в секунду (EPS) во входящем потоке и способны хранить петабайты телеметрии в сжатом виде с возможностью быстрого поиска и анализа. Специалисты выявляют аномалии и формируют отчеты за десятки секунд, а длительное хранение логов помогает проводить глубокие расследования и отслеживать динамику сложных атак.

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

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

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

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

Главное — выстроить работу с логами так, чтобы система оставалась производительной, масштабируемой и экономически оправданной.

Почему бизнесу не стоит отказываться от SIEM: ИБ без слепых зон
EDR фиксирует события на конечных устройствах, XDR объединяет данные из доступных ему систем, а SIEM охватывает всю инфраструктуру

Технические решения, которые делают работу SIEM эффективнее

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

Архитектура хранения

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

Компании, которые разворачивают собственные дата-центры или платформы Big Data, используют распределенные файловые системы и кластеры хранения. Среди распространенных решений:

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

В банковском, телеком- и промышленном секторах, а также в ретейле применяют системы управления базами данных, которые хорошо справляются с лог-аналитикой:

  • Greenplum — MPP-платформа для параллельной обработки запросов;
     
  • ClickHouse — колоночная СУБД с высокой скоростью выборок по логам;
     
  • PostgreSQL — универсальное решение, которое часто служит основой для корпоративных аналитических хранилищ.

Горячее и холодное хранение данных

Горячие данные — это свежие логи, к которым обращаются чаще всего. Для их хранения используют быстрые твердотельные накопители — SATA/SAS SSD и NVMe SSD:

  • SATA/SAS SSD требуют больше инвестиций на старте: нужно закупить оборудование и интегрировать хранилище в инфраструктуру компании. Зато в долгосрочной перспективе такие решения обходятся дешевле благодаря стабильной работе и предсказуемым затратам.
     
  • NVMe SSD предусматривают более высокую производительность и позволяют динамически изменять конфигурацию и масштабировать ресурсы без простоев — как в собственной инфраструктуре, так и в облаке.

Холодные данные — это архивы, к которым возвращаются лишь при необходимости — например, при аудите старых логов и расследовании инцидентов. Для их хранения используют: 

  • HDD обычно выбирают, когда важно сохранить значительные массивы логов в собственной инфраструктуре и при этом снизить нагрузку на производительные системы.
     
  • Облачные хранилища удобны компаниям, которые хотят гибко управлять данными. Ресурсы можно быстро масштабировать под текущие задачи без инвестиций в оборудование.
     
  • Ленточные библиотеки востребованы в банках, телеком- и госсекторе. Они подходят для долговременного хранения информации при меньших затратах на обслуживание.

Нормализация логов и оптимизация поиска

Разные системы пишут логи в своем формате, и без предварительной обработки поиск событий занимает слишком много времени. Чтобы упростить анализ, данные приводят к единому виду — нормализуют:

  • Если у компании есть собственная инфраструктура, для нормализации логов применяют парсеры, ETL-конвейеры и системы лог-менеджмента — например, Logstash, Fluentd, Vector, NiFi, ELK Stack или Graylog. Эти инструменты извлекают ключевые поля, приводят данные к единому формату и готовят их к загрузке в аналитические хранилища.
     

Если инфраструктура размещена в облаке, можно использовать сервисы со встроенной нормализацией логов, такие как VK Cloud Logging или Advanced Log Tank Service. Они сами парсят и обрабатывают события, а также позволяют управлять хранением данных.  


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

  • В собственной инфраструктуре это решения на базе Lucene, а также СУБД ClickHouse или Greenplum — они обеспечивают высокую скорость выборок и масштабируемость при анализе логов.
     
  • Облачные сервисы поддерживают полный цикл работы с логами — от сбора до аналитики. Среди популярных платформ — Logtail и Yandex Cloud Logging.

Сквозной мониторинг на базе SIEM в масштабе компании

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

Снизить уровень шума помогают встроенные механизмы SIEM:

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

SIEM интегрируется с SOC (Security Operation Center) — центром мониторинга безопасности. В системе есть функциональный интерфейс с дашбордами и гибкими настройками для быстрого поиска данных и аналитики как в реальном времени, так и в ретроспективе. 

Многие компании дополняют SOC системой SOAR (Security Orchestration, Automation and Response). Она ускоряет обработку инцидентов, снижает нагрузку на сотрудников и автоматизирует типовые операции: блокировку IP-адресов, оповещение администраторов, изоляцию узлов.

Для руководства SIEM формирует отчеты с визуализацией метрик:

  • MTTD — время, за которое выявлен инцидент; 
  • MTTR — время реагирования на угрозу или восстановления системы после сбоя. 

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

SIEM — платформа, вокруг которой выстраивается культура безопасности

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

Если EDR и XDR фиксируют и блокируют угрозы на уровне конкретных устройств и сервисов, то SIEM может объединять и анализировать события из разных сегментов инфраструктуры — от сетевых экранов до систем контроля доступа. Такой уровень аналитики позволяет оперативно выявлять опасные инциденты, устранять их последствия и предотвращать повторные нарушения.



 


 

Источники изображений:

Личный архив VK Tech

Интересное:

Новости отрасли:

Все новости:

Контакты

Адрес
125167, Россия, г. Москва, Ленинградский проспект 39, стр. 79
Телефон

Социальные сети

ГлавноеЭкспертыДобавить
новость
КейсыМероприятия