Task 1. Введение

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

Участие Red Team бывает разных видов, включая:

  1. Имитации мероприятия ввиде обсуждения за столом.

  2. Имитация противника.

  3. Физическая оценка.

Цели обучения:

  1. Понять компоненты и функции участия Red Team.

  2. Узнайте, как правильно планировать Red Team мероприятие, исходя из потребностей, имеющихся ресурсов и TTPs.

  3. Понимать, как составлять документацию по заданию в соответствии с целями клиента.

Task 2. Определение масштаба мероприятия и целей

Договор между сторонами при промедении Red Teaming мероприятия может быть очень сложным и бюрократическим. Ключом к успешному взаимодействию является четкое определение задач или целей клиента. Цели клиента должны обсуждаться непостредственно между клиентом и командой специалистов, чтобы создать взаимопонимание между обеими сторонами относительно целей и деталей предстоящего мероприятия. Установленные цели являются основой для остальной документации и планирования официального договора.

Без четких и конкретных целей и ожиданий вы готовитесь к очень неструктурированной и незапланированной кампании. Цели задают тон всей остальной работе.

При оценке целей клиента и планировании деталей задания вам часто придется решать, насколько сфокусированными будут действия Red Team.

Задания можно разделить на общие внутренние/сетевые тестирования на проникновение или целенаправленную эмуляцию противника. Целенаправленная имитация противника определяет конкретную APT или группу для имитации атак в рамках мероприятия. Обычно это определяется на основе групп, которые нацелены на конкретные отрасли компании, например, финансовые учреждения и APT38. Внутреннее или сетевое тестирование на проникновение будет иметь схожую структуру, но часто будет менее целенаправленным и будет использовать более стандартные TTP.

Специфика подхода будет зависеть от каждого конкретного случая, определяемого целями клиента.

Цели клиента также повлияют на общие правила проведения и объем задания.

Цели клиента устанавливают только базовое определение целей клиента в отношении задания. Конкретные тонкости договора расширяют цели клиента и определяют специфику договора. Планы договора будут рассмотрены позже в этом номере.

Следующим краеугольным камнем взаимодействия является четко определенный масштаб. Объем работ зависит от организации и от того, как выглядит ее инфраструктура. Обычно в требованиях клиента определяется то, что вы не можете сделать или на что нацелиться, а также то, что вы можете сделать или на что нацелиться. Хотя цели клиента можно обсуждать и определять вместе с командой, предоставляющей услуги, рамки должны устанавливаться только клиентом. В некоторых случаях Red Team может обсудить несогласие с объемом, если это повлияет на проведение мероприятия. Они должны иметь четкое представление о своей сети и последствиях оценки. Конкретные рамки и формулировки всегда будут выглядеть по‑разному, ниже приведен пример того, как могут выглядеть формулировки в со стороны клиента.

  1. Никакой утечки данных.

  2. Производственные серверы запрещены.

  3. 10.0.3.8/18 — вне зоны действия.

  4. 10.0.0.8/20 находится в зоне действия.

  5. Простои системы не допускаются ни при каких обстоятельствах.

  6. Исчезновение 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.

  1. Имя клиента

  2. Поставщик услуг

  3. Сроки

  4. Общие цели/фазы

  5. Другие цели обучения (эксфильтрация)

  6. Высокоуровневые инструменты/техники, которые планируется использовать

  7. Группа угроз для имитации (если есть)

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

Task 7. План использования ресурсов

План использования ресурсов — это второй документ плана, в котором подробно описываются даты, необходимые знания (необязательно), требования к ресурсам. План расширяет CONOPS и включает конкретные детали, такие как даты, требуемые знания и т. д.

В отличие от CONOPS, план ресурсов не должен быть написан в виде документа, вместо этого он должен быть написан в виде маркированных списков подразделов. Как и в большинстве документов Red Team, не существует документов или стандартного набора шаблонов плана использования ресурсов. Ниже приведены примеры подразделов плана использования ресурсов.

  1. Заголовок

    • Персонал

    • Даты

    • Клиеты

  2. Даты проведения мероприятия

    • Даты проведения разведки

    • Даты первоначального компрментации

    • Даты постэксплуатации и сохранения в системе

    • Другие даты

  3. Необходимые знания (по выбору)

    • Разведка

    • Начальная компрометация

    • Пост-эксплуатация

  4. Требования к ресурсам

    • Персонал

    • Аппаратное обеспечение

    • Облако

    • Разное

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

Task 8. План операций

План операций — это гибкий документ (документы), в котором содержатся конкретные детали взаимодействия и происходящих действий. План расширяет текущую CONOPS и должен включать большую часть информации о конкретных действиях. Сюда также можно поместить ROE, в зависимости от глубины и структуры ROE.

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

  1. Заголовок

    • Персонал

    • Даты

    • Клиент

  2. Условия остановки/приостановки мероприятия (могут быть помещены в ROE в зависимости от глубины)

  3. Требуемый/назначенный персонал

  4. Конкретные TTP и планируемые атаки

  5. План связи Red Team

  6. Правила проведения мероприятия (необязательно)

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

  1. vectr.io

  2. Электронная почта

  3. Slack

Task 8. План мероприятия

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

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

  1. Цели

  2. Операторы

  3. Эксплойты/атаки

  4. Цели (пользователи/машины/объекты)

  5. Варианты выполнения плана

Эти два плана можно рассматривать одинаково. План операций следует рассматривать с точки зрения бизнеса и клиента, а план мероприятия — с точки зрения оператора и красной ячейки.

Комментарии (0)