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

Что такое SIEM и как он работает: от сбора логов до инцидентов

7 мин чтенияОпубликовано: 5 августа 2026 г.

Профессиональная визуальная иллюстрация по теме Что такое SIEM в области SIEM и обнаружения

Быстрый ответ

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

Современная организация генерирует данные безопасности практически на каждом уровне: конечные точки, серверы, Active Directory, облачные сервисы, приложения, Firewall, VPN, DNS, почтовые системы и продукты EDR. Каждый источник говорит на своем языке. Событие входа в систему может отображаться с именем пользователя в одном формате в Entra ID, в другом формате в Windows и с третьим идентификатором в бизнес-приложении. Без уровня, который централизует и связывает информацию, аналитику приходится переключаться между экранами и вручную строить общую картину.

Система SIEM призвана решить проблему разрозненности. Она получает Telemetry, сохраняет ее в соответствии с политикой, позволяет выполнять поиск и запросы, применяет логику Detection и предоставляет среду Case Management для расследования. Однако установка продукта не создает автоматически хороший SOC. Качественная SIEM зависит от правильных источников, точного времени, корректного Parsing, владения Rules и четкого процесса реагирования.

Руководство прослеживает одно событие входа в систему от сервера до экрана аналитика, объясняя на каждом этапе, что делает система, что может пойти не так и какое профессиональное решение требуется.

Зачем организации нужна SIEM

Первая цель — централизованная видимость. Когда пользователь входит в систему из необычной страны, его рабочая станция запускает PowerShell, DNS обращается к новому домену, а Firewall обнаруживает исходящий трафик, каждая запись в отдельности может выглядеть безобидно. Связь между ними в течение временного окна и в контексте того же пользователя и актива может указывать на скомпрометированную учетную запись.

Вторая цель — согласованность. SIEM позволяет организации определять Use Cases, Severity, Owners, Playbooks и критерии закрытия. Вместо того чтобы каждый аналитик заново решал, как проверять Password Spray или Malware alert, команда работает по логике и документации, которую можно измерять и улучшать.

Третья цель — сохранение и историческое расследование. Иногда организация обнаруживает Indicator только через несколько недель после проникновения. Если соответствующие логи были сохранены, можно искать IP, hash, домен или учетную запись задним числом, строить Timeline и оценивать масштаб ущерба. Retention должно определяться на основе риска, регулирования, стоимости и потребностей расследования — а не случайными настройками по умолчанию.

Первый этап: источники данных и сбор

Data Source — это место, где происходит событие: Windows Security Log, Syslog Firewall, Audit log SaaS, Telemetry EDR или Authentication log VPN. Сбор осуществляется с помощью Agent, Data Connector, API, Syslog/CEF, Event Forwarding или встроенного облачного сервиса. Каждый метод имеет свои преимущества, ограничения и разрешения.

Перед подключением источника определяется цель сбора. Вопрос не в том, «какие логи можно отправлять?», а в том, «какое поведение мы хотим обнаружить или расследовать, и какие поля для этого нужны?». Password Spray, например, требует как минимум времени, результата входа, пользователя, исходного адреса и иногда приложения или Tenant. Если поле пользователя отсутствует, изощренный Rule не решит проблему.

Уровень	Примеры источников	Ключевой вопрос качества
Идентификация	Entra ID, Active Directory, VPN	Есть ли пользователь, результат, MFA и исходный адрес?
Endpoint	EDR, Sysmon, Windows Events	Есть ли Host, Process, Parent, Command line и hash?
Сеть	Firewall, DNS, Proxy, IDS	Есть ли Source/Destination, Port, Action и Protocol?
Облако и приложение	AWS CloudTrail, Azure Activity, SaaS Audit	Определены ли операция, ресурс и Actor?

Parsing, Normalization и обогащение

После приема система должна понять запись. Parsing извлекает поля из текста или JSON. Normalization сопоставляет различные имена с согласованной моделью: src_ip, sourceAddress и ClientIP могут представлять одну и ту же идею. В Microsoft ASIM предоставляет модель нормализации, которая позволяет писать Query или Detection для единой Schema вместо адаптации логики к каждому продукту в отдельности.

Normalization не удаляет источник. Рекомендуется сохранять также необработанное событие для проверки деталей и расследования ошибочного Parsing. Когда Parser меняется, Rule может перестать работать незаметно. Поэтому измеряются Schema changes, пустые поля, Ingestion delay и аномальный объем.

Enrichment добавляет контекст, отсутствующий в логе: критичность актива, владелец системы, отдел, GeoIP, Threat Intelligence, является ли учетная запись Privileged, принадлежит ли IP корпоративному VPN и соответствует ли активность одобренному Change. Обогащение изменяет качество решения. Один неудачный вход на тестовый сервер не то же самое, что такой же вход на учетную запись Domain Admin.

Обнаружение: от Query до алерта

Detection rule проверяет данные по условию. Она может искать известный Indicator, последовательность событий, Threshold, отклонение от Baseline или комбинацию источников. Scheduled rule запускает Query через определенные промежутки времени и проверяет Lookback window. Если результаты превышают порог, создается Alert. Другие продукты импортируют готовые Alerts, и SIEM может объединять некоторые из них в один Incident.

Хороший Rule начинается с Use Case и гипотезы, а не с технической команды. Необходимо определить, что представляет собой поведение, какие источники требуются, что является единицей результата, какие Entities будут сопоставлены, что такое Severity, что такое Expected noise и что должен делать аналитик. Rule, который невозможно расследовать, создает нагрузку, даже если он «ловит» много событий.

Correlation связывает события. Она может обнаружить пять неудачных попыток, за которыми следует успешная, подозрительный Process после нового входа или один и тот же IP для многих пользователей. Важно помнить: соответствие правилу — это Lead для расследования, а не доказательство атаки. Аналитик должен проверять источник, контекст, Timeline и законные объяснения.

Incident и Case Management

Alert описывает определенное совпадение. Incident — это дело о расследовании, которое централизует Alerts, Entities, Evidence, Timeline, Tasks, Owner, Severity, Status и ответы. Case Management позволяет передавать информацию (Hand-off), эскалировать, документировать и генерировать метрики. Система должна сохранять разделение между фактами, интерпретацией и решением.

При открытии Incident аналитик проверяет: кто пользователь и актив, каково время активности, какие источники участвовали, есть ли дополнительные Alerts, какова критичность актива и что изменилось по сравнению с обычным поведением. Затем он выполняет дополнительные Queries, проверяет Indicators, строит Timeline и решает, является ли это False Positive, Benign Positive или True Positive.

Сценарий: событие входа с сервера на экран аналитика

Сервер Windows регистрирует событие входа с временем, пользователем, Logon type и исходным адресом.
Forwarder или Connector отправляет событие в SIEM. Система добавляет время получения и идентифицирует источник данных.
Parser извлекает Account, Computer, Source IP и Result. Уровень Normalization сопоставляет их с унифицированными полями.
Enrichment помечает учетную запись как Privileged, а сервер как Production. Threat Intelligence не идентифицирует IP, но GeoIP указывает на неожиданную страну.
Rule обнаруживает несколько неудачных попыток, за которыми следует успешная в течение временного окна. Он сопоставляет User, Host и IP и создает Alert.
Дополнительный Alert от EDR обнаруживает аномальный Process на той же рабочей станции. Alert grouping объединяет оба в один Incident.
Аналитик проверяет MFA, VPN, Process tree, DNS и другую активность, строит Timeline и принимает решение о Containment и эскалации.

Что SIEM не делает в одиночку

SIEM не гарантирует, что все данные существуют или верны. Он не заменяет Asset inventory, правильный IAM, EDR, Network controls или профессионалов. Он также не знает автоматически, что является нормальным для организации. Без Owners и Tuning система может генерировать слишком много Alerts или создавать ложное чувство безопасности.

Автоматизация может обогащать, открывать Ticket или изолировать актив, но автоматическое действие должно соответствовать уровню уверенности и воздействия. Блокировка критического пользователя на основе "шумного" Rule может привести к простою. Поэтому определяются Approval, Exceptions, Rollback и Audit trail.

SIEM против смежных систем

Понятие	Фокус	Практическое отличие
Log Management	Сбор, хранение и поиск	Может не включать Detection и полный Case Management
SIEM	Обнаружение, расследование и управление инцидентами на основе множества данных	Связывает Telemetry с процессом SOC
SOAR	Автоматизация и оркестрация реагирования	Запускает Playbooks и связывает системы; иногда интегрирован в SIEM
XDR	Комплексное обнаружение и реагирование в таких доменах, как Endpoint, Identity и Email	Поставляется с глубокими Telemetry и Detections для конкретной платформы

Checklist для внедрения Use Case

Определено поведение, а не только имя Rule.
Необходимые источники данных и поля доступны.
Время событий синхронизировано, и часовой пояс ясен.
Parsing и Normalization проверены на реальных примерах.
Entities и критичность активов сопоставлены.
Определены Threshold, Severity и Expected noise.
Существует Playbook с дополнительными Queries и путем эскалации.
Назначены Owner, Review date и метрики качества.
Проверены Retention, стоимость и права доступа.

Распространенные ошибки

Подключать каждый возможный источник до определения Use Cases.
Полагаться на Timestamp приема вместо времени события.
Предполагать, что каждое поле с именем user представляет одну и ту же личность.
Создавать Rule без Entity mapping или инструкций по расследованию.
Закрывать Alerts как шум, не предоставляя обратную связь Detection owner.
Показывать зеленый Dashboard, когда источник данных перестал отправлять.
Хранить логи в течение периода, который не позволяет проводить историческое расследование.

Заключение и CTA

Выберите один Use Case — например, Password Spray — и нарисуйте всю цепочку: источник, поля, Parser, Query, Entity, Incident и действие аналитика. Затем перейдите к руководству KQL, чтобы написать свой первый запрос. На курсе Cybersecurity & AI в HPI SIEM практикуется как часть полного процесса расследования, включая логи, сети, Windows и реагирование на инциденты.

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

SIEM — это продукт или процесс?

SIEM — это продукт или платформа, но ценность исходит от процесса, который включает сбор, Data quality, Detection engineering, расследование, реагирование и улучшение. Приобретение одной лишь лицензии не создает возможности SOC.

Каждое ли событие в SIEM становится оповещением?

Нет. Большинство событий сохраняются для поиска, Correlation или расследования. Alert создается только тогда, когда логика Detection или подключенный продукт обнаруживают определенное условие.

В чем разница между Alert и Incident?

Alert — это отдельная находка обнаружения. Incident — это дело о расследовании, которое может включать несколько Alerts и доказательств, связанных с одной и той же историей или Entity.

Обязательно ли SIEM должен быть в облаке?

Нет. Существуют облачные, On-premises и гибридные платформы. Выбор зависит от архитектуры, данных, регулирования, стоимости и эксплуатации.

Какой источник данных следует подключать первым?

Начинайте с критически важных активов и удостоверений, а также с четких Use Cases. Обычно Identity, Endpoint, Firewall/DNS и Cloud audit обеспечивают прочную основу, но порядок зависит от организационного риска.