Task 1. Введение
Ключом к успешному Red Team мероприятию является хорошо скоординированное планирование и коммуникация между всеми участвующими сторонами. В этом номере речь пойдет о различных компонентах участия Red Team, а также о планировании и документировании кампании для участия Red Team.
Участие Red Team бывает разных видов, включая:
Имитации мероприятия ввиде обсуждения за столом.
Имитация противника.
Физическая оценка.
Цели обучения:
Понять компоненты и функции участия Red Team.
Узнайте, как правильно планировать Red Team мероприятие, исходя из потребностей, имеющихся ресурсов и TTPs.
Понимать, как составлять документацию по заданию в соответствии с целями клиента.
Task 2. Определение масштаба мероприятия и целей
Договор между сторонами при промедении Red Teaming мероприятия может быть очень сложным и бюрократическим. Ключом к успешному взаимодействию является четкое определение задач или целей клиента. Цели клиента должны обсуждаться непостредственно между клиентом и командой специалистов, чтобы создать взаимопонимание между обеими сторонами относительно целей и деталей предстоящего мероприятия. Установленные цели являются основой для остальной документации и планирования официального договора.
Без четких и конкретных целей и ожиданий вы готовитесь к очень неструктурированной и незапланированной кампании. Цели задают тон всей остальной работе.
При оценке целей клиента и планировании деталей задания вам часто придется решать, насколько сфокусированными будут действия Red Team.
Задания можно разделить на общие внутренние/сетевые тестирования на проникновение или целенаправленную эмуляцию противника. Целенаправленная имитация противника определяет конкретную APT или группу для имитации атак в рамках мероприятия. Обычно это определяется на основе групп, которые нацелены на конкретные отрасли компании, например, финансовые учреждения и APT38. Внутреннее или сетевое тестирование на проникновение будет иметь схожую структуру, но часто будет менее целенаправленным и будет использовать более стандартные TTP.
Специфика подхода будет зависеть от каждого конкретного случая, определяемого целями клиента.
Цели клиента также повлияют на общие правила проведения и объем задания.
Цели клиента устанавливают только базовое определение целей клиента в отношении задания. Конкретные тонкости договора расширяют цели клиента и определяют специфику договора. Планы договора будут рассмотрены позже в этом номере.
Следующим краеугольным камнем взаимодействия является четко определенный масштаб. Объем работ зависит от организации и от того, как выглядит ее инфраструктура. Обычно в требованиях клиента определяется то, что вы не можете сделать или на что нацелиться, а также то, что вы можете сделать или на что нацелиться. Хотя цели клиента можно обсуждать и определять вместе с командой, предоставляющей услуги, рамки должны устанавливаться только клиентом. В некоторых случаях Red Team может обсудить несогласие с объемом, если это повлияет на проведение мероприятия. Они должны иметь четкое представление о своей сети и последствиях оценки. Конкретные рамки и формулировки всегда будут выглядеть по‑разному, ниже приведен пример того, как могут выглядеть формулировки в со стороны клиента.
Никакой утечки данных.
Производственные серверы запрещены.
10.0.3.8/18 — вне зоны действия.
10.0.0.8/20 находится в зоне действия.
Простои системы не допускаются ни при каких обстоятельствах.
Исчезновение PII (Personally Identifiable Inforemation — личная и конфиденциальная информация сотрудников комании) запрещено.
При анализе задач и масштабов клиента с точки зрения Red Team важно понимать более глубокий смысл и последствия. При анализе вы всегда должны в динамике понимать то, как ваша команда будет подходить к решению проблем/задач. Если необходимо, вы можете написать свои планы в мероприятии или начинать их на основе лишь поверхностного ознакомления с целями и объемом работ клиента.
Task 3. RoE (Rules of Engagement)/Правила проведения Red Teaming мероприятия
Правила проведения Red Team мероприятия (RoE) — это юридически обязывающее изложение целей и объема работ клиента с дальнейшей детализацией ожиданий обеих сторон. Это первый официальный документ в процессе планирования взаимодействия, который требует надлежащего согласования между клиентом и Red Team. Этот документ часто выступает в качестве общего договора между двумя сторонами; также можно использовать внешний договор или другие NDA (соглашение о неразглашении).
Формат и формулировка RoE имеют решающее значение, поскольку это юридически обязывающий контракт и устанавливает четкие ожидания.
Структура каждого RoE определяется клиентом и командой разработчиков и может отличаться по объему и общим разделам. Ниже приведена краткая таблица стандартных разделов, которые вы можете увидеть в RoE.
Название раздела |
Описание раздела |
|
Исполнительное резюме |
Общее резюме всего содержания и авторизации в рамках документа RoE |
|
Цель |
Определяет, почему используется документ RoE |
|
Ссылки |
Любые ссылки, используемые в документе RoE (HIPAA, ISO и т.д.) |
|
Сфера действия |
Заявление о согласии с ограничениями и руководящими принципами |
|
Определения |
Определения технических терминов, используемых во всем документе RoE |
|
Правила взаимодействия и соглашение о поддержке |
Определяет обязательства обеих сторон и общие технические ожидания в отношении поведения при взаимодействии |
|
Положения |
Определяют исключения и дополнительную информацию из Правил взаимодействия |
|
Требования, ограничения и полномочия |
Определяют конкретные ожидания ячейки красной команды |
|
Основные правила |
Определяют ограничения на взаимодействие ячейки красной команды |
|
Разрешение вопросов/Контактные лица |
Содержит весь основной персонал, участвующий в взаимодействии |
|
Авторизация |
Заявление о разрешении на участие в мероприятии |
|
Утверждение |
Подписи обеих сторон, утверждающие все подразделы предыдущего документа |
|
Приложение |
Любая дополнительная информация из предыдущих подразделов |
Анализируя документ, важно помнить, что его цель — быть юридическим документом. В будущем требуется более глубокое планирование и описание мероприятия Red Team для расширения RoE и целей клиента.
Task 4. Планирование кампании
До выполнения этой задачи мы в основном занимались планированием и документированием кампаний с точки зрения бизнеса. При планировании кампании используется информация, полученная и спланированная на основе целей клиента и RoE, и применяется к различным планам и документам, чтобы определить, как и что будет делать Red Team.
Каждая внутренняя Red Team будет иметь свою методологию и документацию для планирования кампании. Мы покажем один подробных планов, который позволяет обеспечить точную коммуникацию и подробную документацию. Сводка кампании, которую мы будем использовать, состоит из четырех различных планов, отличающихся глубиной и охватом, адаптированных из документов Red Team мероприятия. Каждый план можно найти в таблице ниже с кратким объяснением.
Тип плана |
Пояснение к плану |
Содержание плана |
План о заключении договора |
Всеобъемлющее описание технических требований Red Team |
CONOPS, требования к ресурсам и персоналу, временные рамки |
Оперативный план |
Расширение плана о заключении договора. Углубляется в специфику каждой детали |
Операторы, известная информация, обязанности и т.д. |
Технический план мероприятия |
Точные команды для выполнения и время выполнения операции |
Команды для выполнения, временные цели, ответственный оператор и т.д. |
План устранению по недостатков |
Определяет, как будет вестись работа после завершения кампании |
Отчет, консультация по устранению последствий и т. д. |
Task 5. Документация описывающая заключение договора между клиентом и Red Team
Документирование Red Team мероприятия является продолжением планирования кампании, когда идеи и мысли о планировании кампании официально документируются. В этом контексте термин «документ» может быть обманчивым, так как некоторые планы не требуют надлежащего документирования и могут быть простыми, как электронное письмо.
В этом задании мы рассмотрим с технической стороны содержания каждого плана кампании, прежде чем рассматривать сами планы и документы в последующем.
План договора:
Компонент |
Назначение |
|
CONOPS (концепция действий) |
Нетехнически написанный обзор того, как Red Team выполняет задачи клиента |
|
План использования ресурсов |
Включает в себя сроки и информацию, необходимую для успешной работы Red Team - любые требования к ресурсам: персонал, оборудование, облачные требования. |
План действий:
Компонент |
Назначение |
|
Персонал |
Информация о требованиях к работникам |
|
Условия остановки мерпориятия |
Как и почему Red Team должна останавливаться во время выполнения задания |
|
RoE (необязательно) |
- |
|
Технические требования |
Какие знания потребуются Red Team для успешной работы |
План мероприятия:
Компонент |
Назначение |
|
Справочники команд (необязательно) |
Точные команды и инструменты для запуска, включая когда, почему и как. Обычно встречается в больших командах с большим количеством операторов с разным уровнем квалификации |
|
Время выполнения |
Время начала этапов мероприятия. По желанию может включать точное время выполнения инструментов и команд |
|
Обязанности/роли |
Кто, что и когда делает |
План по устранению последствий (необязательно):
Компонент |
Назначение |
|
Отчет |
Краткое изложение деталей взаимодействия и отчет о результатах |
|
Устранение недостатков/консультации |
Как клиент будет устранять обнаруженные недостатки? Это может быть включено в отчет или обсуждаться на встрече между клиентом и Red Team |
Task 6. Концепция действий
Концепция операции (CONOPS) — это часть плана мероприятия, в которой подробно описывается высокоуровневый обзор хода операции; мы можем сравнить ее с отчетом о тестировании на проникновение. Этот документ будет служить в качестве справочной информации для бизнеса/клиента, а также для красной ячейки, от которой можно отталкиваться и расширять дальнейшие планы кампании.
Документ CONOPS должен быть написан с точки зрения полутехнического документа, предполагая, что целевая аудитория/читатель обладает нулевыми или минимальными техническими знаниями. Хотя CONOPS должен быть написан на высоком уровне, вы не должны опускать такие детали, как общий инструментарий, цели мероприятия и т.д. Как и в случае с большинством документов Red Team. Не существует установленного стандарта документа CONOPS. Ниже приведен перечень критических компонентов, которые должны быть включены в CONOPS.
Имя клиента
Поставщик услуг
Сроки
Общие цели/фазы
Другие цели обучения (эксфильтрация)
Высокоуровневые инструменты/техники, которые планируется использовать
Группа угроз для имитации (если есть)
Ключом к написанию и пониманию CONOPS является предоставление достаточного количества информации, чтобы получить общее представление обо всех происходящих событиях. CONOPS должна быть легко читаемой и содержать четкие определения и пункты, которые читатели могут легко усвоить.
Task 7. План использования ресурсов
План использования ресурсов — это второй документ плана, в котором подробно описываются даты, необходимые знания (необязательно), требования к ресурсам. План расширяет CONOPS и включает конкретные детали, такие как даты, требуемые знания и т. д.
В отличие от CONOPS, план ресурсов не должен быть написан в виде документа, вместо этого он должен быть написан в виде маркированных списков подразделов. Как и в большинстве документов Red Team, не существует документов или стандартного набора шаблонов плана использования ресурсов. Ниже приведены примеры подразделов плана использования ресурсов.
-
Заголовок
Персонал
Даты
Клиеты
-
Даты проведения мероприятия
Даты проведения разведки
Даты первоначального компрментации
Даты постэксплуатации и сохранения в системе
Другие даты
-
Необходимые знания (по выбору)
Разведка
Начальная компрометация
Пост-эксплуатация
-
Требования к ресурсам
Персонал
Аппаратное обеспечение
Облако
Разное
Ключом к написанию и пониманию плана ресурсов является предоставление достаточного количества информации, чтобы собрать все необходимое, но при этом не стать чрезмерно навязчивым. Документ должен быть прямым и четко определять, что необходимо.
Task 8. План операций
План операций — это гибкий документ (документы), в котором содержатся конкретные детали взаимодействия и происходящих действий. План расширяет текущую CONOPS и должен включать большую часть информации о конкретных действиях. Сюда также можно поместить ROE, в зависимости от глубины и структуры ROE.
План операций должен быть составлен по схеме, аналогичной схеме составления плана использования ресурсов, с использованием маркированных списков и небольших подразделов. Как и в случае с другими документами Red Team, стандартного набора шаблонов плана операций или документов не существует. Ниже приведены примеры подразделов плана операций.
-
Заголовок
Персонал
Даты
Клиент
Условия остановки/приостановки мероприятия (могут быть помещены в ROE в зависимости от глубины)
Требуемый/назначенный персонал
Конкретные TTP и планируемые атаки
План связи Red Team
Правила проведения мероприятия (необязательно)
Наиболее заметным дополнением к этому документу является план связи Red Team. В плане связи должно быть кратко описано, как красная ячейка будет общаться с другими ячейками и клиентом в целом. У каждой команды будет свой предпочтительный метод общения с клиентами. Ниже приведен список возможных вариантов, которые выберет команда для общения.
vectr.io
Электронная почта
Slack
Task 8. План мероприятия
План мероприятия — это документ для конкретной ячейки, в котором подробно описаны точные действия, которые должны выполнить операторы. В документе используется информация из предыдущих планов и назначаются действия.
То, как составлен и детализирован документ, зависит от команды, поскольку это документ для внутреннего пользования, структура и детализация имеют меньшее влияние. Как и в случае со всеми документами, изложенными в этом номере, представление может быть различным. Этот план может быть простым, как рассылка по электронной почте всем операторам. Ниже приведен список минимальных деталей, которые красные ячейки должны включить в план.
Цели
Операторы
Эксплойты/атаки
Цели (пользователи/машины/объекты)
Варианты выполнения плана
Эти два плана можно рассматривать одинаково. План операций следует рассматривать с точки зрения бизнеса и клиента, а план мероприятия — с точки зрения оператора и красной ячейки.