SIEM — это такой «центральный мозг» для событий безопасности. Его задача — собрать логи со всего, что только может что-то логировать, привести их к нормальному виду, связать между собой и подсветить, где у тебя потенциальный инцидент.
Исторически это выросло из двух направлений:
- SIM (Security Information Management) — про долгосрочное хранение и анализ логов: кто куда логинился, что делал, какие события были.
- SEM (Security Event Management) — про онлайн-реагирование на события: алерты, триггеры, дашборды в реальном времени.
Современный SIEM это всё смешивает: забирает логи с серверов, сетевых железок, приложений, баз, систем аутентификации, облаков, endpoint-решений и так далее. Дальше идёт нормализация, корреляция, поведенческий анализ, и на выходе появляются алерты, инциденты и отчеты для аудита.
Что именно делает SIEM #
- Собирает события: логины, логи файерволлов, IDS/IPS, прокси, VPN, всякие облачные аудиты и так далее.
- Анализирует поведение и сигнатуры: ищет отклонения от базовой линии и совпадения с типовыми паттернами атак.
- Генерирует алерты в реальном времени: от простых «10 неудачных логинов» до сложных сценариев lateral movement.
- Хранит логи долго, чтобы можно было делать расследования, отвечать аудиторам и закрывать требования регуляторов.
- Часто интегрируется с SOAR, чтобы не просто сигналить, но и запускать плейбуки реагирования.
Какие SIEMы чаще всего встречаются #
| Название | Особенности |
|---|---|
| Splunk | Очень мощный поиск и аналитика, хорошо масштабируется, но стоит дорого. Часто живет в больших компаниях. |
| IBM QRadar | Сильная корреляция событий с контекстом угроз, есть куча готовых коннекторов. |
| Kaspersky SIEM | Ориентирован на российскую нормативку, интегрируется с другими продуктами Kaspersky. |
| Elastic SIEM | Стек Elasticsearch + Kibana, хорошо подходит, когда нужно много кастома и open source-подход. |
| Azure Sentinel | Облачный SIEM от Microsoft, тесно связан с Microsoft 365 и использует ML/AI-аналитику. |
Где SIEM реально нужен #
- В корпоративных инфраструктурах — следить за входами, правами, действиями пользователей.
- В критичных системах — ловить APT, инсайдеров, подозрительную латеральную активность.
- В ЦОДах и облаках — держать под контролем десятки тысяч хостов и сервисов.
- В банках и финсекторе — чтобы соответствовать PCI DSS, ISO 27001, 152-ФЗ и прочим требованиям.
- В SOC — без SIEM нормально работать просто нечем, это фактически основной инструмент.
Как обычно выглядит работа SIEM шаг за шагом #
- Со всех систем (сервера, сетевые устройства, прокси, приложения) потоком летят логи — через syslog, агентов или API.
- SIEM приводит их к общему формату: CEF, JSON, LEEF — чтобы разные источники можно было анализировать одинаково.
- Запускаются правила корреляции: например, один и тот же IP за минуту ломится в десяток систем.
- Если условие выполняется, система поднимает алерт и отправляет его в SOC или запускает заранее заданный сценарий реакции.
- Всё это складывается в хранилище событий, откуда потом можно достать и для расследований, и для отчетов.
Роль SIEM в общей архитектуре безопасности #
- это единое окно обзора по всей ИТ-инфраструктуре;
- связка между средствами защиты, мониторингом и процессами реагирования;
- инструмент, которым потом машут перед аудиторами и регуляторами;
- главный источник данных для SOC-аналитиков, DFIR и threat hunting-команд.
Из чего вообще состоит SIEM-платформа #
[ Источники данных ]
│
▼
[ Сбор логов ]
(агенты, syslog, API)
│
▼
[ Нормализация ]
(приведение к унифицированному формату: CEF, LEEF, JSON)
│
▼
[ Хранилище событий ]
(временные метки, инциденты, сырые и обработанные логи)
│
▼
[ Корреляция ]
(правила, сигнатуры, поведенческий анализ)
│
▼
[ Алерты / Инциденты ]
│
▼
[ Реакция ]
(ручная или через SOAR: уведомления, блокировка, автоматизация)
Пример простого корреляционного правила #
Сценарий: кто-то подбирает пароль, а потом всё-таки входит.
IF
count(Event.type = "login_failed" AND Event.username = $user) > 5
WITHIN 10 minutes
AND
Event.type = "login_success" AND Event.username = $user
THEN
trigger Alert("Possible brute-force login", severity="high")
Синтаксис в реальных продуктах, конечно, свой: в Splunk это SPL, в QRadar — AQL, в Elastic — KQL, где-то это вообще визуальные конструкторы, но логика примерно одна и та же.
Чем SIEM отличается от SOAR #
| Параметр | SIEM | SOAR |
|---|---|---|
| Назначение | Сбор, анализ, корреляция и хранение событий | Автоматизация и координация реакции на инциденты |
| Фокус | Обнаружение угроз, построение контекста | Выполнение плейбуков, тикеты, workflow |
| Интеграции | С ИБ-системами, ИТ-инфрой, облаками | С SIEM, EDR, тикет-системами, мессенджерами |
| Алерты | Есть | Есть, плюс действия по ним |
| Автоматизация | Ограниченная | Основной функционал — сценарии, цепочки действий |
| Примеры | Splunk, QRadar, ArcSight, Elastic SIEM | Cortex XSOAR, IBM Resilient, Splunk SOAR, Shuffle.io |
| Хранение логов | Да | Обычно нет, опирается на SIEM |
Как они работают в паре #
В живой инфраструктуре связка выглядит так: SIEM находит проблему, SOAR решает, что с ней делать.
- SIEM создает алерт: «10 неудачных логинов подряд, потом успешный».
- SOAR получает алерт, обогащает его данными — IP, гео, репутация, whois.
- Если все условия плейбука выполняются, SOAR блокирует IP, создает тикет (например, в Jira) и шлет уведомление в Slack.
