Новости: Когда ждать PCI DSS v4.0
08.09.2020

Когда ждать PCI DSS v4.0

Когда ждать PCI DSS v4.0 Когда ждать PCI DSS v4.0

Новая версия PCI DSS v4.0 уже бьет рекорды – в процессе запроса комментариев (Request For Comments - RFC) получено 3200 ответов! Это больше, чем в отношении любого стандарта PCI SSC. Причем почти 40% обратной связи идет от представителей торговли. Это повлияло и на график выпуска и жизненного цикла стандарта (Time Line), и на будущие сроки выполнения требований, в частности появились такие пункты, как «будущие требования», или «future-dated requirements», о чем пойдет речь ниже в статье.

Изменения

Организация Payment Card Inductry Security Standards Council (PCI SSC) – совет, созданный коллективным решением международных платежных систем VISA, Master Card, American Express, JCB, Discover, – уже почти 15 лет занимается разработкой и поддержкой стандартов обеспечения безопасности данных индустрии платежных карт. Основными прорабатываемыми советом документами являются:

  • PCI DSS (Payment Card Industry Data Security Standard) – стандарт, определяющий требования безопасности к поставщикам услуг и торгово-сервисным предприятиям, использующим в обращении платежные карты.

  • PCI PA-DSS (Payment Card Industry Payment Application Data Security Standard) – стандарт, определяющий требования по безопасности к платежным приложениям, обрабатывающим данные о держателях карт, и процессу разработки указанных приложений. Стандарт направлен на защиту от атак вида «цепочки поставки».

  • PCI P2PE (Payment Card Industry Point-to-Point Encryption) – стандарт, содержащий требования к решениям по шифрованию данных платежных карт при передаче между участниками процедуры оплаты (от торгово-сервисного предприятия до банка-эквайера).

  • PCI PTS (Payment Card Industry PIN Transaction Security) – стандарт, содержащий требования к обрабатывающим персональный идентификатор (PIN) устройствам: POS-терминалам, PIN-клавиатурам, аппаратным модулям безопасного хранения и обработки действий с PIN (HSM).

  • PCI TSP (Payment Card Industry Token Service Provider) – требования безопасности для поставщиков услуг токенизации.

  • Стандарт Card Production – стандарт для эмитентов платежных карт (выпускающий карты организаций).

  • PCI 3DS Core Security Standard – стандарт безопасности для организаций, выполняющих или предоставляющих функции платежей без физического предоставления карты.

Фокус внимания ключевого стандарта PCI DSS версии 3.2, ввиду роста популярности сервисных моделей в ИТ, уже смещен в сторону расширения ответственности сервис-провайдеров и критериев оценки всех участников, вовлеченных в обслуживание транзакций. Стандарт PCI DSS v3.2 содержит в себе двенадцать разделов проверки безопасности систем:

  • защита вычислительной сети;

  • конфигурация компонентов информационной инфраструктуры;

  • защита хранимых данных о держателях карт;

  • защита передаваемых данных о держателях карт;

  • антивирусная защита информационной инфраструктуры;

  • разработка и поддержка информационных систем;

  • управление доступом к данным о держателях карт;

  • механизмы аутентификации;

  • физическая защита информационной инфраструктуры;

  • протоколирование событий и действий;

  • контроль защищенности информационной инфраструктуры;

  • управление информационной безопасностью.

В то время как 12 основных требований PCI DSS в прорабатываемой версии v4.0 остаются в основном неизменными, предлагается несколько новых требований для устранения растущих рисков и угроз платежным данным и для усиления безопасности как непрерывного процесса. Кроме того, все текущие требования перерабатываются, чтобы сосредоточиться на целях безопасности и возможности дать больше гибкости организациям, использующим различные методологии для соответствия требованиям PCI DSS.

Наибольшее количество вопросов вызвали следующие пункты вышедшего на обсуждение драфта стандарта:

  • Требование 4: защищать данные держателей карт (CHD) с помощью надежной криптографии во время передачи, включая требования защиты для всех передач CHD и использования самоподписанных / внутренних сертификатов.

  • Требование 8: идентификация пользователей и аутентификация доступа, включая требования: длины, истории и частоты смены пароля и соответствия их отраслевым рекомендациям; сравнения новых паролей со списком известных плохих паролей; подтверждения всех факторов многофакторной аутентификации перед предоставлением каких-либо указаний на успех или неудачу фактора; безопасной аутентификации для учетных записей приложений / системы.

  • Требование 9: ограничить физический доступ к данным держателей карт, в том числе расположению уязвимых областей в среде данных о держателях карт.

  • Требование 11: Регулярно тестировать системы и процессы безопасности, включая проверку подлинности при сканировании уязвимостей.

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

Кроме актуализации стандарта, целью новой версии является выработка отношения к ИБ как к постоянному процессу (continuous process), усиление методов валидации и процедур ИБ. По словам представителей совета PCI SSC это реализуется следующим образом: требования будут записаны в виде утверждений, основанных на результатах, с упором на реализацию контроля безопасности в качестве конечного результата. Для многих требований это достигается простым изменением формулировки: с формулировки того, что «должно» быть реализовано, на то, каков «есть» конечный результат безопасности. Проект стандарта PCI DSS v4.0 также включает заявления о намерениях, связывающие требования с результирующим состоянием безопасности. Заявления о намерениях напрямую поддерживают новый индивидуальный подход к валидации, четко определяя результат безопасности, которому должны соответствовать индивидуальные реализации стандарта. То есть поставлен акцент на результирующем состоянии ИБ, предоставляя большую гибкость в том, «как» организация достигает желаемого результата безопасности.

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

Такой подход поддерживает организации, использующие собственные методы обеспечения безопасности, которые могут отличаться от традиционных требований PCI DSS. Посредством индивидуального подхода к проверке организации могут показать, как используемая ими конкретная реализация соответствует намерению и устраняет риск, предоставляя альтернативный способ удовлетворения заявленных требований. Предлагая два подхода к проверке PCI DSS (классическое соответствие с компенсирующими опциями или индивидуальные подходы реализации целей ИБ), организации могут определить, какой вариант лучше всего им подходит для реализации безопасности для каждого требования PCI DSS.

Набор стандартов с 2012 года является обязательным для всех организаций, где присутствуют хранение, обработка или передача хотя бы одного номера карты какой-либо из пяти международных платежных систем-участниц Совета PCI SSC («МИР», Visa, MasterCard, American Express, JCB и Discover) в рамках какого-либо бизнес-процесса организации, с ежегодным контролем поддержания соответствия путем внутреннего или внешнего аудита.

Изменения сопутствующих стандартов

Вместе с основным стандартом PCI DSS обновлению подвергаются и другие не менее важные документы:

  • PIN v3.1 Standard. Основные изменения связаны с использованием ключей RSA для передачи PINили других ключей – они должны иметь такую же или большую силу, чем ключи, которые они шифруют.

  • Secure Software Standard: Terminal Software Module. Проект модуля требований безопасности для платежного программного обеспечения, предназначенного для развертывания на специализированных терминалах с усиленной защитой. Добавление нового модуля – еще один пример модульной архитектуры требования стандарта Secure Software Standard.

  • Software-based PIN Entry on COTS Standard v1.1. Пересмотр касается считывателей магнитных полос – Magnetic Stripe Readers (MSR).

  • PCI PTS Point of Interaction (POI) v6 Standard. Под изменения попали 4 модуля: физическая и логическая защита, интеграция POS-терминалов, интерфейсы и коммуникации, безопасность жизненного цикла.

  • PCI Contactless Payments on COTS (CPoC) Standard – это новый стандарт, касающийся бесконтактных платежей на готовых коммерческих устройствах (COTS). В связи с ростом числа продавцов, использующих смартфоны и другие коммерческие стандартные мобильные устройства (COTS) с механизмами бесконтактных платежей, PCI SSC расширяет поддержку новых стандартов приема мобильных платежей для обеспечения защиты данных и упреждающего управления угрозами. Стандарт CPoC включает конкретные критерии для поставщиков решений по защите платежных данных и вводит требования к испытаниям для лабораторий, признанных PCI, по оценке решений для проверки и включения в список на веб-сайте PCI SSC (через программу поддержки программу CPoC).

  • P2PE Standard v3.0 – стандарт включает набор требований безопасности для проверки приложений и компонентов защиты данных платежных карт с помощью шифрования, начиная с места фиксирования данных в платежном терминале и заканчивая расшифровыванием данных в безопасной среде. Изменения стандарта сосредоточены на его модернизации и упрощении, добавлении гибкости в требования.

PCI DSS for Large Organizations

В этом году организация PCI SSC, а точнее группа Special Interest Group (SIG), выпустила дополнение к стандарту – PCI DSS for Large Organizations. Документ содержит примеры организации ролей и распределения ответственности, процедурные рекомендации, рекомендации по взаимодействию с региональными органами аттестации и другую информацию, полезную крупному масштабированному бизнесу. Ниже приводится перечень разделов этого документа:

  • Роли, обязанности и владение функциями PCI DSS.

  • Поддержание соответствия.

  • Слияния и поглощения.

  • Управление эквайерами и платежными каналами.

  • Образование и осведомленность.

  • Управление системами для поддержания соответствия PCI DSS.

  • Множественные аудиты и оценки.

  • Законы, постановления и стандарты.

Критериями принадлежности к крупному бизнесу являются:

  • количество физических местоположений, каналов оплаты, точек взаимодействия, сотрудников и устройств в организации;

  • общее количество континентов, стран, городов и регионов, в которых организация ведет бизнес;

  • количество и сложность онлайн- или интернет-услуг;

  • большой объем или большая сумма транзакций по платежным картам.

Каждую секцию можно рассматривать независимо. Документ является дополнением к стандарту PCI DSS независимо от его версии (и к версии 3.2.1, и к будущим версиям до момента обновления документа) и включает не технологические, а организационные рекомендации по реализации его требований. Использовать документ могут также организации меньшего масштаба (независимо от выполнения критериев принадлежности к крупному бизнесу).

Выводы

После выхода стандарта у организаций будет достаточно времени для приведения своих процессов в соответствие новым требованиям. Кроме того, часть требований готовится под грифом «future-dated», что дает дополнительный запас времени на их реализацию (нижний указатель времени – до 2024 года).

На текущий момент представлен следующий расширенный план-график внедрения PCI DSS v4.0:

PCI.jpg

Пытаться угадать новые требования и выполнить их заранее – не самый лучший вариант, так как это может привести к необоснованным затратам и смещению фокуса от текущих потребностей обеспечения ИБ. Лучшее, что можно сделать для подготовки, – это обеспечить соответствие имеющейся системы защиты требованиям текущей версии стандарта PCI DSS v3.2, а также заполнить пробелы в защите, исходя из актуальной аналитики рисков для обрабатываемых в организации платежных данных.

Другие новости

Присоединиться к #AngaraTeam!