Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

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

(Нет голосов)

17.12.2010 Количество просмотров 920 просмотров

Сергей Шустиков, руководитель направления менеджмента  Digital Security, CISA, PCI QSA


Настоящая статья посвящена описанию изменений, добавленных в новую версию стандарта безопасности данных индустрии платежных карт PCI DSS 2.0, опубликованную Советом PCI SSC 28 октября 2010 года.


Cergei Shustikov

Жизненный цикл стандарта PCI DSS

С момента появления стандарта PCI DSS было очевидно, что речь идет не о неком непоколебимом монументе, призванном в неизменном виде пройти через века. Напротив, его авторы предусмотрели процедуру регулярного пересмотра и обновления требований стандарта с учетом обратной связи, полученной от участников индустрии платежных карт. До октября 2010 года стандарт PCI DSS проходил двухлетний цикл обновления, но начиная с версии 2.0 жизненный цикл каждой версии стандарта увеличивается на год и, по информации, опубликованной Советом PCI SSC, теперь станет трехлетним.

В ходе этого цикла Совет PCI SSC собирает предложения и пожелания от всех заинтересованных сторон, в том числе, проводя ежегодные встречи представителей сообщества участников индустрии платежных карт. Затем наступает этап анализа собранной информации и подготовки изменений документа, оканчивающийся публикацией новой версии стандарта.

PCI DSS, версия 2.0

Пройдя двухлетний цикл развития, 28 октября 2010 года увидела свет новая версия стандарта PCI DSS, а именно – версия 2.0. Внесенные в регулирующий отрасль документ изменения радикальными назвать сложно, в основном они носят характер уточнений и разъяснений. Кроме того, некоторые проверочные процедуры были по-новому сгруппированы с целью упрощения их восприятия и выполнения при прохождении аудита. Итак, рассмотрим подробно изменения, коснувшиеся требований стандарта PCI DSS.

Требование 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 отмечены как применимые исключительно для web-приложений.

Требование 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 приведено в соответствие своей проверочной процедуре и теперь разрешает прямой доступ к данным или выполнение прямых SQL-запросов в базу данных только администраторам баз данных.

Требование 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, регламентирующая необходимость изучения записей об инциденте с целью проверки того, был ли должным образом выполнен план реагирования на инцидент.

Заключение

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

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

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


Сергей Шустиков – руководитель направления менеджмента информационной безопасности компании Digital Security, CISA, PCI QSA.

Специализируется на системах менеджмента безопасности. Область профессиональных интересов охватывает разработку систем менеджмента информационной безопасности в соответствии с международными стандартами и проведение аудитов на соответствие требованиям международных и национальных стандартов индустрии защиты информации.

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

Полный текст статьи читайте в журнале "ПЛАС" 11 (163) ’2010 сс. 21 - 23


Комментарии (0):

Добавлять комментарии могут только зарегистрированные Пользователи


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

а вы знаете, что...

…первая система бесконтактной оплаты в мире была внедрена в США в 1997 г., она называлась Speedpass, использовалась на АЗС, а форм-фактором платежного инструмента был RFID-брелок для ключей автомобиля?