Стандарт PCI DSS
Стандарт PCI DSS
История стандарта
В последние годы по всему миру участились случаи взлома банковских информационных систем, а также факты мошенничества и кражи данных держателей карт. Подобная нездоровая тенденция послужила одной из главных причин, побудившей международные платежные системы объединить свои усилия и принять дополнительные меры для защиты своих клиентов. С 2001 г. платежные системы начали разрабатывать собственные программы обеспечения информационной безопасности для снижения рисков мошенничества — в VISA это были программы Cardholder Information Security Program (CISP) и Account Information Security (AIS), в MasterCard была разработана программа Site Data Protection (SDP). В 2004 г. был разработан единый набор требований к безопасности данных — Payment Card Industry Data Security Standard 1.0, объединивший в себе требования ряда программ по безопасности платежных систем VISA Int., MasterCard, American Express, Discover Card и JCB.
Впоследствии, в сентябре 2006 г., для развития и продвижения стандарта PCI DSS, был создан специальный Совет по безопасности — PCI Security Standards Council. Основными функциями Совета по безопасности являются разработка и публикация стандартов PCI и всей сопутствующей документации, определение требований к компаниям, планирующим получить сертификацию для проведения аудитов по PCI DSS («QSA») и сканирований («ASV»), осуществление непосредственно самой сертификации, проведение обучающих тренингов для будущих QSA-аудиторов, а также осуществление контроля качества проведенных аудиторами работ. Официальным источником информации о стандартах PCI является сайт Совета по безопасности[66], там можно найти:
• ответы на частые вопросы — FAQ;
• описание рисков, связанных с каждым требованием стандарта — Navigating PCI DSS Document;
• дополнительные материалы и рекомендации Совета по выполнению требований стандарта PCI DSS;
• тексты стандартов PCI DSS, PA DSS и PCI PED на различных языках[67].
В свою очередь международные платежные системы принимают отчетность по результатам аудитов и оценивают работу QSA.
Обновленная версия стандарта PCI DSS 1.1 вышла в сентябре 2006 г., в ноябре 2008 г. вышла версия 1.2 и текущая версия 2.0 на момент написания книги была принята в ноябре 2010 г. Несмотря на большое количество различных версий, по сути набор требований не претерпел существенных изменений, новые версии стандарта в основном содержали уточнение требований и исправление ошибок.
Сферы применения PCI DSS
Действие стандарта PCI DSS распространяется на все торгово-сервисные предприятия (merchants) и поставщиков услуг (service providers), работающих с международными платежными системами, т. е. на всех тех, кто передает, обрабатывает и хранит данные держателей карт. В табл. 2.1 проиллюстрированы различные типы данных и требования к ним, которые выдвигает PCI DSS.
Также в зависимости от количества обрабатываемых транзакций каждой платежной системой компании присваивается определенный уровень с соответствующим набором требований, которые должны выполняться в обязательном порядке. Это может быть (1) ежегодное прохождение аудита, (2) ежеквартальные сканирования сети или (3) ежегодное заполнение листа самооценки (Self Assessment Questionnaire — специальная анкета, разработанная PCI SSC для самооценки компаний).
Требования Стандарта безопасности данных платежных приложений (PA DSS) являются производными от требований Стандарта безопасности данных индустрии платежных карт (PCI DSS) и Процедур аудита безопасности PCI DSS (PCI DSS Security Audit Procedures). Эти документы, с которыми можно ознакомиться на сайте PC PCI, содержат подробное описание требований безопасности данных, которые торгово-сервисные предприятия и сервис-провайдеры должны соблюдать для соответствия стандарту PCI DSS (следовательно, какое приложение платежной системы необходимо использовать для обеспечения соответствия этому стандарту)[68].
Стандарт PCI DSS обычно не распространяется на производителей приложений платежных систем, поскольку большинство производителей не выполняют хранение, обработку и передачу данных о держателях карт. Однако поскольку приложения платежных систем используются клиентами для хранения, обработки и передачи данных о держателях карт, а клиенты должны соблюдать требования стандарта PCI DSS, то приложения платежных систем должны соответствовать требованиям стандарта PCI DSS и не нарушать их.
Ниже приведены несколько способов использования приложений платежных систем, при которых требования стандарта PCI DSS нарушаются:
• хранение данных магнитной полосы карты в сети клиента после авторизации;
• использование приложений, для корректной работы которых требуется отключение клиентами программного обеспечения, которое должно применяться для соблюдения требований стандарта PCI DSS (например, антивирусных программ или межсетевых экранов);
• использование производителями незащищенных методов подключения к этим приложениям для технической поддержки клиента.
При использовании защищенных приложений платежных систем в среде, соответствующей требованиям стандарта PCI DSS, уменьшается вероятность нарушения безопасности, приводящая к компрометации полных данных магнитной полосы, кодов проверки подлинности карты (CAV2, CID, CVC2, CVV2), ПИН-кодов и ПИН-блоков и, в результате, — к осуществлению злоумышленниками мошеннических операций.
Описание требований стандарта
Все требования стандарта сгруппированы в 12 разделов, объединенных в 6 групп:
• построение и поддержание защищенной сети:
• требование 1: установка и администрирование конфигурации межсетевых экранов для защиты данных держателей карт;
• требование 2: не должны использоваться системные пароли и другие параметры безопасности, установленные производителем по умолчанию;
• защита данных держателей карт:
• требование 3: должна быть обеспечена защита данных держателей карт при хранении;
• требование 4: должно быть обеспечено шифрование передачи данных держателей карт по сетям общего пользования;
• реализация программы управления уязвимостями:
• требование 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, например), возникает ситуация, при которой в одной базе данных могут храниться критичные данные авторизации как сохраненные в процессе выпуска карт, так и сохраненные после авторизации. В этом случае необходимо рассматривать каждое место хранения данных в привязке к процессу, в рамках которого они возникают, — ведь в стандарте запрещено хранить критичные данные, возникшие только в результате авторизации, но ничего не сказано о данных, возникающих в рамках выпуска карт.
Наиболее проблемным при внедрении всего стандарта обычно считается требование 3.4 (приведение номеров карт при хранении к нечитаемому виду путем использования шифрования, маскирования и т. п.), поскольку это требует:
• доработки/замены прикладного программного обеспечения, используемого для обработки карт, включая изменение алгоритмов поиска номеров карт, в частности по маске;
• обновления базы данных, поскольку, например, в СУБД Oracle шифрование хорошо поддерживается начиная с 10-й версии;
• апгрейда оборудования на более производительное, поскольку шифрование требует больших аппаратных ресурсов;
• обеспечения шифрования резервных копий баз данных;
• серьезной проработки и регламентации вопросов управления ключами шифрования для каждого ПО, которое его поддерживает (включая генерацию, распределение, обеспечение безопасности и уничтожение).
Требование 4: должно быть обеспечено шифрование передачи данных держателей карт по сетям общего пользования.
Данное обобщенное требование содержит 3 требования и 9 соответствующих им процедур оценки, регламентирующих вопросы шифрования данных платежных карт при передаче их по открытым каналам связи, с использованием программ мгновенного обмена сообщениями (таких как Skype, ICQ и т. п.) и через беспроводные сети.
Необходимо заметить, что в рамках данного требования каналы GSM считаются публичными и требуют криптозащиты трафика. И это несмотря на то, что во многих сетях мобильных операторов реализовано шифрование, а, например, каналы FrameRelay считаются достаточно защищенными и не требуют дополнительного шифрования. А с точки зрения используемых алгоритмов для шифрования можно использовать не только сертифицированную российскую криптографию, но также и другие алгоритмы с достаточной криптозащитой (например, AES 256).
Реализация данного требования в российских банках обычно вызывает наименьшее количество проблем, поскольку исторически у нас вопросам криптозащиты трафика уделают большое внимание как сами банки, так и регулятор в лице ФСБ. Обычно все каналы связи с филиалами, терминальные сети банкоматов уже защищены с помощью VPN, и это вполне соответствует тому, что требует стандарт PCI DSS.
Реализация программы управления уязвимостями
Требование 5: должно использоваться регулярно обновляемое антивирусное программное обеспечение.
Данное обобщенное требование содержит всего 3 требования и 6 соответствующих им процедур оценки, описывающих особенности применения и управления системами антивирусной защиты.
Реализация данных требований обычно не вызывает больших проблем, так как в большинстве организаций уже стоит какая-либо система антивирусной защиты. Реализация требований сводится к правильной настройке системы антивирусной защиты и механизмов протоколирования событий, а также, при необходимости, закупке дополнительных лицензий на серверы, так как в соответствии со стандартом все системные компоненты, потенциально подверженные вирусным атакам, требуют антивирусной защиты. Хотя на практике известны случаи, когда из-за падения производительности ввиду установки антивируса приходилось либо обновлять аппаратную часть серверов, либо менять антивирус на менее требовательный к ресурсам.
Требование 6: должна обеспечиваться безопасность при разработке и поддержке систем и приложений.
Данное обобщенное требование содержит 24 требования и 32 соответствующие им процедуры оценки, регламентирующие вопросы поддержки и обновления систем и регламентирующие вопросы разработки.
Реализация данных требований обычно вызывает серьезные сложности по ряду причин:
1) в большинстве российских компаний обновления безопасности на внутренние серверы, особенно на базы данных, практически никогда не ставились, так как, по мнению администраторов, безопасность обеспечивают внешние межсетевые экраны, а любое обновление может нарушить работоспособность системы, что чревато намного большими проблемами, чем гипотетический взлом. К сожалению, эту логику администраторов вполне понимают и злоумышленники. И, как правило, очень успешно используют уязвимость внутренних серверов для получения доступа к данным пластиковых карт;
2) вендоры прикладного программного обеспечения обычно тестируют совместимость своих приложений с обновлениями операционных систем и баз данных с достаточно большим опозданием, и чаще всего четко прописывают в контрактах на поддержку, с какой именно версией и какими обновлениями операционной системы и базы данных они готовы поддерживать свои приложения, чем ставят своих клиентов в очень неудобное положение — или выполняются требования стандарта, или теряется поддержка вендора для прикладных систем. Впрочем, стандарт безопасности для вендоров PA DSS частично позволяет решить эту проблему, обязывая вендора своевременно тестировать совместимость своих приложений с выходящими обновлениями безопасности.
Еще хуже ситуация обстоит с вопросами разработки программного обеспечения. Как правило, если мы говорим о банковской организации, разработка программного обеспечения для него носит характер побочной деятельности. Количество разработчиков обычно небольшое даже по сравнению с количеством ИТ персонала, поддерживающего системы. Когда ПО разрабатывается своими силами, как правило, процессы разработки не документируются, тестовые системы не выделяются в отдельный сегмент сети, сами разработчики принимают участие и в тестировании, и в поддержке систем, уже находящихся в эксплуатации. Все это является нарушением стандарта, требования которого предполагают наличие задокументированных процессов разработки, четко разделенных на стадии, в рамках каждой их которых учитываются вопросы обеспечения ИБ. Разработка и тестирование должны быть явно разделены, тестирование не должно проводиться на реальных номерах карт, изменения в программном обеспечении должны быть утверждены руководством — это лишь небольшая часть требований, которые не всегда выполняются даже в компаниях, профессионально разрабатывающих программное обеспечение, что уж тут говорить о банке с совершенно другой специализацией.
Также в ходе разработки необходимо учитывать специальную технику и методы программирования, позволяющие избежать типовых уязвимостей, которые потом могут быть использованы злоумышленниками.
Для веб-приложений и этого недостаточно — для дополнительной защиты необходимо устанавливать специальные межсетевые экраны перед веб-серверами или проводить специализированные проверки кода ежегодно.
Реализация мер по строгому контролю доступа
Требование 7: доступ к данным держателей карт должен быть ограничен в соответствии со служебной необходимостью.
Данное обобщенное требование содержит 7 требований и 7 соответствующих им процедур оценки, описывающих необходимость продумывания и документирования минимально достаточных прав доступа для выполнения той или иной работы сотрудникам, а также наличия системы контроля доступа, позволяющей реализовать задуманную политику минимально достаточного доступа.
Если в компании есть должностные инструкции и налажена система предоставления доступа через систему заявок, серьезных трудностей с реализацией этих требований обычно не возникает.
Требование 8: каждому лицу, имеющему доступ к вычислительным ресурсам, должен быть назначен уникальный идентификатор.
Данное обобщенное требование содержит 18 требований и 25 соответствующих им процедур оценки, обеспечивающих две важные задачи безопасности — обеспечение мониторинга действий каждого пользователя в любой системе и снижение риска несанкционированного доступа с использованием чужого пароля. Для этого описаны требования по:
• длине, сложности и частоте смены паролей;
• использованию двухфакторной аутентификации при удаленном доступе;
• автоматической блокировке сеансов работы в случае бездействия пользователя;
• хранению паролей в системах в нечитаемом виде;
• удалению неиспользуемых учетных записей;
• запрету прямого доступа к базам данных, содержащим данные платежных карт для всех пользователей, за исключением администраторов СУБД.
Большинство требований достаточно просто реализуются штатными средствами операционных систем и баз данных, а для повышения уверенности, что все системные компоненты будут настроены корректно, настройки, обеспечивающие выполнение этих требований, рекомендуется включать в стандарты конфигурирования (см. Требование 2).
Требование 9: физический доступ к данным держателей карт должен быть ограничен.
Данное обобщенное требование содержит 20 требований и 28 соответствующих им процедур оценки, регламентирующих вопросы физической защиты серверов и сетевого оборудования:
• систем видеонаблюдения и контроля доступа в помещения;
• визуальной идентификации посетителей;
• учета, контроля перемещения и защиты отчуждаемых носителей, содержащих данные платежных карт;
• уничтожения всех видов носителей защищаемой информации, включая жесткие диски, бумажные носители и магнитные ленты.
Обычно к моменту принятия решения о внедрении стандарта PCI DSS большинство требований данного раздела в банковской организации уже выполняется. Особенно в случае, если банк занимается выпуском платежных карт самостоятельно — ведь для выпуска платежных карт предъявлены намного более серьезные требования по физической защите помещений. Вместе с требованием 5 (антивирусная защита) это требование является наиболее простым и понятным в реализации. Особенно если сравнивать его с требованием 3 (защита данных платежных карт) и требованием 10 (протоколирование и мониторинг доступа).
Регулярный мониторинг и тестирование сетей
Требование 10: должен отслеживаться и контролироваться любой доступ к сетевым ресурсам и данным держателей карт.
Данное обобщенное требование содержит 27 требований и 29 соответствующих им процедур оценки, регламентирующих вопросы протоколирования и мониторинга событий, включая особенности:
• перечня и состава протоколируемых событий;
• удаленного хранения и защиты собранных журналов аудита;
• синхронизации времени между источниками событий и системой мониторинга;
• периода хранения журналов аудита.
Практика показывает, что одна из самых серьезных проблем на пути к соответствию PCI DSS — организация процесса мониторинга событий ИБ. C точки зрения стандарта организовать процесс можно различными способами: централизованно/децентрализованно, средствами автоматизации или без оных и т. п. Для обычного российского банка, имеющего собственный процессинг, организация мониторинга событий информационной безопасности могла бы выглядеть так:
• сбор событий автоматизирован;
• мониторинг в рабочее время обеспечивает квалифицированный сотрудник из подразделения безопасности;
• в ночное время реагирование обеспечивается только на наиболее критичные события, которые поступают дежурному сотруднику и от которого не требуется знаний по ИБ, а требуется реагирование по инструкции (в норме задействуются уже существующие круглосуточные службы поддержки пользователей).
Необходимо отметить важные особенности системы мониторинга событий ИБ применительно к задачам обеспечения и поддержания соответствия стандарту.
1. В систему мониторинга должны собираться события ИБ от всех типов ресурсов в области действия стандарта:
• операционных систем серверов;
• СУБД;
• сетевое оборудование;
• веб-серверы (если используются для обработки карт);
• реже — прикладное ПО обработки карт, если имеющие к информационной безопасности события не регистрируются на других уровнях (например, добавляемая учетная запись не является учетной записью базы данных и выявить ее появление можно только в прикладных журналах или включая аудит на изменение пользовательской таблицы в базе данных).
2. Настройки протоколирования данных ресурсов должны обеспечивать регистрацию (а система мониторинга, в свою очередь, — сбор, обработку и хранение) всех типов событий, приведенных в п. 10.2.1- 10.2.7 стандарта PCI DSS (если имеют смысл для данного типа ресурса), а именно:
• доступ к данным платежных карт (специфично для каждой из форм хранения данных — либо файлы, либо объекты базы данных);
• успешное использование привилегированных административных полномочий и управление системными объектами (управление учетными записями и их правами, старт/остановка сервисов, конфигурирование сетевого оборудования, изменение параметров аудита, изменение протоколов аудита, изменение реестра операционной системы, изменение словарей и сегментов базы данных, создание/монтирование в операционной системе устройств/каналов и др.);
• все события, связанные с работой систем аутентификации (успешный вход в систему, ошибки аутентификации пользователей, ошибки и сбои системы аутентификации);
• попытки использования отсутствующих привилегий, т. е. ошибки логического доступа к объектам и функциям систем (например, пользователь базы данных пытается читать данные из словаря, чтобы узнать структуру базы данных, а прав на это у него нет).
3. В систему мониторинга должны также попадать сообщения от специализированных средств защиты (или мониторинг событий от них организуется децентрализованно):
• межсетевые экраны;
• IDS/IPS;
• средства антивирусной защиты;
• средства контроля целостности и др.
4. Должен обеспечиваться совокупный период хранения зарегистрированных событий информационной безопасности не менее одного года при включенном уровне протоколирования событий на источниках согласно требованиям 10.2.1-10.2.7 стандарта PCI DSS (см. пункт 2 данного списка). Если хранить такой объем событий в системе невозможно (в связи с их объемом и стоимостью хранилища), нужно продумывать решение по архивированию событий (в ручном или автоматическом режиме).
Требование 11: должно выполняться регулярное тестирование систем и процессов обеспечения безопасности.
Данное обобщенное требование содержит 9 требований и 23 соответствующих им процедуры оценки, регламентирующие аспекты периодического тестирования защищенности и частично вопросы обнаружения потенциальных несанкционированных вторжений/изменений в системах, в частности:
• необходимость ежеквартального (или при изменении конфигурации сети или защищаемых серверов) внешнего сканирования с привлечением сертифицированной организации;
платежных систем и расчетов
• необходимость ежеквартального (или при изменении конфигурации сети или защищаемых серверов) внутреннего сканирования уязвимостей с использованием специальных программных средств;
• выявление несанкционированных беспроводных точек доступа;
• выявление несанкционированной активности в сети и/или изменения в файловых системах серверов;
• проведение ежегодных (или при изменении конфигурации сети или защищаемых серверов) внутренних и внешних тестов на проникновение.
Особенностью выполнения этих требований является то, что банку недостаточно просто провести сканирование или заказать тест на проникновение. Требование считается выполненным только в том случае, если в ходе тестирования/сканирования не было обнаружено серьезных уязвимостей. И при этом были протестированы все серверы/устройства и службы, которые входят в область применения стандарта. Более того, к моменту ежегодной проверки нужно показать, что на протяжении всего прошлого года своевременно проводились сканирования и оперативно устранялись уязвимости (в случае их наличия). Внутренние сканирования и тесты на проникновения могут проводиться любыми квалифицированными сотрудниками — как изнутри компании, так и приглашенными извне, тогда как внешнее сканирование должно проводиться сертифицированной компанией, имеющей статус Approved Scanning Vendor (ASV)[69].
Поддержание политики информационной безопасности
Требование 12: должна поддерживаться политика, регламентирующая деятельность всех сотрудников.
Данное обобщенное требование содержит 36 требований и 39 соответствующих им процедур оценки, регламентирующих аспекты нормативно правового обеспечения информационной безопасности, и организации защиты, включая:
• наличие политики безопасности и процедур, описывающих типовые операции обеспечения защиты;
• документированное распределение ответственности за различные аспекты обеспечения безопасности, мониторинга и контроля;
• наличие программы повышения осведомленности и обучения сотрудников в вопросах обеспечения защиты;
• проверку сотрудников на благонадежность перед принятием на работу;
• контроль договорных обязательств в части защиты при передаче данных платежных карт сторонним организациям;
• документирование и периодическое тестирование и обновление плана реагирования на инциденты безопасности;
• обеспечение круглосуточного мониторинга и реагирования на инциденты информационной безопасности.
Реализация этих требований (в частности — по документированию) достаточно проста по сути, но может быть несколько трудоемка для организаций со слабой нормативной базой по обеспечению безопасности. В организациях, где процессы управления безопасностью внедрены давно, обычно достаточно небольшой доработки существующей документации для отражения особенностей требования стандарта PCI DSS.