Эффективность SOC определяет не факт внедрения SIEM, а качество её настройки. На основе анализа реальных инцидентов выделяем 10 повторяющихся ошибок: от отсутствия модели угроз до игнорирования облачных журналов и автоматизации реагирования.
- 1. Введение
- 2. Ошибка 1. SIEM фиксирует события, но не распознаёт атаку как процесс
- 3. Ошибка 2. Сбор всех доступных логов без стратегии приоритизации
- 4. Ошибка 3. Несоответствие возможностей SIEM и зрелости команды SOC
- 5. Ошибка 4. Сбой в этапах парсинга и нормализации логов
- 6. Ошибка 5. Использование типовых правил корреляции без адаптации к среде
- 7. Ошибка 6. Нет валидации и обновления правил детектирования
- 8. Ошибка 7. Фрагментарный сбор данных: игнорирование ключевых источников логов
- 9. Ошибка 8. Игнорирование облачных журналов и SaaS‑логов
- 10. Ошибка 9. Отсутствие интеграции SIEM с системами реагирования (SOAR)
- 11. Ошибка 10. Провалы в управлении идентификацией и доступом (IAM)
- 12. Выводы
Введение
Российский рынок систем управления событиями и инцидентами информационной безопасности (Security Information and Event Management, SIEM) переживает парадоксальный момент.
С одной стороны, на фоне усиления регуляторного давления (Приказ ФСТЭК № 117) растут инвестиции в импортозамещения технологий и создание центров мониторинга безопасности (Security Operations Center, SOC). С другой — способность организаций реально обнаруживать современные многоэтапные атаки зачастую остаётся на критически низком уровне.
В 2026 году ожидается рост успешных атак примерно на 30 %: злоумышленники активно применяют ИИ для планирования, автоматизации и обхода статичных защитных механизмов, а также используют легитимные инструменты системы (LOTL — living-off-the-land) для скрытного продвижения по инфраструктуре.
Исследования показывают, что от 60 % до 85 % всех оповещений в типичном SOC составляют ложные срабатывания. При этом злоумышленники могут оставаться незамеченными в инфраструктуре неделями и даже месяцами, методично продвигаясь к целям.
Парадокс «SIEM есть, а обнаружения нет» объясняется не столько несовершенством технологий, сколько ошибками архитектуры, логики и процессов, заложенных на этапе внедрения и эксплуатации. Как показывает практика, большинство таких провалов можно свести к 10 типовым ошибкам, повторяющимся от проекта к проекту.
Ошибка 1. SIEM фиксирует события, но не распознаёт атаку как процесс
На практике внедрение SIEM часто ограничивается формальным подключением источников логов и активацией стандартного набора правил корреляции. Система исправно генерирует оповещения (алерты), но не видит целостную картину атаки.
SOC реагирует на отдельные сигналы — аномальный HTTP‑запрос, подозрительный процесс, нетипичное подключение — не связывая их в единый сценарий. В результате атаки обнаруживаются на поздних этапах, когда ущерб уже нанесён.
Исследования подтверждают разрыв между формальным покрытием и реальной эффективностью. По данным CardinalOps (2025) корпоративные SIEM детектируют лишь около 21 % техник MITRE ATT&CK, даже при наличии нужных источников.
Тестирование SOC с использованием симуляций атак показывает схожую картину. По данным Picus Blue Report 2025, только 1 из 7 многоэтапных атак приводит к генерации алерта.
Почему это происходит? Распространённая методологическая ошибка — воспринимать MITRE ATT&CK как «чек-лист защиты». ATT&CK описывает поведение злоумышленников, но не заменяет модель угроз и архитектуру SOC. Она не отвечает на ключевые вопросы: кто является вероятным противником, какие активы для него приоритетны и на каком этапе атака должна быть выявлена?
Без этих ответов система проектируется по принципу снизу вверх (Bottom-Up): подключаются все доступные источники логов, активируется типовой контент, алерты формально сопоставляются с MITRE ATT&CK. Система работает, но практической ценности для SOC не даёт.
Это особенно критично для продвинутых угроз. Группы уровня расширенной постоянной угрозы (Advanced Persistent Threat, APT) маскируются под легитимную активность. Они используют украденные учётные данные и штатные инструменты администрирования — PowerShell, протокол удалённого рабочего стола (Remote Desktop Protocol, RDP), инструментарий управления Windows (Windows Management Instrumentation, WMI). Такие действия выглядят как легитимные и легко теряются в общем потоке событий.
Пример ошибки: эксплуатация CVE-2023-20887 в VMware Aria Operations for Networks
Уязвимость CVE-2023-20887 (оценка по шкале CVSS 3.1 — 9,88) — пример того, как отсутствие сценарного подхода лишает SOC контекста атаки. Ошибка валидации входных данных в интерфейсе программирования приложений (Application Programming Interface, API) и особенности конфигурации прокси-сервера позволяли выполнять удалённый код без аутентификации с привилегиями root.
Без сценарной корреляции эти сигналы выглядели как несвязанные аномалии: необычные HTTP-запросы к уязвимому API, запуск нетипичных процессов на сервере приложения и последующие подключения с этого узла к внутренним ресурсам.
Однако при наличии сценария использования (Use Case), построенного сверху вниз — от модели угроз к цепочке атаки — они складывались бы в единый процесс, отражённый в MITRE ATT&CK:
T1190 (Initial Access): эксплуатация публичного приложения через HTTP-запрос к уязвимому API.
T1059 (Execution): выполнение инжектированных команд.
T1046, T1021 (Discovery / Lateral Movement): сканирование доступных сервисов и использование удалённых сервисов для перемещения по сети.
Чем опасна эта ошибка
Если система не распознаёт атаку как процесс, SOC реагирует слишком поздно — на этапах бокового перемещения (lateral movement) или нанесения ущерба. Это увеличивает время присутствия злоумышленника в инфраструктуре, масштабирует последствия инцидента и фактически превращает SIEM в дорогостоящий архив логов.
Избежать ошибки можно при проектировании платформы сверху вниз (Top-Down): от модели угроз и критичных активов — к сценариям атак, необходимым источникам данных и проверяемым правилам корреляции.
Ошибка 2. Сбор всех доступных логов без стратегии приоритизации
Эта ошибка логически продолжает предыдущую. Когда в компании нет модели угроз и понимания, какие сценарии атак для неё критичны, возникает иллюзия, что стратегия «собрать всё» повышает уровень безопасности.
На практике она приводит к обратному эффекту. SIEM поглощает миллионы низкоценностных событий: служебные heartbeat-сообщения, отладочные логи приложений, телеметрию оборудования, вспомогательные события облачных платформ. Формально система работает, но способность выявлять реальные угрозы снижается: цепочки действий злоумышленника растворяются в шуме, а SOC тратит ресурсы на фильтрацию фона вместо анализа атак.
Корень проблемы — отсутствие стратегии приоритизации логов:
- какие источники данных важны для обнаружения атак;
- какие события должны анализироваться в режиме, близком к реальному времени;
- какие логи необходимы для корреляции, а какие — преимущественно для расследований;
- какие данные следует агрегировать или нормализовать, а какие — исключать;
- для выявления каких конкретных тактик, техник и процедур (Tactics, Techniques and Procedures, TTPs) из модели угроз требуется данный источник логов.
Без этих решений SIEM либо не выявляет значимые инциденты, либо генерирует множество низкоприоритетных оповещений.
Пример ошибки: утечка данных банка Capital One
Инцидент с Capital One в 2019 году показал последствия отсутствия приоритизации логов. Злоумышленница Пейдж Томпсон, бывшая сотрудница Amazon Web Services (AWS), получила несанкционированный доступ к облачной инфраструктуре банка через уязвимость типа подделки серверного запроса (Server-Side Request Forgery, SSRF) и ошибочную конфигурацию веб-экрана (Web Application Firewall, WAF).
Это позволило ей обратиться к службе метаданных экземпляра AWS и получить временные учётные данные. Далее с помощью интерфейса командной строки AWS (AWS Command Line Interface, AWS CLI) были выполнены действия по разведке, чтению содержимого более чем 700 хранилищ Simple Storage Service (S3) и эксфильтрации около 30 ГБ данных.
Все ключевые этапы атаки были зафиксированы в журналах AWS CloudTrail. Capital One собирал CloudTrail-логи в полном объёме — десятки миллионов событий в сутки.
Однако критическая последовательность действий не была выделена как приоритетный сценарий: события не имели контекста риска и затерялись в массиве телеметрии. В итоге инцидент обнаружили не средства SIEM, а сторонний исследователь, заметивший украденные данные в GitHub.
Чем опасна эта ошибка
При отсутствии приоритизации логов SIEM перестаёт выделять значимые сигналы и перегружает SOC фоновыми событиями. Аналитики работают в режиме постоянной фильтрации шума, теряя чувствительность к слабым, но критически важным признакам угрозы.
В такой среде атаки обнаруживаются на поздних стадиях, злоумышленник успевает закрепиться в инфраструктуре, утечки данных выявляются постфактум.
Это одна из ключевых ошибок в «10 заповедях SIEM». Стратегия «собрать всё» создаёт иллюзию контроля, но на деле увеличивает стоимость владения системой и снижает её реальную эффективность.
Рисунок 1. Схема атаки через SSRF и доступ к данным в AWS S3 при ошибке WAF
Ошибка 3. Несоответствие возможностей SIEM и зрелости команды SOC
Покупка передовой SIEM‑платформы с модулями анализа поведения пользователей и сущностей (User and Entity Behavior Analytics, UEBA) и компонентами машинного обучения (Machine Learning, ML) сама по себе не создаёт эффективный SOC.
Современная SIEM — это сложная инженерная среда, которая требует постоянной эксплуатации: контроля источников логов и коннекторов, настройки аналитических процессов, обучения UEBA/ML‑модулей на исторических данных. Без этого события фиксируются, но остаются непонятыми.
Основные операционные разрывы проявляются в неспособности адаптировать детектирующую логику под реальную ИТ‑среду (DevOps, CI/CD, бизнес‑приложения), пассивном отношении к источникам данных и формальной эксплуатации аналитических модулей.
Ситуацию усугубляет кадровый дефицит на российском рынке SOC‑эксплуатации. Новые решения внедряются быстрее, чем формируются компетенции. Компании вынуждены выбирать между длительным выращиванием своей команды и передачей эксплуатации внешнему провайдеру (Managed Security Service Provider, MSSP).
В 2026 году ключевым становится не выбор инструментов, а эффективная эксплуатация. Даже современные SIEM с ИИ-ассистентами требуют квалифицированных аналитиков для их настройки и интерпретации результатов.
Пример ошибки: компрометация серверов CI/CD JetBrains TeamCity (CVE-2023-42793)
Критическая уязвимость обхода аутентификации в JetBrains TeamCity стала в 2023 году одним из наиболее опасных инструментов атак на цепочки поставок программного обеспечения. Уязвимость с оценкой CVSS 9.8 позволяла злоумышленнику с сетевым доступом получить полный административный контроль над сервером.
При стандартной настройке SIEM фиксировала разрозненные события: создание привилегированных пользователей, изменения конфигураций сборок, запуск нестандартных процессов (cmd.exe, bash, curl) от имени службы TeamCity, исходящие соединения на подозрительные внешние ресурсы.
Без понимания контекста CI/CD эти события выглядели как набор операционных аномалий. Однако в терминах MITRE ATT&CK они формировали чёткую цепочку атаки: эксплуатация публичного приложения (T1190) → создание учётной записи (T1136) → выполнение команд (T1059) → компрометация цепочки поставок (T1195).
Чем опасна эта ошибка
Несоответствие возможностей SIEM и зрелости SOC приводит к тому, что даже технологически совершенная платформа не выполняет главную функцию — раннее и точное обнаружение атак. Система фиксирует события, но не интерпретирует их в контексте бизнес‑процессов, а аналитики не могут отличить норму от злонамеренной активности.
В итоге атаки выявляются на поздних стадиях, когда злоумышленник уже закрепился в инфраструктуре. Критичные бизнес‑системы (CI/CD, ERP, облако) становятся точками входа для атак на цепочки поставок, SOC теряет контроль над инцидентом, а бизнес‑ущерб многократно возрастает.
Ошибка 4. Сбой в этапах парсинга и нормализации логов
Подключение источников логов само по себе не обеспечивает детектирование угроз. Ключевым этапом становится преобразование сырых, часто неструктурированных событий в нормализованные записи с единой схемой данных.
Парсинг извлекает из лога структурированные поля: IP‑адреса, имена пользователей, временные метки, параметры процессов. Нормализация приводит эти поля к общей модели, чтобы SIEM могла сопоставлять события из разных систем и использовать их в корреляции, UEBA‑моделях и сценариях автоматизации реагирования (Security Orchestration, Automation and Response, SOAR).
Без корректной настройки этих этапов SIEM получает поток разнородных событий, непригодных для анализа. Один и тот же атрибут может приходить под разными именами: пользователь — user, actor.alternateId, sAMAccountName; идентификатор процесса — pid, ProcessId, event.process.pid; командная строка — cmdline, CommandLine, process.args.
Для аналитика это очевидные эквиваленты, но для SIEM без нормализации — разные поля, которые не связываются между собой. Платформа не может определить, что события от VPN‑шлюза, EDR‑агента и системы управления учётными записями относятся к одной сессии пользователя.
Задачу усложняют современные форматы логов: вложенные JSON‑структуры (например, VK Cloud и Yandex Cloud), нестандартизированные форматы отечественного ПО, различия между аудитом Windows, Sysmon, Linux auditd и событиями от российских EDR‑агентов. Ошибка в парсере легко приводит к потере критичных полей (cmdline, parentpid, user, sessionid), что делает невозможным построение цепочек процессов, выявление атак с использованием LOTL‑инструментов и сопоставление активности между локальными и облачными системами.
Пример ошибки: компрометация поддержки Okta (Lapsus$)
В январе 2022 года группа Lapsus$ получила доступ к рабочей станции подрядчика Sitel, обслуживающего Okta. Через удалённую сессию злоумышленники взаимодействовали с Okta Admin Console от имени сотрудника поддержки, выполняли операции с учётными записями, факторами многофакторной аутентификации и настройками политик.
Эта активность фиксировалась в нескольких независимых системах: в журналах Okta (client.ipAddress), на прокси‑сервере подрядчика (srcip, c-ip), на VPN‑шлюзе (remote_addr), в системах контроля доступа (ipsource).
При отсутствии единой схемы нормализации SIEM не смогла связать эти события в единую сессию. Попытки сброса MFA, изменения политик и входы в систему единого входа выглядели как разрозненные аномалии низкого приоритета. Корреляция по сценарию «доступ к админ‑панели → изменение политик → операции с MFA» не сработала, хотя все данные присутствовали в логах. О компрометации стало известно только после публикации скриншотов Lapsus$ в Telegram.
Чем опасна эта ошибка
Некорректная нормализация делает SIEM слепой даже при полном покрытии логами. События фиксируются, но не связываются в цепочку атаки, и перемещение злоумышленника внутри инфраструктуры остаётся незамеченным.
Модели UEBA и сценарии SOAR работают некорректно. Среднее время расследования угроз растёт — аналитики вручную сопоставляют события из разных систем.
Так атаки на цепочки поставок, компрометация привилегированных учётных записей и сложные многоэтапные сценарии проходят мимо, хотя данные формально присутствуют в SIEM.
Ошибка 5. Использование типовых правил корреляции без адаптации к среде
Большинство коммерческих SIEM‑платформ поставляются с предустановленным набором правил корреляции и сценариев обнаружения «из коробки» (Out‑of‑the‑Box, OOTB). Они рассчитаны на усреднённую инфраструктуру и служат лишь отправной точкой.
Применение таких правил без адаптации к модели угроз, архитектуре, бизнес‑процессам и практикам DevOps — системная ошибка. SIEM либо генерирует массу ложных срабатываний (до 70 % времени аналитиков уходит на их разбор), либо пропускает критичные действия, маскирующиеся под нормальные операции.
Особенно уязвимы инфраструктуры с активным использованием PowerShell, CI/CD, удалённого администрирования и сервисных учётных записей. В таких условиях типовое правило «запуск PowerShell» бесполезно. Без анализа контекста (учётная запись, узел, параметры, время) SOC перегружается шумом, а вредоносная активность теряется.
Отсутствие базовой линии нормального поведения делает даже формально корректные правила неэффективными. Для аттестованных систем (ГИС, КИИ, ИСПДн) базовая линия и модель угроз должны опираться на Банк данных угроз (БДУ) ФСТЭК. Использование OOTB‑правил без привязки к угрозам из БДУ может рассматриваться как формальность и приводить к несоответствию регуляторным требованиям.
Пример ошибки: FIN7 и кампании с использованием инструментария Carbanak
В ряде атак группа FIN7 (Carbon Spider, Sangria Tempest), применявшая инструментарий Carbanak, задействовала легитимные компоненты Windows — встроенные утилиты (rundll32.exe, regsvr32.exe, mshta.exe) и стандартные административные механизмы. Внешне их действия выглядели как обычная работа администраторов или систем автоматизации.
Во многих организациях SIEM реагировала на сами факты запуска этих утилит, но не анализировала контекст: удалённые URL, нетипичные имена задач планировщика, обфусцированные скрипты. В результате типовые правила либо отключались как «шумные», либо не позволяли отличить вредоносную активность от легитимной.
Чем опасна эта ошибка
Использование OOTB‑правил без адаптации снижает операционную эффективность SOC и повышает риск пропуска целевых атак. Для аттестованных систем это также создаёт риски формального несоответствия регуляторным требованиям.
Эффективная эксплуатация SIEM требует постоянной адаптации правил под конкретную инфраструктуру и преобразования статичных сигнатур в контекстно‑зависимые сценарии обнаружения, основанные на тактиках и техниках противника.
Рисунок 2. Тактики и методы, используемые Carbanak и FIN7 по данным MITRE (Источник: Carbanak and FIN7 Attack Techniques | Trend Micro (US))
Ошибка 6. Нет валидации и обновления правил детектирования
В ряде SOC управление правилами детектирования строится по принципу «написали — включили — забыли». После первоначальной разработки корреляций или сигма‑правил они годами не пересматриваются. Между тем источники логов меняют формат, инфраструктура уходит в облако, а тактики противника эволюционируют. В итоге правила опираются на устаревшие модели данных, и их реальная эффективность неизвестна.
Отчёт CardinalOps (2025) показывает, что в среднем 13 % правил детектирования неработоспособны — из‑за устаревших полей, отключённых источников и других ошибок. Формально они есть, но фактически не участвуют в обнаружении атак, создавая опасные «слепые зоны».
Полноценный жизненный цикл детектора включает: формулировку гипотезы (какую технику нужно выявить), разработку правила с привязкой к источникам логов, тестирование на реальных данных, ввод в эксплуатацию, мониторинг срабатываний и регулярный пересмотр. Без этого правила перестают работать при любых изменениях в инфраструктуре.
Пример ошибки: эволюция тактик группы APT29 (Cozy Bear / NOBELIUM)
APT29 — пример противника, чьи тактики постоянно менялись. От классического фишинга и компрометации почтовых систем группа перешла к атакам на цепочки поставок (SolarWinds), а затем — к операциям против облачной идентификации: Azure AD, OAuth‑приложений, SAML‑токенов и внешних федераций.
Во многих компаниях правила по APT29 создавались ещё в эпоху on‑prem Active Directory и ориентировались на старые техники: вложения с макросами, аномальные входы в OWA, подозрительные процессы на почтовых серверах.
Эти правила продолжали числиться как покрытие по MITRE ATT&CK, но не учитывали новые векторы — атаки на цепочки поставок, злоупотребление доверенными отношениями, подделку SAML‑токенов, кражу refresh‑токенов и использование облачных API для перемещения.
Организации, которые не обновляли детекторы, сохраняли иллюзорное покрытие: SIEM «видела» только устаревшие техники, оставаясь слепой к актуальным TTP. В отчётах по ATT&CK такие компании показывали высокий процент покрытия, но при моделировании современных атак APT29 правила не срабатывали — события из Azure AD, облачных журналов и систем федерации просто не учитывались.
Чем опасна эта ошибка
Отсутствие жизненного цикла правил делает работу SOC формальной: модель угроз существует на бумаге, но реальное обнаружение атак ей не соответствует. Часть правил не срабатывает, часть устарела, часть не подходит к текущей архитектуре.
Без регулярной проверки через имитацию атак (purple teaming, BAS‑платформы, ручные упражнения) невозможно понять, какие правила действительно работают, а какие создают шум или давно «мертвы».
При реальной угрозе с новыми TTP система не срабатывает, хотя формально покрытие заявлено. Время обнаружения и реагирования растёт, а злоумышленник получает возможность закрепиться в инфраструктуре и развивать атаку незаметно.
Ошибка 7. Фрагментарный сбор данных: игнорирование ключевых источников логов
Многие проекты внедрения SIEM ограничиваются подключением базовых и «удобных» источников: сетевых устройств, журналов операционных систем, прокси. При этом игнорируются критически важные для обнаружения современных атак данные:
- системы обнаружения и реагирования на конечных точках (Endpoint/Extended Detection and Response, EDR/XDR);
- логи систем предотвращения утечек данных (Domain Name System, DNS);
- системы управления идентификацией и доступом (Identity and Access Management, IAM);
- облачные журналы и, что особенно важно, события самих бизнес‑приложений.
Такой подход создаёт иллюзию контроля. Без EDR/XDR остаются невидимыми цепочки процессов и механика атаки, без логов IAM невозможно выявить компрометацию учётных записей, а без журналов бизнес‑приложений SIEM слепа к атакам на них. Именно они всё чаще становятся основным вектором при компрометации цепочек поставок ПО (Software Supply Chain).
Пример ошибки: атаки группы Clop на корпоративные приложения MOVEit и Oracle EBS
Летом 2023 года хакерская группа Clop провела массовую эксплуатацию критической уязвимости SQL‑инъекции в MOVEit Transfer (CVE‑2023‑34362), а затем и связанных уязвимостей (CVE‑2023‑35036, CVE‑2023‑35708, CVE‑2023‑36934). Целью атаки стало не сетевое окружение, а корпоративное приложение для передачи файлов.
В организациях, где SIEM собирала только сетевые журналы и IDS‑события, но не имела логов самого MOVEit, внутренняя активность атакующих — SQL‑инъекции, загрузка веб‑оболочек, операции с файлами — осталась незамеченной. SOC фиксировал инцидент лишь по косвенным признакам, когда данные уже были похищены.
В ноябре 2025 года та же группа использовала уязвимость CVE‑2025‑61882 в Oracle E‑Business Suite для атаки на Logitech, похитив 1,8 ТБ данных. Эксплуатация происходила внутри ERP‑системы, и без её журналов атака оставалась невидимой для SOC.
Оба случая демонстрируют системный риск: современные злоумышленники целенаправленно атакуют корпоративные приложения. Если их журналы (MOVEit, Oracle EBS и др.) не интегрированы в SIEM, атаки выявляются лишь на этапе утечки данных.
Чем опасна эта ошибка
Фрагментарный сбор данных делает мониторинг неполным: SIEM не фиксирует значительную часть действий злоумышленника. Атаки на учётные записи, облачные сервисы или бизнес‑приложения остаются незамеченными, потому что нужные журналы не подключены.
Без детальных логов невозможно восстановить ход инцидента, подтвердить результаты расследования, показать эффективность защиты и выполнить требования ФСТЭК. Это грозит штрафами, а при реальном инциденте — убытками из‑за простоя и утечек данных.
Дополнительно снижается ценность уже внедрённых средств защиты, например EDR и DLP-систем. Их события не складываются в единую картину, и SOC теряет возможность видеть атаку целиком.
Ошибка 8. Игнорирование облачных журналов и SaaS‑логов
Фокус многих SOC остаётся на защите периметра ЦОД, в то время как активность злоумышленников и бизнес‑процессы сместились в облако. Это создаёт критический разрыв между ландшафтом атаки и ландшафтом мониторинга. В России, несмотря на спрос на локальные (on‑premise) развёртывания SIEM, игнорирование журналов облачных платформ (VK Cloud, Yandex Cloud) и SaaS‑сервисов — непростительная ошибка.
В гибридных инфраструктурах отсутствие облачных журналов формирует устойчивую «слепую зону». Действия в облаке (создание инстансов, выдача токенов, доступ к хранилищам, вызовы облачных API) не фиксируются в локальных журналах. SOC видит сетевой трафик и базовые события операционной системы (ОС), но не управление ресурсами и доступом, где сегодня происходят ранние этапы атак.
Это особенно критично для атак на идентификацию, цепочки поставок и злоупотребление облачными API. Без журналов управления ресурсами, аудита API и событий IAM ранние стадии компрометации остаются незаметными, и атака фиксируется только по последствиям.
Пример ошибки: атака на цепочку поставок через компрометацию 3CX
Весной 2023 года была раскрыта масштабная атака на цепочку поставок. Злоумышленники (кластер UNC4736) сначала скомпрометировали инфраструктуру Trading Technologies, внедрив вредоносный код в установщик X_Trader. Затем этот доступ использовали для атаки на систему сборки 3CX, чтобы внедрить вредоносный компонент в официальные обновления мессенджера.
Значительная часть управляющей активности проходила через внешние SaaS‑платформы и облачные сервисы: GitHub использовался для загрузки конфигураций, облачные хостинги — для размещения командных серверов (Command and Control, C2), а облачные API — для взаимодействия внутри инфраструктуры жертв.
В компаниях, где SIEM не собирала журналы этих сервисов, начальная фаза атаки осталась полностью незамеченной. SOC фиксировал проблему лишь на позднем этапе — по сетевым аномалиям или срабатыванию антивируса на конечных точках.
Чем опасна эта ошибка
Атаки с использованием облачных сервисов — кража токенов, создание ресурсов для майнинга, манипуляции с OAuth‑приложениями, перемещение через легитимные API — остаются незаметными. Среднее время обнаружения и реагирования (MTTD/MTTR) растёт: инцидент выявляется только по последствиям.
Для компаний, которые относятся к критической информационной инфраструктуре (КИИ), отсутствие контроля над журналами облачных платформ означает несоответствие требованиям регуляторов.
Интеграция облачных журналов в SIEM — обязательное условие, чтобы видеть реальные бизнес‑процессы и ранние стадии наиболее опасных атак.
Ошибка 9. Отсутствие интеграции SIEM с системами реагирования (SOAR)
Нередко SIEM остаётся «пассивной» системой. Она генерирует алерты, но дальнейшие действия — блокировка IP‑адреса, изоляция хоста, отключение токена или сессии — выполняются вручную.
Такой подход разрывает жизненный цикл инцидента и создаёт критическую задержку между обнаружением (detect) и реагированием (respond). Для современных атак, где шифровальщики выводят инфраструктуру из строя за минуты, а компрометация учётной записи приводит к мгновенной эскалации привилегий, такие задержки недопустимы. Без автоматизации SOC успевает увидеть атаку, но не успевает остановить её.
Современный тренд — объединение SIEM и SOAR в единой платформе. Это ускоряет реакцию в разы и снижает совокупную стоимость владения до 40 %. В «10 заповедях SIEM» рекомендуют закладывать автоматизацию реагирования уже на этапе проектирования, а не откладывать «на потом».
Пример ошибки: атака на Colonial Pipeline
В мае 2021 года оператор топливных трубопроводов Colonial Pipeline стал жертвой группы DarkSide. Доступ был получен через VPN‑учётную запись, защищённую только паролем — многофакторная аутентификация отсутствовала.
SIEM зафиксировала аномальный вход: необычная геолокация и нерабочее время. Однако все действия выполнялись вручную. Пока аналитики согласовывали блокировку, злоумышленники развернули шифровальщик, что привело к остановке критической инфраструктуры, перебоям с топливом в 17 штатах и выплате выкупа.
Отсутствие SOAR‑сценариев для автоматической блокировки сессии и изоляции систем стало одним из факторов, позволивших инциденту перерасти в кризис федерального масштаба.
Чем опасна эта ошибка
Отсутствие автоматизации реагирования создаёт системные уязвимости. Высокий MTTR делает организацию беззащитной перед быстрыми атаками вроде ransomware. Ручная обработка оповещений перегружает SOC и снижает качество расследований. Реакции становятся непоследовательными: разные специалисты принимают разные решения в одинаковых ситуациях.
SIEM без SOAR остаётся половинчатым решением. Полноценная защита требует замкнутого цикла: от обнаружения через SIEM до автоматизированного ответа с интеграцией EDR/XDR, сетевых экранов и систем IAM.
Ошибка 10. Провалы в управлении идентификацией и доступом (IAM)
При слабой IAM-гигиене (нет многофакторной аутентификации (Multi‑Factor Authentication, MFA), избыточные привилегии, неконтролируемые сервисные учётные записи) злоумышленник с учётными данными становится легитимным пользователем в глазах SIEM.
Приказ ФСТЭК №117 прямо предписывает обязательное использование MFA для администраторов и пользователей критической информационной инфраструктуры (КИИ), строгий контроль привилегий и регулярный аудит. Таким образом, зрелая IAM-модель становится не рекомендацией, а обязательным условием соответствия.
Её недостатки напрямую снижают эффективность SIEM. Без MFA компрометация учётной записи становится тривиальной, лишние права позволяют выполнять критические операции без эскалации, а хранение секретов в открытом виде делает инфраструктуру уязвимой.
Пример ошибки: инцидент в Uber
В сентябре 2022 года злоумышленник получил широкий доступ к внутренним системам Uber — домену, облачным консолям и административным панелям. Атака стала возможной из‑за системных провалов в IAM.
Использовалась атака на усталость от MFA (MFA‑fatigue): имея логин и пароль, злоумышленник многократно отправлял push‑запросы, пока сотрудник случайно не подтвердил один из них.
Скомпрометированная учётная запись обладала избыточными привилегиями, что позволило сразу получить доступ к критическим средам.
В инфраструктуре были обнаружены чувствительные данные (например, hardcoded‑ключи), которые упростили дальнейшее продвижение.
Чем опасна эта ошибка
При слабой IAM злоумышленник с украденными учётными данными действует как легитимный пользователь и остаётся незаметным для SIEM. Атака развивается без эксплуатации уязвимостей — за счёт разрешённых операций, что усложняет расследование. Компрометация одной учётной записи при отсутствии сегментации прав быстро приводит к масштабным последствиям и нарушению требований регуляторов.
Без корректной архитектуры управления доступом, контроля привилегий и обязательной многофакторной аутентификации даже продвинутая SIEM фиксирует лишь поверхностные события, не замечая действий внутреннего нарушителя.
Выводы
Ошибки при настройке SIEM образуют порочный круг. Нет модели угроз (Ошибка 1) → собирается всё подряд (2) → SIEM перегружена, команда не справляется (3) → ошибки парсинга ломают контекст (4) → создаются неадаптированные правила (5) → они не тестируются и не обновляются (6) → важные источники остаются вне поля зрения (7, 8) → не хватает ресурсов на автоматизацию реагирования и контроль доступа (9, 10).
Разорвать круг можно, следуя нижепредставленным принципам.
От протоколов — к процессам. Начинать с цели: что защищаем и зачем. Честно оценивать ресурсы SOC и рассматривать сервисные модели (MSSP). Внедрять формальный жизненный цикл управления правилами детектирования.
От сбора данных — к управлению контекстом. Подключать источники осмысленно, начиная с EDR, NGFW и IAM. Признать облако новым периметром и интегрировать его журналы в первую очередь. Требовать от вендоров корректных парсеров и нормализации для всего стека технологий.
От обнаружения — к противодействию. Автоматизировать реагирование на рутинные инциденты через SOAR, снижая операционные затраты. Использовать SIEM и UEBA для постоянного аудита IAM‑гигиены и выявления аномалий.
Успех SIEM определяется точностью аналитики и скоростью реакции. Это достигается, когда работа строится как единый цикл: моделирование угроз, целевой сбор данных, контекстное обнаружение и автоматизированный ответ.
