🔥 🚒 Планирование Red Team упражнения

Этот документ помогает информировать планирование red team, проводя контраст с очень специфическим стилем red team, описанным в Red Teams. Этот метод выражает несколько предубеждений для оптимизации ценности и энтузиазма blue team. Он специально избегает попыток мотивировать через наказание red team.

Просмотрите вопросы ниже, чтобы проверить, было ли ваше планирование red team тщательно продумано для ценности вашей blue team.

❌ Негативные мотивации

Ниже приведены распространённые причины для проведения red team упражнения. Они имеют разрушительные последствия для морального духа или сплочённости команды. Упражнение может быть неправильным инструментом для ваших целей.

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

👍 Заинтересованные стороны

Нет ничего более расточительного, чем упражнение без спонсорства или последующих действий со стороны руководства или влиятельных лиц. Убедитесь, что результаты упражнения поддерживаются энтузиастичной группой заинтересованных сторон. Убедитесь, что эта группа информирована и может генерировать импульс.

• Установите ожидания и известного ответственного / владельца для достижения результатов упражнения
• Убедитесь, что есть готовность к изменениям, и заручитесь спонсорством для проведения изменений.
• Является ли организация добровольным участником этого упражнения?
• Будут ли участники открыты к любой калибровке риска или пересмотру их текущего плана?
• Есть ли значительный долг, который будет иметь приоритет над любыми выводами Red Team?
• Будут ли выводы Red Team настолько предсказуемы, что упражнение изначально не было нужно?

📅 Оценка времени

Вы можете спроектировать количество времени, которое нужно выделить от этого этапа планирования до конца этапа устранения последствий или чего-то промежуточного. Ожидания по времени сильно зависят от решений, принятых для каждого этапа.

• Планирование (Недели/Месяцы): Планирование общего выполнения, заполнение пробелов этого документа.
• Атака (Минуты/Недели): Онбординг red team и активное создание инцидента.
• Реагирование (Часы/Недели): Если инцидент обнаружен, продолжительность немедленного реагирования.
• Tabletop (Дни/Недели): Если инцидент не обнаружен, продолжительность принудительного реагирования или tabletop.
• Реагирование на инцидент (краткосрочное) (Дни/Недели): Время на удаление доступа red team, устранение обнаруженной уязвимости, ликвидацию противника.
• Раскрытие Red Team (Часы): Демонстрация действий Red Team для калибровки реалий IR.
• Реагирование на инцидент (Post Mortem) (Часы/Дни): Организация извлечённых уроков и широкая презентация.
• Долгосрочное устранение последствий (Недели/Месяцы): Завершение более сложных извлечённых уроков, рефакторинг и рост до того, как вы рассмотрите следующую red team.

👪 Люди

Определите всех людей, которым может потребоваться знать планы и секреты Red Team. Здесь вы захотите смягчить любой риск "Break Glass" и иметь готовые контактные данные для отхода от упражнения в случае любой чрезвычайной ситуации.

• Консалтинговые фирмы: Будете ли вы нанимать внешнюю сторону в качестве red team?
• Внутренние ресурсы: Будут ли внутренние сотрудники выступать в роли red team?
• Кто отвечает (в данном случае за сдерживание) за вызов полиции?
• Кто отвечает за входящие PR / Коммуникации?
• Кто отвечает за взаимодействие с клиентами?
• Кто является ресурсом по уведомлению об утечках? (внутренний / внешний юрист)
• Кто является общим "Game Master", который будет направлять проблемы и быть конечным источником здравого смысла?

📉 Стратегия

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

• Осведомлены ли потенциальные защитники о том, что red team следует ожидать в какой-то момент?
  • Должны ли они быть? Нужно ли вам установить это ожидание?
• Объявите ли вы также окно, в котором следует ожидать red team?
  • Вызовет ли это здоровый азарт и подготовительный спринт?
• Будут ли атакующие сильно направляться с подсказками, или это будет свободная форма?
  • Этот компромисс касается ценности реагирования на инциденты и обнаружения уязвимостей.
• Была ли команда проинформирована о том, что будут строгие правила относительно осуждения?
  • Вы хотите избежать любого ощущения, что это наказание за плохую безопасность.
• Была ли команда проинформирована о том, что это предназначено быть подарком для blue team, а не наказанием за плохую безопасность? Т.е., это не тест, это спарринг?
  • Удвойте акцент на этом. Убедитесь, что известно, что это ценный цикл обратной связи, а не цикл оценки производительности сотрудников.
• Был ли выбран конкретный метод или реалистичная "киберубийственная цепочка" для обрамления упражнения?
• Ваша цель — смоделировать инцидент с сильно смягчённым риском или с риском, имеющим гораздо меньше телеметрии / превентивных мер?
• На каждом этапе, что такое "break glass"? Как вы широко объявите правду и что нужно делать дальше, если red team выйдет из-под контроля и вызовет простой?
• При каких обстоятельствах вы хотите "отозвать" red team?
  • Учитывайте, когда она естественно завершена, внешнее вмешательство требует остановки или когда опыт больше не ценен для участников.

🔧 Дизайн атаки

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

• Требует ли атака большого опыта и усилий, или можно создать простые воссоздания атаки для обнаружения? Нужны ли вообще внешние стороны?
• Где в цепочке атаки должно начинаться действие? (Например, рано: spear phishing, или поздно: lateral movement с правами domain admin)
• Какие учётные данные / физический доступ / документация необходимы для поддержки инициации атаки? Кто их предоставит? Есть ли последствия для безопасности, которые нужно будет устранить позже?
• Если red team преуспевает рано, должны ли они начать пентест или оценку уязвимостей? Должны ли они пытаться быть пойманными?
• Должен ли атакующий подражать конкретному противнику или методу атаки?
• Если red team будет обнаружена, будет ли запасной план или вторая атака? Перейдёт ли red team к пентесту?
• Где и как red team будет документировать своё поведение? Это необходимо для последующего tabletop и подтверждения устранения и извлечённых уроков. Можете ли вы собрать историю bash? Дамп TCP? Ручные заметки?
• Основаны ли методы Red Team на реальности? Используют ли они методы, недоступные реалистичному атакующему?

🚨 Реагирование на инциденты

Если вы можете предвидеть, насколько зрелым будет ваш процесс реагирования, вы можете манипулировать реагированием для большей выгоды. Незрелая команда реагирования может сильно направляться Game Master, а зрелая команда реагирования может быть оставлена для выявления проблемных точек в координации и коммуникации.

• Есть ли конкретный метод или план координации, которому должно следовать реагирование на инциденты? Например, повестка и метод, описанные в Security Breach 101 или An Incident Response Plan for Startups
• Потребуется ли, чтобы реагирование на инциденты собиралось естественным образом, чтобы вы могли выявить трения в его процессе?
• Будет ли реагирование на инциденты собираться искусственно, чтобы насильно отработать предполагаемое реагирование как практику?
• Захотите ли вы искусственно эскалировать инцидент, чтобы контролировать реагирование на инциденты?
• Кто будет мостом связи с Red Team, если у Blue Team возникнут честные вопросы? (Например: "Мы думаем, что обнаружили отдельную утечку")
• Кто будет документировать болевые точки Red Team по мере того, как Blue Team будет устранять их? ("Вы продолжали удалять наши беконны, и нам было трудно вернуться, мы не ожидали, что вы найдёте их все сразу!")
• Если реагирование на инциденты не продвигается своевременно, кто или как будут утекать индикаторы Blue Team?
  • Будет ли это сделано в формате tabletop?
• Собираются ли краткосрочные смягчения / долгосрочные превентивные меры в рамках вашего реагирования на инциденты?

🔍 Раскрытие Red Team

У Blue Team будет множество вопросов к red team. Это может быть моментом волнения, если всё сделано правильно. Поддержание здоровых отношений критически важно. Red team следует рассматривать как бесценного спарринг-партнёра. Ещё лучше — как кролика, за которым нужно гнаться.

• Хорошо ли задокументированы и понятны действия Red Team во время фазы атаки?
• Пропустил ли процесс реагирования на инциденты какие-либо существенные действия Red Team?
• Есть ли какие-либо IOC или артефакты, которые всё ещё маячат или могут быть обнаружены в будущем?
• Пережили ли реагирование на инциденты какие-либо бэкдоры или другие изменения, подверженные риску?
• Насколько тщательными были расследование и локализация Blue Team?

💀 Post Mortem

Качественный post mortem проинформирует о месяцах запланированной работы по безопасности и откалибрует всех на миссию через общий опыт.

• Был ли проведён тщательный процесс собеседований или разбора со всеми участниками упражнения?
• Были ли все последующие пункты устранения собраны централизованно и приоритизированы на основе ценностного мнения участников?
• Формулируются ли эти мнения и представляются ли обратно участникам?
• Запланирована ли встреча для их презентации?
• Кто их представляет?
• Доступна ли Red Team для комментариев по этим мнениям или для ответов на вопросы?
• Получают ли участники вознаграждение за участие?
• Имеют ли они достаточно времени для разбора и обсуждения?
• Является ли это ценной калибровкой по отношению к практическим рискам?

👶 Маленькие упражнения

Вы можете сохранить упражнение небольшим и с минимальным вовлечением других. Будьте креативны.

Просто попросите члена команды смоделировать инцидент, на который, как вы думаете, вы сможете успешно ответить. Например, вы можете установить программное обеспечение с функцией автообновления и притвориться, что это вредоносное ПО. Затем вы будете "охотиться" за "C&C", который на самом деле будет просто его маяком обновления. Например, можете ли вы доказать, что он изолирован на этом хосте, а не на других?

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

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