Построение и поддержание защищенной сети

Требование 1: Должны быть обеспечены разработка и управление конфигурацией межсетевых экранов

в целях защиты данных платежных карт (18)

Вопрос Ответ: Да Нет Комментарий*

1.1 Реализованы ли стандарты конфигурирования
межсетевых экранов (МЭ) и маршрутизаторов,
включающие следующее:

1.1.1 Формализованный процесс утверждения и Регламент сопровождения,

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

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

(включая беспроводные сети) к сегментам с данными конфигурирования и мониторинга
платежных карт корпоративной сети

1.1.3 Требования по размещению МЭ на каждом канале

подключения к сети Интернет, а также на границе
между каждой DMZ и внутренней сетью

1.1.4 Описание групп, ролей и обязанностей в отношении Регламент сопровождения,

логического управления сетевыми компонентами конфигурирования и мониторинга
корпоративной сети

1.1.5 Документирование и обоснование применения для

всех использующихся сервисов, протоколов и портов,
включая документирование реализованных
механизмов защиты для небезопасных протоколов
1.1.6 Пересмотр наборов правил межсетевых экранов (МЭ) Нужны подтверждения -
и маршрутизаторов не реже чем через каждые 6 инфраструктуры еще нет
месяцев
1.2 Ограничивает ли конфигурация МЭ возможность
подключения недоверенных сетей к системным
компонентам среды данных платежных карт:
 1.2

Примечание. Под недоверенной сетью понимается

любая сеть, которая является внешней по
отношению к сетям проверяемой организации.
Организация не может контролировать такую сеть
и управлять ею.
1.2.1 Разрешен ли только такой входящий и исходящий Обеспечивается провайдером
трафик, который является необходимым для среды облачных решений
данных платежных карт?
1.2.2 Обеспечена ли защита и синхронизация Обеспечивается провайдером
конфигурационных файлов маршрутизаторов? облачных решений
1.2.3 Установлены ли МЭ для организации защиты Обеспечивается провайдером
периметра между любыми беспроводными сетями и облачных решений
средой платежных карт и настроены ли эти МЭ на
блокирование любого трафика из беспроводных сетей
в среду данных платежных карт или контроль этого
трафика (если такой трафик необходим для ведения
бизнеса)?

1.3 Запрещает ли конфигурация МЭ прямой доступ из сети

Интернет к любым системным компонентам среды
данных платежных карт:
1.3.1 Реализована ли зона DMZ для ограничения входящего Обеспечивается провайдером
и исходящего трафика только теми протоколами, облачных решений
которые необходимы для среды данных платежных
карт?
1.3.2 Ограничен ли входящий интернет-трафик IP-адресами Обеспечивается провайдером
внутри DMZ? облачных решений
1.3.3 Запрещена ли прямая маршрутизация входящего или Обеспечивается провайдером
исходящего трафика между сетью Интернет и средой облачных решений
данных платежных карт?
1.3.4 Запрещен ли трафик с адресами отправителя из Обеспечивается провайдером
внутренней сети, поступающий в DMZ из сети облачных решений
Интернет?
1.3.5 Ограничен ли трафик, исходящий из среды данных Обеспечивается провайдером
платежных карт в сеть Интернет, таким образом, облачных решений
чтобы исходящему трафику были доступны только IP-
адреса в пределах демилитаризованной зоны (DMZ)?
 1.3.6 Реализована ли фильтрация трафика с учетом Обеспечивается провайдером
состояния соединений (stateful inspection), также облачных решений
известная как динамическая фильтрация пакетов
(когда доступ в сеть разрешается только для
«установленных» соединений)?
1.3.7 Размещена ли база данных во внутреннем сегменте Обеспечивается провайдером
сети, отделенном от DMZ? облачных решений
1.3.8 Реализован ли IP-маскарадинг для предотвращения Обеспечивается провайдером
раскрытия структуры внутренней адресации в сети облачных решений
Интернет и используются ли технологии, реализующие
адресное пространство RFC 1918?

Должны использоваться технологии PAT (Port Обеспечивается провайдером

Address Translation) (например, NAT (Network Address облачных решений
Translation)).
1.4 Установлены ли персональные межсетевые экраны на Требование не применимо.
все портативные и/или личные компьютеры Персональные компьютеров
сотрудников, которые обладают возможностью сотрудников не используются.
прямого доступа к сети Интернет (например, на
ноутбуки сотрудников), и используются ли они для
доступа к сети организации?

Требование 2: Не должны использоваться параметры безопасности и системные пароли,

установленные производителем по умолчанию (11)

Вопрос Ответ: Да Нет Комментарий*

2.1 Были ли изменены параметры, заданные Обеспечивается провайдером
производителем по умолчанию, влияющие на облачных решений
защищенность, до подключения системы к сети?
К таким параметрам относятся, например, пароли,
SNMP-строки, а также удаление неиспользуемых
учетных записей.
2.1.1 Изменялись ли для беспроводных сетей, Обеспечивается провайдером
подключенных к среде данных платежных карт или в облачных решений
которых передаются данные платежных карт,
значения, заданные производителем по умолчанию**?

** Эти значения включают (но не ограничиваются

ими) следующие параметры: ключи шифрования в
беспроводных сетях, пароли и SNMP-строки.

Заданы ли параметры безопасности для технологии

надежного шифрования, используемые при
авторизации пользователей и передаче данных?
2.2 Разработаны ли стандарты конфигурирования для Обеспечивается провайдером
всех системных компонентов? облачных решений
Позволяет ли использование этих стандартов
устранить все известные уязвимости и учитывают ли
эти стандарты рекомендации по обеспечению
безопасности систем (определенные, например,
SysAdmin Audit Network Security Network (SANS),
National Institute of Standards Technology (NIST) и
Center for Internet Security (CIS))?
Включает ли эта мера следующее:

2.2.1 Реализована ли на каждом сервере только одна

основная функция?
2.2.2 Отключены ли все ненужные и небезопасные сервисы
и протоколы (сервисы и протоколы, не являющиеся
необходимыми для выполнения назначенных
устройствам функций)?
2.2.3 Настроены ли параметры безопасности систем для
предотвращения ненадлежащего использования?
2.2.4 Удален ли весь избыточный функционал, например,
скрипты, драйверы, функциональные возможности,
подсистемы, файловые системы и неиспользуемые
веб-серверы?
2.3 Выполняется ли шифрование каждого неконсольного
административного доступа?
 2.3

Для управления с помощью веб-интерфейса и

другого неконсольного административного доступа
должны использоваться такие технологии, как SSH,
VPN или SSL/TLS.
2.4 Если ваша организация является хостинг-провайдером
с общей средой, позволяет ли конфигурация ваших
систем защищать среду размещения и данные
платежных карт каждой обслуживаемой организации?

См. Приложение A. Дополнительные требования

стандарта PCI DSS к хостинг-провайдерам с общей
средой для тех требований стандарта, для которых
необходимо обеспечить соответствие.

2.2 Подтверждение, что все политики безопасности и

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

Защита данных платежных карт

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

Вопрос Ответ: Да Нет Комментарий*

3.1 Сведено ли к минимуму хранение данных платежных Политика хранения и
карт и ограничены ли объем хранимой информации и уничтожения данных платежных
период хранения так, как это необходимо исходя из карт
требований бизнеса, правовых и/или нормативных
актов?
Разработана ли политика хранения и уничтожения
данных платежных карт и содержит ли она
ограничения, указанные в п. (a)?
 3.2 Соответствуют ли все системы следующим
требованиям, относящимся к хранению критичных
данных авторизации после авторизации (даже если
эти данные зашифрованы):
3.2.1 Запрещается хранить полное содержимое любого Обеспечено разработчиком Ответ разработчика
трека с магнитной полосы (расположенного, например, модуля:
на оборотной стороне карты, в чипе или еще где-либо). Имя держателя карты
Эти данные также могут называться полным треком PAN
(full track), треком, первым треком (track 1), вторым Дата истечения срока действия
треком (track 2) или данными магнитной полосы.
Примечание. Обычно при ведении бизнеса
необходимо хранить следующие элементы данных
магнитной полосы карты:
 Имя держателя карты
 Номер платежной карты (PAN)
 Дата истечения срока действия
 Сервисный код
Для минимизации рисков должны храниться лишь те
элементы данных, которые необходимы для ведения
бизнеса. ЗАПРЕЩАЕТСЯ хранить card-verification code
или value и проверочное значение PIN (PIN verification
value).
Примечание. Для получения дополнительной
информации
см. Глоссарий (перечень терминов и сокращений) (PCI
DSS and PA-DSS: Glossary of Terms, Abbreviations, and
Acronyms).

3.2.2 Запрещается хранить card-verification code или value Обеспечено разработчиком Ответ разработчика
(трех- или четырехзначное число, напечатанное на модуля
карте), использующиеся для проверки транзакций,
совершающихся в отсутствие карты.
Примечание. Для получения дополнительной
3.2.3 Запрещается
информации хранить PIN-коды или зашифрованные Не применимо Ответ разработчика
PIN-блоки
см. Глоссарий (перечень терминов и сокращений) (PCI
3.3 DSS and PA-DSS:
Маскируются Glossary
ли номера PANof Terms, Abbreviations, and
при отображении Обеспечено разработчиком
Acronyms).
(максимальным количеством разрешенных к модуля
отображению цифр являются первые шесть и
последние четыре цифры)?
 Примечания:
§   Это требование не применяется к сотрудникам
компании и третьим сторонам, имеющим
обоснованную необходимость видеть полный номер
карты (PAN).
 Настоящее требование не отменяет действующие
более строгие требования к отображению данных
платежных карт, например, на чеках POS-терминалов.

3.4 Приведены ли номера PAN к нечитаемому виду вне Обеспечено разработчиком Ответ разработчика
зависимости от места хранения (включая данные на модуля:
портативных носителях, резервных копиях, в шифрование при хранении;
журналах, а также данные, полученные из усечение при отображении в
беспроводных сетей или хранимые в них) с помощью интерфейсах и выдаче из АПИ;
одного из перечисленных ниже способов: замена центральных цифр на "Х"
 Одностороннее хеширование, использующее в логах.
алгоритмы надежной криптографии
 Усечение
 Index token и PAD (PAD должны храниться в
безопасности)
 Надежная криптография совместно с процессами и
процедурами управления ключами шифрования.
Из информации, относящейся к счету, ПО КРАЙНЕЙ
МЕРЕ номер PAN должен быть приведен к
нечитаемому виду.
Если по каким-либо причинам компания не может
привести номер PAN к нечитаемому виду, необходимо
обратиться к Приложению В. Компенсационные меры.
Примечание. Определение термина «надежная
криптография» приведено в Глоссарии (перечне
терминов и сокращений)
(PCI DSS and PA-DSS: Glossary of Terms, Abbreviations,
and Acronyms).
3.4.1 При шифровании дисков (вместо шифрования на
уровне файлов или на уровне полей базы данных):
 Управляется ли логический доступ независимо от
встроенных механизмов контроля доступа
операционной системы (например, баз данных учетных
записей локальной системы)?
 Запрещена ли привязка ключей расшифровки к
учетным записям пользователей?

3.5 Защищены ли ключи, использующиеся для Шифрование используется, Ответ разработчика - шифрование используе
шифрования данных платежных карт, от доступ ограничен.
несанкционированного разглашения и ненадлежащего Ключем шифрования и KEK
использования? являются 2048-байтные rsa-
ключи; карточные данные
3.5.1 Предоставлен ли доступ к криптографическим ключам шифруются блочным CBC
минимальному количеству сотрудников, которым он алгоритмом
необходим? Инструкция по обращению с
3.5.2 Выполняется ли безопасное хранение шифровальными
криптографических ключей? (криптографическими)
средствами.
3.6 1. Полностью ли документированы и реализованы все
процессы и процедуры управления
криптографическими ключами для ключей,
использующихся при шифровании данных платежных
карт?
2. Включают ли они следующее:

3.6.1 Генерация стойких криптографических ключей

3.6.2 Безопасное распределение криптографических ключей

3.6.3 Безопасное хранение криптографических ключей

3.6.4 Периодическая замена криптографических ключей:
§   в соответствии с рекомендациями и
необходимостью связанного приложения (например,
смена ключей шифрования); предпочтительно
автоматически;
 по крайней мере ежегодно.

3.6.5 Отмена или замена старых или заподозренных в

компрометации криптографических ключей
 3.6.6 Разделение информации о криптографическом ключе
между несколькими лицами и разделение ключей

3.6.7 Предотвращение несанкционированной подмены

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

Требование 4: Должно обеспечиваться шифрование данных платежных карт, передаваемых по сетям

общего пользования (3)

Вопрос Ответ: Да Нет Комментарий*

4.1 Используются ли для защиты критичных данных Обеспечено разработчиком
платежных карт при их передаче по сетям общего модуля:
пользования надежная криптография и протоколы, TLS
обеспечивающие защиту передаваемых данных,
например, SSL/TLS, IPSEC?
Примерами открытых сетей общего пользования, на
которые распространяется стандарт PCI DSS,
являются сеть Интернет, беспроводные сети, сети
GSM и GPRS.
4.1.1 Используется ли для реализации надежного Обеспечено разработчиком
шифрования при авторизации и передаче данных в модуля:
беспроводных сетях, в которых передаются данные TLS
платежных карт или которые подключены к среде
данных платежных карт, накопленный в отрасли опыт
(например, стандарт IEEE 802.11i)?
 Примечания:
§   В новых реализациях беспроводных сетей начиная
с 1 апреля 2009 г. запрещено использовать протокол
WEP.
§   В действующих беспроводных сетях начиная с 1
июля 2010 г. запрещено использование протокола
WEP.

4.2 Запрещают ли требования существующей политики Обеспечено разработчиком

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

Реализация программы управления уязвимостями

Требование 5: Должно использоваться и регулярно обновляться антивирусное программное обеспечение

(3)

Вопрос Ответ: Да Нет Комментарий*

5.1 Установлено ли антивирусное программное Сервера с операционной
обеспечение на всех системах, подверженных системой CentOS
воздействию вредоносных программ (персональных
компьютерах и серверах)?
5.1.1 Обладает ли антивирусное программное обеспечение Сервера с операционной
способностью обнаружения, удаления и защиты от системой CentOS
всех известных типов вредоносного программного
обеспечения?
5.2 Включена ли постоянная антивирусная защита, Сервера с операционной
регулярно ли обновляются механизмы обеспечения системой CentOS
антивирусной защиты и обладают ли возможностью
генерации журналов регистрации событий?
Требование 6: Должна обеспечиваться безопасность при разработке и поддержке систем и
приложений (33)

Вопрос Ответ: Да Нет Комментарий*

6.1 §   Установлены ли для всех системных Обеспечивается провайдером
компонентов и программного обеспечения облачных решений
самые последние обновления безопасности,
предоставленные производителями?
§   Установлены ли обновления безопасности,
относящиеся к используемым системам, в
течение 1 месяца с момента их выпуска?
Примечание. Организация может использовать
подход, основанный на анализе рисков, для
приоритезации установки обновлений безопасности.
Например, назначать важнейшим инфраструктурам
(общедоступным устройствам и системам, базам
данных) более высокий приоритет, чем менее
важным внутренним инфраструктурам, чтобы
обеспечить установку обновлений безопасности на
приоритетных системах и устройствах не позднее
чем через 1 месяц после их выпуска, а на системах и
устройствах, имеющих более низкий приоритет, –
не позднее чем через 3 месяца.

6.2 §   Существует ли процесс идентификации

вновь обнаруженных уязвимостей
безопасности (например, подписка на
рассылки, связанные с информационной
безопасностью и обнаружением уязвимостей,
свободно доступные в сети Интернет)?

Обновляются ли стандарты конфигурирования

в соответствии с требованием 2.2 для
устранения новых проблем, связанных с
уязвимостями?
 6.3 1. Производится ли разработка программного Обеспечено разработчиком
обеспечения в соответствии со стандартом PCI DSS модуля
(например,
необходимо обеспечить безопасную авторизацию и
вход в систему), с учетом накопленного в данной
отрасли опыта и учитывает ли вопросы обеспечения
информационной безопасности на всех стадиях
процесса разработки?
2. Обеспечивается ли следующее:

6.3.1 До внедрения в среду эксплуатации должно Положение по обеспечению ИБ

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

6.3 Проверка правильности обработки ошибок Обеспечено разработчиком

.1. модуля
2
6.3 Проверка защиты хранимых криптографических
.1. материалов
3
6.3 Проверка защиты коммуникаций
.1.
4
6.3 Проверка правильности управления доступом на
.1. основе ролей
5 Должны быть разделены среды разработки,
6.3.2 Положение по обеспечению ИБ
тестирования и эксплуатации на этапах ЖЦ ПО
6.3.3 Должно существовать разделение обязанностей в
средах разработки, тестирования и эксплуатации
6.3.4 Для тестирования или разработки не должны
использоваться данные из среды эксплуатации
(реальные номера PAN)
6.3.5 Должно выполняться удаление тестовых учетных
записей и данных до внедрения в среду эксплуатации
6.3.6 Учетные записи, идентификаторы пользователей и
пароли в разработанном программном обеспечении
должны быть удалены до внедрения этого
программного обеспечения в среду эксплуатации или
его передачи клиенту
6.3.7 Для идентификации потенциальных уязвимостей в
разработанном программном обеспечении должен
выполняться анализ кода перед запуском этого ПО в
эксплуатацию или его передачей заказчику.
Примечание. Требование анализа кода должно
применяться ко всем типам кодов (как внутренним,
так и общедоступным) на всех стадиях процесса
разработки системы в соответствии с
требованием 6.3. Анализ кода может выполняться
квалифицированными сотрудниками компании. Если
веб-приложения являются общедоступными, то к
ним также должны применяться дополнительные
меры защиты безопасности для устранения угроз
безопасности и уязвимостей после их реализации в
соответствии с требованием 6.6.

6.4 3. Осуществляется ли внесение любых изменений в Приказ о вводе в опытную

системные компоненты в соответствии с процедурами эксплуатацию.
управления изменениями? Регламент сопровождения
 Обеспечивают ли процедуры управления модуля.
изменениями следующее:

6.4.1 Документирование влияния, оказываемого

изменением
6.4.2 Утверждение руководством

6.4.3 Тестирование работоспособности

6.4.4 Процедуры отката

 6.5 Разрабатываются ли все веб-приложения (внутренние Обеспечено разработчиком
и внешние, включая доступ к приложению с правом модуля
администратора) с учетом рекомендаций по Требуется подтверждение от
программированию защищенных веб-приложений, аудитора:
например, рекомендаций Open Web Application Security ASV-сканирование;
Project Guide (OWASP)? тест на проникновение.

4. Выполняется ли с целью идентификации

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

6.5.1 Межсайтовое выполнение сценариев (XSS)

6.5.2 Инъекции, в частности SQL-инъекции

Также следует принять во внимание LDAP- и Xpath-

инъекции, как и другие угрозы внедрения кода.
6.5.3 Выполнение вредоносного кода

6.5.4 Небезопасные прямые ссылки на объекты

6.5.5 Подделка межсайтового запроса

6.5.6 Утечка информации и неправильная обработка ошибок

6.5.7 Уязвимости подсистемы аутентификации и управления

сеансами
6.5.8 Уязвимости, связанные с хранением
криптографических материалов
 6.5.9 Небезопасные коммуникации

6.5.10 Невозможность ограничения доступа пользователей к

URL-адресам
6.6 Ведется ли постоянная работа по нейтрализации Процедура управления
новых угроз и устранению новых уязвимостей в управления корректирующими и
общедоступных веб- приложениях и защищаются ли превентивными действиями
эти приложения от известных атак с помощью одного СОИБ
из приведенных ниже методов:
§   Анализ веб-приложений с помощью Требуется подтверждение от
ручных или автоматизированных аудитора:
средств или методов оценки защиты ASV-сканирование;
приложений от уязвимостей не реже тест на проникновение.
чем 1 раз в год или после внесения в
них любых изменений

§   Установка межсетевого экрана для Обеспечивается провайдером

защиты общедоступных веб- облачных решений
приложений

Реализация мер по строгому контролю доступа

Требование 7: Доступ к данным платежных карт должен быть ограничен в соответствии со служебной
необходимостью (9)

Вопрос Ответ: Да Нет Комментарий*

 7.1 1. Предоставляется ли доступ к системным Регламент сопровождения
компонентам и данным платежных карт только тем модуля или изменения в
сотрудникам, Регламент сопровождения ПС
которым он необходим для выполнения их (новые роли и формы заявок)
должностных обязанностей?
Включает ли ограничение доступа следующие меры:

7.1.1 Права привилегированных пользователей ограничены

минимально достаточными полномочиями,
необходимыми для выполнения их должностных
обязанностей
7.1.2 Назначение полномочий сотрудникам в системах
выполняется в соответствии с должностью и
выполняемыми функциями
7.1.3 Для предоставления полномочий необходимо наличие
заявки с перечнем запрашиваемых прав,
утвержденной руководством
7.1.4 Использование автоматизированных систем контроля Обеспечивается провайдером
доступа облачных решений
7.2 1. Реализована ли для многопользовательских Обеспечено разработчиком
системных компонентов система контроля доступа, модуля
ограничивающая
доступ по принципу необходимого знания,
запрещающий любой доступ, не разрешенный явно?
2. Включает ли эта система следующие
характеристики:

7.2.1 Распространяется на все системные компоненты Обеспечено разработчиком

модуля
7.2.2 Назначает пользовательские полномочия в
соответствии с должностью и выполняемыми
функциями
7.2.3 По умолчанию запрещает любые виды доступа

Требование 8: Каждому лицу, имеющему доступ к вычислительным ресурсам, должен быть назначен
уникальный идентификатор (20)
 Вопрос Ответ: Да Нет Комментарий*
8.1 Присваивается ли каждому пользователю уникальный Обеспечено разработчиком
идентификатор до предоставления доступа к модуля
системным компонентам или данным платежных карт?

8.2 Используется ли в дополнение к назначению Обеспечено разработчиком

уникального идентификатора для всех пользователей модуля
по крайней мере один из следующих механизмов
аутентификации:
§   Пароль или кодовая фраза
§   Двухфакторная аутентификация
(например, устройства
аутентификации, смарт-карты,
биометрия или открытые ключи)
8.3 Реализована ли двухфакторная аутентификация для Обеспечивается провайдером
предоставления удаленного доступа (доступа сетевого облачных решений
уровня, осуществляемого из-за пределов внутренней
сети) в сеть служащим компании, администраторам
или третьим лицам?
Должны использоваться такие технологии, как
RADIUS или TACACS с аппаратными устройствами
аутентификации; либо VPN (на базе протоколов
SSL/TLS или IPSEC) с пользовательскими
сертификатами

8.4 Приведены ли все пароли к нечитаемому виду при Обеспечено разработчиком

передаче и хранении на всех системных компонентах с модуля
помощью алгоритмов надежной криптографии
(определение термина «надежная криптография» см. в
Глоссарии (перечне терминов и сокращений) (PCI DSS
and PA-DSS: Glossary of Terms, Abbreviations, and
Acronyms)?
 8.5 Обеспечиваются ли для учетных записей сотрудников
и администраторов на всех системных компонентах
надежная аутентификация и управление паролями, как
описано в следующих пунктах:

8.5.1 Контролируется ли добавление, удаление и изменение Функционал администратора ИБ

пользовательских идентификаторов, учетных данных и
других объектов идентификации?
8.5.2 Выполняется ли проверка подлинности пользователей Обеспечено разработчиком
перед сбросом их паролей? модуля
8.5.3 Являются ли пароли для каждого пользователя
уникальными и изменяются ли они сразу же после
первого использования?
8.5.4 Аннулируется ли доступ для каждого сотрудника сразу
после его увольнения?
8.5.5 Выполняется ли удаление/отключение неактивных Обеспечено разработчиком
учетных записей пользователей по крайней мере модуля
каждые 90 дней?
8.5.6 Активируются ли учетные записи, использующиеся Регламент сопровождения
производителями для осуществления удаленной модуля
поддержки, только на период оказания поддержки?
8.5.7 Доводятся ли парольные политики и процедуры до
всех пользователей, обладающих возможностью
доступа к данным платежных карт?
8.5.8 Запрещено ли использование групповых, разделяемых
или встроенных учетных записей и паролей?

8.5.9 Изменяются ли пользовательские пароли по крайней Обеспечено разработчиком

мере каждые 90 дней? модуля
8.5.10 Составляет ли длина паролей как минимум 7
символов?
8.5.11 Содержат ли пароли как цифры, так и буквы?

8.5.12 Запрещено ли задание нового пароля, если он

совпадает с любым из последних четырех ранее
использовавшихся паролей?
 8.5.13 Ограничено ли количество неудачных попыток
получения доступа блокированием идентификатора
пользователя по крайней мере после 6 неудачных
попыток?
8.5.14 Составляет ли продолжительность блокирования
идентификатора пользователя минимум 30 минут или
до активации учетной записи администратором?
8.5.15 Выполняется ли повторный запрос пароля
пользователя для разблокирования терминала при
отсутствии активности во время пользовательского
сеанса более 15 минут?
8.5.16 Аутентифицируется ли любой доступ к любой базе
данных, содержащей данные платежных карт? (В том
числе доступ, осуществляемый приложениями,
администраторами и любыми другими
пользователями.)

Требование 9: Физический доступ к данным платежных карт должен быть ограничен (27)

Вопрос Ответ: Да Нет Комментарий*

9.1 Используется ли для ограничения и отслеживания Обеспечивается провайдером
физического доступа к системам, в которых хранятся, облачных решений
обрабатываются или передаются данные платежных
карт, надежный механизм контроля доступа в
помещения?
9.1.1 Используются ли для наблюдения за критичными
помещениями видеокамеры или другие механизмы
контроля физического доступа?
Примечание. Под критичным помещением
понимается любой центр обработки данных,
серверное помещение или любое помещение, в
котором находятся системы, в которых хранятся
данные платежных карт. К нимне относятся
помещения, в которых находятся только POS-
терминалы, например, зона кассовых аппаратов в
розничном магазине.
 Проводится ли анализ данных
видеонаблюдения и их сопоставление с
другими событиями?
Хранятся ли данные видеонаблюдения по
крайней мере в течение 3 месяцев, если это
не противоречит законодательству?
9.1.2 Ограничен ли физический доступ к сетевым разъемам, Обеспечивается провайдером
расположенным в публично доступных местах? облачных решений

9.1.3 Ограничен ли физический доступ к беспроводным

точкам доступа, маршрутизаторам и портативным
устройствам?
9.2 Разработаны ли процедуры, позволяющие персоналу
легко отличать сотрудников компании от посетителей,
особенно в тех помещениях, в которых существует
возможность получения доступа к данным платежных
карт?
В данном требовании под сотрудниками понимаются
лица, работающие в компании полный рабочий день,
или частично занятые лица, временные служащие и
персонал,лица, работающие по договорам, а также
консультанты, постоянно находящиеся в компании.
Термин «посетитель» относится к производителям,
гостям сотрудников, обслуживающему персоналу или
лицам, которым необходимо посетить помещение в
течение короткого промежутка времени, обычно не
превышающего 1 день.

9.3 Выполняется ли в отношении всех посетителей Обеспечивается провайдером

следующее: облачных решений
9.3.1 Авторизация до входа в помещения, в которых
обрабатываются данные платежных карт
9.3.2 Выдача физического средства идентификации
(например, пропуска или устройства доступа) с
ограниченным сроком действия, отличающего
посетителей от сотрудников компании
9.3.3 Изъятие физического средства идентификации перед
уходом или по истечении срока действия
9.4 Ведется ли журнал регистрации посетителей с целью Обеспечивается провайдером
хранения записей о них? облачных решений
Записываются ли в него имя посетителя, название
компании, которую он представляет, и имя сотрудника,
разрешившего физический доступ?
Хранится ли этот журнал по крайней мере в течение 3
месяцев, если это не противоречит законодательству?

9.5 Хранятся ли носители с резервными копиями в

защищенных местах, предпочтительно во внешних
помещениях, например, альтернативном или
резервном помещении или в коммерческом хранилище
информации?
Проверяются ли эти защищенные места по крайней
мере 1 раз в год?
9.6 Обеспечивается ли физическая защита всех бумажных Политика хранения и
и электронных носителей, содержащих данные уничтожения данных платежных
платежных карт? карт
9.7 Обеспечивается ли строгий контроль за
внутренним или внешним перемещением
носителей всех видов, содержащих данные
платежных карт?
Включает ли эта мера следующее:
9.7.1 Маркировку носителей, чтобы они могли быть
идентифицированы как содержащие
конфиденциальную информацию
9.7.2 Отправку носителей с доверенным курьером или с
помощью другого способа доставки, который можно
проконтролировать
9.8 Утверждает ли руководство перемещение всех
носителей, содержащих данные платежных карт, за
пределы защищенной территории (в особенности если
носители передаются отдельным лицам)?
 9.9 Обеспечивается ли строгий контроль хранения и
доступности носителей, содержащих данные
платежных карт?
9.9.1 Ведутся ли журналы инвентаризации всех
носителей?
Выполняется ли инвентаризация носителей не
реже 1 раза в год?
9.10 Уничтожаются ли носители, содержащие данные
платежных карт, если их хранение больше не
обосновано с точки зрения соблюдения требований
законодательства или выполнения бизнес-задач?
Уничтожаются ли носители следующими способами:

9.10.1 Перекрестное измельчение, сожжение или

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

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

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

данным платежных карт (25)

Вопрос Ответ: Да Нет Комментарий*

10.1 Реализован ли процесс, связывающий осуществление Обеспечивается провайдером
любого доступа к системным компонентам (в облачных решений
особенности доступа с использованием
административных привилегий, например, root) с
конкретными пользователями?
10.2 Выполняется ли для всех системных компонентов
регистрация событий с целью восстановления:
10.2.1 Любого доступа пользователей к данным платежных
карт
10.2.2 Всех действий, выполненных с использованием
административных привилегий
10.2.3 Доступа ко всем журналам регистрации событий

10.2.5 Неудачных попыток логического доступа

10.2.6 Использования механизмов идентификации и

аутентификации
10.2.7 Инициализации журналов регистрации событий

10.2.8 Создания и удаления системных объектов

10.3 Записываются ли в регистрируемых событиях для

каждого системного компонента следующие элементы:

10.3.1 Идентификатор пользователя

10.3.2 Тип события

10.3.3 Дата и время

10.3.4 Индикатор успеха или отказа

10.3.5 Источник события

10.3.6 Идентификатор или название задействованных

данных, системного компонента или ресурса
10.4 Выполняется ли синхронизация времени на всех
критичных системах?
10.5 Защищены ли журналы регистрации событий от
внесения изменений?
Обеспечивает ли эта мера следующее:
10.5.1 Разрешен ли просмотр журналов регистрации событий
только тем сотрудникам, которым это необходимо для
выполнения должностных обязанностей?

10.5.2 Защищены ли файлы журналов регистрации событий

от несанкционированных изменений?
10.5.3 Выполняется ли своевременное резервирование
файлов с зарегистрированными событиями на
централизованный log- сервер или носители, где их
сложнее изменить?
10.5.4 Копируются ли журналы регистрации событий
публично доступных систем на log-сервер во
внутренней сети?
10.5.5 Используется ли для журналов регистрации событий
программное обеспечение контроля целостности
файлов и обнаружения изменений для обеспечения
того, что существующие данные в журналах не смогут
быть изменены без генерации предупреждения (при
этом добавление новых данных не должно вызывать
генерации предупреждения)?

10.6 Выполняется ли по крайней мере ежедневный Обеспечивается провайдером

просмотр журналов зарегистрированных событий для облачных решений
всех системных компонентов?
Просмотр журналов регистрации событий должен
включать журналы серверов, выполняющих функции
обеспечения безопасности, например, систем
обнаружения вторжений (IDS) и серверов
аутентификации, авторизации и учета (Authentication,
Authorization, Accounting, AAA), например, RADIUS.

Примечание. Для достижения соответствия

требованию10.6 может использоваться
инструментарий для сбора, анализа событий и
уведомления.
 10.7 Хранятся ли журналы регистрации событий по крайней Обеспечивается провайдером
мере в течение 1 года таким образом, чтобы они в облачных решений
течение 3 месяцев были доступны в режиме
оперативного доступа для анализа (например, в
режиме онлайн, в виде архива или чтобы их можно
было восстановить из резервной копии)?

Требование 11: Должно выполняться регулярное тестирование систем и процессов обеспечения

безопасности

Вопрос Ответ: Да Нет Комментарий*

11.1 Проводится ли тестирование наличия точек Обеспечивается аудитором -
беспроводного доступа с помощью анализатора Отчеты о тестах на
беспроводных сетей по крайней мере ежеквартально проникновение
или используются ли беспроводные системы IDS/IPS
для идентификации всех используемых беспроводных
устройств?

11.2 Проводятся ли внутренние и внешние сканирования

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

Примечание. Ежеквартальное внешнее сканирование

уязвимостей сети должно выполняться
организацией, имеющей статус ASV (Approved
Scanning Vendor), квалификация которой
подтверждена Payment Card Industry Security
Standards Council (PCI SSC). Сканирования,
проводимые после внесения изменений в сеть, могут
выполняться внутренним персоналом компании.
 11.3 Проводятся ли по крайней мере ежегодно, а также Обеспечивается аудитором.
после любых значительных модернизаций или
модификаций инфраструктуры или приложений
(например, обновление версии ОС, добавление
подсети или веб-сервера) внешние и внутренние тесты
на проникновение?

Включают ли эти тесты на проникновение следующее:

11.3.1 Тесты на проникновение на сетевом уровне

11.3.2 Тесты на проникновение на уровне приложений

11.4 Используются ли для мониторинга всего сетевого Обеспечивается провайдером

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

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

Требование 12: Должна поддерживаться политика информационной безопасности, регламентирующая

деятельность сотрудников и контрагентов (45)

Вопрос Ответ: Да Нет Комментарий*

12.1 Была ли разработана, опубликована, утверждена и Политика информационной
доведена до сотрудников политика информационной безопасности
безопасности, которая включает следующее:
12.1.1 Учитывает все требования данного стандарта

12.1.2 Содержит описание ежегодного процесса

идентификации угроз и уязвимостей, завершающегося
формализованной оценкой рисков
12.1.3 Проведение по крайней мере ежегодного пересмотра
политики ИБ и ее обновления при изменении
инфраструктуры
 12.2 Разработаны ли типовые периодически выполняемые Нормативные документы СОИБ
процедуры обеспечения безопасности,
соответствующие требованиям данного стандарта
(например, процедуры управления пользовательскими
учетными записями и процедуры анализа журналов
регистрации событий)?

12.3 Разработаны ли политики допустимого использования

персональных устройств и технологий, которые могут
быть использованы сотрудниками (например,
технологии удаленного доступа, технологии
беспроводного доступа, съемные носители,
портативные компьютеры, персональные цифровые
секретари (PDA), электронная почта и сеть Интернет),
чтобы определить их допустимое использование для
всех сотрудников и контрагентов?
Содержат ли политики допустимого использования
следующие требования:

12.3.1 Явное утверждение руководством

12.3.2 Прохождение аутентификации перед использованием

технологии
12.3.3 Перечень используемых устройств и сотрудников,
имеющих к ним доступ
12.3.4 Маркировка устройств с указанием имени владельца,
контактной информации и назначения
12.3.5 Допустимое использование технологий

12.3.6 Допустимое размещение используемых устройств в

сети
12.3.7 Перечень разрешенных к использованию типов
устройств
12.3.8 Автоматическое отключение сеансов удаленного
доступа по истечении определенного периода
бездействия
 12.3.9 Включение технологий удаленного доступа для
осуществления поддержки производителями только
при необходимости и немедленное отключение после
использования
12.3.10 Запрет копирования, перемещения и сохранения Политика хранения и
данных платежных карт на локальных дисках и уничтожения данных платежных
съемных носителях при осуществлении удаленного карт
доступа к данным платежных карт
12.4 Определяют ли в явном виде политика и процедуры
информационной безопасности обязанности по
обеспечению ИБ для сотрудников и контрагентов?
12.5 Назначены ли следующие обязанности по управлению Политика информационной
ИБ на индивидуальных сотрудников или группы безопасности
сотрудников:
12.5.1 Разработка, документирование и доведение до
сотрудников политик и процедур безопасности
12.5.2 Мониторинг и анализ событий ИБ, а также
информирование соответствующего персонала
12.5.3 Разработка, документирование и распределение Процедура обработки
процедур реагирования на инциденты безопасности и инцидентов ИБ в платежной
процедуры эскалации для обеспечения своевременной системе
и эффективной обработки инцидентов, связанных с
безопасностью
12.5.4 Администрирование пользовательских учетных Регламент предоставления
записей, включая добавление, удаление и доступа к информационным
модификацию ресурсам вычислительной сети
12.5.5 Мониторинг и контроль любого доступа к данным

12.6 Реализована ли формализованная программа Процедура повышения

повышения осведомленности сотрудников в вопросах осведомленности и обучения
ИБ для обеспечения понимания сотрудниками вопросам ИБ
важности защиты данных платежных карт?

12.6.1 Выполняется ли обучение сотрудников при найме на

работу и по крайней мере ежегодно?
12.6.2 Подтверждают ли сотрудники письменно не реже чем
1 раз в год прочтение и понимание политики и
процедур ИБ?
12.7 Проверяются ли сотрудники при их приеме на работу
для минимизации риска внутренних атак (определение
термина «сотрудник» см. в п. 9.2 выше)?

Для таких сотрудников, как кассиры магазинов,

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

12.8 Если данные платежных карт доступны нескольким ДДК не доступны нескольким
сервис-провайдерам, реализованы ли и выполняются сервис-провайдерам
ли политики и процедуры управления сервис-
провайдерами, включающие следующее:
12.8.1 Поддержание перечня сервис-провайдеров

12.8.2 Составление соглашения, подтверждающего

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

12.8.4 Должна быть разработана программа для

отслеживания статуса соответствия сервис-
провайдера стандарту PCI DSS
12.9 Включает ли план реагирования на инциденты ИБ План ОНиВД
следующее в целях обеспечения немедленного
реагирования на нарушение информационной
безопасности какой-либо системы?
12.9.1 Разработан ли план реагирования на инциденты ИБ,
выполняемый при компрометации системы?
Содержит ли этот план по крайней мере следующее:
 §   Роли и обязанности, а также
стратегии уведомления при инциденте
(например, информирование
платежных систем)
§   Конкретные процедуры
реагирования на инциденты ИБ
§   Процедуры восстановления и
обеспечения непрерывности бизнеса
§   Процедуры резервирования данных

§   Анализ правовых требований по

отчетности при компрометациях
§   Покрытие и реагирование для всех
критичных системных компонентов
§   Ссылки на процедуры реагирования
на инциденты от платежных систем
или сами процедуры
12.9.2 Проводится ли по крайней мере ежегодное
тестирование плана?
12.9.3 Назначены ли сотрудники, реагирующие на инциденты
ИБ 7 дней в неделю 24 часа в сутки?
12.9.4 Выполняется ли соответствующее обучение
персонала, ответственного за реагирование на
инциденты ИБ?
12.9.5 Выполняется ли наблюдение за событиями от систем
IDS, IPS и систем контроля?
12.9.6 Реализован ли процесс изменения и развития плана
реагирования на инциденты ИБ в соответствии с
приобретенным опытом и с учетом развития отрасли
ИБ?

Приложение A. Дополнительные требования стандарта PCI DSS к хостинг-

провайдерам с общей средой

Требование А.1: Хостинг-провайдеры должны защищать среду данных платежных карт (4)
 Вопрос Ответ: Да Нет Комментарий*
A.1 Выполняется ли защита среды размещения и данных Обеспечивается провайдером
каждой обслуживаемой организации (ТСО, сервис- облачных решений
провайдера или другой организации), как описывается
в пп. А.1.1–А.1.4?
Хостинг-провайдер должен выполнять эти требования
в дополнение к остальным имеющим к нему
отношение требованиям стандарта PCI DSS.
Примечание. Даже в случае соответствия хостинг-
провайдера перечисленным требованиям
необязательно обеспечивается соответствие
стандарту PCI DSS организации, пользующейся
услугами этого хостинг- провайдера. Каждая
организация должна соответствовать стандарту
PCI DSS и при необходимости подтверждать свое
соответствие.

A.1.1 Использует ли каждая организация только те

процессы, которые имеют доступ к ее среде данных
платежных карт?
A.1.2 Ограничены ли доступ и привилегии каждой
организации только собственной средой платежных
карт?
A.1.3 Включены ли журналы аудита и регистрации событий
индивидуально для среды платежных карт каждой
организации и в соответствии с требованием 10
стандарта PCI DSS?
A.1.4 Реализованы ли процессы, позволяющие провести
своевременное расследование инцидентов в случае
компрометации размещенных данных любой ТСО или
сервис- провайдера?
а - шифрование используется, доступ ограничен