Red Team vs Penetration Testing vs Vulnerability Assessment: разница

Главная сравнительная таблица

Запомнить одной таблицей — VA широко, но неглубоко; пентест глубоко, но узко; Red Team — весь периметр плюс люди плюс физика.

Vulnerability Assessment: что это и когда нужен

Типовой процесс

1. Discovery — инвентаризация активов (Nmap, Nessus, Qualys)
2. Scanning — активное сканирование каждого актива на известные CVE
3. Analysis — фильтрация ложных срабатываний, приоритизация
4. Reporting — отчёт с CVSS-скорами и рекомендациями

Когда нужен

• Compliance: PCI DSS требование 11.2 — ежеквартальные ASV-сканирования, внутренние и внешние
• Непрерывный мониторинг: зрелые команды используют VA как часть continuous monitoring
• Предварительный этап перед пентестом — определить поверхность атаки
• После patch Tuesday — проверить, что обновления применены

Ограничения

• Много ложноположительных срабатываний (до 20–40% в первый прогон на новой инфраструктуре)
• Не проверяет эксплуатируемость — CVSS-скор не равен реальному риску
• Не видит уязвимости бизнес-логики
• Не находит unknown-unknowns

Penetration Testing: что это и как устроен

Методология (PTES — 7 фаз)

PTES (Penetration Testing Execution Standard) — индустриальный стандарт с 2009 года:

1. Pre-Engagement — согласование scope, правил, NDA, rules of engagement
2. Intelligence Gathering — разведка, OSINT, fingerprint
3. Threat Modeling — моделирование актуальных угроз для бизнеса
4. Vulnerability Analysis — идентификация потенциальных входов
5. Exploitation — активная попытка компрометации
6. Post-Exploitation — эскалация привилегий, lateral movement в согласованных пределах
7. Reporting — детальный отчёт с доказательствами и рекомендациями

Виды пентеста

• Black-box — пентестер не знает о цели ничего (кроме домена/IP). Имитация внешнего атакующего
• Gray-box — пентестер получает базовые учётные данные. Имитация злонамеренного пользователя или подрядчика
• White-box — полный доступ к коду, архитектуре, документации. Максимальная глубина, минимум времени

Типы по предмету

• Network Pentest — внешний/внутренний периметр, сетевые сервисы
• Web Application Pentest — веб-приложения по OWASP WSTG
• Mobile Pentest — iOS/Android приложения по OWASP MASTG
• API Pentest — REST/GraphQL/gRPC по OWASP API Security Top 10
• Cloud Pentest — AWS/Azure/GCP конфигурации, IAM, Kubernetes
• IoT/OT Pentest — промышленные системы, embedded-устройства

Подробнее об AI-модификации — AI-assisted пентест: что это и как работает.

Red Team: полная эмуляция атакующего

Что отличает Red Team от пентеста

• Цель — бизнес-результат, не технический. «Получить доступ к базе клиентов», «отправить платёж от CFO», «выключить SCADA-систему» — а не «найти SQL-инъекцию»
• Полный kill chain. От разведки до exfiltration включительно — как реальный APT
• Скрытность. Обход EDR, AV, SIEM. Защита от детекта — половина работы
• Человеческий фактор. Фишинг, претекстовые звонки, физическое проникновение
• Adversary emulation. Сценарий строится на TTP конкретного актора (APT28, Lazarus, Turla) через MITRE ATT&CK

Типовые фазы Red Team

1. Threat Intelligence (2–4 недели) — разведка на конкретную организацию: кто может атаковать, как, почему
2. Planning — выбор сценария, TTP, целей (crown jewels)
3. Initial Access — фишинг, watering hole, supply chain, физическое проникновение
4. Foothold & Persistence — закрепление на скомпрометированной машине
5. Privilege Escalation — получение прав администратора
6. Lateral Movement — продвижение к целевой системе
7. Objective — достижение заявленной бизнес-цели
8. Exfiltration (если в scope) — вывод данных незаметно для мониторинга
9. Reporting & Debrief — narrative атаки, матрица TTPs, детекторы, которые сработали и не сработали, конкретные рекомендации для Blue Team

Purple Team: совместная работа Red и Blue

Purple Team — не команда, а формат работы. Red Team запускает конкретные TTP, Blue Team в реальном времени смотрит, что сработало в SIEM/EDR, и сразу дорабатывает правила детектирования. Главная цель — не «победа» одной стороны, а улучшение детекций.

Отличия от классического Red Team

• Открытый формат: Blue Team знает, что и когда тестируется
• Итеративность: один TTP → проверка детекта → донастройка SIEM → повтор
• Сроки: недели, а не месяцы
• Результат: улучшенные правила детектирования + натренированный SOC

SANS запустил отдельную программу Purple Team Operations, описывая это как «слияние наступательных и оборонительных концепций». Red Canary через свой Threat Detection Report ежегодно публикует TOP-техник, которые рекомендуются для Purple Team упражнений.

Специализированные виды Red Team

Assumed Breach

Сценарий, при котором атакующий получает начальный доступ «по условию задачи» — симулируется уже скомпрометированный хост или учётная запись. Тест начинается с более позднего этапа kill chain и фокусируется на обнаружении inside-атак. Экономит время и деньги: не тратятся недели на первоначальный прорыв.

Adversary Emulation

Воспроизведение TTP конкретного известного актора (APT28, Lazarus, FIN7) на основе публичных отчётов и MITRE ATT&CK. Цель — проверить, способна ли организация детектировать именно эту группу. MITRE публикует Adversary Emulation Plans (AEP) для многих актёров в открытом доступе.

TIBER-EU

Threat Intelligence-Based Ethical Red Teaming — официальный фреймворк Европейского центрального банка, запущенный в мае 2018. Обновлён в 2025 году под требования DORA. Три фазы:

1. Threat Intelligence — bespoke-разведка на конкретную организацию
2. Red Team Testing — на продуктивных системах critical functions
3. Closure — remediation plan, матрица зрелости, отчёт для регулятора

Итог — не «провал/успех», а матрица зрелости по доменам ATT&CK.

CBEST (Великобритания)

Создан Банком Англии, поддерживается CREST. Длительность типового проекта — 9–12 месяцев: Initiation 6 недель → Threat Intelligence 10 недель → Penetration Testing 14 недель → Closure 4 недели. Обязателен для системно значимых финансовых организаций в UK.

iCAST (Гонконг)

HKMA (Hong Kong Monetary Authority), часть Cyber Fortification Initiative. Intelligence-led, фокус именно на Red Teaming.

DORA TLPT

EU DORA (регламент, действует с 17 января 2025) в статье 26 требует Threat-Led Penetration Testing минимум раз в 3 года для критических финансовых организаций. TIBER-EU — официальный метод выполнения TLPT.

BAS — Breach and Attack Simulation

Ключевые продукты

• Cymulate — широкая библиотека сценариев, SaaS, prevention-oriented
• AttackIQ — ATT&CK coverage measurement
• SafeBreach — один из пионеров BAS, крупнейшая библиотека playbooks

Важно: BAS не заменяет Red Team — он проверяет, что ваши детекторы знают о конкретных TTP. Но он не делает реальный обход EDR, не включает человеческий фактор, не тестирует бизнес-цели. BAS — это «конвейер проверок», Red Team — «реальная атака».

Цены в России в 2026 году

Источники оценок: отчёты anti-malware.ru по рынку пентестинга и ценообразованию, публичные предложения RTM Group, материалы индустриальных конференций. Рынок классического + автоматизированного пентеста в РФ — оценка 5+ млрд ₽; рынок Red Team — 3–4 млрд ₽.

Требования регуляторов

Россия

• 152-ФЗ — не предписывает пентест напрямую, но требует «оценку эффективности мер защиты». Интерпретируется через методики ФСТЭК
• ГОСТ Р 57580.1-2017 / 57580.2 — требует тестирование защитных мер, периодичность по уровню защищённости. Оценка соответствия — раз в 2 года
• Положение ЦБ РФ 851-П (банки, с 29 марта 2025, заменило 683-П) — требует ежегодный пентест и анализ уязвимостей
• 757-П (НФО — страховые, брокеры, УК) — аналогичные требования
• ФСТЭК Методика оценки защищённости (2025) — подробная методология пентеста для аттестованных систем

Международные

• PCI DSS v4.0 Requirement 11:
  • 11.2 — ежеквартальные внешние сканирования через ASV
  • 11.3.1 — ежегодный внутренний и внешний пентест + после значимых изменений
  • 11.4 — сегментация cardholder data environment (CDE) проверяется пентестом
• EU DORA (действует с 17 января 2025): статья 26 — TLPT минимум раз в 3 года для критических финансовых организаций. TIBER-EU — официальный метод
• NIS2 Directive (действует с октября 2024): Article 21(2)(f) требует оценку эффективности мер; ENISA Technical Implementation Guidance (июнь 2025) рекомендует пентест. Штрафы: до €10 млн или 2% глобального оборота
• ISO 27001:2022: Annex A 8.29 (Security Testing in Development), A.8.8 (Technical Vulnerability Management) — пентест не обязателен формально, но де-факто ожидается аудиторами

Инструменты по типам тестирования

Подробнее о том, как ИИ-агенты помогают пентестеру — AI-Assisted Pentest: что это и как работает.

Сертификации для специалистов

Compliance-driven vs Threat-driven

Ключевое разделение пентестов последних лет. Определяет не «что ищем», а «почему ищем».

Распространённые мифы

Миф 1: «Сканер = пентест»

Самая частая ошибка. Сканер автоматически идентифицирует известные CVE по сигнатурам и выдаёт список с CVSS. Пентест — ручная или полуавтоматическая эксплуатация, доказывающая реальный путь к компрометации. PCI DSS прямо разграничивает: req. 11.2 — scan, req. 11.3 — pentest. Сканер скажет «у вас 47 уязвимостей level medium». Пентестер покажет: «через цепочку из трёх medium-уязвимостей атакующий за 20 минут получает данные 2 млн клиентов».

Миф 2: «Пентест = Red Team»

Пентест прозрачен для Blue Team, ограничен scope и временем, цель — документировать уязвимости. Red Team скрытен, scope максимально широк (или намеренно не ограничен), цель — достичь заявленной crown jewel. Путать их — значит либо переплатить за ненужную работу, либо получить Red Team-отчёт там, где нужен был пентест.

Миф 3: «Найдите нам всё»

Запрос без приоритизации scope ведёт к поверхностному покрытию. PTES и TIBER-EU подчёркивают важность Pre-Engagement: согласование целей, crown jewels, правил поведения. Без этого вы получите «средний» результат, не адресующий главные риски.

Миф 4: «Один раз в год — достаточно»

По данным Positive Technologies, средний цикл от обнаружения уязвимости до эксплуатации злоумышленником за последние годы сократился до единиц дней. Проверка раз в 365 дней при таком темпе теряет смысл как первая линия защиты. Современный подход: непрерывный VA + AI-assisted пентест ежеквартально + Red Team раз в год.

Миф 5: «Red Team = успешный взлом»

Цель Red Team — не взломать вас. Цель — проверить, как быстро Blue Team обнаружила атаку и как эффективно отреагировала. «Успешный» Red Team может закончиться тем, что защита сработала на третьем шаге и Red Team не прошёл дальше — и это отличный результат.

Как выбрать нужный подход

Вам нужен VA, если

• Нужно непрерывное покрытие большой инфраструктуры
• Требование аудита (PCI DSS 11.2 — ежеквартальные ASV-сканирования)
• Есть команда, готовая работать с long-tail уязвимостями после сканирования
• Нужна базовая гигиена: обновления, конфигурации, устаревший софт

Вам нужен Pentest, если

• Нужно доказать эксплуатируемость найденного
• Требования регуляторов (851-П, 757-П, PCI DSS 11.3, ГОСТ 57580)
• Релиз нового продукта, крупный рефакторинг, миграция
• Подключение критичных партнёров, подрядчиков
• Ограниченный бюджет, но нужен конкретный технический аудит

Вам нужен Red Team, если

• Есть работающий SOC, который хотите проверить на реальной атаке
• Нужна оценка способности Blue Team реагировать, а не список уязвимостей
• Вы в критичной индустрии (банк, крупный ритейл, критическая инфраструктура)
• Регулятор требует TIBER-EU / DORA TLPT / CBEST
• Уже прошли пентесты и нужен следующий уровень зрелости

Вам нужен Purple Team, если

• Хотите быстро улучшить конкретные детекции SIEM/EDR
• SOC новый или недавно реорганизованный — нужна тренировка
• Red Team показал gaps, и теперь их нужно закрыть коллаборативно

Вам нужен BAS, если

• Хотите непрерывно мерить покрытие MITRE ATT&CK своими детекторами
• Есть зрелый SOC с SIEM/EDR и хочется автоматизировать валидацию
• Нужна регулярная проверка после каждого изменения правил SIEM

Связанные статьи: AI-assisted пентест — современная эволюция пентеста, MITRE ATLAS — матрица для Red Team AI-систем, CompTIA SecAI+ — сертификация по безопасности ИИ.

FAQ