Как объяснить свои находки на брифинге в SOC?

Технические навыки дают вам анализ. Коммуникация дает вам доверие, финансирование и работу. Аналитики, которые могут объяснить, что произошло, почему это важно и что делать дальше, неизменно превосходят коллег с более глубокими знаниями инструментов, но неспособных донести суть.

Структурирование брифинга по инциденту

Используйте перевернутую пирамиду: начните с выводов, затем подкрепите их. Менеджер или дежурный руководитель, вошедший на ваш брифинг, должны получить ответ на вопрос "скомпрометированы ли мы и нужно ли действовать" в первые десять секунд, а не в деталях захвата трафика на шестой минуте.

Рабочая структура:

1. Что произошло — одно предложение. "Рабочая станция в финансовом отделе выполнила вредоносный макрос и отправила сигнал на внешний IP-адрес."
2. Влияние на данный момент — масштаб, затронутые системы, данные, к которым был получен доступ или нет.
3. Что мы сделали — изоляция, блокировка, уже предпринятые меры сдерживания.
4. Что нам нужно — решения, ресурсы или одобрения от присутствующих.
5. Хронология — краткий список в хронологическом порядке для тех, кому нужны детали, отделенный от основного резюме.

Избегайте рассказа о процессе вашего расследования ("сначала я проверил консоль EDR, затем перешел на логи DNS"), если кто-то специально не спросит, как вы туда пришли. Это ваш метод, а не их проблема. Сохраните это для письменного отчета или последующей встречи с экспертами.

Написание передач смены, которые не теряют контекст

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

Хороший заметка передачи включает:

• ID тикета/случая и текущий статус (открыто, мониторится, ожидание ответа)
• Что спровоцировало расследование
• Что подтверждено и что остается гипотезой
• Конкретное следующее действие и кто за него отвечает
• Любые блокираторы (ожидание изменения брандмауэра, ожидание перезвона пользователя)

Пример слабой строки передачи: "Посмотрел на алерт HOST-2231, похоже подозрительно, завтра проверю."

Пример хорошей: "HOST-2231 сработал Sigma rule для доступа к LSASS от неподписанного бинарника (proc: update.exe, hash: 3f2c...). Подтверждено EDR, что дампа памяти не произошло. Пользователь вернется в 9am — интервью еще не было. Следующий шаг: извлечь артефакты prefetch и sched task, эскалировать в IR если бинарник совпадает с известным вариантом Mimikatz."

Вторая версия позволяет следующему аналитику действовать немедленно, не повторяя вашу работу.

Вопросы сценариев интервью: что они на самом деле проверяют

Когда интервьюер говорит "расскажи, как ты бы расследовал фишинг-алерт", он не оценивает, знаешь ли ты правильные названия инструментов. Он проверяет, есть ли у тебя повторяемый процесс и можешь ли ты рассказать свое рассуждение вслух под небольшим давлением — что и требуется на реальной смене.

Структурируй ответ так же, как ты структурировал бы сам инцидент:

• Сначала сформулируй приоритет триажа (это сдерживается, это распространяется, это кандидат на ложное срабатывание)
• Назови конкретные артефакты, которые ты вытащил бы (заголовки письма, репутация отправителя, детонация URL в песочнице, изменения правил почтовых ящиков)
• Скажи, что изменит твой следующий шаг ("если детонация в песочнице показывает страницу сбора учетных данных, я немедленно проверю успешную аутентификацию этого пользователя за последние 24 часа")
• Заверши критериями эскалации — что заставляет тебя классифицировать это как подтвержденный инцидент или закрыть как безопасное

Интервьюеры замечают, когда кандидаты говорят в абсолютах без ветвящейся логики. Реальные расследования условны: "если X, то Y; если нет, то Z." Демонстрация такого ветвления стоит больше, чем перечисление каждого источника логов, который ты когда-либо слышал.

Перевод для нетехнических заинтересованных лиц

CFO не нужно слышать "боковое движение через pass-the-hash, нацеленное на контроллер домена." Ему нужно "злоумышленник использовал украденные учетные данные для попытки доступа к системе, которая управляет доступом для всей компании; мы заблокировали это до того, как это удалось." Держите техническую версию доступной в приложении или последующем документе для людей, которые спросят, но начните разговоры с простым бизнес-воздействием: деньги, простой, утечка данных, нормативное воздействие.

Одна привычка, которая помогает во всех трех контекстах — брифинги, передачи и интервью — писать одну рему в начале, прежде чем писать что-либо еще. Если ты не можешь сжать ситуацию в одно предложение, ты недостаточно хорошо ее понимаешь, чтобы объяснить кому-либо еще.

Для большего о структурировании отчетов об инцидентах и подготовке к интервью для ролей синей команды смотри связанные сегменты Korra Studio по написанию отчетов и практике интервью аналитика SOC.