PA-DSS и PCI Software Security Framework

Итак, с 2020 года начался прием заявок на сертификацию приложений по требованиям PCI Software Security Framework (PCI SSF). В июне 2021 года завершился прием заявок на сертификацию новых приложений по стандарту PA-DSS. Текущий список приложений, соответствующих требованиям стандарта PA-DSS, будет действителен до октября 2022 года.

PCI SSF состоит из двух связанных между собой стандартов — ​Secure Software Standard (SSS) и Secure Software Lifecycle (Secure SLC) Standard.

Secure Software Standard определяет набор требований по безопасности и связанных с ними процедур, выполнение которых гарантирует, что платежное программное обеспечение защищает целостность и конфиденциальность платежных операций и обрабатываемых данных. После прохождения оценки по Secure Software Standard приложение, прошедшее оценку, заносится в перечень Validated Payment Software.

Secure SLC Standard определяет набор требований к поставщикам программного обеспечения по управлению безопасностью поставляемого ими платежного программного обеспечения на протяжении всего жизненного цикла. После прохождения оценки по Secure SLC Standard поставщики программного обеспечения попадают в перечень сертифицированных поставщиков — ​Secure SLC Qualified Vendors.

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

PCI Secure Software Standard и PCI Secure SLC Standard

PCI Secure Software Standard предназначен для платежного программного обеспечения, которое продается или распространяется третьим лицам. В таб. 1 приведены условия применимости PCI Secure Software Standard к платежным приложениям.

Таким образом, PCI Secure Software Standard не предназначен для платежного программного обеспечения, являющегося самописной разработкой, а также разработанного и проданного лишь одному клиенту.

Существует два типа оценки соответствия PCI Secure Software Standard:

• полная оценка соответствия;
• дельта-чек.

Полная оценка проводится квалифицированным оценщиком Secure Software Assessor. Дельта-чеки необходимо проходить при внесении незначительных изменений в программное обеспечение, выполненных в периоды между полными оценками соответствия. Перечень изменений, относящихся к незначительным, приводится на сайте Совета PCI SSC. Дельта-чеки подтверждают, что обновления программного обеспечения не создают новых уязвимостей и программное обеспечение продолжает соответствовать требованиям PCI Secure Software Standard. Дельта-чеки могут выполняться поставщиками со статусом Secure SLC Qualified Vendor.

Secure SLC Standard предназначен для поставщиков программного обеспечения, которые разрабатывают программное обеспечение для индустрии платежей. После прохождения сертификации поставщику присваивается статус Secure SLC Qualified Vendors и предоставляется возможность проведения дельта-­чеков без привлечения сторонних оценщиков.

Подходы к оцениванию Software Security Framework

В отличие от PA-DSS, PCI SSF предусматривает риск-ориентированный подход. Это означает, что теперь поставщики программного обеспечения могут определять способы достижения целей (требований), поставленных стандартами. Для этого они могут выполнить прямые требования стандарта или на основании проведенной оценки рисков определить векторы возможных атак и внедрить меры по снижению возможных рисков. Таким образом, Совет PCI SSC уходит от политики «one size fits all» (одинаковые требования для всех) при построении безопасности программного обеспечения.

Разумеется, такой подход накладывает дополнительные требования на процесс управления рисками. Периодичность применения выбранных мер должна быть документирована и обоснована, а сами меры должны достигать целей, требуемых стандартом. Поставщик должен продемонстрировать и доказать аудитору, что его организационные и технические меры контроля безопасности являются эффективными и соответствуют требованиям PCI SSF.

Сравнение требований PCI SSF с требованиями PA-DSS

PA-DSS содержит более конкретные требования по обеспечению информационной безопасности по сравнению с PCI SSF. Так, на ряд требований PCI SSF приходится сразу несколько требований PA-DSS, например, требования 5 раздела стандарта PCI Secure Software Standard:

5.1. Определить требования к аутентификации, тип доступа и уровень привилегий для всех ролей и ученых записей.

5.2, 5.4. Доступ к критичным активам должен быть защищен, ограничен и персонифицирован.

В PA-DSS по данным требованиям были описаны 3‑й и 12‑й разделы:

3.1.3. Использовать уникальные идентификаторы пользователей.

3.1.4. Использовать определенные методы аутентификации, как минимум один из следующих:
­что-то, что вы знаете;
что-то, что у вас есть;
что-то, чем вы являетесь.

3.1.5. Не использовать групповые, общие учетные записи и пароли.

3.1.6, 3.1.7, 3.1.8. Пароль должен соответствовать следующим требованиям:

• длина не менее 7 символов;
• наличие как букв, так и цифр;
• смена пароля — ​раз в 90 дней;
• новый пароль должен отличаться от последних четырех используемых паролей.

12.1 Неконсольный административный доступ должен быть защищен посредством стойкого шифрования при помощи таких технологий, как SSH, VPN или SSL/TLS.

Еще один пример — ​относительно криптографической защиты в PCI Secure Software Standard существуют лишь следующие требования:

7.1. Использовать криптографические алгоритмы и методы, признанные отраслевыми стандартами.

7.2. Использовать процедуры управления ключами, признанные отраслевыми стандартами.

7.3, 7.4. Использовать генераторы случайных чисел, признанные отраслевыми стандартами. Случайные числа должны иметь энтропию, удовлетворяющую минимальным требованиям отраслевых стандартов.

В PA-DSS на этот счет расписаны конкретные процедуры управления ключами шифрования, обязательные к внедрению.

Иначе говоря, Совет PCI SSC обобщил требования PA-DSS и распределил их между двумя стандартами PCI Secure Software Standard и PCI Secure SLC Standard. В PCI Secure SLC Standard, например, сохранились требования по управлению изменениями и распределению ответственности:

1.2. Назначить ответственность за безопасность программного обеспечения на всех этапах SDLC.

1.3. Обеспечить разработчиков программного обеспечения знаниями в области ИБ, соответствующими их роли и обязанностям.

5.1. Идентифицировать, контролировать и согласовывать все изменения в программном обеспечении.

5.2. Обеспечивать маркировку и отслеживание версий программного обеспечения.

К программному обеспечению POI-устройств (Point of Interaction — ​точка взаимодействия, точка инициализации транзакции) — ​в Secure Software Standard помимо требований основного модуля определены требования дополнительного модуля B (см. таб. 2). Более того необходимо, чтобы платежные приложения разрабатывались под POI-устройства, одобренные Советом PCI SSC.

Исходя из всего вышесказанного, PCI SSF сохранил лучшие практики обеспечения безопасности платежного программного обеспечения из стандарта PA-DSS и дополнил их собственным подходом к построению информационной безопасности на основе оценки рисков.

Темы перехода к новым стандартам PCI SSF также рассматривалась на конференции #PAYMENTSECURITY, состоявшейся 14‑16 июля 2021 года. В ходе конференции состоялся круглый стол с представителями банковской сферы и экспертами по информационной безопасности.

Источник: ПЛАС