31 марта 2022 года был опубликован PCI DSS v. 4.0. В новой версии стандарта произошли изменения как в самих требованиях, так и в подходах к их выполнению. Про изменение подходов к выполнению требований мы рассказывали в предыдущей статье. В данной статье мы подробнее рассмотрим изменения в требованиях стандарта.

Новые требования PCI DSS версии 4.0, которые вступили в силу уже сейчас

• Компании необходимо распределить ответственность и обязанности за выполнение требований каждого раздела стандарта PCI DSS версии 4.0 (требования {1-12}.1.2).
• Если пароль используется как единственный фактор аутентификации для доступа клиентов к данным платёжных карт, то необходимо предоставить клиентам инструкцию по управлению паролями, где должно быть сказано:
  - о периодической смене пароля;
  - об условиях, при которых пароль требуется сменить (требование 8.3.10).
• Как минимум, раз в год необходимо анализировать места хранения носителей информации с резервными копиями ДДК (требование 9.4.1.2).
• Как минимум, раз в год необходимо проводить таргетированный анализ рисков в рамках требований, к которым применяется Индивидуальный подход (требование 12.3.2).
• Для области применимости PCI DSS необходимо составить и поддерживать в актуальном состоянии перечень компонентов информационной инфраструктуры с описанием их функций. (требование 12.5.1).
• Как минимум, раз в год или при изменениях в информационной инфраструктуре необходимо пересматривать область применимости PCI DSS и при необходимости актуализировать:
  - потоки ДПК;
  - места хранения ДПК;
  - перечень компонентов из области применимости PCI DSS;
  - механизмы и методы сегментации сети;
  - каналы взаимодействия с третьими сторонами (требование 12.5.2).
• Поставщикам услуг необходимо предоставлять по запросу своим клиентам информацию о статусе соответствия PCI DSS, а также информацию о том, за какие требования несет ответственность поставщик услуг, а за какие – клиенты (требование 12.9.2).

Новые требования PCI DSS версии 4.0, которые вступят в силу с 31 марта 2025 года

• В перечне мест хранения данных держателей карт должны быть учтены все критичные аутентификационные данные (PIN, TRACK, CVC2/CVV2 и т.д.), хранимые до авторизации транзакции (требование 3.2.1).
• Все критичные аутентификационные данные, хранимые до авторизации транзакции или хранимые эмитентами, должны быть зашифрованы с использованием стойкой криптографии (требования 3.3.2, 3.3.3).
• Должны быть запрещены копирование, вставка и сохранение данных платежных карт при удаленном доступе для всех работников за исключением тех, кому такой доступ согласован и необходим для выполнения должностных обязанностей (требование 3.4.2).
• Хешировать PAN допустимо только с применением хеш-функций с секретом. При этом процедуры управления секретами должны соответствовать требованиям PCI DSS по управлению криптографическими ключами 3.6 и 3.7 (требование 3.5.1.1).
• Если используется шифрование на уровне диска или раздела, то такое шифрование допустимо использовать только на съёмных носителях. В остальных случаях требуется применять дополнительные способы приведения PAN в нечитаемый вид в соответствии с требованием 3.5.1 (требование 3.5.1.2).
• Запрещено использовать одинаковые криптографические ключи для шифрования ДПК в тестовых и производственных средах (требование 3.6.1.1).
• Компании необходимо на периодической основе проверять, что срок действия сертификатов, используемых для защиты PAN при передаче, не истек. При этом можно использовать самоподписанные сертификаты, если используется внутренний СА и DN, а также "issued to" и "issued by" не совпадают (требование 4.2.1).
• Компании необходимо вести перечень доверенных ключей и сертификатов, используемых для защиты PAN при передаче по общедоступным сетям (требование 4.2.1.1).
• Компании необходимо вести перечень используемого ПО, а также компонентов ПО, которые используются в компании (требование 6.3.2).
• Компании необходимо вести перечень используемых криптографических протоколов и, как минимум, раз в год должен производиться их пересмотр (требование 12.3.3).
• Антивирус должен автоматически проверять все съёмные носители на наличие вредоносного ПО в момент подключения или монтирования носителя или производить постоянный поведенческий анализ систем и процессов, когда съёмные носители вставляются, подключаются или монтируются (требование 5.3.3).
• Компании необходимо внедрить процессы и механизмы для защиты пользователей от фишинговых атак (требование 5.4.1).
• Компании необходимо внедрить Web Application Firewall (WAF) как обязательное средство защиты публично доступных web-приложений (требование 6.4.2).
• Все скрипты, загружаемые и выполняемые на платежных страницах в браузере клиента, должны управляться следующим образом:
  - должна быть авторизация скрипта;
  - должна быть гарантирована целостность каждого скрипта;
  - должна проводиться инвентаризация всех скриптов с явным обоснованием их использования (требование 6.4.3).
• Все системные и пользовательские учетные записи, включая учетные записи третьих лиц и вендоров, должны пересматриваться следующим образом: - не реже, чем раз в полгода;
  - привилегии должны соответствовать должностным обязанностям работника или третьей стороны;
  - при выявлении избыточного доступа, он незамедлительно отзывается;
  - руководство осведомлено и подтверждает, что доступ был согласован (требования 7.2.4, 7.2.5.1).
• Для системных учётных записей и учётных записей приложений: - права доступа должны быть предоставлены по принципу минимально необходимых привилегий;
  - доступ должен быть строго ограничен;
  - периодичность смены паролей должна быть определена в рамках таргетированного анализа рисков (требование 7.2.5).
• Длина используемых для аутентификации паролей должна быть не менее 12 символов или максимальное количество символов, поддерживаемое системой, но не менее 8 символов (требование 8.3.6).
• Пароли, используемые как единственный фактор аутентификации клиентов поставщика услуг, должны меняться раз в 90 дней. Либо для таких учётных записей необходимо внедрить динамический анализ их безопасности (требование 8.3.10.1).
• Многофакторная аутентификация должна быть внедрена: - для всех доступов к области применимости PCI DSS (требование 8.4.2);
  - с защитой от атак методом воспроизведения (replay attacks);
  - с отсутствием возможности обхода второго фактора, включая администраторов, за исключением специально задокументированных случаев, одобренных руководством на короткий промежуток времени (требование 8.5.1).
• Если системная учётная запись или учётная запись приложения может быть использована администратором для входа, то: - вход должен быть доступен только в исключительном случае;
  - длительность использования учётной записи должна быть ограничено временем, необходимым на обработку исключительного случая;
  - необходимо задокументировать причину и обстоятельства использования такой учётной записи;
  - использование учётной записи должно быть согласовано руководством;
  - личность работника должна быть подтверждена до использования учётной записи;
  - каждое выполненное действие должно быть сопоставлено с конкретным работником (требование 8.6.1).
• Запрещено хранить пароли, используемые приложениями и системными учётными записями, в коде и в конфигурационных файлах в открытом виде (требование 8.6.2).
• Для анализа событий информационной безопасности должна быть внедрена SIEM (требование 10.4.1.1).
• Все выявленные некритичные уязвимости должны управляться следующим образом:
  - в соответствии с таргетированным анализом рисков согласно требованию 12.3.1;
  - после устранения требуется проведение повторного сканирования уязвимостей (требование 11.3.1.1).
• Внутренний сканер уязвимостей должен иметь возможность авторизоваться в сканируемой системе (требование 11.3.1.2).
• Мульти-тенант сервис-провайдер должен способствовать проведению внешнего тестирования на проникновение своих клиентов:
  - либо провести такое тестирование на проникновение самому согласно требованиям 11.4.3 и 11.4.4,
  - либо предоставить каждому клиенту доступ к инфраструктуре для проведения их собственного тестирования на проникновение (требование 11.4.7).
• Используемые системы IDS/IPS должны быть способны предотвращать использование скрытых каналов передачи вредоносного ПО или обнаруживать и генерировать сигналы тревоги при обнаружении таких каналов (требование 11.5.1.1).
• Необходимо внедрить систему обнаружения изменений на платёжной странице с полями ввода ДПК и в HTTP-заголовках (требование 11.6.1).
• Компании необходимо проводить таргетированный анализ рисков для определения периодичности процедур (требование 12.3.1), в том числе:
  - периодичность анализа событий информационной безопасности для систем, не указанных в требовании 10.4.1 (требование 10.4.2.1),
  - периодичность и типы проверок POI-устройств (требование 9.5.1.2.1),
  - периодичность подтверждения неактуальности антивируса для систем, неподверженных воздействию вредоносного ПО (требование 5.2.3.1),
  - периодичность сканирований на наличие вредоносного ПО (требование 5.3.2.1),
  - периодичность пересмотра прав доступа системных учётных записей и учётных записей приложений (требование 7.2.5.1),
  - периодичность смены паролей системных учётных записей и учётных записей приложений (требование 8.6.3),
  - периодичность повышения осведомлённости работников в области реагирования на инциденты ИБ (требование 12.10.4.1).
• Как минимум, раз в год необходимо проводить инвентаризацию используемого физического оборудования и программных технологий в области применимости PCI DSS. В рамках такой инвентаризации необходимо:
  - анализировать технологии, которые все ещё получают обновления от вендоров;
  - анализировать публикуемые вендорами анонсы "end-of-life";
  - планировать и согласовывать с руководством переход со старых технологий, в том числе технологий, достигших этапа "end-of-life" (требование 12.3.4).
• Как минимум, раз в полгода поставщики услуг должны подтверждать и актуализировать документацию, описывающую область применимости PCI DSS.
• Как минимум, раз в год необходимо пересматривать и в случае необходимости актуализировать программу повышения осведомлённости работников (требование 12.6.2).
• Программа повышения осведомленности работников должна включать в себя:
  - материалы по противодействию фишинговым атакам и социальной инженерии;
  - обучение по разрешенным пользовательским технологиям в области применимости PCI DSS (требование 12.6.3).
• Необходимо разработать планы реагирования на инциденты ИБ, как минимум, связанные:
  - с нарушением целостности платёжных страниц или HTTP-заголовков (требование 12.10.5);
  - с обнаружением PAN в нерегламентированных местах хранения (требование 12.10.7).
• Для поставщиков услуг и их клиентов права доступа должны быть настроены следующим образом:
  - поставщик услуг не имеет доступа к средам клиентов без авторизации;
  - ни один клиент не имеет доступа к среде поставщика без авторизации;
  - эффективность назначенных прав доступа должна подтверждаться не реже, чем раз в полгода по результатам тестирования на проникновение (требования А1.1.1, А1.1.4).
• Поставщики услуг и их клиенты должны внедрить следующие процессы:
  - оповещения от клиентов об инцидентах ИБ и уязвимостях;
  - реагирования поставщиком услуг на возникшие инциденты ИБ и уязвимости согласно требованию 6.3.1 (требование А1.2.3).

Изменения в требованиях PCI DSS версии 3.2.1

Источник: Deiteriy