Як зрозуміти, що ваша SIEM-система налаштована неправильно

SIEM встановлена, логи збираються, дашборди працюють, а SOC щодня отримує сотні або навіть тисячі сповіщень. Формально система функціонує. Але чи означає це, що вона справді допоможе виявити атаку?

Не обов'язково.

Одна з головних проблем SIEM полягає в тому, що саме по собі впровадження платформи не забезпечує ефективного моніторингу безпеки. Якщо джерела даних підключені неправильно, detection rules не відповідають реальній інфраструктурі, а аналітики перевантажені false positives, критична активність може загубитися серед інформаційного шуму.

Розглянемо основні ознаки того, що ваша SIEM-система налаштована неправильно, і що потрібно перевірити.

Що означає «правильно налаштована SIEM»?

SIEM (Security Information and Event Management) централізовано збирає та аналізує події безпеки з різних джерел: серверів, endpoint-рішень, Active Directory, firewall, VPN, Microsoft 365, cloud-середовищ, applications, мережевого обладнання та інших систем.

Але збір логів — лише частина роботи SIEM.

Правильно налаштована система повинна допомагати відповісти щонайменше на три питання:

Що сталося? Наскільки це небезпечно? Що потрібно зробити?

Якщо SIEM лише накопичує дані та генерує alerts без достатнього контексту, її практична цінність для detection and response суттєво знижується.

1. SIEM генерує занадто багато alerts

Одна з найочевидніших ознак проблеми — SOC буквально потопає в сповіщеннях.

Сотні alerts самі по собі не означають, що SIEM добре контролює інфраструктуру. Навпаки, велика кількість низькоякісних сповіщень може призвести до alert fatigue — ситуації, коли аналітики перестають приділяти достатню увагу кожному сигналу.

Наприклад, SIEM може створювати alert після кожної невдалої авторизації.

Одна неправильна спроба введення пароля — звичайна подія. Але 50 невдалих входів за короткий час із різних IP-адрес або послідовність failed login → successful login → privilege escalation вже може бути значно цікавішою для SOC.

Правильно налаштований detection повинен враховувати контекст, частоту, послідовність і ризик подій, а не просто перетворювати кожен event на alert.

2. Більшість alerts — false positives

False positives неможливо повністю усунути. Але якщо аналітики постійно закривають одні й ті самі alerts зі статусом «не інцидент», це сигнал, що detection logic потребує перегляду.

Причини можуть бути різними:

занадто широкі правила;

неправильні thresholds;

відсутність exceptions;

невраховані легітимні administrative activities;

неправильний parsing;

rules, які не адаптовані до конкретного середовища.

Наприклад, security rule може реагувати на використання PowerShell. Але PowerShell регулярно використовують системні адміністратори та автоматизовані процеси.

Якщо SIEM не враховує користувача, endpoint, команду, час виконання та інший контекст, SOC може отримувати десятки непотрібних alerts.

Результат — аналітики витрачають час на шум замість реальних загроз.

3. SIEM збирає не всі потрібні логи

Ще одна поширена проблема — компанія вважає, що «всі логи вже в SIEM», хоча критичні джерела telemetry фактично відсутні.

Наприклад, можуть збиратися Windows events та firewall logs, але не надходити:

1. Microsoft 365 audit logs;
2. VPN logs;
3. EDR telemetry;
4. DNS logs;
5. authentication events;
6. cloud audit logs;
7. logs критичних applications;
8. privileged access events;
9. email security events.

У результаті SIEM бачить лише частину атаки.

Особливо небезпечно, коли джерело формально підключене, але перестало передавати події. Якщо немає контролю log source health, команда може дізнатися про це лише під час інциденту.

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

4. SIEM збирає занадто багато непотрібних даних

Протилежна проблема — збирати все.

На перший погляд логіка проста: що більше logs, то краща visibility.

На практиці це не завжди так.

Безконтрольний ingestion може збільшувати витрати на ліцензування, storage та infrastructure, створювати додаткове навантаження і ускладнювати пошук важливих подій.

Питання повинно звучати не:

«Скільки логів ми можемо зібрати?»

а:

«Які дані потрібні нам для виявлення конкретних сценаріїв атак і розслідування інцидентів?»

Log management має будуватися навколо security use cases, а не принципу «збираємо все про всяк випадок».

5. Detection rules не відповідають реальним загрозам

SIEM часто постачається з набором готових правил.

Це хороша стартова точка, але не готова detection strategy.

Компанії мають різні технології, бізнес-процеси, користувачів, attack surface та threat model. Правило, критичне для банку, може бути майже нерелевантним для SaaS-компанії — і навпаки.

Detection rules повинні відповідати реальним сценаріям атак.

Наприклад:

чи виявить SIEM password spraying?

чи помітить створення нового privileged account?

чи побачить нетиповий вхід адміністратора?

чи виявить credential dumping?

чи зафіксує відключення security controls?

чи побачить lateral movement?

чи виявить підозрілу активність у Microsoft 365?

Якщо відповідь невідома, наявність сотень активних rules ще нічого не говорить про реальну detection coverage.

6. Правила SIEM давно не переглядалися

IT-інфраструктура постійно змінюється.

З'являються нові servers, cloud services, SaaS applications, VPN, endpoints та identity systems. Змінюються IP-адреси, групи користувачів, адміністративні процеси та сама поведінка співробітників.

Якщо detection rules були налаштовані під час впровадження SIEM кілька років тому і після цього майже не переглядалися, частина з них може бути неефективною.

Одні правила генеруватимуть зайвий шум.

Інші перестануть працювати.

А для нових систем detection взагалі може бути відсутній.

SIEM tuning — це постійний процес, а не одноразовий етап впровадження.

7. SIEM бачить окремі події, але не бачить атаку

Сильна SIEM повинна не тільки реагувати на окремі events, а й допомагати встановлювати зв'язок між ними.

Уявімо такий сценарій:

користувач входить у Microsoft 365 з незвичної локації;

через кілька хвилин змінюються налаштування акаунта;

потім створюється нове правило forwarding;

після цього відбувається доступ до великої кількості повідомлень.

Кожна подія окремо може не мати критичного severity.

Але разом вони можуть вказувати на account compromise.

Якщо SIEM не корелює пов'язані події, SOC доводиться вручну збирати картину інциденту з десятків alerts.

8. Усі alerts мають майже однаковий пріоритет

Якщо SOC бачить сотні High або Critical alerts щодня, саме поняття «критичний» швидко втрачає сенс.

Severity повинна враховувати не тільки тип події, а й контекст.

Наприклад, одна й та сама підозріла активність на тестовій машині та на Domain Controller не обов'язково має створювати однаковий ризик.

На пріоритет можуть впливати:

критичність asset;

тип користувача;

рівень привілеїв;

наявність відомої вразливості;

попередня активність;

threat intelligence;

кількість пов'язаних detections.

Це дозволяє SOC концентруватися на подіях із найбільшим реальним ризиком.

9. Ніхто не знає, що робити після alert

Навіть ідеальний detection мало допомагає, якщо після нього немає зрозумілого процесу реагування.

Для критичних use cases повинні існувати зрозумілі процедури.

Хто перевіряє alert? Які дані потрібно зібрати? Коли подія стає incident? Кому її ескалювати? Коли потрібно заблокувати account або ізолювати endpoint?

Якщо кожен аналітик вирішує це самостійно, response залежить від конкретної людини та зміни.

SIEM тому потрібно пов'язувати з incident response process, playbooks і, де це доцільно, SOAR.

10. SIEM не інтегрована з іншими security-рішеннями

SIEM рідко працює ефективно як ізольований продукт.

Для повноцінного контексту їй можуть бути потрібні дані з EDR/XDR, NDR, firewall, IDS/IPS, PAM, DLP, vulnerability management, threat intelligence, identity та cloud platforms.

Наприклад, SIEM бачить підозрілу authentication activity.

Якщо вона також отримує endpoint telemetry, vulnerability context та інформацію про asset criticality, аналітик може значно швидше оцінити ризик.

Інтеграція потрібна не заради кількості джерел. Її задача — дати SOC контекст для прийняття рішення.

11. Detection rules ніхто не тестує

Це одна з найбільш недооцінених проблем.

Правило існує. Воно enabled. Воно красиво описане в документації.

Але чи спрацює воно під час реальної атаки?

Дізнатися це тільки після інциденту — поганий сценарій.

Detection rules потрібно регулярно перевіряти контрольованими сценаріями атак. Для цього можуть використовуватися penetration testing, Purple Team exercises або Breach and Attack Simulation (BAS).

Наприклад, команда може емулювати певну техніку MITRE ATT&CK і перевірити весь ланцюжок:

атака → telemetry → SIEM → detection rule → alert → SOC response.

Якщо атака була виконана, але SIEM не створила очікуваний alert, потрібно визначити, де саме виник detection gap.

12. SIEM не прив'язана до MITRE ATT&CK або іншої моделі detection coverage

Кількість rules — погана метрика ефективності SIEM.

500 правил не обов'язково краще за 100.

Значно корисніше розуміти, які техніки та сценарії атак компанія здатна виявити.

MITRE ATT&CK може використовуватися як одна з моделей для такого mapping.

Наприклад, можна перевірити coverage для:

Initial Access → Execution → Persistence → Privilege Escalation → Credential Access → Discovery → Lateral Movement → Exfiltration.

Це допомагає побачити прогалини.

Компанія може дуже добре виявляти malware execution, але практично не мати detections для credential access або lateral movement.

Саме такі gaps часто залишаються непомітними, якщо оцінювати SIEM тільки за кількістю alerts.

Як перевірити, чи правильно налаштована SIEM?

Найкращий спосіб — не дивитися лише на dashboards та кількість активних rules, а провести комплексну перевірку.

Вона має охоплювати джерела логів, parsing і normalization, detection rules, correlation, false positives, use cases, MITRE ATT&CK coverage, alert prioritization, integrations та incident response.

Після цього варто перейти від теоретичної оцінки до практичної.

Виберіть кілька критичних attack scenarios і перевірте, чи SIEM справді їх виявляє.

Наприклад:

Password spraying → чи буде alert?

Створення privileged account → чи буде alert?

Credential dumping → чи буде alert?

Lateral movement → чи буде alert?

Відключення EDR → чи буде alert?

Підозрілий PowerShell → чи буде alert?

Microsoft 365 account compromise → чи буде alert?

Такий тест дає значно більше інформації про реальний стан SIEM, ніж кількість events per second або красивий SOC dashboard.

SIEM працює — але чи працює detection?

Це головне питання, яке варто поставити.

SIEM може технічно працювати бездоганно: отримувати мільйони events, зберігати logs і показувати десятки dashboards.

Але мета SIEM — не зберігати якомога більше даних.

Мета — допомогти вчасно виявити реальну загрозу та надати достатньо інформації для реагування.

Тому ефективність SIEM краще оцінювати через detection coverage, якість alerts, false positive rate, час виявлення, доступність потрібної telemetry та здатність SOC відреагувати на інцидент.

Коли потрібен аудит SIEM?

Перевірка особливо актуальна, якщо SIEM працює вже кілька років без системного tuning, кількість false positives постійно зростає, SOC перевантажений alerts або в інфраструктурі відбулися значні зміни.

Ще один очевидний сигнал — реальний інцидент, який SIEM не виявила або виявила занадто пізно.

Але чекати такого моменту не варто.

Періодична оцінка SIEM дозволяє знайти detection gaps до того, як ними скористається атакуючий.

Висновок

Неправильно налаштована SIEM не обов'язково виглядає зламаною.

Навпаки — вона може щодня отримувати мільйони logs, генерувати тисячі alerts і мати десятки активних dashboards.

Основні проблеми проявляються інакше: занадто багато false positives, відсутні критичні log sources, застарілі detection rules, слабка кореляція, неправильна пріоритизація та невідомий detection coverage.

Тому головна метрика — не кількість зібраних logs або створених alerts.

Поставте простіше питання:

якщо атака почнеться сьогодні, чи побачить її ваша SIEM?

Якщо на нього немає впевненої відповіді, систему варто перевірити.

FAQ

Чому SIEM генерує багато false positives?

Найчастіші причини — занадто широкі detection rules, неправильні thresholds, відсутність exceptions, недостатній контекст та rules, які не були адаптовані до конкретної IT-інфраструктури. Регулярний SIEM tuning допомагає зменшити кількість непотрібних alerts.

Як часто потрібно переглядати правила SIEM?

Detection rules потрібно переглядати регулярно та після суттєвих змін інфраструктури, появи нових систем, зміни threat landscape або виявлення нових attack scenarios. SIEM tuning має бути постійним процесом.

Як перевірити, чи SIEM виявляє реальні атаки?

Один зі способів — виконувати контрольовану емуляцію attack techniques та перевіряти весь detection chain: чи з'явилася потрібна telemetry, чи потрапила вона в SIEM, чи спрацювало правило і чи отримав SOC коректний alert. Для цього можуть застосовуватися BAS, Purple Teaming та інші security validation підходи.

Чи потрібно збирати в SIEM усі можливі логи?

Не обов'язково. Пріоритет потрібно віддавати telemetry, яка потрібна для security monitoring, detection use cases, incident investigation та compliance. Безконтрольний збір даних може збільшувати витрати й шум без пропорційного покращення detection.

Чи достатньо стандартних SIEM rules?

Зазвичай ні. Вбудовані правила є хорошою базою, але їх потрібно адаптувати до технологій, користувачів, активів, threat model та нормальної поведінки конкретної організації.