Собеседование SOC L1: почему вопрос про ложное срабатывание ломает кандидата с сертификатом

За последний год я провёл больше сорока собеседований на позицию SOC L1 — первая линия центра мониторинга и реагирования на инциденты (Security Operations Center). Из кандидатов с сертификатами CompTIA Security+ или CySA+ примерно каждый третий сыпется на одном и том же месте. Даю алерт из SIEM (Security Information and Event Management — система, которая собирает логи со всей инфраструктуры и ищет в них признаки атак) и прошу объяснить, ложное это срабатывание или нет. Кандидат уверенно произносит определение: «false positive — это когда система ошибочно пометила легитимную активность как вредоносную». Дальше — тишина. Ни шагов расследования, ни вопросов к данным, ни попытки доказать вывод. Сертификат подтвердил знание термина, но не научил думать как аналитик.

Ниже — про то, как устроен триаж алертов SOC (первичная сортировка входящих оповещений по приоритету), почему именно вопрос про false positive в SIEM отделяет «знаю теорию» от «готов к работе», и как подготовиться так, чтобы интервьюер поставил «да».

Что проверяют вопросом про ложное срабатывание в SIEM

На собеседовании SOC аналитик первой линии интервьюер не выясняет, помнит ли кандидат определение false positive. Его знают все, кто прочитал хотя бы одну статью. Проверяют другое — умение думать шагами, когда ответ заранее неизвестен.

Типичная проверка выглядит так. Интервьюер говорит: «В очереди 47 алертов с пометкой High. Что делаешь?» Слабый кандидат выбирает один из двух шаблонов: «эскалирую всё на L2» или «закрываю как false positive». Оба ответа — провал.

Сильный кандидат начинает задавать вопросы: «Какое правило корреляции сработало? Один источник или разные? Какой актив затронут — рабочая станция или контроллер домена?» Он не знает ответа, но знает метод.

По данным рекрутингового агентства KORE1, разрыв между глубиной сертификации SOC аналитика и реальными навыками SOC-работы к 2026 году стал шире, чем когда-либо. Современные SIEM добавили AI-слой первичного триажа (в Microsoft Sentinel — Security Copilot, в Splunk — Mission Control), и теперь от аналитика ждут не чтения карточки алерта, а умения проверить, ошибся ли алгоритм.

Событие, алерт, инцидент — три уровня, которые путают на собеседовании SOC аналитик

Интервьюеры намеренно смешивают эти понятия, чтобы проверить, различает ли кандидат уровни. Зафиксируем разницу — она пригодится и на собеседовании, и в первую смену.

Событие (event) — одна строка лога. Пользователь вошёл в систему, процесс запустился, файрвол заблокировал пакет. Само по себе ничего не значит — просто факт, записанный системой.

Алерт (alert / notable) — срабатывание правила детекции. SIEM сопоставил одно или несколько событий с признаками угрозы. Алерт — гипотеза: «здесь может быть что-то плохое». Правила корреляции — логические условия, которые связывают события. Например: «пять неудачных входов плюс один успешный с того же IP за десять минут».

Инцидент (incident) — подтверждённый случай. Аналитик присвоил классификацию, собрал доказательства, принял решение о следующем шаге.

Согласно NIST SP 800-61 (руководство по реагированию на инциденты), триаж строится по риску — критичности актива и масштабу воздействия, — а не по цвету карточки в дашборде. Тут важный нюанс: высокий severity (важность, которую присвоил автор правила) не равен высокому priority (порядок, в котором аналитик разбирает алерты). На собеседовании SOC L1 кандидат, который начинает с «оно же High — значит, срочно» вместо «какой актив затронут», теряет баллы.

Четыре классификации алерта — не только true и false positive

Русскоязычные материалы по подготовке к собеседованию в SOC почти всегда описывают два состояния: true positive и false positive. В реальной работе — и на нормальном интервью — ждут четыре.

Benign positive — вот что чаще всего путают с false positive, и именно тут ломаются кандидаты. Когда сканер уязвимостей обращается к SMB admin shares, правило корреляции сработало ПРАВИЛЬНО: активность действительно подозрительная. Но она ожидаемая и документированная. Закрывать такой алерт как «false positive» — ошибка классификации. И Microsoft Sentinel, и Splunk ES требуют явного указания причины закрытия, «Benign Positive — Suspicious but Expected» — отдельный пункт в выпадающем списке.

Документация Microsoft по работе с FP в Sentinel прямо говорит: известные IP сканеров получают time-bound automation exception (исключение с ограничением по времени) или запись в watchlist. Не «отключить правило».

На собеседовании я прошу назвать все четыре классификации. Кто вспоминает benign positive — почти всегда проходит дальше.

Кейс для SOC интервью: 47 алертов и LSASS на контроллере домена

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

Ситуация: ночная смена. В очереди SIEM — 47 алертов с уровнем High. Сорок из них — «SMB lateral movement» с IP 10.20.8.14. Один — «LSASS memory access» на хосте DC01 (контроллер домена — сервер, который управляет учётными записями всей сети). Процесс запущен от имени svc-backup, время 02:11.

Младший аналитик предлагает: закрыть сорок как False Positive без комментария, на остальные High вызвать команду IR (Incident Response — группа реагирования на инциденты).

Вопрос кандидату: что не так с этим подходом?

Слабый ответ — и почему он убивает шансы

«Нужно эскалировать все High-алерты, потому что они High». Или наоборот: «Сорок одинаковых — точно ложные, закрываю».

Оба варианта провальные. Закрыть 40 алертов без комментария — следующая смена увидит закрытые карточки без объяснения и потратит время на повторный разбор. «False Positive» — ещё и неверная классификация: сканер ДЕЙСТВИТЕЛЬНО сканировал SMB, правило сработало корректно. Эскалировать всё подряд «потому что High» — завалить L2 шумом и замедлить реакцию на действительно опасный алерт с LSASS.

Триаж алертов SOC — сильный ответ по шагам

Вот ответ, после которого я ставлю «да» в оценке:

Шаг 1 — разделить поток. 40 одинаковых алертов — отдельная группа. LSASS-алерт — отдельный кейс. Приоритет — LSASS на DC01, потому что контроллер домена — crown jewel (критически важный актив сети). Если его скомпрометируют, атакующий получит доступ ко всем учёткам в домене.

Шаг 2 — разобраться с группой из 40. IP 10.20.8.14 — сканер уязвимостей, работающий по расписанию в 02:00? Проверяю в CMDB (база активов) или уточняю у дежурного инженера. Если подтверждается — Benign Positive с комментарием: «Плановое сканирование, IP 10.20.8.14, расписание 02:00–03:00, подтверждено». Создаю тикет на тюнинг правила — добавить IP сканера в исключение с ограничением по времени, чтобы не закрывать тот же алерт каждую ночь.

Шаг 3 — взяться за LSASS. LSASS (Local Security Authority Subsystem Service) — процесс Windows, который хранит учётные данные пользователей в памяти. Обращение к его памяти — техника T1003.001 в MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1003.001 — её идентификаторы для конкретных техник). Тактика — Credential Access (получение учётных данных). Зачем это атакующему: если дампить LSASS на контроллере домена, можно вытащить хеши паролей всех пользователей сети.

Проверяю: какой ПРОЦЕСС обратился к LSASS? svc-backup — сервисная учётная запись бэкапа, которая МОЖЕТ легитимно обращаться к LSASS. Но ключевое — командная строка. Если вижу rundll32.exe comsvcs.dll MiniDump — это не бэкап. Это дамп учётных данных через штатную DLL Windows. Comsvcs.dll — один из LOLBAS-файлов (Living Off the Land Binary — легитимный файл ОС, который атакующий использует как инструмент), задокументированный для техники T1003.001.

Шаг 4 — собрать контекст (30–60 минут вокруг события). На DC01 ищу: Windows Event ID 4624 (успешный вход) и 4625 (неудачный) — кто ещё входил; Event ID 4688 — какие процессы запускались и с какой командной строкой; Event ID 4769 — запросы Kerberos-тикетов (признак горизонтального перемещения по сети); исходящие соединения — есть ли C2-трафик (связь с сервером управления атакой).

index=wineventlog dest=DC01 earliest=-30m latest=+30m
| table _time dest src user EventCode process CommandLine
| sort _time

Этот SPL-запрос (язык запросов Splunk) собирает все Windows-события на DC01 в окне ±30 минут и выводит хронологию с процессами и командными строками. На выходе — таблица из 20–200 строк, по которой видно, что происходило до и после подозрительного обращения к LSASS. Если между входом (4624) и обращением к LSASS появляется powershell.exe -enc (PowerShell с закодированной командой — техника T1059.001, Execution), это серьёзный повод для эскалации.

Шаг 5 — принять решение. Если командная строка и контекст подтверждают легитимный бэкап — Benign Positive с комментарием. Если хоть один признак указывает на атаку — эскалирую на L2 с пакетом: entities (хост, пользователь, процесс), таймлайн, MITRE ID, сырые события, что уже проверил, что прошу сделать L2. Изоляцию контроллера домена L1 самостоятельно не делает — это решение уровня L2/L3.

Подготовка к собеседованию в SOC: Windows Event ID и формула ответа

Шесть Event ID, которые спрашивают всегда

Нюанс, который стоит знать до собеседования: события записываются в журнал Security на Windows. Для Event ID 4688 с командной строкой нужна политика аудита «Audit Process Creation» с параметром «Include command line in process creation events». Без этой настройки поле CommandLine будет пустым — и аналитик останется без главной улики. На интервью об этом спрашивают редко, но если упомянешь сам — это плюс.

Формула ответа на любой кейс собеседования

Каждый кейс для SOC интервью раскладывается по одной структуре:

1. Назвать сущности — хост, пользователь, процесс, IP, MITRE ID. Если поле пустое — сказать, что это проблема парсинга, а не закрытый true positive.
2. Показать, что именно проверишь — сырые события, не дашборд; командная строка, не название алерта.
3. Сказать, что изменит вывод — «если увижу comsvcs.dll MiniDump — true positive; если штатный backup-агент — benign positive».
4. Объяснить, когда эскалируешь — привилегированная учётная запись, критический актив, цепочка техник (Credential Access + Lateral Movement), выход за рамки плейбука.

Эта формула работает на любом кейсе. Запомни её.

Обязанности SOC L1 и escalation процесс SOC

На собеседовании часто просят описать границы роли. Типичная ошибка — заявить, что L1 «расследует инциденты» и «проводит форензику». Нет. Реальные обязанности SOC L1:

• Мониторинг очереди алертов в режиме 24/7 (сменный график)
• Первичный триаж: валидация события, обогащение контекстом, классификация
• Сдерживание (containment) строго по плейбуку — изолировать рабочую станцию через EDR (Endpoint Detection and Response — агент на конечном устройстве, который видит процессы, сетевые соединения и может изолировать хост), заблокировать учётную запись после одобрения
• Эскалация на L2 с пакетом доказательств, когда ситуация выходит за рамки документированного плейбука

Чего L1 НЕ делает самостоятельно: изоляция контроллеров домена, анализ вредоносного ПО, решение о восстановлении, атрибуция атаки.

Границу можно запомнить так: L1 отвечает на вопрос «это реально?», L2 — «насколько далеко зашло?», L3 — «как устроена атака и как её остановить».

Карьера SOC аналитика — сертификация помогает или мешает

Сертификат не мешает. Но создаёт ложное чувство готовности. Security+ учит терминологии — CIA triad (конфиденциальность, целостность, доступность), типы атак, базовые концепции. CySA+ глубже — затрагивает триаж и анализ логов. Ни один экзамен не воспроизводит ситуацию: в очереди 47 карточек, половина — шум сканера, одна — потенциальный дамп паролей с DC, и до конца смены 15 минут.

Что помогает при подготовке к собеседованию в SOC помимо сертификата:

• Практика с реальными логами — BOTS-датасеты от Splunk (Boss of the SOC), лабораторные среды с предзаписанными атаками
• Знание MITRE ATT&CK на уровне тактик (их 14 — от Initial Access до Impact) и умение назвать 5–7 техник с T-кодами
• Привычка проговаривать ход мысли вслух — интервьюер оценивает процесс рассуждения, а не финальный ответ

Каждый третий аналитик, которого я нанял, приходил без единого сертификата — но мог сесть за консоль и показать, как ищет контекст алерта. Каждый пятый с сертификатом не мог ответить, чем Event ID 4624 отличается от 4625.

Я провожу собеседования на SOC L1 три года. Самый стабильный индикатор будущей эффективности — не сертификат, не диплом, не количество пройденных курсов. Это способность кандидата разделить поток алертов на группы, задать правильные вопросы к каждой группе и сформулировать, ЧТО именно изменит его решение. Кандидат, который говорит «проверю командную строку процесса — если comsvcs.dll MiniDump, эскалирую; если штатный backup-агент, закрою как benign positive с комментарием» — уже мыслит как аналитик. Кандидат, который говорит «ложное срабатывание — это когда система ошибается» — пока нет.

Проблема не в сертификатах: Security+ закладывает терминологическую базу, которая объективно нужна. Проблема — в ожидании, что экзамен с вариантами ответов подготовит к работе, где вариантов нет и единственный способ разобраться — открыть сырое событие и прочитать командную строку.

Alert fatigue (усталость от бесконечного потока алертов) — не термин из учебника. Это реальность ночных смен, когда в очереди 300 карточек и хочется закрыть всё одним кликом. Именно в такие моменты пропускают false negative — реальную атаку, которую аналитик не заметил. Час за Splunk с реальным датасетом даёт больше, чем день с флешкартами. На IB Basics показываем, что делать в первый месяц после «хочу в ИБ» — это та структура, которой не хватает между сертификатом и первым рабочим днём в SOC.