Информационная безопасность

SIEM-система: что это, как работает и как её внедрить

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

Редакция Блэнси · 11 мин чтения
SIEM-система: что это, как работает и как её внедрить
Содержание

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

Что такое SIEM и какие задачи она решает

SIEM (Security Information and Event Management) - класс систем для сбора, хранения и анализа событий безопасности. Если коротко, SIEM это центральная точка, куда стекаются журналы серверов, рабочих станций, сетевого оборудования, средств защиты и бизнес-приложений. Там события приводятся к единому виду, связываются правилами и превращаются в оповещения об инцидентах.

Название отражает два исторических направления. SIM (Security Information Management) отвечало за долговременное хранение журналов и отчётность. SEM (Security Event Management) - за анализ событий в реальном времени. Современная SIEM-система объединяет обе функции.

Выявление инцидентов

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

Расследование

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

Соответствие требованиям

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

Как работает SIEM-система: от события до инцидента

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

Сбор событий

SIEM получает данные несколькими способами: принимает сообщения по протоколу syslog, забирает журналы через агенты на серверах и рабочих станциях, опрашивает системы по API или читает базы данных приложений. Типичные источники - контроллеры домена, серверы, межсетевые экраны, VPN-шлюзы, антивирусы и EDR, почтовые системы, СУБД, прокси, облачные сервисы. От набора источников напрямую зависит, какие атаки система вообще способна увидеть.

Нормализация и обогащение

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

Корреляция и правила

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

Инциденты и оповещения

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

Хранение

События хранятся в двух режимах: «горячем» для быстрого поиска за последние недели и «холодном» для архива на месяцы и годы. Срок хранения задают требования регуляторов, внутренние политики и практика расследований: атаки нередко обнаруживают спустя долгое время после первого проникновения. Объём хранилища рассчитывают от потока событий в секунду (EPS) и выбранной глубины архива.

SIEM и смежные классы решений: сравнение

SIEM часто путают с соседними классами средств защиты или ждут от неё того, для чего она не предназначена. Ниже - сравнение по назначению.

Класс Что делает Чем отличается от SIEM
Лог-менеджмент Собирает, хранит и индексирует журналы, даёт поиск по ним Нет или почти нет корреляции и управления инцидентами. Часто служит основой, поверх которой строится SIEM
EDR Глубоко наблюдает за процессами на конечных точках, выявляет и блокирует угрозы на узле Видит детали на одном узле, но не события сети, приложений и облака. Для SIEM это один из ценных источников
SOAR Автоматизирует реагирование по сценариям (плейбукам): блокировка, изоляция узла, сбор данных, заявки Сама не выявляет инциденты, а принимает их, в том числе от SIEM, и ускоряет обработку
NGFW Фильтрует трафик на периметре и внутри сети, контролирует приложения, предотвращает вторжения Средство предотвращения на сетевом уровне. Его журналы - важный источник для SIEM
SOC как сервис Команда аналитиков и процессы мониторинга и реагирования, предоставляемые внешним провайдером Это не продукт, а услуга с людьми. Провайдер может использовать свою SIEM или работать на SIEM заказчика

Связка «SIEM и SOC» - самая частая точка путаницы. SIEM - инструмент, SOC (Security Operations Center) - подразделение или сервис, который этим инструментом пользуется: разбирает инциденты, реагирует, развивает правила. SIEM без людей превращается в архив журналов с непрочитанными оповещениями. SOC без SIEM вынужден работать вручную или на инструментах своего провайдера.

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

Кому нужна SIEM-система и когда внедрять её рано

SIEM даёт результат, когда в компании уже есть базовые меры защиты и люди, способные реагировать. Решение о внедрении стоит принимать по зрелости процессов ИБ, а не по размеру бюджета.

Когда SIEM подходит

  • Инфраструктура распределена: несколько площадок, филиалы, облака, десятки и сотни серверов, и вручную просматривать журналы уже невозможно.
  • Работают базовые средства защиты: антивирус или EDR, межсетевые экраны, централизованное управление учётными записями, резервное копирование.
  • Есть сотрудники или подрядчик, которые будут разбирать инциденты, в том числе в нерабочее время, если это нужно по рискам.
  • Организация относится к субъектам КИИ, оператор ГИС или обрабатывает персональные данные, и требования по регистрации событий и реагированию нужно выполнять системно.
  • Уже были инциденты, которые обнаружили поздно или не смогли полностью расследовать из-за нехватки данных.

Когда внедрять рано

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

SIEM и требования регуляторов: КИИ, ГосСОПКА, приказы ФСТЭК

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

187-ФЗ о безопасности КИИ и ГосСОПКА

Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» обязывает субъектов КИИ незамедлительно информировать о компьютерных атаках и компьютерных инцидентах федеральный орган исполнительной власти, уполномоченный в области функционирования ГосСОПКА (статья 9), а также оказывать содействие его должностным лицам. Для субъектов КИИ в банковской сфере предусмотрено также информирование Банка России. Сообщить об инциденте невозможно, если его не выявили, поэтому для субъектов КИИ мониторинг событий информационной безопасности становится практической необходимостью, а SIEM - одним из его основных инструментов.

Приказ ФСТЭК России № 239

Требования по обеспечению безопасности значимых объектов КИИ, утверждённые приказом ФСТЭК России от 25.12.2017 № 239, содержат группу мер «Аудит безопасности» (АУД) и группу «Реагирование на компьютерные инциденты» (ИНЦ). К первой относятся, в частности, регистрация событий безопасности (АУД.4), защита информации о событиях безопасности (АУД.6) и мониторинг безопасности (АУД.7). Ко второй - выявление, анализ компьютерных инцидентов и хранение информации о них (ИНЦ.1, ИНЦ.3, ИНЦ.6). SIEM помогает реализовать значительную часть этих мер, но не все: организационные меры, регламенты и назначение ответственных остаются на стороне организации.

Персональные данные и государственные информационные системы

Приказ ФСТЭК России от 18.02.2013 № 21 для информационных систем персональных данных включает группу мер «Регистрация событий безопасности» (РСБ): определение событий для регистрации и сроков хранения, сбор и хранение, мониторинг и реагирование, защиту информации о событиях. Для государственных информационных систем с 1 марта 2026 года действуют требования, утверждённые приказом ФСТЭК России от 11.04.2025 № 117, которые заменили приказ № 17. В обоих случаях SIEM используют как техническую основу для мер по регистрации и анализу событий.

Если по требованиям нужны сертифицированные средства защиты, наличие действующего сертификата у конкретной версии продукта проверяют по государственному реестру сертифицированных средств защиты информации ФСТЭК России и документам вендора.

SIEM-системы российские: примеры решений

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

  • MaxPatrol SIEM (Positive Technologies) - собирает и анализирует события, ведёт инвентаризацию активов, получает от вендора пакеты экспертизы с правилами выявления.
  • Kaspersky Unified Monitoring and Analysis Platform (KUMA) («Лаборатория Касперского») - SIEM с набором готовых правил, интеграциями с продуктами вендора и сторонними системами, центральный элемент XDR-решения компании.
  • RuSIEM - российская SIEM для сбора, нормализации и корреляции событий в реальном времени.
  • KOMRAD Enterprise SIEM («Эшелон») - система централизованного управления событиями и инцидентами безопасности.

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

Внедрение SIEM: этапы и чек-лист

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

  1. Обследование. Инвентаризируем активы, изучаем архитектуру сети, действующие средства защиты, требования регуляторов и внутренние политики. Определяем, от каких угроз система должна защищать в первую очередь.
  2. Сценарии и выбор источников. Составляем перечень сценариев выявления и под каждый определяем нужные источники и события. Проверяем, включён ли аудит на узлах, синхронизировано ли время, хватает ли детализации журналов.
  3. Расчёт нагрузки и выбор платформы. Оцениваем поток событий, глубину хранения, требования к отказоустойчивости и сертификации. Сравниваем 2-3 продукта по этим критериям.
  4. Пилот. Подключаем ограниченный набор источников и проверяем на реальных данных: корректно ли разбираются журналы, работают ли правила, выдерживает ли система нагрузку.
  5. Подключение источников и нормализация. Расширяем охват, дописываем разборщики для нестандартных журналов, настраиваем обогащение данными об активах и пользователях.
  6. Настройка правил корреляции. Включаем правила по приоритетным сценариям, адаптируем готовые наборы вендора, пишем собственные правила для бизнес-приложений.
  7. Снижение ложных срабатываний. Разбираем каждое частое срабатывание: настоящая угроза, легитимная активность или ошибка правила. Добавляем исключения и уточняем пороги до рабочего объёма оповещений.
  8. Регламенты реагирования. Описываем, кто и в какие сроки разбирает инциденты каждого типа, как эскалировать, когда информировать руководство и, если требуется, НКЦКИ. Готовим дашборды и отчёты.
  9. Обучение и передача в эксплуатацию. Обучаем аналитиков и администраторов, передаём документацию по архитектуре, источникам и правилам.
  10. Сопровождение. Подключаем новые системы, обновляем правила под новые техники атак, контролируем, что источники не перестали присылать события.

Типичные ошибки внедрения SIEM

  • Подключить всё сразу. Полный охват в первый месяц даёт огромный поток событий, дорогое хранилище и тысячи оповещений, которые никто не разбирает. Разумнее начинать с источников под приоритетные сценарии.
  • Оставить правила «из коробки». Готовые наборы не знают особенностей вашей сети: служебных учётных записей, регламентных заданий, нестандартных приложений. Без адаптации они дают много ложных срабатываний.
  • Не назначить ответственных. Оповещения приходят, но нет регламента, кто их разбирает и что делать дальше. Через несколько недель на них перестают смотреть.
  • Не контролировать источники. Источник перестал отправлять журналы после обновления или смены настроек, а этого никто не заметил. Нужны отдельные правила на пропадание событий.
  • Не учесть хранение. Объём хранилища рассчитан по пилоту, а через год поток событий вырос в разы. Глубину архива приходится сокращать ниже требований.
  • Воспринимать SIEM как разовый проект. Инфраструктура и техники атак меняются, и правила, актуальные при запуске, постепенно теряют ценность без сопровождения.

Как оценить эффект от SIEM

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

  • Покрытие. Доля критичных активов и приоритетных сценариев атак, по которым есть источники и работающие правила.
  • Время обнаружения (MTTD). Сколько проходит от начала подозрительной активности до появления инцидента в SIEM.
  • Время реагирования (MTTR). Сколько проходит от появления инцидента до его локализации и закрытия.
  • Доля ложных срабатываний. Какая часть оповещений после разбора оказалась легитимной активностью. Снижение этой доли означает, что аналитики тратят время на реальные угрозы.
  • Полнота расследований. Удаётся ли восстановить хронологию инцидента по данным SIEM без ручного сбора журналов.
  • Готовность к проверкам. Можно ли подтвердить выполнение мер по регистрации событий и реагированию отчётами из системы.

Дополнительная проверка - учения. Смоделированная атака или тестирование на проникновение показывают, какие этапы SIEM увидела, какие пропустила и сколько времени заняла реакция команды.

Итоги

SIEM-система связывает разрозненные журналы в единую картину, помогает вовремя выявлять инциденты, расследовать их и подтверждать выполнение требований 187-ФЗ и приказов ФСТЭК. Результат зависит не столько от выбранного продукта, сколько от подготовки: инвентаризации активов, продуманных сценариев, настроенных правил, регламентов и людей, которые реагируют на оповещения. Если вы планируете проект, специалисты Блэнси помогут с внедрением SIEM: обследуют инфраструктуру, подберут платформу, подключат источники, настроят правила корреляции и регламенты, а затем возьмут систему на сопровождение.

FAQ

Вопросы и ответы

Что такое SIEM простыми словами?

Это система, которая собирает журналы событий с серверов, сетевого оборудования, средств защиты и приложений, приводит их к единому виду и по правилам выявляет признаки атак. Результат - оповещения об инцидентах и данные для расследования.

Чем SIEM отличается от SOC?

SIEM - программный инструмент для сбора и анализа событий. SOC - команда и процессы мониторинга и реагирования, собственные или внешние. SOC обычно работает на базе SIEM, а SIEM без SOC или ответственных сотрудников мало полезна.

Обязательна ли SIEM для субъектов КИИ?

Закон 187-ФЗ и приказ ФСТЭК № 239 не называют SIEM напрямую, но требуют регистрации событий, мониторинга безопасности, выявления инцидентов и информирования о них. SIEM - распространённый способ выполнить эти меры технически.

Сколько длится внедрение SIEM?

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

Можно ли обойтись без SIEM?

Небольшим компаниям с простой инфраструктурой часто достаточно централизованного сбора журналов, EDR и внешнего SOC. SIEM оправдана, когда источников много, есть требования регуляторов и есть кому реагировать на оповещения.

Какие российские SIEM-системы существуют?

Например, MaxPatrol SIEM от Positive Technologies, Kaspersky Unified Monitoring and Analysis Platform (KUMA), RuSIEM и KOMRAD Enterprise SIEM. Выбор зависит от инфраструктуры, объёма событий и требований к сертификации.

Блог

Читайте также

Все статьи

Аутстаффинг

IT-лизинг: как проверить специалиста в деле и забрать его в штат

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

Аутстаффинг

Аутстаффинг или найм в штат: сколько на самом деле стоит IT-специалист и когда выгоднее аутстафф

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

Разработка

1С-Битрикс: Управление сайтом - возможности, редакции и когда выбирать

Разбираем CMS «1С-Битрикс: Управление сайтом»: модули, редакции, плюсы и минусы, сравнение с другими платформами и чек-лист выбора.

Новый проект

Расскажите о задаче - предложим решение

Никита, CEO Блэнси, лично ответит на вопросы и подключит нужных специалистов.

Файлы

    PDF, Word, Excel, PowerPoint, JPG, PNG или ZIP - до 3 файлов, всего до 10 МБ. Большие файлы пришлите ссылкой на облако в сообщении. Не прикладывайте паспорта и документы с персональными данными других людей.

    Как вы о нас узнали