Триаж алертов SOC аналитик: разбираю тестовое задание на L1

За последние два года через моё тестовое задание на позицию SOC L1 прошли больше сорока кандидатов. Семь из десяти расставили приоритеты неправильно. Задание одно и то же: пять алертов, расположи по порядку разбора. Причина провала почти всегда одна — кандидат сортирует по severity (оценка критичности, которую система выставляет автоматически), вместо того чтобы выстраивать priority (реальная очерёдность разбора с учётом контекста). Ниже — полный разбор этого тестового с объяснением логики, которую ожидает интервьюер.

Что проверяет тестовое задание на сортировку алертов по приоритету

Триаж алертов (alert triage) — процесс, при котором аналитик получает поток уведомлений от систем безопасности и решает: что расследовать первым, что подождёт, а что закрыть как ложное срабатывание. Термин пришёл из медицины: в приёмном покое врач не лечит всех подряд, а определяет, кому помощь нужна прямо сейчас. В SOC (Security Operations Center — центр мониторинга безопасности) та же логика: алертов за смену приходят тысячи, а аналитиков — единицы.

На собеседовании тестовое задание на триаж проверяет не знание конкретного SIEM (Security Information and Event Management — система, которая собирает логи со всей инфраструктуры и генерирует алерты на подозрительную активность). Оно проверяет три вещи:

1. Умеешь ли ты отличить severity от priority. Severity — автоматическая оценка от SIEM. Priority — твоя оценка с учётом контекста: какой актив, какое время суток, какая стадия атаки.
2. Видишь ли ты контекст за алертом. Один и тот же алерт «failed login» может быть рутиной или началом атаки. Разница — в деталях вокруг.
3. Можешь ли ты объяснить своё решение. «Мне показалось» — не ответ. Интервьюер ждёт цепочку: «вижу X, поэтому делаю Y».

По данным Verizon DBIR 2025, 68% утечек данных связаны с человеческим фактором — ошибками, социальной инженерией, неверными действиями. Аналитик, который не умеет расставлять приоритеты, тратит время на шум и пропускает настоящую атаку. Как формулирует CyberDefenders в руководстве по alert triage: «Risk scoring — это вход для человеческого суждения, не замена ему.»

Кейс для собеседования ИБ: пять алертов, одна ночная смена

Вот тестовое задание. Воскресенье, 3:00 ночи. Ты — единственный аналитик на смене. В SIEM пришли пять алертов за последние 15 минут. Расставь по приоритету: 1 — разбирать первым, 5 — последним.

Попробуй расставить сам, прежде чем читать дальше. Запиши свой порядок и сравни с разбором.

Ошибки при триаже алертов: на чём заваливаются кандидаты

Severity — это не priority

Самая частая ошибка: кандидат ставит алерт A первым (Critical), алерт E — вторым (High), а алерт D — последним (Low). Это механическая сортировка, а не анализ инцидентов безопасности.

Severity отвечает на вопрос «насколько опасна эта угроза в теории?». Priority — «насколько это опасно именно здесь, именно сейчас?».

Алерт E — хороший пример расхождения. Антивирус нашёл троян на сервере DEV-SANDBOX-03 в каталоге /test-samples/. Severity = High, потому что антивирус увидел сигнатуру трояна. Но это песочница DevOps — среда, где разработчики намеренно тестируют образцы вредоносного ПО. Файл лежит в тестовом каталоге изолированного хоста. Priority низкий: нужно подтвердить, что файл не запущен как процесс, что нет сетевой активности наружу, задокументировать и закрыть.

А вот алерт D — обратная ситуация. DNS-запрос к свежезарегистрированному домену — один из классических признаков C2-канала (Command & Control — канал связи между малварью на заражённом хосте и сервером атакующего; по нему малварь получает команды и отправляет украденные данные). SIEM ставит Low, потому что один DNS-запрос сам по себе не атака. Но смотри на контекст: запрос идёт с ноутбука CFO, HTTPS-соединение уже установлено (данные передаются), время — 3 часа ночи воскресенья. CFO в это время вряд ли работает. Это может быть начало эксфильтрации — вывода данных из сети.

Триаж вслепую: алерт без контекста

Вторая ошибка — кандидат оценивает алерт изолированно, не задавая уточняющих вопросов.

Возьмём алерт C (Medium severity): 15 неуспешных входов, потом 1 успешный вход сервисной учёткой на контроллер домена. Кандидат, который не задаёт вопросов, скажет: «Medium, подождёт.» Кандидат, который думает как аналитик, спросит:

• Эта сервисная учётка обычно логинится на контроллер домена? (Проверяем baseline — типичное поведение)
• 15 неуспешных попыток — перебор пароля или ротация ключей мониторинга? (Разные причины — разная реакция)
• Есть ли другие алерты с тех же источников за последний час? (Ищем корреляцию)

Если svc-monitoring обычно не ходит на контроллер домена, а тут 15 неудач и один успех — это паттерн lateral movement (перемещение атакующего по внутренней сети после первичного проникновения). Воскресенье, 3 ночи — легитимные сервисные задачи в это время обычно не меняют поведение.

На Habr в статье про ошибки триажа разбирается похожий кейс: три low-severity алерта (GetCallerIdentity, ListBuckets, AssumeRole), каждый закрыт как false positive, а вместе они складываются в картину разведки за полторы минуты. Один алерт — событие. Три связанных алерта — цепочка.

Вот факторы, которые нужно прогнать для каждого алерта:

«False positive» без обоснования

Третья ошибка: кандидат произносит «это false positive» и не объясняет, как он это подтвердил.

False positive (ложное срабатывание, часто сокращают FP) — алерт на легитимную активность. Например, сканер уязвимостей проверяет порты — IDS (Intrusion Detection System — система обнаружения вторжений, которая анализирует сетевой трафик) видит сканирование и генерирует алерт. Активность обнаружена верно, но она не вредоносная.

Проблема не в том, чтобы найти FP. Проблема — в документировании. Когда кандидат говорит «алерт E — false positive, потому что это песочница», я спрашиваю: «А как ты это подтвердил?» Сильный ответ выглядит так:

1. Проверил, что DEV-SANDBOX-03 действительно в сегменте песочницы (по инвентаризации активов или CMDB)
2. Убедился, что файл не запущен как процесс — через EDR (Endpoint Detection and Response — агент на конечной точке, который видит процессы, файлы и сетевые соединения хоста)
3. Проверил отсутствие исходящих соединений с этого хоста
4. Записал: «FP — тестовый образец в изолированной песочнице, файл не запущен, сетевая активность отсутствует. Рекомендация: добавить исключение для /test-samples/ на хостах sandbox-сегмента»

Это занимает пару минут, но показывает интервьюеру: ты не просто нажал «закрыть», а проверил гипотезу и оставил след для следующего аналитика.

Приоритизация инцидентов: фреймворк для ответа на собеседовании SOC аналитик

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

Вопрос 1: Что за актив под ударом? Контроллер домена, ноутбук CFO, сервер с персональными данными — критичные активы. Рабочая станция стажёра в изолированном VLAN — нет. Компрометация критичного актива = высокий priority при любом severity.

Вопрос 2: На какой стадии атаки мы находимся? Разведка — есть часы на реакцию. Эксфильтрация — минуты. Lateral movement на контроллер домена — реагируй немедленно. По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют действительные учётные данные — атакующий может быть внутри и не генерировать «громких» алертов.

Вопрос 3: Это нормально для этого актора в это время? Бухгалтер запускает PowerShell с закодированной командой в 3 ночи — аномалия. Администратор делает то же самое в рабочее время — скорее всего штатная операция.

Вопрос 4: Есть ли связанные алерты? Один алерт — событие. Три алерта от одного источника за 10 минут — потенциальная атака. Ищи совпадение IP-адресов, учётных записей, хостов, временных окон.

Разбор тестового задания ИБ: пять алертов по шагам

Применяем фреймворк. Для каждого алерта — обоснование priority и формулировка, которую ожидает интервьюер.

Priority 1 — Алерт C (SIEM: Medium): brute-force + успешный вход на контроллер домена

Контроллер домена — самый критичный актив в Windows-инфраструктуре. 15 неуспешных + 1 успешный вход сервисной учёткой — паттерн credential brute-force с последующим lateral movement. Аномалия baseline: svc-monitoring не должна генерировать failed logins. Время — ночь выходного.

Действия: немедленно проверить активность svc-monitoring за последний час, сверить с историей логонов этой учётки. Если аномалия подтвердится — эскалация на L2 с рекомендацией изолировать учётку.

Что сказать: «Ставлю первым: успешный вход после серии неуспешных на контроллер домена — возможная компрометация crown jewel. Severity Medium обманчива — SIEM не учитывает, что целевой хост DC.»

Priority 2 — Алерт D (SIEM: Low): DNS к свежему домену с ноутбука CFO

Ноутбук CFO — доступ к финансовой информации, стратегическим документам. HTTPS-соединение установлено — данные, возможно, уже передаются. CFO в 3 часа ночи воскресенья — аномалия. Newly registered domain — классический признак C2.

Действия: проверить, были ли другие DNS-запросы к NRD (newly registered domains) с этого хоста. Посмотреть объём HTTPS-трафика через NetFlow или прокси-лог.

Что сказать: «Low severity — потому что один DNS-запрос сам по себе не опасен. Но CFO + ночь + свежий домен + установленное HTTPS — паттерн C2-канала. Если не проверю сейчас, утром может быть поздно.»

Priority 3 — Алерт B (SIEM: High): PowerShell encoded command на бухгалтерской станции

Выполнение закодированной PowerShell-команды — техника T1059.001 в MITRE ATT&CK (открытая база тактик и техник атак; T-коды — идентификаторы конкретных техник). PowerShell — встроенная утилита Windows, которую атакующие часто используют для запуска вредоносного кода. В каталоге LOLBAS (легитимные системные бинарники, которые атакующие переиспользуют в своих целях) Powershell.exe описан именно как инструмент выполнения произвольного кода. В SigmaHQ — публичном репозитории правил обнаружения — на технику T1059.001 заведено более 250 правил. Одна из самых распространённых техник в реальных атаках.

Бухгалтер не использует PowerShell — аномалия. Но priority ниже, чем у C и D: те указывают на более продвинутые стадии (доступ к DC, возможная эксфильтрация).

Действия: декодировать команду через Event ID 4104 (Script Block Logging — журнал PowerShell, который записывает полный текст выполненных скриптов).

Пример запроса в Splunk (предусловие: логи Windows поступают в индекс windows, на хосте включён Script Block Logging через групповую политику):

index=windows EventCode=4104 host="WS-FIN-012" earliest=-1h
| table _time, ScriptBlockText, UserID

В столбце ScriptBlockText будет расшифрованный текст скрипта. Если там Invoke-WebRequest на внешний IP — это загрузка payload. Если Get-Process или сервисный скрипт администратора — возможно, легитимная операция.

Priority 4 — Алерт A (SIEM: Critical): brute-force RDP на TERM-SRV01

Severity = Critical, потому что правило настроено на «больше 200 попыток за 5 минут». Но brute-force RDP (Remote Desktop Protocol — протокол удалённого рабочего стола) от внешнего IP на опубликованный сервер — это фоновый шум интернета. Каждый сервер с открытым портом 3389 получает сотни таких попыток в сутки. Ключевое: успешного входа нет.

Действия: убедиться, что учётка admin_backup не скомпрометирована. Проверить Event ID 4624 (Successful Logon) за тот же период:

index=windows EventCode=4624 TargetUserName="admin_backup"
  host="TERM-SRV01" earliest=-1h
| table _time, SourceIP, LogonType

Если в результатах пусто — входа не было, алерт документируем. Если есть строки — priority мгновенно поднимается до первого. Рекомендация: ограничить RDP по IP через firewall, отключить учётку admin_backup, если она не используется.

Что сказать: «Critical severity — но нет успешного входа. Internet noise. Ставлю четвёртым. Но обязательно проверяю 4624 — если вход был, priority сразу в единицу.»

Priority 5 — Алерт E (SIEM: High): антивирус в DevOps-песочнице

Песочница для тестирования, файл в каталоге /test-samples/, хост изолирован. Подтверждаем: файл не запущен, сетевой активности нет. Документируем как confirmed FP с обоснованием. Рекомендация: добавить исключение в правило антивируса для /test-samples/ на хостах sandbox-сегмента — чтобы алерт не отвлекал в следующую смену.

Подготовка к собеседованию SOC аналитик: что запомнить

Перед собеседованием пройдись по этому списку — он покрывает подавляющее большинство вопросов о триаже.

Ключевые Windows Event ID спрашивают почти на каждом собеседовании — это подтверждает и EpicDetect в списке 50 вопросов для SOC-аналитиков: 4624 — успешный вход, 4625 — неуспешный, 4648 — вход с явным указанием учётных данных (может указывать на pass-the-hash), 4672 — назначение специальных привилегий, 4104 — Script Block Logging (содержимое выполненных PowerShell-скриптов).

Отдельно подготовь ответ на вопрос «Как поступишь, если не можешь определить — вредоносный алерт или нет?» Правильный ответ: эскалирую на L2 (аналитик второй линии — проводит глубокое расследование), приложив всё, что собрал. Плохой ответ: «Закрою, скорее всего FP.» Лучше эскалировать ложную тревогу, чем пропустить настоящую атаку — на уровне L1 стоимость пропущенного инцидента несопоставимо выше стоимости ложной эскалации.

Два года назад я начал давать это тестовое — и с тех пор вижу одну закономерность: кандидаты с практическим опытом, пусть даже с CTF-площадок или домашних лабораторий, справляются лучше тех, кто учился только по учебникам. Не потому что задачи на CTF похожи на работу в SOC, а потому что там вырабатывается привычка спрашивать: «Что я вижу? Что это может значить? Какие данные нужны, чтобы подтвердить или опровергнуть гипотезу?» Это ровно та логика, которая отличает живого аналитика от человека, нажимающего кнопки по инструкции. Большинство «завалившихся» на моём тестовом — не глупые. Они просто никогда не тренировали принятие решений под давлением. Severity = Critical стоит в алерте красным шрифтом — и рука тянется поставить его первым, не задумываясь. Тренировка на приближённых к реальности кейсах ломает этот рефлекс. Сертификаты дают базу, но не дают навык принятия решений — а именно его проверяют на собеседовании. Если формат «пять алертов — расставь приоритеты» зацепил и хочется разбирать подобные сценарии системно — на IB Basics как раз учат не «что такое CIA-triad», а как работать с первыми задачами в SOC и blue team.