С 22 по 24 октября 2019 года в Дублине прошла ежегодная конференция PCI Community Meeting, организованная Советом PCI SSC, в рамках которой его представителями был анонсирован ряд важных нововведений. Владимир Ковалев, инженер по защите информации компании Deiteriy, принимавшей участие в мероприятии, делится с журналом «ПЛАС» наиболее актуальными итогами конференции.
Тема появления новых версий стандартов была затронута в первый же день работы конференции, 22 октября. По заявлению представителей PCI SSC, вместо PCI DSS v3.2.1 будет выпущена новая версия стандарта PCI DSS v4.0. В свою очередь, вместо стандарта PA-DSS уже выпущена серия стандартов и сопровождающих документов Secure Software Framework (SSF). А на смену стандарту PCI P2PE v2.0 придет новая версия PCI P2PE v3.0. Чтобы предоставить возможность применять мобильные устройства для приема платежей посредством платежных карт, представители Совета PCI SSC разработали стандарт Contactless Payments on COTS Standard. Рассмотрим имеющуюся на сегодняшний день информацию о каждой из новых версий.
PCI DSS v4.0
В новой версии стандарта PCI DSS предполагается большая гибкость в достижении соответствия требованиям. На смену компенсационным мерам в классическом варианте придут два других варианта достижения соответствия требованиям стандарта: defined implementation и customized implementation.
- Defined implementation. Этот подход используется в актуальной версии 3.2.1, а также использовался и в предыдущих версиях. Суть его заключается в том, что в каждом требовании стандарта PCI DSS описана контрмера, которую необходимо внедрить, и описана проверочная процедура, которую необходимо выполнить, чтобы оценить эффективность внедрения контрмеры. В случае если в компании по какой-либо причине невозможно внедрить описанную в стандарте контрмеру, в версиях стандарта 3.2.1 и более ранних необходимо внедрять компенсационные меры для снижения риска, от которого закрывает основная контрмера.
- Customized implementation. Это альтернативный способ достижения целей каждого требования, введенный в PCI DSS v4.0. В случае с customized implementation контрмера может быть определена компанией самостоятельно в зависимости от возможностей, бизнес-процессов и требований к безопасности в самой компании. Однако вместе с вводимой контрмерой необходимо также внедрить метод оценки ее эффективности, который будет использоваться аудитором вместо проверочной процедуры стандарта из варианта defined implementation. В предыдущих версиях стандарта PCI DSS необходимо было указать официальную причину невозможности внедрения требуемой контрмеры. Поскольку при использовании customized implementation такую причину указывать не требуется, компании смогут более гибко подходить к реализации требований стандарта новой версии.
Для разных требований стандарта можно применять разные подходы достижения соответствия (например, для одних требований можно использовать defined implementation, а для других – customized implementation). Поскольку в новой версии стандарта допустимо определять контрмеры в компании самостоятельно, пропадает смысл использовать компенсационные меры, которые, соответственно, из нее исчезли.
Именно такое нововведение обеспечивает гибкость, облегчает приведение к соответствию и поддержку соответствия требованиям стандарта PCI DSS для компаний с высокой зрелостью риск-ориентированной модели управления информационной безопасностью. Первый черновой вариант стандарта был опубликован Советом в закрытом доступе в конце октября 2019 года. Вместе с первым полным черновым вариантом стандарта были опубликованы шаблоны отчетных документов, сводка информации об изменениях в стандарте новой версии и информация о новом подходе в целом.
В первом квартале 2020 года Совет PCI SSC намерен рассмотреть все комментарии, полученные через программу RFC (Request For Comments). Во втором квартале 2020 года планируется проведение дополнительного периода программы RFC. После обработки комментариев, полученных во второй волне, будет выпущена окончательная версия стандарта PCI DSS v4.0. Доступ к черновому варианту стандарта и программе RFC в целом имеют только основные контактные лица организаций:
- участников PCI SSC;
- QSA;
- ASV.
Secure Software Framework (SSF)
Также в первый день конференции PCI Community Meeting был представлен доклад о нововведениях Совета в области разработки приложений, а именно о серии стандартов, руководств и других документов, относящихся к SSF. Все документы уже опубликованы в открытом доступе на официальном сайте Совета. При этом планируется дополнить стандарт специальными модулями, в которых будут описаны Function-Specific и Platform-Specific требования. Это позволит упростить обеспечение безопасности приложений в зависимости от выполняемой приложением функции или от платформы, для которой оно разработано.
Для SSF предусмотрено три сценария проведения аудита. Первый сценарий – проведение аудита безопасного жизненного цикла ПО. На рис. 1 представлен процесс проведения аудита безопасности жизненного цикла ПО (Secure software lifecycle), разрабатываемого в компании.
На рис. 2 представлен второй сценарий проведения аудита по Secure Software конкретного платежного приложения вендора.
В случае с сертификацией по Secure Software, как указано на рис. 2, Совету отправляется заполненный ROV (Report On Validation), подтверждающий статус соответствия платежного приложения.
Последний сценарий аудита описывает последовательность самооценки при обновлении или изменении платежного приложения. Согласно информации, предоставленной PCI SSC, компания, сертифицированная по Secure SLC, может выполнять самооценку при каких-либо изменениях и обновлениях платежного приложения, находящегося в списке Validated Secure Software. Сценарий такой самооценки представлен на рис. 3.
Возможность проведения сертификационного аудита по новым стандартам безопасности в области платежных приложений и их разработки появится только в первом квартале 2020 года, поскольку программа обучения сертифицированных аудиторов появится только в этот период. В июне 2021 года закончится возможность сертификации платежных приложений по стандарту PA-DSS, а в октябре 2022 года программа PA-DSS окончательно завершит свое существование.
PCI P2PE v3.0
На дублинской конференции был анонсирован выход новой версии стандарта PCI P2PE v3.0. Одним из важнейших нововведений этого стандарта является изменение структуры сертификации. Для того чтобы понять, как именно изменилась структура сертификации, стоит для начала рассмотреть высокоуровневую архитектуру системы, к которой применимо P2PE решение. На рис. 4 представлен пример такой высокоуровневой архитектуры.
Как изображено на рисунке, в архитектуру сертифицированного по стандарту P2PE решения входят две области, первая из которых – среда шифрования данных на стороне торгово-сервисного предприятия (ТСП). Ее составляющими являются:
1. Держатель платежной карты, который инициирует операции с данными платежной карты.
2. POI (Point Of Interaction) устройство. Оно, в свою очередь, состоит из следующих компонентов:
- Метод считывания данных платежной карты (например, считыватель магнитной ленты, считыватель чипа или NFC-считыватель). Соответственно, этому компоненту данные платежной карты передаются в открытом виде.
- Прошивка для безопасного считывания и обмена данными с системой шифрования. Этот компонент должен сам соответствовать или взаимодействовать с компонентом, соответствующим стандарту P2PE в области управления ключами и требованиям к криптографии в целом. Соответственно, с помощью этого компонента обеспечивается конфиденциальность данных платежных карт.
- Интерфейсы взаимодействия, через которые передаются данные программному обеспечению ТСП в процессинговый центр для обработки операций, а также интерфейсы взаимодействия, необходимые для загрузки или управления ключами самого POI-устройства.
- Интерфейсы приложений, позволяющие взаимодействовать с различными приложениями самого POI-устройства для обработки данных платежных карт (например, «обрезать» полный номер карты перед передачей его в кассовое ПО для печати чека).
- Приложения POI-устройства для обработки данных платежных карт.
3. Кассовое программное обеспечение или другие системы торгово-сервисного предприятия. Такое ПО обычно не получает данные платежной карты в открытом виде.
Вторая область – среда безопасной расшифровки данных платежных карт, которая включает в себя:
1. Процессинг операций по платежным картам. Как правило, получает зашифрованные данные от POI-устройства, а затем передает криптограмму HSM (Hardware Secure Module) для расшифрования и обработки операции.
2. HSM служит для проведения криптографических операций с данными платежных карт. В этом устройстве должно быть обеспечено соответствие требованиями P2PE в области управления ключами и криптографии в целом. Также в HSM происходит загрузка ключей и управление криптографическими ключами.
В стандарте P2PE v2.0 существуют 4 типа Component Provider для сертификации P2PE решения:
- KIF (Key Injection Facilities);
- CA/RA (Certification Authority/Registration Authority);
- Encryption Management;
- Decryption Management.
Так как развитие в платежной индустрии происходит непрерывно, возникают новые сервисы, которые могут передаваться на аутсорсинг. Таким образом, для облегчения сертификации и работы решений, сертифицированных по P2PE v.3.0, были добавлены еще 4 типа Component Provider:
- Установка устройств для взаимодействия (POI Deployment);
- Управление устройствами для взаимодействия (POI Management);
- Загрузка ключей (Key loading);
- Управление ключами (Key management).
При этом POI Deployment и POI Management являются составляющими сервисами Encryption Management, а Key Loading и Key Management – составляющие сервисы KIF. На рис. 5 представлены актуальные типы Component Provider в P2PE v3.0.
В связи с появлением новых типов Component Provider изменилась и структура сертификации по новой версии стандарта. На рис. 6 представлены сервисы, которые могут быть сертифицированы по P2PE v3.0.
В ходе конференции представители Совета PCI SSC сообщили о том, что для перехода на новую версию стандарта планируется выделить 18 месяцев, в течение которых будут актуальны обе версии стандарта.
Contactless Payments on COTS Standard
Как заявили на мероприятии, стандарт Contactless Payments on COTS планировалось опубликовать в начале 2020 года. Однако 4 декабря в блоге Совета PCI SSC Лаура Грей (Laura K. Gray) сообщила о том, что новый стандарт уже доступен на официальном сайте совета PCI SSC. Как заявили на мероприятии, в начале 2020 года планируется публикация стандарта Contactless Payments on COTS Standard. Внедрение этого нового стандарта позволит использовать мобильные устройства, планшеты и т. п. для приема оплаты посредством платежных карт. На рис. 7 представлена высокоуровневая архитектура взаимодействия при бесконтактной оплате платежной картой или мобильным устройством через COTS (Commercial Of The Shelf) устройство.
Стоит отметить, что в стандарте рассматриваются только случаи, когда:
1. Используется встроенный NFC-интерфейс для бесконтактной оплаты через COTS-устройство.
2. Поддерживаются только транзакции для бесконтактной EMV-оплаты или транзакции со считыванием данных магнитной полосы.
3. Безопасность опирается на защитные механизмы приложения, проверку компонентов на COTS-устройстве, а также мониторинг на стороне серверной части приложения.
4. Запрещены PIN/CVM транзакции.
Есть два варианта реализации платежного приложения и системы регистрации событий. На рис. 8.а и 8.б представлены оба эти варианта.
На рисунке 8.а представлен вариант, когда система регистрации событий находится отдельно от платежного приложения. Платежное приложение по безопасному каналу передает данные системе регистрации событий на этом же COTS-устройстве. В свою очередь, система регистрации событий по безопасному отдельному каналу передает данные серверной части.
На рисунке 8.б представлен вариант, когда система мониторинга встроена в платежное приложение на COTS-устройстве, соответственно, данные платежного приложения и системы мониторинга передаются по одному защищенному каналу серверной части приложения. В настоящей статье описаны самые значимые изменения, анонсированные представителями PCI SSC на Community Meeting 2019 в Дублине. В заключение стоит отметить, что индустрия платежных карт непрерывно развивается, и в поддержку такого развития адаптируются существующие и разрабатываются новые стандарты безопасности в этой индустрии.