Вы находитесь на странице: 1из 180

Стандарт безопасности данных

индустрии платежных карт (PCI DSS)

Требования и процедуры оценки безопасности


Версия 3.2
Апрель 2016 г.
Изменения документа
Дата Версия Описание Страницы
В документе "PCI DSS Requirements and Security Assessment Procedures" («Стандарт
безопасности данных индустрии платежных карт. Требования и процедуры оценки
безопасности») версии 1.2 устранена избыточность документов, а также в него внесены
Октябрь 2008 г. 1.2 общие и частные изменения в сравнении с версией 1.1 под названием "PCI DSS Security
Audit Procedures" («Процедуры оценки безопасности»). Для получения полной информации
см. "PCI Data Security Standard Summary of Changes from PCI DSS Version 1.1 to 1.2."
(Обзор изменений PCI DSS в версии 1.2 в сравнении с версией 1.1)
Добавлено предложение, которое было неправильно удалено при переработке версии
5
PCI DSS 1.1 в версию 1.2.
Исправлено “then” (затем) на “than” (чем) в описании проверочных процедур 6.3.7.a и
32
6.3.7.b.

Июль 2009 г. 1.2.1 Удалено выделение серым цветом для столбцов “in place” (выполнено) и “not in place” (не
33
выполнено) в описании проверочных процедур 6.5.b.
Для таблицы «Компенсационные меры – Пример заполнения» исправлено предложение в
верхней части страницы, которое теперь звучит так: «Пользуйтесь этой таблицей для
64
описания компенсационных мер по любым требованиям, имеющим статус «Выполнено
благодаря использованию компенсационных мер».
Обновлены и внесены изменения из версии 1.2.1. См. «PCI DSS: обзор изменений
Октябрь 2010 г. 2.0
PCI DSS в версии 2.0 в сравнении с версией 1.2.1».
Изменение в сравнении с версией 2.0. См. «PCI DSS: обзор изменений PCI DSS в
Ноябрь 2013 г. 3.0
версии 3.0 в сравнении с версией 2.0».
Изменение в сравнении с PCI DSS версии 3.0. См. «PCI DSS: обзор изменений PCI DSS
Апрель 2015 г. 3.1
версии 3.1 в сравнении с версией 3.0».
Изменение в сравнении с PCI DSS версии 3.1. См. «PCI DSS: обзор изменений PCI DSS
Апрель 2016 г. 3.2
версии 3.2 в сравнении с версией 3.1».

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 2
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Этот документ (далее «Официальный перевод на русский язык") является официальным переводом на русский язык документа,
описанного как PCI DSS v3.2, доступного по адресу https://www.pcisecuritystandards.org/document_library, ©2006-2016 PCI Security
Standards Council, LLC (далее «Совет»). Данный официальный перевод на русский язык представлен с согласия и при поддержке
компании ABBIS (далее «Компания») исключительно в информационных целях в соответствии с соглашением между Советом и
Компанией. Настоящим переводом не предоставляются какие-либо права на реализацию описанных в нем спецификаций; такие права
могут быть получены только в результате принятия условий лицензионного соглашения, текст которого находится по адресу:
https://www.pcisecuritystandards.org/document_library. Версия документа на английском языке размещена по адресу
https://www.pcisecuritystandards.org/document_library и для всех целей считается окончательной версией данного документа. В случае
каких-либо неоднозначностей или противоречий между настоящей версией и версией документа на английском языке англоязычный
текст имеет преимущественную силу, и в этой связи не следует руководствоваться данной версией для какой бы то ни было цели. Ни
Совет, ни Компания не несут никакой ответственности за любые ошибки или неясности, содержащиеся в данном документе.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 3
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Содержание
Изменения документа ......................................................................................................................................................................... 2
Введение и обзор стандарта PCI DSS .............................................................................................................................................. 6
Источники информации о PCI DSS ................................................................................................................................................................. 7
Область применения стандарта PCI DSS ........................................................................................................................................ 8
Связь между стандартами PCI DSS и PA-DSS .............................................................................................................................. 10
Применимость PCI DSS к приложениям, соответствующим стандарту PA-DSS .................................................................................. 10
Применимость стандарта PCI DSS к разработчикам платежных приложений ....................................................................................... 10
Область применимости требований стандарта PCI DSS............................................................................................................ 11
Сегментация сети......................................................................................................................................................................................... 13
Беспроводные сети ........................................................................................................................................................................................ 13
Привлечение сторонних поставщиков услуг (аутсорсинг)......................................................................................................................... 14
Передовой опыт по внедрению стандарта PCI DSS в привычные бизнес-процессы .......................................................... 15
Для аудиторов: выборка подразделений организации и системных компонентов ............................................................. 17
Компенсационные меры ................................................................................................................................................................... 18
Процесс проведения оценки соответствия стандарту PCI DSS ................................................................................................ 19
Версии стандарта PCI DSS ............................................................................................................................................................... 20
По состоянию на дату публикации данного документа стандарт PCI DSS версии 3.1 действителен до 31 октября 2016
г., после чего он будет недействителен. Все процедуры подтверждения соответствия стандарту PCI DSS после
указанной даты должны проводиться по стандарту PCI DSS версии 3.2 или более поздних версий. ............................. 20
Подробные требования и процедуры оценки безопасности стандарта PCI DSS .................................................................. 21
Построить и поддерживать защищенные сети и системы ........................................................................................................................ 22
Требование 1. Установить и поддерживать конфигурацию межсетевых экранов для защиты ДДК. ............................................... 22
Требование 2. Не использовать пароли к системам и другие параметры безопасности по умолчанию, заданные производителем.
32
Защищать ДДК 40
Требование 3. Защищать хранимые ДДК................................................................................................................................................. 40
Требование 4. Шифровать ДДК при передаче через сети общего пользования................................................................................... 55
Поддерживать программу управления уязвимостями. ............................................................................................................................. 58
Требование 5. Защищать все системы от вредоносного ПО и регулярно обновлять антивирусные ПО или программы. ............. 58

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 4
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требование 6. Разрабатывать и поддерживать безопасные системы и приложения......................................................................... 62
Внедрять строгие меры контроля доступа ................................................................................................................................................. 80
Требование 7. Ограничивать доступ к ДДК в соответствии со служебной необходимостью........................................................... 80
Требование 8. Идентифицировать и аутентифицировать доступ к системным компонентам ...................................................... 84
Требование 9. Ограничивать физический доступ к ДДК ........................................................................................................................ 98
Осуществлять регулярный мониторинг и тестирование сетей .............................................................................................................. 111
Требование 10. Отслеживать и вести мониторинг всего доступа к сетевым ресурсам и ДДК .........................................................111
Требование 11. Регулярно тестировать системы и процессы безопасности. ....................................................................................123
Поддерживать политику информационной безопасности ...................................................................................................................... 134
Требование 12. Поддерживать политику информационной безопасности для всех работников. ..........................................................134
Приложение A. Дополнительные требования PCI DSS ........................................................................................................... 150
Приложение А1. Дополнительные требования PCI DSS для поставщиков услуг хостинга с общей средой ........................................151
Приложение А2. Дополнительные требования PCI DSS для организаций, использующих SSL и (или) ранние версии TLS ..................154
Приложение А3: Дополнительная проверка организаций зоны повышенного риска ................................................................................158
Приложение B. Компенсационные меры .................................................................................................................................. 175
Приложение С: Компенсационные меры – Форма для заполнения .................................................................................... 177
Приложение D. Сегментация и выборка подразделений организации и системных компонентов ............................. 180

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 5
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Введение и обзор стандарта PCI DSS
Стандарт безопасности данных индустрии платежных карт (PCI DSS) разработан, чтобы повысить уровень безопасности данных о
держателях карт (ДДК) и содействовать широкому внедрению унифицированных мер защиты данных по всему миру. Стандарт PCI DSS
содержит базовые технические и операционные требования, которые разработаны для защиты данных платежных карт (ДПК). Данный
стандарт применяется для всех организаций, вовлеченных в обработку платежных карт: ТСП, процессинговых центров, эквайреров,
эмитентов и поставщиков услуг, а также всех прочих организаций, которые хранят, обрабатывают или передают ДДК и (или) критичные
аутентификационные данные (КАД). Ниже приведен общий обзор 12 требований стандарта PCI DSS.

Стандарт безопасности данных индустрии платежных карт (PCI DSS): общий обзор
Построить и 1. Установить и поддерживать конфигурацию межсетевых экранов для
поддерживать защиты ДДК.
защищенные сети и 2. Не использовать пароли к системам и другие параметры
системы безопасности по умолчанию, заданные производителем.
3. Защищать хранимые ДДК
Защищать ДДК
4. Шифровать ДДК при передаче через сети общего пользования.
Поддерживать программу 5. Защищать все системы от вредоносного ПО и регулярно обновлять
управления антивирусные ПО или программы
уязвимостями. 6. Разрабатывать и поддерживать безопасные системы и приложения
7. Ограничивать доступ к ДДК в соответствии со служебной
необходимостью.
Внедрять строгие меры
8. Идентифицировать и аутентифицировать доступ к системным
контроля доступа
компонентам
9. Ограничивать физический доступ к ДДК
Осуществлять регулярный 10. Отслеживать и вести мониторинг всего доступа к сетевым ресурсам
мониторинг и и ДДК
тестирование сетей 11. Регулярно тестировать системы и процессы безопасности
Поддерживать политику
12. Поддерживать политику информационной безопасности для всех
информационной
работников.
безопасности

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 6
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
подробные и инструкции, чтобы способствовать организациям в подготовке и проведении оценки соответствия требованиям PCI DSS, а
также в предоставлении отчета по результатам ее проведения. Требования стандарта PCI DSS и проверочные процедуры описываются,
начиная со стр. 15.

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

Источники информации о PCI DSS

На сайте Совета PCI SSC (PCI Security Standards Council) (www.pcisecuritystandards.org) имеется множество дополнительных источников
информации, призванных способствовать организациям в оценке и подтверждении соответствия PCI DSS, включая:
 Библиотеку документов, в том числе:
Примечание: «Вспомогательные
o PCI DSS: обзор изменений PCI DSS в версии 3.0 в сравнении с версией документы» относятся к
2.0 (PCI DSS – Summary of Changes from PCI DSS version 2.0 to 3.0) сопроводительным документам PCI DSS. В
o Краткий справочник по PCI DSS (PCI DSS Quick Reference Guide) них приводятся дополнительные аспекты и
рекомендации по выполнению требований
o Глоссарий. Основные определения, аббревиатуры и сокращения
PCI DSS, которые при этом не заменяют,
стандартов PCI DSS и PA-DSS
не исключают и не расширяют ни PCI DSS,
o Рекомендации и Вспомогательные документы (Information Supplements ни любое из его требований.
and Guidelines)
o Приоритетный подход к PCI DSS (Prioritized Approach for PCI DSS)
o Шаблон Отчета о соответствии и инструкции по его заполнению
o Опросные листы для самооценки (ОЛС), рекомендации и инструкции по их заполнению
o Свидетельства о соответствии (AOC)
 Часто задаваемые вопросы
 Веб-сайт PCI for Small Merchants («PCI для ТСП малого бизнеса»)
 Обучающие курсы и информационные вебинары по PCI
 Список сертифицированных аудиторов безопасности и авторизованных поставщиков услуг сканирования (ASV)
 Список одобренных PTS устройств и платежных приложений, прошедших проверку на соответствие стандарту PA-DSS

Более подробная информация об этих и других ресурсах доступна на сайте www.pcisecuritystandards.org.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 7
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Область применения стандарта PCI DSS
Данный стандарт применяется для всех организаций, вовлеченных в обработку платежных карт: ТСП, процессинговых центров,
эквайреров, эмитентов и поставщиков услуг, а также всех прочих организаций, которые хранят, обрабатывают или передают ДДК и (или)
КАД.
ДДК и КАД определяются следующим образом:

Данные платежных карт


В ДДК входят: В КАД входят:

 номер карты (PAN);  полные данные треков (данные


магнитной полосы или ее
 имя держателя карты; эквивалента на чипе);
 дата истечения срока действия карты;  CAV2/CVC2/CVV2/CID
 сервисный код.  ПИН-коды и (или) ПИН-блоки

Номер карты является определяющим фактором для ДДК. Если имя держателя карты, сервисный код и (или) дата истечения
срока действия карты хранятся, обрабатываются или передаются вместе с PAN или иным образом присутствуют в среде ДДК (CDE),
то они должны быть защищены согласно применимым требованиям PCI DSS.

Требования PCI DSS применимы к организациям, в которых осуществляется хранение, обработка или передача данных платежных
карт (ДДК и (или) КАД). Некоторые требования PCI DSS также могут быть применены к организациям, передавшим платежные
операции или управление своей средой ДДК на аутсорсинг1. Кроме того, организации, передавшие свои платежные операции или свою
среду ДДК на аутсорсинг, отвечают за то, чтобы защита данных платежных карт осуществлялась третьими лицами в соответствии с
применимыми требованиями PCI DSS.

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 8
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Привести хранимые данные к
Хранение
Элемент данных нечитаемому виду согласно требованию
разрешено
3.4
Номер карты (PAN) Да Да
Имя держателя карты Да Нет
ДДК
Сервисный код Да Нет
Дата истечения срока
ДПК

Да Нет
действия карты
Полные данные треков3 Нет Нельзя хранить согласно требованию 3.2
КАД2 CAV2/CVC2/CVV2/CID4 Нет Нельзя хранить согласно требованию 3.2
5
ПИН-код и (или) ПИН-блок Нет Нельзя хранить согласно требованию 3.2

Требования 3.3 и 3.4 PCI DSS применяются только к PAN. Если PAN хранится вместе с другими элементами ДДК, то согласно требованию
3.4 PCI DSS приводить к нечитаемому виду необходимо только PAN.
После авторизации хранить КАД запрещено (даже в зашифрованном виде). Данное требование действует, даже если PAN отсутствует в
среде. Организациям следует связаться со своими эквайрерами или напрямую с конкретными международными платежными системами,
чтобы узнать, разрешается ли хранить КАД до авторизации, в течение какого срока, а также узнать о соответствующих требованиях к
использованию и защите данных.

3
Полные данные треков на магнитной полосе, эквивалентные данные на чипе или в ином месте
4
Трех- или четырехзначное проверочное значение, напечатанное на лицевой или обратной стороне платежной карты.
5
Персональный идентификационный номер, который вводится держателем карты при выполнении операции с предоставлением карты, и (или)
зашифрованный ПИН-блок, присутствующий в сообщении о транзакции
Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 9
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Связь между стандартами PCI DSS и PA-DSS
Применимость PCI DSS к приложениям, соответствующим стандарту PA-DSS
Использование приложения, которое соответствует стандарту безопасности данных платежных приложений (PA-DSS), само по себе не
обеспечивает соответствие организации требованиям PCI DSS. Это связано с тем, что приложение должно быть внедрено в среду,
соответствующую стандарту PCI DSS, и согласно «Руководству по внедрению в соответствии с PA-DSS» (предоставляется
разработчиком платежного приложения).
Все приложения, которые хранят, обрабатывают или передают ДДК, входят в область оценки организации на соответствие стандарту
PCI DSS, даже если они уже были проверены на соответствие PA-DSS. Оценка соответствия стандарту PCI DSS призвана подтвердить,
что платежное приложение, соответствующее стандарту PA-DSS, должным образом сконфигурировано и безопасно внедрено в
соответствии с требованиями PCI DSS. Если платежное приложение подверглось какой-либо модификации, во время оценки
соответствия стандарту PCI DSS потребуется более тщательное изучение, так как приложение может более не соответствовать версии,
проверенной на соответствие PA-DSS.
Требования стандарта PA-DSS основаны на требованиях и процедурах оценки безопасности стандарта PCI DSS (определенных в
данном документе). Стандарт PA-DSS более подробно описывает требования к платежному приложению, необходимые, чтобы
организациям было проще достичь соответствия стандарту PCI DSS. Поскольку угрозы безопасности постоянно развиваются,
приложения, которые уже не поддерживаются разработчиком (например, в отношении которых разработчик объявил об окончании срока
эксплуатации), могут не обеспечивать такой же уровень безопасности как поддерживаемые разработчиком версии.
Безопасные платежные приложения, внедряемые в среду, соответствующую стандарту PCI DSS снижают вероятность нарушений
безопасности (а также мошеннических действий, возникающих в результате таких нарушений), ведущих к компрометации PAN, полных
данных треков, проверочных кодов и значений (CAV2, CID, CVC2, CVV2), ПИН-кодов и ПИН-блоков.
Чтобы определить, применим ли стандарт PA-DSS к определенному платежному приложению, следует обратиться к документу
«Руководство по программе PA-DSS», который доступен на сайте www.pcisecuritystandards.org.

Применимость стандарта PCI DSS к разработчикам платежных приложений


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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 10
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Область применимости требований стандарта PCI DSS
Требования PCI DSS применяются ко всем системным компонентам, которые входят в среду ДДК или подключены к ней. Среда ДДК –
это совокупность людей, процессов и технологий, которые хранят, обрабатывают или передают ДДК или КАД. Термин «системные
компоненты» включает в себя сетевые и вычислительные устройства, серверы и приложения. Примерами системных компонентов
являются, среди прочего:
 системы, которые:
— предоставляют службы безопасности (например, серверы аутентификации),
— способствуют сегментации сети (например, внутренние межсетевые экраны),
— могут влиять на безопасность среды ДДК (например, серверы разрешения имен или веб-переадресации);
 компоненты виртуализации, например:
— виртуальные машины,
— виртуальные коммутаторы и (или) маршрутизаторы,
— виртуальные приложения и (или) компьютеры,
— гипервизоры;
 сетевые компоненты, в том числе:
— межсетевые экраны,
— коммутаторы,
— маршрутизаторы,
— беспроводные точки доступа,
— устройства сетевой безопасности,
— прочие устройства безопасности;
 типы серверов, в том числе:
— веб-серверы,
— серверы приложений,
— серверы баз данных,
— серверы аутентификации,
— почтовые серверы,

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 11
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
— прокси-серверы,
— серверы службы времени (NTP),
— DNS-серверы;
 приложения, включая все приобретенные или заказные приложения, в том числе внутренние и внешние (например, доступные
через Интернет);
 любой другой компонент или устройство, расположенное внутри среды ДДК или подключенное к ней.

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

Для того чтобы подтвердить корректность и точность определения среды ДДК, следует выполнить следующие действия:
 оцениваемая организация выявляет и документирует присутствие всех ДДК в своей инфраструктуре для того, чтобы убедиться,
что ДДК отсутствуют вне определенной на текущий момент среды ДДК;
 после того, как все места расположения ДДК выявлены и документированы, организация использует эту информацию для
проверки того, что область оценки PCI DSS определена надлежащим образом (например, результаты могут быть представлены в
виде схемы или перечня мест расположения ДДК);
 любые обнаруженные ДДК подлежат включению в область оценки PCI DSS и в среду ДДК; если обнаружены данные, еще не
включенные в среду ДДК, такие данные следует безопасно удалить, перенести в определенную на данный момент среду ДДК
или переопределить среду ДДК так, чтобы в нее вошли эти данные;
 организация сохраняет документы, описывающие, каким образом была определена область оценки PCI DSS. Документы
сохраняются для их проверки аудитором и (или) для использования при следующем ежегодном подтверждении области оценки
PCI DSS.
При каждой оценке соответствия PCI DSS аудитор должен проверить, что область оценки корректно определена и документирована.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 12
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Сегментация сети
Сегментация сети, т. е. отделение среды ДДК от остальной части сети организации в отдельный сегмент (изоляция) не является
требованием PCI DSS. Однако сегментация настоятельно рекомендуется как средство, позволяющее уменьшить:
 область оценки соответствия PCI DSS;
 затраты на оценку соответствия PCI DSS;
 стоимость и сложность реализации и обслуживания защитных мер для соответствия PCI DSS;
 риск для организации (снижаемый за счет объединения ДДК в меньшем количестве мест расположения, находящихся под более
надежным контролем).
Если надлежащая сегментация сети отсутствует (так называемая «плоская сеть»), в область оценки соответствия PCI DSS попадает вся
сеть. Сегментация сети может быть выполнена с использованием множества физических или логических мер, например, надлежащим
образом сконфигурированных межсетевых экранов внутри сети, маршрутизаторов со строгими списками контроля доступа или при
помощи иных технологий, которые ограничивают доступ к определенному сегменту сети. Для того чтобы системный компонент был
исключен из области оценки PCI DSS, его следует должным образом изолировать (сегментировать) от среды ДДК так, чтобы даже в
случае компрометации такого системного компонента это не повлияло бы на безопасность среды ДДК.
Важным предварительным условием к сокращению области среды ДДК является четкое понимание потребностей и процессов
организации, связанных с хранением, обработкой или передачей ДДК. Размещение ДДК в минимально возможном количестве мест
расположения за счет удаления неиспользуемых данных и объединения нужных данных может потребовать реорганизации устоявшейся
практики ведения деятельности.
Документирование потоков ДДК с помощью схемы потоков данных помогает полностью разобраться во всех потоках ДДК и
подтверждает результативность любой сегментации при изолировании среды ДДК.
Если сегментация сети реализована и используется для уменьшения области оценки соответствия PCI DSS, аудитор должен убедиться
в том, что сегментация выполнена надлежащим образом и позволяет уменьшить область оценки. В целом, надлежащая сегментация
сети изолирует системы, которые хранят, обрабатывают или передают ДДК, от систем, которые этого не делают. Достаточность той или
иной реализации сегментации сети, однако, очень зависит от множества факторов и обстоятельств, например, конфигурации данной
сети, используемых технологий и иных реализуемых защитных мер.
В Приложении D: «Сегментация и выборка подразделений организации и (или) системных компонентов» содержится дополнительная
информация о влиянии сегментации сети и выборки на определение области оценки соответствия PCI DSS.

Беспроводные сети
Если в организации используются беспроводные технологии для хранения, обработки или передачи ДДК (например, транзакции с
использованием беспроводных POS-терминалов для ускорения обслуживания клиентов) или если беспроводная локальная сеть (WLAN)
подключена к среде ДДК или является ее частью, то применению и выполнению подлежат требования и проверочные процедуры PCI
DSS для беспроводных окружений (например, требования 1.2.3, 2.1.1 и 4.1.1) Перед внедрением беспроводных технологий организация
Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 13
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
должна тщательно проанализировать необходимость их внедрения и оценить связанные с этим риски. Рекомендуется использовать
беспроводные технологии только для передачи некритичных данных.

Привлечение сторонних поставщиков услуг (аутсорсинг)


Поставщики услуг и ТСП могут привлекать сторонние организации к обработке, хранению и передаче ДДК от их имени или к управлению
компонентами, такими, как маршрутизаторы, межсетевые экраны, физическая безопасность и (или) серверы, что, однако, может
оказывать воздействие на безопасность среды ДДК.
Стороны должны четко определить, какие услуги и системные компоненты входят в область оценки поставщика услуг на соответствие
требованиям PCI DSS, какие требования покрываются поставщиком услуг, а какие находятся в области ответственности его клиентов и
должны быть включены в рамки оценки их собственного соответствия PCI DSS. Например, поставщик услуг управляемого хостинга
должен четко указать, какие IP-адреса просканированы в рамках его ежеквартального сканирования на наличие уязвимостей, и за какие
IP-адреса отвечают клиенты и должны включать их в свои собственные ежеквартальные сканирования.

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

Сторонние поставщики услуг могут подтвердить соответствие требованиям двумя способами:


1) ежегодная оценка: поставщики услуг могут проходить ежегодную оценку (ежегодные оценки) соответствия PCI DSS по своей
инициативе и предоставить подтверждение соответствия своим клиентам, или
2) неоднократные оценки, оценки по запросу: если поставщики услуг не проходят оценку PCI DSS по своей инициативе, они могут
проходить оценки по требованию своих клиентов и (или) быть проверены в рамках каждой оценки соответствия, которую
проходят клиенты данного поставщика услуг, с предоставлением результатов оценки соответствующему клиенту
(соответствующим клиентам).
Если сторонний поставщик услуг проходит оценку соответствия PCI DSS по своей инициативе, он должен представить своим клиентам
достаточное подтверждение того, что его область применимости PCI DSS включает услуги, относящиеся к клиенту, и что выполнение
соответствующих требований PCI DSS были проверено и подтверждено. Конкретный вид подтверждения, которое поставщик услуг
должен предоставить своим клиентам, зависит от действующих соглашений и (или) договоров между этими сторонами. Например,
Свидетельство о соответствии и (или) соответствующие разделы Отчета о соответствии поставщика услуг (отредактированного для
защиты конфиденциальной информации) могут предоставить всю или некоторую информацию.
Дополнительно ТСП и поставщики услуг должны распоряжаться всеми связанными с ними сторонними поставщиками услуг, которые
имеют доступ к ДДК, и отслеживать их статус соответствия PCI DSS. Подробнее см. требование 12.8.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 14
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Передовой опыт по внедрению стандарта PCI DSS в привычные бизнес-
процессы
Для того чтобы обеспечить надлежащую реализацию защитных мер, стандарт PCI DSS должен быть внедрен в привычные бизнес-
процессы в рамках общей стратегии безопасности организации. Это позволит организации постоянно следить за эффективностью
защитных мер и поддерживать среду в соответствии с требованиями PCI DSS в период между оценками соответствия PCI DSS.
Примеры внедрения PCI DSS в привычные бизнес-процессы включают, помимо прочего, следующие действия:
1. Вести мониторинг защитных мер (например, межсетевых экранов, систем обнаружения или предотвращения вторжений, систем
мониторинга целостности файлов, антивирусного ПО, механизмов контроля доступа и т. д.), чтобы обеспечить их эффективную
работу, соответствующую их назначению.
2. Своевременно обнаруживать сбои в работе защитных мер и реагировать на них. Включать следующие действия в процессы
реагирования на сбои защитных мер:
 восстановить защитную меру;
 определить причину сбоя;
 определить и решить любые проблемы с безопасностью, возникшие в период сбоя защитных мер;
 реализовать меры по смягчению последствий, такие как процесс или технические меры, во избежание повторного
возникновения причины сбоя;
 возобновить мониторинг защитной меры, возможно, с временным усилением мониторинга, чтобы проверить, что мера
работает эффективно.
3. Рассматривать изменения среды (например, добавление новых систем, внесение изменений в систему или конфигурацию сети)
до внесения изменений и выполнить следующие действия:
 определять потенциальное воздействие на область оценки PCI DSS (например, новое правило межсетевого экранирования,
разрешающее подключение между системой в среде ДДК и другой системой, может привести к включению дополнительных
систем или сетей в область применимости PCI DSS);
 определять требования PCI DSS, применимые к системам и сетям, на которые распространяются изменения (например,
если новая система входит в область применимости PCI DSS, ее необходимо настроить согласно стандартам конфигурации,
включая мониторинг целостности файлов, антивирусное ПО, обновления, ведение журналов аудита и т. д., и включить в
план ежеквартального сканирования на наличие уязвимостей);
 обновлять область применимости PCI DSS и внедрять необходимые защитные меры.
4. Официально пересматривать влияние на область применимости требований PCI DSS после изменений в организационной
структуре (например, слияния или приобретения компаний).
5. Проводить периодические проверки и опросы, чтобы подтвердить, что требования PCI DSS по-прежнему выполняются, а
работники соблюдают процессы обеспечения безопасности. Такие периодические проверки должны распространяться на все

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 15
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
подразделения и места расположения, в том числе торговые точки, центры обработки данных и т. д. Они должны включать в себя
проверку системных компонентов (или выборок системных компонентов) на предмет того, что требования PCI DSS по-прежнему
выполняются (например, применяются стандарты конфигурации, используются последние обновления и антивирусное ПО,
проводится мониторинг журналов аудита и т. д.). Частота проведения регулярных проверок должна определяться организацией в
соответствии с размером и сложностью ее среды.
Они также могут использоваться, чтобы проверить, что ведутся надлежащие записи, например, журналы аудита, отчеты о
результатах сканирования на наличие уязвимостей, журналы межсетевого экранирования и т. д., чтобы облегчить подготовку
организации к следующей оценке соответствия требованиям.
6. Проверять аппаратные и программные технологии не реже одного раза в год, чтобы убедиться, что вендор продолжает их
поддержку и что они соответствуют требованиям организации к безопасности, включая PCI DSS. Если будет установлено, что
технологии более не поддерживаются вендором или не соответствуют требованиям организации к безопасности, организация
должна подготовить план решения проблемы, при необходимости включающий замену технологий.
Кроме вышеуказанных мер организации также могут принять решение о разделении обязанностей по обеспечению безопасности так,
чтобы функции по обеспечению безопасности и (или) проведению проверок были отделены от операционной деятельности. В средах,
где один работник выполняет несколько обязанностей (например, администрирование и выполнение действий по обеспечению
безопасности), обязанности могут быть распределены таким образом, чтобы ни один работник не обладал полным контролем над
процессом без независимого надзора. Например, за настройку и за утверждение изменений могут отвечать разные лица.

Примечание: для некоторых организаций информация об этом передовом опыте также является
требованиями по непрерывному обеспечению соответствия PCI DSS. Например, эти принципы
включены в некоторые требования PCI DSS, и дополнительная проверка организаций зоны
повышенного риска (Приложение А3 PCI DSS) требует от организаций зоны повышенного риска
проверки выполнения этих принципов.

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 16
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Для аудиторов: выборка подразделений организации и системных компонентов
Выборка позволяет аудиторам облегчить процесс оценки при наличии большого количества подразделений организации и (или)
системных компонентов.
Хотя аудитору разрешается проводить выборку подразделений организации и системных компонентов в рамках проверки организации
на соответствие требованиям PCI DSS, организациям запрещается применять требования PCI DSS только к части своей среды
(например, требования о проведении ежеквартального сканирования на наличие уязвимостей распространяются на все системные
компоненты). Аналогично, аудитору запрещается проверять соответствие только выборке требований PCI DSS.
После того, как аудитор изучил в целом область и сложность оцениваемой среды, он может самостоятельно сделать репрезентативную
выборку подразделений организации и системных компонентов, чтобы оценить соответствие организации требованиям PCI DSS.
Выборка должна быть определена сначала для подразделений организации, а затем для системных компонентов внутри каждого из них.
Выборка должна быть репрезентативной как для всех типов и мест расположения подразделений организации, так и для типов
системных компонентов внутри выбранных подразделений организации. Выборка должна быть достаточно обширной, чтобы аудитор мог
удостовериться в надлежащей реализации защитных мер.
Примеры подразделений организации включают среди прочего: офисы организации, магазины, франчайзинговые предприятия,
процессинговые центры, центры обработки данных и другие типы подразделений с разными местами расположения. В выборку должны
включаться системные компоненты из каждого выбранного подразделения организации. Например, для каждого выбранного
подразделения организации следует включать набор различных ОС, функций и приложений, относящихся к проверяемой области.
Например, аудитор может определить, что выборка внутри подразделения организации должна включать:
— серверы Sun, на которых функционирует Apache,
— Windows-серверы, на которых функционирует СУБД Oracle,
— мейнфреймы, на которых функционируют унаследованные платежные приложения,
— серверы передачи данных под управлением HP-UX,
— Linux-серверы с MySQL.
Если все приложения работают на базе одной версии ОС (например, Windows 7 или Solaris 10), в выборку все же необходимо включать
набор различных приложений (например, серверы базы данных, веб-серверы, серверы передачи данных).
При самостоятельном составлении выборки подразделений организации и системных компонентов аудитор должен учесть следующее:
 выборка может быть меньше, если реализованы стандартизованные и централизованные защитные и операционные процессы и
меры PCI DSS, которые обеспечивают единство подходов и которые должны соблюдаться всеми подразделениями организации
или во всех системных компонентах; выборка должна быть достаточно большой, чтобы предоставить аудитору достаточную
уверенность в том, что все подразделения организации и (или) системные компоненты сконфигурированы в соответствии со

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 17
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
стандартизованными процессами; аудитор должен убедиться в том, что стандартизованные и централизованные защитные меры
реализованы и работают;
 при наличии более одного типа действующих стандартизованных операционных и (или) защитных процессов (например, для
разных типов подразделений организации и (или) системных компонентов) выборка должна быть достаточно большой, чтобы
включать в себя подразделения организации и (или) системные компоненты, привязанные к каждому типу процесса;
 если действующие стандартизованные процессы и меры по соблюдению требований PCI DSS отсутствуют, а управление каждым
подразделением организации и (или) каждым системным компонентом осуществляется с использованием нестандартизованных
процессов, то выборка должна быть больше для того, чтобы аудитор мог убедиться, что в каждом подразделении организации и
в каждом системном компоненте требования PCI DSS выполняются надлежащим образом;
 выборка системных компонентов должна включать каждый используемый тип и сочетание, например, выборка приложений
должна включать все версии и платформы для каждого типа приложений.

Для каждого случая применения выборки аудитор должен:


Также см.: Приложение D:
 документировать обоснование выбранного метода формирования выборки и ее размера; «Сегментация и выборка
подразделений
 документировать и утвердить стандартизованные процессы и механизмы PCI DSS,
организации и (или)
используемые для определения размера выборки;
системных компонентов».
 объяснить, почему сделанная выборка адекватна и репрезентативна для общего количества
элементов.
Аудиторы должны перепроверять обоснование выборки при каждой оценке. Если используется выборка, то для каждой оценки
соответствия должны выбираться разные подразделения организации и системные компоненты.

Компенсационные меры
Аудитор должен ежегодно документировать все компенсационные меры, пересматривать их, утверждать и включать в Отчет о
соответствии согласно Приложению B: «Компенсационные меры» и Приложению С: «Компенсационные меры – Форма для заполнения».
Для каждой отдельно взятой компенсационной меры в обязательном порядке должна быть заполнена форма «Компенсационные меры –
Форма для заполнения» (Приложение C) . Кроме того, результаты применения компенсационных мер должны быть отражены в Отчете о
соответствии в пункте соответствующего требования PCI DSS.
Подробнее о компенсационных мерах см. в вышеупомянутых Приложениях B и C.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 18
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Инструкции и содержание Отчета о соответствии
Инструкции по заполнению и требования к содержанию Отчета о соответствии указаны в Шаблоне отчета о соответствии стандарту
PCI DSS.
Шаблон отчета о соответствии стандарту PCI DSS должен использоваться для создания Отчета о соответствии. Проверяемая
организация должна выполнять соответствующие требования каждой международной платежной системы по предоставлению
подтверждения статуса соответствия. Для получения информации об инструкциях и требованиях по предоставлению подтверждения
статуса соответствия следует обращаться к представителям каждой международной платежной системы или к эквайреру.

Процесс проведения оценки соответствия стандарту PCI DSS


Процесс проведения оценки соответствия стандарту PCI DSS включает выполнение следующих шагов:
1. Подтвердить область оценки соответствия PCI DSS.
2. Провести проверку среды на соответствие PCI DSS, следуя проверочным процедурам для каждого требования.
3. Заполнить соответствующий отчет о проведении оценки (например, Опросный лист для самооценки или Отчет о соответствии),
включая документирование всех компенсационных мер, согласно применимым рекомендациям и инструкциям PCI.
4. Полностью заполнить Свидетельство о соответствии для поставщиков услуг или для ТСП, в зависимости от обстоятельств.
Свидетельства о соответствии доступны на сайте Совета PCI SSC.
5. Предоставить Опросный лист для самооценки или Отчет о соответствии и Свидетельство о соответствии вместе со всей
требуемой документацией – например, отчетом об ASV-сканировании – эквайреру (для ТСП), или международной платежной
системе или другой заинтересованной организации (для поставщиков услуг).
6. При необходимости провести исправление по невыполненным требованиям и предоставить обновленный отчет.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 19
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Версии стандарта PCI DSS
По состоянию на дату публикации данного документа стандарт PCI DSS версии 3.1 действителен до 31 октября 2016 г., после чего он
будет недействителен. Все процедуры подтверждения соответствия стандарту PCI DSS после указанной даты должны проводиться по
стандарту PCI DSS версии 3.2 или более поздних версий.
6
В следующей таблице представлена сводная информация о версиях стандарта PCI DSS и их сроках действия .
Версия Дата публикации Дата окончания действия
Стандарт PCI DSS версии 3.2 (настоящий документ) апрель 2016 г. будет определена позже
Стандарт PCI DSS версии 3.1 апрель 2015 г. 31 октября 2016 г.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 20
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Подробные требования и процедуры оценки безопасности стандарта PCI DSS
В приведенной ниже таблице требований и процедур оценки безопасности стандарта PCI DSS заголовки столбцов означают следующее:
 Требования PCI DSS – в данном столбце определены требования стандарта безопасности данных; соответствие PCI DSS
проверяется по этим требованиям.
 Проверочные процедуры – в данном столбце указаны действия, которые должен выполнить аудитор для проверки выполнения
требований PCI DSS и простановки отметки «Выполнено».
 Пояснение – в данном столбце описано назначение или цель с точки зрения безопасности, преследуемая каждым требованием
PCI DSS. В данном столбце даются только пояснения, которые помогают понять назначение каждого требования. Информация в
этом столбце не заменяет и не дополняет требования и проверочные процедуры PCI DSS.

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

Для получения инструкций по документированию оценки соответствия PCI DSS см. документы (доступные на сайте Совета
PCI SSC):
 инструкции по заполнению Отчета о соответствии в Шаблоне отчета о соответствии стандарту PCI DSS;
 инструкции и рекомендации по заполнению Опросных листов для самооценки в документе Инструкции и рекомендации по
заполнению ОЛС PCI DSS;
 инструкции по заполнению отчетов о подтверждении соответствия стандарту PCI DSS в Свидетельствах о соответствии
стандарту PCI DSS.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 21
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Построить и поддерживать защищенные сети и системы
Требование 1. Установить и поддерживать конфигурацию межсетевых экранов для защиты ДДК.
Межсетевые экраны – это устройства, которые контролируют сетевой трафик, разрешенный между локальными (внутренними) сетями
организации и недоверенными (внешними) сетями, а также которые контролируют входящий и исходящий трафик в зонах повышенной
критичности, находящихся внутри доверенных сетей организации. Среда ДДК является примером зоны повышенной критичности внутри
доверенной локальной сети организации.
Межсетевой экран анализирует весь сетевой трафик и блокирует соединения, которые не удовлетворяют заданным критериям
безопасности.
Все системы должны быть защищены от несанкционированного доступа из недоверенных сетей, будь то подключение систем
электронной торговли к сети через Интернет, доступ работников к Интернету через браузеры, доступ работников к электронной почте,
выделенные подключения со сторонними организациями, подключения по беспроводным сетям или иными способами. Зачастую
кажущиеся малозначимыми каналы связи с недоверенными сетями могут представлять собой незащищенные пути доступа к ключевым
системам. Межсетевые экраны – важнейшие механизмы обеспечения безопасности любой компьютерной сети.
Иные системные компоненты могут обеспечивать функциональные возможности межсетевого экрана, если эти компоненты отвечают
минимальным требованиям к межсетевым экранам, приведенным в Требовании 1. Если иные системные компоненты обеспечивают
функциональные возможности межсетевого экрана в составе среды ДДК, они должны быть включены в область оценки и проверены на
соответствие Требованию 1.

Требования PCI DSS Проверочные процедуры Пояснение


1.1 Разработать и внедрить 1.1 Проверить стандарты конфигурации межсетевых Межсетевые экраны и маршрутизаторы – это
стандарты конфигурации межсетевых экранов и маршрутизаторов, а также иную указанную ниже ключевые компоненты архитектуры, которая
экранов и маршрутизаторов. документацию, на предмет полноты стандартов и их используется для контроля входа в сеть и
Стандарты должны включать в себя: надлежащего внедрения следующим образом: выхода из нее. Эти устройства являются
программным или аппаратным обеспечением,
которое блокирует нежелательный доступ и
управляет санкционированным доступом на
входе в сеть и выходе из нее.
Стандарты конфигурации и процедуры
конфигурирования помогают обеспечить
надежность первой линии обороны
организации в защите ее данных.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 22
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
1.1.1Формализованный процесс 1.1.1.аПроверить документированные процедуры на Документированный и внедренный процесс
утверждения и тестирования всех предмет того, что существует формализованный процесс утверждения и тестирования всех
сетевых соединений и изменений в тестирования и утверждения всех: подключений и изменений межсетевых
конфигурациях межсетевых экранов экранов и маршрутизаторов поможет не
 сетевых соединений;
и маршрутизаторов. допустить возникновения проблем
 изменений в конфигурациях межсетевых экранов и безопасности, связанных с неправильной
маршрутизаторов. настройкой сети, маршрутизатора или
1.1.1.b Для выборки сетевых соединений опросить межсетевого экрана.
ответственных работников и проверить записи на предмет Без формализованного утверждения и
того, что сетевые соединения были протестированы и тестирования изменений записи об
утверждены. изменениях могут не обновляться, что может
привести к несоответствию между сетевой
документацией и реальной конфигурацией.
1.1.1.с Определить выборку реальных изменений,
произведенных в конфигурациях межсетевого экрана и
маршрутизатора, сравнить их с записями об изменениях и
опросить ответственных работников на предмет того, что
изменения были протестированы и утверждены.

1.1.2 Актуальную схему сети, 1.1.2.a Проверить схему (схемы) и конфигурации сети на Схемы сети описывают конфигурацию сетей и
которая указывает все подключения предмет наличия актуальной схемы сети, а также того, что определяют места расположения всех сетевых
между средой ДДК и другими в схеме отмечены все подключения к ДДК и что она устройств.
сетями, включая все беспроводные включает все беспроводные сети. Без актуальных схем сети устройства могут
сети быть пропущены, невольно к ним не будут
1.1.2.b Опросить ответственных работников на предмет
того, что схема поддерживается в актуальном состоянии. применены защитные меры, которые были
внедрены для выполнения требований
стандарта PCI DSS, и таким образом, эти
устройства будут уязвимы к компрометации.

1.1.3 Актуальную схему, 1.1.3 Проверить схему потоков данных и опросить Схемы потоков ДДК определяют расположение
отображающую все потоки ДДК по работников на предмет того, что схема: всех ДДК, которые хранятся, обрабатываются
системам и сетям. или передаются внутри сети.
 отражает все потоки ДДК по системам и сетям;
 поддерживается в актуальном состоянии и Схемы сети и потоков ДДК, демонстрирующие
обновляется, если в среду вносятся изменения. как ДДК перемещаются по сетям и между
отдельными системами и устройствами,
помогают организации получить
представление об области своей среды и
отслеживать ее.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 23
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
1.1.4 Требования о необходимости 1.1.4.a Проверить стандарты конфигурации межсетевого Использование межсетевого экрана на каждом
межсетевого экранирования каждого экрана на наличие требований о необходимости входящем (и исходящем) Интернет-
Интернет-соединения и соединений межсетевого экранирования каждого Интернет- соединении, а также между каждой
между каждой демилитаризованной соединения, а также соединений между каждой демилитаризованной зоной и внутренней
зоной и внутренней сетью. демилитаризованной зоной и внутренней сетью. сетью позволяет организации отслеживать
доступ, контролировать его и свести к
1.1.4.b Убедиться, что актуальная схема сети минимуму возможности злоумышленников на
соответствует стандартам конфигурации межсетевых получение доступа к внутренней сети через
экранов. незащищенное соединение.
1.1.4.c Проверить конфигурации сети на наличие
межсетевого экрана на каждом Интернет-соединении и
между каждой демилитаризованной зоной и внутренней
сетью согласно документированным стандартам
конфигурации и схемам сети.

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

1.1.6 Документирование служебного 1.1.6.a Убедиться, что стандарты конфигурации Зачастую компрометация происходит из-за
обоснования и утверждение для межсетевых экранов и маршрутизаторов содержат наличия неиспользуемых или небезопасных
использования всех разрешенных документированный перечень всех служб, протоколов и служб и портов, поскольку они часто содержат
служб, протоколов и портов, а также портов, обоснование служебной необходимости и известные уязвимости, и многие организации
документация по реализованным утверждение каждого из них. не устанавливают обновления для
средствам защиты тех протоколов, уязвимостей служб, протоколов и портов,
которые признаны небезопасными. 1.1.6.b Выявить разрешенные небезопасные службы, которые не используются этими
протоколы и порты и проверить документальное организациями (даже при наличии таких
оформление средств защиты для каждой службы. уязвимостей). Четкое определение и
1.1.6.с Проверить конфигурацию межсетевых экранов и документальное оформление служб,
маршрутизаторов на предмет того, что протоколов и портов, необходимых для
документированные средства защиты внедрены для осуществления деятельности, позволяет
каждой небезопасной службы, протокола и порта. организациям обеспечить отключение или
удаление всех остальных служб, протоколов и
портов.
Утверждение должно предоставляться

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 24
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
работниками, независимыми от работников,
которые осуществляют конфигурирование.
Если небезопасные службы, протоколы или
порты необходимы для осуществления
деятельности, организация должна четко
понимать и принимать риск, связанный с их
использованием, обосновать необходимость
их использования, а также документировать и
внедрить средства защиты, которые позволят
безопасно использовать эти протоколы. Если
эти небезопасные службы, протоколы или
порты не являются необходимыми для
осуществления деятельности, их следует
отключить или удалить.
За пояснениями по службам, протоколам и
портам, считающимися небезопасными,
обращайтесь к отраслевым стандартам и
руководствам (например, NIST, ENISA, OWASP
и другие).

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 25
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
1.2 Создать конфигурации 1.2 Проверить конфигурацию межсетевых экранов и Необходимо установить защиту сети между
межсетевых экранов и маршрутизаторов и выполнить следующие действия, чтобы внутренней доверенной сетью и любой
маршрутизаторов, которые убедиться, что соединения между недоверенными сетями и недоверенной внешней сетью и (или) сетью,
ограничивают соединения между системными компонентами, находящимися в среде ДДК, которая не находится под контролем
недоверенными сетями и любыми ограничены: организации. Если данная мера будет
системными компонентами в среде реализована некорректно, организация будет
ДДК. уязвима к несанкционированному доступу со
стороны злоумышленников или вредоносного
Примечание: недоверенной
ПО.
является любая сеть, внешняя по
отношению к сетям, Для того чтобы межсетевой экран
принадлежащим проверяемой действительно выполнял свои функции, его
организации и (или) сеть, которая необходимо должным образом
не находится ни под контролем, ни сконфигурировать так, чтобы он
под управлением проверяемой контролировал и (или) ограничивал входящий
организации. и исходящий трафик в сети организации.

1.2.1 Ограничить входящий и 1.2.1.а Проверить стандарты конфигурации межсетевого Изучение всех входящих и исходящих
исходящий трафик только теми экрана и маршрутизатора на предмет того, что они соединений позволяет проверять и
соединениями, которые необходимы определяют входящий и исходящий трафик, необходимый ограничивать трафик по адресу источника
для среды ДДК. Весь остальной для среды ДДК. и (или) адресу назначения, тем самым
трафик должен быть явным образом предотвращая нефильтрованный доступ
запрещен. 1.2.1.b Проверить конфигурации межсетевого экрана и между недоверенными и доверенными
маршрутизатора на предмет того, что входящий и средами. Этопредотвращает доступ
исходящий трафик ограничен только тем трафиком, злоумышленников к сети организации с
который необходим для среды ДДК. несанкционированных IP-адресов или с
1.2.1.с Проверить конфигурации межсетевого экрана и использованием служб, протоколов или портов
маршрутизатора на предмет того, что весь прочий несанкционированным способом (например,
входящий и исходящий трафик явным образом запрещен, для отправки на недоверенный сервер данных,
например, путем явного запрета "deny all" или неявного которые злоумышленники получили из сети
запрета по умолчанию после разрешающих правил. организации).
Установка запрета на весь входящий и
исходящий трафик, кроме явно необходимого,
помогает предотвратить возникновение
непреднамеренных брешей, которые делают
возможным несанкционированный и
потенциально вредоносный входящий или
исходящий трафик.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 26
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
1.2.2 Обеспечить безопасность и 1.2.2.a Проверить конфигурационные файлы В то время как рабочие (или активные)
синхронизацию конфигурационных маршрутизаторов на предмет того, что они защищены от конфигурационные файлы включают текущие
файлов маршрутизаторов. несанкционированного доступа. безопасные настройки, в файлы стартовой
конфигурации (используемые
1.2.2.b Проверить конфигурации маршрутизаторов на маршрутизаторами при перезапуске или
предмет того, что они синхронизированы, например, что загрузке) необходимо внести те же самые
рабочий (или активный) и стартовый (используемый при безопасные настройки для их применения при
загрузке устройств) конфигурационные файлы совпадают. каждом запуске.
Поскольку они выполняются только время от
времени, о стартовых конфигурационных
файлах часто забывают и не обновляют их.
Если маршрутизатор выполняет перезапуск и
загружает стартовую конфигурацию без
безопасных настроек, которые имелись в
рабочем конфигурационном файле, это может
привести к применению менее безопасных
правил, и этим могут воспользоваться
злоумышленники для проникновения в сеть.

1.2.3 Установить пограничные 1.2.3.а Проверить конфигурации межсетевых экранов и Санкционированное (или
межсетевые экраны между каждой маршрутизаторов на предмет того, что межсетевые несанкционированное) внедрение и
беспроводной сетью и средой ДДК и экраны установлены на периметре между всеми использование беспроводных технологий в
настроить их так, чтобы они беспроводными сетями и средой ДДК. сети часто приводит к тому, что
блокировали любой трафик, либо злоумышленники получают доступ к сети и
разрешали только авторизованный 1.2.3.b Убедиться, что межсетевые экраны настроены так, ДДК. Если беспроводное устройство или сеть
трафик – если такой трафик чтобы блокировать любой трафик, либо разрешать только установлены без ведома организации,
необходим в служебных целях – авторизованный трафик – если такой трафик необходим в злоумышленник может просто и незаметно
между беспроводной сетью и служебных целях – между беспроводной сетью и средой проникнуть в сеть. Если межсетевые экраны не
средой ДДК. ДДК. ограничивают доступ из беспроводной сети к
среде ДДК, злоумышленники, которые
получили несанкционированный доступ к
беспроводной сети, могут без труда
подключиться к среде ДДК и
скомпрометировать данные платежных карт.
Межсетевые экраны должны быть
установлены между всеми беспроводными
сетями и средой ДДК независимо от
назначения среды, к которой подключена
беспроводная сеть. Это могут быть, среди
прочего, корпоративные сети, розничные
Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 27
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
магазины, гостевые сети, склады и т. д.

1.3 Запретить прямой публичный 1.3 Проверить конфигурацию межсетевых экранов и Могут быть легитимные основания для
доступ между сетью Интернет и маршрутизаторов, включая, помимо прочего, разрешения недоверенных соединений с
любым системным компонентом в маршрутизатор на границе с сетью Интернет, системными компонентами, расположенными в
среде ДДК. маршрутизатор и межсетевой экран демилитаризованной демилитаризованной зоне (DMZ) (например,
зоны, демилитаризованную зону сегмента с ДДК, чтобы разрешить публичный доступ к веб-
маршрутизатор на периметре и внутренний сегмент сети с серверу), однако, такие соединения не могут
ДДК. Проделать следующие действия, чтобы убедиться, что быть разрешены системным компонентам во
прямой доступ отсутствует между сетью Интернет и внутренней сети. Назначение межсетевого
системными компонентами внутреннего сегмента сети с экрана состоит в управлении и контроле всех
ДДК: соединений между общедоступными
системами и внутренними системами,
особенно теми, которые используются для
хранения, обработки или передачи ДДК. Если
разрешен прямой доступ между
общедоступными системами и средой ДДК,
реализуемая межсетевым экраном защита
обходится, и системные компоненты,
хранящие ДДК, могут стать уязвимыми к
компрометации.

1.3.1 Реализовать 1.3.1Проверить конфигурации межсетевых экранов и Демилитаризованная зона – это часть сети,
демилитаризованную зону таким маршрутизаторов на предмет того, что которая управляет соединениями между сетью
образом, чтобы ограничить демилитаризованная зона реализована таким образом, Интернет (или другими недоверенными
входящий трафик только теми чтобы входящий трафик был ограничен только теми сетями) и службами, к которым у организации
системными компонентам, которые системными компонентами, которые обеспечивают работу есть необходимость предоставить публичный
обеспечивают работу разрешенных разрешенных общедоступных служб, протоколов и портов. доступ (такими как веб-сервер).
общедоступных служб, протоколов и Такие функциональные возможности
портов. предназначены для предотвращения доступа
1.3.2 Ограничить входящий 1.3.2 Проверить конфигурации межсетевого экрана и злоумышленников к внутренней сети
интернет-трафик IP-адресами, маршрутизатора на предмет того, что входящий интернет- организации из Интернета и использования
находящимися в трафик ограничен IP-адресами, находящимися в служб, протоколов или портов
демилитаризованной зоне. демилитаризованной зоне. несанкционированным образом.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 28
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
1.3.3 Реализовать меры, которые 1.3.3 Проверить конфигурации межсетевых экранов и Обычно пакет содержит IP-адрес компьютера,
противодействуют подмене IP- маршрутизаторов на предмет того, что в них реализованы который его отправил. Это позволяет другим
адреса благодаря тому, что меры, которые противодействуют подмене IP-адреса компьютерам в сети узнать, откуда был
позволяют определить фальшивые (например, пакеты с внутренними адресами не могут отправлен пакет. Злоумышленники часто
исходные IP-адреса и блокируют им попасть в демилитаризованную зону из сети Интернет). пытаются подменить (или имитировать) IP-
доступ в сеть адрес отправителя так, чтобы система-
(например, блокируют трафик из получатель сочла, что пакет пришел из
сети Интернет, в котором в качестве доверенного источника.
адреса источника указан внутренний Фильтрация входящих пакетов позволяет,
адрес). помимо прочего, предотвратить подмену IP-
адресов (имитацию адреса внутренней сети
организации для пакета).

1.3.4 Запретить 1.3.4 Проверить конфигурации межсетевых экранов и Весь трафик, исходящий из среды ДДК,
несанкционированный исходящий маршрутизаторов на предмет того, что исходящий трафик должен быть проверен на предмет его
трафик из среды ДДК в сеть из среды ДДК в сеть Интернет явно авторизован. соответствия установленным и утвержденным
Интернет. правилам. Соединения должны быть
проверены на предмет того, что трафик
ограничивается только разрешенными
соединениями (например, через ограничение
адресов (портов) источника или назначения и
(или) блокировку содержимого).

1.3.5 Разрешено пропускать в сеть 1.3.5 Проверить конфигурации межсетевых экранов и Межсетевой экран, отслеживающий состояние
пакеты только для установленных маршрутизаторов на предмет того, что межсетевой экран каждого соединения, проходящего через него,
(“established”) соединений. разрешает прохождение пакетов во внутреннюю сеть знает, являются ли пакеты, которые выглядят
только для установленных соединений и отклоняет любые как ответ на предыдущее соединение,
входящие соединения, если они не относятся к действительным авторизованным ответом
предварительно установленной сессии. (поскольку он хранит информацию о состоянии
каждого соединения) или же это попытка
вредоносного трафика обойти межсетевой
экран, чтобы он разрешил соединение.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 29
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
1.3.6 Размещать системные 1.3.6 Проверить конфигурации межсетевых экранов и Если ДДК размещены в демилитаризованной
компоненты, в которых хранятся маршрутизаторов на предмет того, что системные зоне, внешнему злоумышленнику проще
ДДК (например, базы данных), во компоненты, в которых хранятся ДДК, располагаются во получить эту информацию, поскольку ему
внутреннем сегменте сети, внутреннем сегменте сети, отделенном от нужно будет преодолеть меньшее количество
отделенном от демилитаризованной демилитаризованной зоны (DMZ) и иных недоверенных уровней защиты. Защита системных
зоны и иных недоверенных сетей. сетей. компонентов, которые хранят ДДК, во
внутреннем сегменте сети, отделенном от
демилитаризованной зоны и иных
недоверенных сетей межсетевым экраном,
может предотвратить попадание
несанкционированного сетевого трафика в
системный компонент.
Примечание: это требование не
распространяется на временное хранение
ДДК в энергозависимой памяти.
1.3.7 Не раскрывать частные IP- 1.3.7.a Проверить конфигурации межсетевых экранов и Ограничение передачи внутренних или
адреса и информацию о маршрутизаторов на предмет того, что внедрены методы, частных IP-адресов необходимо для того,
маршрутизации сторонам, не исключающие раскрытие частных IP-адресов и данных о чтобы злоумышленник не имел возможности
имеющим санкционированного маршрутизации из внутренней сети в сеть Интернет. изучить IP-адреса внутренней сети и
доступа к такой информации. использовать эту информацию для получения
доступа к сети.
Примечание: методы сокрытия IP-
адресации включают, среди прочего: Средства, используемые для соблюдения
 преобразование сетевых адресов 1.3.7.b Опросить работников и проверить документацию этого требования, могут зависеть от
(NAT); на предмет того, что любое раскрытие частных IP-адресов конкретной используемой сетевой технологии.
и данных о маршрутизации является санкционированным. Например, меры, принятые для выполнения
 размещение серверов,
содержащих ДДК, за прокси- данного требования, могут отличаться для
серверами и (или) межсетевыми сетей IPv4 и сетей IPv6.
экранами;
 удаление или фильтрацию
объявлений о маршрутах для
частных сетей, использующих
открытое адресное
пространство для
зарегистрированных сетей;
 внутреннее использование
адресного пространства
согласно RFC1918 вместо
адресного пространства для
зарегистрированных сетей.
Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 30
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
1.4 Установить программные 1.4.a Проверить политики и стандарты конфигурации на Переносные вычислительные устройства,
персональные межсетевые экраны предмет того, что: которым разрешено подключаться к сети
или иную реализацию аналогичной Интернет из сети, являющейся внешней по
 программные персональные межсетевые экраны или их
функциональности на все аналоги требуются на всех портативных отношению к межсетевому экрану
портативные вычислительные вычислительных устройствах, в том числе организации, более уязвимы к Интернет-
устройства (например, используемые принадлежащих организации и (или) работникам, угрозам. Использование функциональности
работниками ноутбуки), которые при которые при нахождении вне сети подключены к сети межсетевого экрана (например, программного
нахождении вне сети подключены к Интернет (например, используемые работниками или аппаратного персонального межсетевого
сети Интернет и которые также ноутбуки) и которые также используются для доступа к экрана) помогает защитить устройства от
используются для доступа к среде среде ДДК. Интернет-атак, которые могут использовать
ДДК. Требования к конфигурациям  определены конкретные настройки конфигурации для устройство для получения доступа к системам
межсетевых экранов или их аналогов: персональных межсетевых экранов (или их аналогов); и данным организации после повторного
подключения устройства к сети.
 определены конкретные настройки  персональные межсетевые экраны (или их аналоги)
конфигурации; настроены на то, чтобы быть запущенными; Организация сама определяет конкретные
 персональные межсетевые экраны  настройки персональных межсетевых экранов (или их настройки конфигурации для персональных
(или их аналоги) запущены; аналогов) не поддаются изменениям со стороны межсетевых экранов.
 настройки персональных пользователей портативных вычислительных устройств. Примечание: это требование применяется к
межсетевых экранов (или их 1.4.b Проверить выборку принадлежащих организации портативным вычислительным
аналогов) не поддаются и (или) работникам устройств на предмет того, что: устройствам, принадлежащим работникам
изменениям со стороны или организации. Системы, которыми
пользователей портативных  персональные межсетевые экраны (или их аналоги)
установлены и сконфигурированы согласно конкретным невозможно управлять с помощью
вычислительныхустройств.
конфигурационным настройкам организации; корпоративных политик, представляют
собой уязвимые места и дают
 персональные межсетевые экраны (или их аналоги)
злоумышленникам возможности, которыми
запущены;
те могут воспользоваться. Разрешая
 настройки персональных межсетевых экранов (или их
недоверенным системам подключаться к
аналогов) не поддаются изменениям со стороны
среде ДДК организации, можно предоставить
пользователей портативных вычислительных устройств.
доступ атакующим и прочим
злоумышленникам.

1.5 Гарантировать, что политики 1.5 Проверить документацию и опросить работников на Работники должны знать и соблюдать
безопасности и рабочие процедуры предмет того, что политики безопасности и рабочие политики безопасности и рабочие процедуры,
управления межсетевыми экранами процедуры управления межсетевыми экранами: чтобы обеспечить постоянное управление
документированы, используются и межсетевыми экранами и маршрутизаторами
 документированы;
известны всем заинтересованным во избежание несанкционированного доступа к
 используются;
лицам. сети.
 известны всем заинтересованным лицам.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 31
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требование 2. Не использовать пароли к системам и другие параметры безопасности по умолчанию, заданные
производителем.
Злоумышленники (внешние и внутренние по отношению к организации) часто используют для компрометации систем пароли и иные
параметры по умолчанию, заданные производителем. Эти пароли и параметры хорошо известны в сообществах хакеров, и их легко
получить из открытых источников.

Требования PCI DSS Проверочные процедуры Пояснение


2.1 Всегда изменять параметры по 2.1.а Сделать выборку системных компонентов и (с Злоумышленники (внешние и внутренние по
умолчанию, заданные помощью системного администратора) попытаться отношению к организации) часто используют
производителями, а также удалять осуществить вход в устройства и приложения, используя настройки, учетные записи и пароли по
или отключать неиспользуемые учетные записи и пароли по умолчанию, устанавливаемые умолчанию, заданные производителем, для
учетные записи по умолчанию перед производителем, чтобы проверить, что ВСЕ пароли по компрометации операционных систем,
установкой систем в сети. умолчанию (включая пароли к операционным системам, приложений и устройств, на которых они
Это требование применимо ко ВСЕМ защитному программному обеспечению, учетным записям установлены. Поскольку эти настройки по
паролям по умолчанию, включая, в приложений и системным учетным записям, POS- умолчанию хорошо известны и часто
том числе, пароли к операционным терминалам, а также строки доступа SNMP) были публикуются в хакерских сообществах, их
системам, защитному программному изменены. (Используйте руководства от вендоров и изменение снизит уязвимость систем к атакам.
обеспечению, учетным записям Интернет-ресурсы, чтобы узнать учетные записи и пароли Даже если не планируется использовать
приложений и системным учетным по умолчанию, устанавливаемые производителем). учетную запись по умолчанию, изменение
записям, POS-терминалам 2.1.b Проверить выборку системных компонентов на пароля по умолчанию на надежный
(терминалы в точках продаж), предмет того, что все неиспользуемые учетные записи по уникальный пароль и последующее
платежным приложениям, а также умолчанию (включая учетные записи к операционным отключение учетной записи не позволит
строкам доступа SNMP и т. д. системам, POS-терминалам, защитному программному злоумышленнику повторно включить ее и
обеспечению, приложениям, устройствам, а также строки получить доступ с помощью пароля по
доступа SNMP и т. д.) удалены или отключены. умолчанию.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 32
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
2.1.с Опросить работников и проверить сопроводительную
документацию на предмет того, что:
 все учетные данные по умолчанию, заданные
производителем (включая пароли по умолчанию к
операционным системам, POS-терминалам, защитному
программному обеспечению, приложениям и системным
учетным записям, а также строки доступа SNMP и т. д.)
изменяются перед установкой системы в сети;
 неиспользуемые учетные записи, настроенные по
умолчанию, (включая учетные записи к операционным
системам, POS-терминалам, защитному программному
обеспечению, приложениям и системным учетным
записям, а также строки доступа SNMP и т. д.)
удаляются или отключаются перед установкой системы
в сети.
2.1.1 Для беспроводных окружений, 2.1.1.а Опросить ответственных работников и проверить Если беспроводные сети реализованы без
которые подключены к среде ДДК сопроводительную документацию на предмет того, что: использования достаточно безопасных
либо передают ДДК, необходимо конфигураций (включая изменение настроек по
 установленные по умолчанию ключи шифрования
изменить ВСЕ параметры по умолчанию), анализаторы беспроводных сетей
были изменены при установке;
умолчанию, заданные могут прослушивать трафик, без труда
производителем, включая, помимо  ключи шифрования заменяются каждый раз, когда извлекать пароли и данные, а также легко
прочего, ключи шифрования для любое лицо, знающее данные ключи, увольняется из проникать в сеть и атаковать ее.
доступа к беспроводной сети, организации либо переходит на другую должность.
Кроме того, протокол обмена ключами для
пароли, строки доступа SNMP. 2.1.1.b Опросить работников и проверить политики и ранних версий протокола шифрования 802.11x
процедуры на предмет того, что: (Wired Equivalent Privacy, WEP) был взломан, и
 при установке требуется изменение строк доступа может сделать шифрование бесполезным.
SNMP по умолчанию; Микропрограммное обеспечение для устройств
следует обновить для поддержки более
 при установке требуется изменение паролей и (или)
защищенных протоколов.
парольных фраз по умолчанию к точкам доступа.
2.1.1.c Проверить документацию вендора и выполнить
вход на беспроводные устройства при содействии
системного администратора, чтобы подтвердить, что:
 не используются строки доступа SNMP по
умолчанию;
 не используются пароли и (или) парольные фразы по
умолчанию к точкам доступа.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 33
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
2.1.1.d Проверить документацию вендора и настройки
беспроводной конфигурации на предмет того, что
микропрограммное обеспечение беспроводных устройств
обновлено для того, чтобы поддерживать стойкие
алгоритмы шифрования для:
 аутентификации в беспроводных сетях;
 передачи данных по беспроводным сетям.
2.1.1.e Проверить документацию вендора и настройки
беспроводной конфигурации на предмет того, что прочие
настройки безопасности по умолчанию, заданные
производителем в беспроводных устройствах, были
изменены, если это применимо.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 34
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
2.2 Разработать стандарты 2.2.a Проверить стандарты конфигурации организации для У многих операционных систем, баз данных и
конфигурации для всех системных всех типов системных компонентов на предмет того, что эти корпоративных приложений существуют
компонентов. Убедиться в том, что стандарты согласуются с требованиями отраслевых известные уязвимости, а также известные
стандарты учитывают все известные стандартов безопасной настройки систем. способы настройки данных систем для
уязвимости, а также согласуются с устранения этих уязвимостей. Чтобы помочь
положениями отраслевых стандартов 2.2.b Проверить политики и опросить работников на лицам, которые не являются экспертами в
безопасной настройки систем. предмет того, что стандарты конфигурации обновляются по области безопасности, некоторые
мере обнаружения новых уязвимостей в соответствии с организации, специализирующиеся в области
Например, к источникам требованием 6.1.
общепринятых отраслевых информационной безопасности,
стандартов по безопасной настройке 2.2.с Проверить политики и опросить работников на предоставляют рекомендации по безопасной
систем относятся, среди прочих: предмет того, что стандарты конфигурации применяются настройке систем и устранению уязвимостей.
при настройке новых систем, и что перед установкой К примерам источников, где можно найти
 Центр Интернет-безопасности
системы в сети выполняется проверка, что стандарты рекомендации по стандартам настройки,
(CIS);
конфигурации выполнены. относятся среди прочих: www.nist.gov,
 Международная организация по
www.sans.org, www.cisecurity.org, www.iso.org, а
стандартизации (ISO); 2.2.d Проверить стандарты системной конфигурации на также веб-сайты вендоров.
 Институт системного наличие следующих процедур для всех типов системных
администрирования, aудита, компонентов: Стандарты конфигурации должны быть
cетевых технологий и проблем актуальными, чтобы гарантировать, что
 изменить все параметры по умолчанию, заданные недавно обнаруженные уязвимости
безопасности (SANS);
производителем, и исключить неиспользуемые учетные устраняются до установки системы в сети.
 Национальный институт записи по умолчанию;
стандартов и технологий (NIST).
 реализовать на каждом сервере только одну основную
функцию для того, чтобы исключить совмещение на
одном и том же сервере функций, требующих
различных уровней безопасности;
 включать только необходимые службы, протоколы,
управляющие программы и т. д., требующиеся для
функционирования системы;
 реализовать дополнительные защитные меры для
любых необходимых служб, протоколов и управляющих
программ, которые признаны небезопасными;
 настроить параметры безопасности системы таким
образом, чтобы исключить возможность ее
некорректного использования;
 удалить все неиспользуемые функциональные
возможности, такие как, скрипты, драйверы, функции,
подсистемы, файловые системы, а также
неиспользуемые веб-серверы.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 35
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
2.2.1Реализовать на каждом сервере 2.2.1.a Сделать выборку системных компонентов и Если функции, для которых необходим разный
только одну основную функцию во проверить системные конфигурации на предмет того, что уровень безопасности, расположены на одном
избежание совмещения на одном и выполняется правило «один сервер — одна основная сервере, уровень безопасности функций с
том же сервере функций, требующих функция». более высокими требованиями к безопасности
различных уровней защиты. будет понижен ввиду наличия функций с более
(Например, веб-серверы, серверы 2.2.1.b Если используются технологии виртуализации, низким уровнем безопасности. Кроме того,
баз данных и DNS-серверы следует проверить системные конфигурации на предмет того, что функции с более низким уровнем безопасности
размещать на разных серверах). на одном виртуальном системном компоненте или могут содержать уязвимости для безопасности
устройстве реализована только одна основная функция. других функций того же сервера. Путем
Примечание: при использовании
рассмотрения требований к безопасности
технологии виртуализации,
разных функций сервера в стандартах
необходимо реализовывать только
конфигураций и относящихся к ним процессах,
одну основную функцию для каждого
организации могут убедиться в отсутствии
виртуального системного
функций с разными уровнями безопасности на
компонента.
одном сервере.

2.2.2 Включать только необходимые 2.2.2.a Сделать выборку системных компонентов и Как сказано в требовании 1.1.6, существует
службы, протоколы, управляющие проверить включенные службы, управляющие программы много протоколов, которые могут быть
программы и т. д., требующиеся для и протоколы на предмет того, что включены только необходимы для работы (или включены по
функционирования системы. необходимые службы или протоколы. умолчанию) и которые обычно используются
злоумышленниками для компрометации сети.
2.2.2.b Выявить любые включенные небезопасные Включение этого требования в стандарты
службы, управляющие программы и протоколы, и конфигурации и относящиеся к ним процессы
опросить работников на предмет того, что использование организации гарантирует, что будут включены
таких служб, управляющих программ и протоколов только необходимые службы и протоколы.
обосновано в документированных стандартах
конфигурации.

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 36
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
используется SSL и (или) ранние 2.2.3.b Если используется SSL и (или) ранние версии TLS, затруднит злоумышленникам использование
версии TLS, требования, описанные выполнить проверочные процедуры, описанные в распространенных уязвимостей через сеть.
в Приложении А2, должны быть Приложении А2: Дополнительные требования PCI DSS Для получения информации о стойкой
выполнены. для организаций, использующих SSL и (или) ранние криптографии и безопасных протоколах
версии TLS. необходимо обратиться к отраслевым
стандартам и передовому опыту (например,
NIST SP 800-52 и SP 800-57, OWASP и т.д.).

2.2.4 Настроить параметры 2.2.4.a Опросить системных администраторов и (или) Стандарты конфигурации и относящиеся к ним
безопасности системы таким администраторов безопасности на предмет того, что им процессы должны явным образом учитывать
образом, чтобы исключить известны настройки основных параметров безопасности настройки и параметры безопасности, которые
возможность некорректного системных компонентов. несут в себе известные последствия для
использования системы. безопасности каждого типа используемой
2.2.4.b Проверить стандарты конфигурации на предмет системы.
того, что они включают основные параметры
безопасности. Чтобы обеспечить безопасную настройку
систем, работники, отвечающие за настройку
2.2.4.c Сделать выборку системных компонентов и и (или) администрирование систем, должны
проверить основные параметры безопасности на предмет быть осведомлены о конкретных параметрах
того, что они выставлены надлежащим образом и безопасности и настройках, применимых к
согласно стандартам конфигурации. системе.

2.2.5 Удалить все неиспользуемые 2.2.5.a Сделать выборку системных компонентов и Неиспользуемые функции могут предоставить
функциональные возможности, проверить конфигурации на предмет того, что злоумышленникам дополнительные
например, скрипты, драйверы, неиспользуемые функциональные возможности возможности для получения доступа к
функции, подсистемы, файловые (например, скрипты, драйверы, функции, подсистемы, системе. Благодаря удалению
системы, а также неиспользуемые файловые системы и т. д.) удалены. неиспользуемых функциональных
веб-серверы. возможностей, организация может
2.2.5.b Проверить документацию и параметры сконцентрироваться на защите требуемых
безопасности на предмет того, что включенные функции функций и снизить риск злоупотребления
документированы и поддерживают безопасную неизвестными функциями.
конфигурацию.
Включение этого требования в стандарты и
2.2.5.c Проверить документацию и параметры процессы безопасной настройки обрабатывает
безопасности на предмет того, что в выборке системных последствия для безопасности, связанные с
компонентов присутствуют только документированные неиспользуемыми функциями (например,
функциональные возможности. удаление и (или) отключение FTP- или веб-
сервера, если сервер не будет выполнять
такие функции).

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 37
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
2.3 При использовании любого 2.3 Сделать выборку системных компонентов и проверить, Если при неконсольном (в т. ч. удаленном)
неконсольного административного что канал неконсольного административного доступа администрировании не используются
доступа к системе всегда шифровать зашифрован следующим образом: безопасная аутентификация и шифрование
канал с использованием стойкой канала, существует возможность перехвата
криптографии. 2.3.a Проследить за входом администратора в каждую злоумышленником критичной информации
систему и проверить системные конфигурации на (например, идентификаторов и паролей
Примечание: в случаях, когда предмет того, что метод стойкого шифрования
используется SSL и (или) ранние администратора). Злоумышленник может
применяется до запроса пароля администратора. использовать эту информацию для получения
версии TLS, требования, описанные
в Приложении А2, должны быть 2.3.b Проверить службы и файлы параметров на доступа к сети, получения прав
выполнены. системах на предмет того, что Telnet и другие администратора и кражи данных.
небезопасные протоколы удаленного доступа к системе Незашифрованные протоколы (например,
недоступны для неконсольного доступа. HTTP, Тelnet и т. д.) передают трафик или
аутентификационные данные в открытом виде,
2.3.c Проследить за входом администратора в каждую
упрощая перехват этой информации
систему на предмет того, что административный доступ к злоумышленником.
любому веб-интерфейсу управления проходит
шифрование с использованием стойкой криптографии. Для того чтобы криптография была признана
стойкой, следует применять признанные в
2.3.d Ознакомиться с документацией вендора и опросить отрасли протоколы с надлежащей стойкостью
работников на предмет того, что для используемых ключей и процессы управления ключами,
технологий используется стойкая криптография, и что она соответствующие типу используемой
внедрена в соответствии с передовым опытом и (или) технологии. (См. определение термина
рекомендациями вендоров. «стойкая криптография» в документе
Глоссарий. Основные определения,
2.3.е Если используется SSL и (или) ранние версии TLS, аббревиатуры и сокращения стандартов PCI
выполнить проверочные процедуры, описанные в DSS и PA-DSS, а также отраслевые стандарты
Приложении А2: Дополнительные требования PCI DSS и передовой опыт, такие как NIST SP 800-52 и
для организаций, использующих SSL и (или) ранние SP 800-57, OWASP и т.д.).
версии TLS.

2.4Вести учет системных компонентов, 2.4.a Проверить системный учет на предмет того, что Благодаря ведению текущего списка всех
на которые распространяется поддерживается список программных и аппаратных системных компонентов, организация может
действие стандарта PCI DSS. компонентов, включающий описание функции и (или) точно и эффективно определять область
применения для каждого из них. своей среды для внедрения защитных мер
PCI DSS. Без такого учета некоторые
2.4.b Опросить работников на предмет того, что учетная системные компоненты могут быть забыты или
документация поддерживается в актуальном состоянии. случайно исключены из стандартов
конфигурации организации.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 38
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
2.5 Гарантировать, что политики 2.5 Проверить документацию и опросить работников на Работники должны быть ознакомлены с
безопасности и операционные предмет того, что политики безопасности, операционные политиками безопасности и повседневными
процедуры управления параметрами процедуры управления параметрами по умолчанию, операционными процедурами, а также
по умолчанию, заданными заданными производителями, и другими параметрами соблюдать их, чтобы обеспечить постоянный
производителями, и другими безопасности: контроль над параметрами по умолчанию,
параметрами безопасности заданными производителями, и другими
 документированы;
документированы, используются и параметрами безопасности и исключить
 используются;
известны всем заинтересованным небезопасные конфигурации.
лицам.  известны всем заинтересованным лицам.

2.6 Поставщики услуг хостинга с 2.6 Выполнить проверочные процедуры A.1.1–A.1.4, Данное требование предназначено для
общей средой должны защищать описанные в Приложении А1: «Дополнительные поставщиков услуг хостинга, которые
среды и ДДК каждой организации, требования PCI DSS для поставщиков услуг хостинга с предоставляют общие среды размещения для
размещенные на хостинге. Эти общей средой», для оценки соответствия таких нескольких клиентов на одном и том же
поставщики должны соответствовать поставщиков требованиям PCI DSS, чтобы проверить, что сервере. Когда все данные находятся на
особым требованиям, описанным в данные поставщики защищают размещенные у них среду и одном и том же сервере и под управлением
Приложении A1: «Дополнительные данные организаций (ТСП и поставщиков услуг). единой среды, отдельные клиенты обычно не
требования PCI DSS для имеют возможности управлять настройками
поставщиков услуг хостинга с общей этих совместно используемых серверов. Это
средой». позволяет клиентам добавлять небезопасные
функции и скрипты, которые влияют на
безопасность сред всех остальных клиентов, и
таким образом, злоумышленник может,
получив доступ к данным одного клиента,
скомпрометировать данные всех остальных
клиентов. См. подробные сведения о
требованиях в Приложении A1.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 39
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Защищать ДДК
Требование 3. Защищать хранимые ДДК
Такие методы защиты, как шифрование, усечение, маскирование и хеширование являются важнейшими компонентами защиты ДДК.
Если злоумышленник обходит иные защитные меры и получает доступ к зашифрованным данным без надлежащего криптографического
ключа, то эти данные остаются для злоумышленника нечитаемыми и непригодными для использования. Иные эффективные методы
защиты хранимых данных также следует рассматривать как потенциальные возможности снижения риска. Например, методы
минимизации риска включают в себя отказ от хранения ДДК, кроме случаев крайней необходимости, усечение ДДК, если полный PAN не
требуется, и отказ от передачи PAN в незащищенном виде с использованием технологий обмена сообщениями для конечных
пользователей, таких как электронная почта и системы мгновенного обмена сообщениями.
См. «Глоссарий. Основные определения, аббревиатуры и сокращения стандартов PCI DSS и PA-DSS» для определения термина
«Стойкая криптография» и других терминов PCI DSS.

Требования PCI DSS Проверочные процедуры Пояснение


3.1 Свести хранение ДДК к минимуму 3.1.а Проверить политики, процедуры и процессы хранения Официальная политика хранения данных
с помощью политик, процедур и и уничтожения данных на предмет наличия в них определяет, какие данные необходимо
процессов хранения и уничтожения следующих требований для всех хранилищ ДДК: хранить и где находятся эти данные, чтобы их
данных, в которые включены, как можно было безопасно уничтожить или
 ограничение количества хранимых данных и сроков
минимум, следующие требования для хранения до значений, необходимых для выполнения удалить, когда они больше не требуются.
всех хранилищ ДДК: законодательных, нормативных и (или) служебных После авторизации разрешается хранить
 ограничение количества хранимых требований; только номер карты (PAN) (приведенный в
данных и сроки хранения до  конкретные требования к хранению ДДК (например, ДДК нечитаемый вид), дату истечения срока
значений, необходимых для требуется хранить в течение срока X по причинам Y); действия, имя держателя карты и сервисный
выполнения законодательных,  процессы безопасного удаления ДДК, если в их код.
нормативных и (или) служебных хранении больше нет необходимости в соответствии с Знание мест хранения ДДК необходимо для их
требований; законодательными, нормативными или служебными надлежащего хранения или удаления, когда
 конкретные требования к требованиями; они больше не требуются. Чтобы определить
хранению ДДК;  наличие ежеквартального процесса обнаружения и надлежащие требования к хранению,
 процессы безопасного удаления безопасного удаления ДДК, по которым превышены организации сначала следует выяснить свою
данных, когда в них уже нет сроки хранения, установленные требованиями.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 40
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
необходимости; 3.1.b Опросить работников на предмет того, что: служебную необходимость, а также любые
 ежеквартальный процесс законодательные или нормативные
 все места хранения ДДК включены в процессы хранения требования, которые применимы к ее отрасли
обнаружения и безопасного
и удаления данных; и (или) к типу хранимых данных.
удаления ДДК, по которым
превышены сроки хранения,  реализован ежеквартальный процесс обнаружения и
установленные требованиями. безопасного удаления ДДК, проводимый вручную или
автоматически;
 этот процесс реализуется для всех мест хранения ДДК.

3.1.с Для выборки системных компонентов, которые хранят Обнаружение и удаление хранящихся данных
ДДК: с истекшим сроком хранения позволяет
предотвратить хранение данных, которые
 проверить файлы и системные записи на предмет того,
что сроки хранения данных не превышают сроки, больше не требуются. Данный процесс можно
определенные политикой хранения данных; автоматизировать (полностью или частично)
или выполнять вручную. Например, можно
 проверить механизм удаления на предмет того, что
запрограммировать процедуру обнаружения и
данные удаляются безопасным образом.
удаления данных (автоматическую или
ручную) и (или) проверять места хранения
данных вручную.
Внедрение методов безопасного удаления
данных гарантирует, что данные, когда они
больше не требуются, восстановить будет
невозможно.
Важно! Не хранить данные, если они не
нужны!

3.2 Запрещается хранить КАД после 3.2.a Для эмитентов и (или) компаний, поддерживающих КАД состоят из полных данных треков, кода
авторизации (даже в зашифрованном услуги эмиссии и хранящих КАД, проверить политики и или значения проверки подлинности карты и
виде). Если КАД получены, следует опросить работников на предмет того, что у этих данных ПИН-кода. Хранить КАД после
сделать все данные организаций есть документированное обоснование для авторизации запрещается! Эти данные
невосстановимыми до завершения хранения КАД. представляют большую ценность для
процесса авторизации. злоумышленников, т.к. последние, используя
3.2.b Для эмитентов и (или) компаний, поддерживающих такие данные, могут генерировать поддельные
Эмитенты и компании, которые услуги эмиссии и осуществляющих хранение КАД, платежные карты и осуществлять
поддерживают услуги эмиссии, проверить места хранения данных и системные мошеннические транзакции.
могут хранить КАД, если: конфигурации на предмет того, что КАД защищены.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 41
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
 имеется служебное обоснование, и 3.2.с Для всех других организаций, если организация Эмитенты платежных карт или компании,
 данные хранятся безопасно. принимает КАД, проверить политики, процедуры и которые оказывают или поддерживают услуги
системные конфигурации на предмет того, что данные не эмиссии, часто создают и контролируют КАД в
К КАД относятся данные, сохраняются после авторизации. рамках процесса эмиссии. Компаниям, которые
перечисленные в требованиях 3.2.1 – оказывают, содействуют или поддерживают
3.2.3. услуги выпуска карт, разрешается хранить КАД
ТОЛЬКО В ТОМ СЛУЧАЕ, если у них есть в
этом обоснованная служебные необходимость.
Следует отметить, что все требования
стандарта PCI DSS распространяются на
эмитентов, и единственное исключение для
эмитентов и их процессинговых центров
заключается в том, что они могут хранить КАД,
если у них в этом есть обоснованная
потребность. Под такой потребностью
понимается не удобство, а необходимость для
выполнения эмитентом своей функции. Любые
такие данные должны храниться безопасно, в
соответствии с требованиями стандарта
PCI DSS и требованиями конкретной
международной платежной системы.
3.2.d Для всех других организаций, если организация Для неэмитентов хранение КАД после
принимает КАД, проверить процедуры и процессы авторизации запрещено.
безопасного удаления данных на предмет того, что данные
восстановить невозможно.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 42
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.2.1 Запрещается хранить полное 3.2.1 Проверить источники данных в выборке системных Если сохранены полные данные треков,
содержимое любого трека компонентов, включая перечисленные ниже, на предмет злоумышленники, получившие доступ к этим
(магнитной полосы на обратной того, что полные данные любого трека магнитной полосы, данным, могут использовать их для
стороне карты, эквивалентных находящейся на обратной стороне карты (или ее аналога воспроизведения платежных карт и
данных на чипе или в ином месте) на чипе), не сохраняются после авторизации: осуществления мошеннических транзакций.
после авторизации. Эти данные
 входящие данные о транзакции;
также называются «полные данные
треков», «трек», «трек 1», «трек 2» и  все журналы (например, журналы транзакций,
«данные магнитной полосы». хронологии, отладки, ошибок);
 файлы хронологии;
Примечание: для повседневного
 файлы трассировки;
ведения деятельности может быть
необходимо хранение следующих  несколько схем баз данных;
элементов данных магнитной  содержимое баз данных.
полосы:
 имя держателя карты;
 номер карты (PAN);
 дата истечения срока действия
карты;
 сервисный код.
Для минимизации рисков храните
только те элементы данных, в
хранении которых есть служебная
необходимость.

3.2.2 Запрещается хранить код или 3.2.2 Проверить источники данных в выборке системных Код проверки подлинности карты
значение проверки подлинности компонентов, включая перечисленные ниже, на предмет предназначен для защиты операций без
карты (трех- или четырехзначное того, что трех- или четырехзначный код или значение предоставления платежной карты (например,
число, напечатанное на лицевой или проверки подлинности карты, напечатанные на лицевой при оплате через Интернет, по почте или по
обратной стороне карты, стороне карты или на месте для подписи (данные CVV2, телефону, т. е. в транзакциях, где не
используемые для подтверждения CVC2, CID, CAV2), не сохраняются после авторизации: присутствуют ни карта, ни ее держатель).
транзакций, выполняемых без  входящие данные о транзакции; В случае кражи этих данных, злоумышленник
предоставления платежной карты) получит возможность совершения
после авторизации.  все журналы (например, журналы транзакций,
хронологии, отладки, ошибок); мошеннических транзакций через Интернет, по
почте или телефону.
 файлы хронологии;
 файлы трассировки;
 несколько схем баз данных;
 содержимое баз данных.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 43
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.2.3 Запрещается хранить ПИН-код 3.2.3 Проверить источники данных в выборке системных Данные значения должны быть известны
или зашифрованный ПИН-блок компонентов, включая перечисленные ниже, на предмет только держателю карты или банку-эмитенту
после авторизации. того, что ПИН-коды, а также зашифрованные ПИН-блоки карты. В случае кражи этих данных
не сохраняются после авторизации: злоумышленник получит возможность
совершения мошеннических дебетовых
 входящие данные о транзакции;
транзакций с использованием ПИН-кода
 все журналы (например, журналы транзакций, (например, для получения наличных через
хронологии, отладки, ошибок); банкомат).
 файлы хронологии;
 файлы трассировки;
 несколько схем баз данных;
 содержимое баз данных.
3.3 Маскировать PAN при его 3.3.а Проверить письменные политики и процедуры Отображение полного PAN на экранах
отображении (максимально маскирования PAN при его отображении на предмет того, компьютеров, чеках об оплатах с
возможное количество отображаемых что: использованием платежных карт, факсах или в
цифр – первые шесть и последние бумажных отчетах может привести к тому, что
 список ролей, которым требуется доступ к больше чем
четыре), чтобы только работники с первые шесть и (или) последние четыре цифры (в том эти данные станут известны посторонним
обоснованной служебной числе полный PAN), документирован, и для каждой роли лицам и могут быть использованы в
необходимостью могли видеть больше обоснована служебная необходимость такого доступа; мошеннических целях. Отображение полного
чем первые шесть и (или) последние PAN только тем лицам, у которых есть такая
 PAN должен маскироваться при отображении, так
четыре цифры PAN. обоснованная служебная необходимость,
чтобольше чем первые шесть и (или) последние четыре
цифры PAN видны только тем работникам, у которых на минимизирует риски того, что посторонние
Примечание: это требование не
то есть служебная необходимость; лица получат доступ к данным PAN.
заменяет собой существующие
более строгие требования к  для всех ролей, которым явным образом не разрешено Метод маскирования всегда должен
отображению ДДК (например, видеть полный PAN, должен быть виден только обеспечивать отображение минимального
требования законодательства или маскированный PAN. количества цифр, которые необходимы для
международных платежных систем к выполнения конкретной производственной
3.3.b Проверить системные конфигурации на предмет того,
чекам POS-терминалов). функции. Например, если только последние
что полный PAN отображается только для пользователей и
четыре цифры нужны для выполнения
(или) ролей, у которых есть документированная служебная
производственной функции, PAN маскируется
необходимость, и маскируется для всех остальных
так, что работник, выполняющий данную
запросов.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 44
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.3.с Проверить варианты отображения PAN (например, на функцию, может видеть только последние
экране, на бумажных квитанциях) на предмет того, что эти четыре цифры. Другой пример: если
номера маскируются при отображении ДДК и чтобольше производственная необходимость требует
чем первые шесть и (или) последние четыре цифры PAN доступ к банковскому идентификационному
видны только лицам, у которых есть обоснованная номеру (BIN) для маршрутизации,
служебная необходимость. отображаются только цифры BIN (обычно это
первые шесть цифр) в течение выполнения
этой производственной функции.
Это требование касается защиты PAN,
отображаемого на экранах, бумажных
квитанциях, распечатках и т. д., и его следует
отличать от требования 3.4, которое касается
защиты PAN при его хранении в файлах, базах
данных и т. д.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 45
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.4 Привести PAN к нечитаемому виду 3.4.a Проверить документацию о системе, используемой Защитить все PAN, которые хранятся в
во всех местах их хранения (включая для защиты PAN, в том числе информацию о ее вендоре, основных хранилищах (базах данных,
журналы, резервные копии, съемные типе системы и (или) процесса, алгоритмах шифрования неструктурированных файлах, таких как
цифровые носители), используя для (при использовании таковых) на предмет того, что PAN текстовые файлы, таблицы и т. д.), а также во
этого любой из следующих методов: приводится к нечитаемому виду с использованием одного вспомогательных хранилищах (резервных
из следующих методов: копиях, журналах регистрации событий,
 однонаправленное хеширование
журналах исключений и отладки и т. д.).
на основе стойкой криптографии  однонаправленного хеширования на основе стойкой
(хеш-код должен быть криптографии; Для приведения ДДК к нечитаемому виду
сформирован из целого PAN);  усечения; можно использовать функции
 усечение (хеш-код не может  индексных маркеров и шифровальных блокнотов, однонаправленного хеширования на основе
использоваться для замены причем такие блокноты при хранении должны быть стойкой криптографии. Их использование
усеченного сегмента PAN); защищены; целесообразно тогда, когда нет
 индексные маркеры и необходимости в восстановлении исходного
 стойкой криптографии с сопутствующими процессами и
шифровальные блокноты (такие процедурами управления ключами. номера (так как однонаправленное
блокноты при хранении должны хеширование является необратимым).
быть защищены); 3.4.b Проверить несколько таблиц или файлов из выборки Желательно (но на данный момент не
хранилищ данных на предмет того, что PAN приведены к является требованием) добавлять
 стойкая криптография с
нечитаемому виду (т. е. не хранятся как незашифрованный дополнительное входное значение к ДДК
сопутствующими процессами и
текст). перед хешированием, чтобы у
процедурами управления ключами.
3.4.c Проверить выборку съемных носителей (например, злоумышленника было меньше возможностей
Примечание: при наличии доступа к
для сравнения данных (и получения PAN) с
PAN одновременно в усеченном и магнитные ленты с резервными копиями данных) на
таблицами предварительно подсчитанных
хешированном виде злоумышленнику предмет того, что PAN на данных носителях приведены к
значений хеша.
будет несложно восстановить нечитаемому виду.
исходный PAN. Если в среде Цель усечения заключается в том, чтобы
3.4.d Проверить выборку журналов аудита, включая окончательно удалять часть PAN, так что
организации содержится PAN
журналы платежных приложений, на предмет того, что PAN только часть PAN(как правило, не больше
одновременно в усеченном и
приведены в них к нечитаемому виду или отсутствуют в шести первых и четырех последних цифр)
хешированном виде, должны быть
журналах. хранится.
введены дополнительные защитные
меры, чтобы исключить Индексный маркер – это криптографический
возможность корреляции PAN в маркер, который заменяет PAN, основанный
усеченном и хешированном виде и на определенном индексе значений, не
возможность восстановления поддающихся вычислению. Одноразовый
исходного PAN. блокнот – это система, в которой секретный
ключ, сгенерированный случайным образом,
используется только один раз для
шифрования сообщения, которое затем

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 46
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.4.е Если в среде организации содержится PAN расшифровывается с помощью
одновременно в усеченном и хешированном виде, соответствующего одноразового блокнота и
проверить применяемые меры контроля на предмет того, ключа.
что хешированная и усеченная версии PAN не могут быть Цель стойкой криптографии (см. определение
скоррелированы для восстановления PAN в исходном виде. в документе Глоссарий. Основные
определения, аббревиатуры и сокращения
стандартов PCI DSS и PA-DSS) заключается
в том, что шифрование должно быть основано
на использовании протестированных и
общепринятых отраслевых алгоритмов с
высокой надежностью криптографических
ключей (а не проприетарных или
«самописных» алгоритмов).
Сопоставляя хешированные и усеченные
версии PAN, злоумышленник может без труда
вычислить исходный PAN. Меры, которые
используются, чтобы предотвратить
сопоставление этих данных, помогают
обеспечить нечитаемость исходного PAN.

3.4.1 Если используется 3.4.1.a Если применяется шифрование диска, проверить Цель этого требования состоит в том, чтобы
шифрование диска (вместо конфигурацию и проследить за процессом определить условия, при которых можно
шифрования на уровне файлов или аутентификации на предмет того, что логический доступ к использовать шифрование на уровне диска
шифрования базы данных на уровне зашифрованной файловой системе реализован при для приведения ДДК к нечитаемому виду. При
столбцов), то управление помощи механизма, независимого от нативных шифровании диска в компьютере шифруется
логическим доступом должно механизмов аутентификации операционной системы весь жесткий диск или раздел, а информация
осуществляться отдельно и (например, путем отказа от использования локальных баз автоматически расшифровывается, когда ее
независимо от нативных механизмов данных учетных записей или основных учетных данных запрашивает авторизованный пользователь.
аутентификации и контроля доступа для входа в сеть). Многие решения для шифрования дисков
операционной системы (например, перехватывают операции чтения-записи
путем отказа от использования 3.4.1.b Проследить за процессами и опросить работников операционной системы и выполняют
локальных баз данных учетных на предмет того, что криптографические ключи хранятся соответствующие криптографические
записей пользователей или безопасно (например, на съемном носителе, который преобразования, не требуя каких-либо
основных учетных данных для входа достаточно защищен надежными механизмами контроля дополнительных действий со стороны
в сеть). Ключи расшифрования не доступа). пользователя, за исключением

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 47
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
должны быть связаны с учетными 3.4.1.c Проверить конфигурации и проследить за предоставления пароля или парольной фразы
записями пользователей. процессами на предмет того, что ДДК на съемных при запуске системы или в начале сеанса. С
Примечание: это требование носителях хранятся только в зашифрованном виде. учетом этих особенностей шифрования на
применяется в дополнение ко всем уровне диска, для того, чтобы соответствовать
Примечание: если шифрование диска не используется данному требованию, метод шифрования не
остальным требованиям PCI DSS
для шифрования съемных носителей, данные на таких должен:
по шифрованию и управлению
съемных носителях должны быть приведены к
ключами. 1) использовать тот же аутентификатор
нечитаемому виду с использованием какого-либо другого
пользователя, что и операционная
метода.
система; или
2) использовать ключ расшифрования,
связанный или взятый из локальных баз
данных учетных записей или основных
учетных данных для входа в сеть.
Полное шифрование диска помогает защитить
данные в случае физической утраты диска и,
следовательно, может быть целесообразно
для портативных устройств, содержащих ДДК.

3.5 Документировать и внедрить 3.5 Проверить политики и процедуры управления ключами Криптографические ключи должны быть
процедуры защиты ключей, на предмет того, что определены процессы для защиты надежно защищены, поскольку лица,
используемых для защиты хранимых ключей шифрования ДДК от раскрытия или получившие к ним доступ, смогут
ДДК от раскрытия или злоупотребления, и в этих процессах предусмотрено, как расшифровать данные. Ключи шифрования
злоупотребления, следующим минимум, следующее: ключей, при использовании таковых, должны
образом. обладать, как минимум, такой же
 доступ к ключам шифрования ограничен минимально
криптографической стойкостью, что и ключи
Примечание: это требование необходимым количеством хранителей ключа;
шифрования данных. Это необходимо, чтобы
применяется к ключам шифрования  ключи шифрования ключей должны обладать такой же
обеспечить надлежащую защиту ключей
хранимых ДДК, а также к ключам криптографической стойкостью, как и ключи
шифрования данных, и самих данных, которые
шифрования ключей, используемым шифрования данных, которые они защищают;
шифруются с использованием этих ключей.
для защиты ключей шифрования  ключи шифрования ключей хранятся отдельно от
данных. Такие ключи должны ключей шифрования данных; Требование по защите ключей от раскрытия и
обладать, как минимум, такой же  ключи хранятся безопасно в минимально возможном злоупотребления распространяется как на
надежностью, как и ключи количестве мест и форм хранения. ключи шифрования ключей, так и на ключи
шифрования данных. шифрования данных. Поскольку один ключ
шифрования ключей может предоставить
доступ ко многим ключам шифрования данных,
ключи шифрования ключей требуют надежных
защитных мер.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 48
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.5.1 Дополнительное требование 3.5.1 Опросить ответственных работников и проверить Примечание: это требование применяется,
только для поставщиков услуг: документацию на предмет того, что документ существует и только когда организация определена как
вести документальное описание описывает криптографическую архитектуру, включая: поставщик услуг.
криптографической архитектуры,  детальную информацию о всех алгоритмах,
включающей: Ведение актуальной документации,
протоколах и ключах, которые используются для описывающей криптографическую
 детальную информацию о защиты ДДК, в том числе стойкость ключа и дата архитектуру, позволяет организации понимать,
всех алгоритмах, протоколах окончания действия ключа; какие алгоритмы, протоколы и
и ключах, которые
 описание назначения каждого из ключей; криптографические ключи используются для
используются для защиты защиты ДДК, а также какие устройста
ДДК, в том числе стойкость  учет любых HSM и SCD, которые используются для генерируют, используют и защищают ключи.
ключа и дата окончания управления ключами. Это позволяет организации не отставать от
действия ключа; меняющихся угроз для ее архитектуры и
 описание назначения каждого планировать обновления для обеспечения
из ключей; защиты с помощью изменения различных
алгоритмов и (или) стойкости ключей. Ведение
 учет любых HSM и SCD, такой документации также позволяет
которые используются для организации выявлять потеренные ключи или
управления ключами. устройства по управлению ключами и
Примечание: до 31 января 2018 года несанкционированные добавления в ее
это требование носит криптографическую архитектуру.
рекомендательный характер, а
после этой даты становится
обязательным требованием.

3.5.2 Ограничить доступ к 3.5.2 Проверить списки доступа пользователей на Следует сократить до минимума количество
криптографическим ключам предмет того, что доступ к ключам ограничен минимально лиц, имеющих доступ к криптографическим
минимально необходимым числом необходимым числом хранителей ключа. ключам (тем самым сокращая возможности
хранителей ключа. раскрытия ДДК посторонним лицам). Обычно
такими лицами являются работники,
назначенные хранителями ключей.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 49
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.5.3 Всегда хранить секретные и 3.5.3.а Проверить документированные процедуры на Криптографические ключи должны храниться
закрытые ключи шифрования и (или) предмет того, что криптографические ключи шифрования безопасно для предотвращения
расшифрования ДДК в одной (или и (или) расшифрования ДДК должны существовать только несанкционированного или ненужного доступа,
более) форм из следующего в одной (или более) форм из следующего перечня: который может привести к раскрытию ДДК.
перечня:  защищенные ключом шифрования ключей, который Это требование не подразумевает, что ключи
 защищенные ключом имеет такую же криптографическую стойкость, как и шифрования ключей должны быть
шифрования ключей, который ключ шифрования данных, и хранится отдельно от зашифрованы, но они должны быть защищены
имеет такую же ключа шифрования данных; от раскрытия и злоупотребления в
криптографическую стойкость,  в защищенном криптографическом устройстве (таком соответствии с требованием 3.5. Если
как и ключ шифрования данных, как аппаратный модуль безопасности (HSM) или POI- используются ключи шифрования ключей, их
и хранится отдельно от ключа терминал, утвержденный согласно требованиям PCI хранение в местах, физически и (или)
шифрования данных; PTS); логически отделенных от ключей шифрования
 в защищенном данных, снижает риск несанкционированного
 в форме компонентов ключа или в форме
криптографическом устройстве доступа к тем и другим ключам.
разделяемого секрета в соответствии с принятым в
(таком как аппаратный модуль отрасли методом.
безопасности (HSM) или POI-
терминал, утвержденный 3.5.3.b Проверить системные конфигурации и места
согласно требованиям PCI PTS); хранения ключей на предмет того, что криптографические
ключи шифрования ДДК всегда существуют в одной (или
 в форме как минимум двух
более) форм из следующего перечня:
компонентов ключа полной
длины или в форме  защищенные ключом шифрования ключей;
разделяемого секрета в  в защищенном криптографическом устройстве (таком
соответствии с принятым в как аппаратный модуль безопасности (HSM) или POI-
отрасли методом. терминал, утвержденный согласно требованиям PCI
PTS);
Примечание: хранение публичных
ключей в одной из этих форм не  в форме компонентов ключа или в форме
требуется. разделяемого секрета в соответствии с принятым в
отрасли методом.
3.5.3.c Если используются ключи шифрования ключей,
проверить системные конфигурации и места хранения
ключей на предмет того, что:
 ключи шифрования ключей обладают такой же
криптографической стойкостью, что и ключи
шифрования данных, которые они защищают;
 ключи шифрования ключей хранятся отдельно от
ключей шифрования данных.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 50
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.5.4 Хранить криптографические 3.5.4 Проверить места хранения ключей и проследить за Хранение криптографических ключей
ключи в минимально возможном процессами на предмет того, что ключи хранятся в шифрования в минимально возможном
количестве мест расположения. минимально возможном количестве мест расположения. количестве мест расположения помогает
организации отслеживать и осуществлять
мониторинг всех мест хранения ключей и
снижает вероятность раскрытия ключей
посторонним лицам.

3.6 Полностью документировать и 3.6.a Дополнительная проверочная процедура для Способ управления криптографическими
внедрить все процессы и процедуры поставщиков услуг: если поставщик услуг предоставляет ключами представляет собой критичную часть
управления криптографическими клиентам ключи шифрования для передачи или хранения непрерывного обеспечения безопасности
ключами шифрования ДДК, в том ДДК, проверить документацию, которую поставщик услуг средства шифрования. В основе правильно
числе: предоставляет клиентам, на наличие в ней рекомендаций о организованного процесса управления
том, как безопасно передавать, хранить и обновлять ключи ключами, вне зависимости от того,
Примечание: существует
клиентов, в соответствии с требованиями 3.6.1–3.6.8, выполняется ли он вручную или автоматически
множество различных источников, из
приведенными ниже. в составе продукта шифрования, лежат
которых можно получить
отраслевые стандарты, и такой процесс
информацию о стандартах 3.6.b Проверить процедуры и процессы управления учитывает все основные требования с 3.6.1 по
управления ключами (например, сайт ключами шифрования ДДК и выполнить следующее: 3.6.8.
института NIST - http://csrc.nist.gov).
Предоставление потребителям рекомендаций
по безопасной передаче, хранению и
обновлению криптографических ключей
помогает предотвратить неправильное
управление ключами или их раскрытие
посторонним организациям.
Данное требование применяется к ключам
шифрования хранимых ДДК, и любым
соответствующим ключам шифрования
ключей.
Примечание: проверочная процедура 3.6.а
является дополнительной процедурой,
применяемой только для организаций,
которые определены как поставщики услуг.

3.6.1 Генерировать 3.6.1.а Убедиться, что процедуры управления ключами Средство шифрования должно генерировать
криптографически стойкие ключи указывают, каким образом следует генерировать стойкие стойкие ключи согласно определению для
ключи. термина «генерация криптографических

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 51
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.6.1.b Пронаблюдать процедуры генерации ключей на ключей», приведенному в документе
предмет того, что генерируются стойкие ключи. «Глоссарий. Основные определения,
аббревиатуры и сокращения стандартов PCI
DSS и PA-DSS». Использование стойких
криптографических ключей значительно
повышает уровень безопасности
зашифрованных ДДК.

3.6.2 Распространять 3.6.2.а Убедиться, что процедуры управления ключами Средство шифрования должно обеспечивать
криптографические ключи указывают, как безопасным образом распространять безопасный способ распространения ключей
безопасным образом ключи. (то есть ключи не должны распределяться в
незашифрованном виде), и только среди
3.6.2.b Проверить метод распространения ключей на хранителей ключа, указанных в
предмет того, что они распространяются безопасным требовании 3.5.1.
образом.

3.6.3 Защита хранения 3.6.3.а Убедиться, что процедуры управления ключами Средство шифрования должно обеспечивать
криптографических ключей указывают, как хранить ключи безопасным образом. безопасное хранение ключей (например,
шифруя их с использованием ключа
3.6.3.b Проверить метод хранения ключей на предмет шифрования ключей). Хранение ключей без
того, что ключи хранятся в безопасности. надлежащей защиты может дать
злоумышленникам доступ, который приведет к
расшифрованию и раскрытию ДДК.

3.6.4 Заменять криптографические 3.6.4.а Убедиться, что процедуры управления ключами Отрезок времени, в течение которого
ключи с истекшим криптопериодом устанавливают криптопериод для каждого типа определенный криптографический ключ может
(например, по прошествии используемых ключей, а также определяют процесс их использоваться по определенному для него
определенного срока действия и замены по завершении установленного криптопериода назначению. Определяя криптопериод,
(или) получении с помощью данного (криптопериодов). следует учитывать, среди прочего: надежность
ключа определенного объема используемого алгоритма, размер или длину
шифротекста) в соответствии с 3.6.4.b Опросить работников на предмет того, что ключи ключа, риск компрометации ключа и
указаниями соответствующего заменяются по завершении установленного критичность шифруемых данных.
вендора приложений или владельца криптопериода (криптопериодов).
Когда криптопериод ключей шифрования
ключа и на основании отраслевых подходит к концу, их следует периодически
рекомендаций и руководств менять, чтобы минимизировать риск того, что
(например, специальной публикации злоумышленник получит ключи шифрования и
NIST 800-57). сможет использовать их для расшифрования
данных.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 52
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
3.6.5 Заменять ключи или изымать 3.6.5.а Проверить процедуры управления ключами на Чтобы исключить возможность дальнейшего
их из обращения (например, предмет того, что они определяют следующие процессы: использования ключей, следует изымать из
архивировать, уничтожать и (или)  изъятие либо замена ключей в случае ослабления обращения и (или) уничтожать те из них,
отзывать) по мере необходимости, которые больше не используются или не
целостности;
если ослаблена целостность ключа требуются, а также те, которые (возможно)
(например, уволился работник,  замена ключей, которые были или могли быть были скомпрометированы. Если требуется их
знающий компонент ключа в скомпрометированы; хранение (например, для поддержки
незашифрованном виде) либо есть  исключение возможности того, что сохраненные, но архивированных зашифрованных данных),
подозрения, что ключи изъятые из обращения или замененные ключи не ключи следует надежно защитить.
скомпрометированы. используются для операций шифрования.
Средство шифрования должно обеспечивать и
Примечание: если существует 3.6.5.b Опросить работников на предмет того, что поддерживать процесс замены ключей, по
необходимость сохранения изъятых внедрены следующие процессы: которым подошел срок замены или которые
из обращения или замененных (возможно) были скомпрометированы.
 изъятие либо, при необходимости, замена ключей в
ключей, следует заархивировать их случае ослабления целостности, в т. ч. вследствие
безопасным образом (например, с увольнения работника, обладающего информацией о
использованием ключа шифрования ключе;
ключей). Использовать помещенные
 замена ключей шифрования, которые были или могли
в архив криптографические ключи
быть скомпрометированы;
только для расшифрования и (или)
верификации.  исключение возможности того, что сохраненные, но
изъятые из обращения или замененные ключи
используются для операций шифрования.
3.6.6 Если применяются ручные 3.6.6.а Проверить ручные процедуры управления Разделенное знание и двойной контроль за
процедуры управления незашифрованными ключами на предмет того, что они ключами используются, чтобы исключить
незашифрованными определяют использование следующих процессов: возможность доступа одного человека к
криптографическими ключами, целому ключу. Такая мера применима для
 разделенное знание ключей, где как минимум двое
данные процедуры должны операций управления ключами, выполняемых
людей владеют компонентами одного ключа, и
координироваться с использованием вручную, или в средствах шифрования, где
каждый из них знает только свой компонент ключа; И
принципа разделения знания и управление ключами не реализовано.
двойного контроля.  двойной контроль ключей таким образом, чтобы для
выполнения любых операций по управлению Разделенное знание – это метод, при
Примечание: примеры ручных ключами требовалось как минимум два человека, и использовании которого двое или более людей
процедур управления ключами ни один из них не обладал доступом к раздельно владеют компонентами одного
включают, как минимум, генерацию аутентификационным данным (например, паролям ключа; каждый из этих людей знает только
ключа, его передачу, загрузку, или ключам) другого. свой компонент ключа, а отдельные

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 53
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
хранение и уничтожение. 3.6.6.b Опросить работников и (или) проследить за компоненты не дают никакой информации об
процессами на предмет того, что в процедурах ручного исходном криптографическом ключе.
управления незашифрованными ключами используется Двойной контроль требует наличия двух или
следующее: более людей для выполнения определенной
 разделенное знание; И функции, при этом ни один из них не имеет
доступа к аутентификационным данным
 двойной контроль.
другого или возможности их использовать.

3.6.7 Исключить 3.6.7.а Убедиться, что процедуры управления ключами Средство шифрования не должно допускать
несанкционированную замену определяют процессы, исключающие или принимать замену ключей,
криптографического ключа. несанкционированную замену ключей. инициированную неавторизованными
источниками или непредусмотренными
3.6.7.b Опросить работников и (или) проследить за процессами.
процессами на предмет того, что несанкционированная
замена ключей исключена.

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

3.6.8.b Проверить документацию или иные


доказательства того, что хранители ключа подтвердили (в
письменном или электронном виде), что понимают и
принимают свои обязанности.

3.7 Гарантировать, что политики 3.7 Проверить документацию и опросить работников на Работники должны знать и соблюдать
безопасности и операционные предмет того, что политики безопасности и операционные политики безопасности и документированные
процедуры защиты хранимых ДДК процедуры защиты хранимых ДДК: операционные процедуры для управления
документированы, используются и безопасным хранением ДДК на постоянной
 документированы;
известны всем заинтересованным основе.
 используются;
лицам.
 известны всем заинтересованным лицам.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 54
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требование 4. Шифровать ДДК при передаче через сети общего пользования.
Критичная информация должна быть зашифрована при передаче через сети, к которым злоумышленники могут легко получить доступ.
Неправильно сконфигурированные беспроводные сети и уязвимости устаревших протоколов шифрования и аутентификации остаются
целями для злоумышленников, которые используют данные уязвимости, чтобы получить привилегированный доступ к среде ДДК.

Требования PCI DSS Проверочные процедуры Пояснение


4.1 Использовать стойкую 4.1.a Выявить все места, где осуществляется прием или Критичная информация должна шифроваться
криптографию и безопасные передача ДДК через открытые общедоступные сети. при передаче по сетям общего пользования,
протоколы, чтобы защитить критичные Проверить документированные стандарты и сравнить их с потому что злоумышленник без труда может
ДДК при их передаче через открытые системными конфигурациями на предмет того, что во всех перехватить и (или) изменить их маршрут при
общедоступные сети с учетом местах используются протоколы безопасности и стойкая передаче.
следующего: криптография. Безопасная передача ДДК требует
 принимаются только доверенные 4.1.b Проверить документированные политики и процедуры использования доверенных ключей и (или)
ключи и сертификаты; на предмет того, что: сертификатов, безопасного протокола
 используемый протокол передачи и шифрования надлежащей
 принимаются только доверенные ключи и (или) стойкости для шифрования ДДК. Не следует
поддерживает только безопасные
сертификаты; принимать запросы на подключение от систем,
версии и конфигурации;
 стойкость шифрования  используемым протоколом поддерживаются только не поддерживающих требуемую стойкость
соответствует используемой безопасные версии и конфигураций (небезопасные шифрования, т. к. это приведет к
методологии шифрования. версии или конфигурации не поддерживаются); небезопасному подключению.
 применяется шифрование надлежащей стойкости Следует отметить, что некоторые версии
Примечание: там, где используется
согласно используемой методологии шифрования. протоколов (например, SSL, SSH 1.0 и ранние
SSL и (или) ранние версии TLS,
требования, описанные в 4.1.с Сделать выборку входящих и исходящих отправок по версии TLS) содержат известные уязвимости,
Приложении А2, должны быть мере их выполнения (например, отслеживая системные которые могут быть использованы
выполнены. процессы или сетевой трафик) и проверить их на предмет злоумышленником для получения контроля
того, что все ДДК передаются в зашифрованном виде с над подверженной этим уязвимостям
использованием стойкой криптографии. системой. Независимо от того, какой протокол
Примеры открытых общедоступных используется, следует убедиться, что он
сетей включают, как минимум: 4.1.d Проверить ключи и сертификаты на предмет того, что настроен на то, чтобы использовать только
принимаются только доверенные ключи и (или) безопасные конфигурации и версии для
 сеть Интернет; сертификаты. предотвращения небезопасного подключения.
 беспроводные технологии, Например, использовать только доверенные
включая протоколы 802.11 и 4.1.е Проверить системные конфигурации на предмет того, сертификаты и поддерживать только стойкое
что протокол реализован таким образом, чтобы
Bluetooth; шифрование (не поддерживать нестойкие,
использовать только безопасные конфигурации и что он не
 технологии сотовой связи, небезопасные протоколы или методы).
поддерживает небезопасные версии или конфигурации.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 55
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
например GSM, CDMA; 4.1.f Проверить системные конфигурации на предмет того, Проверка того, что сертификат является
 GPRS; что в используемой методологии шифрования применяется доверенным (например, срок действия его не
 спутниковые средства связи. шифрование надлежащей стойкости. (См. рекомендации истек, и он получен из доверенного источника),
вендора и (или) информацию о передовом опыте). помогает обеспечить целостность безопасного
подключения.

4.1.g Если реализован протокол TLS, проверить системные Как правило, URL-адрес должен начинаться с
конфигурации на предмет того, что TLS включен при префикса HTTPS, и (или) в окне веб-браузера
каждой передаче или получении ДДК. должен отображаться значок замка. Многие
Например, если протокол реализован на базе браузера: поставщики TLS-сертификатов также
предоставляют хорошо заметную печать
 в качестве протокола URL-адреса указан HTTPS; и подтверждения проверки (иногда называемую
 ДДК запрашиваются только в том случае, если URL- «печать безопасности», «печать безопасного
адрес содержит префикс HTTPS. сайта» или «печать доверия»), по которой
можно щелкнуть для просмотра информации о
4.1.h Если используются ранние версии TLS, выполнить
веб-сайте.
проверочные процедуры, описанные в Приложении А2:
Дополнительные требования PCI DSS для организаций, Для получения информации о стойкой
использующих SSL и (или) ранние версии TLS. криптографии и безопасных протоколах
необходимо обратиться к отраслевым
стандартам и передовому опыту (например,
NIST SP 800-52 и SP 800-57, OWASP и т.д.).

4.1.1 Убедиться, что при 4.1.1 Выявить все беспроводные сети, передающие ДДК Злоумышленники используют свободно
использовании беспроводных сетей, либо подключенные к среде ДДК. Проверить распространяемые и широкодоступные
передающих ДДК либо документированные стандарты и сравнить их с средства для прослушивания беспроводного
подключенных к среде ДДК, системными конфигурациями на предмет того, что во трафика. Использование стойкой
применяется передовой отраслевой всех беспроводных сетях: криптографии может ограничить раскрытие
опыт, чтобы реализовать стойкое критичной информации, передаваемой по
 применяется передовой отраслевой опыт, чтобы
шифрование при аутентификации и беспроводным сетям.
реализовать стойкое шифрование при
передаче данных. Чтобы предотвратить доступ
аутентификации и передаче данных;
 не используется слабое шифрование (например, злоумышленников к беспроводным сетям или
WEP, SSL) в качестве защитной меры для использование беспроводных сетей для
аутентификации или передачи данных. получения доступа к другим внутренним сетям
или данным, требуется стойкая криптография
для аутентификации и передачи ДДК.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 56
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
4.2 Запрещается пересылать 4.2.a Если для передачи ДДК используются технологии Сообщения, передаваемые по электронной
незащищенные PAN с обмена сообщениями для конечных пользователей, то почте, с помощью систем мгновенного обмена
использованием технологий обмена просмотреть процессы отправки PAN и проверить выборку сообщениями, в чате, или SMS могут быть
сообщениями для конечных передач исходящих данных по мере их выполнения на перехвачены в процессе доставки, как во
пользователей (например, предмет того, что PAN приводится к нечитаемому виду или внутренней, так и во внешней общедоступной
электронная почта, системы защищается с применением стойкой криптографии каждый сетях. Не используйте эти средства передачи
мгновенного обмена сообщениями, раз при отправке с использованием технологий обмена сообщений для отправки PAN, если они не
SMS, чат и т. д.). сообщениями для конечных пользователей. обеспечивают стойкого шифрования.

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

4.3 Гарантировать, что политики 4.3 Проверить документацию и опросить работников на Работники должны знать и соблюдать
безопасности и операционные предмет того, что политики безопасности и операционные политики безопасности и операционные
процедуры шифрования процедуры шифрования передаваемых ДДК: процедуры для непрерывного управления
передаваемых ДДК документированы, безопасной передачей ДДК.
 документированы;
используются и известны всем
 используются;
заинтересованным лицам.
 известны всем заинтересованным лицам.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 57
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Поддерживать программу управления уязвимостями.
Требование 5. Защищать все системы от вредоносного ПО и регулярно обновлять антивирусные ПО или
программы.
Вредоносное ПО, включая вирусы, червей и трояны, проникает в сеть во время выполнения многих разрешенных бизнесом действий,
включая использование работниками электронной почты, сети Интернет, мобильных компьютеров, а также запоминающих устройств, что
приводит к эксплуатации уязвимостей системы. Антивирусное ПО должно использоваться на всех системах, обычно подверженных
воздействию вредоносного ПО, чтобы защитить системы от текущих и возможных угроз со стороны вредоносного ПО. Дополнительные
решения для защиты от вредоносного ПО могут использоваться в качестве дополнения к антивирусному ПО; однако такие
дополнительные решения не снимают требование об обязательном наличии антивирусного ПО.

Требования PCI DSS Проверочные процедуры Пояснение


5.1 Развернуть антивирусное ПО на 5.1 Проверить, что антивирусное ПО развернуто в выборке Против, казалось бы, защищенных систем идет
всех системах, обычно подверженных системных компонентов, включая все типы ОС, обычно постоянный поток атак, в которых
воздействию вредоносного ПО подверженных воздействию вредоносного ПО, при наличии используются широкодоступные эксплойты и
(особенно на персональных применимой антивирусной технологии. которые часто называются «атаками нулевого
компьютерах и серверах). дня» (такие атаки используют ранее
неизвестные уязвимости). Без регулярно
обновляемого антивирусного ПО, новые
формы вредоносного ПО могут атаковать
системы, нарушать работу сети, приводить к
компрометации данных.

5.1.1 Убедиться, что антивирусное 5.1.1 Проверить документацию вендора и конфигурации Важно обеспечить защиту от ВСЕХ типов и
ПО способно обнаруживать и антивирусов на предмет того, что антивирусные форм вредоносного ПО.
устранять все известные типы программы:
вредоносного ПО, а также  обнаруживают все известные типы вредоносного ПО;
обеспечивать защиту от них.
 удаляют все известные типы вредоносного ПО;
 защищают от всех известных типов вредоносного ПО.
Примерами типов вредоносного ПО являются вирусы,
черви, трояны, шпионское и рекламное ПО, руткиты.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 58
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
5.1.2 Проводить периодические 5.1.2 Опросить работников на предмет того, что для Как правило, мейнфреймы, компьютеры
проверки в системах, которые выявления угроз заражения новыми формами среднего уровня (например, AS/400) и
обычно считаются не вредоносного ПО ведется мониторинг и проверки систем, подобные системы в данное время не
подверженными заражению которые считаются не подверженными заражению подвержены заражению вредоносным ПО или
вредоносным ПО, выявляя и вредоносным ПО, для того, чтобы подтвердить, что этим не являются его мишенью. Однако тенденции
оценивая угрозы заражения новыми системам по-прежнему не требуется антивирусное ПО. в области вредоносного ПО могут быстро
формами вредоносного ПО, для меняться, а значит, организациям важно знать
того, чтобы проверять, что эти о новых видах вредоносного ПО, которые
системы по-прежнему не требуют могут быть опасны для их систем (например,
антивирусного ПО. отслеживая сообщения о безопасности от
вендоров ПО и новостных групп антивирусов,
чтобы узнать, угрожают ли их системам новые
виды и формы вредоносного ПО).
В процесс выявления новых уязвимостей в
системе безопасности следует включить
тенденции в области вредоносного ПО.
Порядок реагирования на новые тенденции
организации следует по необходимости
включить в стандарты конфигурации и
защитные меры.

5.2 Гарантировать, что все 5.2.a Проверить политики и процедуры на предмет того, что Даже у лучших антивирусов снижается
антивирусные механизмы: они предписывают поддерживать антивирусные ПО и базы эффективность, если за ними не следить и не
 поддерживаются в актуальном в актуальном состоянии. поддерживать в актуальном состоянии с
состоянии; помощью последних обновлений
5.2.b Проверить конфигурацию антивирусов, включая
 выполняют периодическое безопасности, антивирусных баз или защитных
установочные образы, на предмет того, что антивирусные
сканирование; мер от вредоносного ПО.
механизмы:
 создают журналы регистрации Журналы регистрации событий предоставляют
 настроены на автоматическое обновление;
событий, которые хранятся возможность мониторинга активности вирусов
 настроены на периодическое сканирование. и вредоносного ПО, и реагирования на эту
согласно требованию 10.7
стандарта PCI DSS. 5.2.c Проверить выборку системных компонентов, включая активность. Поэтому следует настроить
все типы операционных систем, подверженных средства защиты от вредоносного ПО на
воздействию вредоносного ПО, на предмет того, что: генерацию журналов регистрации событий и
управлять этими журналами в соответствии с
 антивирусное ПО и базы актуальны;
требованием 10.
 выполняется периодическое сканирование.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 59
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
5.2.b Проверить конфигурацию антивирусов, включая
установочные образы и выборку системных компонентов,
на предмет того, что:
 включено создание журналов регистрации событий;
 журналы хранятся согласно требованию 10.7 стандарта
PCI DSS.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 60
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
5.3 Убедиться, что антивирусные 5.3.а Проверить конфигурацию антивирусов, включая Антивирус, работающий постоянно и
механизмы постоянно запущены, и установочные образы ПО и выборку системных защищенный от изменений, обеспечит
пользователи не могут их ни компонентов, на предмет того, что антивирусное ПО надежную защиту от вредоносного ПО.
отключить, ни изменить без явного постоянно запущено. Использовать защитные меры на основе
разрешения, которое выдается политик на всех системах, чтобы исключить
руководством на каждый конкретный 5.3.b Проверить конфигурацию антивирусов, включая
установочные образы ПО и выборку системных возможность изменения или отключения
случай и на ограниченный период защитных мер антивирусного ПО. Это
времени. компонентов, на предмет того, что антивирусное ПО не
может быть отключено или изменено пользователями. позволит не допустить, чтобы злоумышленник
Примечание: антивирусные мог воспользоваться уязвимостями систем.
средства могут быть временно 5.3.c Опросить ответственных работников и проследить за
Также могут потребоваться дополнительные
отключены только в случае процессами на предмет того, что антивирусное ПО не меры безопасности на период времени, в
обоснованной технической может быть отключено или изменено пользователями без течение которого антивирусная защита будет
необходимости, с разрешения явного разрешения руководства в каждом конкретном отключена (например, отключение
руководства в каждом конкретном случае и на ограниченный период времени. незащищенной системы от сети Интернет пока
случае. Если антивирусную защиту отключена антивирусная защита и запуск
нужно отключить для определенной полного сканирования после его повторного
цели, необходимо получить включения).
официальное разрешение. Также
могут понадобиться
дополнительные защитные меры на
время, в течение которого
антивирусная защита будет
неактивна.

5.4 Гарантировать, что политики 5.4 Проверить документацию и опросить работников на Работники должны знать и соблюдать
безопасности и операционные предмет того, что политики безопасности и операционные политики безопасности и операционные
процедуры защиты систем от процедуры защиты систем от вредоносного ПО: процедуры для постоянной защиты систем от
вредоносного ПО документированы, вредоносного ПО.
 документированы;
используются и известны всем
 используются;
заинтересованным лицам.
 известны всем заинтересованным лицам.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 61
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требование 6. Разрабатывать и поддерживать безопасные системы и приложения
Злоумышленники используют уязвимости безопасности для получения привилегированного доступа к системам. Многие такие
уязвимости устраняются с помощью обновлений безопасности, которые предоставляются вендором и которые должны устанавливаться
организациями, управляющими системами. На все системы должны быть установлены все надлежащие обновления ПО, чтобы
защититься от эксплуатации уязвимостей и от компрометации ДДК злоумышленниками и вредоносным ПО.
Примечание: надлежащими являются те обновления, которые были оценены и протестированы в достаточной мере на предмет
того, что они совместимы с существующими конфигурациями безопасности. В приложениях собственной разработки многих
уязвимостей можно избежать, если использовать стандартные процессы разработки систем и приемы безопасного
программирования.

Требования PCI DSS Проверочные процедуры Пояснение


6.1 Наладить процесс выявления 6.1.a Проверить политики и процедуры на предмет того, Цель данного требования состоит в том, чтобы
уязвимостей с помощью авторитетных что в процессах требуется: организации были постоянно в курсе новых
внешних источников информации об уязвимостей, которые могут воздействовать на
 идентифицировать новые уязвимости;
уязвимостях, а также процесс оценки ее среду.
 оценивать критичность уязвимостей, в т. ч.
критичности (например, «высокая», Источники информации об уязвимостях должны
идентифицировать все уязвимости с «высоким» и
«средняя» или «низкая») для недавно быть достоверными. Зачастую к таковым
«критичным» уровнями;
обнаруженных уязвимостей. относятся веб-сайты вендоров, отраслевые
 использовать авторитетные внешние источники
Примечание: оценка критичности информации об уязвимостях. новостные группы, почтовые рассылки или RSS-
уязвимости должна быть основана на ленты.
6.1.b Опросить ответственных работников и проследить
отраслевых рекомендациях и учитывать Как только организация выявляет уязвимость,
за процессами на предмет того, что:
потенциальное воздействие. Например, которая может оказать негативное влияние на
критерии критичности уязвимости  новые уязвимости выявляются; среду организации, необходимо оценить
могут учитывать систему оценки CVSS  уязвимости оцениваются по ранжированию рисков, критичность уязвимости. Следовательно, в
base, классификацию вендора и (или) тип при этом идентифицируются все «высокие» риски и организации должен быть метод оценки
систем, подверженных воздействию. «критичные» уязвимости; уязвимостей и уровня их критичности на
Методы оценки критичности  процессы выявления новых уязвимостей постоянной основе. Для этого недостаточно
уязвимостей и ранжирования рисков безопасности включают в себя использование для провести сканирование авторизованным
зависят от среды организации и ее этого авторитетных внешних источников поставщиком услуг сканирования (ASV) или
стратегии по оценке рисков. При оценке информации об уязвимостях. внутреннее сканирование на наличие
критичности уязвимостей необходимо, уязвимостей; для этого необходим процесс
как минимум, идентифицировать все активного мониторинга отраслевых источников
уязвимости, уровень критичности информации об уязвимостях.
которых для среды считается высоким. Ранжируя риски (например, «высокий»,
Помимо оценки критичности «средний» или «низкий» уровни), организация
уязвимостей, они могут быть сочтены может быстрее идентифицировать наиболее
критическими, если представляют высокие риски, устанавливать им приоритет и
неотвратимую угрозу для среды, управлять ими, а также минимизировать

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 62
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
воздействуют на критичные системы вероятность использования злоумышленниками
и (или) могут привести к уязвимостей, которые представляют наиболее
компрометации, если не будут высокий риск для организации.
нейтрализованы. К критичным системам
могут, например, относиться системы
безопасности, общедоступные
устройства и системы, базы данных и
другие системы, осуществляющие
хранение, обработку или передачу ДДК.
6.2 Гарантировать, что все системные 6.2.a Проверить политики и процедуры, относящиеся к Против, казалось бы, защищенных систем идет
компоненты и ПО защищены от известных установке обновлений безопасности, на наличие постоянный поток атак, в которых используются
уязвимостей путем установки применимых процессов, которые требуют: широкодоступные эксплойты и которые часто
обновлений безопасности, которые называются «атаками нулевого дня» (такие атаки
 устанавливать применимые критичные обновления
выпускает производитель. Устанавливать безопасности, которые выпускает производитель, в используют ранее неизвестные уязвимости).
критичные обновления безопасности в течение месяца после их выхода; Если самые последние обновления не
течение одного месяца с момента их внедряются на критичных системах как можно
 устанавливать все применимые обновления
выпуска. быстрее, злоумышленник может использовать
безопасности, которые выпускает производитель, в
эти уязвимости, чтобы атаковать систему,
Примечание: критичные обновления течение соответствующего срока с момента их
нарушить ее работу или получить доступ к
безопасности должны выявляться в выхода (например, в течение трех месяцев).
критичным данным.
соответствии с процессом 6.2.b Сравнить перечень обновлений безопасности,
ранжирования рисков (см. Установка приоритета для обновлений критичной
которые установлены на каждой системе из выборки
требование 6.1). инфраструктуры максимально быстро
системных компонентов и связанного с ними ПО, с
обеспечивает защиту систем и устройств с
перечнем последних обновлений безопасности, которые
высоким приоритетом от уязвимостей после
выпускает производитель, на предмет того, что:
выхода обновления. Рекомендуется определить
 применимые критичные обновления безопасности, приоритеты установки обновлений таким
которые выпускает производитель, устанавливаются образом, чтобы обновления безопасности
в течение месяца с момента выпуска; устанавливались на критичные или
 все применимые обновления безопасности, которые подверженные риску системы в течение 30 дней,
выпускает производитель, устанавливаются в а обновления с меньшим уровнем риска – в
течение надлежащего срока с момента выпуска течение 2–3 месяцев.
(например, в течение трех месяцев).
Данное требование распространяется на
применимые обновления для всего
установленного ПО, включая платежные
приложения, как прошедшие проверку на
соответствие стандарту PA-DSS, так и не
проходившие данной проверки.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 63
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.3 Разрабатывать внутренние и внешние 6.3.a Проверить документированные процессы Если не учитывать информационную
приложения (включая административный разработки ПО на предмет того, что они основаны на безопасность на этапах разработки ПО
доступ к приложениям через веб- передовом отраслевом опыте и (или) стандартах. (определения требований, проектирования,
интерфейс) безопасно, с соблюдением анализа и тестирования), в производственную
следующих требований: 6.3.b Проверить документированные процессы среду непреднамеренно или сознательно могут
разработки ПО на предмет того, что в них учитывается быть внесены уязвимости.
 согласно требованиям PCI DSS информационная безопасность в течение всего цикла
(например, по безопасной разработки. Понимая, как критичные данные
аутентификации и ведению журналов обрабатываются приложением – в том числе во
регистрации событий); 6.3.c Проверить документированные процессы время хранения, передачи и нахождения в
 на основе отраслевых стандартов и разработки ПО на предмет того, что приложения памяти, возможно, будет проще определять
(или) рекомендаций; разрабатываются в соответствии с PCI DSS. места, где требуется защита данных.
 с учетом информационной 6.3.d Опросить разработчиков ПО на предмет того, что
безопасности в течение всего цикла
реализованы документированные процессы разработки
разработки ПО.
ПО.
Примечание: настоящее требование
относится к любому ПО собственной
разработки и заказному ПО,
разработанному третьим лицом.

6.3.1 Удалять все учетные записи 6.3.1 Проверить документированные процедуры Следует удалять учетные записи разработчиков,
разработчиков, тестовые учетные записи разработки ПО и опросить ответственных работников тестовые учетные записи и (или) учетные записи
и (или) учетные записи заказного на предмет того, что все допроизводственные учетные заказного приложения, имена пользователей и
приложения, идентификаторы записи и (или) учетные записи заказного приложения, пароли из производственного кода до перевода
пользователей и пароли перед идентификаторы пользователей и (или) пароли приложения в производственный режим или
передачей ПО заказчикам или удаляются перед передачей ПО заказчикам или предоставления приложения заказчикам,
переводом его в производственный переводом его в производственный режим. поскольку эти элементы могут использоваться
режим. для получения информации о функционировании
приложения. Обладание этой информацией
может помочь злоумышленникам
скомпрометировать приложение и связанные с
ним ДДК.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 64
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.3.2 Контролировать разрабатываемый 6.3.2.a Проверить документированные процедуры Уязвимости в разрабатываемом коде обычно
код на наличие потенциальных разработки ПО и опросить ответственных работников используются злоумышленниками для получения
уязвимостей (вручную или на предмет того, что все изменения разрабатываемого доступа к сети и компрометации ДДК.
автоматически) перед передачей программного кода обязательно контролируются Контроль кода должны выполнять опытные
готовых приложений заказчикам или (вручную или автоматически) с учетом следующих специалисты, знакомые с методиками такого
переводом их в производственный требований: контроля. Чтобы обеспечить объективный и
режим с соблюдением как минимум  контролировать изменения программного кода независимый контроль кода, такой контроль
следующих требований: должны выполнять лица, отличные от
лицами, которые не являются авторами этого
 контролировать изменения кода, и лицами, которые знают методики контроля разработчика кода. Автоматизированные
программного кода лицами, которые кода и методы безопасного программирования; средства или процессы могут заменять ручной
не являются авторами этого кода, и  контролируя программный код, убедиться, что он контроль кода, однако следует учитывать, что
лицами, которые знают методики разработан в соответствии с рекомендациями автоматизированным средством контроля кода
контроля кода и методы безопасного безопасного программирования (см. сложно или вообще невозможно обнаружить
программирования; Требование 6.5 PCI DSS); некоторые ошибки программирования.
 контролируя программный код,  вносить все необходимые корректировки до Благодаря исправлению ошибок
убедиться, что он разработан в выпуска ПО; программирования до того, как код
соответствии с рекомендациями разворачивается в производственной среде или
 результаты контроля кода рассматриваются и
безопасного программирования; передается заказчикам, код не создает
утверждаются руководством до выпуска ПО.
 вносить все необходимые потенциально используемые уязвимости в
корректировки до выпуска ПО; средах. Гораздо сложнее и дороже исправлять
ошибки в коде после развертывания приложения
 результаты контроля кода
рассматриваются и утверждаются или его запуска в производственных средах.
руководством до выпуска ПО. Формализованный контроль кода и его
(Продолжение на следующей утверждение руководством до выпуска ПО
странице) позволяет гарантировать, что код одобрен и
разработан в соответствии с политиками и
процедурами.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 65
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
Примечание: данное требование к 6.3.2.b Сделать выборку недавних изменений
контролю кода применимо ко всему разрабатываемого приложения и проверить ее на
разрабатываемому коду (как внутренних предмет того, что его код контролируется согласно
приложений, так и приложений, требованию 6.3.2.a, приведенному выше.
доступных из Интернета) как составная
часть цикла разработки системы.
Контроль программного кода может
проводиться компетентными
внутренними работниками или
третьими лицами. Общедоступные веб-
приложения также подлежат
применению дополнительных мер по
защите от текущих угроз и уязвимостей
после внедрения, согласно
требованию 6.6 стандарта PCI DSS.

6.4 Соблюдать процессы и процедуры 6.4 Проверить политики и процедуры на предмет Если контроль изменений не документируется и
контроля изменений по всем изменениям наличия в них следующих требований: не выполняется надлежащим образом, средства
системных компонентов. Эти процессы защиты могут быть непреднамеренно или
 отделить среды разработки и (или) тестирования от
должны включать в себя следующее: производственных сред; отделение реализовать с сознательно упущены или отключены, могут
использованием мер контроля доступа; возникать ошибки обработки или может быть
внедрен вредоносный код.
 разделить обязанности между работниками,
относящимися к средам разработки и (или)
тестирования и к производственным средам;
 не использовать производственные данные
(действующие PAN) для тестирования или
разработки;
 удалять тестовые данные и учетные записи из
системы перед переводом ее в производственный
режим;
 документировать процедуры контроля изменений,
относящиеся к внедрению обновлений безопасности
и изменений ПО.
6.4.1 Отделить среды разработки и (или) 6.4.1.а Проверить документацию сети и конфигурации В связи с постоянными изменениями сред
тестирования от производственных сред; сетевых устройств на предмет того, что среды разработки и тестирования, они, как правило,
отделение реализовать с разработки и (или) тестирования отделены от менее защищены, чем производственная среда.
использованием мер контроля доступа. производственных сред. Без надлежащего разделения производственная

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 66
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.4.1.b Проверить настройки механизмов контроля среда и ДДК могут быть скомпрометированы
доступа на предмет того, что они внедрены для вследствие менее строгих конфигураций защиты
разделения сред разработки и (или) тестирования и и возможных уязвимостей в среде тестирования
производственной среды (сред). или разработки.

6.4.2 Разделить обязанности между 6.4.2 Проследить за процессами и опросить Уменьшая количество работников, имеющих
работниками сред разработки и (или) работников, относящихся к средам разработки и (или) доступ к производственной среде и ДДК, можно
тестирования и работниками тестирования, и работников, относящихся к минимизировать риск и упростить контроль за
производственных сред. производственным средам, на предмет того, что тем, чтобы доступ был ограничен только теми
обязанности работников сред разработки и (или) лицами, у которых есть на то служебная
тестирования и работников производственных сред необходимость.
разделены. Цель данного требования состоит в том, чтобы
отделить функции разработки и тестирования от
производственных функций. Например,
разработчик может использовать учетную запись
с правами уровня администратора в среде
разработки и иметь отдельную учетную запись с
правами доступа на уровне пользователя в
производственной среде.

6.4.3 Не использовать производственные 6.4.3 Проверить процессы тестирования и опросить В средах разработки или тестирования обычно
данные (действующие PAN) для работников на предмет того, что внедрены процедуры, реализованы менее жесткие защитные меры.
тестирования или разработки. исключающие использование производственных Использование в такой среде производственных
данных (действующих PAN) для тестирования или данных дает возможность злоумышленникам
разработки. получить к ним несанкционированный доступ
(например, к ДДК).
6.4.3.b Проверить выборку данных тестовой среды на
предмет того, что производственные данные
(действующие PAN) не используются для
тестирования или разработки.

6.4.4 Удалить тестовые данные и 6.4.4.a Проследить за процессами проведения Тестовые данные и учетные записи следует
учетные записи из системных тестирования и опросить работников на предмет того, удалить перед переводом системных
компонентов перед переводом системы что все тестовые данные и учетные записи удаляются компонентов в производственный режим,
в производственный режим. из системы перед переводом ее в производственный поскольку эти элементы могут использоваться
режим. для получения информации о функционировании

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 67
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.4.4.b Проверить выборку данных и учетных записей приложения или системы. Обладая этой
из недавно установленных или обновленных информацией, злоумышленники могут
производственных систем на предмет того, что все скомпрометировать систему и связанные с ней
тестовые данные и учетные записи удаляются из ДДК.
системы перед переводом ее в производственный
режим.

6.4.5 Включить в процедуры контроля 6.4.5.a Проверить документированные процедуры Если обновления ПО и оборудования, а также
изменений следующее: контроля изменений на предмет того, что процедуры обновления безопасности не управляются
требуют: должным образом, то влияние таких системных
изменений может быть не до конца понято и
 документировать влияние изменений;
может привести к нежелательным последствиям.
 документировать согласования изменений, со
стороны уполномоченных лиц;
 проводить функциональное тестирование на
предмет того, что внесенные изменения не
снижают защищенность системы;
 предусмотреть процедуры отмены изменений.
6.4.5.b Опросить ответственных работников по
выборке системных компонентов, чтобы определить
недавние изменения. Отследить эти изменения с
помощью соответствующей документации по контролю
изменений. Выполнить следующие действия по
каждому изученному изменению:

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

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 68
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.4.5.3 Функциональное тестирование, 6.4.5.3.a Для каждого изменения из выборки Следует выполнять тщательное тестирование,
чтобы проверить, что изменения не убедиться, что функциональное тестирование чтобы проверить, что после внедрения
снижают защищенность системы. выполнено для того, чтобы убедиться, что изменения уровень безопасности среды не
изменение не снижало защищенность системы. снизится. Цель тестирования состоит в том,
чтобы подтвердить, что все существующие
6.4.5.3.b В отношении изменений разрабатываемого
защитные меры по-прежнему работают, что они
кода убедиться, что все обновления протестированы
заменяются защитными мерами такой же
на соответствие требованию 6.5 PCI DSS перед их
надежности или что они усиливаются после
развертыванием в производственной среде.
любых изменений в среде.

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 69
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.4.6 После выполнения существенных 6.4.6 Проверить по выборке системных компонентов Наличие процессов анализа существенных
изменений все соответствующие записи изменений, опросить работников и изменений позволяет гарантировать, что все
требования PCI DSS должны быть проследить за системами и (или) сетями, которые соответствующие защитные меры PCI DSS
выполнены на всех новых или подверглись изменениям, на предмет того, что применены для каждой системы или сети,
измененных системах или сетях, и применимые требования PCI DSS были выполнены, которые были добавлены или изменены в среде,
документация обновлена в случае и документация обновлена в рамках изменений. находящейся в области применимости
необходимости. стандарта.
Примечание: до 31 января 2018 года это Внедрение этой проверки в процесс управления
требование носит рекомендательный изменениями гарантирует, что списки устройств
характер, а после этой даты и стандарты конфигураций поддерживаются
становится обязательным актуальными, и защитные меры применяются
требованием. там, где это необходимо.
В процесс управления изменениями следует
включить доказательства того, что требования
PCI DSS выполнены или сохранены посредством
повторяющегося процесса. Примерами
требований PCI DSS, которые могут быть
затронуты, являются, среди прочего:
 актуализировать схему сети в
соответствии с изменениями;
 сконфигурировать системы согласно
стандартам конфигурации с изменением
всех паролей по умолчанию и
отключением неиспользуемых сервисов;
 защитить системы с помощью
необходимых мер, например,
мониторинга целостности файлов,
антивирусного ПО, обновлений, ведения
журналов аудита;
 не хранить критичные
аутентификационные данные (КАД),
хранение всех ДДК документировать и
включить в политики и процедуры
хранения данных;
 включить новые системы в
ежеквартальный процесс сканирования
на наличие уязвимостей.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 70
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.5 Управлять распространенными 6.5.a Проверить политики и процедуры разработки ПО Прикладной уровень подвержен высокому риску
уязвимостями программного кода в на предмет того, что разработчики обязаны не реже и может являться целью как внутренних, так и
процессе разработки ПО следующим одного раза в год проходить обучение актуальным внешних угроз.
образом: методикам безопасного программирования, основанным Требования 6.5.1–6.5.10 представляют собой
на отраслевых рекомендациях и руководствах.
 обучать разработчиков не реже одного минимально необходимые защитные меры,
раза в год актуальным методикам подлежащие выполнению, и организации
безопасного программирования, должны внедрять те методики безопасного
включая информацию о том, как 6.5.b Проверить документацию об обучении на предмет программирования, которые применимы к
избежать распространенных того, что разработчики проходят обучение актуальным определенным технологиям в их среде.
программных уязвимостей; методикам безопасного программирования не реже Разработчики приложений должны быть
 разрабатывать приложения в одного раза в год, в том числе тому, как избегать надлежащим образом подготовлены, чтобы
соответствии с основными принципами распространенных уязвимостей программирования. определять и устранять проблемы, связанные с
безопасного программирования. этими и другими распространенными
6.5.c Убедиться, что имеются реализованные процессы,
Примечание: уязвимости, предназначенные для защиты, по крайней мере, от уязвимостями программного кода.
перечисленные в требованиях 6.5.1 – следующих уязвимостей: Осведомленность работников о правилах
6.5.10 были актуальны в соответствии с безопасного программирования позволит свести
отраслевыми рекомендациями, к минимуму количество уязвимостей,
существовавшими на момент публикации возникающих из-за низкого качества кода.
настоящей версии PCI DSS. Тем не Обучение разработчиков может осуществляться
менее, по мере обновления отраслевых как самой организацией, так и третьими лицами
рекомендаций по управлению и должно быть применимо к используемой
уязвимостями (таких, как Руководство технологии.
OWASP, Список SANS CWE Top 25, CERT По мере изменений отраслевых методик
Secure Coding и т. д.) следует безопасного программирования должны
использовать их актуальные версии. соответственно обновляться методики
программирования и обучения разработчиков в
организации, чтобы бороться с новыми угрозами
(например, атаками на извлечение данных из
памяти, т.н. memory scraping).
Уязвимости, указанные в требованиях 6.5.1–
6.5.10, представляют собой лишь минимальный
список. Организация самостоятельно
обеспечивает соответствие тенденциям в
области уязвимостей и внедряет
соответствующие меры безопасности в свои
методики безопасного программирования.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 71
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
Примечание: требования 6.5.1–6.5.6, приведенные ниже, распространяются на все приложения
(внешние или внутренние).

6.5.1 Инъекции, в частности, SQL- 6.5.1 Проверить политики и процедуры разработки ПО Инъекции кода, в частности SQL-инъекции,
инъекции, а также инъекции LDAP, и опросить ответственных работников на предмет того, являются распространенным способом
XPath, команд ОС и др. что в методиках программировании учтены уязвимости компрометации приложений. Инъекция
к инъекциям, в том числе: происходит, когда предоставленные
пользователем данные передаются
 введенные пользователями данные проверяются
интерпретатору как часть команды или запроса.
на предмет того, что они не могут изменить
Введенные злоумышленником вредоносные
значение существующих команд и запросов;
данные некорректно обрабатываются
 используются параметризованные запросы. интерпретатором, вызывая нежелательные
команды или изменяя данные. Это позволяет
злоумышленнику атаковать компоненты внутри
сети через приложение, инициировать такие
атаки, как переполнение буфера, получить
доступ к конфиденциальной информации или
информации о функциональных возможностях
серверного приложения.
Следует проверять информацию перед
отправкой в приложение (например, проверяя
все буквенные символы, сочетания буквенных и
цифровых символов и т. д.)

6.5.2 Переполнение буфера 6.5.2 Проверить политики и процедуры разработки ПО Переполнение буфера происходит, когда
и опросить ответственных работников на предмет того, приложение не имеет соответствующих
что методики программирования учитывают ограничений при проверке буферного
уязвимости переполнения буфера, в том числе: пространства. Это может привести к тому, что
информация, содержащаяся в буфере,
 проверяют границы буфера;
вытесняется за пределы области буферной
 усекают строки ввода. памяти в область исполняемой памяти. Когда это
происходит, злоумышленник получает
возможность внедрить в буфер вредоносный код
и затем поместить этот вредоносный код в
область исполняемой памяти путем
переполнения буфера. Затем вредоносный код
выполняется, что зачастую позволяет
злоумышленнику получить удаленный доступ к
приложению и (или) зараженной системе.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 72
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.5.3 Небезопасное криптографическое 6.5.3 Проверить политики и процедуры разработки ПО Приложения, которые не используют для
хранилище. и опросить ответственных работников на предмет того, хранения данных стойкие криптографические
что методики программирования учитывают функции надлежащим образом, подвергаются
небезопасность криптографического хранилища повышенному риску компрометации и делают
следующим образом: ДДК и (или) учетные данные для
аутентификации уязвимее. Если злоумышленник
 защищают от криптографических уязвимостей;
сможет использовать уязвимости
 используют стойкие криптографические криптографических процессов, он, возможно,
алгоритмы и надежные ключи. получит доступ к зашифрованным данным в
открытом виде.

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 73
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.5.5 Некорректная обработка ошибок. 6.5.5 Проверить политики и процедуры разработки ПО Вследствие некорректной обработки ошибок в
и опросить ответственных работников на предмет того, приложении может происходить
что методики программирования учитывают непреднамеренная утечка информации о
уязвимости некорректной обработки ошибок и конфигурации и внутренних рабочих процессах,
предотвращают утечку информации через сообщения или же раскрытие закрытой информации.
об ошибках (например, отображая общие, а не Злоумышленники используют эти уязвимости,
конкретные сведения об ошибке). чтобы похитить критичные данные и (или)
компрометировать систему. Если
злоумышленник сможет вызвать появление
ошибок, которые приложение не сможет
правильно обработать, существует возможность
получения злоумышленником подробной
информации о системе, возникновения отказов в
обслуживании, нарушения работы системы
безопасности или сбоя сервера. Например,
сообщение «введен неправильный пароль»
говорит злоумышленнику о том, что
использовался верный идентификатор
пользователя и теперь необходимо
сосредоточить свои усилия только на подборе
пароля. Следует использовать менее
конкретные сообщения об ошибках, например:
«данные не могут быть проверены».

6.5.6 Все уязвимости с высоким уровнем 6.5.6 Проверить политики и процедуры разработки ПО Все уязвимости, которым в процессе
критичности, идентифицированные в и опросить ответственных работников на предмет того, ранжирования рисков организации был присвоен
процессе обнаружения уязвимостей (в что методики программирования учитывают любые высокий уровень критичности (в соответствии с
соответствии с требованием 6.1 уязвимости с высоким уровнем критичности, которые требованием стандарта 6.1) и которые могут
стандарта PCI DSS). могут повлиять на работу приложения (в соответствии повлиять на работу приложения, должны быть
с требованием 6.1 стандарта PCI DSS). идентифицированы и учтены во время
разработки приложения.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 74
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
Веб-приложениям, как внутренним, так и
внешним (общедоступным), свойственны
Примечание: требования 6.5.7–6.5.10, приведенные ниже, распространяются на веб-приложения и уникальные риски для безопасности, которые
интерфейсы приложений связаны с архитектурой веб-приложений, а также
(внешние или внутренние): относительной простотой и
распространенностью компрометации.

6.5.7 Межсайтовый скриптинг (XSS) 6.5.7 Проверить политики и процедуры разработки ПО Межсайтовый скриптинг (XSS) происходит, когда
и опросить ответственных работников на предмет того, приложение отправляет предоставленные
что методики программирования учитывают пользователем данные в веб-браузер без
межсайтовый скриптинг (XSS), в том числе: предварительной проверки или шифрования
этого содержимого. Межсайтовый скриптинг
 проверяют все параметры перед их включением в
позволяет злоумышленникам выполнять
код;
сценарии в браузере жертвы для перехвата
 используют контекстно-зависимое изолирование. сеансов пользователя, дефейса веб-сайтов,
возможного внедрения червей и т. д.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 75
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.5.8 Ошибки механизмов контроля 6.5.8 Проверить политики и процедуры разработки ПО Прямая ссылка на объект возникает, когда
доступа (например, небезопасные и опросить ответственных работников на предмет того, разработчик раскрывает ссылку на внутренний
прямые ссылки на объекты, отсутствие что методики программирования учитывают ошибки объект, такой как файл, каталог, запись в базе
ограничения доступа по URL, обход механизмов контроля доступа (например, данных или ключ, в виде URL-адреса или
директорий и отсутствие ограничения небезопасные прямые ссылки на объекты, отсутствие параметра формы. Злоумышленники могут
прав доступа пользователя к функциям). ограничения доступа по URL, обход директорий), в том использовать эти ссылки для доступа к другим
числе: объектам без авторизации.
 обеспечивают надлежащую аутентификацию Следует неукоснительно применять меры
пользователей; контроля доступа на уровне представления и
 проверяют входные данные; бизнес-логики для всех URL-адресов. Часто
защитить критичные функциональные
 не раскрывают пользователям прямые ссылки на
возможности можно, только исключив
внутренние объекты;
отображение ссылок или URL-адресов
 пользовательские интерфейсы запрещают доступ несанкционированным пользователям.
к несанкционированным функциям. Злоумышленники могут использовать эту
уязвимость для получения доступа и выполнения
несанкционированных операций путем прямого
доступа к URL-адресам.
Злоумышленник может просканировать
структуру директорий веб-сайта (обход
директорий), чтобы получить
несанкционированный доступ к информации, в т.
ч. информации о функционировании сайта для
последующей эксплуатации.
Если пользовательские интерфейсы разрешают
доступ к несанкционированным функциям, это
может позволить злоумышленникам получить
доступ к привилегированным учетным данным
или ДДК. Доступ к прямым ссылкам на критичные
ресурсы должен быть разрешен только
авторизованным пользователям. Ограничивая
доступ к информационным ресурсам, можно
предотвратить передачу ДДК на
неавторизованные ресурсы.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 76
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.5.9 Подделка межсайтовых запросов 6.5.9 Проверить политики и процедуры разработки ПО В случае подделки межсайтовых запросов
(CSRF). и опросить ответственных работников на предмет того, (CSRF) браузер жертвы отправляет
что методики программирования учитывают предварительно аутентифицированный запрос в
возможность подделки межсайтовых запросов (CSRF) уязвимое веб-приложение, что позволяет
и гарантируют, что приложения не полагаются на злоумышленнику совершить любые действия,
учетные данные для авторизации и токены, которые которые может совершить жертва (например,
автоматически отправляются браузерами. обновление сведений о счете, совершение
покупок или даже вход в приложение).

6.5.10 Противодействие компрометации 6.5.10 Проверить политики и процедуры разработки Безопасная аутентификация и управление
механизмов аутентификации и ПО и опросить ответственных работников на предмет сеансами не позволяют злоумышленнику
управления сеансами того, что методики программирования учитывают скомпрометировать подлинные учетные данные,
возможность атак на механизмы аутентификации и ключи или сеансовые токены, с помощью
управления сеансами, в том числе, следующим которых в некоторых случаях злоумышленник
образом: может выдать себя за авторизованного
пользователя.
 помечают сеансовые токены (например, cookies)
флагом "secure";
 не указывают идентификатор сеанса в URL-
адресе;
 устанавливают соответствующие ограничения по
длительности сеанса и ротации идентификаторов
после успешного входа.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 77
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.6 Постоянно управлять новыми угрозами 6.6 Для общедоступных веб-приложений убедиться Общедоступные веб-приложения являются
и уязвимостями общедоступных веб- следующим образом в том, что реализован один из основной целью для злоумышленников, и плохо
приложений и обеспечить этим следующих методов: написанные веб-приложения могут упростить
приложениям защиту от известных атак злоумышленникам получение доступа к
 проверить документированные процессы и отчеты о
одним из следующих методов: результатах анализа защищенности приложений и критичным данным и системам. Анализ
приложений или установка межсетевого экрана
 проверять общедоступное веб- опросить работников на предмет того, что анализ (с
приложение на наличие уязвимостей, использованием средств или методов ручного или уровня веб-приложений требуются для того,
используя методы или инструменты автоматизированного анализа защищенности чтобы снижать количество компрометаций веб-
ручного или автоматизированного приложений) общедоступных веб-приложений приложений, связанных с недостаточным
анализа защищенности приложений не проходит следующим образом: контролем процессов программирования или
реже одного раза в год, а также после - не реже раза в год; управления приложением.
внесения любых изменений; - после любых изменений;  Средства и методы ручной или
Примечание: данный анализ - организацией, специализирующейся на автоматизированной оценки защищенности
отличается от сканирования на безопасности приложений; приложений используются для анализа
наличие уязвимостей, выполняемого и (или) проверки приложений на наличие
- анализ включает как минимум проверку на
согласно требованию 11.2. уязвимостей
наличие всех уязвимостей, приведенных в
требовании 6.5;  Межсетевые экраны уровня веб-приложений
 устанавливать автоматизированное используются для фильтрации и блокировки
техническое средство (например, - все уязвимости устраняются;
ненужного трафика на уровне приложений.
межсетевой экран уровня веб- - безопасность приложения анализируется При использовании совместно с межсетевым
приложений) перед общедоступными повторно после устранения уязвимостей. экраном сетевого уровня, правильно
веб-приложениями для непрерывной  Проверить настройки системной конфигурации и сконфигурированный межсетевой экран
проверки всего трафика, опросить ответственных работников на предмет того, уровня веб-приложений предотвращает атаки
предназначенное для обнаружения и что автоматизированное техническое средство уровня приложений, если приложения
предупреждения веб-атак. (например, межсетевой экран уровня веб- настроены ненадлежащим образом или
приложений), обнаруживающее и предупреждающее имеются уязвимости в коде. Это может быть
веб-атаки, реализовано следующим образом: достигнуто за счет сочетания технологии и
- расположено перед общедоступными веб- процесса. Решения, основанные на
приложениями, чтобы обнаруживать и процессах, должны иметь механизмы,
предупреждать веб-атаки; которые способствуют своевременному
- постоянно запущено и обновляется ответу на уведомления, для того, чтобы
соответствующим образом; отвечать цели данного требования,
- создает журналы регистрации событий; заключающейся в предотвращении атак.
- настроено на блокирование веб-атак или на Примечание: «организацией,
генерацию соответствующих уведомлений, специализирующейся на безопасности
которые будут незамедлительно изучены. приложений», может быть сторонняя компания
или внутренняя организация, работники
которой специализируются на безопасности
приложений и могут доказать независимость
от группы разработчиков.
Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 78
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
6.7 Гарантировать, что политики 6.7 Проверить документацию и опросить работников на Работники должны знать и соблюдать политики
безопасности и операционные процедуры предмет того, что политики безопасности и безопасности и операционные процедуры, чтобы
разработки и поддержки безопасных операционные процедуры разработки и поддержки постоянно обеспечивать системам и
систем и приложений документированы, безопасных систем и приложений: приложениям безопасную разработку и защиту
используются и известны всем от уязвимостей.
 документированы;
заинтересованным лицам.
 используются;
 известны всем заинтересованным лицам.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 79
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Внедрять строгие меры контроля доступа
Требование 7. Ограничивать доступ к ДДК в соответствии со служебной необходимостью.

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

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

Требования PCI DSS Проверочные процедуры Пояснение


7.1. Ограничить доступ к 7.1 Проверить документированную политику контроля доступа Чем больше людей имеют доступ к ДДК, тем
системным компонентам и ДДК на предмет того, что она отражает требования 7.1.1–7.1.4 выше риск того, что учетные записи
только теми лицами, которым следующим образом: пользователей будут использоваться во
такой доступ требуется в вредоносных целях. Ограничивая доступ только
 определением прав доступа и назначением привилегий
соответствии с их служебными для каждой роли; теми лицами, которым он необходим в
обязанностями. служебных целях, организация может
 ограничением доступа привилегированных учетных
предотвратить ненадлежащее обращение с ДДК,
записей только тем набором прав, который им минимально
связанное с неопытностью или злым умыслом.
необходим для выполнения своих должностных
обязанностей;
 назначением прав доступа согласно роли и должностным
обязанностям конкретного работника;
 документированным утверждением (в письменной или
электронной форме) всех прав доступа уполномоченными
сторонами с указанием списка конкретных утвержденных
привилегий.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 80
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
7.1.1 Определить необходимые 7.1.1 Сделать выборку ролей и проверить их на предмет Для того чтобы доступ к ДДК ограничивался
права доступа для каждой роли, того, что потребности в правах доступа для каждой роли только теми лицами, которым он необходим,
включая: определены и включают: сначала нужно определить:
 системные компоненты и  системные компоненты и информационные ресурсы, — необходимые права доступа для каждой
информационные ресурсы, доступ к которым необходимо предоставить каждой роли (например, системного администратора,
доступ к которым роли для выполнения должностных обязанностей; работника колл-центра, продавца),
необходимо предоставить  список прав доступа, необходимых каждой роли для — системы, устройства и данные, доступ к
каждой роли для выполнения должностных обязанностей. которым необходим для каждой роли,
выполнения должностных
обязанностей; — уровень прав доступа, необходимых каждой
роли для реального выполнения своих
 необходимый уровень
должностных обязанностей.
привилегий (например,
пользовательский, Как только роли и необходимые им права
администраторский и т. д.) доступа определены, лицам могут быть
для доступа к ресурсам. предоставлены соответствующие права
доступа.

7.1.2 Ограничить права доступа 7.1.2.a Опросить работников, отвечающих за назначение Назначая привилегированные идентификаторы,
идентификаторам прав доступа, на предмет того, что доступ идентификаторам важно предоставлять лицам только те права,
привилегированных привилегированных пользователей: которые им минимально необходимы для
пользователей только тем выполнения должностных обязанностей
 назначен только тем ролям, которым он явно
набором прав, который («минимально необходимый набор прав»).
необходим;
минимально необходим им для Например, администратор баз данных или
выполнения своих должностных  ограничен только тем набором прав, который администратор резервного копирования не
обязанностей. минимально необходим для выполнения должностных должны иметь те же полномочия, что и
обязанностей. администратор всей системы.
(Продолжение на следующей странице)

7.1.2.b Сделать выборку учетных записей Назначая минимально необходимый набор прав,
привилегированных пользователей и опросить руководящих можно предотвратить ошибочное или случайное
работников на предмет того, что назначенные полномочия: изменение конфигурации приложения или его
настроек безопасности со стороны
 необходимы для выполнения этим лицом своих
пользователей, не обладающих достаточными
должностных обязанностей;
знаниями о приложении. Устанавливая
 ограничен только тем набором прав, который минимально необходимые права доступа, можно
минимально необходим для выполнения должностных также свести к минимуму ущерб, если
обязанностей. постороннее лицо получит доступ к
идентификатору пользователя.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 81
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
7.1.3 Назначать права доступа 7.1.3 Сделать выборку идентификаторов пользователей и Как только необходимые права доступа для
согласно роли и должностным опросить руководящих работников на предмет того, что ролей пользователей (согласно
обязанностям конкретного полномочия назначены согласно роли и должностным требованию 7.1.1 стандарта PCI DSS)
работника. обязанностям соответствующего работника. определены, права доступа удобно
предоставляются лицам согласно их ролям и
должностным обязанностям благодаря
использованию уже созданных ролей.

7.1.4 Требовать документы, 7.1.4 Сделать выборку учетных записей пользователей и Утверждающий документ (например, в
утверждающие права доступа и сравнить их с утверждающими документами на предмет письменном или электронном виде) гарантирует,
завизированные того, что: что права доступа и полномочия известны и
уполномоченными лицами, с утверждены руководством, а доступ необходим
 имеется документ, утверждающий назначенные права
указанием необходимых прав для выполнения должностных обязанностей.
доступа;
доступа.
 эти права доступа утверждены уполномоченными
лицами;
 указанные полномочия соответствуют ролям,
назначенным работнику.
7.2 Установить систему (или 7.2 Проверить настройки системы и документацию вендора на Если отсутствует механизм ограничения доступа
системы) контроля доступа к предмет того, что система (или системы) контроля доступа согласно служебной необходимости,
системным компонентам, которая реализована следующим образом: пользователю, без его ведома, может быть
ограничивает доступ в предоставлен доступ к ДДК. Системы контроля
соответствии со служебной доступа автоматизируют процесс ограничения
необходимостью пользователя и доступа и назначения полномочий. Кроме того,
которая настроена запрещать все, настройка на запрет всего по умолчанию
что явным образом не разрешено. исключает получение кем-либо прав доступа до
Система (или системы) контроля тех пор, пока не будет установлено правило,
доступа должна: напрямую предоставляющее такие права.
Организации могут иметь одну или несколько
7.2.1 охватывать все системные 7.2.1 проверить, что системы контроля доступа внедрены на систем контроля доступа для управления
компоненты; всех системных компонентах; доступом пользователей.

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 82
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
7.3 Гарантировать, что политики 7.3 Проверить документацию и опросить работников на Работники должны знать и соблюдать политики
безопасности и операционные предмет того, что политики безопасности и процедуры безопасности и операционные процедуры, чтобы
процедуры ограничения доступа к ограничения доступа к ДДК: гарантировать, что контроль доступа
ДДК документированы, выполняется непрерывно, предоставляется
 документированы;
используются и известны всем только по служебной необходимости и с
 используются;
заинтересованным лицам. минимально необходимым набором прав.
 известны всем заинтересованным лицам.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 83
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требование 8. Идентифицировать и аутентифицировать доступ к системным компонентам
Назначение уникального идентификатора каждому лицу, имеющему доступ, обеспечивает однозначную подотчетность каждого лица в
его действиях. Если такая подотчетность реализована, то действия, производимые с критичными данными и системами, производятся
известными и авторизованными пользователями и процессами и связь между такими действиями и совершившими их пользователями
или процессами может быть отслежена.
Эффективность пароля во многом зависит от устройства и реализации системы аутентификации, в частности от того, насколько часто
злоумышленник может пытаться ввести пароль и какие меры безопасности предпринимаются для защиты паролей пользователей в
точке ввода, в момент передачи и во время хранения.
Примечание: данные требования применимы ко всем учетным записям с административными полномочиями, включая учетные
записи POS-терминалов, а также ко всем учетным записям, которые используются для просмотра ДДК или доступа ним, или для
доступа к системам, содержащим ДДК. Сюда относятся учетные записи производителей и других третьих лиц (например, для
поддержки или обслуживания). Данные требования не применимы к учетным записям, используемым клиентами (например,
держателями карт).
Однако требования 8.1.1, 8.2, 8.5, 8.2.3–8.2.5 и 8.1.6–8.1.8 не относятся к учетным записям пользователей платежных приложений
на POS-терминалах, которые обладают доступом только к одному номеру карты в один момент времени для проведения одной
транзакции (например, учетные записи кассиров).

Требования PCI DSS Проверочные процедуры Пояснение


8.1 Определить и внедрить 8.1.a Проверить процедуры и подтвердить, что они Уникально идентифицируя каждого
следующим образом политики и регламентируют процессы для выполнения каждого из пользователя – вместо использования одного
процедуры, обеспечивающие нижеуказанных положений 8.1.1–8.1.8 идентификатора для нескольких работников –
надлежащее управление организация может устанавливать
идентификацией пользователей, не 8.1.b Убедиться следующим образом в том, что индивидуальную ответственность работников за
являющихся клиентами, и реализованы процедуры, предназначенные для управления их действия и эффективно вести журнал
администраторов на всех системных идентификацией пользователей: регистрации событий по каждому из них. Это
компонентах: поможет ускорить разрешение проблем и
противодействие им, когда обнаруживаются
8.1.1 Назначить всем пользователям 8.1.1 Опросить административных работников на предмет случаи некорректного использования или злого
уникальные учетные записи, прежде того, что всем пользователям назначены уникальные умысла.
чем предоставить им доступ к учетные записи для доступа к системным компонентам или
системным компонентам или ДДК. ДДК.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 84
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
8.1.2 Контролировать добавление, 8.1.2 В выборке учетных записей привилегированных и Чтобы гарантировать, что учетные записи
удаление и изменение учетных обычных пользователей проверить связанные с ними пользователей, получивших доступ к системам,
записей пользователей, учетных авторизации и проверить настройки системы на предмет действительны и правомочны, следует
данных и иных объектов того, что каждая учетная запись обычного и применять строгие процессы к любым
идентификации. привилегированного пользователей наделена только теми изменениям учетных записей пользователей и
полномочиями, которые указаны в утверждающем иных учетных данных (в т. ч. добавлению новых,
документе. изменению или удалению имеющихся).

8.1.3 Немедленно отзывать доступ у 8.1.3.a Сделать выборку пользователей, уволенных за Если работник уволился из компании и все еще
каждого уволенного пользователя. прошедшие шесть месяцев, и проанализировать текущие имеет доступ к сети через свою учетную запись,
списки доступа – как локального, так и удаленного, на существует риск несанкционированного или
предмет того, что учетные записи таких злонамеренного доступа к ДДК через старую
пользователей заблокированы или удалены из списков и (или) неиспользуемую учетную запись со
доступа. стороны злоумышленника или бывшего
работника. Чтобы предотвращать
8.1.3.b Убедиться, что все физические средства несанкционированный доступ, следует сразу (как
аутентификации (например, смарт-карты, токены и т. д.) можно скорее) после ухода работника отозвать
были возвращены или деактивированы. пользовательские учетные данные и другие
средства аутентификации.

8.1.4 Удалять и (или) блокировать 8.1.4 Проверить учетные записи пользователей на Нерегулярно используемые учетные записи
неактивные учетные записи не позже предмет того, что любые учетные записи, неактивные часто подвергаются атакам в связи с меньшей
чем через 90 дней. более 90 дней, удаляются или блокируются. вероятностью того, что изменения (например,
смена пароля) будут замечены. Следовательно,
такими учетными записями легче
воспользоваться для доступа к ДДК.

8.1.5 Управлять учетными записями, 8.1.5.a Опросить работников и проверить процессы Предоставляя вендорам доступ в сеть
которые используются третьими управления учетными записями, которые используют организации круглосуточно и без выходных для
сторонами для удаленного доступа, третьи стороны для доступа, поддержки и обслуживания того, чтобы они могли по необходимости
поддержки и обслуживания системных компонентов, на предмет того, что учетные обслуживать системы организации, организация
системных компонентов, следующим записи, которые используются для удаленного доступа: увеличивает вероятность несанкционированного
образом: доступа как со стороны пользователя из среды
 отключаются, когда они не используются;
вендора, так и со стороны злоумышленника,
 включать только на  включаются только тогда, когда они нужны третьей который обнаружит и сможет использовать
необходимый промежуток стороне и отключаются, когда они не используются. внешнюю точку входа в сеть, постоянно
времени и отключать, когда они
8.1.5.b Опросить работников и проверить процессы на доступную для подключений. Включение доступа
не используются;
предмет того, что во время выполнения работ учетные только на необходимые промежутки времени и
 вести мониторинг, когда они отключение, когда в нем больше нет
записи, используемые третьими сторонами для
используются. необходимости, предотвращает ненадлежащее
удаленного доступа, контролируются.
использование таких подключений.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 85
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
Ведя мониторинг доступа вендоров, можно
убедиться в том, что они получают доступ только
к необходимым системам и только в
согласованный промежуток времени.

8.1.6 Блокировать идентификатор 8.1.6.a Проверить настройки системной конфигурации в Если механизм блокировки учетных записей не
пользователя не более чем после выборке системных компонентов на предмет того, что в реализован, злоумышленник может непрерывно
шести неудачных попыток входа параметрах аутентификации установлено требование, пытаться подобрать пароль вручную или с
подряд. чтобы учетная запись пользователя блокировалась не использованием автоматизированных средств
более чем после шести неудачных попыток входа. (программ перебора паролей) до тех пор, пока
ему это не удастся, и он не получит доступ к
8.1.6.b Дополнительная проверочная процедура для учетной записи пользователя.
оценки поставщиков услуг: проверить внутренние
процессы и клиентскую и (или) пользовательскую Примечание: проверочная процедура 8.1.6.b
документацию и проследить за внедренными процессами является дополнительной процедурой,
на предмет того, что учетные записи пользователей, не применяемой только для организаций, которые
являющихся клиентами, временно блокируются не более определены как поставщики услуг.
чем после шести неудачных попыток входа.

8.1.7 Установить период блокировки 8.1.7 Проверить настройки системной конфигурации в Если учетная запись пользователя блокируется
идентификатора пользователя выборке системных компонентов на предмет того, что в результате непрекращающихся попыток
равным 30 минутам или до тех пор, учетная запись пользователя блокируется не менее чем на подбора пароля, защитные меры в виде
пока его не разблокирует 30 минут, либо до тех пор, пока его не разблокирует задержки активации заблокированных учетных
администратор. администратор. записей помогут остановить злоумышленника от
непрерывного подбора пароля (он будет
вынужден остановиться, по крайней мере, на
30 минут до автоматической активации учетной
записи). Кроме того, если будет запрошена
повторная активация, администратор или
специалист технической поддержки может
установить, действительно ли ее запросил
владелец учетной записи.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 86
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
8.1.8 Если сеанс был неактивен в 8.1.8 Проверить настройки системной конфигурации в Когда пользователи отлучаются от работающих
течение 15 минут и больше, выборке системных компонентов на предмет того, что компьютеров, имеющих доступ к критичным
требовать у пользователя пройти сеанс работы пользователя или система блокируется не системным компонентам сети или ДДК, эти
повторную аутентификацию для позднее чем через 15 минут простоя. компьютеры могут использоваться кем-нибудь в
возобновления работы терминала отсутствие этих пользователей, что приведет к
или сеанса. несанкционированному доступу к учетной записи
и (или) некорректному ее использованию.
Повторная проверка подлинности может быть
применена на системном уровне для защиты
всех сеансов, запущенных на компьютере, или
на уровне приложений.

8.2 Помимо назначения уникального 8.2 Чтобы убедиться, что аутентификация пользователей Если данные методы аутентификации
идентификатора, обеспечить для доступа к среде ДДК осуществляется с помощью использовать совместно с уникальными
надлежащее управление уникального идентификатора и дополнительного фактора учетными записями, то можно защитить
аутентификацией пользователей, не аутентификации (например, пароля), выполнить следующее: уникальные учетные записи пользователей от
являющихся клиентами, и компрометации, поскольку злоумышленнику
 проверить документацию, описывающую используемый
администраторов на уровне всех метод (методы) аутентификации; нужно знать и уникальный идентификатор, и
системных компонентов, применяя пароль (или другой используемый элемент
 посмотреть порядок аутентификации по каждому
хотя бы один из следующих методов аутентификации). Стоит учесть, что цифровой
используемому методу аутентификации и типу
аутентификации всех пользователей: сертификат является подходящим вариантом
системного компонента на предмет того, что
для аутентификации по методу «обладания
 обладание информацией аутентификация осуществляется согласно указанному в
(например, паролем или парольной документации методу (методам) аутентификации. предметом», если он уникален для каждого
фразой); конкретного пользователя.
 обладание предметом (например, Поскольку одним из первых действий, которые
аппаратным токеном или смарт- злоумышленник предпринимает для
картой); компрометации системы, является
 обладание параметрами использование простых или отсутствующих
(например, биометрическими). паролей, важно реализовать надежные
процессы управления аутентификацией.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 87
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
8.2.1 Привести все учетные данные 8.2.1.a Проверить документацию вендора и настройки Многие сетевые устройства и приложения
для аутентификации (например, системной конфигурации на предмет того, что пароли передают незашифрованные пароли (в
пароли и (или) парольные фразы) к защищены с использованием стойкой криптографии во читаемом виде) по сети и (или) хранят их в
нечитаемому виду с использованием время их передачи и хранения. незашифрованном виде. Злоумышленник может
стойкой криптографии, когда они без труда перехватить незашифрованные
передаются или хранятся на любых 8.2.1.b Проверить файлы паролей в выборке системных пароли при их передаче, используя анализатор
системных компонентах. компонентов на предмет того, что пароли хранятся в пакетов, или получить прямой доступ к
нечитаемом виде. незашифрованным паролям в файлах, в которых
8.2.1.c Проверить передачу данных в выборке системных они хранятся, и использовать эти данные для
компонентов на предмет того, что пароли передаются в получения несанкционированного доступа.
нечитаемом виде. Примечание: проверочные процедуры 8.2.1.d и
8.2.1.e являются дополнительными
8.2.1.d Дополнительная проверочная процедура для
процедурами, применяемыми только для
оценки поставщиков услуг: проверить файлы паролей
организаций, которые определены как
на предмет того, что пароли пользователей, не
поставщики услуг.
являющихся клиентами, хранятся в нечитаемом виде.

8.2.1.e Дополнительная проверочная процедура для


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

8.2.2 Проверить идентификационные 8.2.2 Проверить процедуры аутентификации, Многие злоумышленники используют
данные пользователя перед выполняемые перед изменением учетных данных для социальную инженерию – например, звонят в
изменением любых учетных данных аутентификации, а также действия работников, службу поддержки для изменения пароля и
для аутентификации (например, отвечающих за безопасность, на предмет того, что, если действуют как легитимный пользователь, чтобы
перед сбросом пароля, перед сброс учетных данных для аутентификации изменить пароль и затем иметь возможность
предоставлением новых токенов или запрашивается по телефону, электронной почте, через использовать учетную запись пользователя.
перед генерацией новых ключей). Интернет или иным удаленным способом, Рекомендуется использовать секретный вопрос,
идентификационные данные пользователя проверяются ответ на который может дать только реальный
до выполнения запроса. пользователь, чтобы помочь администраторам
идентифицировать пользователя перед сбросом
или изменением учетных данных для
аутентификации.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 88
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
8.2.3 Обеспечить соответствие 8.2.3.a Проверить настройки системной конфигурации в Надежные пароли и (или) парольные фразы
паролей и (или) парольных фраз выборке системных компонентов на предмет того, что являются первой линией обороны в сети,
следующим требованиям: пароли и (или) парольные фразы соответствуют поскольку злоумышленник обычно сначала
следующим требованиям к сложности и стойкости: пытается найти учетные записи с простыми или
 длина пароля не менее семи
отсутствующими паролями. Если используются
символов;  длина пароля не менее семи символов;
короткие или тривиальные пароли,
 наличие в пароле и цифр, и  наличие в пароле и цифр, и букв. злоумышленнику относительно просто найти
букв. такие уязвимые учетные записи и
8.2.3.b Дополнительная проверочная процедура для
Как вариант, пароли и (или) оценки поставщиков услуг: проверить внутренние скомпрометировать сеть с использованием
парольные фразы должны иметь процессы, а также клиентскую и (или) пользовательскую идентификатора реального пользователя.
сложность и стойкость, сравнимые с документацию на предмет того, что пароли и (или) В соответствии с данным требованием в паролях
указанными выше параметрами. парольные фразы пользователей, не являющихся и (или) парольных фразах должно быть не менее
клиентами, соответствуют, как минимум, следующим семи символов (и букв, и цифр). Если данное
требованиям к сложности и стойкости: минимальное требование не может быть
 длина пароля не менее семи символов; выполнено в силу технических ограничений,
организации могут рассмотреть альтернативные
 наличие в пароле и цифр, и букв.
решения «эквивалентной надежности». Для
дополнительной информации о вариативности и
эквивалентной надежности (также используется
термин «энтропия») паролей и (или) парольных
фраз разных форматов следует обратиться к
отраслевым стандартам (например, текущая
версия NIST SP 800-63).

Примечание: проверочная процедура 8.2.3.b


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

8.2.4 Менять пароли и (или) 8.2.4.a Проверить настройки системной конфигурации в Пароли и (или) парольные фразы, которые не
парольные фразы пользователей, выборке системных компонентов на предмет того, что меняются и действуют в течение длительного
как минимум, один раз в 90 дней. настройки паролей и (или) парольных фраз пользователей времени, дают злоумышленникам больше
требуют смену пароля, как минимум, один раз в 90 дней. времени для их подбора.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 89
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
8.2.4.b Дополнительная проверочная процедура для Примечание: проверочная процедура 8.2.4.b
оценки поставщиков услуг: проверить внутренние является дополнительной процедурой,
процессы и документацию клиента и (или) пользователя применяемой только для организаций, которые
на предмет того, что: определены как поставщики услуг.
 требуется периодическая смена паролей и (или)
парольных фраз пользователей, не являющихся
клиентами;
 пользователи, не являющиеся клиентами, получают
инструкции о том, когда и при каких обстоятельствах
должен меняться пароль и (или) парольная фраза.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 90
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
8.2.5 Запретить пользователю 8.2.5.a Получить и проверить настройки системных Если история паролей не ведется,
менять пароль и (или) парольную конфигураций в выборке системных компонентов на эффективность смены паролей снижается, так
фразу на какие-либо из четырех предмет того, что настройки паролей требуют, чтобы как предыдущие пароли могут быть многократно
последних паролей и (или) новые пароли и (или) парольные фразы отличались от повторно использованы. Запрет повторного
парольных фраз данного последних четырех использованных паролей. использования паролей в течение
пользователя, использованных им определенного периода времени снижает
ранее. 8.2.5.b Дополнительная проверочная процедура вероятность того, что угаданные или
оценки для поставщиков услуг: проверить внутренние подобранные пароли будут использованы в
процессы и документацию клиента и (или) пользователя на будущем.
предмет того, что новый пароль и (или) парольная фраза
пользователя, не являющегося клиентом, должен Примечание: проверочная процедура 8.2.5.b
отличаться от четырех предыдущих паролей, является дополнительной процедурой,
использованных им ранее. применяемой только для организаций, которые
определены как поставщики услуг.

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

8.3 Защитить все индивидуальные Мультифакторная аутентификация требует от


неконсольные административные пользователя предоставления, как минимум,
доступы и все удаленные доступы в двух отдельных форм аутентификации (как
среду ДДК с использованием описано в требовании 8.2) перед тем, как доступ
мультифакторной аутентификации. будет предоставлен.
Мультифакторная аутентификация обеспечивает
дополнительную уверенность в том, что лица,
пытающиеся получить доступ, являются теми, за
кого себя выдают. При использовании
мультифакторной аутентификации
злоумышленнику придется скомпрометировать,
как минимум, два различных
аутентификационных механизма, что повышает
сложность компрометации и таким образом
уменьшает риск.
Мультифакторная аутентификация не

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 91
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
обязательно должна быть одновременно на
обоих уровнях - на системном уровне и на
уровне приложений - для определенного
системного компонента. Мультифакторная
аутентификация может выполняться либо при
входе в определенную сеть, либо при входе в
системный компонент.
Примеры технологий мультифакторной
аутентификации включают среди прочего
удаленную аутентификацию и систему RADIUS с
токенами; систему TACACS с токенами и другие
технологии, которые поддерживают
мультифакторную аутентификацию.

8.3.1 Реализовать мультифакторную 8.3.1.а Проверить сетевые и (или) системные Это требование распространяется на всех
аутентификацию для всех конфигурации, в зависимости от ситуации, на предмет работников, обладающих административным
неконсольных доступов в среду ДДК того, что мультифакторная аутентификация требуется для доступом в среду ДДК. Это требование
для работников с административным всех неконсольных административных доступов в среду распространяется только на работников,
доступом. ДДК. обладающих административным доступом, и
только для неконсольного доступа в среду ДДК.
Примечание: до 31 января 8.3.1.b Проследить за выборкой случаев входа Это требование не распространяется на учетные
2018 года это требование носит работников, являющиеся администраторами, в среду ДДК записи приложений или систем, выполняющие
рекомендательный характер, а на предмет того, что, как минимум, два из трех методов автоматические функции.
после этой даты становится аутентификации используются.
обязательным требованием. Если организация не использует сегментацию
для отделения среды ДДК от остальной сети,
администратор может использовать
мультифакторную аутентификацию либо при
входе в сеть среды ДДК, либо при входе в
систему.
Если среда ДДК отделена от остальной сети
организации, администратору может
потребоваться использование мультифакторной
аутентификации во время подключения к
системе среды ДДК из сети, не входящей в среду
ДДК. Мультифакторная аутентификация может
быть внедрена на уровне сети или на уровне
системы и (или) приложения, внедрение на
обоих уровнях не требуется. Если
администратор использует мультифакторнную
аутентификацию при входе в сеть среды ДДК,
Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 92
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
ему не нужно также использовать
мультифакторную аутентификацию при входе в
определенную систему или приложение внутри
среды ДДК.

8.3.2 Реализовать 8.3.2.a Проверить системные конфигурации серверов и Данное требование предназначено для того,
мультифакторнуюаутентификацию, систем удаленного доступа на предмет того, что чтобы оно применялось ко всем работникам
которая должна применяться к мультифакторная аутентификация требуется для: (включая обычных пользователей,
удаленному доступу в сеть (как для администраторов и вендоров поддержки или
 любого удаленного доступа работников, как
пользователей, так и для пользователей, так и администраторов; техобслуживания), которые имеют удаленный
администраторов, включая третьих доступ к сети, если через такой удаленный
 любого удаленного доступа третьих лиц и (или) вендоров
лиц для поддержки или обслуживания) доступ можно получить доступ к среде ДДК.
(включая доступ к приложениям и системным
из внешней сети. Если удаленный доступ осуществляется к сети,
компонентам для поддержки или обслуживания).
которая надлежащим образом сегментирована
8.3.2.b Проследить за тем, как работники из выборки
так, чтобы удаленные пользователи не могли
(например, пользователи и администраторы) осуществляют
получить доступ к среде ДДК или воздействовать
удаленный доступ к сети, на предмет того, что используются
на нее, мультифакторная аутентификация для
как минимум два из трех методов аутентификации.
удаленного доступа к такой сети не является
обязательной. Однако мультифакторная
аутентификация требуется для любого
удаленного доступа к сетям, имеющим доступ к
среде ДДК, и рекомендуется для любого
удаленного доступа к сетям организации.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 93
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
8.4 Документировать политики и 8.4.a Проверить процедуры и опросить работников на Доводя парольные политики и процедуры и
процедурыаутентификации и довести предмет того, что политики и процедуры аутентификации политики и процедуры аутентификации до
их до сведения всех пользователей, доведены до сведения всех пользователей. сведения всех пользователей, можно помочь им
включая: понять и соблюдать эти политики.
 рекомендации по выбору надежных 8.4.b Проверить политики и процедурыаутентификации, Например, рекомендации по выбору надежных
учетных данных для доведенные до сведения пользователей, на предмет того, паролей могут включать советы работникам о
аутентификации; что туда включены: том, как выбирать трудноугадываемые пароли,
 рекомендации для пользователей  рекомендации по выбору надежных учетных данных для которые не содержат словарных слов или
по защите учетных данных для аутентификации; информацию о пользователе (например,
аутентификации;  рекомендации пользователям по защите своих учетных идентификатор пользователя, имена членов
 указания не использовать ранее данных для аутентификации; семьи, дата рождения и т. д.).
использованные пароли;  указания пользователям не использовать ранее Рекомендации по защите учетных данных для
 указания по смене пароля в случае использованные пароли; аутентификации могут быть следующими:
подозрения на его компрометацию.  указания по смене пароля в случае подозрения на его — не записывать пароли,
компрометацию.
— не сохранять пароли в незащищенных
8.4.c Опросить пользователей из выборки на предмет того, файлах ,
что им известны политики и процедуры аутентификации.
— проявлять бдительность в отношении
злоумышленников, которые могут попытаться
использовать их пароли (например, звоня
работнику с просьбой дать его пароль для
решения какой-либо проблемы).
Рекомендуя пользователям сменить пароли,
если есть вероятность, что пароль больше не
является надежным, можно пресечь
злоумышленникам возможность использовать
действующий пароль для получения
несанкционированного доступа.

8.5 Не использовать групповые, общие 8.5.a Проверить списки учетных записей пользователей в Если несколько пользователей используют одни
и стандартные учетные записи и выборке системных компонентов на предмет того, что: и те же учетные данные для аутентификации
пароли, а также прочие подобные (например, учетную запись и пароль),
 стандартные учетные записи заблокированы или
методы аутентификации и обеспечить проследить за доступом в систему и действиями
удалены;
выполнение следующих положений: того или иного пользователя становится
 общие учетные записи пользователей для системного
невозможно. Это, в свою очередь, не позволит
 стандартные учетные записи администрирования и иных критичных функций
заблокированы или удалены; организации устанавливать ответственность за
отсутствуют;
действия конкретного пользователя, или
 общие учетные записи для  общие и стандартные учетные записи пользователей не
фактически регистрировать события, связанные
системного администрирования и используются для администрирования любых системных
с этими действиями, поскольку эти действия
иных критичных функций компонентов.
Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 94
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
отсутствуют; 8.5.b Проверить политики и процедуры аутентификации на могут быть совершены любым членом группы,
 общие и стандартные учетные предмет того, что они явным образом запрещают которой известны учетные данные для
записи пользователей не использование групповых и общих учетных записей и (или) аутентификации.
используются для паролей и прочих подобных средств аутентификации.
администрирования любых
системных компонентов. 8.5.c Опросить системных администраторов на предмет
того, что пользователям не выдаются групповые и общие
учетные записи и (или) пароли и прочие подобные средства
аутентификации, даже если таковые запрашиваются.

8.5.1 Дополнительное 8.5.1 Дополнительная проверочная процедура для Примечание: это требование применимо
требование для поставщиков оценки поставщиков услуг: проверить политики и только для организаций, которые определены
услуг: поставщики услуг, имеющие процедуры аутентификации и опросить сотрудников на как поставщики услуг.
удаленный доступ к помещениям предмет того, что для каждого клиента используются
клиента (например, для поддержки отдельные учетные данные. Чтобы предотвратить компрометацию учетных
POS систем или серверов), обязаны записей нескольких клиентов через
использовать уникальные учетные компрометацию единых учетных данных,
данные для аутентификации вендоры, осуществляющие удаленный доступ к
(например, пароль и (или) парольная средам клиентов, должны использовать разные
фраза) для каждого клиента. учетные данные для аутентификации на каждого
клиента.
Примечание: это требование не
распространяется на поставщиков Такие технологии, как мультифакторная
аутентификация, обеспечивающая уникальность
услуг хостинга, осуществляющих
доступ к своей общей хостинговой учетных данных для каждого подключения
среде, в которой размещены среды (например, с помощью одноразового пароля),
нескольких клиентов. также могут отвечать данному требованию.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 95
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
8.6 Если используются иные 8.6.a Проверить политики и процедуры аутентификации на Если механизмы аутентификации пользователя
механизмы аутентификации предмет того, что для использования механизмов (например, физические токены безопасности,
(например, физические или аутентификации (например, физических токенов смарт-карты и сертификаты) могут
логические токены безопасности, безопасности, смарт-карт и сертификатов) определены использоваться несколькими учетными
смарт-карты, сертификаты и т. д.), процедуры, которые, среди прочего, требуют: записями, то определить пользователя,
организация должна: использующего этот механизм аутентификации,
 назначать механизмы аутентификации для каждой
будет невозможно. Наличие физических и (или)
 назначать механизмы учетной записи в отдельности, а не для нескольких
аутентификации для каждой учетных записей сразу; логических механизмов контроля (например,
учетной записи в отдельности, а не ПИН-код, биометрические данные или пароль),
 установить физические и (или) логические защитные
для нескольких учетных записей уникальных для каждого пользователя, не
меры, чтобы для получения доступа такие механизмы
сразу; позволит злоумышленникам получить доступ с
мог использовать только тот пользователь, для которого
помощью общего механизма аутентификации.
 реализовать физические и (или) они предназначены.
логические меры, чтобы для
получения доступа такие
механизмы мог использовать
только тот пользователь, для
которого они предназначены.
8.6.b Опросить работников, отвечающих за безопасность, на
предмет того, что механизмы аутентификации назначаются
для каждой учетной записи в отдельности, а не для
нескольких учетных записей сразу.

8.6.c Проверить настройки системной конфигурации и (или),


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

8.7 Ограничить любой доступ к базе 8.7.a Проверить настройки конфигурации баз данных и Если аутентификация пользователя для доступа
данных, содержащей ДДК (включая приложений на предмет того, что пользователи проходят к базам данных и приложениям не выполняется,
доступ со стороны приложений, аутентификацию перед предоставлением доступа. повышается риск несанкционированного или
администраторов и любых других вредоносного доступа. Кроме того, события,
пользователей) следующим образом: 8.7.b Проверить настройки конфигурации баз данных и связанные с таким доступом, не могут быть
приложений на предмет того, что любые пользовательские зарегистрированы, поскольку пользователь не
 осуществлять доступ, запросы и операции с данными (доступ, запрос, перемещение,
операции с базами данных только аутентифицируется и, следовательно,
копирование, удаление) осуществляются только неизвестен системе. Доступ к базам данных
программными методами; программными методами (например, с использованием должен предоставляться только программными
 разрешать запросы и прямой хранимых процедур). методами (например, с использованием

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 96
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
доступ к базам данных только 8.7.c Проверить настройки контроля доступа к базам данных хранимых процедур), а не через прямой доступ
администраторам баз данных; и настройки конфигурации приложений для доступа к базам конечных пользователей к базе данных (за
 разрешать использовать учетные данных на предмет того, что запросы и прямой доступ к исключением администраторов баз данных,
записи приложений для доступа к базам данных разрешен только администраторам баз которым может потребоваться прямой доступ к
БД только приложениям (а не данных. базе данных для выполнения своих
отдельным пользователям или административных обязанностей).
иным процессам). 8.7.d Проверить настройки контроля доступа к базам
данных, настройки конфигурации и систем управления
базами данных и учетные записи приложений для доступа к
базам данных на предмет того, что учетные записи
приложений могут использоваться только приложениями (а
не отдельными пользователями или иными процессами).

8.8 Гарантировать, что политики 8.8 Проверить документацию и опросить работников на Работники должны знать и соблюдать политики
безопасности и операционные предмет того, что политики безопасности и операционные безопасности и операционные процедуры
процедуры идентификации и процедуры идентификации и аутентификации: непрерывного управления идентификацией и
аутентификации документированы, авторизацией.
 документированы;
используются и известны всем
 используются;
заинтересованным лицам.
 известны всем заинтересованным лицам.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 97
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требование 9. Ограничивать физический доступ к ДДК
Любой физический доступ к данным или системам, содержащим ДДК, предоставляет лицам возможность получить доступ к устройствам
или данным, удалить системы или печатные материалы. Такой доступ должен быть соответствующим образом ограничен. В рамках
требования 9 термин «работник объекта» относится к постоянным работникам, занятым как полный, так и неполный рабочий день,
временным работникам, подрядчикам и консультантам, находящимся на территории организации. Термин «посетитель» относится к
вендорам, гостям работников объекта, обслуживающему персоналу и иным лицам, кратковременно находящимся на территории
организации, как правило, не более одного дня. Термин «носитель» относится ко всем бумажным и электронным носителям, которые
содержат ДДК.

Требования PCI DSS Проверочные процедуры Пояснение


9.1 Использовать надлежащие 9.1 Убедиться, что меры обеспечения физической Без механизмов контроля физического доступа
средства контроля прохода на безопасности имеются в каждом машинном зале, центре (например, бейджей и контроля за входом в
территорию, чтобы ограничивать и обработки данных и иных физических зонах, в которых помещения) посторонние могут без труда
отслеживать физический доступ к располагаются системы среды ДДК. получить доступ к помещениям с целью кражи,
системам среды ДДК. отключения, порчи или уничтожения критичных
 Убедиться, что доступ контролируется с помощью
систем и ДДК.
устройств считывания бейджей или иных механизмов,
включая бейджи для авторизации и механические замки. Блокировка экрана входа в консоль не позволит
 Проследить за попыткой системного администратора посторонним получить доступ к критичной
войти в консоли случайно выбранных систем среды ДДК информации, внести изменения в системную
на предмет того, что они заблокированы во избежание конфигурацию, внести уязвимости в сеть или
несанкционированного доступа. уничтожить записи.
9.1.1 Использовать либо камеры 9.1.1.a Убедиться, что установлены либо камеры Если расследуются нарушения физической
видеонаблюдения, либо механизмы видеонаблюдения, либо механизмы контроля доступа (или безопасности, такие механизмы дают
контроля доступа (или оба варианта) оба варианта) для наблюдения за точками входа (выхода) в возможность выявлять лица, которые
для отслеживания каждого случая критичные помещения. осуществляли физический доступ к критичным

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 98
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
физического доступа к критичным 9.1.1.b Убедиться, что либо камеры видеонаблюдения, либо помещениям, а также установить время входа и
помещениям. Проверять собранные механизмы контроля доступа (или оба варианта) защищены выхода.
данные и сопоставлять их с другими от физического вмешательства или отключения. Злоумышленники, желающие получить
данными. Хранить эти данные не физический доступ к критичным помещениям,
менее трех месяцев, если часто пытаются отключить или обойти средства
законодательством не наложены мониторинга. Чтобы защитить такие устройства
иные ограничения. от физического вмешательства, видеокамеры
Примечание: термин «критичные можно разместить за пределами досягаемости
помещения» относится к любым и (или) так, чтобы можно было обнаруживать
центрам обработки данных, попытки физического вмешательства.
серверным комнатам или иным Механизмы контроля доступа также могут
помещениям, в которых расположены находиться под наблюдением или быть
системы, хранящие, оснащены физическими средствами защиты от
обрабатывающие или передающие повреждения или отключения
ДДК. Исключением являются места, злоумышленниками.
где присутствуют только POS-
терминалы, например, кассовые зоны (Продолжение на следующей странице)
розничных магазинов.

9.1.1.c Убедиться, что данные, полученные с камер Критичными помещениями являются, например,
видеонаблюдения и (или) механизмов контроля доступа, комнаты с серверами корпоративных баз
проверяются, и эти данные хранятся не менее 3 месяцев. данных; служебные помещения розничных
магазинов, где хранятся ДДК; хранилища с
большим объемом ДДК. Каждая организация
должна составить список критичных
помещений, чтобы обеспечить реализацию
надлежащих физических механизмов
наблюдения.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 99
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
9.1.2 Внедрить механизмы 9.1.2 Опросить ответственных работников и проверить Ограничение доступа к сетевым разъемам (или
физического и (или) логического места расположения общедоступных сетевых разъемов на портам) исключает для злоумышленников
контроля, чтобы ограничить доступ к предмет того, что там реализованы меры физического возможность подключиться к сетевым
сетевым разъемам, расположенным и (или) логического контроля для ограничения доступа к разъемам и получить доступ к внутренним
в общедоступных местах. общедоступным сетевым разъемам. сетевым ресурсам.
Например, сетевые разъемы, Независимо от типа используемых механизмов
расположенные в общедоступных контроля (физических, логических или
местах и местах, доступных смешанных) они должны обеспечивать
посетителям, можно отключать и достаточную защиту, чтобы исключить
включать только тогда, когда подключение к сети лиц или устройств, не
доступ к сети однозначно разрешен. имеющих на то явного разрешения.
Также можно внедрить процессы,
исключающие наличие посетителей
без постоянного сопровождения в
помещениях с работающими
сетевыми разъемами.

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 100
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
9.2 Разработать процедуры, которые 9.2.a Проверить документированные процессы на предмет Идентифицируя авторизованных посетителей
позволяют легко различать того, что в них определены процедуры, которые требуют так, чтобы их можно было легко отличать от
работников объекта от посетителей и идентифицировать и различать работников объекта и работников объекта, можно исключить
которые предусматривают: посетителей. предоставление доступа посторонним
посетителям к местам хранения ДДК.
 идентификацию работников Убедиться, что процедуры предусматривают:
объекта или посетителей  идентификацию работников объекта и посетителей
(например, путем выдачи (например, путем выдачи бейджей);
бейджей);
 требования к внесению изменений в права доступа;
 требования к внесению изменений
 изъятие или блокирование средств идентификации у
в права доступа;
работников объекта или средств идентификации с
 изъятие или блокирование средств истекшим сроком действия (например, бейджей) у
идентификации у работников посетителей.
объекта или средств
идентификации с истекшим сроком 9.2.b Проверить методы идентификации (такие как бейджи) и
действия (например, бейджей) у пронаблюдать процессы идентификации и различения
посетителей. работников объекта и посетителей на предмет того, что:
 посетители четко идентифицированы;
 работники объекта явно отличаются от посетителей.
9.2.с Убедиться, что доступ к процессу идентификации
(например, к системе выдачи бейджей) ограничивается
только уполномоченными работниками.

9.3 Контролировать физический 9.3.a Из выборки работников объекта, имеющих физический Контроль физического доступа к критичным
доступ работников объекта к доступ к критичным помещениям опросить ответственных помещениям позволяет обеспечить, чтобы
критичным помещениям следующим работников и проверить списки контроля доступа на предмет доступ предоставлялся только уполномоченным
образом: того, что: работникам, которым он необходим для
выполнения должностных обязанностей.
 утверждать права доступа  доступ к критичным помещениям утвержден;
согласно персональным  доступ необходим для выполнения должностных Если работник увольняется из организации,
должностным обязанностям; обязанностей. сразу после увольнения (как можно скорее)
 отзывать доступ сразу после следует забрать или отключить все средства
9.3.b Проследить за входом работников в критичные физического доступа, чтобы работник не мог
увольнения работника; забирать
помещения на предмет того, что все работники проходят получить физический доступ к критичным
или отключать все средства
авторизацию перед получением доступа. помещениям.
физического доступа (например,
ключи, карты доступа и т. д.). 9.3.c Сделать выборку недавно уволенных работников и
проверить списки контроля доступа на предмет того, что у них
нет физического доступа к критичным помещениям.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 101
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
9.4 Внедрить процедуры 9.4 Проверить наличие механизмов авторизации и контроля Средства контроля посетителей снижают риск
идентификации и авторизации доступа посетителей следующим образом: того, что посторонние лица и злоумышленники
посетителей, в т. ч.: получат доступ в помещения организации (и,
потенциально, к ДДК).
9.4.1 Выдавать разрешение 9.4.1.a Просмотреть процедуры и опросить работников на
Средства контроля посетителей обеспечивают
посетителям до входа в помещения, предмет того, что посетители получают разрешение до
возможность, чтобы посетители
где обрабатываются или хранятся получения доступа в помещения, где обрабатываются или
идентифицировались именно как посетители и
ДДК, и постоянно сопровождать хранятся ДДК, и посетителей постоянно сопровождают во
чтобы за их действиями могли наблюдать
посетителей во время пребывания в время пребывания в этих помещениях.
работники. Средства контроля также
этих помещениях.
9.4.1 Проследить за использованием бейджей посетителей обеспечивают, чтобы продолжительность
или других средств идентификации на предмет того, что доступа посетителей была ограничена
бейдж не дает возможности получить доступ в помещения, отведенным им временем посещения.
где хранятся ДДК, без сопровождения работников Обязательное изъятие бейджей у посетителей
организации. после истечения срока действия или
завершения посещения исключает для
9.4.2 Идентифицировать 9.4.2.a Осмотреть бейджи лиц, находящихся на территории
злоумышленников возможность
посетителей и выдавать им бейдж объекта, на предмет того, что у посетителей есть бейджи
воспользоваться ранее авторизованным
или другое средство идентификации или иные средства идентификации и что посетителей легко
пропуском для получения физического доступа
с ограниченным сроком действия и отличить от работников объекта.
в здание после завершения визита.
позволяющее отличить посетителя
от работника объекта. 9.4.2.b Убедиться, что бейдж посетителя или иное средство Журнал регистрации посетителей, где
идентификации посетителя имеет ограниченный срок фиксируется минимум информации о
действия. посетителе, является простым и недорогим в
обслуживании средством, позволяющим
9.4.3 Требовать от посетителей 9.4.3 Проследить за процессом ухода посетителей с
идентифицировать физический доступ в здание
вернуть выданный бейдж или иное объекта на предмет того, что от посетителей требуется
или помещение и потенциальный доступ к ДДК.
средство идентификации до ухода с возврат бейджа или другого средства идентификации при
объекта или по истечении срока его уходе посетителя или окончании срока действия средства
действия. идентификации.

9.4.4 Ведется журнал регистрации 9.4.4.a Убедиться в том, что ведется журнал регистрации
посетителей как на входе в посетителей, в который заносятся записи о физическом
помещения, так и на входе в доступе на объект, а также в машинные залы и центры
вычислительные центры и центры обработки данных, где хранятся или передаются ДДК.
обработки данных, в которых
хранятся или передаются ДДК. 9.4.4.b Убедиться, что журнал содержит:

В журнале регистрировать имя  имя посетителя;


посетителя, организацию, которую  название организации, которую он представляет;
он представляет, а также данные  имя работника объекта, разрешившего посетителю
работника объекта, который физический доступ.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 102
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
разрешил физический доступ. 9.4.4.с Убедиться в том, что журнал хранится не менее трех
Хранить этот журнал не менее трех месяцев.
месяцев, если законодательством не
установлены иные ограничения.

9.5 Обеспечить физическую 9.5 Убедиться, что процедуры защиты ДДК включают меры Меры физической безопасности носителей
безопасность всех носителей. физической защиты для всех носителей (в т. ч., среди предназначены для того, чтобы предотвращать
прочего, компьютеры, съемные электронные носители, несанкционированный доступ к ДДК на
бумажные счета, бумажные отчеты и факсы). носителях любого типа. Если ДДК не защищены
должным образом на съемных и портативных
носителях, распечатаны или оставлены без
присмотра на чьем-либо столе, существует
вероятность их несанкционированного
просмотра, копирования или сканирования.
9.5.1 Хранить носители с 9.5.1. Проверить, что безопасность места расположения Если хранилище небезопасно, то резервные
резервными копиями в безопасном хранилища проверяется не реже одного раза в год, чтобы копии, в которых содержатся ДДК, могут быть
месте, желательно в удаленном убедиться,что хранилище для носителей резервных копий легко потеряны, похищены или скопированы
подразделении, например, в является безопасным. для злонамеренных целей.
альтернативном или резервном Периодическая проверка хранилища позволяет
месте, либо на территории организации вовремя решать обнаруженные
организации, обеспечивающей проблемы с безопасностью, сводя к минимуму
безопасное хранение. Проверять потенциальный риск.
безопасность этого места не реже
раза в год.

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 103
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
9.6.1 классифицировать носители 9.6.1 Проверить, что носители классифицированы так, Важно, чтобы носитель был промаркирован
так, чтобы можно было определить чтобы можно было определить уровень критичности таким образом, чтобы его категория была
уровень критичности хранимых данных. очевидна. Носитель, который не маркирован как
данных; конфиденциальный, может быть недостаточно
защищен, а также может быть потерян или
украден.
Примечание: это не означает, что
необходимо прикреплять к носителям
маркировку «Конфиденциальная информация»;
цель требования состоит в такой
идентификации носителей с критичными
данными, которая позволит организации
защищать их.
9.6.2 отправлять носители только 9.6.2.a Опросить работников и проверить записи на предмет Если носитель отправляется способом, не
надежными курьерами или иным того, что пересылка любого носителя за пределы предусматривающим отслеживание (например,
способом доставки, который подразделения регистрируется в журнале, а сама обычной почтой), то он может быть утерян или
позволяет точно отслеживать пересылка выполняется только надежными курьерами или украден. Использование надежных курьеров
посылку. иным способом, который можно тщательно отслеживать. для доставки любых носителей с ДДК позволяет
организации использовать систему
9.6.2.b Сделать выборку записей за несколько последних отслеживания, чтобы вести учет
дней из журнала перемещения всех носителей за пределы местонахождения посылок.
охраняемой территории и проверить выборку на предмет
того, что сведения о перемещении носителей
документируются.

9.6.3 Гарантировать, что любой 9.6.3 Сделать выборку записей за несколько последних Если нет четкого процесса для утверждения
вынос любых носителей за пределы дней из журнала перемещения всех носителей. Проверить любых перемещений носителей за пределы
охраняемой территории (включая журналы и опросить ответственных работников на предмет охраняемой территории, то носители нельзя
передачу носителя частным лицам) того, что любой вынос носителей за пределы охраняемой будет ни отслеживать, ни должным образом
утверждается руководством. территории (включая передачу носителя частным лицам) защищать, их местонахождение будет
надлежащим образом утверждается руководством. неизвестно, что приведет к потере или краже
носителей.
9.7 Обеспечить строгий контроль 9.7 Получить и проверить политику контроля хранения и Если методы тщательной инвентаризации и
хранения и доступности носителей. обслуживания всех носителей на предмет того, что она контроля за хранением отсутствуют, то факт
требует периодическую инвентаризацию носителей. кражи или утери носителя может оставаться

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 104
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
9.7.1 Должным образом вести 9.7.1 Проверить журналы инвентаризации носителей на незамеченным в течение неопределенного
журналы инвентаризации всех предмет того, что такие журналы ведутся, а инвентаризация периода времени.
носителей и проводить носителей проводится не реже одного раза в год. Если носители не проходят инвентаризацию, то
инвентаризацию носителей не реже факт кражи или утери носителя может остаться
одного раза в год. незамеченным навсегда или в течение
длительного периода времени.
9.8 Уничтожать носители, которые 9.8 Проверить политику периодического уничтожения Если информация, содержащаяся на жестких
более не требуются для служебных носителей на предмет того, что она распространяется на все дисках компьютеров, портативных накопителях,
нужд или для выполнения требований носители, и содержит следующие требования: CD- и DVD-дисках или на бумаге, не
законодательства, следующим уничтожается надлежащим образом,
 печатные материалы измельчать путем перекрестной
способом: злоумышленники могут извлечь эту
резки, сжигать или преобразовывать в целлюлозную
массу способом, исключающим их восстановление; информацию с утилизированных носителей и
получить доступ к ДДК. Например,
 защищать контейнеры для материалов, приготовленных
злоумышленники могут исследовать
для уничтожения;
содержимое мусорных контейнеров на наличие
 уничтожать ДДК на электронном носителе без
информации, которую они могут использовать
возможности восстановления (например, с помощью
для атак.
программы безопасного удаления данных в соответствии
с отраслевыми стандартами безопасного удаления или Защита контейнеров для материалов,
путем физического уничтожения носителя). приготовленных для уничтожения, позволяет
предотвратить получение критичной
9.8.1 Измельчать, сжигать или 9.8.1.a Опросить работников и проверить процедуры на
информации при сборе материалов. Например,
преобразовывать печатные предмет того, что печатные материалы измельчаются путем
контейнеры с материалами, подлежащими
материалы в целлюлозную массу перекрестной резки, сжигаются или преобразовываются в
измельчению, могут быть оборудованы замком
способом, исключающим целлюлозную массу способом, исключающим их
для предотвращения доступа к их содержимому
возможность восстановления ДДК. восстановление.
или они могут иным образом физически
Защищать контейнеры для
9.8.1.b Осмотреть контейнеры для материалов, исключать доступ в контейнер.
материалов, приготовленных для
уничтожения. приготовленных для уничтожения, на предмет того, что они Для безопасного уничтожения электронных
надежно защищены. носителей можно, например, использовать
безопасное стирание, размагничивание или
9.8.2 Привести ДДК, хранимые на 9.8.2 Убедиться в том, что ДДК на электронных носителях физическое разрушение носителя (например,
электронных носителях, к уничтожаются без возможности восстановления (например, истирание или измельчение жесткого диска).
состоянию, исключающему с помощью программы безопасного удаления данных в
возможность их восстановления. соответствии с отраслевыми стандартами безопасного
удаления или путем физического уничтожения носителя).

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 105
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
9.9 Защитить устройства, 9.9 Проверить документированные политики и процедуры Злоумышленники пытаются красть ДДК путем
считывающие ДДК путем прямого на наличие следующих требований: кражи и (или) подмены считывающих устройств
физического взаимодействия с картой,  поддерживать список устройств; и терминалов. Например, они пытаются украсть
от физического вмешательства и  периодически проверять устройства на предмет устройства, чтобы понять, как их взломать и
подмены. физического вмешательства или подмены; часто пытаются заменить настоящие
 обучить работников, чтобы они знали признаки устройства на мошеннические, присылающие
Примечание: данные требования
подозрительного поведения и уведомляли о физическом им информацию о платежной карте каждый раз,
распространяются на устройства
вмешательстве или подмене устройств. когда вставляется карта. Злоумышленники
для считывания информации с
также пытаются установить снаружи устройств
платежной карты, которые
так называемые «скиммеры», предназначенные
используются в точке продаж для
для перехвата данных о платежной карте еще
транзакций с предоставлением
перед ее вставкой в устройство (например,
карты (т. е. при проведении карты
прикрепляя дополнительное устройство для
через устройство или при вставке в
считывания карт поверх настоящего, чтобы
него карты). Данное требование не
данные о платежной карте считывались
распространяется на компоненты
дважды – сначала поддельным, а затем
ручного ввода ключа (например,
настоящим компонентом устройства). Таким
компьютерные клавиатуры и
образом, транзакции могут проходить в
клавиатуры POS-терминала).
обычном режиме, в то время как
злоумышленник «снимает» информацию с
платежной карты.
Для компонентов ручного ввода ключа
(например, компьютерных клавиатур и
клавиатур POS-терминалов) данное требование
является рекомендуемым, но не обязательным.
Дополнительную информацию о передовом
опыте по предотвращению скимминга можно
найти на сайте PCI SSC.
9.9.1 Вести актуальный список 9.9.1.a Проверить, что список устройств включает Поддерживая актуальный список устройств,
устройств. Список должен включать следующую информацию: организация может отслеживать
следующую информацию: предполагаемое местонахождение устройства и
 марка и модель устройства;
быстро его обнаруживать в случае его утери
 марка и модель устройства;  местонахождение устройства (например, адрес объекта или пропажи.
 местонахождение устройства или подразделения, в котором находится устройство);
(например, адрес объекта или Список устройств может составляться
 серийный номер устройства или другой уникальный
подразделения, в котором автоматически (например, через систему
идентификатор.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 106
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
находится устройство); 9.9.1.b Сделать выборку устройств из списка и проверить управления устройствами) или вручную
 серийный номер устройства или устройства и их местонахождение на предмет того, что (например, в электронных или бумажных
другой уникальный список является точным и актуальным. записях). Для устройств, находящихся в
идентификатор. постоянном движении, информация о
9.9.1.c Опросить работников на предмет того, что список местонахождении может включать в себя имя
актуализируется каждый раз, когда устройства работника, за которым это устройство
добавляются, перемещаются, списываются и т. д. закреплено.
9.9.2 Периодически проверять 9.9.2.a Проверить документированные процедуры на Регулярно осматривая устройства, организации
поверхность устройств для предмет того, что в процессах определено следующее: могут быстрее обнаруживать физическое
обнаружения признаков физического вмешательство или подмену устройства и,
 процедуры осмотра устройств;
вмешательства (например, следовательно, снижать потенциальный ущерб
 частота осмотров.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 107
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
прикрепленных к устройствам 9.9.2.b Опросить ответственных работников и проследить за от мошеннических устройств.
скиммеров) или подмены (например, процессом осмотра на предмет того, что: Способ осмотра зависит от устройства
проверяя серийный номер или иные (например, можно использовать фотографию
характеристики устройств на  работники знают процедуры осмотра устройств;
изначально безопасного устройства, чтобы
предмет того, что устройство не  все устройства периодически осматриваются на сравнить текущий вид с исходным и обнаружить
было заменено на мошенническое). наличие следов физического вмешательства или изменения). Также можно использовать
подмены. защитный маркер (например, видимый в
Примечание: признаками того, что
устройство подверглось ультрафиолетовом излучении) для маркировки
физическому вмешательству или поверхностей и отверстий устройства, чтобы
что устройство было подменено, можно было легко заметить любое физическое
могут служить подозрительные вмешательство или подмену. Злоумышленники
накладки или кабели, подключенные к часто заменяют внешний кожух устройства,
устройству, отсутствующие или чтобы скрыть следы физического
измененные защитные наклейки вмешательства, и указанные выше способы
(пломбы), поврежденный или помогут обнаружить такую замену. Поставщики
перекрашенный корпус, изменение устройств также часто предоставляют
серийного номера или иных внешних рекомендации по защите и инструкции, которые
обозначений. помогут определить, подвергалось ли
устройство физическому вмешательству.
Частота осмотров зависит от таких факторов,
как местонахождение устройства и наличие за
ним наблюдения. Например, устройства,
установленные работниками организации в
общественном месте и находящиеся без
присмотра, требуется осматривать чаще, чем
устройства, расположенные в безопасном
месте и находящиеся под присмотром. Способ
и частота осмотров определяется ТСП согласно
его процессу ежегодной оценки рисков.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 108
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
9.9.3 Обучать работников 9.9.3.a Проверить учебные материалы для работников в Злоумышленники часто выдают себя за
распознавать признаки физического точках продаж на предмет того, что материалы обучают в т. уполномоченный обслуживающий персонал для
вмешательства или подмены ч. следующему: получения доступа к POS-устройствам. Следует
устройств. Обучать в т. ч.  проверять личность любых третьих лиц, выдающих проверять все третьи лица, запрашивающие
следующему: себя за ремонтников или специалистов доступ к устройствам, до того, как предоставить
техобслуживания, до того, как им предоставляется им доступ, например, посовещавшись с
 проверять личность любых
доступ на внесение изменений или устранение проблем руководством или позвонив в компанию,
третьих лиц, выдающих себя за
с устройствами; обслуживающую POS-терминалы, (например,
ремонтников или специалистов
 не устанавливать, не заменять или не возвращать вендору или эквайреру) для получения
техобслуживания, до того, как
устройства без проверки; подтверждения. Злоумышленники часто
им предоставляется доступ на
 знать признаки подозрительного поведения вблизи пытаются обмануть работников, одевшись
внесение изменений или
устройств (например, попытки посторонних лиц соответствующим образом (например, носят с
устранение проблем с
отключить или открыть устройства); собой чемоданчик с инструментами и
устройствами;
одеваются в служебную униформу) и также
 не устанавливать, не заменять  сообщать соответствующим работникам (например,
могут быть осведомлены о местонахождении
или не возвращать устройства руководителю или специалисту по безопасности) о
устройств, поэтому важно, чтобы работники
без проверки; подозрительном поведении, признаках физического
были обучены всегда соблюдать
 знать признаки подозрительного вмешательства или подмены устройства.
установленные процедуры.
поведения вблизи устройств 9.9.3.b Опросить работников из выборки в местах установки Еще один излюбленный трюк
(например, попыток посторонних POS-терминалов на предмет того, что они прошли обучение злоумышленников – отправка почтой «новой»
лиц отключить или открыть и знают процедуры того, как: системы POS-терминала с указанием
устройства);
 проверять личность любых третьих лиц, выдающих установить его вместо настоящего и «вернуть»
 сообщать соответствующим себя за ремонтников или специалистов настоящий терминал по указанному адресу.
работникам (например, техобслуживания, до того, как им предоставляется Злоумышленники даже могут оплатить
руководителю или специалисту доступ на внесение изменений или устранение проблем почтовые расходы по возврату настоящего
по безопасности) о с устройствами; терминала, так как они очень хотят заполучить
подозрительном поведении, такого рода устройства. Перед установкой
 не устанавливать, не заменять или не возвращать
признаках физического и (или) эксплуатацией устройства работники
устройства без проверки;
вмешательства или подмены должны всегда удостоверять у руководителя и
устройства.  знать признаки подозрительного поведения вблизи поставщика, что оно настоящее и получено из
устройств (например, попыток посторонних лиц доверенного источника.
отключить или открыть устройства);
 сообщать соответствующим работникам (например,
руководителю или специалисту по безопасности) о
подозрительном поведении, признаках физического
вмешательства или подмены устройства.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 109
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
9.10 Гарантировать, что политики 9.10 Проверить документацию и опросить работников на Работники должны знать и соблюдать политики
безопасности и операционные предмет того, что политики безопасности и операционные безопасности и процедуры постоянного
процедуры ограничения физического процедуры ограничения физического доступа к ДДК: ограничения физического доступа к ДДК и
доступа к ДДК документированы, среде ДДК.
 документированы;
используются и известны всем
 используются;
заинтересованным лицам.
 известны всем заинтересованным лицам.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 110
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Осуществлять регулярный мониторинг и тестирование сетей
Требование 10. Отслеживать и вести мониторинг всего доступа к сетевым ресурсам и ДДК
Механизмы регистрации событий и возможность проследить действия пользователей являются критичными для обнаружения,
предотвращения и минимизации воздействия от компрометации данных. Наличие журналов регистрации во всех средах позволяет
тщательно отслеживать, создавать оповещения и проводить анализ при возникновении внештатных ситуаций. Без журналов
регистрации действий в системе определить причины компрометации трудно, если вообще возможно.

Требования PCI DSS Проверочные процедуры Пояснение


10.1 Внедрить журналы регистрации 10.1 Наблюдая за действиями системного администратора и Важно иметь процесс или систему, где доступ
событий, в которых любой доступ к опрашивая его, проверить, что: пользователей привязывается к компонентам
системным компонентам системы, к которым он осуществлялся. Данная
 включено и действует ведение журналов регистрации
привязывается к конкретному событий системных компонентов; система будет генерировать журналы
пользователю. регистрации событий и позволит отслеживать
 доступ к системным компонентам привязывается к
подозрительную деятельность определенного
конкретным пользователям.
пользователя.

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

10.2.1 все сеансы персонального 10.2.1 убедиться, что каждый персональный сеанс доступа к Злоумышленники могут получить информацию
доступа пользователей к ДДК; ДДК регистрируется; об учетной записи пользователя с доступом к
системам в среде ДДК или создать новую
несанкционированную учетную запись для
получения доступа к ДДК. Регистрация всех
сеансов доступа к ДДК позволяет выявить,
какие учетные записи могут быть
скомпрометированы или неправильно
использованы.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 111
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
10.2.2 все действия, совершенные 10.2.2 убедиться в том, что регистрируются все действия, Учетные записи с расширенными правами
любым лицом с привилегиями совершенные любым лицом с привилегиями доступа, такие как «администратор» или
суперпользователя (root) или суперпользователя или администратора; «суперпользователь», могут существенно
администратора; влиять на безопасность или функциональные
возможности системы по выполнению
операций. Если не регистрировать
выполняемые действия, организация не
сможет отслеживать проблемы, связанные с
ошибками администрирования или
ненадлежащим использованием прав доступа
в отношении отдельных лиц или действий.

10.2.3 доступ ко всем журналам 10.2.3 убедиться, что регистрируется доступ ко всем Злоумышленники часто пытаются изменить
регистрации событий; журналам регистрации событий; записи в журнале, чтобы скрыть свои
действия. Регистрация сеансов доступа
позволяет организации связывать
несоответствия или возможные изменения
записей в журнале с конкретной учетной
записью. Имея доступ к журналам изменений,
добавлений и удалений, есть возможность
отследить несанкционированные действия
сотрудников.

10.2.4 неуспешные попытки 10.2.4 убедиться, что регистрируются неуспешные попытки Злоумышленники часто предпринимают
логического доступа; логического доступа; многочисленные попытки доступа к целевым
системам. Несколько неуспешных попыток
входа в систему могут свидетельствовать о
том, что неавторизованный пользователь
пытается войти в систему, перебирая или
угадывая пароли.

10.2.5 использование и изменение 10.2.5.а убедиться в том, что регистрируется использование Не зная того, кто входил в систему на момент
механизмов идентификации и механизмов идентификации и аутентификации; возникновения инцидента, невозможно
аутентификации, включая, помимо выявить учетные записи, которые могли быть
прочего, создание новых учетных 10.2.5.b убедиться в том, что регистрируется любое использованы. Кроме того, злоумышленники
записей, повышение привилегий, а повышение привилегий; могут также пытаться манипулировать
также все изменения, добавления, механизмами аутентификации, чтобы обойти
удаления учетных записей с 10.2.5.с убедиться в том, что регистрируются любые их или выдать себя за другого пользователя.
правами суперпользователя или изменения, добавления или удаления в отношении любых
администратора учетных записей с правами суперпользователя или
администратора.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 112
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
10.2.6 запуск, остановка или 10.2.6 убедиться в регистрации следующих событий: Выключение (или приостановка ведения)
приостановка ведения журналов журналов аудита перед выполнением
 запуск журналов аудита;
регистрации событий; подозрительных действий является
 остановка или приостановка журналов аудита; распространенной практикой среди
злоумышленников, которые стремятся
избежать обнаружения. Запуск журнала аудита
может указывать на то, что функции журнала
были отключены пользователем в целях
сокрытия своих действий.

10.2.7 создание и удаление 10.2.7 убедиться, что регистрируется создание и удаление Вредоносное ПО часто создает или заменяет
объектов системного уровня. объектов системного уровня. объекты системного уровня на целевой
системе, чтобы получить контроль над
определенной функцией или операцией в этой
системе. Регистрация создания или удаления
объектов системного уровня, таких как
таблицы баз данных или хранимые процедуры,
упрощает определение легитимности таких
изменений.

10.3 Записывать в журналах 10.3 Опрашивая работников и просматривая журналы аудита, Записывая указанные данные для
регистрации событий для каждого выполнить следующие действия для каждого контролируемого контролируемых событий, перечисленных в
события каждого системного события (из требования 10.2): требовании 10.2, можно быстро
компонента, как минимум, следующее: идентифицировать потенциальную
компрометацию и иметь достаточно сведений
10.3.1 идентификатор пользователя; 10.3.1 убедиться в том, что идентификатор пользователя о том, кто, что, когда, где и как сделал.
записывается в журнал;

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

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

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

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 113
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
10.3.6 идентификатор или название 10.3.6 убедиться, что идентификатор или название данных,
данных, системного компонента или системного компонента или ресурса, на которые
ресурса, на которые воздействовало воздействовало событие, включены в записи журнала.
событие.

10.4 Синхронизировать все часы и 10.4 Проверить стандарты конфигурации и относящиеся к ним Технология синхронизация времени
системное время в критичных процессы на предмет того, что для синхронизации часов используется для синхронизации часов на
системах с помощью механизмов внедрена и поддерживается в актуальном состоянии нескольких системах. Если часы
синхронизации времени и обеспечить технология синхронизации времени, удовлетворяющая синхронизированы некорректно, бывает
выполнение следующих требований требованиям 6.1 и 6.2 стандарта PCI DSS. сложно или даже невозможно сравнить файлы
при получении, распространении и журналов регистрации событий из различных
хранении данных о времени. систем и установить точную
последовательность событий (что имеет
Примечание: примером механизма
большое значение при расследовании
синхронизации времени является
нарушений). Для групп, расследующих
сетевой протокол службы времени
инциденты, точность и согласование времени
(NTP).
на всех системах и времени совершения
10.4.1 Установить точное и 10.4.1.a Проверить процесс получения, распространения и каждого действия является критичным для
согласованное время в критичных хранения точного времени в организации, на предмет того, того, чтобы определить, каким образом были
системах. что: скомпрометированы системы.

 только назначенные центральные серверы времени


получают информацию о времени из внешних
источников, а данная информация основывается на
Международном атомном времени (International Atomic
Time) или Всемирном координированном времени (UTC);
 при наличии более одного назначенного сервера
времени, серверы времени связываются друг с другом
для поддержания точного времени;
 системы получают информацию о времени только от
назначенных центральных серверов времени.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 114
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
10.4.1.b Проверить системные параметры времени в
выборке системных компонентов на предмет того, что:
 только назначенные центральные серверы времени
получают информацию о времени из внешних
источников, а данная информация основывается на
Международном атомном времени (International Atomic
Time) или Всемирном координированном времени (UTC);
 при наличии более одного назначенного сервера
времени, серверы времени связываются друг с другом
для поддержания точного времени;
 системы получают информацию о времени только от
назначенных центральных серверов времени.

10.4.2 Защитить данные о времени. 10.4.2.a Проверить системные конфигурации и настройки


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

10.4.2.b Проверить системные конфигурации, настройки,


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

10.4.3 Получать настройки времени 10.4.3 Проверить системные конфигурации на предмет того,
из общепризнанных в отрасли что серверы времени принимают обновления времени от
источников. специализированных, общепризнанных отраслевых внешних
источников (чтобы злоумышленник не мог изменить время).
Как вариант, данные обновления можно зашифровать с
помощью симметричного ключа, а также можно создать
списки контроля доступа, определяющие IP-адреса
клиентских машин, которым будут предоставляться
обновления времени (чтобы предотвратить
несанкционированное использование внутренних серверов
времени).

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 115
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
10.5 Защитить журналы регистрации 10.5 Опросить системных администраторов и проверить Злоумышленники, проникшие в сеть, зачастую
событий от изменений: системные конфигурации и права доступа на предмет того, что пытаются внести изменения в журналы аудита
журналы регистрации событий защищены от изменений для того, чтобы скрыть свои действия. При
следующим образом: недостаточной защите журналов аудита
гарантировать их полноту, точность и
целостность будет невозможно, и они будут
бесполезны в качестве средства
расследования после компрометации.

10.5.1 ограничить доступ к 10.5.1 доступ к журналу регистрации событий предоставлен Надежная защита журналов регистрации
просмотру журналов регистрации только тем работникам, которым такой доступ необходим в событий подразумевает строгий контроль
событий только теми работниками, соответствии с их должностными обязанностями. доступа (ограничение доступа к журналам по
которым такой доступ необходим в принципу служебной необходимости) и
соответствии с их должностными использование физического или сетевого
обязанностями; разделения, чтобы затруднить поиск и
модификацию журналов.
10.5.2 защищать файлы журналов 10.5.2 актуальные журналы регистрации событий защищены
регистрации событий от от несанкционированного изменения с помощью механизмов Оперативно сохраняя резервные копии
несанкционированных изменений; контроля доступа, физического разделения и (или) журналов регистрации событий на
разделения на уровне сетей; централизованный сервер протоколирования
или на носитель, где их изменение затруднено,
10.5.3 оперативно сохранять 10.5.3 резервные копии журналов регистрации событий можно защитить журналы даже в случае
резервные копии журналов оперативно сохраняются на централизованный сервер компрометации системы, их генерирующей.
регистрации событий на протоколирования или отдельный носитель, на котором их
централизованный сервер трудно изменить;
протоколирования или носитель, на
котором их трудно изменить;

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 116
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
10.5.5 применять ПО для 10.5.5 проверить системные настройки, отслеживаемые Системы мониторинга целостности файлов
мониторинга целостности файлов файлы и результаты мониторинга на предмет того, что в или обнаружения несанкционированных
или обнаружения изменений в журналах применяется ПО для мониторинга целостности изменений выполняют проверку на внесение
журналах регистрации событий, файлов или обнаружения несанкционированных изменений в изменений в критичные файлы и генерируют
чтобы данные существующих журналах. уведомления при обнаружении изменений. В
журналов нельзя было изменить без целях мониторинга целостности файлов
автоматического создания организация обычно выполняет мониторинг
уведомления (однако добавление файлов, которые не меняются нечасто, но
новых данных не должно создавать изменение которых может свидетельствовать
уведомление). о компрометации.

10.6 Проверять журналы и события 10.6 Выполнить следующее. Большое количество компрометаций
безопасности всех системных происходит за несколько дней или даже
компонентов, чтобы выявлять месяцев до обнаружения. Регулярная
аномалии или подозрительную проверка журналов вручную или
активность. автоматически позволяет выявлять и
заблаговременно противодействовать
Примечание: для выполнения
несанкционированному доступу к среде ДДК.
данного требования могут
использоваться средства сбора и Проверку журналов не обязательно выполнять
анализа журналов регистрации вручную. Средства сбора и анализа журналов
событий, а также средства регистрации событий, а также средств
оповещения. оповещения могут облегчить проверку
благодаря тому, что они указывают на
события, которые требуют проверки.

10.6.1 Проверять не реже одного 10.6.1.a Проверить политики и процедуры безопасности на Ежедневная проверка журналов регистрации
раза в день: предмет того, что имеются процедуры, требующие проверять событий минимизирует время, необходимое
следующие записи вручную или автоматически не реже для обнаружения компрометации.
 все события безопасности;
одного раза в день: Чтобы обнаруживать потенциальные
 журналы всех системных
компонентов, которые хранят,  все события безопасности; проблемы, необходимо ежедневно проверять
обрабатывают или передают ДДК  журналы всех системных компонентов, которые хранят, события безопасности (например,
и (или) КАД; обрабатывают или передают ДДК и (или) КАД; уведомления или предупреждения о
подозрительной или аномальной активности),
 журналы всех критичных  журналы всех критичных системных компонентов;
журналы критичных системных компонентов и
системных компонентов;  журналы всех серверов и системных компонентов, журналы систем, выполняющих функции
 журналы всех серверов и выполняющих функции безопасности (например, защиты (например, межсетевых экранов,
системных компонентов, межсетевых экранов, систем обнаружения или систем обнаружения или предотвращения
выполняющих функции предотвращения вторжений, серверов аутентификации, вторжений, систем мониторинга целостности
безопасности (например, серверов перенаправления для электронной коммерции файлов). Следует учитывать, что значение
межсетевых экранов, систем и т. д.).

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 117
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
обнаружения или 10.6.1.b Проследить за процессами и опросить работников термина «событие безопасности» зависит от
предотвращения вторжений, на предмет того, что не реже раза в день проверяются: организации и может включать ограничения по
серверов аутентификации, типу технологий, местонахождении и функции
серверов перенаправления для  все события безопасности; устройства. Организациям также
электронной коммерции и т. д.).  журналы всех системных компонентов, которые хранят, рекомендуется определить так называемый
обрабатывают или передают ДДК и (или) КАД; «нормальный» трафик в целях идентификации
 журналы всех критичных системных компонентов; аномального поведения.
 журналы всех серверов и системных компонентов,
выполняющих функции безопасности (например,
межсетевых экранов, систем обнаружения или
предотвращения вторжений, серверов аутентификации,
серверов перенаправления для электронной коммерции
и т. д.).
10.6.2 Периодически изучать 10.6.2.a Проверить политики и процедуры безопасности на Периодически следует проверять журналы
журналы других системных предмет того, что имеются процедуры, требующие всех остальных системных компонентов, чтобы
компонентов на основании политик и периодически изучать журналы всех остальных системных выявлять признаки потенциальных проблем
стратегии управления рисками компонентов (вручную или автоматически) на основании или попыток получить доступ к критичным
организации, определяемых в политик и стратегии управления рисками. системам через другие, менее критичные
рамках ежегодной оценки рисков. системы. Частота проведения проверок
определяется организацией в рамках
ежегодной оценки рисков.

10.6.2.b Проверить документацию организации по оценке


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

10.6.3 Изучать исключения и 10.6.3.a Проверить политики безопасности и процедуры на Если исключения и аномалии, обнаруженные
аномалии, обнаруженные во время предмет того, что имеются процедуры, требующие изучать во время проверки журналов, не будут
проверки. исключения и аномалии, обнаруженные во время проверки. изучены, организация может не узнать о
несанкционированной и потенциально
10.6.3.b Проследить за процессами и опросить работников вредоносной активности внутри своей сети.
на предмет того, что исключения и аномалии изучаются.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 118
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
10.7 Сохранять историю журналов 10.7.a Проверить политики и процедуры на предмет того, что То, что журналы должны храниться, по
регистрации событий не менее одного они определяют: крайней мере, в течение года, связано с тем
года, причем в оперативном доступе фактом, что на обнаружение компрометации
 политики хранения журналов аудита;
должна находиться история не менее требуется время. У экспертов, таким образом,
 процедуры хранения журналов аудита в течение не менее
чем за последние три месяца имеется достаточно материалов с хронологией
одного года, в том числе в оперативном доступе не менее
(например, в прямом доступе, в событий, позволяющих более точно
трех месяцев.
архиве, либо с возможностью определить продолжительность
восстановления из резервной копии). 10.7.b Опросить работников и проверить журналы аудита на существования потенциальной компрометации
предмет того, что журналы доступны, по крайней мере, в и систем, потенциально подверженных ее
течение одного года. воздействию. Располагая журналами за три
месяца, организация может быстро выявить
10.7.с Опросить работников и проследить за процессами на
компрометацию и минимизировать ущерб.
предмет того, что для проведения анализа можно
Хранение журналов в оффлайновых местах
незамедлительно восстановить журналы аудита как минимум
расположения может затруднить получение к
за последние три месяца.
ним оперативного доступа и привести к
увеличению времени, необходимого, чтобы
восстановить данные журнала, выполнить
анализ и выявить системы или данные,
подвергшиеся воздействию компрометации.

10.8 Дополнительное требование 10.8.а Проверить документированные политики и процедуры Примечание: это требование применимо
для поставщиков услуг: внедрить на предмет того, что определены процессы своевременного только для организаций, которые
процесс своевременного обнаружения обнаружения и отчетности об ошибках в критичных системах определены как поставщики услуг.
и отчетности об ошибках в критичных контроля безопасности, включая среди прочего ошибки: Если формализованные процессы
системах контроля безопасности, обнаружения ошибок и оповещения
 межсетевых экранов;
включая среди прочего ошибки: отсутствуют, в случае возникновения ошибок в
 систем обнаружения или предотвращения вторжений;
 межсетевых экранов; критичных механизмах контроля безопасности
 систем мониторинга целостности файлов; данные ошибки могут остаться
 систем обнаружения и (или)
 антивирусного ПО; невыявленными в течение длительного
предотвращения вторжений;
времени, и злоумышленники получат
 систем мониторинга  физических механизмов контроля доступа; достаточно времени для компрометации
целостности файлов;  логических механизмов контроля доступа; систем и хищения критичных данных из среды
 антивирусного ПО; ДДК.
 механизмов ведения журналов регистрации событий;
Определенные типы ошибок могут
 физических механизмов  средств сегментации (если они используются)

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 119
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
контроля доступа; 10.8.b Проверить процессы обнаружения и оповещения и различаться в зависимости от
опросить работников на предмет того, что эти процессы функциональности устройства и использыемой
 логических механизмов
внедрены на всех критичных механизмах контроля технологии. Типовые ошибки включают
контроля доступа;
безопасности, и в случае обнаружения ошибок в данных прекращение выполнения системой функции
 механизмов ведения обеспечения безопасности или выполнение
механизмах происходит оповещение.
журналов регистрации функции не в том виде, в котором она
событий; запланирована, например, межсетевой экран
 средств сегментации (если удаляет все свои правила или переходит в
они используются) автономный режим.

Примечание: до 31 января 2018 года


это требование носит
рекомендательный характер, а
после этой даты становится
обязательным требованием.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 120
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
10.8.1 Дополнительное 10.8.1.a Проверить документированные политики и процедуры Примечание: это требование применимо
требование для поставщиков и опросить персонал на предмет того, что процессы только для организаций, которые
услуг: своевременно реагировать на реагирования на ошибки в механизмах контроля безопасности определены как поставщики услуг.
ошибки в любых критичных определены, внедрены и включают: Если реагирование на оповещения об ошибках
механизмах контроля безопасности. в критичных механизмах контроля
 восстановление функций обеспечения безопасности;
Процессы реагирования на ошибки в безопасности не осуществляется быстро и
механизмах контроля безопасности  определение и документирование продолжительности эффективно, злоумышленники могут
должны включать: (дата и время начала и окончания) ошибки в воспользоваться этим временем для
обеспечении безопасности; внедрения вредоносного ПО, получить
 восстановление функций
обеспечения безопасности;  определение и документирование причины (причин) контроль над системой или похитить данные
ошибки, включая изначальную причину, и из среды организации.
 определение и
документирование мер, необходимых для Документированные свидетельства (например,
документирование
исправления изначальной причины; записи о проблемах в системе управления)
продолжительности (дата и
должны поддерживать действующими
время начала и окончания)  определение и решение любых вопросов
процессы и процедуры реагирования на
ошибки в обеспечении безопасности, которые возникают во время ошибки;
ошибки в обеспечении безопасности. Кроме
безопасности;
 выполнение оценки рисков, чтобы определить того, работники должны знать свои
 определение и необходимость дальнейших действий при ошибке в обязанности в случае возникновения ошибки.
документирование причины обеспечении безопасности; Ответные действия на ошибки должны быть
(причин) ошибки, включая зафиксированны в виде документированных
 применение мер для предотвращения причины свидетельств.
изначальную причину, и
ошибки и недопущения ее повторения;
документирование мер,
необходимых для  возобновление мониторинга механизмов контроля
исправления изначальной безопасности.
причины;

 определение и решение
любых вопросов
безопасности, которые
возникают во время ошибки;

 выполнение оценки рисков,


чтобы определить
необходимость дальнейших
действий при ошибке в
обеспечении безопасности;

 применение мер для


предотвращения причины
ошибки и недопущения ее

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 121
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
повторения; 10.8.1.b Проверить записи на предмет того, что ошибки в
механизмах контроля безопасности задокументированы и
 возобновление мониторинга
механизмов контроля включают:
безопасности.  определение причины (причин) ошибки, включая
изначальную причину;
Примечание: до 31 января
2018 года это требование носит  продолжительность (дата и время начала и
рекомендательный характер, а окончания) ошибки в обеспечении безопасности;
после этой даты становится
обязательным требованием.  меры, необходимые для исправления изначальной
причины.

10.9 Гарантировать, что политики 10.9 Проверить документацию и опросить работников на Работники должны знать и соблюдать
безопасности и операционные предмет того, что политики безопасности и операционные политики безопасности и повседневные
процедуры мониторинга любого процедуры мониторинга любого доступа к сетевым ресурсам и операционные процедуры непрерывного
доступа к сетевым ресурсам и ДДК ДДК: мониторинга любого доступа к сетевым
документированы, используются и ресурсам и ДДК.
 документированы;
известны всем заинтересованным
 используются;
лицам.
 известны всем заинтересованным лицам.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 122
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требование 11. Регулярно тестировать системы и процессы безопасности.
Уязвимости постоянно обнаруживаются злоумышленниками и исследователями, а также появляются вместе с новым программным
обеспечением. Системные компоненты, процессы и заказные программы необходимо часто тестировать на предмет того, что защитные
меры соответствуют постоянно меняющейся среде.

Требования PCI DSS Проверочные процедуры Пояснение

11.1 Внедрить процессы 11.1.а Проверить политики и процедуры на наличие в них Установка и (или) использование беспроводных
ежеквартальной проверки на наличие процессов, предписывающих ежеквартально выявлять и технологий в сети являются одними из
беспроводных точек доступа (802.11), а идентифицировать санкционированные и наиболее часто используемых
также выявления и идентификации несанкционированные беспроводные точки доступа. злоумышленниками способов для получения
санкционированных и доступа к сети и ДДК. Если беспроводное
несанкционированных беспроводных 11.1.b Проверить используемую методологию на предмет устройство или сеть установлены без ведома
точек доступа. того, что она достаточна, чтобы выявить и организации, злоумышленник может без труда
идентифицировать любые несанкционированные и незаметно проникать в сеть.
Примечание: в данном процессе могут
беспроводные точки доступа, в т. ч., как минимум, Несанкционированные беспроводные
использоваться, среди прочего,
указанные ниже: устройства могут быть скрыты или подключены
следующие методы: сканировать
к компьютеру, другому компоненту системы или
беспроводные сети, выполнять  беспроводные адаптеры, вставленные в системные
непосредственно к сетевому порту или
физическую или логическую проверку компоненты;
сетевому устройству, такому как
системных компонентов и  портативные или мобильные устройства, маршрутизатор или коммутатор. Любое такое
инфраструктуры, реализовать подключенные к системным компонентам для несанкционированное устройство может
контроль доступа к сети или создания беспроводной точки доступа (например, выполнять роль несанкционированной точки
беспроводные системы обнаружения через USB и т. п.); доступа в среду.
или предотвращения вторжений.
 беспроводные устройства, подключенные к сетевому Зная, какие беспроводные устройства
Какие бы методы ни использовались, порту или сетевому устройству. санкционированы, администраторы могут
они должны быть достаточны, чтобы
быстро обнаруживать несанкционированные
обнаруживать как санкционированные, 11.1.c Если используется сканирование беспроводных беспроводные устройства, а, реагируя на
так и несанкционированные сетей, проверить результаты недавних сканирований обнаружение несанкционированных
устройства. беспроводных сетей на предмет того, что: беспроводных точек доступа, организация
 идентифицируются санкционированные и может заблаговременно снизить уязвимость
несанкционированные беспроводные точки доступа; среды ДДК к действиям злоумышленников.
 сканирование всех системных компонентов и Поскольку подключить к сети беспроводную
помещений проводится, по крайней мере, точку доступа несложно, определить ее
ежеквартально. наличие трудно, а риск от

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 123
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение

11.1.d Если используется автоматизированный несанкционированных беспроводных устройств


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

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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 124
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение

11.2 Проводить внешнее и внутреннее 11.2 Проверить отчеты о результатах сканирования и Сканирование на наличие уязвимостей
сканирование сети на наличие сопутствующую документацию на предмет того, что выполняется с использованием сочетания
уязвимостей не реже одного раза в внешнее и внутреннее сканирование сети на наличие автоматизированных или ручных средств,
квартал, а также после значительных уязвимостей проводится следующим образом: техник и (или) методов,которые проверяют
изменений в сети (например, установки внутренние и внешние сетевые устройства и
новых системных компонентов, серверы и предназначены для того, чтобы
изменения топологии сети, изменения выявлять потенциальные уязвимости, которые
правил межсетевых экранов, могут быть обнаружены и использованы
обновления продуктов). злоумышленниками.
Примечание: в рамках Стандартом PCI DSS требуется три типа
ежеквартального сканирования можно сканирования на наличие уязвимостей:
объединить несколько отчетов о
результатах сканирования, чтобы  ежеквартальное внутреннее сканирование
подтвердить, что все системы были на наличие уязвимостей, проводимое
просканированы, и все квалифицированными работниками (статус
соответствующие уязвимости авторизованного поставщика услуг
обработаны. Может потребоваться сканирования (ASV) по требованиям
дополнительная документация, чтобы стандарта PCI SSC не требуется);
подтвердить, что неустраненные
 ежеквартальное внешнее сканирование на
уязвимости находятся в процессе
устранения. наличие уязвимостей, которое должны
выполнять организации, имеющие статус
Для первоначального соответствия
авторизованного поставщика услуг
стандарту PCI DSS успешное
прохождение четырех ежеквартальных сканирования (ASV);
сканирований необязательно, если  внутреннее и внешнее сканирования, по
аудитор убедился в следующем: 1) необходимости, после значительного
последнее сканирование было пройдено изменения в сети.
успешно, 2) в организации имеются
После обнаружения уязвимостей организация
документированные политики и
процедуры, которые регламентируют устраняет их и проводит повторное
необходимость ежеквартального сканирование пока не устранит их полностью.
сканирования, 3) обнаруженные Своевременное выявление и устранение
уязвимости были устранены и это уязвимостей снижает вероятность того, что
подтверждено повторным злоумышленник будет использовать уязвимость
сканированием (сканированиями). В
и скомпрометирует системный компонент или
течение всех последующих лет после
первоначального подтверждения ДДК.
соответствия стандарту PCI DSS
успешное прохождение всех четырех
ежеквартальных сканирований
обязательно.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 125
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение

11.2.1 Проводить ежеквартальное 11.2.1.a Проверить отчеты сканирования на предмет Установленный процесс выявления
внутреннее сканирование на наличие того, что за последние 12 месяцев было проведено 4 уязвимостей во внутренних системах требует
уязвимостей. Обрабатывать ежеквартальных внутренних сканирования. ежеквартального сканирования уязвимостей.
уязвимости и сканировать повторно, Уязвимости, которые представляют
чтобы проверить, что все уязвимости с 11.2.1.b Проверить отчеты о результатах сканирования максимальный уровень критичности для среды
высоким уровнем критичности на предмет того, что все уязвимости с высоким уровнем (например, те, которым согласно требованию
устанены в соответствии с принятой в критичности обработаны, и процесс сканирования 6.1 присвоен высокий уровень критичности),
организации оценкой критичности включает повторное сканирование, чтобы проверить, должны быть устранены в первую очередь.
уязвимостей (согласно что все уязвимости с высоким уровнем критичности Внутреннее сканирование на наличие
требованию 6.1). Сканирование (согласно определению в требовании 6.1 PCI DSS) уязвимостей могут выполнять
должны выполнять устранены. квалифицированные работники, которые
квалифицированные работники. являются достаточно независимыми
11.2.1.c Опросить работников на предмет того, что относительно сканируемых компонентов
сканирование проводилось квалифицированными системы (например, нельзя, чтобы за
работниками организации либо квалифицированной сканирование межсетевого экрана отвечал его
третьей стороной, а также, если применимо, проверить администратор), либо организация может
тестировщиков на организационную независимость проводить внутреннее сканирование услугами
(наличие у них статуса QSA или ASV не требуется). другой организации, которая занимается
сканированием на наличие уязвимостей.

11.2.2 Проводить ежеквартальное 11.2.2.a Проверить результаты четырех последних Поскольку внешние сети подвержены более
внешнее сканирование на наличие внешних сканирований на наличие уязвимостей и высокому риску компрометации,
уязвимостей с привлечением проверить, проведены ли четыре последние внешние ежеквартальное сканирование на наличие
авторизованного поставщика услуг ежеквартальные сканирования в течение последних уязвимостей в таких сетях должны выполнять
сканирования (ASV), утвержденного 12 месяцев. специалисты авторизованного поставщика
Советом PCI SSC. По необходимости, услуг сканирования, утвержденного Советом
повторять сканирование, пока оно не 11.2.2.b Проверить результаты каждого PCI SSC.
будет пройдено успешно. ежеквартального сканирования (в т. ч. повторных Надежная программа сканирования на наличие
Примечание: для ежеквартального сканирований) на предмет того, что они отвечают уязвимостей обеспечивает выполнение
внешнего сканирования на наличие требованиям «Руководства для авторизованных сканирования и своевременное выявление
уязвимостей использовать поставщиков услуг сканирования» к успешно уязвимостей.
авторизованного поставщика услуг пройденному сканированию (например, отсутствуют
сканирования (ASV), утвержденного уязвимости с оценкой 4.0 и выше по системе CVSS и нет
Советом PCI SSC. ошибок, в результате которых автоматическое
сканирование было прервано).

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 126
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
См. «Руководство для авторизованных 11.2.2.c Проверить отчеты о результатах сканирования
поставщиков услуг сканирования» (ASV на предмет того, что сканирование производилось
Program Guide), опубликованное на веб- авторизованным поставщиком услуг сканирования,
сайте Совета PCI SSC, для получения утвержденным Советом PCI SSC.
информации об обязанностях
заказчиков сканирования, подготовке к
сканированию и т. д.

11.2.3 Проводить внутреннее и 11.2.3.a Проверить и сопоставить документацию по Понятие «значительного изменения» сильно
внешнее сканирования и, при контролю изменений и отчеты о результатах зависит от конфигурации конкретной среды.
необходимости, повторять сканирования на предмет того, что выполнялось Если после обновления или модификации
сканирование после любого сканирование системных компонентов после любых может появиться доступ к ДДК или
значительного изменения в сети. значительных изменений. безопасность среды ДДК может быть снижена,
Сканирование должны выполнять то изменение считается значительным.
квалифицированные работники. 11.2.3.b Проверить отчеты о сканировании на предмет
Сканирование среды после любых
того, что процесс сканирования предусматривает
значительных изменений гарантирует, что
повторять сканирования:
изменения внедрены надлежащим образом, и
 для внешнего сканирования – до тех пор, пока не безопасность среды не была нарушена в
устранены уязвимости с оценкой 4.0 и более по результате этих изменений. Необходимо
системе CVSS; просканировать все системные компоненты, на
 для внутреннего сканирования – до тех пор, пока не которые повлияло изменение.
будут устранены все уязвимости с высоким уровнем
критичности, согласно определению в
требовании 6.1 PCI DSS.
11.2.3.c Убедиться, что сканирование проводилось
квалифицированными работниками организации или
третьей стороны, а также, если применимо, проверить
тестировщиков на организационную независимость
(наличие у них статуса QSA или ASV не требуется).

11.3 Внедрить методологию проведения 11.3 Проверить методологию проведения тестов на Цель теста на проникновение — смоделировать
тестирования на проникновение, проникновение и опросить ответственных работников на реальную атаку, чтобы выявить, насколько
которая: предмет того, что она: глубоко злоумышленник сможет проникнуть в
среду. Благодаря этому, организация может
 основана на общепринятых  основана на общепринятых отраслевых подходах к
лучше разобраться в своих потенциальных
отраслевых подходах к проведению проведению тестирования на проникновение
уязвимостях и разработать стратегию защиты
тестирования на проникновение (например, NIST SP800-115);
от атак.
(например, NIST SP800-115);  охватывает весь периметр среды ДДК и критичные
 охватывает весь периметр среды системы; Тест на проникновение отличается от
сканирования на наличие уязвимостей тем, что
Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 127
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
ДДК и критичные системы;  включает тестирование как снаружи сети, так и внутри первый является активным процессом и он
 включает тестирование как снаружи сети; может включать эксплуатацию обнаруженных
сети, так и внутри сети;  включает тестирование для проверки любых средств уязвимостей. Сканирование на наличие
сегментации и сокращения области применимости; уязвимостей может быть первым, но точно не
 включает тестирование для проверки
единственным шагом, который выполняет
любых средств сегментации и  требует, чтобы тесты на проникновение на уровне
специалист по тестам на проникновение, чтобы
сокращения области применимости; приложения включали, как минимум, проверку на
определить стратегию тестирования. Даже если
 требует, чтобы тесты на наличие уязвимостей, приведенных в требовании 6.5;
сканирование на наличие уязвимостей не
проникновение на уровне  требует, чтобы тесты на проникновение на уровне обнаруживает известные уязвимости,
приложения включали, как минимум, сети охватывали операционные системы и сетевые специалист по тестам на проникновение часто
проверку на наличие уязвимостей, компоненты; получает достаточно информации о системе,
приведенных в требовании 6.5;  включает анализ и оценку угроз и уязвимостей, чтобы выявить потенциальные проблемы
 требует, чтобы тесты на найденных за последние 12 месяцев; безопасности.
проникновение на уровне сети  регламентирует хранение результатов тестов на Тесты на проникновение обычно выполняются
охватывали операционные системы и проникновение и мер, предпринятых для устранения вручную. Даже используя автоматизированные
сетевые компоненты; уязвимостей. средства, тестировщик должен применять свои
 включает анализ и оценку угроз и знания систем для проникновения в среду.
уязвимостей, найденных за Часто тестировщик использует несколько типов
последние 12 месяцев; эксплойтов вместе, чтобы обойти несколько
 регламентирует хранение уровней защиты. Например, если тестировщик
результатов тестов на находит способ получить доступ к серверу
проникновение и мер, предпринятых приложений, он использует
для устранения уязвимостей. скомпрометированный сервер как площадку
для новой атаки, где использует ресурсы,
доступ к которым имеет сервер. Таким образом,
тестировщик может имитировать методы,
которыми пользуются злоумышленники, для
выявления потенциальных уязвимостей среды.
Методы тестирования на проникновение
зависят от организации, а тип, глубина и
сложность тестирования зависят от
конкретной среды и оценки рисков
организации.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 128
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение

11.3.1 Проводить внешний тест на 11.3.1.a Проверить объем работ и результаты Тесты на проникновение, выполняемые по
проникновение не реже одного раза в последнего внешнего теста на проникновение на графику и после значительных изменений в
год и после любых значительных предмет того, что тест на проникновение среде – это превентивная мера, позволяющая
модификаций или обновлений осуществляется: уменьшить риск доступа злоумышленников к
инфраструктуры или приложений  в соответствии с определенной методологией; среде ДДК.
(например, обновления операционной Понятие «значительного» обновления или
 не реже раза в год;
системы, добавления подсети или веб- модификации сильно зависит от конфигурации
сервера к среде).  после любых значительных изменений в среде.
конкретной среды. Если после обновления или
11.3.1.b Убедиться, что тест на проникновение модификации может появиться доступ к ДДК
проводили квалифицированные работники организации или безопасность среды ДДК может быть
либо квалифицированная третья сторона и, если снижена, то изменение считается
применимо, что они организационно независимы значительным. Выполнение тестов на
(наличие у них статуса QSA или ASV не требуется). проникновение после обновления или
модификации сети гарантирует, что
11.3.2 Выполнять внутренний тест на 11.3.2.a Проверить объем работ и результаты существующие механизмы по-прежнему
проникновение не реже одного раза в последнего внутреннего теста на проникновение на работают.
год и после любых значительных предмет того, что тест на проникновение проводится:
модификаций или обновлений  в соответствии с определенной методологией;
инфраструктуры или приложений
 не реже раза в год;
(например, обновления операционной
системы, добавления подсети или веб-  после любых значительных изменений в среде.
сервера к среде).
11.3.2.b Убедиться, что тест на проникновение
проводили квалифицированные работники организации
либо квалифицированная третья сторона и, если
применимо, что они организационно независимы
(наличие у них статуса QSA или ASV не требуется).

11.3.3 Устранять потенциально 11.3.3 Проверить результаты теста на проникновение на


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

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 129
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение

11.3.4 Если для изоляции среды ДДК 11.3.4.а Проверить средства сегментации и Тест на проникновение – это важный
от других сетей используется методологию теста на проникновение и подтвердить, инструмент проверки, что реализованная
сегментация, проводить тест на что процедуры теста на проникновение сегментация действительно изолирует среду
проникновение не реже одного раза в предусматривают тестирование всех методов ДДК от других сетей. Тест на проникновение
год и после любого изменения сегментации на предмет того, что методы сегментации необходимо нацелить на средства сегментации,
средств/методов сегментации на действительно работают и изолируют от остальных все используемые как на границе, так и внутри сети
предмет того, что методы сегментации системы,находящиеся в среде ДДК. организации, но вне среды ДДК. Он должен
действительно работают и изолируют подтвердить, что невозможно преодолеть
от остальных все системы, 11.3.4.b Проверить результаты последнего теста на средства сегментации и получить доступ к
находящиеся в среде ДДК. проникновение на предмет того, что: среде ДДК. Например, проверив сеть и (или)
 тест на проникновение для проверки средств просканировав ее на наличие открытых портов,
сегментации осуществляется не реже одного раза в можно убедиться, что между сетями,
год и после любого изменения средств и (или) входящими в область применимости, и
методов сегментации; остальными сетями подключений нет.
 тест на проникновение распространяется на все
используемые средства и (или) методы
сегментации;
 тест на проникновение проверяет, действительно ли
механизмы и (или) методы сегментации работают и
изолируют все системы, находящиеся в среде ДДК,
от остальных.

11.3.4.с Убедиться, что тест на проникновение


проводили квалифицированные работники организации
либо квалифицированная третья сторона и, если
применимо, что они организационно независимы
(наличие у них статуса QSA или ASV не требуется).

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 130
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение

11.3.4.1 Дополнительное 11.3.4.1.а Проверить результаты последнего теста на Примечание: это требование применимо
требование для поставщиков проникновение на предмет того, что: только для организаций, которые определены
услуг: если применяется сегментация,  тест на проникновение для проверки средств как поставщики услуг.
подтвердить область применимости сегментации осуществляется, как минимум, каждые
PCI DSS путем тестирования на Для поставщиков услуг проверка области
6 месяцев и после любого изменения средств и
проникновение в отношении средств применимости PCI DSS должна осуществляться
(или) методов сегментации;
сегментации, как минимум, каждые 6 как можно чаще для подтверждения того, что
 тест на проникновение распространяется на все область применимости PCI DSS остается
месяцев и после любого изменения
используемые средства и (или) методы актуальной и соответствует изменениям
средств и (или) методов сегментации.
сегментации; бизнес-целей.
Примечание: до 31 января 2018 года
 тест на проникновение проверяет, действительно ли
это требование носит
механизмы и (или) методы сегментации
рекомендательный характер, а после
этой даты становится обязательным эффективно работают и изолируют все системы,
требованием. находящиеся в среде ДДК, от остальных.

11.3.4.1.b Убедиться, что тест на проникновение


проводили квалифицированные работники организации
либо квалифицированная третья сторона и, если
применимо, что они организационно независимы
(наличие у них статуса QSA или ASV не требуется).

11.4 Использовать методы обнаружения 11.4.a Проверить системные конфигурации и схемы сети Методы обнаружения и (или) предотвращения
и (или) предотвращения вторжений для на предмет того, что методы мониторинга (например, вторжений (например, система обнаружения
обнаружения и (или) предотвращения системы обнаружения и (или) предотвращения или предотвращения вторжений, IDS/IPS)
вторжения в сеть. Осуществлять вторжений) используются для всего трафика: сопоставляют поступающий в сеть трафик с
мониторинг всего сетевого трафика по тысячами известных сигнатур и (или) моделей
 по периметру среды ДДК;
периметру среды ДДК и в критичных вредоносного поведения (инструментарий
точках внутри среды ДДК, и оповещать  в критичных точках внутри среды ДДК. злоумышленников, троянское и другое
работников о подозрениях на вредоносное ПО и т. д.), отправляют
11.4.b Проверить системные конфигурации и опросить
компрометацию. предупреждения и (или) блокируют попытку
ответственных работников на предмет того, что средства
Поддерживать в актуальном состоянии проведения атаки. Не используя превентивные
обнаружения и (или) предотвращения вторжений
системы обнаружения и меры для обнаружения несанкционированной
уведомляют работников о подозрениях на
предотвращения вторжений, их деятельности, можно не заметить атаки на
компрометацию.

Стандарт безопасности данных индустрии платежных карт (PCI DSS), версия 3.2 Стр. 131
© PCI Security Standards Council, LLC, 2006–2016. Все права защищены. Апрель 2016 г.
Требования PCI DSS Проверочные процедуры Пояснение
сигнатуры и правила. 11.4.c Проверить конфигурации систем обнаружения или компьютерные ресурсы (или их ненадлежащее
предотвращения вторжений (IDS/IPS) и документацию использование) в момент выполнения. Для
вендоров на предмет того, что, чтобы обеспечить блокирования попыток вторжений необходимо
оптимальную защиту, средства обнаружения и (или) вести мониторинг уведомлений, генерируемых
предотвращения вторжений настроены, поддерживаются данными средствами.
и обновляютс