Алерт, который читает комиссия: документ Word запустил PowerShell с длинной командой в base64. «Расскажите, что будете делать». Кандидат знает, почему это плохо — родительский и дочерний процессы не совпадают, кодировка обычно означает, что команду прячут, — и отвечает уверенно: индикатор зловредный, блокирую исходный IP, изолирую хост. Комиссия кивает, тянет паузу и спрашивает: «Изолировать какой хост? Он один?»
Ответа нет. Человек рванул к реакции, не установив, на что именно реагирует, и теперь собирает картину по кускам прямо перед людьми, которые решают, брать его или нет.
Пробел здесь не в знаниях. Закодированный PowerShell, запущенный из Office, узнает любой, кто сидел в этом кресле хоть раз. Проверяют другое: есть ли у вас повторяемый процесс, который вы запустите в два часа ночи на настоящем инциденте, когда рядом нет ни лектора, ни времени подумать.
Что именно ломает типичный ответ
Смотрите, что произошло: кандидат перескочил шаг и начал с вывода. Хост изолировать — вывод. Но изоляция хоста отвечает на вопрос «что делать», а до него нужно ответить на «что случилось». В реальной смене такой прыжок стоит дорого: вы блокируете один узел, а через час выясняется, что та же команда пробежала ещё по девяти машинам, и всё это время вы держали глаза закрытыми на остальные восемь.
Панель ждёт не список инструментов. Она слушает, в каком порядке вы раскладываете неопределённость.
Четыре шага, которых не хватает в ответе
Порядок важен: каждый следующий шаг опирается на предыдущий, а не наоборот.
1. Scope — что вообще задето
Первый вопрос, который вы задаёте себе, а не комиссии: это один хост или несколько? Один пользователь или картина по многим? И как далеко назад уходит активность — свежее событие или оно тянется неделю и всплыло только сейчас. Здесь и живёт ответ про «какой хост»: вы сначала очерчиваете область, потом трогаете что-то внутри неё.
2. Context — есть ли у этого законное место
Дальше вы проверяете, ожидаемо ли такое поведение в этой среде: скрипт администратора по расписанию, известный инструмент развёртывания — или у процесса нет ни одной причины существовать в базовой линии конкретного хоста. Понимание базовой линии — то, что отличает аналитика, который разбирает инцидент, от аналитика, который листает гугл во время разбора.
3. Decision — когда эскалировать, а когда закрывать
Нужно вслух назвать, что сделало бы событие безобидным и что заставляет поднимать его прямо сейчас. Для закодированного PowerShell, который породил Word, безобидной версии обычно нет — так и скажите и переходите к эскалации, вместо того чтобы откладывать решение на потом.
4. Escalation — что вы передаёте дальше
Дерево процессов, точные метки времени, список затронутых хостов и конкретная причина, по которой вы считаете событие небезобидным. Следующему человеку не должно понадобиться повторять ваши первые десять минут работы.
| Этап | Вопрос, на который отвечаете | Что уходит дальше |
|---|---|---|
| Scope | Один хост или несколько, один пользователь или закономерность, как глубоко по времени | Список затронутых узлов и границы инцидента |
| Context | Это нормальная активность для этой машины или аномалия на её базовой линии | Аргумент «почему это выглядит чужим здесь» |
| Decision | Что делает событие безобидным и что требует эскалации немедленно | Явная формулировка решения |
| Escalation | Что именно передать и с какой формулировкой | Дерево процессов, метки времени, список хостов, причина |
Как это звучит вслух
Технически то же самое, что и в неудачном ответе, но порядок другой:
«Сначала определю область: по этой команде в base64 и по родительскому процессу Winword проверю, сколько хостов и пользователей задето и насколько вглубь уходит активность. Потом посмотрю контекст: есть ли у закодированного PowerShell из Word причина быть на этой машине в её базовой линии — по опыту, нет. Поэтому решение — эскалация сейчас, без ожидания. На L2 передам дерево процессов, точные метки, список затронутых хостов и причину, по которой считаю событие небезобидным».
Тот же технический инстинкт, но звучит как процесс, а не как догадка. Именно так и устроена работа SOC: свежий алерт на L1, детект и суждение об эскалации уровня L3.
Ошибки, которые ломают даже правильный ответ
- Начать с блокировки. Блокировка IP или изоляция хоста — действие внутри области, а не описание области. Сначала границы, потом действия.
- Смешать контекст и решение. «Это подозрительно» — это ещё не решение. Комиссии нужна фраза про то, что вы делаете: эскалируете или закрываете как ложное срабатывание.
- Свалить всё в один поток речи. Четыре шага — это не скороговорка одной фразой, а четыре короткие остановки, из которых понятно, что вы движетесь по шаблону, а не по наитию.
- Забыть про передачу. Многие доходят до «эскалирую» и останавливаются. Что именно вы кладёте на стол следующему — половина оценки.
- Проговорить дерево процессов без цели. Детали нужны не сами по себе, а как доказательство: почему вы не считаете это штатным скриптом администратора.
Где схема не работает
Если вопрос на интервью не про разбор алерта, а про архитектуру детектирования — например, «как бы вы написали правило на такое поведение», — порядок другой: сначала логика обнаружения, потом то, как вы будете копать срабатывания. Четыре шага заточены под живой инцидент, а не под проектирование правил.
И ещё: механически проговаривать «scope, context, decision, escalation» без технической начинки — тот же провал, только с другой стороны. Схема нужна, чтобы ваш технический инстинкт прозвучал внятно, а не чтобы заменить его.
Если из всей статьи держать в голове одну вещь — пусть это будет вопрос «а сколько их ещё?». Он один вытягивает и область, и контекст, и решение, и то, что вы передадите дальше.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.