Обзор изменений в стандарте PCI DSS версии 2.0 по сравнению с версией 1.2.1

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

С одной стороны нет никаких запретов на протяжении 2011 года проходить аудит на соответствие стандарту PCI DSS по версии 1.2.1. С другой стороны с 2012 года, единственной версией по которой можно будет это сделать станет 2.0. Так как же поступить?

Рассмотрим отличия которые появились в версии 2.0

Требование 1

Во введении к требованию отмечено, что функциональность межсетевого экранирования может быть реализована не только традиционным межсетевым экраном.
В требовании 1.3.1 уточнено, что входящий трафик, проходящий через DMZ, должен быть ограничен протоколами, необходимыми для предоставления авторизованных сервисов, перечень которых составлен при выполнении требования 1.2.1.
Требование 1.3.3 в новой версии запрещает прямые соединения между сетью Интернет и средой ДДК, в предыдущей версии были запрещены прямые маршруты.
Требование 1.3.5 в новой версии требует, чтобы весь исходящий из среды ДДК трафик в сеть Интернет был явным образом авторизован. Ранее данное требование требовало ограничить исходящие соединения из среды ДДК только адресами, расположенными в DMZ, что являлось дублированием требования 1.3.3, которое запрещает прямые соединения между сетью Интернет и средой ДДК.
В требовании 1.3.7 уточнено положение о том, что компоненты, хранящие ДДК, должны располагаться в сегменте сети, изолированном как от DMZ, так и от иных недоверенных сетей. Ранее содержалось только требование изоляции от DMZ, хотя было очевидно, что от всех иных сетей защита тоже должна быть обеспечена.
В требовании 1.3.8 расширены правила сокрытия адресации внутренних компонентов среды ДДК и информации о маршрутах, введено правило необходимости авторизации при всех эпизодах раскрытия такой информации. Явным образом перечислены рекомендуемые методы сокрытия внутренней адресации: использование технологии NAT и прокси-серверов, отключение объявления маршрутов (route advertisements) для частных сетей, использование приватных адресных пространств (RFC 1918) во внутренних сетях.
Проверочная процедура 1.4.b, регламентирующая проверку невозможности отключения персонального межсетевого экрана пользователем, расширена до компьютеров, принадлежащих сотрудникам, если таковые используются для доступа к сети организации.

Требование 2

Из требования 2.1.1 исключено упоминание включения стойких криптографических алгоритмов для беспроводных сетей, так как это дублирование требования 4.1.1.
Проверочная процедура 6.2.c, регламентирующая проверку обновления стандартов конфигурации в случае обнаружения уязвимости, переехала в 2.2.b.
В требовании 2.2.1 учтены нюансы виртуализации, теперь правило «одна функция — один сервер» звучит как «одна функция — один реальный или виртуальный сервер».
Требование 2.2.2 теперь прямо говорит о том, что должны быть включены только необходимые и защищенные протоколы и сервисы, ранее оно требовало отключение ненужных и небезопасных.
В требование 2.3 внесено уточнение, что канал неконсольного административного доступа должен быть зашифрован с применением стойких криптографических алгоритмов.

Требование 3

Реструктурировано требование 3.1, добавлена новая проверочная процедура 3.1.1.e, требующая проверки того, что для хранимых ДДК не истекли максимальные сроки хранения.
В требование 3.2 внесено уточнение, что эмитенты и компании, обеспечивающие эмиссионные сервисы, могут иметь обоснованную необходимость хранения критичных аутентификационных данных. Такая необходимость должна иметь обоснование с точки зрения бизнеса, а хранимые данные должны быть защищены.
Для проверочных процедур требований 3.2.1 — 3.2.3 уточнено, что проверка наличия сохраняемых критичных аутентификационных данных не должна ограничиваться перечнем типов мест хранения, перечисленных в тексте процедур, а следует изучить все потенциальные места появления таких данных.
В требование 3.4 внесены уточнения относительно хеширования номеров карт, а именно: хеширован должен быть весь номер карты, хеширование только средней части номера карты не допускается. При наличии в информационной инфраструктуре одновременно маскированного и хешированного номера карты, следует принять меры, исключающие возможность нахождения злоумышленником корреляции между маскированным и хешированным значением одного и того же номера карты, так как при этом номер становится достаточно легко восстановим.
В требование 3.5 внесено уточнение, что ключи шифрования ключей должны быть не менее стойкими, чем ключи шифрования данных.
Добавлена проверочная процедура 3.5.2.b, требующая проверки того, что ключи хранятся в минимально возможных местах и формах представления.
Уточнена проверочная процедура 3.6.b, требующая проверки того, что поставщики услуг, предоставляющие клиентам ключи шифрования передаваемых или хранимых ДДК, должны также предоставлять клиентам руководство по безопасному управлению ключами, соответствующее требованиям 3.6.1 — 3.6.8.
В требованиях 3.6.4 и 3.6.5 расширен перечень ситуаций, требующих смены криптографического ключа, ключ должен быть изменен в конце установленного криптопериода, который может определяться как временным сроком, так и количеством данных, зашифрованных одним ключом. Для определения криптопериода рекомендуется использовать раздел 5.3 документа NIST Special Publication 800-57. Также требуется смена ключа в ситуации, когда неприкосновенность ключа поставлена под сомнение, например, при увольнении сотрудника, имевшего доступ к ключу, либо при наличии иных подозрений компрометации ключа. Если при изменении ключа старый ключ сохраняется с целью обеспечения доступа к зашифрованных архивным данным, то такой ключ может быть использован только для операций расшифрования и верификации архивных данных и не может быть использован для операций шифрования.
В требовании 3.6.6 уточнено, что раздельное знание и двойной контроль необходимы для ручных операций по управлению криптографическими ключами в открытом виде. Примерами таких операций служат генерация ключа, его передача, загрузка в устройство, хранение и уничтожение.
В требование 3.6.8 внесено уточнение, гласящее о том, что формальное принятие обязанностей по управлению ключами ответственными лицами может иметь как рукописную, так и электронную форму. При этом от представителей международных платежных систем в Совете PCI SSC в рамках мероприятия PCI SSC European Community Meeting 2010 мною был получен комментарий о том, что вывод о степени надежности электронной формы документа, достаточности механизмов обеспечения её безопасности, а значит и о допустимости её применения в каждом конкретном случае делается QSA-аудитором.

Требование 4

Проверочные процедуры требования 4.1 были перегруппированы и добавлена необходимость проверки того, что используемые протоколы передачи данных не поддерживают свои небезопасные версии и конфигурации (проверочная процедура 4.1.с).
В требование 4.1.1 включен запрет на использование протокола WEP для беспроводных сетей, регламентировано использование протокола IEEE 802.11i (WPA).
В требование 4.2 внесено уточнение, что при передаче через пользовательские системы передачи сообщений (электронная почта, ICQ и т. д.) номер карты должен быть приведен в нечитаемый вид, шифрование является только одним из способов приведения к такому виду. Ранее в описанном случае требование 4.2 подразумевало только использование шифрования.

Требование 5

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

Требование 6

В требование 6.2 внесено положение о том, что вновь обнаруженные уязвимости должны быть ранжированы по уровню связанного с ними риска. До 30 июня 2012 года ранжирование уязвимостей по уровню риска носит рекомендательный характер, а после этой даты становится обязательным требованием. Для определения уровня риска следует руководствоваться принятыми методами индустрии безопасности, например, относить к уязвимостям высокого риска те из них, которые имеют уровень 4.0 и выше по шкале CVSS. Также можно пользоваться классификацией обновлений безопасности, выпускаемых производителем, и относить к уязвимостям высокого риска те из них, для закрытия которых производитель выпустил обновление категории «критическое». Кроме того, для оценки уровня риска уязвимости можно применять подход, основанный на критичности компонента информационной инфраструктуры, в котором она была обнаружена. Соответствующие изменения были внесены в требования 6.5.6 и 11.2.
Требование 6.3 было реструктурировано, требования 6.3.1.x были объединены с 6.5, требования 6.3.2 — 6.3.5 были перенесены в 6.4.1 — 6.4.4.
В требовании 6.3.2 (прежнее 6.3.7), объединены две проверочные процедуры в одну 6.3.2.a, относящуюся как к внутренним так и к общедоступным приложениям (ранее они были разделены по этому признаку).
Требование 6.4 было реструктурировано, оно включило в себя прежние требования 6.3.2 — 6.3.4, а кроме того прежние требования 6.4.1 — 6.4.4 были перенумерованы в 6.4.5.1 — 6.4.5.4.
В требование 6.4.5.3 внесено уточнение, гласящее, что функциональное тестирование при внесении изменения должно быть проведено с целью определения влияния на безопасность системы. Ранее требование регламентировано лишь проверку операционной функциональности. Сюда же добавлена дополнительная проверочная процедура, регламентирующая проверку процедуры тестирования обновлений программного кода (ранее была в прежнем требовании 6.3.1).
В требовании 6.5 расширен перечень источников информации по безопасному программированию (OWASP Guide, SANS CWE Top 25, CERT Secure Coding), обновлен перечень уязвимостей 6.5.x в соответствии с вышеупомянутыми источниками и с учетом его объединения с прежним требованием 6.3.1. Требование 6.5.6 изложено с учетом требования 6.2, а требования 6.5.7 — 6.5.9 отмечены как применимые исключительно для веб-приложений.

Требование 7

В требование 7.1.3 внесено уточнение, гласящее о том, что формальное согласование заявки на доступ может иметь как рукописную, так и электронную форму. При этом от представителей международных платежных систем в Совете PCI SSC в рамках мероприятия PCI SSC European Community Meeting 2010 мною был получен комментарий о том, что вывод о степени надежности электронной формы документа, достаточности механизмов обеспечения её безопасности, а значит и о допустимости её применения в каждом конкретном случае делается QSA-аудитором.

Требование 8

Во введении к требованию отмечено, что требования 8.1, 8.2 и 8.5.8 — 8.5.15 не применимы к учетным записям пользователей кассового (POS) приложения, которые в каждый момент времени имеют доступ только к данным одной карты, с целью осуществления платежной транзакции, например, учетным записям кассиров магазина. При этом отмечено, что данные требования применимы ко всем учетным записям пользователей кассового (POS) приложения с административными полномочиями, а также имеющим доступ к хранимым ДДК.
В требовании 8.2 перечислены аутентификационные факторы.
В требовании 8.3 уточнено, что повторное использование одного и того же фактора, например двух различных паролей, не является двухфакторной аутентификацией.
Требование 8.5.6 приведено в соответствие своей проверочной процедуре и теперь регламентирует необходимость мониторинга действий, совершаемых от имени учетных записей, используемых поставщиком программного обеспечения для удаленной поддержки.
В требования 8.5.9 — 8.5.13 внесена поправка, гласящая, что касаемо поставщиков услуг, данные требования не применимы к учетным записям их клиентов.
Требование 8.5.16 приведено в соответствие своей проверочной процедуре и теперь разрешает прямой доступ к данным или осуществление запросов в базу данных только администраторам баз данных.

Требование 9

Во введении к требованию определены термины «персонал», «посетитель» и «носитель данных».
В требовании 9.1.1 уточнена возможность применения либо камер видеонаблюдения, либо иных механизмов контроля физического доступа.
Требование 9.6 в части, касающейся физического доступа к сетевому оборудованию и телекоммуникационным линиям, перемещено в 9.1.3.
Проверочная процедура требования 9.3.1 изменена: «наблюдать за использованием посетительских пропусков» (ранее было: «попробовать получить доступ к дата-центру с использованием посетительского пропуска»).
Требование 9.7.1 уточнено: «классифицировать носители данных так, чтобы уровень критичности хранимых на них данных мог быть определен», ранее было: «как содержащих конфиденциальную информацию».

Требование 10

Требование 10.4 разделено на три требования 10.4.1 — 10.4.3.

Требование 11

В требование 11.1 внесены уточнения относительно методов, применяемых для поиска неавторизованных беспроводных устройств.
Требование 11.2 разделено на три требования 11.2.1 — 11.2.3. В описание процесса сканирования внесены уточнения с учетом требования 6.2.
В требование 11.4 внесено уточнение относительно мест расположения систем IDS/IPS, а именно: системы IDS/IPS должны контролировать периметр среды ДДК и критичные точки внутри среды ДДК.

Требование 12

Во введении к требованию указано, что политика информационной безопасности должна быть применима ко всему персоналу организации.
К требованию 12.1.2 добавлена новая проверочная процедура 12.1.2.b, регламентирующая необходимость проверки того, что оценка рисков выполнятся не реже одного раза в год.
В требование 12.3.4 внесено уточнение, что маркировка носителя данных должна нести информацию, которую можно связать с владельцем носителя (ранее требовалось указание владельца напрямую).
В требование 12.3.10 внесена поправка, разрешающая копирование, перемещение и хранение ДДК при удаленной работе, но только при выполнении соответствующих процедур авторизации доступа и обеспечении передаваемых и хранимых ДДК согласно всем требованиям стандарта PCI DSS. Добавлена соответствующая проверочная процедура — 12.3.10.b.
В требование 12.8.4 внесено уточнение, регламентирующее необходимость мониторинга статуса соответствия поставщиков услуг стандарту PCI DSS не реже одного раза в год.
В требование 12.9 добавлена новая проверочная процедура 12.9.1.b, регламентирующая необходимость изучения записей об инциденте с целью проверки того, был ли должным образом выполнен план реагирования на инцидент.

Выводы.

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

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

Тем кто проходит аудит в первый раз, не вижу смысла проходит по стандарту 1.2.1 так как он устаревает (устарел). У кто будет подтверждать - есть выбор. Но мое мнение, что нет смысла затягивать, так как все равно проходить аудит придется. А наличие сертификата о прохождении по 2.0 - может дать какое никакое, а преимущество. В первую очередь маркетинговое, ну само собой разумеется в вопросах информационной безопасности. Ведь любая проверка или сертификация - это стимул собраться, привести себя в порядок и стать чуточку лучше.