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

Кто на самом деле сидит в комнате

На первом собеседовании на роль аналитика кибербезопасности редко присутствует только HR. Ожидайте, что с самого начала в звонке будет руководитель SOC или старший аналитик, потому что важные вопросы не может задать тот, кто сам не разбирал алерты. В небольших компаниях можете получить сразу CISO. В крупных часто сначала идёт технический скрининг (старший аналитик или тимлид, 30-45 минут, упор на сценарии), а затем панель, которая включает менеджера по найму и иногда кого-то из IT-операций или команды платформы, с которой вы будете работать — потому что большая часть работы это эскалация и передача дел, а не только детектирование.

Если компания ведёт зрелый SOC, вы также можете встретиться с тем, кто отвечает за SIEM (Splunk, Microsoft Sentinel, QRadar, Elastic) и с тем, кто отвечает за EDR (CrowdStrike, Defender for Endpoint, SentinelOne). Они задают разные вопросы, потому что их беспокоят разные типы отказов: владелец SIEM хочет знать, умеете ли вы писать запросы, которые не мусор; владелец EDR хочет знать, не будете ли вы гоняться за безобидным PowerShell-скриптом два часа, потому что не проверили родительский процесс сначала.

Техническое задание: как оно выглядит

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

• Триаж алертов в изолированном SIEM или в наборе скриншотов. Вам дают несколько алертов — вход из необычной географической точки, всплеск исходящих DNS-запросов, детект EDR с меткой «подозрительный», а не «вредоносный» — и просят сказать, какие вы бы эскалировали, какие закрыли и почему. Интервьюер следит за порядком вашего рассуждения, а не за финальным ответом.
• Pcap или фрагмент логов. Вам могут дать вывод Wireshark или сырые логи файрвола и попросить восстановить, что произошло: это сканирование портов, неудачный брутфорс, C2-маячки с нестандартным интервалом. Некоторые компании заменяют это фишинговым письмом с заголовками и просят прочитать цепочку Received и оценить результаты SPF/DKIM/DMARC.
• Настольный сценарий инцидента. «Записка о вымогателе появляется на ноутбуке финансиста в 16:00 пятницы. Опишите следующий час». Это проверяет, знаете ли вы структуру жизненного цикла инцидента из NIST 800-61 — идентификация, изоляция, ликвидация, восстановление, извлечённые уроки — не декламируя её списком. Хорошие кандидаты изолируют хост до того, как начнут спрашивать, кто отвечает.
• Домашнее задание, реже сейчас, чем несколько лет назад. Обычно письменный отчёт об инциденте на основе данного набора логов или короткая модель угроз для гипотетической системы. Если вы его получили, интервьюеры проверяют, умеете ли вы писать для тех, кто не был в комнате — потому что отчёты об инцидентах читают люди, которых не было на звонке.

Что редко проверяют, несмотря на то, что предполагают общие руководства по собеседованиям, это можете ли вы процитировать модель OSI или дать определение «нулевого доверия» по памяти. Это всплывает максимум как разминочные вопросы. Упражнение существует, чтобы увидеть, что вы делаете, когда алерт неоднозначен, потому что большинство алертов неоднозначны.

Вопросы, которые на самом деле проверяют компетентность

Некоторые вопросы звучат как светская беседа, но это не так. Вот что они на самом деле проверяют:

«Расскажите о последнем ложном срабатывании, которое вы закрыли». Это не тест на память. Это проверяет, понимаете ли вы почему это было ложное срабатывание — механизм, а не просто метку — и настроили ли вы что-нибудь после этого или просто нажали «закрыть». Аналитик, который не может описать настройку правила детектирования или подавление шумного источника, недостаточно долго выполнял работу, чтобы снизить шум, который он генерирует.

«Каков ваш процесс, когда вы получаете алерт, который не понимаете?» Они слушают последовательность: проверить актив (это контроллер домена или чей-то ноутбук), проверить нормальное поведение учётной записи, вытащить связанные события в окне по обе стороны от алерта, проверить, появляется ли IOC где-то ещё, затем решить. Если ответ сразу прыгает к «я бы это эскалировал», это красный флаг для опытного интервьюера, потому что эскалировать всё — это то, что делает тот, кто не знает, как расследовать.

«Расскажите о случае, когда вы ошиблись насчёт инцидента». Это намеренно неудобный вопрос. Аналитики, которые работали только с тикетами, а не с настоящими инцидентами, часто не имеют ответа, потому что ошибиться означает принять решение в условиях неопределённости. Интервьюеры используют это, чтобы отделить людей, следовавших инструкции, от тех, кому приходилось принимать решение в 2 часа ночи при неполной информации.

«Как вы поддерживаете актуальность threat intel и как это меняет то, на что вы смотрите?» Не «читаете ли вы блоги». Они хотят знать, можете ли вы назвать конкретный фид или источник (исследование угроз вендора, ISAC, внутренний список IOC из предыдущего инцидента) и, что важнее, привести пример детектирования или охоты, которые вы построили из-за того, что прочитали — а не просто подписались на рассылку.

Вопросы о MITRE ATT&CK обычно не просят вас процитировать ID тактик. Они проверяют, используете ли вы это как рабочий инструмент: можете ли вы соотнести наблюдаемую технику (скажем, T1053 для злоупотребления запланированными задачами) с тем, что вы ожидали бы увидеть следующим в цепочке, и узнали бы вы это, если бы увидели.

Как звучит поверхностный ответ

Для того, кто реально управляет SOC, вот признаки:

• Описывать детектирование полностью в терминах инструментов («мы использовали Splunk и CrowdStrike») без упоминания того, что вы искали или какой была логика запроса. Назвать SIEM — не то же самое, что показать, что вы можете им пользоваться.
• Отвечать на вопрос «каков процесс реагирования на инциденты» перечислением фаз NIST по порядку без примера. Заучить шесть слов может любой. Интервьюеру нужен один инцидент, где изоляция была сложнее, чем описано в учебнике — потому что production-система, которую нельзя просто выдернуть из сети, или скомпрометированная учётная запись, которая также является учёткой, под которой работает критический сервис — вот где настоящее суждение.
• Трактовать каждый сценарий так, будто ответ — «эскалировать команде реагирования на инциденты», не демонстрируя, что вы знаете, что эта команда хотела бы получить сначала: охват, затронутые хосты, время первого индикатора, началась ли уже изоляция.
• Путать управление уязвимостями с детектированием. Когда спрашивают про CVE, а вы можете сказать только «мы бы это пропатчили» без упоминания компенсирующих контролей, подверженности или эксплуатируемости в вашей среде — это предполагает, что вы не сидели на встречах по приоритизации патчей.
• Говорить о сертификатах (Security+, CySA+, GCIH, OSCP) как о достижениях, а не как о свидетельстве конкретной способности. Интервьюер, у которого самого есть GCIH, спросит, что вы делали в лабах, а не сдали ли вы.

Что сделать перед следующим собеседованием

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

Если вы подаёте заявки на несколько ролей в SOC или аналитиков одновременно, и объявления просят слегка разные комбинации инструментов (здесь Sentinel, там QRadar, SOAR-платформа, которую вы трогали только раз), jobmarket.pro читает каждое объявление полностью и готовит заявку из вашего реального опыта, не выдумывая знакомство с инструментами, которые вы не использовали.