Переход на PCI Secure Software Standard 2.0: обзор изменений и пошаговая дорожная карта
С 2019 года в индустрии платежных карт существует фреймворк PCI Software Security Framework (PCI SSF). Он был создан на замену устаревшего стандарта PCI PA-DSS. Фреймворк включает в себя два взаимодополняющих стандарта: Secure Software Standard (SSS), который фокусируется на безопасности программного обеспечения, и Secure Software Lifecycle (SLC), посвящённый процессам разработки. 15 января 2026 года Совет PCI SSC опубликовал новую версию стандарта Secure Software Standard (SSS). В статье изложены основные обновления и изменения этой версии.
Концепция стандарта PCI SSS 2.0 была существенно переработана. Новая версия меняет подход к оценке платежного программного обеспечения (ПО), смещая фокус с функциональных признаков на виды обрабатываемых активов. Тем самым расширяется область применимости стандарта и оптимизируются процессы обеспечения безопасности, которые влияют на производителей ПО, аудиторов и клиентов во всей платежной индустрии.
Концепция стандарта PCI SSS 2.0 была существенно переработана. Новая версия меняет подход к оценке платежного программного обеспечения (ПО), смещая фокус с функциональных признаков на виды обрабатываемых активов. Тем самым расширяется область применимости стандарта и оптимизируются процессы обеспечения безопасности, которые влияют на производителей ПО, аудиторов и клиентов во всей платежной индустрии.
Новый подход к области применимости стандарта и определению защищаемых активов
Ранее стандарт PCI SSS распространялся на платёжные приложения (payment software), то есть те, которые хранят, обрабатывают или передают платёжные данные в рамках проведения платёжной транзакции. Новая версия стандарта смотрит на суть: работает ли в принципе ваше ПО с защищаемыми активами? Если да, то стандарт применяется к приложению автоматически, независимо от его функционального назначения. Теперь важно не то, к какому типу ПО относится ваша программа и что она делает, а то, с какими данными она работает. Именно поэтому из стандарта был удален даже сам термин «платежное программное обеспечение» (payment software).
Под защищаемыми активами в версии стандарта PCI SSS 2.0 понимается целый набор новых терминов, описывающих то, что нужно защищать:
Под защищаемыми активами в версии стандарта PCI SSS 2.0 понимается целый набор новых терминов, описывающих то, что нужно защищать:
- Sensitive Data (чувствительные данные) — это любая информация, компрометация которой может привести к ущербу для системы, пользователей, бизнеса или платёжной инфраструктуры.
- Sensitive Resources (чувствительные ресурсы) — это программные компоненты, несанкционированный доступ к которым может привести к компрометации системы или её функций безопасности.
- Sensitive Functionality (чувствительная функциональность) — это функции ПО, которые при злоупотреблении, неправильном использовании или компрометации могут привести к нарушению безопасности системы, данных или бизнес-процессов.
- Sensitive Modes of Operation (чувствительные режимы работы) — это специальные режимы функционирования ПО, которые предоставляют расширенные привилегии, возможности управления или доступ к внутренним механизмам ПО.
Совет PCI SSC также издал отдельный документ PCI SSS Sensitive Asset Identification, который дополняет стандарт PCI SSS 2.0. Документ содержит важную информацию: методы определения чувствительных данных, ресурсов, функциональности и режимов работы ПО, а также шаблоны перечней для их описания. Представленные в документе примеры защищаемых активов из Приложения А разработчики ПО могут использовать при подготовке к аудиту на соответствие PCI SSS.
Изменение структуры требований и проверочных процедур
В предыдущей версии PCI SSS было явно определено, какие организационные и технические меры защиты критических активов должны быть реализованы на уровне программного обеспечения и процессов в компании. Такой подход не учитывал особенностей архитектуры ПО и часто приводил к формальному выполнению требований.
В обновлённой версии стандарта каждое требование описывает цель — результат, который должен быть достигнут, без жёсткого предписания конкретных способов её достижения. Такой подход близок к одному из вариантов выполнения требований, предусмотренных стандартом PCI DSS 4.0.1, и направлен на повышение гибкости при реализации мер защиты.
Одновременно с этим изменился подход к проверочным процедурам. В версии 2.0 стандарт прямо закрепляет необходимость использования как статического, так и динамического анализа безопасности ПО при проверке выполнения ряда требований. То, что раньше подразумевалось, теперь явно прописано в стандарте: предоставление исходного кода аудитору является обязательным.
Тем самым формат аудита смещается от формальной проверки процессов и функций ПО к технически обоснованной оценке защищённости ПО.
В обновлённой версии стандарта каждое требование описывает цель — результат, который должен быть достигнут, без жёсткого предписания конкретных способов её достижения. Такой подход близок к одному из вариантов выполнения требований, предусмотренных стандартом PCI DSS 4.0.1, и направлен на повышение гибкости при реализации мер защиты.
Одновременно с этим изменился подход к проверочным процедурам. В версии 2.0 стандарт прямо закрепляет необходимость использования как статического, так и динамического анализа безопасности ПО при проверке выполнения ряда требований. То, что раньше подразумевалось, теперь явно прописано в стандарте: предоставление исходного кода аудитору является обязательным.
Тем самым формат аудита смещается от формальной проверки процессов и функций ПО к технически обоснованной оценке защищённости ПО.
Процесс анализа вносимых изменений и использование подстановочных знаков (wildcard)
Изменения также затронули руководящий документ Program Guide, в соответствии с которым проводится аудит на соответствие PCI SSS. В предыдущей версии стандарта изменения в ПО делились на две категории: изменения с «низким» уровнем воздействия и «высоким» уровнем воздействия на безопасность. Эти категории были заменены на дельта-изменения 1 и 2 уровней (Tier 1 и Tier 2).
Тип изменения | Описание | Вендор со статусом SSLC | Вендор без статуса SSLC |
Изменения, допускающие использование подстановочного знака (wildcard) | Только для не влияющих на безопасность изменений в отношении ПО из Листинга Совета PCI SSC (Validated Secure Software Product Listing). Изменения, соответствующие wildcard-части версии, не требуют валидации со стороны Совета PCI SSC. Подстановочные знаки (wildcard) не могут использоваться для изменений Tier 1 Delta и Tier 2 Delta. | Допустимо к применению | Допустимо к применению |
Tier 1 Delta | 1.Любые изменения ПО, не влияющие на безопасность, но при которых необходимо изменить номер версии ПО. При этом вендор ПО ранее не использовал подстановочные знаки (wildcard) при регистрации ПО в Листинге Совета PCI SSC. или 2.Только для вендоров со статусом SSLC: Любые исправления и патчи, влияющие на безопасность, даже если они затрагивают защищаемые активы. | Не требуется привлечение аудитора | Требуется привлечение аудитора |
Tier 2 Delta | 1.Для вендоров без статуса SSLC: Любые исправления и патчи, влияющие на безопасность. 2. Добавление в ПО нового типа защищаемых активов (Sensitive data, Sensitive functionality, Sensitive resource). 3. Любое изменение, которое требует проверки новых требований Стандарта, не охваченных предыдущей оценкой. Сюда относятся как отдельные требования, которые ранее были признаны «Неприменимыми», так и целые дополнительные модули, которые ранее не оценивались. 4. Изменения, касающиеся устройств PTS POI, включая аппаратное обеспечение (hardware, HW) и(или) прошивку (firmware, FW). 5. Удаление определенной версии ПО из Листинга Совета PCI SSC (Validated Secure Software Product Listing). 6. Изменение необходимых зависимостей в ПО. | Требуется привлечение аудитора |
Таким образом, первичная оценка ПО и его регистрация в Листинге Совета PCI SSC возможны только с привлечением аудитора. Далее при наличии статуса SSLC изменения Tier 1 Delta можно выполнять самостоятельно, без привлечения аудитора, напрямую связываясь с Советом PCI SSC через их Портал. Для изменений Tier 2 Delta привлечение аудитора является обязательным.
Также стало возможным использование подстановочных знаков (wildcards), т.е. в Листинге Совета PCI SSC можно указывать версию ПО как 4.*.*. Версии, содержащие изменения, не влияющие на безопасность, можно выпускать под номером 4.1.0, 4.1.1 и т.д., без уведомления Совета PCI SSC. Ключевое правило: использование подстановочных знаков (wildcards) должно быть проверено и подтверждено аудитором во время полной оценки (Full Assessment). Аудитор должен убедиться, что разработчик понимает, какие типы изменений допустимы в рамках wildcard, а какие потребуют повторной оценки ПО.
Также стало возможным использование подстановочных знаков (wildcards), т.е. в Листинге Совета PCI SSC можно указывать версию ПО как 4.*.*. Версии, содержащие изменения, не влияющие на безопасность, можно выпускать под номером 4.1.0, 4.1.1 и т.д., без уведомления Совета PCI SSC. Ключевое правило: использование подстановочных знаков (wildcards) должно быть проверено и подтверждено аудитором во время полной оценки (Full Assessment). Аудитор должен убедиться, что разработчик понимает, какие типы изменений допустимы в рамках wildcard, а какие потребуют повторной оценки ПО.
Включение в стандарт требований к SDK
SDK – это набор библиотек, интерфейсов и компонентов, предназначенных для встраивания в программные продукты для расширения их функциональности. При этом безопасность конечного решения во многом зависит именно от свойств SDK, даже если он не используется напрямую для обработки чувствительных данных.
В новой версии стандарта для SDK выделен отдельный раздел требований (Module D). Ранее такие компоненты не рассматривались как самостоятельный объект оценки. Их безопасность проверялась только в составе ПО либо вовсе исключалась из области аудита.
Это делает возможным проводить оценки безопасности SDK, специфичных для EMVCo 3DS. Здесь стоит напомнить, что в индустрии платежных карт существует стандарт PCI 3DS SDK, который является обязательным для вендоров SDK, используемых для аутентификации покупателей в рамках протокола EMV 3-D Secure. Совет PCI SSC ведет к тому, что новый стандарт PCI SSS версии 2.0 и его последующие версии станут полной заменой стандарту PCI 3DS SDK.
В новой версии стандарта для SDK выделен отдельный раздел требований (Module D). Ранее такие компоненты не рассматривались как самостоятельный объект оценки. Их безопасность проверялась только в составе ПО либо вовсе исключалась из области аудита.
Это делает возможным проводить оценки безопасности SDK, специфичных для EMVCo 3DS. Здесь стоит напомнить, что в индустрии платежных карт существует стандарт PCI 3DS SDK, который является обязательным для вендоров SDK, используемых для аутентификации покупателей в рамках протокола EMV 3-D Secure. Совет PCI SSC ведет к тому, что новый стандарт PCI SSS версии 2.0 и его последующие версии станут полной заменой стандарту PCI 3DS SDK.
Обновление PCI 3DS Data Matrix
Обновления в стандарте PCI SSS привели к появлению в PCI 3DS Data Matrix отдельного раздела, посвящённого 3DS SDK. В нём определён перечень данных, которые могут собираться, обрабатываться или передаваться SDK и которые подлежат защите в соответствии с требованиями стандартов индустрии платёжных карт.
Для каждого типа данных указано, какие свойства безопасности должны быть обеспечены —конфиденциальность или целостность, — а также допускается ли их хранение внутри SDK. Свойство доступности в Data Matrix не рассматривается. При этом, для большинства типов данных хранение в SDK прямо запрещено, что подчёркивает его роль, как транзитного компонента, не предназначенного для долговременного хранения чувствительной информации.
В таблице ниже приведён перечень основных типов данных, требования к их безопасности и ограничения на хранение внутри SDK.
Для каждого типа данных указано, какие свойства безопасности должны быть обеспечены —конфиденциальность или целостность, — а также допускается ли их хранение внутри SDK. Свойство доступности в Data Matrix не рассматривается. При этом, для большинства типов данных хранение в SDK прямо запрещено, что подчёркивает его роль, как транзитного компонента, не предназначенного для долговременного хранения чувствительной информации.
В таблице ниже приведён перечень основных типов данных, требования к их безопасности и ограничения на хранение внутри SDK.
Тип данных | Описание | Требования безопасности | Хранение в SDK |
Информация об устройстве. | Сведения об устройстве пользователя, зашифрованные данные устройства, а также транзакционные данные, получаемые 3DS SDK от приложения 3DS Requestor через API. | Обеспечение конфиденциальности и целостности. | Запрещено |
Открытые ключи для установления сессии (асимметричное шифрование). | Временные открытые ключи ACS и 3DS SDK, используемые для установления защищённого канала связи. | Обеспечение целостности. | Запрещено |
Закрытые и сессионные ключи. | Внутренние временные закрытые ключи и ключи сессий, используемые 3DS SDK. | Обеспечение конфиденциальности и целостности. | Запрещено |
Аутентификационные данные. | Данные, получаемые SDK в сообщениях CRes, данные, передаваемые SDK в сообщениях CReq, а также данные, вводимые пользователем в процессе аутентификации. | Обеспечение конфиденциальности и целостности. | Запрещено |
Статические данные 3DS SDK. | Данные, относящиеся непосредственно к SDK (идентификатор приложения SDK, справочный номер SDK, тип SDK, максимальный таймаут, открытый ключ DS). | Обеспечение целостности. | Разрешено |
Иные изменения
В новую версию стандарта PCI SSS 2.0 также вошли следующие изменения:
1. Требования по безопасному процессу разработки, которые пересекались с требованиями стандарта PCI Secure Software Lifecycle (SLC), были удалены.
2. Описание обязанностей и ответственности сторон, участвующих в оценке по PCI SSS, перенесено в Program Guide.
3. Глоссарий терминов был перенесен из отдельного документа в Приложение А стандарта PCI SSS. Был введен термин «Strong Authentication», в котором стандарт опирается на концепцию «Strong Cryptography», определенную в Глоссарии Совета PCI SSC, а не на конкретные параметры криптографических ключей.
4. Требования стандарта были перераспределены по разным целям безопасности и модулям. Было создано 11 общих целей безопасности (Security Objectives), которые применяются ко всему ПО, и 4 специфических модуля:
─ Module A: Защита данных платежных карт. Требования предыдущей версии стандарта были пересмотрены.
─ Module B: ПО для POI-устройств. В сравнении с предыдущей версией стандарта, этот модуль был значительно упрощен, поскольку часть требований включили в основные требования (Цели безопасности), а требования к SRED (Secure Reading and Exchange of Data — безопасное считывание и обмен данными) были пересмотрены.
─ Module C: Публично-доступное ПО. Ранее модуль назывался «Требования к веб-приложениям».
─ Module D: SDK. Новый модуль, посвящённый безопасности SDK, о котором ранее уже упоминалось.
5. Появился отдельный набор требований, связанных с архитектурой ПО, его составом и правилами управления версиями (Security Objective 1). В рамках этого раздела устанавливаются требования к:
─ описанию архитектуры ПО;
─ идентификации и учёту всех компонентов, входящих в состав ПО, включая сторонние библиотеки и модули (Software Bill of Materials, SBOM);
─ документированию методики управления версиями ПО.
1. Требования по безопасному процессу разработки, которые пересекались с требованиями стандарта PCI Secure Software Lifecycle (SLC), были удалены.
2. Описание обязанностей и ответственности сторон, участвующих в оценке по PCI SSS, перенесено в Program Guide.
3. Глоссарий терминов был перенесен из отдельного документа в Приложение А стандарта PCI SSS. Был введен термин «Strong Authentication», в котором стандарт опирается на концепцию «Strong Cryptography», определенную в Глоссарии Совета PCI SSC, а не на конкретные параметры криптографических ключей.
4. Требования стандарта были перераспределены по разным целям безопасности и модулям. Было создано 11 общих целей безопасности (Security Objectives), которые применяются ко всему ПО, и 4 специфических модуля:
─ Module A: Защита данных платежных карт. Требования предыдущей версии стандарта были пересмотрены.
─ Module B: ПО для POI-устройств. В сравнении с предыдущей версией стандарта, этот модуль был значительно упрощен, поскольку часть требований включили в основные требования (Цели безопасности), а требования к SRED (Secure Reading and Exchange of Data — безопасное считывание и обмен данными) были пересмотрены.
─ Module C: Публично-доступное ПО. Ранее модуль назывался «Требования к веб-приложениям».
─ Module D: SDK. Новый модуль, посвящённый безопасности SDK, о котором ранее уже упоминалось.
5. Появился отдельный набор требований, связанных с архитектурой ПО, его составом и правилами управления версиями (Security Objective 1). В рамках этого раздела устанавливаются требования к:
─ описанию архитектуры ПО;
─ идентификации и учёту всех компонентов, входящих в состав ПО, включая сторонние библиотеки и модули (Software Bill of Materials, SBOM);
─ документированию методики управления версиями ПО.
Расширилась ли область оценки?
Стандарт по-прежнему применяется к вендорам ПО и компонентов, используемых в индустрии платежных карт, однако, как уже было сказано ранее, в области действия стандарта теперь может оказаться любое ПО, обрабатывающее защищаемые активы, даже если ранее такое ПО не считалось платежным.
Когда выполнение требований новой версии PCI SSS станет обязательным?
Совет PCI SSC ввёл переходный период, связанный с необходимостью обучения аудиторов. Со второго квартала 2026 года организации, проходящие аудит на соответствие PCI Secure Software Standard, могут выбирать между версиями стандарта 1.2.1 и 2.0. С конца второго квартала 2027 года PCI SSS версии 1.2.1 утратит силу.
Шаблоны отчетных документов, таких как Сертификат (Attestation of Validation, AOV) и Отчет (Report on Validation, ROV) так же будут пересмотрены и обновлены в ближайшее время.
На текущий момент времени Совет PCI SSC разрабатывает новую версию стандарта Secure Software Lifecycle (SSLC).
Шаблоны отчетных документов, таких как Сертификат (Attestation of Validation, AOV) и Отчет (Report on Validation, ROV) так же будут пересмотрены и обновлены в ближайшее время.
На текущий момент времени Совет PCI SSC разрабатывает новую версию стандарта Secure Software Lifecycle (SSLC).
Что следует начать уже сейчас?
1. Изучите документ PCI SSS Sensitive Asset Identification. Это ключевой инструмент для понимания того, как идентифицировать и документировать защищаемые активы.
2. Проведите инвентаризацию защищаемых активов в своем ПО: сопоставьте данные, функции и ресурсы с определениями из стандарта.
3. Сравните текущую реализацию вашего ПО с 11 новыми целями безопасности и требованиями модулей.
4. Обновите методику управления версиями, чтобы использовать преимущества подстановочных знаков (wildcards) в номерах версий.
5. Рассмотрите возможность получения статуса Secure Software Lifecycle (SSLC) для получения преимуществ при внесении изменений 1-го уровня (Tier 1 Delta).
2. Проведите инвентаризацию защищаемых активов в своем ПО: сопоставьте данные, функции и ресурсы с определениями из стандарта.
3. Сравните текущую реализацию вашего ПО с 11 новыми целями безопасности и требованиями модулей.
4. Обновите методику управления версиями, чтобы использовать преимущества подстановочных знаков (wildcards) в номерах версий.
5. Рассмотрите возможность получения статуса Secure Software Lifecycle (SSLC) для получения преимуществ при внесении изменений 1-го уровня (Tier 1 Delta).
Новая версия PCI Secure Software Standard 2.0 отражает переход Совета PCI SSC от строгого формального подхода к более гибкой и зрелой модели оценки безопасности ПО. Требования стандарта становятся всё более ориентированы на достижение целей безопасности, а не на привязку к конкретным методам обеспечения безопасности.