Пентест по PCI DSS: охват, методология и выбор подрядчика

Условная ситуация. Небольшой платёжный сервис-провайдер принимает карточные платежи для интернет-магазинов. Весной команда перенесла сервис токенизации в новый сегмент облака: другие группы безопасности, новый бастион для администраторов, обновлённые правила между зоной данных карт и корпоративной сетью. До визита асессора остаётся месяц, и в папке с доказательствами лежит прошлогодний отчёт о пентесте. Открыв его, руководитель безопасности видит три проблемы. Охват — только внешние IP-адреса. Проверки сегментации нет вообще. А часть внутренних проверок выполнял администратор, который сам настраивал межсетевые экраны.

Это вымышленный пример, а не история конкретной компании. Но каждый вопрос в нём реален. Была ли миграция значимым изменением, после которого нужен новый тест? Проверено ли разделение среды данных держателей карт (CDE) и как часто это должен делать именно сервис-провайдер? Достаточно ли независим тестировщик? Тестирование на проникновение по PCI DSS ценно ровно настолько, насколько хорошо на эти вопросы ответили до начала работ. Ниже — что требует действующая версия стандарта, как выводить охват из потоков данных, как спланировать тест, чтобы отчёт выдержал вопросы асессора, и как выбирать подрядчика по доказательствам, а не по цене за день.

Что требует PCI DSS v4.0.1 от тестирования на проникновение

PCI DSS — базовый набор технических и операционных требований к защите платёжных данных. Он адресован тем, кто хранит, обрабатывает или передаёт данные держателей карт или чувствительные аутентификационные данные, а также тем, кто может повлиять на безопасность CDE. Действующая версия — 4.0.1. Совет PCI SSC опубликовал её 11 июня 2024 года как ограниченную редакцию: по сравнению с 4.0 в ней не добавлено и не удалено ни одного требования. Версия 4.0 выведена из обращения 31 декабря 2024 года. Поэтому в техническом задании стоит ссылаться на 4.0.1, а точные формулировки для документов сверять с официальным текстом.

Тестированию на проникновение посвящено требование 11.4. В отличие от многих отраслевых тем, периодичность здесь записана прямо, и её полезно знать точно.

Внутренний и внешний пентест: раз в 12 месяцев и после значимых изменений

Требование 11.4.2 предписывает внутренний пентест по методологии, которую определила сама организация, не реже одного раза в 12 месяцев и после любого значимого обновления или изменения инфраструктуры или приложений. Требование 11.4.3 задаёт те же условия для внешнего пентеста.

Две детали важнее, чем кажется. Первая — слова «по методологии организации». Документ о методологии не формальность: именно по нему асессор будет сверять, что и как делалось. Вторая — триггер изменений. В нашем примере перенос токенизации в новый облачный сегмент с новым бастионом трудно не считать значимым изменением, и прошлогодний отчёт его уже не описывает. Что считать значимым, зависит от среды, однако PCI DSS задаёт минимальный круг факторов для оценки: новое или существенно обновлённое оборудование и ПО в CDE, изменения потоков или хранения платёжных данных, границ CDE и охвата оценки, поддерживающей инфраструктуры — например, служб каталогов, времени, журналирования и мониторинга, — а также поставщиков и их услуг, поддерживающих CDE или выполняющих требования PCI DSS. Организации стоит заранее закрепить свои критерии поверх этого минимума и уметь объяснить решение по конкретному изменению. О том, как строить проверки по событию, а не по календарю, подробно рассказано в материале о пентесте, запускаемом изменениями.

Проверка сегментации: раз в 12 месяцев для использующих её, раз в шесть — для сервис-провайдеров

Если сегментация используется для изоляции CDE от других сетей, требование 11.4.5 применяется ко всем таким организациям: все средства и методы сегментации проверяют тестированием на проникновение не реже раза в 12 месяцев и после любых их изменений. Проверка должна подтвердить, что средства работают и действительно изолируют CDE от всех систем вне охвата; где разделяются системы с разными уровнями безопасности, проверяется и эта изоляция.

Требование 11.4.6 — дополнительное и действует только для сервис-провайдеров: тот же тип проверки выполняют не реже раза в шесть месяцев и после любых изменений средств или методов сегментации. Шестимесячный интервал нельзя переносить на всех мерчантов, но общую ежегодную обязанность по 11.4.5 при используемой сегментации нельзя пропускать. В нашем примере изменение правил между зонами само по себе запускает внеочередную проверку. Отдельно требование 11.4.7 обязывает мультитенантного сервис-провайдера поддерживать внешние пентесты клиентов по 11.4.3 и 11.4.4: предоставить своевременный доступ для их теста либо доказательство сопоставимого тестирования инфраструктуры, предоставленной клиенту по подписке. Часть сведений в результатах можно скрыть, если оставшегося достаточно для подтверждения всех элементов этих требований. После 31 марта 2025 года это уже обязательное требование, а не рекомендация.

Кто может проводить тест

Стандарт допускает и внутренний, и внешний ресурс, если он квалифицирован и организационно независим. Статус QSA или ASV у тестировщика для такого пентеста не требуется. Независимость означает, что тестирующий не проверяет собственную работу: администратор, который настраивал межсетевые экраны, — плохой кандидат для проверки их правил, даже если он сильный специалист.

Чем пентест не является

Регулярное сканирование уязвимостей закреплено в PCI DSS отдельными требованиями и не заменяет тестирование по 11.4, как и пентест не заменяет сканирование. Кроме того, отчёт о пентесте — это доказательство, которое оценивает асессор, но не сертификация, не аттестация и не заключение о соответствии. Хороший отчёт облегчает оценку, но соответствие сам по себе не подтверждает.

Охват пентеста PCI DSS: от потоков данных карт, а не от списка IP

Охват по PCI DSS привязан к тому, где хранятся, обрабатываются и передаются данные карт, и к системам, способным повлиять на безопасность CDE. Это не всё предприятие автоматически. Поэтому разумная последовательность обратна привычной: сначала схема потоков данных, затем реестр систем на этих потоках и только потом адреса и URL для теста.

Что обычно оказывается в охвате

Как правило, это несколько групп активов. Доступные из интернета платёжные страницы, API оформления заказа и интерфейсы, через которые проходят платёжные данные. Внутренние системы CDE: токенизация, базы с данными карт, обработка транзакций. Механизмы, которые должны отделять CDE от остальных сетей: правила межсетевых экранов, облачные группы безопасности, маршрутизация. Пути администрирования и удалённого доступа: бастионы, VPN, облачные консоли, конвейеры развёртывания, способные менять конфигурацию CDE. И сторонние компоненты платёжного потока: шлюз, скрипты на странице оплаты, вебхуки эквайера.

Для путей администрирования полезно сразу разделить два вида учётных данных. Вход людей защищён многофакторной аутентификацией, и тестировщик ищет её обход, слабые сценарии восстановления и избыточные права после входа. Учётные данные сервисов — API-ключи, сервисные аккаунты, токены конвейера — проверяются иначе: где они хранятся, кому видны, на что дают права и что можно сделать, получив один такой ключ. Если смешать эти проверки в одну строку отчёта, половина вывода потеряется.

Две ловушки

Первая — исключать системы, потому что они хрупкие или политически чувствительные. Старый процессинговый сервер, который «лучше не трогать», остаётся частью CDE; его исключение подрывает смысл теста и почти наверняка вызовет вопросы асессора. Хрупкость решается ограничениями в правилах проведения работ, а не изъятием из охвата.

Вторая ловушка — включать всё предприятие «на всякий случай». Это раздувает бюджет, распыляет время тестировщиков и не повышает уверенность в защите именно платёжных данных. Обеих ловушек позволяет избежать задокументированная граница: по каждому включению и исключению записано обоснование, и асессор видел его до начала работ.

Таблица ниже раскладывает охват по границам атаки и показывает, на какой вопрос отвечает каждая.

Если граница CDE в вашей среде пока размыта, с такой таблицы удобно начать разговор о проекте. Схему потоков данных и обоснование включений можно обсудить с Pentest.red на странице согласования охвата пентеста. Решение о том, что требует стандарт в вашем случае, остаётся за вами и асессором.

Разрешения и правила проведения работ

Письменное разрешение — обязательное предварительное условие, а не бумажная формальность. Давать его должны те, кто действительно уполномочен распоряжаться целевыми системами: владелец бизнеса, ответственный за инфраструктуру, а там, где применимы их условия, — провайдеры хостинга, облака или управляемых услуг. Если API платёжного шлюза принадлежит другой компании, согласие владельца интернет-магазина не даёт права атаковать этот API.

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

Отдельно оговаривается обращение с данными. Если тестировщик встретил реальные номера карт, он фиксирует минимально необходимое доказательство, маскирует номер, не копирует данные в свои системы и сразу сообщает ответственному. Журналы и снимки экрана очищаются от секретов и лишних персональных данных. Организация хранит результаты пентеста и результаты мероприятий по устранению не менее 12 месяцев, как требует 11.4.1; доступ к ним ограничивается, а хранение копий у подрядчика отдельно минимизируется договором.

Методология: NIST SP 800-115 как каркас

Требование 11.4.1 не предписывает конкретную фирменную методику, но задаёт её обязательный минимум. Методология организации должна опираться на признанные отраслевые подходы; охватывать весь периметр CDE и критические системы, проверки изнутри и снаружи сети, сегментацию и другие средства сокращения охвата; включать прикладной уровень как минимум по уязвимостям из 6.2.4, а также сетевой уровень для сетевых компонентов и операционных систем; учитывать угрозы и уязвимости, с которыми организация столкнулась за предыдущие 12 месяцев; и описывать оценку и обработку риска найденных эксплуатируемых слабостей. Методология должна предусматривать попытки контролируемой эксплуатации: автоматизация может помогать, но один лишь сканер или эксплуатация только его находок не заменяют работу компетентного тестировщика.

Процессным каркасом для выполнения этого минимума может служить NIST SP 800-115 — техническое руководство по тестированию и оценке информационной безопасности, опубликованное в сентябре 2008 года взамен SP 800-42. Оно помогает планировать и проводить технические тесты, анализировать результаты и разрабатывать меры по снижению риска. Формально руководство описывает три фазы оценки: планирование, выполнение и этап после выполнения, куда входят анализ находок, отчётность и рекомендации.

Документ прямо говорит, что не претендует на полное описание программы тестирования: это обзор ключевых техник с их преимуществами и ограничениями. Для PCI ценен именно этот подход. Хороший отчёт объясняет не только что сделано, но и почему выбрана каждая техника и чего она не могла обнаружить. Поскольку руководство датировано 2008 годом, содержание прикладных проверок лучше брать из более новых источников, о которых ниже.

Поверх трёх фаз NIST практично выстроить собственный цикл устранения: ответственные, сроки по риску, повторный тест. Это уже не формулировка руководства, а рабочая надстройка, без которой трудно выполнить требование 11.4.4.

1. Карта потоков данныхГде данные карт поступают, перемещаются и хранятся и какие системы могут повлиять на CDE.
2. Разрешения и правилаПодписи уполномоченных владельцев и провайдеров, окна, запреты, обращение с данными, условия остановки.
3. Внешний, внутренний тест и сегментацияПроверки по 11.4.2 и 11.4.3; сегментация по 11.4.5, а для сервис-провайдеров — дополнительная периодичность 11.4.6.
4. Исправление по рискуОтветственные и сроки для каждой эксплуатируемой уязвимости в соответствии с 11.4.4.
5. Повторный тест и записьПроверка исправлений в согласованной среде с фиксацией того, какие варианты атаки перепроверены.

Платёжная страница и API оформления заказа

Для применимых веб-проверок платёжных страниц, API оформления заказа и административных консолей полезны стандарты веб-тестирования. OWASP Web Security Testing Guide даёт набор тест-кейсов; в отчёте стоит указывать использованную версию, например 4.2. OWASP ASVS задаёт проверяемые требования к веб-контролям. В версии 5.0.0 проект рекомендует ссылаться на требования вместе с номером версии, в формате вроде v5.0.0-1.2.5, потому что нумерация между версиями меняется. Такие ссылки делают охват проверяемым, но не доказывают, что приложение соответствует стандарту целиком.

OWASP Top 10 редакции 2025 года — документ для осведомлённости о главных рисках веб-приложений, а не план теста. Охват, который заканчивается на десяти категориях, уже того, что позволяют WSTG и ASVS.

Сессии, скрипты и междоменные запросы

На платёжной странице особенно важны три механизма. Первый — сессии. Сам HTTP не связывает запросы между собой, поэтому приложение обычно хранит состояние сессии на сервере и передаёт браузеру идентификатор в cookie. Тестировщик проверяет, как идентификатор выдаётся, обновляется ли он после входа, какими флагами и сроком жизни защищён.

Второй — загрузка скриптов. Content Security Policy позволяет ограничить, откуда странице разрешено загружать ресурсы, и помогает смягчать межсайтовый скриптинг и внедрение данных. Сторонний скрипт, выполняемый в контексте платёжной страницы, может получить доступ к вводу; его необходимость, источник и ограничения нужно проверять отдельно.

Третий — CORS. Эта политика определяет, какие чужие источники могут читать ответы API. Если сервер динамически разрешает Origin, контролируемый атакующим, и одновременно разрешает учётные данные, браузер жертвы может раскрыть этому сайту аутентифицированный ответ — когда правила cookie и поведение конкретного API действительно допускают отправку таких данных.

Бизнес-логика оплаты

Отдельная зона — логика, которую сканеры почти не видят. Условный пример: API оформления заказа берёт сумму из запроса клиента вместо пересчёта на сервере. Другой: обработчик вебхука эквайера меняет статус заказа на «оплачен», не проверяя подпись уведомления. Это ошибки бизнес-логики и проверки подлинности сообщений: при достижимости соответствующего сценария они могут привести к финансовым потерям. Как планировать такие проверки, разобрано в статье о тестировании бизнес-логики, а методика проверки самого API — в материале об оценке безопасности REST API.

Компромиссы: сканер или ручной тест, продуктив или стенд

NIST SP 800-115 рассматривает сканирование уязвимостей и тестирование на проникновение как разные техники со своими сильными и слабыми сторонами. Сканер быстро и повторяемо проходит много активов и подходит для частых проверок. Ручной тест медленнее, зато находит ошибки логики, цепочки слабостей и пробелы в авторизации, которые сканер не связывает между собой. Убедительный пентест использует инструменты для широты, а человека — для глубины. Отчёт, состоящий в основном из вывода сканера, должен вызывать вопросы.

Выбор среды — тоже компромисс. Тест в продуктивной среде даёт самую реалистичную картину, но несёт операционный риск для процессинга. Стенд безопаснее, однако может отличаться конфигурацией, сетевыми правилами и данными, поэтому его результаты нельзя без оговорок переносить на продуктив. Если тестируется копия, отчёт должен перечислять известные различия и указывать, какие выводы требуют подтверждения в рабочей среде. Особенно это касается сегментации: правила на стенде доказывают только свойства стенда.

Уровень знаний тестировщика влияет на то, сколько успеют проверить. Чёрный ящик имитирует внешнего нарушителя без информации. Серый или белый ящик — с тестовыми учётными записями и архитектурной документацией — обычно позволяет за то же время пройти заметно большую часть приложения. Это практическое наблюдение, а не измеренная статистика, но логика проста: нельзя проверить контроль, до которого тестировщик не добрался.

Наконец, бюджет. Вместо покупки фиксированного числа человеко-дней опишите охват через границы из таблицы выше, применимые версионированные веб-проверки ASVS и WSTG и отдельные критерии для инфраструктуры и других технологий, а затем попросите подрядчиков оценить именно его. Тогда непрозрачная оценка трудозатрат превращается в сопоставимую спецификацию.

Как ранжировать находки: риск, CWE и признаки эксплуатации

Требование 11.4.4 говорит об исправлении эксплуатируемых уязвимостей и слабостей в соответствии с риском, значит, отчёту нужна внятная приоритизация. Классификация по CWE в этом помогает. Список CWE Top 25 Most Dangerous Software Weaknesses редакции 2025 года выделяет классы слабостей, которые MITRE описывает как часто легко обнаруживаемые и эксплуатируемые и способные привести к захвату системы, краже данных или отказу приложения. Сопутствующий список 2025 CWE Top 10 KEV Weaknesses ранжирует классы слабостей по каталогу активно эксплуатируемых уязвимостей CISA.

Эти сигналы не стоит переоценивать. Принадлежность находки к классу из KEV-списка — повод рассмотреть её внимательнее, но сама классификация CWE не доказывает, что эту конкретную уязвимость можно эксплуатировать или что её уже эксплуатировали. Решает подтверждение в вашей среде: достижимость, необходимые условия, что получает атакующий и насколько близко это к данным карт. Как совмещать эти факторы, подробно разобрано в статье о приоритизации уязвимостей по риску.

У разметки по CWE есть и второе применение. Предупреждения CISA Secure by Design посвящены целым классам дефектов: межсайтовому скриптингу, внедрению команд ОС, обходу каталогов, переполнению буфера. Если находки размечены, повторяющиеся классы можно вернуть в стандарты разработки и устранять систематически, а не по одной.

Исправление и повторный тест по требованию 11.4.4

Если пентест выявил эксплуатируемые уязвимости или слабости, одного отчёта недостаточно. Требование 11.4.4 предписывает исправлять их по результатам оценки риска по 6.3.1 и повторять тестирование для проверки исправлений. Поэтому повторную проверку стоит оценить и запланировать в исходном договоре, а не обсуждать после получения отчёта: сколько времени у команды на исправления, кто перепроверяет и в какой среде.

Вывод повторного теста ограничен тем, что действительно проверено. «Исправлено» означает: в согласованной среде, для перечисленных вариантов атаки, на указанную дату исходная цепочка больше не работает. В согласованном охвате полезно проверить и близкие варианты: если поправили один параметр API, а соседний по-прежнему принимает сумму от клиента, нельзя представлять точечную проверку как устранение всего класса. Как выстроить такую перепроверку, описано в материале о проверке исправлений после пентеста.

Вторая таблица — практический перечень того, что стоит требовать при приёмке результатов.

Отчёт, который выдерживает вопросы асессора

Ценность отчёта определяется тем, можно ли по нему действовать. По каждой находке нужны затронутый актив, условия подтверждения, доказательства, достаточные для санкционированной перепроверки, класс CWE там, где он применим, ссылки на версионированные требования ASVS или области WSTG только для подходящих веб-проверок либо иной технический критерий, и обоснование риска в контексте платёжной среды. Находку без воспроизводимых доказательств трудно исправить и трудно защитить перед асессором. Отдельный раздел должен описывать ограничения: что не тестировалось и почему, где среда отличалась от продуктивной.

Результаты полезно связать с управлением рисками в целом. NIST Cybersecurity Framework 2.0 помогает организациям понимать и улучшать управление рисками кибербезопасности, а его профили позволяют показать руководству, что тестирование платёжной среды — часть общей программы, а не разовая задача к аудиту. Повторяющиеся классы находок в купленном ПО стоит передавать поставщикам. Подход CISA Secure by Design исходит из того, что производители должны брать на себя большую долю нагрузки по безопасности, а руководство Secure by Demand написано как раз для заказчиков, ведущих переговоры о закупках. Доказательства из пентеста — весомый аргумент в таком разговоре.

Как выбрать подрядчика для пентеста по PCI DSS

К выбору подрядчика имеет смысл переходить, когда определены охват, методология и ожидания к отчёту: только тогда предложения можно сравнить честно. Попросите каждого кандидата описать, как его процесс соотносится с фазами NIST SP 800-115, по каким версиям WSTG и ASVS составлены применимые веб-тесты и какие критерии используются для остальных технологий, как он проверяет сегментацию и где заканчивается автоматизация. Запросите обезличенный образец отчёта и оцените его по таблице приёмки выше. Если образец перечисляет вывод сканера с типовыми советами, глубина услуги понятна независимо от цены.

Квалификацию проверяйте по людям: какой опыт у конкретных тестировщиков с платёжными приложениями и инфраструктурой, кто контролирует качество отчёта, как обеспечивается организационная независимость. Рекомендации проверяйте самостоятельно. Статус QSA или ASV для пентеста по 11.4 не требуется и сам по себе не подтверждает качество именно тестирования на проникновение.

Коммерческие условия должны покрывать повторный тест, обращение с данными карт, если они встретились, оформление разрешений с каждым владельцем, немедленное информирование о критичных находках во время работ, защищённую передачу и хранение отчёта. Сравнивайте предложения не по цене за IP-адрес или день, а по охвату и доказательствам, которые каждое из них обязуется дать. Если хотите обсудить такой охват и формат доказательств для своей платёжной среды, посмотрите описание услуги тестирования на проникновение и приходите к разговору с готовой схемой потоков данных. Способ подтверждения соответствия зависит от применимого для организации маршрута — например, SAQ или оценки с ROC. Технический отчёт о пентесте может быть доказательством для этого процесса, но не заменяет требуемую самооценку, оценку асессора или итоговые документы PCI DSS.

Вывод

Пентест по PCI DSS приносит пользу, когда соответствие считается минимумом, а снижение риска — целью. Требование 11.4 версии 4.0.1 задаёт рамку: методология с минимумом из 11.4.1 и хранением результатов не менее 12 месяцев; отдельные внутренний и внешний тесты не реже раза в 12 месяцев и после значимых изменений; проверка сегментации по 11.4.5 ежегодно и после любых её изменений, а для сервис-провайдеров — дополнительно не реже раза в шесть месяцев; исправление по риску с повторной проверкой. В пределах этой рамки качество определяют: охват, выведенный из потоков данных, разрешения от тех, кто вправе их давать, методология с понятными фазами, прикладные проверки по версионированным требованиям и отчёт, который можно воспроизвести.

Вернёмся к условному провайдеру из начала. Ему не нужен «ещё один пентест». Ему нужны внеочередная проверка после миграции, тест сегментации с правильной периодичностью и тестировщик, который не проверяет собственные правила. Такая постановка задачи даёт проверяемые основания снижать риск и понимать границы доказанного, а не просто пополняет папку с документами.