SIEM собирает логи, нормализует их, применяет правила корреляции и поднимает алерты для триажа. Разбираем весь конвейер на примере, который можно запустить.
Когда команда безопасности говорит, что «видела атаку», обычно это значит: атака оставила записи в нескольких местах, а система свела их вместе и подняла флаг. Чаще всего такая система — это SIEM, сокращение от security information and event management. С SIEM начинается значительная часть ежедневной работы SOC: аналитик открывает алерт, смотрит стоящие за ним события и решает, нужно ли кому-то действовать.
Здесь по шагам разобрано, что делает SIEM: откуда берутся данные, почему логи надо привести к другому виду, прежде чем от них будет толк, как правила корреляции превращают события в алерты и что происходит после срабатывания. Ещё показано, какое место SIEM занимает рядом с EDR и SOAR, а один пример алерта сопоставлен с техникой MITRE ATT&CK, чтобы было видно, как детект связан с поведением атакующего.
Лаборатория для этого не нужна. Практическая часть — небольшой скрипт, который работает на любой машине с Python 3.12 и использует синтетические логи. Из сырых строк он делает настоящий алерт, а если поменять данные, изменится и результат. Если нужен полноценный стек, в последних разделах названы два бесплатных варианта, которые можно поставить самостоятельно.
SIEM выполняет три задачи на одной платформе. Он собирает логи и события из многих источников. Хранит эти данные, чтобы по ним можно было искать позже. И применяет к ним правила, которые поднимают алерт, когда что-то совпадает с шаблоном.
В руководстве NIST по управлению логами компьютерной безопасности, SP 800-92, собраны практические рекомендации о том, как выстроить, внедрить и поддерживать управление логами в организации. Управление логами там описано как постоянная практика, которую команда должна спланировать и вести дальше. SIEM — один из распространённых способов вести её в большом масштабе, но есть и другие. Маленькая команда может многого добиться с центральным лог-сервером и несколькими хорошо написанными поисковыми запросами.
Слово «security» в названии значит меньше, чем слово «event». По умолчанию SIEM не знает, какое событие плохое. Он знает события, которые вы ему отправляете, и правила, которые вы пишете. Качество его работы зависит от входящих данных и от детектов поверх них.
Атакующие редко дают один ясный сигнал. Неудачный вход, новая задача в планировщике и исходящее соединение с незнакомым хостом сами по себе обычны. Вместе они могут описывать вторжение. SIEM полезен тем, что может положить эти записи рядом, по всем хостам, аккаунтам и временным отрезкам. Человек, читающий отдельные файлы на отдельных машинах, в заметном масштабе на это не способен.
Вторая причина в объёме. Организация с несколькими сотнями машин может выдавать миллионы строк логов в день. Ни один аналитик их не читает. Задача SIEM — сократить этот объём до короткого списка того, на что должен посмотреть человек, с контекстом, которого хватит для быстрого решения.
SIEM работает поэтапно. Сломаться может каждый этап, и многие проблемы с детектами восходят к одному из них.
Источник логов — это всё, что пишет запись о случившемся. В большинстве сред обычно встречаются такие:
Каждый источник описывает мир со своей точки зрения. Файрвол видит соединение. Хост на Windows видит вход в систему. Всю историю целиком не видит ни один из них.
На этапе сбора записи идут от источника в SIEM. Обычные способы: агент, установленный на хосте, форвардер, который читает файлы логов, сообщения syslog по сети или API, через который события забираются из облачного сервиса. Агенты могут снимать с хоста больше деталей. Syslog прост и поддерживается почти везде, но под нагрузкой может терять сообщения, если их никто не буферизует.
Сбой сбора происходит тихо. Если сервер перестал присылать логи, SIEM по умолчанию ошибки не покажет. Про этот сервер ему просто нечего сказать, и тишина может выглядеть как спокойствие. Хорошие команды следят за объёмом событий по каждому источнику и поднимают алерт, когда источник замолкает.
У каждого источника свой формат. Одна система пишет имя пользователя как user, другая как account, третья как subject.name во вложенном JSON. Нормализация отображает эти поля на одну общую схему, чтобы правило могло сказать «поле пользователя» и для любого источника это значило одно и то же.
Большинство продуктов SIEM делают это за вас, встроенными парсерами или по опубликованной схеме. Цель у всех одна: после нормализации поиск неудачных входов выглядит одинаково для событий из Linux, Windows и облачного провайдера идентификации.
Скрипт ниже делает то же самое в малом масштабе. Он берёт одну сырую строку SSH и каждый раз выдаёт словарь с одними и теми же именами полей.
Срок хранения показывает, как долго логи лежат до удаления. Звучит как административная мелочь, но именно он определяет, что вы сможете расследовать. Для вторжения, обнаруженного через три месяца, нужны логи трёхмесячной давности. Если срок хранения две недели, улики исчезнут раньше, чем кто-то начнёт их искать.
Подходящий срок зависит от вашей политики, юридических и регуляторных обязанностей и стоимости хранения. Рекомендации по управлению логами вроде NIST SP 800-92 охватывают весь жизненный цикл данных, поэтому срок хранения закладывают в план с самого начала, пока диск ещё не заполнился. Запишите, что вы храните, как долго и кто может это читать. Потом проверьте, что удаление действительно происходит.
Свежие данные обычно лежат в быстром и дорогом хранилище. Старые можно перенести в более дешёвое, где поиск идёт медленнее. Компромисс простой: чем старше событие, тем дольше его искать.
На этапе корреляции SIEM смотрит на несколько событий сразу, а не внутрь одного. Правило корреляции описывает шаблон: условие, временное окно и ключ группировки. Когда шаблон обнаружен, правило создаёт алерт.
Вот правило для password spraying, записанное обычным языком. В практической части мы его проверим.
Group events by source IP over a 10-minute window.
Count distinct user accounts with a failed login from that source.
If the count is 4 or more, and the same source later has a successful login,
create an alert with the source IP, the accounts and the successful login.Такое правило полезно по двум причинам. Оно опирается на несколько событий, поэтому один неудачный вход не вызывает срабатывания. И группирует оно по ключу, который подходит к атаке. Подбирая пароли, атакующие часто пробуют один пароль на многих аккаунтах из одного места, и при группировке по источнику эта картина хорошо видна.
Алерт сообщает, что что-то требует внимания. Вывода о том, что атака произошла, в нём нет. Триаж — первое решение после срабатывания. Аналитик задаёт четыре вопроса: основан ли алерт на настоящих данных, важен ли этот аккаунт или хост, что происходило до и после и какой следующий шаг. Многие алерты закрываются здесь как безобидные: например, это ваш собственный скан уязвимостей или пользователь, который ошибся в пароле после смены.
Хороший триаж заканчивается решением и заметкой. В заметке записано, что проверил аналитик, чтобы следующему человеку не пришлось повторять работу. Команды, которые пропускают заметку, каждую неделю заново расследуют один и тот же безобидный алерт.
Три термина встречаются вместе в большинстве SOC, и области их действия пересекаются.
SIEM собирает и коррелирует записи из многих источников по всей среде. Его сила в широте охвата и истории. Его ограничение в том, что он видит только то, о чём сообщает каждый источник.
EDR, endpoint detection and response, подробно следит за конечными точками. Он записывает активность процессов, изменения файлов и сетевые соединения на каждом хосте и часто умеет изолировать машину. Его сила в глубине на конечной точке. Логов файрвола и облачного аудита он не видит, если вы их к нему не подключили.
SOAR, security orchestration, automation and response, выполняет плейбуки. Плейбук может дополнить алерт проверкой репутации, открыть тикет, после согласования отключить аккаунт или уведомить дежурного. Его сила в повторяемой реакции. Его результаты зависят от качества алертов, которые он получает.
Для этого упражнения нужен только Python 3.12. Логи синтетические и используют адреса из 192.0.2.0/24, диапазона, зарезервированного для документации. Никакая система при этом не затрагивается. Скрипт читает строки, нормализует их, применяет правило password spraying и печатает результат.
Сохраните этот код как siem_demo.py:
# Synthetic logs only. 192.0.2.0/24 is a documentation range (TEST-NET-1).
import re
from collections import defaultdict
RAW = """\
2026-11-07T10:00:01Z sshd[811]: Failed password for alice from 192.0.2.44 port 50111
2026-11-07T10:00:03Z sshd[812]: Failed password for bob from 192.0.2.44 port 50112
2026-11-07T10:00:05Z sshd[813]: Failed password for carol from 192.0.2.44 port 50113
2026-11-07T10:00:07Z sshd[814]: Failed password for dave from 192.0.2.44 port 50114
2026-11-07T10:00:09Z sshd[815]: Failed password for erin from 192.0.2.44 port 50115
2026-11-07T10:00:11Z sshd[816]: Accepted password for erin from 192.0.2.44 port 50116
2026-11-07T10:02:00Z sshd[820]: Accepted password for frank from 192.0.2.10 port 50200
2026-11-07T10:03:00Z sshd[821]: Failed password for frank from 192.0.2.10 port 50201
"""
PATTERN = re.compile(
r"^(?P<ts>\S+) sshd\[\d+\]: (?P<outcome>Failed|Accepted) password for "
r"(?P<user>\S+) from (?P<src>\S+) port \d+$"
)
def normalize(line):
m = PATTERN.match(line)
if not m:
return None
return {
"timestamp": m["ts"],
"event_type": "authentication",
"outcome": "success" if m["outcome"] == "Accepted" else "failure",
"user": m["user"],
"source_ip": m["src"],
}
events = [e for e in (normalize(l) for l in RAW.splitlines()) if e]
print(f"normalized {len(events)} events")
# Rule: one source IP fails against 4+ different accounts, then gets a success from that IP.
fails = defaultdict(set)
successes = defaultdict(list)
for e in events:
if e["outcome"] == "failure":
fails[e["source_ip"]].add(e["user"])
else:
successes[e["source_ip"]].append(e)
for ip, users in fails.items():
if len(users) >= 4 and successes.get(ip):
s = successes[ip][0]
print(f"ALERT src={ip} failed_accounts={len(users)} then_success_user={s['user']} at={s['timestamp']}")
print(" mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)")Запустите его из папки, где он сохранён:
python -I siem_demo.pyФлаг -I запускает Python в изолированном режиме. Он игнорирует переменные окружения и не добавляет папку скрипта в путь импорта. Это хорошая привычка, когда запускаете скрипт, написанный не вами.
На машине с Windows 11, где проверялась статья, с Python 3.12.10 вывод был таким:
normalized 8 events
ALERT src=192.0.2.44 failed_accounts=5 then_success_user=erin at=2026-11-07T10:00:11Z
mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)Правило в скрипте намеренно короткое. Оно не применяет 10-минутное окно из версии на обычном языке и не проверяет, что успешный вход случился после неудач. Правило для продакшена делало бы и то и другое.
Пять аккаунтов получили отказ с одного адреса примерно за десять секунд. Затем erin успешно вошла с того же адреса. Правило сработало, потому что выполнились оба условия: много аккаунтов и мало попыток на каждый, а после них успешный вход. Опечатка или сохранённый пароль редко выглядят так.
Теперь посмотрите на второй источник, 192.0.2.10. Frank успешно вошёл, а потом появилась неудача. Правило промолчало, потому что с этого адреса получил отказ только один аккаунт. Для этого и нужен ключ группировки. Один неудачный вход — это шум. Отказы у пяти разных аккаунтов из одного места складываются в шаблон.
Поменяйте данные и посмотрите на компромиссы. Если удалить строку с успешным входом erin, алерт исчезнет, хотя неудачи останутся: правилу нужно и то и другое. Если поднять порог до 6, алерт тоже исчезнет, потому что отказ получили только пять аккаунтов. В продакшене более строгое правило пропускает медленные атаки, а более мягкое чаще срабатывает на обычное поведение.
MITRE ATT&CK — публичная база знаний о поведении атакующих. У каждой техники есть ID, тактика и описание, а в рекомендациях по детекту некоторых техник перечислены источники данных, которые их выявляют.
Этот алерт подходит под T1110, Brute Force, в тактике Credential Access. ATT&CK описывает brute force как повторяющиеся попытки получить доступ к аккаунтам, когда атакующий не знает пароля. Там перечислены четыре подтехники. Password Spraying (T1110.003) означает перебор одного или нескольких паролей на многих аккаунтах, что позволяет не заблокировать ни один отдельный аккаунт. Password Guessing (T1110.001) перебирает много паролей для одного аккаунта. Credential Stuffing (T1110.004) повторно использует пароли, утёкшие из других сервисов. На этой же странице есть ссылка на стратегию детекта, которая коррелирует неудачи аутентификации на разных платформах; идея та же, что и у нашего маленького правила.
Обратите внимание на слово «candidate» в выводе. Правило совпало с шаблоном, и шаблон согласуется со spraying. Он согласуется и с неправильно настроенным сервисом, который пробует несколько сохранённых учётных данных, и с внутренним тестом. Что именно произошло, должен выяснить триаж. Сопоставление с ATT&CK подсказывает, где искать и какое связанное поведение проверять дальше, например использование действительных аккаунтов (T1078) после успешного входа. Доказательством того, что атака произошла, оно не служит.
Большую часть этого можно освоить, ничего не покупая. Два открытых варианта покрывают путь от сбора до алерта. Запускайте любой из них на свободной машине или в виртуальной машине.
В документации Wazuh он описан как бесплатная платформа безопасности с открытым исходным кодом, объединяющая возможности XDR и SIEM. У него три центральных компонента, Wazuh indexer, Wazuh server и Wazuh dashboard, плюс универсальный агент, который ставится на наблюдаемые системы. В руководстве по началу работы есть quickstart, который разворачивает стек за несколько минут. Там же описаны пошаговая установка, виртуальные машины, Docker и Kubernetes. Версию и точные команды смотрите в актуальной документации, потому что от релиза к релизу они меняются.
Для практики поставьте агент на виртуальную машину с Linux. Со второй виртуальной машины, которой вы управляете, сделайте несколько неудачных входов по SSH и посмотрите, как события приходят в панель. Так вы пройдёте сбор, нормализацию и алерты на настоящем конвейере.
В документации Elastic Security описан SIEM, построенный на Elastic Stack. В обзоре перечислены сбор данных через интеграции и Elastic Agent, детект с помощью готовых правил, собственных правил и машинного обучения, триаж алертов, Timeline для хантинга и Cases для записи расследований. Какие из этих функций входят в самостоятельно развёрнутую установку, зависит от уровня лицензии, поэтому перед деплоем прочитайте страницу подписок Elastic. В обзоре нет списка функций SIEM, которые такая установка получает бесплатно, так что не рассчитывайте, что бесплатный уровень покрывает какую-то конкретную функцию детекта.
Начните с руководства NIST SP 800-92. Оно организационное и высокоуровневое, так что читайте его ради вопросов, которые оно ставит: например, кто отвечает за каждый источник логов и как долго они хранятся. Затем откройте страницу ATT&CK для T1110 и прочитайте заметки о детекте рядом с подтехниками.
После этого поставьте Wazuh или Elastic на виртуальную машину и отправьте логи из одного источника, которым вы управляете. Напишите одно правило под шаблон, который можете вызвать намеренно, а затем напишите заметку о триаже так, будто завтра её подхватит коллега.
Следующая статья этой серии посвящена журналу событий Windows и идентификаторам событий, на которых держатся многие правила корреляции; с ней такие правила легче читать: журналы событий Windows и идентификаторы событий. Если хотите понять, как на практике пишут отдельный детект, статья YARA-правило для безобидного тестового файла показывает ту же идею: проверить правило на известных данных, прежде чем ему доверять.
Детектирование и blue team
Как читать журнал Security: политика аудита, события 4624, 4625, 4634, 4672, 4688 и 1102, что добавляет Sysmon и как найти собственный неудачный вход.
Детектирование и blue team
Напишите правило Sigma для неудачных входов в Windows, проверьте его, сконвертируйте для Splunk и протестируйте на заведомо хороших и заведомо плохих событиях.