Безопасность карточного бизнеса : бизнес-энциклопедия - А. Алексанов
Шрифт:
Интервал:
Закладка:
• реализация программы управления уязвимостями:
• требование 5: должно использоваться регулярно обновляемое антивирусное программное обеспечение;
• требование 6: должна обеспечиваться безопасность при разработке и поддержке систем и приложений;
• реализация мер по строгому контролю доступа:
• требование 7: доступ к данным держателей карт должен быть ограничен в соответствии со служебной необходимостью;
• требование 8: каждому лицу, имеющему доступ к вычислительным ресурсам, должен быть назначен уникальный идентификатор;
• требование 9: физический доступ к данным держателей карт должен быть ограничен;
• регулярный мониторинг и тестирование сетей:
• требование 10: должен отслеживаться и контролироваться любой доступ к сетевым ресурсам и данным держателей карт;
• требование 11: должно выполняться регулярное тестирование систем и процессов обеспечения безопасности;
• поддержание политики информационной безопасности:
• требование 12: должна поддерживаться политика, регламентирующая деятельность всех сотрудников.
Каждое из 12 общих требований содержит ряд «подтребований» и процедур их проверки, которые, с одной стороны, обеспечивают (как минимум в теории) однообразие контроля требований аудиторам и, с другой стороны, часто детализируют само требование. Также для понимания сути требования и/или процедуры проверки бывает полезно учитывать, в какой группе находится данное требование. Описание требований приведено для версии стандарта PCI DSS 2.0.
Построение и поддержание защищенной сетиТребование 1: установка и администрирование конфигурации межсетевых экранов для защиты данных держателей карт.
Данное обобщенное требование содержит 18 требований и 25 процедур оценки их соответствия, регламентирующих различные аспекты применения межсетевых экранов для защиты сегментов сети, обрабатывающих данные платежных карт, такие как:
• сегментация сети на различные зоны безопасности и размещение серверов в них;
• необходимость документирования и поддержания актуальности схемы сети, перечня разрешенных протоколов;
• настройка конкретных правил фильтрации трафика;
• необходимость регламентирования процесса внесения изменений в конфигурации межсетевых экранов;
• настройка правил фильтрации трафика на мобильных компьютерах.
Обычно реализация данных требований достаточно трудоемка, ввиду того что кроме настройки межсетевого экрана чаще всех приходится менять сегментацию сети, переносить серверы в дополнительные сегменты безопасности, решать вопросы с производительностью межсетевых экранов и определять порты, через которые работают серверы, ранее находившиеся в одном сегменте.
Тем не менее при правильной реализации риск несанкционированного доступа в сеть после выполнения всех требований этого раздела существенно снижается.
Требование 2: не должны использоваться системные пароли и другие параметры безопасности, установленные производителем по умолчанию.
Данное обобщенное требование содержит 23 требования и соответствующие им процедуры оценки, регламентирующие различные аспекты настройки серверов, сетевого оборудования, приложений и баз данных, в частности:
• разработка стандартов безопасной настройки, определяющих конкретные параметры безопасности для каждого вида используемых систем;
• изменение параметров систем, установленных по умолчанию;
• разделение важных функций между различными серверами;
• удаление ненужного или неиспользуемого функционала;
• регламентация используемых протоколов взаимодействия;
• обеспечение безопасного удаленного доступа администраторов для управления системами.
Как правило, реализация данного набора требований требует определенного времени как на разработку необходимых параметров безопасности, так и на тестирование их работоспособности и применение на всех системных компонентах. Для большой организации этот процесс может затянуться на несколько месяцев.
Но в результате безопасность систем существенно возрастает, особенно в совокупности с правильно настроенным межсетевым экраном и вовремя устанавливаемыми обновлениями безопасности. По сути, реализация требований 1, 2 и 6 в полном объеме могли бы предотвратить более 90 % случившихся взломов систем с последующими утечками данных платежных карт.
Защита данных держателей картТребование 3: должна быть обеспечена защита данных держателей карт при хранении.
Данное обобщенное требование содержит 15 требований и соответствующих им процедур оценки, определяющих, как необходимо обрабатывать, хранить и защищать непосредственно данные платежных карт (такие как PAN, TRACK, PINBLOCK и т. п.), в том числе:
• необходимо хранить номера карт только в тех местах и в течение такого срока, которые явно определены бизнес-целями;
• соблюдать политику по уничтожению номеров карт после истечения срока их обоснованного хранения;
• ограничивать доступ сотрудников к номерам карт в приложениях;
• маскировать, шифровать, использовать другие способы затруднения получения полного номера карт при хранении;
• жесткие запреты хранения критичных данных карт, используемых для авторизации после ее завершения;
• управлять криптографическими ключами, используемыми для шифрования данных при хранении.
Необходимо отметить следующее: так как стандарт разрабатывался в первую очередь для снижения рисков мошенничества в инфраструктурах торгово-сервисных предприятий и поставщиков сервиса (таких как платежные шлюзы, процессинговые центры и т. п.), вопросы защиты и хранения данных платежных карт в банковских организациях в рамках их выпуска не рассмотрены достаточно подробно. В результате при подтверждении соответствия стандарту в банках, где осуществляется и эквайринг, и выпуск карт на базе решения некоторых вендоров (таких как OpenWay, например), возникает ситуация, при которой в одной базе данных могут храниться критичные данные авторизации как сохраненные в процессе выпуска карт, так и сохраненные после авторизации. В этом случае необходимо рассматривать каждое место хранения данных в привязке к процессу, в рамках которого они возникают, — ведь в стандарте запрещено хранить критичные данные, возникшие только в результате авторизации, но ничего не сказано о данных, возникающих в рамках выпуска карт.