Detection Engineering: как строить правила обнаружения угроз
Что такое Detection Engineering
Detection Engineering — это инженерная дисциплина внутри кибербезопасности, которая занимается систематическим созданием, тестированием и сопровождением правил обнаружения угроз. Если коротко: это методология, позволяющая превратить знание о том, как атакует противник, в конкретную логику, которая сработает в SIEM или EDR в нужный момент.
Само слово «engineering» здесь принципиально. Речь идёт не о разовом написании правила и его забвении — а о полноценном инженерном процессе: анализ угрозы, проектирование детекта, тестирование на реальных и синтетических данных, версионирование, деплой и постоянное улучшение. Всё это делается систематически, воспроизводимо и документируется.
До того как Detection Engineering сформировался как отдельная практика, правила писались хаотично: разные аналитики SOC создавали детекты под конкретные инциденты, никто не следил за качеством, а технический долг накапливался годами. В результате SIEM был переполнен шумными правилами, аналитики тонули в ложных срабатываниях, а реальные атаки проскакивали незамеченными.
💡 Detection Engineering решает главную проблему корпоративной безопасности: разрыв между тем, что организация знает об угрозах, и тем, что она реально способна обнаружить в своей инфраструктуре.
Сегодня Detection Engineering — это точка пересечения нескольких дисциплин: threat intelligence (знание о том, как атакуют), log management (умение работать с данными), программирование (написание и автоматизация правил) и security operations (понимание контекста, в котором будут работать детекты). Именно эта многослойность делает дисциплину одной из самых востребованных в индустрии.
Место Detection Engineering в структуре кибербезопасности
Detection Engineering — часть Blue Team, широкого понятия, объединяющего всех специалистов, занятых защитой, мониторингом и реагированием. Blue Team включает SOC-аналитиков, специалистов по Threat Intelligence, Incident Response, Forensics и именно Detection Engineering. Каждое из этих направлений самостоятельно, но они постоянно взаимодействуют между собой.
Detection Engineering занимает в этой экосистеме особое место: он работает «ниже» аналитиков SOC по стеку, создавая инструментарий, которым те пользуются ежедневно. Без качественных правил обнаружения SOC-аналитик просто не увидит атаку — сколько бы экспертизы у него ни было.
Detection Engineering vs SOC-аналитик: в чём разница
Это разграничение важно, потому что на практике его часто размывают. SOC-аналитик — конкретная роль: он работает с алертами, расследует инциденты, реагирует на угрозы в режиме реального времени. Detection Engineer — другая роль: он создаёт сами правила, по которым эти алерты генерируются.
SOC-аналитик спрашивает: «Что произошло?» Detection Engineer спрашивает: «Как нам это увидеть в следующий раз?» Первый работает с событием. Второй — с системой обнаружения событий. В небольших командах эти роли могут совмещаться, но в зрелых SOC это разные позиции с разными KPI и разным фокусом.
Как работает процесс Detection Engineering
Detection Engineering — это не разовое действие, а циклический процесс. Он начинается задолго до написания первого правила и не заканчивается после его деплоя. Рассмотрим каждый этап подробно.
Этап 1. Моделирование угроз и источники данных
Прежде чем написать хоть строчку правила, Detection Engineer задаёт вопрос: от чего именно мы хотим защититься? Это не абстрактный вопрос — он требует конкретного ответа в виде списка техник из MITRE ATT&CK, актуальных для вашей отрасли и вашего типа инфраструктуры.
Параллельно оценивается покрытие данными: какие логи вы собираете? Есть ли в вашем SIEM события аутентификации Windows (Event ID 4624, 4625, 4648)? Собираются ли DNS-запросы? Есть ли телеметрия с эндпоинтов через EDR? Если нужного источника данных нет — правило написать невозможно. Поэтому Detection Engineering начинается с аудита видимости (visibility assessment).
💡 Правило не может обнаружить то, о чём вы не собираете данные. Visibility — фундамент всего Detection Engineering. Без понимания, какие данные есть, написание правил — это стрельба вслепую.
Этап 2. Написание правил обнаружения
На этом этапе формируется логика детекта. Detection Engineer изучает, как конкретная техника атаки проявляется в логах: какие артефакты остаются, какие паттерны поведения характерны для вредоносной активности в отличие от легитимной. Это требует глубокого понимания и «языка атак», и «языка инфраструктуры».
Правило пишется так, чтобы оно максимально точно описывало вредоносное поведение и при этом не срабатывало на легитимные процессы. Это баланс между чувствительностью (sensitivity) и специфичностью (specificity) — и найти его сложнее, чем кажется. Слишком чувствительное правило генерирует шум. Слишком специфичное — пропускает варианты атаки.
Этап 3. Тестирование и валидация правил
Написанное правило нужно проверить до его попадания в продакшн. Тестирование включает несколько уровней. Во-первых, unit-тесты на синтетических данных: создаются искусственные события, которые должны триггерить правило, и убеждаются, что оно действительно срабатывает. Во-вторых, проверка на исторических данных: правило прогоняется по логам за прошлые периоды, чтобы оценить реальный уровень шума.
Для имитации атак используются фреймворки типа Atomic Red Team или Caldera — они воспроизводят конкретные техники ATT&CK в контролируемой среде. Это позволяет убедиться, что правило работает именно так, как задумано.
Этап 4. Деплой, мониторинг и итерации
После успешного тестирования правило публикуется в SIEM и начинает работать. Но работа Detection Engineer на этом не заканчивается. Необходимо отслеживать метрики: сколько алертов генерирует правило в день, какой процент из них — истинные срабатывания (true positives), нет ли признаков деградации правила после изменений в инфраструктуре.
Инфраструктура меняется — меняются и условия, в которых работают правила. Правило, идеально работавшее полгода назад, может начать генерировать шум после обновления ПО или изменения архитектуры сети. Поэтому Detection Engineering — это непрерывный цикл, а не проект с финальной датой.
Ключевые инструменты Detection Engineer
Стек инструментов Detection Engineer шире, чем кажется на первый взгляд. Это не просто умение писать запросы в SIEM — это пересечение нескольких технологических слоёв, каждый из которых критически важен.
SIEM-платформы как основа обнаружения
SIEM (Security Information and Event Management) — главная среда, в которой живут правила Detection Engineer. Именно здесь агрегируются логи из всей инфраструктуры, здесь выполняются корреляционные правила и генерируются алерты для SOC-аналитиков.
Наиболее распространённые платформы на российском рынке: MaxPatrol SIEM (Positive Technologies), RuSIEM, KUMA (Kaspersky). В международной практике доминируют Splunk, Microsoft Sentinel, Elastic SIEM и Chronicle (Google). Detection Engineer должен уметь работать минимум с одной платформой на уровне написания запросов — SPL для Splunk, KQL для Sentinel, EQL или Lucene для Elastic.
💡 Знание конкретного языка запросов (SPL, KQL, EQL) — это не «дополнительный навык», а базовое требование. Без него написать работающее правило в SIEM невозможно.
MITRE ATT&CK: фреймворк для построения детектов
MITRE ATT&CK — это не инструмент в техническом смысле, а структурированная база знаний о тактиках, техниках и процедурах (TTP) реальных атакующих. Для Detection Engineer это главный словарь: каждое правило должно быть привязано к конкретной технике ATT&CK. Это позволяет измерять покрытие — какой процент техник из матрицы организация реально способна обнаружить.
Практическое применение: берём технику T1059 (Command and Scripting Interpreter) — и смотрим, как именно злоумышленники используют PowerShell, cmd, WScript в реальных кампаниях. На основе этого пишем правила, которые будут отлавливать подозрительное поведение именно в этих точках. ATT&CK даёт контекст — правило без контекста это просто строчка условий.
Sigma — универсальный язык правил
Sigma — это открытый формат описания правил обнаружения, не привязанный к конкретной SIEM-платформе. Правило пишется один раз в формате YAML, а затем конвертируется в нужный язык запросов с помощью транслятора sigma-cli. Это решает проблему vendor lock-in: одна команда может поддерживать единую базу правил, которые работают и в Splunk, и в Elastic, и в Sentinel.
Sigma-правило содержит метаданные (название, автор, дата, ссылка на ATT&CK), описание логики детекта, уровень опасности (low/medium/high/critical) и фильтры для исключения ложных срабатываний. Репозиторий SigmaHQ содержит тысячи готовых правил с открытым исходным кодом — это ценнейший ресурс для обучения и готовая база для старта.
Дополнительный стек: EDR, SOAR, тестовые фреймворки
EDR (Endpoint Detection and Response) — источник богатейшей телеметрии с эндпоинтов: цепочки процессов, сетевые соединения, обращения к реестру, файловые операции. Популярные решения: CrowdStrike Falcon, Microsoft Defender for Endpoint, Elastic Agent, Carbon Black. Detection Engineer должен понимать, какие данные даёт конкретный EDR и как их использовать в правилах.
SOAR (Security Orchestration, Automation and Response) — платформы автоматизации реагирования. Detection Engineer взаимодействует с ними при настройке автоматических реакций на алерты: блокировка IP, изоляция хоста, создание тикета в трекере.
Тестовые фреймворки: Atomic Red Team (библиотека атомарных тестов от Red Canary), MITRE Caldera (автоматизированная симуляция атак), Stratus Red Team (облачные среды). Эти инструменты позволяют воспроизвести конкретные техники ATT&CK в изолированной среде и проверить, срабатывают ли правила так, как ожидается.
Типы правил обнаружения: от сигнатур до поведенческих детектов
Не все правила обнаружения устроены одинаково. Detection Engineer работает с несколькими принципиально разными подходами, и понимание их различий — ключ к построению эффективного detection coverage.
Сигнатурные правила
Самый простой и старый тип. Сигнатурное правило ищет точное совпадение: конкретный хэш файла, конкретную строку в командной строке, конкретный IP-адрес из списка угроз. Достоинство — высокая точность при низком уровне ложных срабатываний. Недостаток — хрупкость: один байт изменения в малваре, одна новая C2-инфраструктура — и правило перестаёт работать.
Сигнатурные правила хороши для известных угроз с устойчивыми IoC (Indicators of Compromise). Они плохо работают против новых атак и атакующих, которые умеют менять свои инструменты.
Аномалии и статистические детекты
Аномалийные правила не ищут конкретный паттерн — они выявляют отклонения от нормального поведения. Пример: пользователь обычно логинится с одного города, а сейчас — с другого конца страны за час до этого. Или: сервер, который никогда не генерировал исходящие HTTPS-соединения, вдруг начал это делать в 3 часа ночи.
Статистические детекты требуют понимания «нормы» для конкретной среды. Это трудоёмко: нужно накопить достаточный baseline и настроить пороговые значения. Зато такие правила значительно устойчивее к изменениям тактики атакующих — поведенческие паттерны меняются медленнее, чем конкретные инструменты.
Поведенческие правила (behavioral detection)
Поведенческие детекты — самый сложный и ценный тип. Они описывают не отдельный артефакт, а цепочку событий и контекст их возникновения. Например: процесс Word.exe породил дочерний процесс PowerShell, который установил сетевое соединение с внешним IP. Каждое из этих событий по отдельности может быть легитимным. Вместе — это классический паттерн фишинговой атаки с макросом.
💡 Поведенческие правила работают на уровне TTP — тактик, техник и процедур. Атакующий может сменить инструмент, но не может легко изменить фундаментальную технику атаки. Именно поэтому behavioral detection значительно устойчивее к уклонению.
Построение поведенческих правил требует глубокого понимания операционных систем, сетевых протоколов и того, как атакующие используют легитимные инструменты (технику Living off the Land, или LotL). Это высший уровень Detection Engineering, к которому ведут годы практики и изучения реальных инцидентов.
Качество правил: как избежать шума и ложных срабатываний
Плохое правило хуже отсутствия правила. Это не преувеличение. Правило, генерирующее сотни ложных срабатываний в день, делает несколько плохих вещей одновременно: перегружает аналитиков SOC, снижает их доверие к системе обнаружения, создаёт «усталость от алертов» (alert fatigue) — состояние, при котором люди начинают игнорировать уведомления, в том числе реальные угрозы.
Метрики качества детекта
Зрелые команды Detection Engineering измеряют качество каждого правила количественно. Ключевые метрики:
True Positive Rate (TPR) — доля реальных угроз, которые правило обнаружило. False Positive Rate (FPR) — доля легитимных событий, на которые правило сработало ошибочно. Signal-to-Noise Ratio (SNR) — общее соотношение значимых алертов к шуму. Mean Time to Detect (MTTD) — среднее время от начала атаки до момента генерации алерта.
Если правило генерирует больше 5–10 ложных срабатываний в день — это сигнал к ревизии логики или добавлению исключений (allowlist). Если правило не генерирует ничего за несколько месяцев в активной инфраструктуре — возможно, оно вообще не работает из-за изменений в данных.
💡 Alert fatigue — одна из главных причин пропуска реальных инцидентов. По данным исследований, в перегруженных SOC аналитики пропускают до 35% критических алертов просто потому, что поток уведомлений слишком велик. Качество детектов напрямую влияет на безопасность организации.
Detection-as-Code: правила в системе контроля версий
Detection-as-Code (DaC) — это подход, при котором правила обнаружения хранятся в системе контроля версий (Git) и управляются как программный код: с code review, CI/CD-пайплайнами, автотестами и историей изменений. Этот подход пришёл в Detection Engineering из практик DevOps и кардинально изменил качество процессов.
Что даёт DaC? Во-первых, прозрачность: каждое изменение правила документируется в коммите с описанием причины. Во-вторых, контроль качества: перед деплоем правило проходит автоматические тесты и code review от коллег. В-третьих, откатываемость: если правило начало генерировать шум, его можно мгновенно откатить к предыдущей версии. В-четвёртых, коллаборация: вся команда работает с единой кодовой базой, нет «правил в голове одного человека».
Типичный DaC-стек выглядит так: правила пишутся в Sigma YAML → хранятся в GitLab/GitHub → CI/CD-пайплайн запускает автотесты → при успешном прохождении правило автоматически деплоится в SIEM. Это позволяет сократить время от написания правила до его появления в продакшне с нескольких недель до нескольких часов.
Навыки и знания Detection Engineer
Detection Engineering — одна из немногих специализаций в кибербезопасности, где требуется одновременно широкая и глубокая экспертиза. Нельзя быть хорошим Detection Engineer, зная только SIEM. Нельзя быть им, зная только ATT&CK. Нужно всё это вместе — плюс умение думать и как атакующий, и как инженер.
Технические навыки
Работа с SIEM и языками запросов — базовый уровень: умение писать сложные корреляционные запросы, понимать особенности нормализации данных в конкретной платформе, оптимизировать производительность правил.
Знание операционных систем — детальное понимание того, как работает Windows (Event Log, Sysmon, WMI, реестр, Named Pipes), Linux (auditd, syslog, proc filesystem) и как атакующие эксплуатируют встроенные механизмы этих систем.
Сетевые протоколы и анализ трафика — понимание DNS, HTTP/S, SMB, Kerberos на уровне «что выглядит нормально, а что — нет». Detection Engineer должен уметь читать сетевые логи и находить в них паттерны C2-коммуникации или lateral movement.
Программирование и скриптинг — Python для автоматизации и обработки данных, Bash для работы с логами, знание регулярных выражений (regex). Понимание Git для работы в Detection-as-Code парадигме.
Экспертные знания в области безопасности
Понимание техник атакующих — Detection Engineer должен думать как Red Team. Не обязательно уметь проводить атаки самостоятельно, но понимать механику: как работает Pass-the-Hash, что такое Kerberoasting, как выглядит beacon timing у Cobalt Strike, какие артефакты оставляет LSASS dumping.
Threat Intelligence — умение читать технические отчёты об угрозах (Threat Intel reports), извлекать из них IoC и TTP, переводить их в правила. Понимание того, как работают APT-группы, какие инструменты используют и как их отличить от легитимного ПО.
Опыт в SOC или Incident Response — практика расследования реальных инцидентов формирует интуицию, которую невозможно получить из книг. Именно поэтому многие Detection Engineer начинают карьеру в SOC, а потом специализируются. Это органичный и логичный путь.
💡 Лучшие Detection Engineer — это люди, которые понимают, как думает атакующий, и умеют это знание формализовать в логику, понятную машине. Это редкое сочетание аналитического мышления, технической глубины и инженерной дисциплины.
Soft skills и аналитическое мышление
Detection Engineering — командная работа. Специалист постоянно взаимодействует с SOC-аналитиками (чтобы понять, что их больше всего беспокоит), с Threat Intelligence (чтобы получать актуальные данные об угрозах), с Red Team (чтобы проверять правила в симулированных атаках) и с инженерами инфраструктуры (чтобы правильно настраивать источники данных). Умение объяснять сложные вещи просто, документировать решения и работать в agile-командах — не менее важно, чем технические навыки.
Где учиться Detection Engineering
Detection Engineering — молодая, но стремительно развивающаяся дисциплина. Специализированных курсов по ней заметно меньше, чем по смежным темам вроде Penetration Testing или Incident Response, но их количество растёт. При выборе обучения важно ориентироваться на практику: курсы, где вы пишете реальные правила в реальном SIEM, стоят в десятки раз больше, чем курсы с теоретическими слайдами.
Хорошая программа по Detection Engineering должна включать: работу с MITRE ATT&CK и Sigma, практику на SIEM-платформе, разбор реальных кейсов из инцидентов, тестирование правил с помощью Atomic Red Team и основы Detection-as-Code. Если хотя бы половина этого присутствует — программа достойна внимания.
Попасть в Detection Engineering можно разными путями. Из SOC — самый органичный: вы уже понимаете, как работают алерты, что мешает аналитикам и где дыры в обнаружении. Из разработки — тоже реально, особенно если у вас есть интерес к безопасности: навыки программирования в Detection Engineering критически важны. С нуля — сложнее, но при наличии технической базы (администрирование, сетевое дело) вполне достижимо через 1–2 года целенаправленного обучения.
Где учиться?
Собрали курсы по мониторингу, обнаружению угроз и работе с SIEM — с разбивкой по уровням подготовки и платформам.
Смотреть курсы →