Отличия требований PCI DSS версии 4.0 от версии 3.2.1

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

1.1.1. Все изменения в конфигурациях межсетевых экранов (МЭ) и маршрутизаторов должны проходить по процедуре управления изменениями.

1.2.2.Все изменения в конфигурациях средств контроля сетевой безопасности (Network Security Controls – NSC) должны проходить по процедуре управления изменениями.

Новое понятие NSC включает в себя не только МЭ и маршрутизаторы, но и любые другие средства сетевой безопасности, которые управляют сетевым трафиком на основе определенных политик или правил.

1.1.7. Правила МЭ должны пересматриваться не реже, чем раз в полгода.

1.2.7. Конфигурации NSC должны пересматриваться не реже, чем раз в полгода.

Теперь пересмотру подлежат не только правила МЭ, но и конфигурации NSC.

1.4. На устройствах с доступом в Интернет и область применимости PCI DSS должен быть настроен персональный МЭ или аналогичное ПО. Такое ПО должно быть всегда запущено и не должно позволять вносить изменения пользователям в настройки.

1.5.1. На устройствах с доступом к недоверенным сетям и области применимости PCI DSS необходимо настроить средства контроля безопасности для защиты от угроз. Такие средства должны быть всегда запущены и не должны позволять вносить пользователям не согласованные с руководством изменения.

На персональных устройствах должны быть установлены средства контроля безопасности для защиты от угроз, направленных на внутреннюю сеть.

2.2. Необходимо разработать стандарты конфигурации (СК) для всех компонентов информационной инфраструктуры и убедиться, что данные СК учитывают меры противодействия всем известным уязвимостям и соответствуют принятым в отрасли стандартам.

2.2.1. Необходимо:
- разработать, внедрить и поддерживать в актуальном состоянии СК для всех компонентов информационной инфраструктуры;
- учитывать меры противодействия всем известным уязвимостям;
- обновлять СК в случае обнаружения новых уязвимостей;
- применять СК при настройке новых компонентов.

Теперь в стандарте явно указано, что СК необходимо обновлять, в случае обнаружения новых уязвимостей в компоненте информационной инфраструктуры и что СК необходимо применять в отношении новых компонентов информационной инфраструктуры.

2.2.1. На сервере должна быть реализована только одна основная функция, например, веб-сервер, сервер баз данных и DNS должны быть реализованы на отдельных серверах.

2.2.3. Основные функции, требующие разных уровней безопасности, должны управляться одним из следующих образов:
- одна функция – один компонент;
- функции разного уровня на одном сервере изолированы друг от друга;
- функции разного уровня на одном сервере защищены по высшему уровню из требуемых.

Добавлена гибкость при использовании функции, требующих разных уровней
безопасности, на одном сервере.

3.3. Максимальное количество цифр PAN при отображении: первые 6 и последние 4 цифры.

3.4.1. Максимальное количество цифр PAN при отображении: BIN и последние 4 цифры.

Разрешено отображать большее количество цифр PAN в случае, если BIN больше 6 цифр.

5.2. Антивирус должен периодически сканировать системы на наличие ВПО.

5.3.2. Антивирус должен производить периодические сканирования на наличие ВПО и сканирования в режиме реального времени или постоянный поведенческий анализ систем и процессов.

Добавлена альтернатива периодическим сканированиям на наличие ВПО.

6.4.3. Производственные данные (реальные PAN) не могут использоваться для тестирования или разработки.

6.5.5. Производственные PAN не могут использоваться в предпроизводственных средах за исключением случаев, когда данные среды находятся в CDE и защищены соответствующим образом.

В случае, если предпроизводственные среды находятся в CDE и защищены соответствующим образом, в них можно использовать производственные данные.

8.7. Пользовательский доступ к БД с ДДК должен быть разрешен только через приложения и программные методы в соответствии с принципом минимальных привилегий или через прямой доступ для администраторов БД. Учетные записи приложений могут использоваться только самими приложениями.

7.2.6. Пользовательский доступ к репозиториям с ДДК должен быть разрешен только через приложения и программные методы в соответствии с принципом минимальных привилегий или через прямой доступ для администраторов БД.

Требование расширено и теперь применяется ко всем местам хранения ДДК, а не только к БД.

8.5. Запрещено использовать неперсонализированные учётные записи, пароли и другие аутентификационные данные. Неперсонализированные учётные записи не должны использоваться для администрирования компонентов информационной инфраструктуры, а должны быть заблокированы или удалены.

8.2.2. Неперсонализированные учётные записи или другие аутентификационные данные могут использоваться только в качестве обоснованного исключения после согласования руководством периода времени, необходимого на устранение неполадок.
За всеми действиями, выполненными из-под таких учётных записей, должен вестись мониторинг.

Разрешено использовать неперсонализированные учётные записи в случае критических ситуаций.

8.1.6. Учетная запись должна блокироваться после 6 неуспешных попыток входа.

8.3.4. Учетная запись должна блокироваться после 10 неуспешных попыток входа.

Допустимое количество неуспешных попыток входа увеличено.

8.2.4. Необходимо менять пароли (парольные фразы), как минимум, раз в 90 дней.

8.3.9. Если пароли (парольные фразы) используются в качестве единственного фактора аутентификации для пользовательского доступа, то их необходимо менять, как минимум, раз в 90 дней или вести динамический анализ безопасности учетных записей.

В качестве альтернативы ежеквартальной смене пароля можно использовать решения класса UEBA (User and Entity Behavior Analytics).