Как отвечать на собеседовании в SOC: почему вопрос про PowerShell проверяет не знания, а порядок действий

Алерт, который читает комиссия: документ Word запустил PowerShell с длинной командой в base64. «Расскажите, что будете делать». Кандидат знает, почему это плохо — родительский и дочерний процессы не совпадают, кодировка обычно означает, что команду прячут, — и отвечает уверенно: индикатор зловредный, блокирую исходный IP, изолирую хост. Комиссия кивает, тянет паузу и спрашивает: «Изолировать какой хост? Он один?»

Ответа нет. Человек рванул к реакции, не установив, на что именно реагирует, и теперь собирает картину по кускам прямо перед людьми, которые решают, брать его или нет.

Пробел здесь не в знаниях. Закодированный PowerShell, запущенный из Office, узнает любой, кто сидел в этом кресле хоть раз. Проверяют другое: есть ли у вас повторяемый процесс, который вы запустите в два часа ночи на настоящем инциденте, когда рядом нет ни лектора, ни времени подумать.

Что именно ломает типичный ответ

Смотрите, что произошло: кандидат перескочил шаг и начал с вывода. Хост изолировать — вывод. Но изоляция хоста отвечает на вопрос «что делать», а до него нужно ответить на «что случилось». В реальной смене такой прыжок стоит дорого: вы блокируете один узел, а через час выясняется, что та же команда пробежала ещё по девяти машинам, и всё это время вы держали глаза закрытыми на остальные восемь.

Панель ждёт не список инструментов. Она слушает, в каком порядке вы раскладываете неопределённость.

Четыре шага, которых не хватает в ответе

Порядок важен: каждый следующий шаг опирается на предыдущий, а не наоборот.

1. Scope — что вообще задето

Первый вопрос, который вы задаёте себе, а не комиссии: это один хост или несколько? Один пользователь или картина по многим? И как далеко назад уходит активность — свежее событие или оно тянется неделю и всплыло только сейчас. Здесь и живёт ответ про «какой хост»: вы сначала очерчиваете область, потом трогаете что-то внутри неё.

2. Context — есть ли у этого законное место

Дальше вы проверяете, ожидаемо ли такое поведение в этой среде: скрипт администратора по расписанию, известный инструмент развёртывания — или у процесса нет ни одной причины существовать в базовой линии конкретного хоста. Понимание базовой линии — то, что отличает аналитика, который разбирает инцидент, от аналитика, который листает гугл во время разбора.

3. Decision — когда эскалировать, а когда закрывать

Нужно вслух назвать, что сделало бы событие безобидным и что заставляет поднимать его прямо сейчас. Для закодированного PowerShell, который породил Word, безобидной версии обычно нет — так и скажите и переходите к эскалации, вместо того чтобы откладывать решение на потом.

4. Escalation — что вы передаёте дальше

Дерево процессов, точные метки времени, список затронутых хостов и конкретная причина, по которой вы считаете событие небезобидным. Следующему человеку не должно понадобиться повторять ваши первые десять минут работы.

Как это звучит вслух

Технически то же самое, что и в неудачном ответе, но порядок другой:

«Сначала определю область: по этой команде в base64 и по родительскому процессу Winword проверю, сколько хостов и пользователей задето и насколько вглубь уходит активность. Потом посмотрю контекст: есть ли у закодированного PowerShell из Word причина быть на этой машине в её базовой линии — по опыту, нет. Поэтому решение — эскалация сейчас, без ожидания. На L2 передам дерево процессов, точные метки, список затронутых хостов и причину, по которой считаю событие небезобидным».

Тот же технический инстинкт, но звучит как процесс, а не как догадка. Именно так и устроена работа SOC: свежий алерт на L1, детект и суждение об эскалации уровня L3.

Ошибки, которые ломают даже правильный ответ

• Начать с блокировки. Блокировка IP или изоляция хоста — действие внутри области, а не описание области. Сначала границы, потом действия.
• Смешать контекст и решение. «Это подозрительно» — это ещё не решение. Комиссии нужна фраза про то, что вы делаете: эскалируете или закрываете как ложное срабатывание.
• Свалить всё в один поток речи. Четыре шага — это не скороговорка одной фразой, а четыре короткие остановки, из которых понятно, что вы движетесь по шаблону, а не по наитию.
• Забыть про передачу. Многие доходят до «эскалирую» и останавливаются. Что именно вы кладёте на стол следующему — половина оценки.
• Проговорить дерево процессов без цели. Детали нужны не сами по себе, а как доказательство: почему вы не считаете это штатным скриптом администратора.

Где схема не работает

Если вопрос на интервью не про разбор алерта, а про архитектуру детектирования — например, «как бы вы написали правило на такое поведение», — порядок другой: сначала логика обнаружения, потом то, как вы будете копать срабатывания. Четыре шага заточены под живой инцидент, а не под проектирование правил.

И ещё: механически проговаривать «scope, context, decision, escalation» без технической начинки — тот же провал, только с другой стороны. Схема нужна, чтобы ваш технический инстинкт прозвучал внятно, а не чтобы заменить его.

Если из всей статьи держать в голове одну вещь — пусть это будет вопрос «а сколько их ещё?». Он один вытягивает и область, и контекст, и решение, и то, что вы передадите дальше.