SIEM

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

SIEM получает данные от серверов, рабочих станций, Firewall, EDR, Active Directory, приложений, облачных сервисов и других систем. Затем она приводит события к удобному для анализа виду, сопоставляет их между собой и помогает обнаруживать признаки атак и нарушений.

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

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

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

Представим компанию с сотнями компьютеров и десятками серверов.

Каждая система ведет собственные Logs:

Firewall → network logs
Windows → security logs
Linux → authentication logs
EDR → endpoint alerts
Web Server → access logs
Cloud → audit events

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

SIEM собирает их в одном месте и позволяет построить единый Timeline.

Расшифровка SIEM

SIEM расшифровывается как Security Information and Event Management — управление информацией и событиями безопасности.

Исторически концепция объединила две задачи: долгосрочное управление Security Information и оперативную обработку Security Events.

Для чего нужна SIEM

SIEM используется для:

• централизованного сбора логов;
• поиска Security Events;
• корреляции событий;
• обнаружения атак;
• расследования инцидентов;
• создания Alerts;
• аудита действий пользователей;
• мониторинга привилегированных Accounts;
• Threat Hunting;
• Compliance и отчетности.

Какие данные собирает SIEM

Источниками могут быть практически любые системы, способные отдавать Logs или Events.

Как работает SIEM

Упрощенная архитектура выглядит так:

Sources
↓
Log Collection
↓
Parsing / Normalization
↓
Storage
↓
Correlation / Detection
↓
Alerts / Investigation

Сначала события собираются, затем разбираются по полям, сохраняются и анализируются правилами или аналитическими механизмами.

Сбор логов

Logs могут поступать разными способами:

• Agent;
• Syslog;
• API;
• Windows Event Forwarding;
• Cloud Connector;
• File Collection;
• Message Queue.

Выбор зависит от источника и архитектуры.

Agent-based сбор

На Server или Endpoint устанавливается Agent, который читает локальные журналы и отправляет события в SIEM.

Преимущество — возможность централизованно контролировать доставку и собирать данные даже из сложных локальных источников.

Agentless сбор

SIEM может получать события без локального Agent, например через Syslog или API.

Это упрощает эксплуатацию, но доступный набор данных зависит от возможностей Source System.

Syslog

Syslog широко используется сетевым оборудованием и Unix-подобными системами для передачи событий.

Firewall, Router и Switch могут отправлять Logs на централизованный Collector.

Почему надежность доставки логов важна

Если во время атаки Events не дошли до SIEM, расследование будет неполным.

Для критичных Sources полезны Buffering, Queue и Monitoring доставки.

Parsing

Разные системы записывают Events в разных форматах.

Parser извлекает из строки отдельные поля.

Например:

time=12:10 user=admin src=10.0.1.25 action=login status=failed

SIEM выделяет Timestamp, User, Source IP, Action и Status.

Normalization

Normalization приводит события разных Vendors к общей модели.

Один продукт может использовать поле src_ip, другой sourceAddress, третий client_ip.

После Normalization они представляются как единое логическое поле Source IP.

Зачем нужна нормализация

Без общей схемы Detection Rule пришлось бы писать отдельно для каждого продукта.

Нормализация позволяет применять одно правило к разным Sources.

Enrichment

SIEM может дополнять Event внешней информацией.

Например:

• GeoIP;
• Asset Criticality;
• Username и Department;
• Threat Intelligence;
• CMDB;
• Vulnerability Information.

Пример обогащения

Исходный Event содержит:

src_ip=10.20.30.15

После Enrichment SIEM понимает:

Host=FINANCE-PC-17
Owner=Accounting
Criticality=High

Alert становится более информативным.

Корреляция событий

Correlation объединяет несколько Events по времени, пользователю, IP, Host или другим признакам.

Например:

10 failed logins
↓
successful login
↓
admin group membership change

Каждое событие отдельно может быть обычным, но вместе они выглядят подозрительно.

Correlation Rule

Правило может выглядеть концептуально так:

IF failed_logins > 20
AND successful_login = true
WITHIN 10 minutes
THEN create alert

Реальный синтаксис зависит от SIEM Platform.

Detection Rule

Detection Rule описывает поведение, которое следует считать подозрительным.

Например:

• массовые Failed Logins;
• вход Administrator ночью;
• создание нового Privileged Account;
• запуск PowerShell после Office Document;
• Connection к известному вредоносному Domain.

Alert

Когда правило срабатывает, SIEM создает Alert.

Alert должен содержать достаточно контекста, чтобы аналитик мог быстро понять причину.

Полезные поля:

• Severity;
• Source;
• User;
• Host;
• IP;
• Detection Rule;
• Related Events;
• Timestamp.

Incident

Несколько Alerts могут относиться к одной атаке.

SOC объединяет их в Incident и расследует как единое событие.

SIEM и SOC

SIEM является одним из основных инструментов Security Operations Center.

SOC Analyst использует ее для мониторинга Alerts, поиска событий, Threat Hunting и расследования Incidents.

SIEM и EDR

EDR предоставляет глубокую Endpoint Telemetry, а SIEM объединяет данные EDR с другими Sources.

Например:

EDR → suspicious process
Firewall → outbound connection
AD → privileged login
↓
SIEM correlation

Так появляется более полный Security Context.

SIEM и XDR

XDR больше ориентирован на готовую Detection and Response Correlation между Endpoint, Identity, Email, Network и Cloud.

SIEM обычно предоставляет более универсальную платформу сбора и анализа Logs из практически любых систем.

Эти решения могут использоваться совместно.

SIEM и SOAR

SOAR автоматизирует действия после Detection.

SIEM создает Alert, а SOAR запускает Playbook.

SIEM Alert
↓
SOAR Playbook
↓
Block IP
Disable account
Create ticket

SIEM и Firewall

Firewall отправляет в SIEM информацию о Connections.

SIEM может обнаружить, что один внутренний Host устанавливает тысячи Connections на необычные внешние Addresses.

SIEM и WAF

WAF Logs показывают SQL Injection, XSS, Bot Activity и другие Web Security Events.

SIEM связывает их с Web Server, Endpoint и Identity Data.

SIEM и Active Directory

Directory Events особенно важны для Security Monitoring.

SIEM может отслеживать:

• Logon;
• Failed Login;
• Password Reset;
• создание Account;
• изменение Groups;
• Administrative Activity.

Привилегированные учетные записи

Действия Domain Admin и других Privileged Accounts имеют повышенный риск.

SIEM может создавать Alert при необычном использовании таких Credentials.

SIEM и VPN

VPN Logs позволяют видеть удаленные подключения сотрудников.

Например, SIEM связывает:

VPN login from new country
↓
Admin access to server
↓
Large file download

Такая последовательность требует анализа.

SIEM и SSH

Linux Server может отправлять события успешных и неудачных SSH Logins.

SIEM обнаруживает Brute Force, необычный Root Login или массовые подключения одного Account к нескольким Hosts.

SIEM и RDP

Windows Events позволяют анализировать Remote Desktop Sessions.

Полезны правила на:

• RDP Login из неизвестной сети;
• массовые Failed Logins;
• Administrator Login на критичный Server;
• подозрительное перемещение между Hosts.

SIEM и Cloud

В Cloud SIEM получает Audit Logs от IaaS и SaaS Platforms.

Например:

• создание новой VM;
• изменение Firewall Rule;
• создание Access Key;
• назначение Admin Role;
• отключение Logging.

Cloud Audit Logs

Audit Events показывают, кто и когда изменил Cloud Resource.

Это критично для Investigation, потому что многие Cloud Attacks происходят без Malware на Endpoint.

SIEM и SaaS

Корпоративные SaaS Applications также генерируют Authentication и Audit Events.

SIEM может выявлять необычные Logins, массовую загрузку файлов или изменение Sharing Permissions.

SIEM и Web Server

Access Logs позволяют анализировать HTTP Requests.

Например, всплеск 404, странные URL и многочисленные Requests к административным Endpoints могут указывать на сканирование.

SIEM и Database

Database Audit Logs помогают контролировать:

• Administrative Login;
• создание пользователей;
• изменение Permissions;
• доступ к критичным Tables;
• массовый Export.

SIEM и DNS

DNS Logs являются ценным источником для обнаружения Malware и Command and Control.

Если Endpoint внезапно обращается к подозрительному Domain, SIEM может связать это с EDR Alert.

SIEM и Proxy

Corporate Proxy Logs показывают, какие Websites и APIs посещают пользователи и Servers.

Это помогает расследовать Phishing и Malware Downloads.

SIEM и Email Security

Email Gateway может передавать информацию о Phishing, Attachments и подозрительных Links.

SIEM связывает эти события с дальнейшими действиями пользователя.

Пример цепочки атаки

Email Security → malicious attachment
EDR → powershell started
DNS → suspicious domain
Firewall → outbound connection
AD → privileged login

SIEM позволяет собрать все это в общий Timeline.

Threat Hunting

Threat Hunting — проактивный поиск подозрительной активности в накопленных данных.

Аналитик не ждет Alert, а формулирует Hypothesis.

Например: «Есть ли в инфраструктуре Hosts, которые выполняли определенную подозрительную Command Line?»

IOC Search

Если Security Team получает вредоносный IP или Hash, его можно найти в исторических Logs.

Так аналитик определяет, взаимодействовали ли корпоративные системы с этим Indicator раньше.

Threat Intelligence

SIEM может получать внешние списки вредоносных IP, Domains и Hashes.

При совпадении с внутренним Event создается дополнительный Security Signal.

Почему IOC недостаточно

Indicator может быстро устареть или быть заменен злоумышленником.

Поэтому SIEM должна использовать и Behavioral Rules, а не только списки известных адресов.

UEBA

UEBA, или User and Entity Behavior Analytics, анализирует нормальное поведение Users и Hosts и ищет отклонения.

Например, Account обычно входит только днем из одного офиса, но внезапно ночью начинает обращаться к сотням Servers.

Baseline

Для поиска аномалий нужно знать нормальное поведение.

Baseline может учитывать:

• обычное время входа;
• типичные Hosts;
• среднее количество Requests;
• обычные страны входа;
• типичный объем данных.

Anomaly Detection

Аномалия сама по себе не означает атаку.

Командировка сотрудника также создает необычный Login.

Поэтому Context и Correlation остаются критичными.

False Positive

False Positive — легитимное событие, ошибочно признанное подозрительным.

Если таких Alerts слишком много, возникает Alert Fatigue.

False Negative

False Negative означает, что атака произошла, но Detection Rule ее не обнаружила.

Поэтому правила необходимо регулярно тестировать и обновлять.

Alert Fatigue

Если SOC получает тысячи малоценных Alerts, действительно критичный Incident может потеряться среди шума.

Для уменьшения проблемы используются Tuning, Correlation и Risk-based Prioritization.

Severity

Alert может иметь уровень Critical, High, Medium или Low.

Severity должна учитывать не только тип Detection, но и Criticality Asset.

Одинаковая атака на тестовый Notebook и Domain Controller имеет разный бизнес-риск.

Asset Criticality

CMDB или Asset Inventory может сообщить SIEM, что определенный Server является критичным.

Тогда события на нем получают более высокий Risk Score.

Risk-based Alerting

Вместо одного простого правила SIEM может накапливать Risk Signals.

Например:

new country login +20
failed MFA +30
admin role assigned +50

При достижении порога создается High-risk Incident.

MITRE ATT&CK

Detection Rules часто связывают с техниками MITRE ATT&CK.

Это помогает понимать, какие этапы Attack Lifecycle покрывает Monitoring.

Coverage Mapping

Security Team может построить Matrix и увидеть, что хорошо обнаруживает Credential Access, но почти не контролирует Exfiltration.

Это помогает планировать новые Detection Rules.

Log Retention

Retention определяет, как долго SIEM хранит Events.

Если Incident обнаружен через полгода, расследование возможно только при наличии соответствующих исторических данных.

Hot и Cold Storage

Свежие Logs могут храниться в быстром Search Storage, а старые — в более дешевом Archive.

Это позволяет уменьшить стоимость без полного удаления истории.

Стоимость SIEM

Одной из основных статей расходов является объем данных.

Если компания отправляет в SIEM абсолютно все Debug Logs, стоимость Storage и обработки может резко вырасти.

Events per Second

EPS показывает количество Events, поступающих в систему за секунду.

Этот показатель используется при Capacity Planning некоторых SIEM Architectures.

Data Volume

В Cloud SIEM стоимость часто зависит от объема Ingested Data и Retention.

Поэтому важно понимать, какие Logs действительно имеют Security Value.

Что не стоит отправлять в SIEM

Не каждый Application Debug Log нужен Security Team.

Перед подключением Source следует определить Use Cases.

Иначе SIEM превращается в дорогое хранилище данных без практической ценности.

Use Case

Use Case описывает, какую угрозу нужно обнаруживать и какие Sources для этого нужны.

Например:

Use case: SSH brute force
Sources: Linux authentication logs
Rule: many failed logins from one source

Почему начинать нужно с Use Cases

Так команда сначала понимает, какой Security Question хочет решить, и только затем подключает данные.

Это эффективнее стратегии «соберем все логи, а потом разберемся».

Log Source Health

SIEM должна контролировать, продолжают ли Sources отправлять данные.

Если Domain Controller внезапно перестал присылать Events, это может быть как технической ошибкой, так и признаком атаки.

Gap Detection

Monitoring должен создавать Alert, если критичный Source молчит дольше допустимого времени.

Отсутствие событий — тоже важное событие.

Time Synchronization

Все устройства должны иметь корректное время.

Если один Server отстает на 15 минут, Timeline Incident становится трудно восстановить.

Поэтому синхронизация времени через NTP или другой корпоративный механизм критична.

Timestamp

SIEM должна различать время возникновения Event и время его получения.

При сетевой задержке эти значения могут различаться.

SIEM и Compliance

Централизованные Logs помогают подтверждать выполнение требований внутреннего контроля и различных стандартов.

Например, компания может показать историю Administrative Logins и изменения Permissions.

Но сам факт наличия SIEM не означает автоматическое соответствие требованиям.

Audit Trail

Audit Trail позволяет восстановить, кто и когда выполнил действие.

Это важно не только для Security Incident, но и для внутреннего расследования ошибок.

Immutable Logs

Для критичных журналов полезно затруднить незаметное удаление или изменение событий.

Если злоумышленник получил Administrator Access, он может попытаться очистить локальный Log.

Централизованная отправка данных помогает сохранить копию вне скомпрометированного Host.

SIEM и Backup

SIEM не является заменой Backup бизнес-данных.

Она хранит Security Telemetry, а не полноценные копии Database, документов или VM.

SIEM и Observability

Observability Platform и SIEM могут хранить похожие Logs, но решают разные задачи.

Observability ориентирована на Reliability и Performance приложений, а SIEM — на Security Detection и Investigation.

Можно ли использовать одни логи для SIEM и Observability

Да, часть Sources полезна обоим направлениям.

Например, Web Access Logs помогают одновременно искать 5xx Errors и подозрительные Requests.

Но Retention, Permissions и аналитика обычно отличаются.

SIEM и Big Data

Крупная SIEM обрабатывает огромные объемы Events, поэтому использует распределенный Search и Storage.

Производительность зависит от количества Sources, Queries, Detection Rules и Retention.

On-premise SIEM

On-premise решение размещается в инфраструктуре компании.

Организация самостоятельно управляет Compute, Storage, Backup и обновлениями.

Cloud SIEM

Cloud SIEM предоставляется как сервис.

Провайдер управляет значительной частью платформы, а компания подключает Sources и Detection Rules.

On-premise и Cloud SIEM

SIEM и Hybrid Infrastructure

Одна SIEM может одновременно получать Logs из локального дата-центра, Public Cloud и SaaS Applications.

Это особенно важно для компаний с распределенной архитектурой.

SIEM и филиалы

Филиалы могут отправлять Logs в центральный Collector.

При нестабильном WAN полезно иметь локальный Buffer, чтобы события не терялись при временном отключении связи.

High Availability SIEM

Если SIEM недоступна во время Incident, Security Team теряет оперативную видимость.

Для критичной инфраструктуры Collectors, Search и Storage должны иметь достаточную отказоустойчивость.

SIEM как цель атаки

Злоумышленнику выгодно отключить Monitoring или удалить Logs.

Поэтому SIEM Console, Collectors и Service Accounts являются критичными Security Assets.

MFA для SIEM

Administrative Access следует защищать MFA.

Особенно это важно, если SIEM позволяет запускать интегрированные Response Actions.

RBAC

Role-based Access Control разделяет права.

Например, Analyst может выполнять поиск, но не имеет возможности удалять Logs или менять Retention.

Least Privilege

Accounts, которыми SIEM получает данные через API, должны иметь минимально необходимые Permissions.

Read-only доступ обычно безопаснее полного Administrator Access.

Конфиденциальность данных

Logs могут содержать IP Addresses, Usernames, URLs, Email и другие чувствительные данные.

Доступ к SIEM Storage необходимо строго контролировать.

Secrets в логах

Application не должна записывать Passwords, API Tokens и Authorization Headers в Logs.

Если такой Event попадет в SIEM, Secret окажется доступен большему количеству систем и сотрудников.

Masking

Чувствительные поля можно маскировать или исключать перед сохранением.

Например:

card_number=****1234

Это снижает риск утечки через Logging Infrastructure.

SIEM и Incident Response

Во время расследования SIEM помогает ответить на вопросы:

• когда началась атака;
• какой User был затронут;
• с каких IP выполнялись действия;
• какие Hosts участвовали;
• были ли аналогичные события раньше;
• какие Accounts нужно заблокировать.

Timeline Incident

События сортируются по времени:

11:02 phishing email
11:08 user login
11:09 suspicious process
11:11 DNS request
11:12 outbound connection
11:15 admin login

Так аналитик видит развитие атаки.

Root Cause Analysis

SIEM помогает найти первоначальную точку проникновения.

Если просто заблокировать последний вредоносный IP, но не понять, что Credentials украдены через Phishing, Incident может повториться.

SIEM и MTTD

Mean Time to Detect показывает скорость обнаружения Incident.

Хорошая Detection Engineering помогает уменьшить MTTD.

SIEM и MTTR

Mean Time to Respond показывает скорость реакции.

Быстрый поиск контекста и интеграция с SOAR могут уменьшить MTTR.

Detection Engineering

Detection Engineering — системная разработка и тестирование правил обнаружения угроз.

Она включает:

• Use Cases;
• Log Sources;
• Correlation Rules;
• Testing;
• Tuning;
• Coverage Mapping.

Тестирование правил

Правило нельзя считать качественным только потому, что оно сохранено в SIEM.

Нужно проверить, срабатывает ли оно на реальное тестовое событие и какой Alert получает SOC.

Detection as Code

В зрелых командах Detection Rules могут храниться в Version Control и проходить Review.

Это упрощает Audit изменений и Rollback.

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

1. Собирать все Logs без Use Cases.
2. Не контролировать Log Source Health.
3. Не синхронизировать время.
4. Не настраивать Parsers.
5. Создавать слишком много Alerts.
6. Не назначать владельцев Incident.
7. Хранить Secrets в журналах.
8. Не учитывать стоимость Retention.
9. Не тестировать Detection Rules.
10. Считать SIEM автоматической заменой SOC.

SIEM без SOC

SIEM может создавать Alerts круглосуточно, но если никто их не анализирует, реальная эффективность будет низкой.

Нужны внутренний SOC, дежурная Security Team или MDR/MSSP модель.

Почему установка SIEM не означает защиту

SIEM — инструмент Detection и Investigation.

Она не исправляет Vulnerabilities и не блокирует Malware автоматически без дополнительных интеграций.

Нужны процессы Response и другие Security Controls.

Как внедрить SIEM

Шаг 1. Определить Use Cases

Начните с конкретных угроз, которые хотите обнаруживать.

Шаг 2. Выбрать Sources

Подключайте только данные, необходимые для этих сценариев.

Шаг 3. Настроить Parsing

Проверьте корректность User, IP, Host и Timestamp.

Шаг 4. Создать Detection Rules

Правила должны соответствовать реальной инфраструктуре.

Шаг 5. Настроить Tuning

Уменьшите False Positives без создания слепых зон.

Шаг 6. Определить Response

Каждый Critical Alert должен иметь владельца и понятный Playbook.

Шаг 7. Контролировать Sources

SIEM должна замечать пропавшие Logs.

Шаг 8. Регулярно пересматривать Coverage

Новые Cloud Services и Servers нужно включать в Monitoring.

Практический пример

Сотрудник компании получает Phishing Email и вводит корпоративный Password на поддельном сайте.

Через несколько минут VPN Gateway фиксирует успешный Login с нового IP.

Затем Windows Server регистрирует RDP Login этой же Account, а EDR замечает запуск PowerShell.

Firewall фиксирует соединение с подозрительным внешним Domain.

Все события попадают в SIEM:

Email alert
↓
VPN login
↓
RDP session
↓
PowerShell
↓
External connection

Correlation Rule связывает User и временной интервал и создает Critical Incident.

SOC Analyst видит полную цепочку, блокирует Account, изолирует Endpoint через EDR и проверяет, использовались ли те же Credentials на других Servers.

После Incident команда добавляет новое Detection Rule и проверяет, какие еще пользователи получили такое же Phishing Email.

Так SIEM превращает отдельные Logs из разных систем в единую картину атаки.

SIEM для бизнеса

Для бизнеса SIEM особенно важна в инфраструктуре с большим количеством серверов, удаленных сотрудников, Cloud Services и средств защиты.

Она дает единое место для мониторинга Security Events и помогает сократить время расследования.

При этом эффективность зависит не от количества собранных гигабайтов, а от качества Use Cases, Detection Rules и процесса Response.

Преимущества SIEM

• централизованный сбор Logs;
• поиск по всей инфраструктуре;
• корреляция Events;
• Threat Hunting;
• Audit Trail;
• Compliance Reporting;
• Incident Investigation;
• интеграция с SOC и SOAR.

Ограничения SIEM

• требует качественных Log Sources;
• может быть дорогой при большом Data Volume;
• нуждается в постоянном Tuning;
• не гарантирует Detection всех атак;
• не заменяет EDR, Firewall и Backup;
• нуждается в специалистах для анализа Alerts;
• некачественные Parsers снижают ценность данных.

Когда SIEM особенно нужна

SIEM становится особенно полезной, когда количество систем уже не позволяет расследовать Incidents вручную по отдельным Logs.

Это типичная ситуация для среднего и крупного бизнеса, дата-центров, финансовых организаций, Cloud Infrastructure и компаний с формализованными требованиями к Security Monitoring.

Связанные термины

Краткий итог

SIEM — система централизованного сбора, хранения и анализа событий информационной безопасности. Она объединяет Logs серверов, сетевых устройств, приложений, EDR, Cloud и Identity Systems в едином поисковом и аналитическом пространстве.

Главная функция SIEM — Correlation. Она помогает увидеть связь между событиями, которые по отдельности могут не выглядеть критичными: Phishing, необычный Login, запуск подозрительного Process и внешнее сетевое соединение.

SIEM не является самостоятельной защитой от всех атак. Для эффективной работы нужны качественные Log Sources, настроенные Detection Rules, контроль Retention и команда SOC или MDR, которая анализирует Alerts и выполняет Response.