На предпоследнем PCI DSS-пентесте для процессингового центра отчёт предыдущей команды QSA завернул трижды: не было proof of exploitation, маппинг находок на CDE отсутствовал, а segmentation testing подменили выводом Nessus. Мой отчёт по тому же окружению приняли с первого раза - не потому что нашёл больше уязвимостей, а потому что задокументировал их в формате Requirement 11.4. Разница между «провести пентест» и «провести PCI DSS пентест, который примет аудитор» - целиком в деталях scope, метода и структуры отчёта.
Requirement 11.4 в PCI DSS v4.0: что поменялось для пентестера
PCI DSS v4.0 стал единственным действующим стандартом 31 марта 2024 года. Все отложенные требования (future-dated) обязательны с 31 марта 2025 года, по данным PCI SSC. Если ваш заказчик до сих пор ссылается на Requirement 11.3 из версии 3.2.1 - он отстал на поколение, и QSA ему об этом напомнит. Подробнее - в нашем руководстве по кибербезопасности банков.Requirement 11.4 - основной контроль, регулирующий PCI DSS пентест. Пять подпунктов, каждый из которых влияет на планирование и проведение работ:
- 11.4.1 - задокументированная методология тестирования. Не «мы используем Kali», а описание подхода на базе PTES, NIST SP 800-115 или OWASP Testing Guide с привязкой к конкретному CDE.
- 11.4.2 - внутренний пентест минимум раз в год и после любого значимого изменения инфраструктуры.
- 11.4.3 - внешний пентест с аналогичным расписанием. Scope - все интернет-доступные системы, связанные с CDE.
- 11.4.4 - обязательное исправление найденных эксплуатируемых уязвимостей и retesting для подтверждения. QSA запросит evidence и фикса, и повторного теста.
- 11.4.5 - segmentation testing как самостоятельное требование. Для сервис-провайдеров - каждые шесть месяцев, для остальных - ежегодно.
Три ключевых сдвига по сравнению с v3.2.1
Обязательный retesting. При версии 3.2.1 хватало плана ремедиации. Теперь QSA потребует доказательство: уязвимость закрыта и это подтверждено повторным тестом. Планируйте timeline engagement с учётом полного цикла «находка -> фикс -> ретест» - закладывайте минимум три месяца до даты ежегодного PCI-аудита.Authenticated internal scanning (Req 11.3.1.2). Внутреннее сканирование уязвимостей теперь обязательно проводится с учётными данными. Это не пентест, но влияет на scope: если authenticated scan обнаружил критичную уязвимость, пентестер должен проверить эксплуатируемость. Результаты Nessus/Qualys с кредами - входные данные для вашего пентеста, а не замена ему.
Tamper detection для платёжных страниц (Req 11.6.1). Для организаций с веб-платежами обязателен мониторинг изменений HTTP-заголовков и JavaScript на странице оплаты - защита от Magecart-атак. Пентестер проверяет работоспособность этого механизма: попытка внедрить тестовый скрипт должна сгенерировать алерт. Если не сгенерировала - у заказчика проблема, и это идёт в отчёт.
Триггеры «significant change»
PCI DSS v4.0 требует повторный тест на проникновение PCI DSS после «значимых изменений», но исчерпывающий чеклист отсутствует. Согласно PCI SSC Penetration Testing Guidance, к триггерам относятся: новое сетевое оборудование, обновление ОС, новые платёжные потоки, добавление подсетей, крупные изменения firewall rules.Decision tree, который я использую при согласовании с заказчиком:
- Изменение затронуло границу CDE? -> Ретест сегментации
- Изменилась топология сети внутри CDE? -> Ретест внутреннего пентеста
- Добавлены или изменены внешние системы? -> Ретест внешнего пентеста
- Изменена логика веб-приложения, обрабатывающего платежи? -> Ретест application layer
- Добавлен новый платёжный канал? -> Полный повторный пентест
Scope и CDE: где обычный пентестер ошибается первым делом
Неправильное определение scope - причина номер один отклонения пентест-отчётов при QSA-ревью, по данным Sherlock Forensics. Scope PCI DSS пентеста определяется не пожеланиями заказчика, а расположением cardholder data environment. Заказчик может хотеть протестировать три сервера - но если CDE включает двадцать, QSA завернёт отчёт.
Определение scope за четыре шага
Шаг 1. Идентификация CDE. Cardholder Data Environment - все системы, которые хранят, обрабатывают или передают данные держателей карт (PAN, Cardholder Name, Service Code, и т.д.), плюс все системы, напрямую подключённые к ним без сегментационного контроля. Если сервер может общаться с платёжным приложением без прохождения через firewall - этот сервер в scope. Без вариантов.Шаг 2. Маппинг connected systems. Системы, предоставляющие security-сервисы для CDE, - firewalls, серверы аутентификации (AD, SSO для CDE-привилегированных аккаунтов), SIEM, логирование - входят в scope, даже если не обрабатывают карточные данные напрямую. Их часто пропускают. На одном проекте AD-контроллер, обслуживающий CDE-аккаунты, вообще не был в карте сети заказчика - а через него можно было получить доступ ко всему процессингу.
Шаг 3. Валидация границ сегментации. Если заказчик использует сетевую сегментацию для сокращения PCI DSS scope, границы между in-scope и out-of-scope сетями нужно протестировать. Пентест подтверждает, что out-of-scope системы не могут добраться до CDE ни через какой маршрут, включая непрямые пути через shared management VLAN или jump-серверы.
Шаг 4. Документирование исключений. Любая система, исключённая из тестирования, документируется с обоснованием. «Мы исключили, потому что сложно тестировать» - не обоснование. QSA проверит каждое исключение.
Grey box по умолчанию
Тест на проникновение PCI DSS - это по определению grey box. До начала работ получите от заказчика:- Карту сети с обозначением сегментов (пользовательский, технологический, DMZ, процессинг)
- Правила межсетевого экранирования на границах подсетей (ACL/МСЭ)
- Список веб-приложений и СУБД - тестовых и продуктивных
- Информацию о беспроводных сетях в периметре CDE
- Политики блокировки учётных записей, исключения для тестовых аккаунтов
Сегментация сети: отдельный обязательный блок PCI DSS пентеста
Для service providers этот тест выполняется каждые шесть месяцев. Если за прошедший период менялись правила firewall или добавлялись новые VLAN - тест повторяется вне расписания.
Методология: чем PCI DSS пентест отличается от стандартного
Если вы провели десятки обычных пентестов и берёте первый PCI DSS-проект - вот ключевые расхождения.| Критерий | Стандартный пентест | PCI DSS пентест (Req 11.4) |
|---|---|---|
| Scope | Определяется заказчиком | CDE + connected systems + сегментация |
| Модель доступа | Black / grey / white box | Grey box обязательно |
| Социальная инженерия | Часто включена | Не требуется стандартом |
| Минимизация DoS | По согласованию | Обязательна |
| Retesting | По договору | Обязательно, с evidence |
| Частота | По договору | Ежегодно + после significant change |
| Segmentation testing | Опционально | Обязательный отдельный блок |
| Формат отчёта | Произвольный | Должен пройти QSA-ревью |
| Квалификация тестировщика | На усмотрение заказчика | Организационная независимость + подтверждённая экспертиза |
| Основная цель | Любые активы по договору | Доступ к данным платёжных карт |
Kill chain в привязке к PCI DSS scope
Внешний пентест покрывает initial access: все интернет-доступные IP и домены, связанные с CDE, - веб-приложения с платёжными страницами, API, VPN-эндпоинты, DNS в периметре. На этом этапе актуальны Network Service Discovery (T1046, Discovery) для разведки и Exploit Public-Facing Application (T1190, Initial Access) для пробива периметра.Внутренний пентест - lateral movement от non-CDE к CDE. Проверяется:
- Exploitation of Remote Services (T1210, Lateral Movement) - попытка перемещения между сегментами
- Network Sniffing (T1040, Credential Access / Discovery) - анализ трафика на предмет PAN или CVV в открытом виде
- Brute Force (T1110, Credential Access) и Valid Accounts (T1078, Initial Access) - тестирование и переиспользование учётных данных
- Unsecured Credentials (T1552, Credential Access) - поиск карточных данных в конфигах, логах, дампах
- OS Credential Dumping (T1003, Credential Access) - извлечение хешей для дальнейшего перемещения к CDE
Application layer тестируется отдельно через Requirement 6.2.4: проверка на уязвимости OWASP Top 10 - Injection (A03:2021), Broken Access Control (A01:2021), Cryptographic Failures (A02:2021), Security Misconfiguration (A05:2021). Если у заказчика есть кастомное веб-приложение для обработки платежей - оно тестируется по OWASP Testing Guide, результаты включаются в общий отчёт.
Пентест vs ASV-сканирование
ASV-скан (Approved Scanning Vendor, Req 11.3.2) - автоматизированное квартальное сканирование внешних IP. Оно не заменяет пентест. ASV находит известные CVE, мисконфигурации, просроченные сертификаты. Пентест эксплуатирует уязвимости, строит цепочки атак и доказывает возможность доступа к CHD. Предоставлять отчёт ASV вместо пентеста - гарантированный отказ при QSA-ревью. Я видел это дважды, и оба раза заказчик терял два-три месяца на переделку.PCI DSS пентест отчёт: шесть компонентов, без которых завернут
За десяток PCI DSS-пентестов у меня сформировался набор обязательных секций. QSA проверяет наличие каждой:
1. Документированная методология. Название стандарта (PTES, NIST SP 800-115, OWASP Testing Guide) и описание, как он применялся к конкретному CDE. «Мы провели пентест» без описания методологии - сразу же отказ.
2. Scope с маппингом на CDE. Каждая протестированная система привязана к CDE-карте. Если CDE включает 15 IP-адресов, а в отчёте протестировано 8 - QSA потребует обоснование каждого исключения.
3. Находки с CVSS-рейтингами и proof of exploitation. Каждая уязвимость - с CVSS score, вектором атаки, скриншотами или логами эксплуатации. Отчёт без proof of exploitation - отчёт о сканировании, а не о пентесте.
4. Результаты segmentation testing. Отдельная секция: из каких сегментов проводились тесты, какие порты проверялись, evidence того, что firewall-правила работают.
5. Статус ремедиации и evidence ретеста. Для каждой эксплуатируемой уязвимости: дата обнаружения -> дата фикса -> дата ретеста -> результат ретеста.
6. Квалификация тестировщика. PCI DSS допускает внутренние ресурсы при организационной независимости - сетевая команда не может тестировать свою же сеть. Сертификации OSCP, GPEN, GWAPT, CREST CRT/CCT - в отчёте упоминайте их явно.
Типичные причины отклонения QSA
- Подмена пентеста выводом Nessus/Qualys без ручной эксплуатации
- Scope не совпадает с CDE-картой заказчика
- Segmentation testing отсутствует как отдельный блок
- Нет retesting после ремедиации
- Находки без CVSS и без доказательств эксплуатации
- Методология названа, но не описано, как она применялась
Ограничения и когда PCI DSS пентеста недостаточно
PCI DSS пентест - целевое упражнение с жёстким scope. Он проверяет возможность доступа к CHD, но не покрывает:- Социальную инженерию. Стандарт не требует phishing-кампаний, хотя реальные атаки на платёжные системы часто начинаются именно с них.
- Физический доступ. Тестирование физической безопасности серверных - за рамками Req 11.4.
- Supply chain. Зависимости от third-party провайдеров тестируются опосредованно (через сегментацию), полноценный supply chain audit - другое требование.
Российский рынок PCI DSS-пентестов несколько лет работал в режиме «бумажного» compliance - как описывают авторы Plusworld, заказчики покупали подписанный отчёт, а не реальную оценку защищённости. После 2022 года часть организаций сохранила потребность в PCI DSS для работы с международными платёжными системами. Рынок сжался, но требования к качеству выросли - «лояльных» аудиторов стало меньше, а QSA стали внимательнее.
Из десяти моих PCI DSS-пентестов ни один не прошёл по сценарию «получили scope -> протестировали -> сдали отчёт». В каждом проекте scope корректировался: обнаруживались неучтённые connected systems, нелегитимные маршруты между сегментами, забытые тестовые серверы с доступом к production-базе. Сетевые инженеры заказчика не всегда могут ответить, какие VLAN имеют L3-маршрут к процессинговому серверу. Firewall-правила написаны пять лет назад и с тех пор не пересматривались.
Это не исключение - это норма. Пентестер фактически проводит discovery и помогает заказчику понять, что у него реально в scope. Если вы честно документируете расхождения между заявленным и обнаруженным CDE в отчёте - QSA это оценит. Если промолчите - проблемы при аудите неизбежны.
PCI DSS v4.0 сделал пентест менее формальным и более требовательным. Retesting, segmentation validation, authenticated scanning - всё это превращает ежегодный «визит для галочки» в полноценный цикл оценки. Пентестер, который умеет не только ломать, но и грамотно документировать находки в привязке к Requirement 11.4, стоит дороже - и заслуженно. Формулу на бумаге можно понять за час, а вот segmentation testing по-настоящему ощущается, когда сам проходишь пять VLAN подряд и в третьем находишь незакрытый маршрут к CDE - задачи такого типа, привязанные к работе с трафиком и сетевой сегментацией, можно потренировать на HackerLab.pro в категории network.
Последнее редактирование модератором:
