Як я пояснюю свої висновки на брифінгу в SOC?

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

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

Використовуйте перевернену пірамід: почніть з висновку, потім підтримайте його. Менеджер або дежурний керівник, який заходить на ваш брифінг, повинні отримати відповідь на питання «ми скомпрометовані та чи мені потрібно діяти» протягом перших десяти секунд, а не похованої в деталях захоплення пакетів на шостій хвилині.

Працюючий структура:

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

Уникайте розповіді про процес вашого розслідування («спочатку я перевірив консоль EDR, потім я розпочав пошук в логах DNS») якщо хтось конкретно не запитав, як ви туди потрапили. Це ваш метод, а не їхня проблема. Збережіть це для письмового звіту чи подальшого слідування фахівців.

Написання передач змін, які не втрачають контекст

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

Добра замітка передачі змін включає:

• Номер квитка/справи та поточний статус (відкрито, моніторинг, очікування відповіді)
• Що запустило розслідування
• Що було підтверджено порівняно з тим, що все ще є гіпотезою
• Конкретна наступна дія та хто за неї відповідає
• Будь-які перешкоди (очікування на змену брандмауера, очікування зворотного дзвінка користувача)

Приклад слабкої лінії передачі: «Дослідив сповіщення на HOST-2231, виглядає підозріло, перевірю завтра.»

Приклад сильної: «HOST-2231 запустив Sigma правило для доступу LSASS неsottoscritto бінарним файлом (процес: update.exe, хеш: 3f2c...). Підтверджено EDR, що дамп пам'яті не відбувся. Користувач в офісі до 9 ранку — інтерв'ю ще не було. Наступний крок: витягнути артефакти prefetch та sched task, змінити статус на IR, якщо бінарний файл збігається з відомим варіантом Mimikatz.»

Другий варіант дозволяє наступному аналітику діяти негайно без переробки вашої роботи.

Питання сценаріїв співбесід: що вони насправді тестують

Коли інтерв'юер говорить «розповідайте, як ви б розслідували сповіщення про фішинг», вони не оцінюють, чи ви знаєте правильні назви інструментів. Вони перевіряють, чи у вас є повторюваний процес та чи можете ви розповісти про своє мислення вголос під легким тиском — що саме потрібне на справжній зміні.

Структуруйте свою відповідь так, як ви б структурували сам інцидент:

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

Інтерв'юери звертають увагу, коли кандидати говорять абсолютами без розгалуженої логіки. Справжні розслідування умовні: «якщо X, то Y; якщо ні, то Z.» Показ цього розгалуження коштує більше, ніж декламування всіх джерел логів, які ви коли-небудь чули.

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

Керівнику фінансового відділу не потрібно чути «бічний рух через передачу хешу, спрямований на контролер домену.» Їм потрібно «зловмисник використав украдені облікові дані, щоб спробувати отримати доступ до системи, яка контролює доступ для всієї компанії; ми це блокували, перш ніж це вдалося.» Тримайте технічну версію доступною в додатку чи подальшому документі для людей, які запитають, але розпочніть розмови з простою мовою про бізнес-вплив: гроші, час простою, витік даних, нормативний вплив.

Одна звичка, яка допомагає у всіх трьох контекстах — брифінгах, передачах змін та інтерв'ю — це написання одного речення-резюме перед тим, як ви напишете щось інше. Якщо ви не можете стиснути ситуацію в одне речення, ви її досить не розумієте, щоб пояснити комусь іншому.

Для отримання додаткової інформації про структурування звітів про інциденти та підготовку до співбесід, специфічні для ролей синьої команди, перевірте пов'язані сегменти Korra Studio про написання звітів та практику співбесід аналітика SOC.