Пентест и соответствие требованиям: практическое руководство
Отчёт о пентесте становится доказательством соответствия только тогда, когда он связан с конкретным требованием: законом, стандартом, договором, политикой или программой аудита. Универсальной категории «compliance-пентест» не существует. GDPR и ISO/IEC 27001 не предписывают пентест по названию, PCI DSS содержит прямые требования к тестам, а DORA устанавливает TLPT лишь для определённых финансовых организаций. Поэтому сначала определяют применимое требование, затем область, полномочия, метод, допустимые доказательства и формат отчёта.
Содержание
Пентест и соответствие требованиям: что именно должен доказать тест
GDPR, ISO/IEC 27001, PCI DSS, DORA, NIS2 и CRA — разные основания и обязанности
Ключевые выводы
| Пункт | Подробности |
|---|---|
| Сначала определите требование | Метод и доказательства выбирают по точному пункту закона, стандарта, договора или политики. |
| Нормативные источники различаются | GDPR и ISO/IEC 27001 не называют пентест обязательным методом; PCI DSS и отдельные положения DORA содержат более конкретные требования. |
| Оценка уязвимостей и пентест дополняют друг друга | Сканирование, ручная проверка и эксплуатация дают разные доказательства; ни один метод не является универсальным. |
| Планируйте доказательства до начала теста | Зафиксируйте область, полномочия, критерии, ограничения, формат результатов, хранение данных и повторную проверку. |
Пентест и соответствие требованиям: что именно должен доказать тест
Глоссарий SANS помогает пояснить понятие пентеста как контролируемой проверки, но источник обязательства всегда находится в применимом праве, стандарте, договоре или внутренней политике. Выражение penetration testing compliance — рабочее описание теста, подготовленного под такое требование, а не самостоятельный сертификат или единый юридический режим.
Обычно проверяемый процесс включает следующие элементы:
Письменная авторизация — разрешение стороны, которая вправе согласовать тест для всех включённых активов, в том числе облачной и сторонней инфраструктуры
Определённая область (scope) — системы, адреса, приложения, роли, исключения, временные окна и допустимые источники трафика
Правила взаимодействия — разрешённые и запрещённые действия, условия остановки, каналы связи, обработка данных и порядок эскалации
Методология — подход, соответствующий цели: например OWASP WSTG/MASTG для приложений, NIST SP 800-115 или PTES для технической оценки; TLPT по DORA применяется только при наличии соответствующего основания
Документирование результатов — проверяемые наблюдения, использованный метод, ограничения, влияние, рекомендации и результат повторной проверки; эксплуатация нужна только там, где она оправдана и разрешена
Доказательность означает возможность связать вывод с требованием и исходными данными. Аудитору или владельцу контроля должны быть понятны область, дата, версия системы, способ проверки, результат, ограничения и дальнейшие действия. Интерактивная сессия на цели сама по себе этого не обеспечивает.
Оценка уязвимостей систематически выявляет и подтверждает широкий набор слабостей; пентест проверяет согласованные сценарии и влияние в заданной области. Некоторые требования прямо требуют сканирования, другие — пентеста, а третьи допускают разные методы оценки эффективности. Правильная программа часто использует оба.
Самая частая ошибка — заказать тест до прочтения требования. PDF со списком CVE не докажет выполнение пункта, если неизвестны область и критерии; аналогично успешная эксплуатация не заменит обязательный внешний скан, проверку сегментации или запись в Statement of Applicability.
Какие нормы и стандарты могут обосновывать пентест в Европе
Ниже приведена техническая ориентация, а не заключение о применимости права. Всегда проверяйте актуальный текст, юрисдикцию, статус организации, договоры и указания компетентного аудитора или юридической службы.
GDPR (Общий регламент по защите данных)
Статья 32(1)(d) GDPR требует процесса регулярного тестирования, оценки и анализа эффективности технических и организационных мер безопасности обработки. GDPR не называет пентест обязательным методом. Пентест может быть одним из уместных доказательств для конкретного риска, наряду с другими техническими и организационными проверками. Обзор требований GDPR по кибербезопасности полезен как комментарий, но решающим источником остаётся текст регламента.
Для проверки по GDPR свяжите тест с рисками для прав и свобод людей, системами обработки и выбранными мерами. Отчёт должен показывать, что именно оценено, по каким критериям и какие действия предприняты; список CVE без контекста обработки данных недостаточен.
ISO/IEC 27001
ISO/IEC 27001:2022 определяет требования к системе управления информационной безопасностью (ISMS), но не устанавливает универсальную обязанность проводить пентест. Контроль A.8.8 относится к управлению техническими уязвимостями, а A.5.36 — к соблюдению политик, правил и стандартов информационной безопасности. Пентест может служить доказательством, если он выбран по оценке риска, Statement of Applicability, внутренней политике или договору; сам номер контроля не доказывает обязательность именно этого метода.
NIST SP 800-115
NIST SP 800-115 — руководство по планированию и проведению технических тестов, анализу результатов и мерам снижения риска, а не закон или сертификат соответствия. Для пентеста оно описывает модель Planning, Discovery, Attack и Reporting и подчёркивает необходимость плана оценки, Rules of Engagement и отчётности. Организация сама связывает этот метод с проверяемой политикой или требованием.
| Стандарт | Требования пентеста | Частота | Документация |
|---|---|---|---|
| GDPR, статья 32 | Не предписывает пентест; требует регулярного процесса проверки и оценки эффективности мер | Регулярно и соразмерно риску; без единого календаря для всех организаций | Область обработки, метод, результат, риск и действия по улучшению |
| ISO/IEC 27001:2022 | Не предписывает пентест универсально; метод следует из ISMS, риска, SoA, политики или договора | По программе ISMS, оценке риска, изменениям и обязательствам организации | Связь с риском, применимым контролем, критериями и корректирующими действиями |
| NIST SP 800-115 | Практическое руководство по техническим оценкам, а не самостоятельное требование compliance | По плану оценки, политике и риску конкретной организации | План, RoE, методы, доказательства, ограничения, выводы и меры снижения риска |
| PCI DSS v4.0.1 | Прямые требования к внутренним и внешним пентестам и, при применимости, проверке сегментации | Не реже одного раза в 12 месяцев и после значимых изменений; дополнительные сроки зависят от требования | Методика, область, результаты, устранение находок и повторная проверка |
Европейский контекст
DORA применяется с 17 января 2025 года и требует программы тестирования цифровой операционной устойчивости. Расширенный TLPT по статье 26 обязателен не для каждой финансовой организации, а для организаций, определённых компетентным органом по установленным критериям; базовая периодичность — не реже одного раза в три года, но орган может её изменить с учётом риска. TIBER-EU служит европейской рамкой для тестирования на основе разведданных об угрозах и не заменяет проверку конкретных требований DORA и применимых RTS.
NIS2 — Директива (ЕС) 2022/2555 — в статье 21(2)(f) требует политик и процедур оценки эффективности мер управления киберриском, но не называет пентест единственным обязательным методом. В Польше директиву внедрила новеллизация закона о KSC, действующая с 3 апреля 2026 года; для ряда организаций, соответствовавших критериям на дату вступления закона в силу, переходный срок продолжается до 3 апреля 2027 года. Область, сроки и санкции нужно проверять по действующему национальному закону, а не переносить механически из директивы.
CRA — Cyber Resilience Act (Регламент (ЕС) 2024/2847) — применяется в основном с 11 декабря 2027 года; обязанности по статье 14 начинают применяться 11 сентября 2026 года, а глава о нотификации органов оценки соответствия — 11 июня 2026 года. Производитель должен проводить эффективные регулярные тесты и обзоры безопасности продукта, но регламент не превращает каждый такой тест в обязательный внешний пентест. Процедура оценки соответствия зависит от категории продукта и применённых стандартов.
Пентест и оценка уязвимостей: взаимодополняющие методы
Доказательная ценность зависит не от названия услуги, а от проверяемого требования, области, качества метода и прослеживаемости результата. Ниже — типичное различие, которое нужно адаптировать к конкретной программе.
Обзор различий между услугами помогает отделить широкое выявление слабостей от проверки согласованного сценария. Однако ошибочно утверждать, что compliance всегда требует только пентеста: PCI DSS, например, содержит отдельные требования и к сканированию, и к пентестам.
| Характеристика | Оценка уязвимостей | Пентест |
|---|---|---|
| Метод | Систематическое выявление, подтверждение и приоритизация слабостей | Проверка согласованных сценариев, предпосылок и влияния |
| Результат | Набор находок с доказательствами, охватом и приоритетом | Подтверждённые сценарии, ограничения и минимальные доказательства влияния |
| Значение для соответствия требованиям | Высокое, если требование относится к сканированию или управлению уязвимостями | Высокое, если требование или риск требуют пентеста; иначе может быть неприменимо |
| Достаточность отчёта | Достаточен, если метод и формат соответствуют проверяемому пункту | Достаточен только при правильной области, полномочиях, методе и документации |
| Стоимость | Зависит от области, глубины, квалификации и требований к валидации | Зависит от области, сценариев, риска и требований к доказательствам |
Состав документации определяет конкретный источник требования. Для авторизованного пентеста обычно полезны следующие элементы:
Документ авторизации, выданный стороной с полномочиями на все включённые активы
Область (scope) с идентификаторами систем, приложений, ролей, исключений и временных окон
Правила взаимодействия с разрешёнными действиями, условиями остановки, контактами и обработкой данных
Описание методики и критериев, адаптированных к цели и проверяемому требованию
Проверяемые доказательства: версия, конфигурация, запрос и ответ, журнал, снимок экрана или иное минимальное подтверждение; эксплуатация каждой критической находки не является универсальным требованием
Оценка технического и бизнес-влияния в контексте тестируемой среды
Рекомендации по устранению, владелец действия, приоритет и критерий повторной проверки
Дата, версия отчёта, исполнители, контроль качества и правила распространения документа
NIST SP 800-115 и публикации ENISA не устанавливают общего правила, по которому каждое доказательство соответствия требует успешной эксплуатации. Автоматический скан не заменяет пентест, если требование прямо называет пентест, но может быть подходящим доказательством отдельного процесса управления уязвимостями.
Практический совет: до начала работ создайте матрицу «требование — система — метод — доказательство — ответственный — повторная проверка». Заполняйте её по ходу проекта и храните только необходимые данные с контролем доступа и сроком удаления.
Руководство по фаззингу описывает один из методов поиска ошибок реализации. Включайте фаззинг только тогда, когда он соответствует области, риску и критерию проверки; сам по себе он не делает отчёт соответствующим требованиям.
Как спланировать, провести и документировать проверку
Практический процесс начинается не с инструмента, а с сопоставления требования с системой и ожидаемым доказательством. Ниже — рабочая схема, которую следует адаптировать к договору и применимой норме.
Для сложного пентеста удобно выделить шесть фаз:
Планирование и авторизация — определите источник требования, бизнес-цель, владельцев активов, полномочия, данные третьих сторон и критерии приёмки
Область и Rules of Engagement — перечислите цели, исключения, роли, окна, источники трафика, допустимые методы, лимиты нагрузки, условия остановки, контакты и план восстановления
Разведка и обнаружение — собирайте только разрешённые данные, фиксируйте охват и отмечайте различие между проверенной, недоступной и исключённой поверхностью
Валидация и минимальное доказательство — сначала используйте версию, конфигурацию и безопасную проверку; эксплуатацию, цепочки и повышение привилегий выполняйте только при необходимости, разрешении и контроле риска
Оценка влияния — свяжите подтверждённый технический эффект с данными, процессом и контролем. Постэксплуатация не является обязательной фазой каждого теста и требует отдельного обоснования
Отчётность и повторная проверка — подготовьте техническую часть и резюме для владельцев риска, покажите ограничения, сохраните прослеживаемость доказательств и зафиксируйте результат устранения
Руководство CREST по выбору пентеста подчёркивает значение ясной цели, области, компетентного исполнителя и полезного отчёта. Это хорошая практика закупки услуги, но не заменяет требования конкретного регулятора или стандарта.
Главный критерий качества — прослеживаемость. Каждый вывод должен ссылаться на актив, условие, метод и доказательство; каждая рекомендация — на риск и критерий закрытия. Исключённые и непроверенные области нужно показать явно.
Типичные ошибки в проектах, подготовленных для подтверждения соответствия требованиям:
Нет действительного разрешения или оно выдано стороной без полномочий на часть инфраструктуры
Область описана как «вся ИТ-инфраструктура» без проверяемого перечня систем, ролей и исключений
Доказательства не содержат времени, версии, контекста цели или связи с конкретной находкой
Отчёт написан только для инженеров и не объясняет риск, решение и владельца действия
Метод и критерии не описаны, поэтому результат невозможно воспроизвести или сравнить
Использован только один метод, хотя требование или риск предполагают сканирование, ручную проверку или оба подхода
Практический совет: добавьте раздел «Ограничения» с исключёнными активами, недоступными ролями, непроверенными сценариями, временными ограничениями и влиянием этих факторов на выводы. Это защищает от ложного впечатления полного покрытия.
Продвинутый метод, например фаззинг, полезен только при правильной гипотезе, контроле нагрузки, минимизации входа и анализе первопричины. В отчёте фиксируйте не эффектность инструмента, а воспроизводимое наблюдение и его связь с требованием.
Типичные пробелы в пентестах для целей соответствия
Проблемы чаще возникают не из-за отсутствия эффектной эксплуатации, а из-за слабой прослеживаемости: неопределённой области, неясных критериев, неполных доказательств, отсутствия ограничений и несвязанных рекомендаций.
Фраза «протестирована сетевая инфраструктура» не позволяет оценить охват. Укажите системы, диапазоны, приложения, роли, интерфейсы, даты и исключения, а также объясните, какие выводы нельзя сделать из-за ограничений.
Вторая ошибка — путать отсутствие эксплуатации с отсутствием доказательств. Иногда безопасная проверка версии и конфигурации достаточна; иногда нужен PoC. Выбирайте минимальное надёжное доказательство по требованию и риску, а не запускайте эксплойт ради впечатляющего снимка экрана.
Третья ошибка — отчёт без адресата. Инженерам нужны точные условия и шаги исправления, владельцу риска — влияние и приоритет, аудитору — связь с критерием и доказательством. Один документ может иметь несколько уровней, но выводы должны оставаться согласованными.
Реалистичность означает соответствие модели угроз и среде, а не максимальную агрессивность. Проверьте внешнюю экспозицию, идентификацию, конфигурацию, устаревшие компоненты и процессы доступа; экзотический модуль не должен вытеснять более вероятные сценарии.
Scope, RoE и бизнес-цель согласуют до начала работ. Изменения оформляют как контролируемое расширение области, а не дописывают задним числом. Это сохраняет полномочия, безопасность и доказательную ценность результата.
Оборудование полезно, когда область включает Wi-Fi, RFID/NFC, SDR, BadUSB или физический интерфейс. Оно не создаёт «аудиторское доказательство» автоматически: воспроизводимость обеспечивают калиброванная процедура, зафиксированная конфигурация, контрольные данные, ограничения и независимая проверка результата.
Инструменты для воспроизводимой лабораторной проверки
Выбирайте оборудование после определения интерфейса, протокола и требуемого доказательства. Для большинства проверок приложений и сетевых служб достаточно программных инструментов и изолированных целей; специальное оборудование имеет смысл только для конкретного физического или радиоинтерфейса.
SAPSAN — европейский поставщик лабораторного оборудования для специалистов по информационной безопасности. В магазине SAPSAN представлены средства для разрешённых тестов Wi-Fi, RFID/NFC, SDR, BadUSB и расширения для Flipper Zero. Выбирайте устройство по поддерживаемому диапазону, протоколу, интерфейсу и совместимости. Использование в рабочей среде требует согласованной области, безопасной конфигурации и защиты собранных данных; принятие доказательства определяет методика и аудитор, а не сам факт применения оборудования.
Часто задаваемые вопросы
Достаточно ли регулярного сканирования уязвимостей для соответствия требованиям?
Это зависит от проверяемого пункта. Сканирование может быть прямым требованием или важным доказательством управления уязвимостями, но не заменяет пентест, если стандарт, договор или программа прямо требует пентеста.
Требует ли GDPR проведения пентеста по названию?
Нет. Статья 32 GDPR требует регулярного процесса проверки, оценки и анализа эффективности мер безопасности обработки. Пентест может быть уместной частью этого процесса по результатам оценки риска, но не является единственным названным методом.
Какой отчёт о пентесте подходит для аудита соответствия?
Универсального шаблона нет. Отчёт должен показывать применимое требование, область, полномочия, метод, доказательства, ограничения, риск, рекомендации и повторную проверку в формате, согласованном с аудитором.
Как часто нужно проводить пентест для целей соответствия?
Срок задаёт конкретное требование. PCI DSS v4.0.1 предусматривает тесты не реже одного раза в 12 месяцев и после значимых изменений; для организаций, определённых для TLPT по DORA, базовый интервал составляет три года и может быть изменён органом. В других случаях частоту определяют риск, изменения, договор и политика.