SIEM fundamentals
SIEM собирает логи с каждого хоста, приводит их к одной схеме и коррелирует этот поток в горстку алертов. Сложность не в хранении — а в том, чтобы из миллионов событий в час вытащить те три, что что-то значат.
3 часа ночи. Атакующий входит с украденным паролем, сервис аутентификации отдаёт чистый 200, а балансировщик, база данных, Linux-машина и audit-лог Kubernetes послушно пишут свои строки — каждый в своём формате, каждый в своём месте. Все записи, нужные чтобы поймать вторжение, уже существуют. Пробой не в том, что никто не залогировал; в том, что доказательство разбросано по сорока хостам в четырёх форматах, и никто не следил за единственной последовательностью — новая гео-локация, потом неудачная MFA, потом sudo, потом исходящая передача 4 ГБ — которая, прочитанная вместе, кричит о компрометации. SIEM существует, чтобы прочитать эти сорок логов как одну историю.
К концу урока ты будешь понимать, как SIEM превращает пожарный шланг сырых логов с каждого хоста в нормализованный, скоррелированный поток — и почему по-настоящему сложная часть это алертинг, а не хранение.
Что такое SIEM на самом деле
SIEM расшифровывается как Security Information and Event Management — но за аббревиатурой прячется настоящая работа. SIEM — это место, где каждый лог в твоей инфраструктуре собирается, делается сопоставимым и отслеживается на паттерны, которые ни один лог по отдельности не выдаст. NIST SP 800-92, канонический гайд по управлению логами, формулирует ядро проблемы точно: логи порождаются десятками источников в несовместимых форматах и объёмах, которые ни один человек не прочитает, поэтому вся ценность в их централизации и анализе, а не в самом акте записи.
Представь это как конвейер из четырёх стадий. Каждая стадия — место, где реальные системы ломаются в продакшене, поэтому стоит пройти их по порядку.
Стадии 1–2: сбор и нормализация — негламурная половина
Сбор — это сантехника: доставить каждый лог в одно место. Агенты (демон на каждом хосте, читающий файлы), syslog по сети, API облачных провайдеров (CloudTrail, GCP Audit Logs) и прямые интеграции — всё это кормит SIEM. Сбои здесь приземлённые и постоянные: хост, чей агент умер три недели назад, — это слепое пятно, о котором ты не знаешь, а неправильно настроенный фаервол, молча роняющий UDP-syslog, теряет записи без ошибки где-либо. Зрелый рефлекс — мониторить отсутствие логов: источник, внезапно замолчавший, сам по себе является алертом, потому что атакующие выключают логирование.
Нормализация — вот где живёт настоящая инженерия. Строка Linux sshd, JSON-событие AWS CloudTrail и access-лог nginx все описывают «кто-то что-то сделал откуда-то», но пишут это совершенно по-разному. Нормализация парсит каждый формат и отображает его поля в одну общую схему — так что srcip, 192.168.1.5 и client_addr все становятся единым полем вроде source.ip. Без этого корреляция невозможна: нельзя соединить неудачный вход по SSH с подозрительным запросом к базе, если «пользователь» — это acct, user_name и principalId в трёх разных логах.
| Сырой источник | Родное поле «кто» | Родное поле «откуда» | Нормализованная схема |
|---|---|---|---|
| Linux sshd | user | rhost | user.name / source.ip |
| AWS CloudTrail | userIdentity.principalId | sourceIPAddress | user.name / source.ip |
| nginx access | (нет — вывести из auth) | $remote_addr | user.name / source.ip |
| K8s audit | user.username | sourceIPs[] | user.name / source.ip |
Четыре источника, четыре схемы, один язык запросов после нормализации. Именно поэтому зрелые SIEM опираются на общую модель полей — Elastic Common Schema (ECS) и OCSF (Open Cybersecurity Schema Framework) существуют ровно затем, чтобы source.ip означало одно и то же везде, и одно правило могло охватить любой источник.
Стадия 3: корреляция — чтение логов как истории
Корреляция — причина существования SIEM. Единственный неудачный вход — это шум. Неудачный вход на сервисный аккаунт, который никогда не давал сбоев, из страны, которую ты никогда не видел, с последующим за девяносто секунд успешным входом и эскалацией привилегий — это атака, и увидеть её можно только соединяя события между источниками на временном окне. Этот join — ровно то, что сделала возможным нормализация.
Корреляционные правила бывают двух широких форм, и зрелые инженеры намеренно их смешивают:
- Сигнатурные / known-bad правила напрямую отображают поведение атакующего. Фреймворки вроде MITRE ATT&CK каталогизируют техники — скажем,
T1110Brute Force илиT1078Valid Accounts — и ты пишешь правила, детектирующие их телеметрию: «10 неудачных аутентификаций, потом успех с одного IP за 5 минут» отображается в credential stuffing. Они точны, но ловят только то, что ты назвал. - Аномальные / поведенческие правила помечают отклонение от базовой линии: пользователь тянет в 50× свой обычный объём данных, сервер открывает исходящее соединение, которого никогда не делал. Они ловят неизвестное, но платят за это ложными срабатываниями, потому что «необычное» и «вредоносное» пересекаются лишь частично.
▸Почему это работает
Почему бы просто не алертить на каждую отдельную подозрительную строку и пропустить корреляцию? Потому что объём тебя уничтожит. Инфраструктура среднего размера выдаёт миллионы событий в час, и заметная их доля в изоляции выглядит слегка подозрительно — каждый неудачный вход, каждый новый IP, каждая крупная загрузка. Алерти на каждое — и ты похоронишь реальную атаку под десятью тысячами безобидных; за неделю дежурный замьютит канал. Корреляция — это акт поднятия планки: она требует, чтобы несколько слабых сигналов выстроились в конкретной последовательности и окне, прежде чем что-либо достигнет человека, обменивая сырую полноту на точность, которая держит алерты заслуживающими доверия.
Стадия 4: алертинг — где SIEM живут или умирают
Весь конвейер существует, чтобы произвести небольшое число высокоточных алертов. Эту часть команды недооценивают. Хранение — решённая, скучная проблема: можно докупить. Тюнинг — вечная. Каждое правило сидит на компромиссе между ложными срабатываниями (кричать «волки!», пока аналитики не перестанут слушать — усталость от алертов, задокументированный сбой за реальными пробоями, которые технически детектировали, а потом проигнорировали) и ложными пропусками (реальная атака, которая никогда не задевает правило). Правило, затянутое достаточно туго, чтобы быть тихим, может пропустить новую атаку; правило, ослабленное достаточно, чтобы поймать всё, топит команду. Зрелая мера SIEM — не сколько он принимает, а его отношение сигнал/шум: алертов в день, которые человек реально может разобрать, и доля тех из них, что настоящие.
Твой SIEM выдаёт 800 алертов «подозрительный вход» в день; аналитики тихо замьютили канал, и в прошлом месяце сквозь него проскочил реальный захват аккаунта. Выбери ответ, который лучше всего чинит корневую проблему.
Почему нормализация — предпосылка для корреляции, а не опциональная приятность?
SIEM принимает 40 миллионов событий/час и хранит их идеально, но дежурная команда замьютила свой канал алертов. Что на самом деле сломано?
Упорядочь четыре стадии конвейера SIEM, от сырого лога до человека:
- 1 Сбор — доставить каждый лог в одно место (агенты, syslog, облачные API)
- 2 Нормализация — распарсить каждый формат в одну общую схему
- 3 Корреляция — соединить нормализованные события между источниками на временном окне
- 4 Алерт — отдать человеку только высокоточные совпадения
- 01Пройди по четырём стадиям конвейера SIEM и назови реальный продакшен-сбой на каждой.
- 02SIEM безупречно принимает 40 млн событий/час, но реальный захват аккаунта пропущен. Где проблема и как её чинить?
SIEM — Security Information and Event Management — существует потому, что каждая запись, нужная чтобы поймать вторжение, уже есть, просто разбросана по десяткам хостов в несовместимых форматах, и никто не читает их как одну историю. Он работает как конвейер из четырёх стадий. Сбор доставляет каждый лог в одно место (агенты, syslog, облачные API) и трактует замолчавший источник как отдельный алерт. Нормализация парсит каждый формат в общую схему (ECS/OCSF), чтобы source.ip означало одно и то же в строке sshd, событии CloudTrail и audit-логе K8s — без чего корреляция невозможна. Корреляция соединяет эти нормализованные события между источниками на временном окне, смешивая сигнатурные правила, отображённые на техники MITRE ATT&CK, с аномальными правилами против базовой линии, так что последовательность слабых сигналов становится одним детектированием. Алертинг отдаёт человеку только высокоточные совпадения, и именно здесь SIEM живут или умирают: хранение легко, но вечный компромисс между ложными срабатываниями (усталость от алертов) и ложными пропусками (пропущенная атака) делает сигнал/шум настоящей зрелой мерой. В следующий раз, когда SIEM хвалят за приём 40 миллионов событий в час, твой первый вопрос правильный: со сколькими алертами в день человек реально работает, и сколько из них настоящие?
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.