Журнал ПЛАС » Архив » 2016 » ЖУРНАЛ ПЛАС № 6(229) » 728 просмотров

PCI DSS 3.2: что изменилось и к чему готовиться

PCI DSS 3.2: что изменилось и к чему готовиться

Петр Шаповалов,
инженер по защите информации, PCI QSA, компания Deiteriy

До 31 января 2018 года новые требования PCI DSS 3.2 являются рекомендациями, но после наступления этой даты станут обязательными для выполнения


28 апреля 2016 года на официальном сайте Совета PCI SSC был опубликован пресс-релиз о выходе новой версии стандарта безопасности данных индустрии платежных карт PCI DSS 3.2. Версия получилась внеплановая (обычно новые версии Совет публикует осенью), но при этом изменения в ней считаются минорными. Давайте разберемся, что поменялось в новом стандарте.

Помимо совсем мелких корректировок, которые были сделаны с целью исправления различных опечаток, ошибок форматирования, пунктуации и т. д., в новой версии стандарта появился ряд уточнений и дополнений, а также ряд новых требований. Эти требования пока еще являются рекомендательными, но с 1 февраля 2018 года станут обязательными для выполнения. К таким новинкам относятся следующие.

Применимо ко всем организациям:

• для всех изменений в информационной инфраструктуре необходимо дополнительно проверять, что все применимые требования стандарта PCI DSS выполнены для изменяемых компонентов. Иными словами, если вы внесли какое-либо изменение в информационную инфраструктуру, нужно убедиться, что соответствие стандарту не нарушилось (например, обновить схемы сети и потоков данных, провести сканирование на уязвимости и иные подобные мероприятия);
• для удаленного неконсольного административного доступа в область применимости стандарта PCI DSS нужно реализовать мультифакторную аутентификацию.
Применимо только к поставщикам услуг:
• в случае использования шифрования архитектуру системы шифрования нужно документировать. Алгоритмы, протоколы и процедуры управления ключами необходимо описать и поддерживать в актуальном состоянии;
• требуется контролировать работоспособность систем безопасности. В случае возникновения сбоев в работе таких систем следует выполнить процедуры реагирования и зарегистрировать факт сбоя;
• тестирование на проникновение в части сегментации сети необходимо проводить не реже одного раза в шесть месяцев, а также после внесения любых критичных изменений в информационную инфраструктуру;
• в организации должен быть внедрен высокоуровневый документ, в котором будет описана программа соответствия требованиям стандарта PCI DSS и назначен ответственный работник, который будет контролировать ее выполнение и держать в курсе руководство организации о статусе данной программы;
• не реже одного раза в квартал необходимо проверять, что работники организации корректно выполняют процедуры по ежедневному анализу журналов протоколирования событий, пересмотру правил межсетевого экранирования, применению стандартов конфигурации для новых систем, реагированию на сигналы систем безопасности, а также соблюдают процедуры управления изменениями.

Повторюсь, что до 31 января 2018 года данные требования являются рекомендациями, а уже после наступления этой даты станут обязательными для выполнения. Но поскольку процесс реализации новых требований может занять длительное время и потребовать привлечения дополнительных средств бюджета, участникам рынка рекомендуется начать его выполнение как можно раньше.


Реализация новых требований может занять длительное время, поэтому стоит начать их выполнение как можно раньше


Помимо новых требований, в текст стандарта внесены уточнения, включая следующие:

• если в области применимости стандарта PCI DSS используется PA-DSS сертифицированное приложение, но его поддержка производителем прекратилась (например, у ПО появился статус «End-of-life»), то это приложение уже не сможет обеспечивать необходимый уровень безопасности. Поэтому стандарт рекомендует отслеживать статус поддержки при выборе PA-DSS сертифицированных приложений;
• при определении границ области применимости стандарта PCI DSS следует учитывать системы, обеспечивающие непрерывность работы компонентов информационной инфраструктуры: системы резервного копирования и восстановления, отказоустойчивые системы;
• перед переводом в производную среду компонента информационной инфраструктуры необходимо изменять все стандартные настройки и отключать стандартные учетные записи. Согласно пояснению, это требование касается и платежных приложений;
• добавлено примечание в проверочную процедуру по поиску полного номера карты PAN в логах компонентов информационной инфраструктуры. Уточнение заключается в том, что логи необходимо анализировать и для платежных приложений в том числе;
• добавлено примечание к требованию 3.4.1 по шифрованию дисков: это требование применимо в дополнение ко всем другим требованиям по шифрованию и управлению ключами в области применимости стандарта;
• разработчики должны как минимум ежегодно обучаться методам безопасного программирования;
• добавлено примечание к требованию по системе контроля доступа. Стандарт допускает, что таких систем в организации может быть несколько;
• уточнено, что в качестве системы контроля доступа можно использовать либо систему видеонаблюдения, либо СКУД, либо обе технологии одновременно;
• если в версии 3.1 стандарта PCI DSS должен был контролироваться лишь удаленный доступ вендоров в информационную инфраструктуру, в версии 3.2 внесено уточнение о том, что необходимо обеспечить контроль удаленного доступа любой третьей стороны.

Новое Приложение А2 включило в себя отдельные требования для организаций, которые все еще используют протокол SSL и ранние версии протокола TLS. Это Приложение содержит требования по использованию POS-терминалов (необходимо иметь доказательство того, что POS-устройства не подвержены атакам на небезопасные версии протоколов), а также требование по наличию Плана перехода на безопасные версии протоколов.

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

Отмечу, что из текста PCI DSS полностью исчезли все примеры безопасных протоколов. Сделано это намеренно, чтобы не пришлось экстренно обновлять стандарт в случае, если рекомендуемый безопасный протокол станет уязвимым, как это было в случае SSL и ранних версий TLS.

Совет PCI SSC активно продвигает модель соответствия требованиям стандарта, которая носит название BAU (Business-asUsual). В текст самого стандарта, начиная еще с версии 3.0, был добавлен целый раздел «Best Practices for Implementing PCI DSS into Business-as-Usual Processes». Позднее Совет PCI SSC ввел термин Designated Entity. Банки-эквайеры и международные платежные системы (МПС) могут присваивать данный статус организациям с повышенным риском компрометации карточных данных. Для таких организаций существуют отдельные требования, направленные на поддержание BAU, – DESV (Designated Entities Supplemental Validation). Эти требования были отдельно опубликованы в июне 2015 года. Проверять выполнение этих требований может QSA-аудитор, сформировав по итогам проверки отдельный АОС и ROC. В версии 3.2 стандарта PCI DSS требования DESV полностью перетекли в новое Приложение А3 PCI DSS, а часть из них легла в основу новых требований самого PCI DSS.

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

Следует обратить внимание и на ранее не упомянутые нами следующие незначительные изменения и уточнения:

• требования 8 раздела стандарта PCI DSS 3.2 теперь не распространяются на учетные записи держателей карт;
• перечень поставщиков услуг должен включать в себя описание услуг, которые поставщик предоставляет сертифицируемой организации;
• результаты тестирований на проникновение должны проверяться квалифицированным работником организации или представителем третьей стороны. При этом не обязательно, чтобы третьей стороной выступал QSA или ASV;
• список файлов, целостность которых должна контролироваться, может быть расширен и на системы вне области применимости стандарта PCI DSS, если результат анализа рисков информационной безопасности того потребует;
• в требование 1.4 по персональным межсетевым экранам добавлена возможность использования эквивалентной технологии: «Install personal firewall software or equivalent functionality on any portable computing devices»;
• добавлены ссылки на рекомендации по генерации криптографических ключей (NIST Special Publication 800-133, ISO 11568-2, ISO 11568-4, EPC 342-08);
• добавлена ссылка на NIST SP 800-63 для случая, если нет возможности выполнить требования по длине и составу пароля/ парольной фразы.

Из мелких изменений есть ряд исправлений в терминологии: «passwords/phrases» заменено на «passwords/passphrases», двухфакторная аутентификация 2FA – на мультифакторную MFA.

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

Подробно с новой версией стандарта можно ознакомиться на сайте Совета PCI SSC по ссылке: www.pcisecuritystandards.org/document_library.

Подписывайтесь на наши группы, чтобы быть в курсе событий отрасли.

Читайте в этом номере:


Перейти к началу страницы

Подпишитесь на новости индустрии

Нажимая на кнопку "подписаться", вы соглашаетесь с


политикой обработки персональных данных