Чтение онлайн

• требование 9: физический доступ к данным держателей карт должен быть ограничен;

• регулярный мониторинг и тестирование сетей:

• требование 10: должен отслеживаться и контролироваться любой доступ к сетевым ресурсам и данным держателей карт;

• требование 11: должно выполняться регулярное тестирование систем и процессов обеспечения безопасности;

• поддержание политики информационной безопасности:

• требование 12: должна поддерживаться политика, регламентирующая деятельность всех сотрудников.

Каждое из 12 общих требований содержит ряд «подтребований» и процедур их проверки, которые, с одной стороны, обеспечивают (как минимум в теории) однообразие контроля требований аудиторам и, с другой стороны, часто детализируют само требование. Также для понимания сути требования и/или процедуры проверки бывает полезно учитывать, в какой группе находится данное требование. Описание требований приведено для версии стандарта PCI DSS 2.0.

Требование 1: установка и администрирование конфигурации межсетевых экранов для защиты данных держателей карт.

Данное обобщенное требование содержит 18 требований и 25 процедур оценки их соответствия, регламентирующих различные аспекты применения межсетевых экранов для защиты сегментов сети, обрабатывающих данные платежных карт, такие как:

• сегментация сети на различные зоны безопасности и размещение серверов в них;

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

• настройка конкретных правил фильтрации трафика;

• необходимость регламентирования процесса внесения изменений в конфигурации межсетевых экранов;

• настройка правил фильтрации трафика на мобильных компьютерах.

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

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

Требование 2: не должны использоваться системные пароли и другие параметры безопасности, установленные производителем по умолчанию.

Данное обобщенное требование содержит 23 требования и соответствующие им процедуры оценки, регламентирующие различные аспекты настройки серверов, сетевого оборудования, приложений и баз данных, в частности:

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

• изменение параметров систем, установленных по умолчанию;

• разделение важных функций между различными серверами;

• удаление ненужного или неиспользуемого функционала;

• регламентация используемых протоколов взаимодействия;

• обеспечение безопасного удаленного доступа администраторов для управления системами.

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

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

Требование 3: должна быть обеспечена защита данных держателей карт при хранении.

Данное обобщенное требование содержит 15 требований и соответствующих им процедур оценки, определяющих, как необходимо обрабатывать, хранить и защищать непосредственно данные платежных карт (такие как PAN, TRACK, PINBLOCK и т. п.), в том числе:

• необходимо хранить номера карт только в тех местах и в течение такого срока, которые явно определены бизнес-целями;

• соблюдать политику по уничтожению номеров карт после истечения срока их обоснованного хранения;

• ограничивать доступ сотрудников к номерам карт в приложениях;

• маскировать, шифровать, использовать другие способы затруднения получения полного номера карт при хранении;

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

• управлять криптографическими ключами, используемыми для шифрования данных при хранении.

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

Наиболее проблемным при внедрении всего стандарта обычно считается требование 3.4 (приведение номеров карт при хранении к нечитаемому виду путем использования шифрования, маскирования и т. п.), поскольку это требует:

• доработки/замены прикладного программного обеспечения, используемого для обработки карт, включая изменение алгоритмов поиска номеров карт, в частности по маске;

• обновления базы данных, поскольку, например, в СУБД Oracle шифрование хорошо поддерживается начиная с 10-й версии;

• апгрейда оборудования на более производительное, поскольку шифрование требует больших аппаратных ресурсов;

• обеспечения шифрования резервных копий баз данных;

• серьезной проработки и регламентации вопросов управления ключами шифрования для каждого ПО, которое его поддерживает (включая генерацию, распределение, обеспечение безопасности и уничтожение).

Требование 4: должно быть обеспечено шифрование передачи данных держателей карт по сетям общего пользования.