1.1.1
Определенные Требования к Подходу:

Все политики безопасности и операционные процедуры, указанные в Требовании 1:

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

 

Требование 1.1.1 касается эффективного управления и поддержания различных политик и процедур, указанных в Требовании 1.

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

 

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

 

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

1.1.2
Определенные Требования к Подходу:
Роли и обязанности для выполнения действий, указанных в Требовании 1, задокументированы, распределены и поняты.

Цель Индивидуального Подхода:
Распределяются повседневные обязанности по выполнению всех действий, указанных в Требовании 1. Персонал несет ответственность за успешное и непрерывное выполнение этих требований.

Определенные Процедуры Тестирования Подхода:

Цель:
Если роли и обязанности официально не распределены, персонал может не знать о своих повседневных обязанностях, и важные действия могут не выполняться.

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

Определения:
Метод документирования ролей и обязанностей - это матрица распределения обязанностей, которая включает в себя, кто несет ответственность, подотчетен, консультируется и информируется (также называемая матрицей RACI).

1.2.1
Определенные Требования к Подходу:
Стандарты конфигураций для наборов правил NSC:

Цель Индивидуального подхода:
Способы настройки и работы NSC определены и последовательно применяются.

Определенные Процедуры Тестирования Подхода:

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

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

Определения:
NSC являются ключевыми компонентами сетевой архитектуры.
Чаще всего NSCS используются на границах CDE для управления сетевым трафиком, входящим и исходящим из CDE. Стандарты конфигурации определяют минимальные требования организации к конфигурации ее NSCS.

Примеры:
Примеры NSC, охватываемых этими стандартами конфигурации, включают, но не ограничиваются: брандмауэры, маршрутизаторы, настроенные со списками контроля доступа, и облачные виртуальные сети.

1.2.2
Определенные Требования к Подходу:
Все изменения в сетевых подключениях и конфигурациях NSCS утверждаются и управляются в соответствии с процессом управления изменениями, определенным в Требовании 6.5.1.

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

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

Определенные Процедуры Тестирования Подхода:

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

1.2.3
Определенные Требования к Подходу:
Поддерживается точная сетевая схема (схемы), которая показывает все соединения между CDE и другими сетями, включая любые беспроводные сети.

Цель Индивидуального подхода:
Осуществляется и выполнимо определение границ между CDE, всеми доверенными сетями и всеми ненадежными сетями.

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

Определенные Процедуры Тестирования Подхода:

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

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

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

1.2.4
Определенные Требования к Подходу:
Поддерживается точная схема (схемы) потока (потоков) данных, отвечающая следующим требованиям:

Цель Индивидуального подхода:
Осуществляется и выполнимо представление информации о любом обмене учетных данных между компонентами системы и между сегментами сети.

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

Определенные Процедуры Тестирования Подхода:

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

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

1.2.5
Определенные Требования к Подходу:
Все разрешенные службы, протоколы и порты идентифицированы, одобрены и соответствуют определенным бизнес-потребностям.

Цель Индивидуального подхода:
Несанкционированный сетевой трафик (службы, протоколы или пакеты, предназначенные для определенных портов) не может попадать в сеть или выходить из нее.

Определенные Процедуры Тестирования Подхода:

Цель:
Компрометации часто происходят из-за неиспользуемых или небезопасных служб (например, telnet и FTP), протоколов и портов, поскольку это может привести к открытию ненужных точек доступа в CDE. Кроме того, службы, протоколы и порты, которые включены, но не используются, часто игнорируются и остаются незащищенными и необновленными. Определяя службы, протоколы и порты, необходимые для бизнеса, организации могут гарантировать, что все другие службы, протоколы и порты будут отключены или удалены.

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

1.2.6
Определенные Требования к Подходу:
Функции безопасности определяются и реализуются для всех служб, протоколов и портов, которые используются и считаются небезопасными, таким образом, чтобы снизить риск.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Компрометируются небезопасные сетевые конфигурации.

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

Дополнительная информация:
Для получения рекомендаций по службам, протоколам или портам, которые считаются небезопасными, обратитесь к отраслевым стандартам и рекомендациям (например, от NIST, ENISA, OWASP).

1.2.7
Определенные Требования к Подходу:
Конфигурации NSC пересматриваются не реже одного раза в шесть месяцев для подтвердждения их актуальности и эффективности.

Цель Индивидуального подхода:
Конфигурации NSC, которые разрешают или ограничивают доступ к доверенным сетям, периодически проверяются, чтобы гарантировать, что разрешены только авторизованные подключения с текущим бизнес-обоснованием.

Определенные Процедуры Тестирования Подхода:

Цель:
Такая проверка дает организации возможность очистить любые ненужные, устаревшие или неправильные правила и конфигурации, которые могут быть использованы неуполномоченным лицом. Кроме того, это гарантирует, что все правила и конфигурации разрешают только авторизованные службы, протоколы и порты, соответствующие документированным бизнес-обоснованиям.

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

1.2.8
Определенные Требования к Подходу:
Файлы конфигурации для NSCs:

Цель Индивидуального подхода:
NSCS не могут быть определены или изменены с использованием ненадежных объектов конфигурации (включая файлы).

Примечания по применению:
Любой файл или параметр, используемый для настройки или синхронизации NSCS, считается “файлом конфигурации”. Сюда входят файлы, автоматизированные и системные элементы управления, сценарии, настройки, инфраструктура в виде кода или другие параметры, которые копируются, архивируются или хранятся удаленно.

Определенные Процедуры Тестирования Подхода:

Цель:
Чтобы предотвратить применение несанкционированных конфигураций к сети, сохраненные файлы с конфигурациями для сетевых элементов управления должны обновляться и защищаться от несанкционированных изменений.
Сохранение актуальной и безопасной информации о конфигурации гарантирует, что правильные настройки для NSCS применяются при каждом запуске конфигурации.

Примеры:
Если защищенная конфигурация маршрутизатора хранится в энергонезависимой памяти, при перезапуске или перезагрузке этого маршрутизатора эти элементы. 

1.3.1
Определенные Требования к Подходу:
Входящий трафик в CDE ограничен следующим образом:

Цель Индивидуального подхода:
Несанкционированный трафик не может попасть в CDE.

Определенные Процедуры Тестирования Подхода:

Цель:
Это требование направлено на предотвращение доступа злоумышленников к сети организации через несанкционированные IP-адреса или несанкционированного использования служб, протоколов или портов.

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

Примеры:
Реализация правила, запрещающего весь входящий и исходящий трафик, который специально не требуется — например, с помощью явного “запретить все” или неявного запрета после инструкции allow — помогает предотвратить непреднамеренные ошибки, которые допускают непреднамеренный и потенциально вредоносный трафик.

1.3.2
Определенные Требования к Подходу:

Исходящий трафик из CDE ограничен следующим образом:

Цель Индивидуального подхода:
Несанкционированный трафик не может покинуть CDE.

Определенные Процедуры Тестирования Подхода:

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

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

Примеры:
Реализация правила, запрещающего весь входящий и исходящий трафик, который специально не требуется — например, с помощью явного “запретить все” или неявного запрета после инструкции allow — помогает предотвратить непреднамеренные ошибки, которые допускают непреднамеренный и потенциально вредносный трафик.

1.3.3
Определенные Требования к Подходу:
NSCS устанавливаются между всеми беспроводными сетями и CDE, независимо от того, является ли беспроводная сеть CDE, так что:

Цель Индивидуального подхода:
Несанкционированный трафик не может пересекать границы сети между любыми беспроводными сетями и проводными средами в CDE.

Определенные Процедуры Тестирования Подхода:

Цель:
Известная (или неизвестная) реализация и использование беспроводной технологии в сети является распространенным способом получения злоумышленниками доступа к сети и данным учетной записи. Если беспроводное устройство или сеть установлены без ведома субъекта, злоумышленник может легко и “незаметно” проникнуть в сеть. Если NSCS не ограничивают доступ из беспроводных сетей в CDE, злоумышленники, которые получают несанкционированный доступ к беспроводной сети, могут легко подключиться к CDE и скомпрометировать информацию учетной записи.

1.4.1
Определенные Требования к Подходу:
NSCs реализуются между доверенными и ненадежными сетями.

Цель Индивидуального подхода:
Несанкционированный трафик не может пересекать границы сети между доверенными и ненадежными сетями.

Определенные Процедуры Тестирования Подхода:

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

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

1.4.2
Определенные Требования к Подходу:

Входящий трафик из ненадежных сетей в доверенные сети ограничен:

Цель Индивидуального подхода:
Только авторизованный трафик или трафик, являющийся ответом на системный компонент в доверенной сети, может поступать в доверенную сеть из ненадежной сети.

Примечания по применению:
Целью этого требования является рассмотрение сеансов связи между доверенными и ненадежными сетями, а не специфики протоколов. Это требование не ограничивает использование UDP или других сетевых протоколов без установления соединения, если состояние поддерживается NSC.

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Системные компоненты, предоставляющие общедоступные службы, такие как электронная почта, веб-серверы и DNS-серверы, наиболее уязвимы для угроз, исходящих из ненадежных сетей.
В идеале такие системы размещаются в выделенной доверенной сети, которая является общедоступной (например, DMZ), но которая отделена через NSCS от более критичных внутренних систем, что помогает защитить остальную часть сети в случае взлома систем, доступных извне. Эта функция предназначена для предотвращения доступа злоумышленников к внутренней сети организации из Интернета или несанкционированного использования служб, протоколов или портов.
Если эта функциональность предоставляется как встроенная функция NSC, организация должна убедиться, что ее конфигурации не приводят к отключению или обходу функциональности.

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

1.4.3
Определенные Требования к Подходу:
Меры по борьбе с подменой адресов применяются для обнаружения и блокирования входа поддельных IP-адресов источника в доверенную сеть.

Цель Индивидуального подхода:
Пакеты с поддельными IP-адресами источника не могут попасть в доверенную сеть.

Определенные Процедуры Тестирования Подхода:

Цель:
Фильтрация пакетов, поступающих в доверенную сеть, помогает, среди прочего, гарантировать, что пакеты не “подделываются”, чтобы выглядеть так, как будто они поступают из собственной внутренней сети организации. Например, меры по борьбе с подменой предотвращают попадание внутренних адресов, исходящих из Интернета, в DMZ.

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

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

1.4.4
Определенные Требования к Подходу:
Системные компоненты, в которых хранятся данные о держателях карт, недоступны напрямую из ненадежных сетей.

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

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

Определенные Процедуры Тестирования Подхода:

Цель:
Данные о держателях карт, к которым можно получить прямой доступ из ненадежной сети, например, потому, что они хранятся в системе в пределах DMZ или в облачной службе баз данных, легче получить доступ внешнему злоумышленнику, поскольку существует меньше защитных уровней для проникновения. Использование NSCS для обеспечения того, чтобы к компонентам системы, в которых хранятся данные о держателях карт (например, к базе данных или файлу), можно было получить прямой доступ только из доверенных сетей, может предотвратить попадание несанкционированного сетевого трафика на системный компонент.

1.4.5
Определенные Требования к Подходу:
Раскрытие внутренних IP-адресов и информации о маршруте только авторизованным сторонам.

Цель Индивидуального подхода:
Внутренняя сетевая информация защищена от несанкционированного раскрытия.

Определенные Процедуры Тестирования Подхода:

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

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

Примеры:
Способы скрытия IP-адресации могут включать, но не ограничиваться ими:

1.5.1
Определенные Требования к Подходу:

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

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

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

Определенные Процедуры Тестирования Подхода:

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

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

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

2.1.1
Определенные Требования к Подходу:
Все политики безопасности и операционные процедуры, указанные в Требовании 2:

Цель Индивидуального подхода:
Ожидания, средства контроля и надзор за выполнением мероприятий в рамках Требования 2 определяются и соблюдаются соответствующим персоналом. Все вспомогательные действия повторяемы, последовательно применяются и соответствуют намерениям руководства.

Определенные Процедуры Тестирования Подхода:

Цель:
Требование 2.1.1 касается эффективного управления и поддержания различных политик и процедур, указанных в Требовании 2. Хотя важно определить конкретные политики или процедуры, указанные в Требовании 2, не менее важно обеспечить их надлежащее документирование, поддержание и распространение.

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

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

2.1.2
Определенные Требования к Подходу:
Роли и обязанности для выполнения действий, указанных в Требовании 2, задокументированы, распределены и поняты.

Цель Индивидуального подхода:
Распределяются повседневные обязанности по выполнению всех действий, указанных в Требовании 2. Персонал несет ответственность за успешное и непрерывное выполнение этих требований.

Определенные Процедуры Тестирования Подхода:

Цель:
Если роли и обязанности официально не распределены, персонал может не знать о своих повседневных обязанностях, и важные действия могут не выполняться.

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

Примеры:
Метод документирования ролей и обязанностей - это матрица распределения обязанностей (также называемая матрицей RACI).

2.2.1
Определенные Требования к Подходу:
Стандарты конфигурации разрабатываются, внедряются и поддерживаются в соответствии с рекомендациями:

Цель Индивидуального подхода:
Все компоненты системы сконфигурированы надежно и последовательно в соответствии с принятыми в отрасли стандартами безопасности или рекомендациями поставщиков.

Определенные Процедуры Тестирования Подхода:

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

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

Дополнительная информация:
Источники информации для руководства по стандартам конфигурации включают, но не ограничиваются ими: Центр безопасности Интернета (CIS), Международная организация по стандартизации (ISO), Национальный институт стандартов и технологий (NIST), Альянс облачной безопасности и поставщики продуктов.

2.2.2
Определенные Требования к Подходу:
Учетные записи поставщика по умолчанию управляются следующим образом: 

Цель Индивидуального подхода:
Доступ к системным компонентам с использованием паролей по умолчанию невозможен.

Примечания по применению:
Это относится ко ВСЕМ учетным записям и паролям поставщика по умолчанию, включая те, которые используются операционными системами, программным обеспечением, предоставляющим службы безопасности, учетными записями приложений и систем, терминалами точек продаж (POS), платежными приложениями и протоколами простого сетевого управления (SNMP) по умолчанию.
Это требование также применяется, если системный компонент не установлен в среде организации, например, программное обеспечение и приложения, которые являются частью CDE и доступны через облачную службу подписки.

Определенные Процедуры Тестирования Подхода:

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

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

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

2.2.3
Определенные Требования к Подходу:
Основные функции, требующие различных уровней безопасности, управляются следующим образом:

или

или

Цель Индивидуального подхода:
Основные функции с более низкими требованиями к безопасности не могут повлиять на безопасность основных функций с более высокими требованиями к безопасности в том же компоненте системы.

Определенные Процедуры Тестирования Подхода:

Цель:
Системы, содержащие комбинацию служб, протоколов и демонов для их основной функции, будут иметь профиль безопасности, соответствующий для обеспечения эффективной работы этой функции. Например, системы, которые должны быть напрямую подключены к Интернету, будут иметь определенный профиль, например DNS-сервер, веб-сервер или сервер электронной коммерции. И наоборот, другие системные компоненты могут выполнять основную функцию, содержащую другой набор служб, протоколов и демонов, которые выполняют функции, которые объект не хочет предоставлять в Интернет. Это требование направлено на обеспечение того, чтобы различные функции не влияли на профили безопасности других служб таким образом, который может привести к их работе на более высоком или более низком уровне безопасности.

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

2.2.4
Определенные Требования к Подходу:
Включаются только необходимые службы, протоколы, демоны и функции, а все ненужные функции удаляются или отключаются.

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

Определенные Процедуры Тестирования Подхода:

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

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

Примеры:
Ненужные функциональные возможности могут включать, но не ограничиваться ими, скрипты, драйверы, функции, подсистемы, файловые системы, интерфейсы (USB и Bluetooth) и ненужные веб-серверы.

2.2.5
Определенные Требования к Подходу:
Если присутствуют какие-либо небезопасные службы, протоколы или демоны:

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

Определенные Процедуры Тестирования Подхода:

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

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

Дополнительная информация:
Для получения рекомендаций по службам, протоколам или демонам, которые считаются небезопасными, обратитесь к отраслевым стандартам и рекомендациям (например, опубликованным NIST, ENISA и OWASP).

2.2.6
Определенные Требования к Подходу:
Параметры безопасности системы настроены для предотвращения неправильного использования.

Цель Индивидуального подхода:
Системные компоненты не могут быть скомпрометированы из-за неправильной настройки параметров безопасности.

Определенные Процедуры Тестирования Подхода:

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

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

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

2.2.7
Определенные Требования к Подходу:
Весь административный доступ, не связанный с консольным доступом, шифруется с использованием надежной криптографии.

Цель Индивидуального подхода:
Открытые текстовые факторы авторизации администратора не могут быть прочитаны или перехвачены из любых сетевых передач.

Примечания по применению:
Это включает в себя административный доступ через браузерные интерфейсы и интерфейсы прикладного программирования (API).

Определенные Процедуры Тестирования Подхода:

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

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

Примеры:
Протоколы открытого текста (такие как HTTP, telnet и т.д.) не шифруют трафик или данные входа в систему, что упрощает перехват этой информации злоумышленником. Неконсольный доступ может быть облегчен с помощью технологий, обеспечивающих альтернативный доступ к системам, включая, но не ограничиваясь этим, внеполосный (OOB), управление отключением света (LOM), Интеллектуальный интерфейс управления платформой (IPMI) и переключатели клавиатуры, видео, мыши (KVM) с удаленными возможностями. Эти и другие технологии и методы, не связанные с консольным доступом, должны быть защищены надежной криптографией

Дополнительная информация:
Обратитесь к отраслевым стандартам и передовой практике, таким как NIST SP 800-52 и SP 800-57.

2.3.1
Определенные Требования к Подходу:
Для беспроводных сред, подключенных к CDE или передающих данные учетной записи, все настройки поставщика беспроводной связи по умолчанию изменяются при установке или подтверждаются как безопасные: 

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

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

Определенные Процедуры Тестирования Подхода:

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

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

2.3.2
Определенные Требования к Подходу:
Для беспроводных сред, подключенных к CDE или передающих данные учетной записи, беспроводные ключи шифрования изменяются:

Цель Индивидуального подхода:
Знание беспроводных ключей шифрования не может обеспечить несанкционированный доступ к беспроводным сетям.

Определенные Процедуры Тестирования Подхода:

Цель:
Изменение ключей беспроводного шифрования всякий раз, когда кто-то, знающий ключ, покидает организацию или переходит на роль, которая больше не требует знания ключа, помогает ограничить знание ключей только теми, кому это необходимо для бизнеса.
Кроме того, изменение ключей шифрования беспроводной сети всякий раз, когда подозревается или известно, что ключ содержит, делает беспроводную сеть более устойчивой к компрометации.

Надлежащая практика:
Эта цель может быть достигнута несколькими способами, включая периодическую смену ключей, смену ключей с помощью определенного процесса “joiners-movers-leavers” (JML), внедрение дополнительных технических средств контроля и отказ от использования фиксированных предварительно разделяемых ключей.
Кроме того, управление любыми ключами, которые, как известно, или предположительно скомпрометированы, должно осуществляться в соответствии с планом реагирования организации на инциденты в соответствии с требованием 12.10.1.

3.1.1
Определенные Требования к Подходу:
Все политики безопасности и операционные процедуры, указанные в Требовании 3:

Цель Индивидуального подхода:
Ожидания, средства контроля и надзор за выполнением мероприятий в рамках Требования 3 определяются и соблюдаются соответствующим персоналом. Все вспомогательные действия повторяемы, последовательно применяются и соответствуют намерениям руководства.

Определенные Процедуры Тестирования Подхода:

Цель:
Требование 3.1.1 касается эффективного управления и поддержания различных политик и процедур, указанных в Требовании 3. Хотя важно определить конкретные политики или процедуры, указанные в Требовании 3, не менее важно обеспечить их надлежащее документирование, поддержание и распространение.

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

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

3.1.2
Определенные Требования к Подходу:
Роли и обязанности для выполнения действий, указанных в Требовании 3, задокументированы, распределены и поняты.

Цель Индивидуального подхода:
Распределяются повседневные обязанности по выполнению всех действий, указанных в Требовании 3. Персонал несет ответственность за успешное и непрерывное выполнение этих требований.

Определенные Процедуры Тестирования Подхода:

Цель:
Если роли и обязанности официально не распределены, персонал может не знать о своих повседневных обязанностях, и важные действия могут не выполняться.

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

Примеры:
Метод документирования ролей и обязанностей - это матрица распределения обязанностей, которая включает в себя, кто несет ответственность, подотчетен, консультируется и информируется (также называемая матрицей RACI).

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

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

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

Определенные Процедуры Тестирования Подхода:

Цель:
Официальная политика хранения данных определяет, какие данные необходимо хранить, как долго и где эти данные хранятся, чтобы их можно было безопасно уничтожить или удалить, как только в них больше не будет необходимости. Единственными данными учетной записи, которые могут быть сохранены после авторизации, являются основной номер учетной записи или PAN (нечитаемый), дата истечения срока действия, имя владельца карты и код обслуживания.
Хранение данных SAD до завершения процесса авторизации также включено в политику хранения и удаления данных, так что хранение этих конфиденциальных данных сведено к минимуму и сохраняется только в течение определенного периода времени.

Надлежащая практика:
При определении мест хранения данных учетной записи учитывайте все процессы и персонал, имеющие доступ к данным, поскольку данные могли быть перемещены и сохранены в других местах, чем первоначально определено. Места хранения, которые часто упускаются из виду, включают системы резервного копирования и архивирования, съемные устройства хранения данных, бумажные носители и аудиозаписи.
Чтобы определить соответствующие требования к хранению, организация сначала должна понять свои собственные бизнес-потребности, а также любые юридические или нормативные обязательства, применимые к ее отрасли или к типу сохраняемых данных. Внедрение автоматизированного процесса для обеспечения автоматического и безопасного удаления данных по истечении установленного срока хранения может помочь гарантировать, что данные учетной записи не будут храниться сверх того, что необходимо для деловых, юридических или нормативных целей.
Методы удаления данных, когда они превышают срок хранения, включают безопасное удаление для полного удаления данных или их восстановления и невозможности восстановления. Идентификация и безопасное удаление сохраненных данных, срок хранения которых превысил установленный срок, предотвращает ненужное хранение данных, которые больше не нужны. Этот процесс может быть автоматизированным, ручным или сочетанием того и другого.
Функция удаления в большинстве операционных систем не является “безопасным удалением”, поскольку она позволяет восстановить удаленные данные, поэтому вместо этого необходимо использовать специальную функцию безопасного удаления или приложение, чтобы сделать данные невосстановимыми.
Помните, если он вам не нужен, не храните его!

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

Дополнительная информация:
См. NIST SP 800-88 Rev.1, Руководство по санитарной обработке носителей.

3.3.1
Определенные Требования к Подходу:
SAD не сохраняется после авторизации, даже если он зашифрован. Все полученные конфиденциальные аутентификационные данные становятся невосстановимыми после завершения процесса авторизации

Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.

Примечания по применению:
Это требование не распространяется на эмитентов и компании, которые поддерживают услуги выдачи (где SAD необходим для законных бизнес-потребностей выпуска) и имеют бизнес-обоснование для хранения конфиденциальных аутентификационных данных.
Дополнительные требования, конкретно касающиеся эмитентов, см. в Требовании 3.3.3.
Конфиденциальные аутентификационные данные включают данные, указанные в требованиях 3.3.1.1-3.3.1.3.

Определенные Процедуры Тестирования Подхода:

Цель:
SAD очень ценен для злоумышленников, поскольку позволяет им создавать поддельные платежные карты и совершать мошеннические транзакции. Поэтому хранение SAD после завершения процесса авторизации запрещено.

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

3.3.1.1
Определенные Требования к Подходу:
Полное содержимое любого трека не сохраняется после завершения процесса авторизации.

Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.

Примечания по применению:
В ходе обычной работы может потребоваться сохранить следующие элементы данных из трека:

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

Определенные Процедуры Тестирования Подхода:

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

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

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

3.3.1.2
Определенные Требования к Подходу:
Код подтверждения карты не сохраняется после завершения процесса авторизации.

Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Если данные кода подтверждения карты украдены, злоумышленники могут совершать мошеннические транзакции через Интернет и по почте/по телефону (MO/TO). Отказ от хранения этих данных снижает вероятность их компрометации.

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

3.3.1.3
Определенные Требования к Подходу:
Личный идентификационный номер (PIN-код) и блок PIN-кода не сохраняются после завершения процесса авторизации.

Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.

Примечания по применению:
Блоки PIN-кода шифруются в ходе естественного процесса транзакций, но даже если объект снова зашифрует блок PIN-кода, его все равно нельзя сохранить после завершения процесса авторизации.

Определенные Процедуры Тестирования Подхода:

Цель:
PIN-код и блоки PIN-кодов должны быть известны только владельцу карты или организации, выпустившей карту. Если эти данные будут украдены, злоумышленники могут совершать мошеннические транзакции на основе PIN-кода (например, покупки в магазине и снятие средств в банкоматах). Отказ от хранения этих данных снижает вероятность их компрометации.

Примеры:
Источники данных, которые необходимо проверить, чтобы убедиться, что PIN-код и PIN-коды не сохраняются после завершения процесса авторизации, включают, но не ограничиваются ими:

3.3.2
Определенные Требования к Подходу:
Информация, хранящаяся в электронном виде до завершения авторизации, шифруется с использованием надежной криптографии.

Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.

Примечания по применению:
Разрешено ли хранение SAD до авторизации, определяется организациями, которые управляют программами соответствия требованиям (например, платежными брендами и эквайерами). Свяжитесь с интересующими вас организациями для получения любых дополнительных критериев.
Это требование распространяется на все хранилища SAD, даже если в среде нет PAN.
Обратитесь к Требованию 3.2.1 для получения дополнительного требования, которое применяется, если SAD сохраняется до завершения авторизации.
Это требование не распространяется на эмитентов и компании, которые поддерживают услуги по выпуску, если существует законное коммерческое обоснование для хранения SAD).
Требования, предъявляемые конкретно к эмитентам, приведены в Требовании 3.3.3.
Это требование не заменяет порядок управления блоками PIN-кодов и не означает, что правильно зашифрованный блок PIN-кодов должен быть зашифрован снова.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

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

Определения:
Процесс авторизации завершается, как только получен ответ на запрос авторизации, то есть утверждение или отклонение.

3.3.3
Определенные Требования к Подходу:
Дополнительное требование к эмитентам и компаниям, которые поддерживают услуги выдачи и хранят конфиденциальные аутентификационные данные: Любое хранение конфиденциальных аутентификационных данных:

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

Примечания по применению:
Это требование распространяется только на эмитентов и компании, которые поддерживают услуги выдачи и хранят конфиденциальные данные аутентификации.
Организации, которые выпускают платежные карты или которые предоставляют или поддерживают услуги по выдаче, часто создают и контролируют конфиденциальные аутентификационные данные в рамках функции выдачи. Компаниям, которые предоставляют, облегчают или поддерживают выдачу услуг, разрешается хранить конфиденциальные данные аутентификации ТОЛЬКО в том случае, ЕСЛИ у них есть законная деловая потребность в хранении таких данных.
Требования PCI DSS предназначены для всех организаций, которые хранят, обрабатывают или передают данные учетной записи, включая эмитентов. Единственным исключением для эмитентов и обработчиков данных эмитентов является то, что конфиденциальные аутентификационные данные могут быть сохранены, если для этого есть законная причина. Любые такие данные должны храниться надежно и в соответствии со всеми стандартами PCI DSS и конкретными требованиями платежного бренда.
Приведенный выше маркер (для шифрования хранимых данных с помощью надежной криптографии) является наилучшей практикой до 31 марта 2025 года, после чего он потребуется как часть требования 3.3.3 и должен быть полностью рассмотрен во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

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

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

Дополнительная информация:
Обратитесь к ISO/DIS 9564-5 Финансовые услуги — Личный идентификационный номер (PIN-код)

3.4.1
Определенные Требования к Подходу:
При отображении PAN маскируется (ячейка и последние четыре цифры - это максимальное количество отображаемых цифр), так что только персонал с законными деловыми потребностями может видеть больше, чем ячейка и последние четыре цифры PAN.

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

Примечания по применению:
Это требование не отменяет более строгих требований, предъявляемых к отображению данных о держателях карт, например, юридических требований или требований к платежным маркам для чеков в точках продаж (POS).
Это требование относится к защите PAN, когда он отображается на экранах, бумажных квитанциях, распечатках и т.д., И его не следует путать с требованием 3.5.1 о защите PAN при хранении, обработке или передаче.

Определенные Процедуры Тестирования Подхода:

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

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

Определения:
Маскировка не является синонимом усечения, и эти термины не могут использоваться взаимозаменяемо. Маскирование относится к сокрытию определенных цифр во время отображения или печати, даже если в системе хранится вся панорама целиком. Это отличается от усечения, при котором усеченные цифры удаляются и не могут быть восстановлены в системе. Замаскированный PAN может быть “разоблачен”, но нет никакого "удаления усечения" без воссоздания PAN из другого источника.

Дополнительная информация:
Для получения дополнительной информации о маскировании и усечении см. Часто задаваемые вопросы PCI SSC по этим темам.

3.4.2
Определенные Требования к Подходу:
При использовании технологий удаленного доступа технические средства контроля предотвращают копирование и/или перемещение PAN для всего персонала, за исключением тех, у кого есть документально подтвержденное, четкое разрешение и законная, определенная деловая потребность.

Цель Индивидуального подхода:
PAN не может быть скопирован или перемещен неавторизованным персоналом с использованием технологий удаленного доступа.

Примечания по применению:
Хранение или перемещение PAN на локальные жесткие диски, съемные электронные носители и другие устройства хранения данных позволяет использовать эти устройства для PCI DSS.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

Цель:
Перемещение PAN на несанкционированные устройства хранения является распространенным способом получения и использования этих данных мошенническим путем.
Методы обеспечения того, чтобы копировать или перемещать PAN могли только те, у кого есть явное разрешение и законные деловые причины, сводят к минимуму риск получения доступа к PAN посторонними лицами.

Надлежащая практика:
Копирование и перемещение PAN следует выполнять только на устройства хранения, которые разрешены и разрешены для данного пользователя.

Определения:
Виртуальный рабочий стол - это пример технологии удаленного доступа. Устройства хранения данных включают, но не ограничиваются ими, локальные жесткие диски, виртуальные диски, съемные электронные носители, сетевые диски и облачные хранилища.

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

3.5.1
Определенные Требования к Подходу:
PAN становится нечитаемым в любом месте, где хранится, с использованием любого из следующих подходов:

Цель Индивидуального подхода:
Открытый текстовый файл не может быть считан с носителя.

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

Определенные Процедуры Тестирования Подхода:

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

Дополнительная информация:
Для получения информации о форматах усечения и усечении в целом см. Часто задаваемые вопросы PCI SSC по этой теме.
Источники информации о токенах индекса включают:

3.5.1.1
Определенные Требования к Подходу:
Хэши, используемые для того, чтобы сделать PAN нечитаемым (согласно первому пункту Требования 3.5.1), представляют собой криптографические хэши с ключом для всего PAN, с соответствующими процессами и процедурами управления ключами в соответствии с требованиями 3.6 и 3.7.

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

Определенные Процедуры Тестирования Подхода:

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

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

Дополнительная информация:
Соответствующие алгоритмы криптографического хеширования с ключом включают, но не ограничиваются ими: HMAC, CMAC и GMAC с эффективной криптографической надежностью не менее 128 бит (NIST SP 800-131Ar2).
Обратитесь к следующему для получения дополнительной информации о HMAC, CMAC и GMAC, соответственно: NIST SP 800-107r1, NIST SP 800-38B и NIST SP 800-38D).
См. NIST SP 800-107 (Редакция 1): Рекомендация для приложений, использующих одобренные алгоритмы хэширования §5.3.

3.5.1.2
Определенные Требования к Подходу:
Если шифрование на уровне диска или раздела (а не шифрование базы данных на уровне файлов, столбцов или полей) используется для того, чтобы сделать PAN нечитаемым, оно реализуется только следующим образом:

ИЛИ

Цель Индивидуального подхода:
Это требование не подходит для индивидуального подхода.

Примечания по применению:
Хотя шифрование диска все еще может присутствовать на устройствах такого типа, оно не может быть единственным механизмом, используемым для защиты данных, хранящихся в этих системах. Любой сохраненный PAN также должен быть сделан нечитаемым в соответствии с требованием 3.5.1 — например, с помощью усечения или механизма шифрования на уровне данных. Полное шифрование диска помогает защитить данные в случае физической потери диска, и поэтому его использование подходит только для съемных устройств хранения электронных носителей.
Носители, являющиеся частью архитектуры центра обработки данных (например, диски с возможностью горячей замены, массовые резервные копии на магнитной ленте), считаются несъемными электронными носителями, к которым применяется требование 3.5.1
Реализации шифрования диска или раздела также должны соответствовать всем другим требованиям к шифрованию PCI DSS и управлению ключами

Определенные Процедуры Тестирования Подхода:

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

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

3.5.1.3
Определенные Требования к Подходу:
Если используется шифрование на уровне диска или раздела (а не шифрование базы данных на уровне файлов, столбцов или полей), чтобы сделать PAN нечитаемым, оно управляется следующим образом:

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

Примечания по применению:
Реализации шифрования диска или раздела также должны соответствовать всем другим требованиям к шифрованию PCI DSS и управлению ключами.

Определенные Процедуры Тестирования Подхода:

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

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

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

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

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

Определенные Процедуры Тестирования Подхода:

Цель:
Криптографические ключи должны быть надежно защищены, поскольку те, кто получит доступ, смогут расшифровать данные.

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

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

3.6.1.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поддерживается документированное описание криптографической архитектуры, которое включает:

Цель Индивидуального подхода:
Поддерживаются и доступны точные сведения о криптографической архитектуре.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
В облачных реализациях HSM ответственность за криптографическую архитектуру в соответствии с этим требованием будет разделена между поставщиком облачных услуг и облачным заказчиком.
Вышеприведенный пункт (для включения в криптографическую архитектуру, чтобы предотвратить использование одних и тех же криптографических ключей в производстве и тестировании) является наилучшей практикой до 31 марта 2025 года, после чего он потребуется как часть требования 3.6.1.1 и должен быть полностью рассмотрен во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

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

3.6.1.2
Определенные Требования к Подходу:
Секретные и закрытые ключи, используемые для шифрования/дешифрования сохраненных данных учетной записи, постоянно хранятся в одной (или нескольких) из следующих форм:

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

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

ИЛИ

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

Надлежащая практика:
Если ключи шифрования данных хранятся в HSM, канал взаимодействия HSM должен быть защищен, чтобы предотвратить перехват операций шифрования или дешифрования.

3.6.1.3
Определенные Требования к Подходу:
Доступ к компонентам криптографических ключей с открытым текстом ограничен минимальным количеством необходимых хранителей.

Цель Индивидуального подхода:
Доступ к компонентам криптографического ключа открытого текста ограничен необходимым персоналом.

Определенные Процедуры Тестирования Подхода:

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

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

3.6.1.4
Определенные Требования к Подходу:
Криптографические ключи хранятся в минимально возможном количестве мест.

Цель Индивидуального подхода:
Криптографические ключи сохраняются только там, где это необходимо.

Определенные Процедуры Тестирования Подхода:

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

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

Цель Индивидуального подхода:
Генерируются надежные криптографические ключи.

Определенные Процедуры Тестирования Подхода:

Цель:
Использование надежных криптографических ключей значительно повышает уровень безопасности зашифрованных данных учетной записи.

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

Цель Индивидуального подхода:
Криптографические ключи защищены во время распространения

Определенные Процедуры Тестирования Подхода:

Цель:
Безопасное распространение или передача секретных или частных криптографических ключей означает, что ключи распространяются только уполномоченным хранителям, как указано в требовании 3.6.1.2, и никогда не распространяются небезопасно.

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

Цель Индивидуального подхода:
Криптографические ключи защищены при хранении.

Определенные Процедуры Тестирования Подхода:

Цель:
Хранение ключей без надлежащей защиты может предоставить доступ злоумышленникам, что приведет к расшифровке и раскрытию данных учетной записи.

Надлежащая практика:
Ключи шифрования данных можно защитить, зашифровав их с помощью ключа шифрования ключей. Ключи могут храниться в Аппаратном модуле безопасности (HSM).
Секретные или закрытые ключи, которые могут расшифровывать данные, никогда не должны присутствовать в исходном коде.

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

Цель Индивидуального подхода:
Криптографические ключи не используются за пределами их определенного криптопериода.

Определенные Процедуры Тестирования Подхода:

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

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

Дополнительная информация: 
NIST SP 800-57 Часть 1, редакция 5, Раздел 5.3 Криптопериоды - содержит руководство по установлению периода времени, в течение которого конкретный ключ разрешен для использования законными субъектами, или ключи для данной системы будут оставаться в силе. Рекомендуемые криптопериоды для различных типов ключей приведены в таблице 1 SP 800-57, часть 1.

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

Цель Индивидуального подхода:
Ключи удаляются из активного использования, когда есть подозрение или известно, что целостность ключа ослаблена.

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

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Архивированные криптографические ключи следует использовать только для целей дешифрования/проверки.
Решение для шифрования должно предусматривать и облегчать процесс замены ключей, которые подлежат замене или которые, как известно, или предположительно скомпрометированы. Кроме того, управление любыми ключами, которые, как известно, или предположительно скомпрометированы, должно осуществляться в соответствии с планом реагирования организации на инциденты в соответствии с требованием 12.10.1.

Дополнительная информация:
Отраслевые рекомендации по архивированию устаревших ключей изложены в NIST SP 800-57, Часть 1, редакция 5, раздел 8.3.1, и включают ведение архива доверенной третьей стороной и хранение архивной ключевой информации отдельно от оперативных данных.

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

Цель Индивидуального подхода:
Секретные или закрытые ключи открытого текста не могут быть известны никому. Операции, связанные с ключами открытого текста, не могут выполняться одним человеком.

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

ИЛИ

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

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

Надлежащая практика:
Там, где используются ключевые компоненты или общие ресурсы ключей, процедуры должны гарантировать, что ни один хранитель никогда не будет иметь доступа к достаточному количеству ключевых компонентов или общих ресурсов для восстановления криптографического ключа. Например, в схеме m-of-n (например, Shamir), где для восстановления криптографического ключа требуются только два из любых трех компонентов, хранитель не должен иметь текущих или предварительных знаний более чем об одном компоненте. Если хранителю ранее был назначен компонент A, который затем был переназначен, хранителю не следует назначать компонент B или C, поскольку это дало бы хранителю знания о двух компонентах и возможность воссоздать ключ.

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

Дополнительная информация:
Отраслевые стандарты для управления ключевыми компонентами включают:

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

Цель Индивидуального подхода:
Криптографические ключи не могут быть заменены неавторизованным персоналом.

Определенные Процедуры Тестирования Подхода:

Цель:
Если злоумышленник сможет заменить ключ объекта ключом, который известен злоумышленнику, злоумышленник сможет расшифровать все данные, зашифрованные с помощью этого ключа

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

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

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

Определенные Процедуры Тестирования Подхода:

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

Дополнительная информация:
Отраслевые рекомендации для ключевых хранителей, а также их роли и обязанности включают:

3.7.9
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если поставщик услуг делится криптографическими ключами со своими клиентами для передачи или хранения данных учетной записи, руководство по безопасной передаче, хранению и обновлению таких ключей документируется и распространяется среди клиентов поставщика услуг.

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

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.

Определенные Процедуры Тестирования Подхода:

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

Дополнительная информация:
Многочисленные отраслевые стандарты управления ключами приведены выше в Руководстве по требованиям 3.7.1-3.7.8.

4.1.1
Определенные Требования к Подходу:
Все политики безопасности и операционные процедуры, указанные в Требовании 4, должны быть:

Цель Индивидуального подхода:
Ожидания, средства контроля и надзор за выполнением мероприятий в рамках Требования 4 определяются и соблюдаются соответствующим персоналом. Все вспомогательные действия повторяемы, последовательно применяются и соответствуют намерениям руководства.

Определенные Процедуры Тестирования Подхода:

Цель:
Требование 4.1.1 касается эффективного управления и поддержания различных политик и процедур, указанных в Требовании 4. Хотя важно определить конкретные политики или процедуры, указанные в Требовании 4, не менее важно обеспечить их надлежащее документирование, поддержание и распространение.

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

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

4.1.2
Определенные Требования к Подходу:
Роли и обязанности для выполнения действий, указанных в Требовании 4, задокументированы, распределены и поняты.

Цель Индивидуального подхода:
Распределяются повседневные обязанности по выполнению всех действий, указанных в Требовании 4. Персонал несет ответственность за успешное и непрерывное выполнение этих требований.

Определенные Процедуры Тестирования Подхода:

Цель:
Если роли и обязанности официально не распределены, персонал может не знать о своих повседневных обязанностях, и важные действия могут не выполняться.

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

Примеры:
Метод документирования ролей и обязанностей - это матрица распределения обязанностей, которая включает в себя, кто несет ответственность, подотчетен, консультируется и информируется (также называемая матрицей RACI).

4.2.1
Определенные Требования к Подходу:
Надежная криптография и протоколы безопасности реализованы следующим образом для защиты PAN во время передачи по открытым общедоступным сетям:

Цель Индивидуального подхода:
Открытый текст PAN не может быть прочитан или перехвачен из любых передач по открытым общедоступным сетям.

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Схемы сети и потоков данных, определенные в требовании 1, являются полезными ресурсами для определения всех точек подключения, где данные учетной записи передаются или принимаются по открытым общедоступным сетям.
Хотя это и не требуется, считается хорошей практикой для организаций также шифровать PAN по своим внутренним сетям, а для организаций устанавливать любые новые сетевые реализации с зашифрованными сообщениями.
Передача PAN может быть защищена путем шифрования данных перед их передачей или путем шифрования сеанса, по которому передаются данные, или и того, и другого. Хотя не требуется, чтобы надежная криптография применялась как на уровне данных, так и на уровне сеанса, настоятельно рекомендуется. Если данные зашифрованы на уровне данных, криптографическими ключами, используемыми для защиты данных, можно управлять в соответствии с требованиями 3.6 и 3.7. Если данные зашифрованы на уровне сеанса, назначенным хранителям ключей следует назначить ответственность за управление ключами передачи и сертификатами.
Некоторые реализации протоколов (такие как SSL, SSH v1.0 и ранние версии TLS) имеют известные уязвимости, которые злоумышленник может использовать для получения доступа к открытым текстовым данным. Крайне важно, чтобы организации были осведомлены об установленных в отрасли датах устаревания используемых ими наборов шифров и были готовы перейти на более новые версии или протоколы, когда старые больше не считаются безопасными.
Проверка того, что сертификаты являются доверенными, помогает обеспечить целостность защищенного соединения. Чтобы считаться доверенным, сертификат должен быть выдан из надежного источника, такого как доверенный центр сертификации (CA), и срок его действия не истек. Для проверки сертификатов можно использовать обновленные Списки отзыва сертификатов (CRL) или Протокол онлайн-статуса сертификата (OCSP).
Методы проверки сертификатов могут включать закрепление сертификата и открытого ключа, при котором доверенный сертификат или открытый ключ закрепляются либо во время разработки, либо при его первом использовании. Организации также могут подтвердить это у разработчиков или просмотреть исходный код, чтобы убедиться, что клиенты и серверы отклоняют подключения, если сертификат неисправен.
Для сертификатов TLS на основе браузера доверие к сертификату часто можно проверить, нажав на значок блокировки, который появляется рядом с адресной строкой.

Примеры:
Открытые общедоступные сети включают, но не ограничиваются ими:

Дополнительная информация:
С рекомендациями поставщиков и лучшими отраслевыми практиками можно ознакомиться для получения информации о надлежащей надежности шифрования, специфичной для используемой методологии шифрования.
Для получения дополнительной информации о надежной криптографии и безопасных протоколах см. Отраслевые стандарты и рекомендации, такие как NIST SP 800-52 и SP 800-57.
Дополнительные сведения о доверенных ключах и сертификатах см. в Руководстве NIST по практике кибербезопасности Специальная публикация 1800-16 "Защита веб-транзакций: Управление сертификатами сервера безопасности транспортного уровня (TLS)".

4.2.1.1
Определенные Требования к Подходу:
Ведется учет доверенных ключей и сертификатов объекта, используемых для защиты PAN во время передачи.

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

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Для сертификатов в описи должен быть указан центр сертификации, выдавший сертификат, и дата истечения срока действия сертификата.

4.2.1.2
Определенные Требования к Подходу:
Беспроводные сети, передающие PAN или подключенные к CDE, используют лучшие отраслевые практики для реализации надежной криптографии для аутентификации и передачи.

Цель Индивидуального подхода:
Открытый текст PAN не может быть прочитан или перехвачен при передаче по беспроводной сети.

Определенные Процедуры Тестирования Подхода:

Цель:
Поскольку для подключения к беспроводным сетям не требуются физические носители, важно установить элементы управления, ограничивающие, кто может подключаться и какие протоколы передачи будут использоваться. Злоумышленники используют бесплатные и широко доступные инструменты для подслушивания беспроводных сообщений. Использование надежной криптографии может помочь ограничить раскрытие конфиденциальной информации в беспроводных сетях.
Беспроводные сети представляют уникальные риски для организации; поэтому они должны быть идентифицированы и защищены в соответствии с отраслевыми требованиями. Надежная криптография для аутентификации и передачи PAN требуется для предотвращения получения злоумышленниками доступа к беспроводной сети или использования беспроводных сетей для доступа к другим внутренним сетям или данным.

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

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

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

Цель Индивидуального подхода:
Открытый текст PAN не может быть прочитан или перехвачен из передач с использованием технологий обмена сообщениями конечных пользователей.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Технологии обмена сообщениями с конечными пользователями обычно могут быть легко перехвачены путем перехвата пакетов во время доставки по внутренним и общедоступным сетям.

Надлежащая практика:
Использование технологии обмена сообщениями с конечным пользователем для отправки PAN следует рассматривать только в тех случаях, когда существует определенная бизнес-потребность.

Примеры:
Электронная почта, мгновенные сообщения, SMS и чат являются примерами типа технологии обмена сообщениями с конечным пользователем, к которой относится это требование.

5.1.1
Определенные Требования к Подходу:
Все политики безопасности и операционные процедуры, указанные в Требовании 5:

Цель Индивидуального подхода:
Ожидания, средства контроля и надзор за выполнением мероприятий в рамках Требования 5 определяются и соблюдаются соответствующим персоналом. Все вспомогательные действия повторяемы, последовательно применяются и соответствуют намерениям руководства.

Определенные Процедуры Тестирования Подхода:

Цель:
Требование 5.1.1 касается эффективного управления и поддержания различных политик и процедур, указанных в Требовании 5. Хотя важно определить конкретные политики или процедуры, указанные в Требовании 5, не менее важно обеспечить их надлежащее документирование, поддержание и распространение.

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

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

5.1.2
Определенные Требования к Подходу:
Роли и обязанности для выполнения действий, указанных в Требовании 5, задокументированы, распределены и поняты.

Цель Индивидуального подхода:
Распределяются повседневные обязанности по выполнению всех действий, указанных в Требовании 5. Персонал несет ответственность за успешное и непрерывное выполнение этих требований.

Определенные Процедуры Тестирования Подхода:

Цель:
Если роли и обязанности официально не распределены, сети и системы могут не быть должным образом защищены от вредоносных программ.

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

Примеры:
Метод документирования ролей и обязанностей - это матрица распределения обязанностей, которая включает в себя, кто несет ответственность, подотчетен, консультируется и информируется (также называемая матрицей RACI).

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

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

Определенные Процедуры Тестирования Подхода:

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

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

Определения:
Системные компоненты, которые, как известно, подвержены вредоносному ПО, имеют активные вредоносные эксплойты, доступные в реальном мире (а не только теоретические эксплойты).

5.2.2
Определенные Требования к Подходу:
Развернутые решения для защиты от вредоносных программ:

Цель Индивидуального подхода:
Вредоносная программа не может запускать или заражать другие компоненты системы.

Определенные Процедуры Тестирования Подхода:

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

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

Примеры:
Типы вредоносных программ включают, но не ограничиваются ими, вирусы, трояны, черви, шпионские программы, программы-вымогатели, кейлоггеры, руткиты, вредоносный код, скрипты и ссылки.

5.2.3
Определенные Требования к Подходу:
Любые системные компоненты, которые не подвержены риску заражения вредоносными программами, периодически проверяются на наличие следующих:

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

Примечания по применению:
Системные компоненты, на которые распространяется это требование, - это те, для которых не развернуто решение для защиты от вредоносных программ в соответствии с требованием 5.2.1.

Определенные Процедуры Тестирования Подхода:

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

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

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

5.2.3.1
Определенные Требования к Подходу:
Частота периодических оценок компонентов системы, идентифицированных как не подверженные риску вредоносного ПО, определяется в целевом анализе рисков организации, который выполняется в соответствии со всеми элементами, указанными в Требовании 12.3.1.

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

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

5.3.1
Определенные Требования к Подходу:
Решения для защиты от вредоносных программ поддерживаются в актуальном состоянии с помощью автоматических обновлений.

Цель Индивидуального подхода:
Механизмы защиты от вредоносных программ могут обнаруживать и устранять новейшие вредоносные угрозы.

Определенные Процедуры Тестирования Подхода:

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

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

5.3.2
Определенные Требования к Подходу:
Решение (решения) для защиты от вредоносных программ:

ИЛИ

Цель Индивидуального подхода:
Вредоносная программа не может завершить выполнение проверки.

Определенные Процедуры Тестирования Подхода:

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

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

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

5.3.2.1
Определенные Требования к Подходу:
Если периодические проверки на наличие вредоносных программ выполняются в соответствии с Требованием 5.3.2, частота проверок определяется в целевом анализе рисков организации, который выполняется в соответствии со всеми элементами, указанными в Требовании 12.3.1.

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

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

Определенные Процедуры Тестирования Подхода:

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

5.3.3
Определенные Требования к Подходу:
Для съемных электронных носителей решение (решения) для защиты от вредоносных программ:

ИЛИ

Цель Индивидуального подхода:
Вредоносные программы не могут быть внедрены в системные компоненты с помощью внешних съемных носителей.

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

Цель:
Портативные мультимедийные устройства часто упускаются из виду как способ проникновения вредоносных программ. Злоумышленники часто предварительно загружают вредоносное ПО на портативные устройства, такие как USB и флэш-накопители; подключение зараженного устройства к компьютеру затем запускает вредоносное ПО, создавая новые угрозы в среде.

5.3.4
Определенные Требования к Подходу:
Журналы аудита для решения (решений) для защиты от вредоносных программ включены и сохраняются в соответствии с требованием 10.5.1.

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

Определенные Процедуры Тестирования Подхода:

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

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

Цель Индивидуального подхода:
Механизмы защиты от вредоносных программ не могут быть изменены неавторизованным персоналом.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Важно, чтобы защитные механизмы всегда были запущены, чтобы вредоносное ПО обнаруживалось в режиме реального времени. Случайный запуск и остановка антивирусных решений могут позволить вредоносным программам распространяться бесконтрольно и незамеченными.

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

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

5.4.1
Определенные Требования к Подходу:
Существуют процессы и автоматизированные механизмы для обнаружения и защиты персонала от фишинговых атак.

Цель Индивидуального подхода:
Существуют механизмы защиты от фишинговых атак и снижения рисков, связанных с ними.

Примечания по применению:
Это требование относится и к автоматизированному механизму. Не предполагается, что системы и службы, обеспечивающие такие автоматизированные механизмы (например, серверы электронной почты), подпадают под действие стандарта PCI DSS.
Основное внимание в этом требовании уделяется защите персонала, имеющего доступ к системным компонентам inscope для PCI DSS.
Выполнение этого требования для технических и автоматизированных средств контроля для обнаружения и защиты персонала от фишинга отличается от требования 12.6.3.1 для обучения по вопросам безопасности. Выполнение этого требования также не соответствует требованию о проведении обучения персонала по вопросам безопасности, и наоборот.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

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

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

Дополнительная информация:
Дополнительные сведения о фишинге см. Ниже:

6.1.1
Определенные Требования к Подходу:
Все политики безопасности и операционные процедуры, указанные в Требовании 6:

Цель Индивидуального подхода:
Ожидания, средства контроля и надзор за выполнением мероприятий в рамках Требования 6 определяются и соблюдаются соответствующим персоналом. Все вспомогательные действия повторяемы, последовательно применяются и соответствуют намерениям руководства.

Определенные Процедуры Тестирования Подхода:

Цель:
Целевое требование 6.1.1 касается эффективного управления и поддержания различных политик и процедур, указанных в Требовании 6. Хотя важно определить конкретные политики или процедуры, указанные в Требовании 6, не менее важно обеспечить их надлежащее документирование, поддержание и распространение.

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

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

6.1.2
Определенные Требования к Подходу:
Роли и обязанности для выполнения действий, указанных в Требовании 6, задокументированы, распределены и поняты.

Цель Индивидуального подхода:
Распределяются повседневные обязанности по выполнению всех действий, указанных в Требовании 6. Персонал несет ответственность за успешное и непрерывное выполнение этих требований.

Определенные Процедуры Тестирования Подхода:

Цель:
Если роли и обязанности официально не распределены, системы не будут надежно обслуживаться, и уровень их безопасности будет снижен.

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

Примеры:
Метод документирования ролей и обязанностей - это матрица распределения обязанностей, которая включает в себя, кто несет ответственность, подотчетен, консультируется и информируется (также называемая матрицей RACI).

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

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

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

Определенные Процедуры Тестирования Подхода:

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

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

Примеры:
Методологии и фреймворки безопасного управления жизненным циклом программного обеспечения включают PCI Software Security Framework, BSIMM, OPENSAMM и работы из NIST, ISO и SafeCode.

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

Цель Индивидуального подхода:
Персонал, занимающийся разработкой программного обеспечения, по-прежнему хорошо осведомлен о методах безопасной разработки, безопасности программного обеспечения и атаках на языки, фреймворки или приложения, которые они разрабатывают. Персонал может получить доступ к помощи и руководству, когда это необходимо.

Определенные Процедуры Тестирования Подхода:

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

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

6.2.3
Определенные Требования к Подходу:
Разработанное на заказ и заказное программное обеспечение проверяется перед выпуском в производство или для клиентов, чтобы выявить и исправить потенциальные уязвимости в коде следующим образом:

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

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

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Следующие пункты следует рассмотреть для включения в обзоры кода:

6.2.3.1
Определенные Требования к Подходу:
Если проверка кода вручную выполняется для программного обеспечения, изготовленного на заказ, перед выпуском в производство, изменения кода:

Цель Индивидуального подхода:
Процесс проверки кода вручную невозможно обойти, и он эффективен при обнаружении уязвимостей в системе безопасности.

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

Определенные Процедуры Тестирования Подхода:

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

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

Дополнительная информация:
См. Руководство по обзору кода OWASP.

6.2.4
Определенные Требования к Подходу:
Методы разработки программного обеспечения или другие методы определяются и используются персоналом по разработке программного обеспечения для предотвращения или смягчения распространенных программных атак и связанных с ними уязвимостей в программном обеспечении на заказ и на заказ, включая, но не ограничиваясь следующим:

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

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

Определенные Процедуры Тестирования Подхода:

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

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

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

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

6.3.1
Определенные Требования к Подходу:
Уязвимости в системе безопасности выявляются и устраняются следующим образом:

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

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

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Методы оценки уязвимостей и присвоения рейтингов рисков будут варьироваться в зависимости от среды организации и стратегии оценки рисков.
Когда организация присваивает свои рейтинги рисков, ей следует рассмотреть возможность использования формальной, объективной, обоснованной методологии, которая точно отражает риски уязвимостей, относящихся к организации, и переводит их в соответствующий приоритет, присвоенный организации для устранения.
Процессы организации по управлению уязвимостями должны быть интегрированы с другими процессами управления — например, управление рисками, управление изменениями, управление исправлениями, реагирование на инциденты, безопасность приложений, а также надлежащий мониторинг и протоколирование этих процессов. Это поможет обеспечить надлежащее выявление и устранение всех уязвимостей. Процессы должны поддерживать текущую оценку уязвимостей. Например, уязвимость, первоначально идентифицированная как низкая степень риска, может впоследствии стать более высокой степенью риска. Кроме того, уязвимости, которые по отдельности считаются низким или средним риском, могут в совокупности представлять высокий или критический риск, если они присутствуют в одной и той же системе или если они используются в системе с низким уровнем риска, что может привести к доступу к CDE.

Примеры:
Некоторые организации, которые выпускают предупреждения для информирования организаций о срочных уязвимостях, требующих немедленных исправлений/обновлений, - это национальные группы компьютерной готовности к чрезвычайным ситуациям/ реагирования (сертификаты) и поставщики.
Критерии ранжирования уязвимостей могут включать критичность уязвимости, выявленной в предупреждении от Форума Групп реагирования на инциденты и безопасности (FIRST) или сертификата, рассмотрение оценки CVSS, классификацию поставщиком и/или тип затронутых систем.

Дополнительная информация:
Надежные источники информации об уязвимостях включают веб-сайты поставщиков, отраслевые группы новостей, списки рассылки и т.д. Если программное обеспечение разрабатывается собственными силами, внутренняя команда разработчиков должна также рассмотреть источники информации о новых уязвимостях, которые могут повлиять на приложения, разработанные внутри компании. Другие методы обеспечения выявления новых уязвимостей включают решения, которые автоматически распознают и предупреждают об обнаружении необычного поведения. Процессы должны учитывать широко опубликованные эксплойты, а также атаки “нулевого дня”, нацеленные на ранее неизвестные уязвимости.
Для программного обеспечения, изготовленного на заказ и изготовленного на заказ, организация может получать информацию о библиотеках, фреймворках, компиляторах, языках программирования и т.д. из общедоступных надежных источников (например, специальных ресурсов и ресурсов от разработчиков компонентов). Организация также может самостоятельно анализировать сторонние компоненты и выявлять уязвимости.
Для контроля над программным обеспечением, разработанным собственными силами, организация может получать такую информацию из внешних источников. Организация может рассмотреть возможность использования программы “вознаграждение за ошибки”, в рамках которой она размещает информацию (например, на своем веб-сайте), чтобы третьи стороны могли связаться с организацией с информацией об уязвимостях. Внешние источники могут включать независимых исследователей или компании, которые сообщают организации о выявленных уязвимостях, и могут включать такие источники, как Общая система оценки уязвимостей (CVSS) или Методология оценки рисков OWASP

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

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

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

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

6.3.3
Определенные Требования к Подходу:
Все компоненты системы защищены от известных уязвимостей путем установки соответствующих исправлений/обновлений безопасности следующим образом:

Цель Индивидуального подхода:
Компоненты системы не могут быть скомпрометированы путем использования известной уязвимости.

Определенные Процедуры Тестирования Подхода:

Цель:
Постоянно обнаруживаются новые эксплойты, которые могут позволить проводить атаки на системы, ранее считавшиеся безопасными. Если самые последние исправления/обновления безопасности не будут внедрены в критические системы как можно скорее, злоумышленник может использовать эти эксплойты для атаки или отключения системы или получения доступа к конфиденциальным данным.

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

6.4.1
Определенные Требования к Подходу:
Для общедоступных веб-приложений новые угрозы и уязвимости устраняются на постоянной основе, и эти приложения защищены от известных атак следующим образом:

ИЛИ

Цель Индивидуального подхода:
Общедоступные веб-приложения защищены от вредоносных атак.

Примечания по применению:
Эта оценка отличается от проверки уязвимостей, выполненной для требований 11.3.1 и 11.3.2.
Это требование будет заменено Требованием 6.4.2 после 31 марта 2025 года, когда Требование 6.4.2 вступит в силу.

Определенные Процедуры Тестирования Подхода:

ИЛИ

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

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

Примеры:
Брандмауэр веб-приложений (WAF), установленный перед общедоступными веб-приложениями для проверки всего трафика, является примером автоматизированного технического решения, которое обнаруживает и предотвращает веб-атаки (например, атаки, включенные в требование 6.2.4). WAFS фильтруют и блокируют несущественный трафик на прикладном уровне. Правильно настроенный WAF помогает предотвратить атаки прикладного уровня на приложения, которые неправильно закодированы или настроены.
Другим примером автоматизированного технического решения являются технологии самозащиты приложений во время выполнения (RASP). При правильной реализации решения RASP могут обнаруживать и блокировать аномальное поведение программного обеспечения во время выполнения. В то время как WAFs обычно отслеживают периметр приложения, решения RASP отслеживают и блокируют поведение внутри приложения.

6.4.2
Определенные Требования к Подходу:
Для общедоступных веб-приложений развертывается автоматизированное техническое решение, которое постоянно обнаруживает и предотвращает веб-атаки, по крайней мере, со следующими:

Цель Индивидуального подхода:
Общедоступные веб-приложения защищены в режиме реального времени от вредоносных атак.

Примечания по применению:
Это новое требование заменит требование 6.4.1, как только наступит дата его вступления в силу.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

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

Примеры:
Брандмауэр веб-приложений (WAF), который может быть локальным или облачным, устанавливаемый перед общедоступными веб-приложениями для проверки всего трафика, является примером автоматизированного технического решения, которое обнаруживает и предотвращает веб-атаки (например, атаки, включенные в требование 6.2.4). WAFS фильтруют и блокируют несущественный трафик на прикладном уровне. Правильно настроенный WAF помогает предотвратить атаки прикладного уровня на приложения, которые неправильно закодированы или настроены.

6.4.3
Определенные Требования к Подходу:
Все скрипты страницы оплаты, которые загружаются и выполняются в браузере пользователя, управляются следующим образом:

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

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

Определенные Процедуры Тестирования Подхода:

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

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

Определения:
“Необходимо” для этого требования означает, что проверка субъектом каждого сценария обосновывает и подтверждает, почему это необходимо для функциональности платежной страницы для принятия платежной транзакции

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

6.5.1
Определенные Требования к Подходу:
Изменения во всех компонентах системы в производственной среде вносятся в соответствии с установленными процедурами, которые включают:

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

Определенные Процедуры Тестирования Подхода:

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

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

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

Цель Индивидуального подхода:
Все компоненты системы проверяются после внесения существенных изменений на соответствие применимым требованиям PCI DSS.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Наличие процессов для анализа существенных изменений помогает гарантировать, что все соответствующие элементы управления PCI DSS применяются к любым системам или сетям, добавленным или измененным в рамках среды in-scope, и что требования PCI DSS продолжают выполняться для обеспечения безопасности среды.

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

Примеры:
Применимые требования PCI DSS, которые могут быть затронуты, включают, но не ограничиваются ими::

6.5.3
Определенные Требования к Подходу:
Предпроизводственные среды отделены от производственных сред, и это разделение обеспечивается с помощью средств контроля доступа.

Цель Индивидуального подхода:
Предпроизводственная среда не может привносить риски и уязвимости в производственную среду.

Определенные Процедуры Тестирования Подхода:

Цель:
Среды разработки и тестирования из-за постоянно меняющегося состояния часто менее безопасны, чем производственная среда.

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

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

6.5.4
Определенные Требования к Подходу:
Роли и функции разделены между производственной и предпроизводственной средами для обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и утвержденные изменения.

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

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

Определенные Процедуры Тестирования Подхода:

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

6.5.5
Определенные Требования к Подходу:
Текущие PANs не используются в предпроизводственных средах, за исключением случаев, когда эти среды включены в CDE и защищены в соответствии со всеми применимыми требованиями PCI DSS.

Цель Индивидуального подхода:
Текущие PANs не могут присутствовать в среде предварительного производства за пределами CDE.

Определенные Процедуры Тестирования Подхода:

Цель:
Использование текущих PANs за пределами защищенных CDE предоставляет злоумышленникам возможность получить несанкционированный доступ к данным о держателях карт.

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

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

6.5.6
Определенные Требования к Подходу:
Тестовые данные и тестовые учетные записи удаляются из компонентов системы перед запуском системы в эксплуатацию.

Цель Индивидуального подхода:
Тестовые данные и тестовые учетные записи не могут существовать в производственных средах.

Определенные Процедуры Тестирования Подхода:

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

7.1.1
Определенные Требования к Подходу:
Все политики безопасности и операционные процедуры, указанные в Требовании 7:

Цель Индивидуального подхода:
Ожидания, средства контроля и надзор за выполнением мероприятий в рамках Требования 7 определяются и соблюдаются соответствующим персоналом. Все вспомогательные действия повторяемы, последовательно применяются и соответствуют намерениям руководства.

Определенные Процедуры Тестирования Подхода:

Цель:
Требование 7.1.1 касается эффективного управления и поддержания различных политик и процедур, указанных в Требовании 7. Хотя важно определить конкретные политики или процедуры, указанные в Требовании 7, не менее важно обеспечить их надлежащее документирование, ведение и распространение.

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

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

7.1.2
Определенные Требования к Подходу:
Роли и обязанности для выполнения действий, указанных в Требовании 7, задокументированы, распределены и поняты.

Цель Индивидуального подхода:
Распределяются повседневные обязанности по выполнению всех действий, указанных в Требовании 7. Персонал несет ответственность за успешное и непрерывное выполнение этих требований.

Определенные Процедуры Тестирования Подхода:

Цель:
Если роли и обязанности официально не распределены, персонал может не знать о своих повседневных обязанностях, и важные действия могут не выполняться.

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

Примеры:
Метод документирования ролей и обязанностей - это матрица распределения обязанностей, которая включает в себя, кто несет ответственность, подотчетен, консультируется и информируется (также называемая матрицей RACI).

7.2.1
Определенные Требования к Подходу:
Определена модель управления доступом, которая включает в себя предоставление доступа следующим образом:

Цель Индивидуального подхода:
Требования к доступу устанавливаются в соответствии с должностными функциями в соответствии с принципами наименьших привилегий и необходимости знать

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Фактором, который следует учитывать при определении потребностей в доступе, является принцип разделения обязанностей. Этот принцип предназначен для предотвращения мошенничества и неправильного использования или кражи ресурсов. Например, 1) разделение критически важных функций и функций поддержки информационной системы между различными лицами и/или функциями, 2) установление ролей таким образом, чтобы деятельность по поддержке информационной системы выполнялась различными функциями/лицами (например, управление системой, программирование, управление конфигурацией, обеспечение качества и тестирование, а также сетевая безопасность), и 3) обеспечение того, чтобы сотрудники службы безопасности, выполняющие функции контроля доступа, не выполняли также функции аудита.
В средах, где один человек выполняет несколько функций, таких как администрирование и операции безопасности, обязанности могут быть распределены таким образом, чтобы ни один отдельный человек не имел сквозного контроля над процессом без независимой контрольной точки. Например, ответственность за настройку и ответственность за утверждение изменений могут быть возложены на отдельных лиц.

Определения:
Ключевые элементы модели контроля доступа включают в себя:

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

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

7.2.2
Определенные Требования к Подходу:
Доступ назначается пользователям, включая привилегированных пользователей, на основе:

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

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Права доступа предоставляются пользователю путем назначения одной или нескольким функциям. Оценка назначается в зависимости от конкретных функций пользователя и с минимальным объемом, необходимым для выполнения задания.
При назначении привилегированного доступа важно назначать отдельным лицам только те привилегии, которые им необходимы для выполнения их работы (“наименьшие привилегии”). Например, администратору базы данных или администратору резервного копирования не следует назначать те же привилегии, что и общему системному администратору.
Как только потребности определены для пользовательских функций (в соответствии с требованием PCI DSS 7.2.1), легко предоставить отдельным лицам доступ в соответствии с их классификацией должностей и функциями, используя уже созданные роли.
Организации могут пожелать рассмотреть возможность использования Управления привилегированным доступом (PAM), которое представляет собой метод предоставления доступа к привилегированным учетным записям только тогда, когда эти привилегии требуются, и немедленного отзыва этого доступа, как только они больше не нужны.

7.2.3
Определенные Требования к Подходу:
Необходимые привилегии утверждаются уполномоченным персоналом

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

Определенные Процедуры Тестирования Подхода:

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

7.2.4
Определенные Требования к Подходу:
Все учетные записи пользователей и связанные с ними права доступа, включая учетные записи третьих лиц/поставщиков, проверяются следующим образом:

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

Примечания по применению:
Это требование применяется ко всем учетным записям пользователей и связанным с ними привилегиям доступа, включая учетные записи, используемые персоналом и третьими лицами/поставщиками, а также учетные записи, используемые для доступа к сторонним облачным сервисам.
См. Требования 7.2.5 и 7.2.5.1 и 8.6.1-8.6.3 для элементов управления учетными записями приложений и систем.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

Надлежащая практика:
Когда пользователь переходит на новую роль или в новый отдел, обычно привилегии и доступ, связанные с его прежней ролью, больше не требуются. Постоянный доступ к привилегиям или функциям, которые больше не требуются, может привести к риску неправильного использования или ошибок. Поэтому, когда обязанности меняются, процессы, которые повторно проверяют доступ, помогают гарантировать, что доступ пользователя соответствует новым обязанностям пользователя.
Организации могут рассмотреть возможность внедрения регулярного, повторяющегося процесса для проведения проверок прав доступа и назначения “владельцев данных”, которые отвечают за управление и мониторинг доступа к данным, связанным с их должностной функцией, и которые также обеспечивают, чтобы доступ пользователей оставался актуальным и надлежащим. В качестве примера, непосредственный руководитель может ежемесячно проверять доступ к группе, в то время как старший менеджер проверяет доступ своих групп ежеквартально, внося обновления в доступ по мере необходимости. Цель этих рекомендаций состоит в том, чтобы поддерживать и облегчать проведение обзоров не реже одного раза в 6 месяцев.

7.2.5
Определенные Требования к Подходу:
Все учетные записи приложений и системы и связанные с ними права доступа назначаются и управляются следующим образом:

Цель Индивидуального подхода:
Права доступа, предоставляемые учетным записям приложений и систем, ограничены только доступом, необходимым для работоспособности этого приложения или системы.

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

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

7.2.5.1
Определенные Требования к Подходу:
Все права доступа по учетным записям приложений и систем и связанные с ними права доступа проверяются следующим образом:

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

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

7.2.6
Определенные Требования к Подходу:
Доступ всех пользователей к хранилищам запросов сохраненных данных о держателях карт ограничен следующим образом:

Цель Индивидуального подхода:
Прямой нефильтрованный (специальный) доступ по запросу к хранилищам данных о держателях карт запрещен, если только он не выполняется уполномоченным администратором.

Примечания по применению:
Это требование применяется к элементам управления доступом пользователей к хранилищам запросов сохраненных данных о держателях карт.
См. Требования 7.2.5 и 7.2.5.1 и 8.6.1-8.6.3 для элементов управления учетными записями приложений и систем.

Определенные Процедуры Тестирования Подхода:

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

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

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

7.3.1
Определенные Требования к Подходу:
Существует система (системы) контроля доступа, которая ограничивает доступ на основе необходимости пользователя знать и охватывает все компоненты системы.

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

Определенные Процедуры Тестирования Подхода:

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

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

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

Определенные Процедуры Тестирования Подхода:

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

7.3.3
Определенные Требования к Подходу:
Система (системы) контроля доступа по умолчанию настроена на “запретить все”.

Цель Индивидуального подхода:
Права доступа и привилегии запрещены, если это прямо не разрешено.

Определенные Процедуры Тестирования Подхода:

Цель:
Значение по умолчанию “запретить всем” гарантирует, что никому не будет предоставлен доступ, если не установлено правило, специально предоставляющее такой доступ.

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

8.1.1
Определенные Требования к Подходу:
Все политики безопасности и операционные процедуры, указанные в Требовании 8, должны быть:

Цель Индивидуального подхода:
Ожидания, средства контроля и надзор за выполнением мероприятий в рамках Требования 8 определяются и соблюдаются соответствующим персоналом. Все вспомогательные действия повторяемы, последовательно применяются и соответствуют намерениям руководства.

Определенные Процедуры Тестирования Подхода:

Цель:
Требование 8.1.1 касается эффективного управления и поддержания различных политик и процедур, указанных в Требовании 8. Хотя важно определить конкретные политики или процедуры, указанные в Требовании 8, не менее важно обеспечить их надлежащее документирование, поддержание и распространение.

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

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

8.1.2
Определенные Требования к Подходу:
Роли и обязанности для выполнения действий, указанных в Требовании 8, задокументированы, распределены и поняты.

Цель Индивидуального подхода:
Распределяются повседневные обязанности по выполнению всех действий, указанных в Требовании 8. Персонал несет ответственность за успешное и непрерывное выполнение этих требований.

Определенные Процедуры Тестирования Подхода:

Цель:
Если роли и обязанности официально не распределены, персонал может не знать о своих повседневных обязанностях, и важные действия могут не выполняться.

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

Примеры:
Метод документирования ролей и обязанностей - это матрица распределения обязанностей, которая включает в себя, кто несет ответственность, подотчетен, консультируется и информируется (также называемая матрицей RACI).

8.2.1
Определенные Требования к Подходу:
Всем пользователям присваивается уникальный идентификатор, прежде чем будет разрешен доступ к компонентам системы или данным о держателях карт.

Цель Индивидуального подхода:
Все действия всех пользователей приписываются отдельному лицу.

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

Определенные Процедуры Тестирования Подхода:

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

8.2.2
Определенные Требования к Подходу:
Групповые, общие или общие учетные записи или другие общие учетные данные для проверки подлинности используются только при необходимости в исключительных случаях и управляются следующим образом:

Цель Индивидуального подхода:
Все действия, выполняемые пользователями с общими, системными или общими идентификаторами, относятся к отдельному лицу.

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

Определенные Процедуры Тестирования Подхода:

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

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

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

8.2.3
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Поставщики услуг с удаленным доступом к помещениям клиентов используют уникальные факторы аутентификации для каждого помещения клиента.

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

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

Определенные Процедуры Тестирования Подхода:

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

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

8.2.4
Определенные Требования к Подходу:
Добавление, удаление и изменение идентификаторов пользователей, факторов аутентификации и других объектов идентификаторов управляются следующим образом:

Цель Индивидуального подхода:
События жизненного цикла для идентификаторов пользователей и факторов аутентификации не могут происходить без соответствующей авторизации.

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

Определенные Процедуры Тестирования Подхода:

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

8.2.5
Определенные Требования к Подходу:
Доступ для прекращенных пользователей немедленно аннулируется.

Цель Индивидуального подхода:
Учетные записи прекращенных пользователей не могут быть использованы.

Определенные Процедуры Тестирования Подхода:

Цель:
Если сотрудник или третья сторона/ поставщик покинули компанию и по—прежнему имеют доступ к сети через свою учетную запись пользователя, может возникнуть ненужный или злонамеренный доступ к данным о держателях карт - либо со стороны бывшего сотрудника, либо со стороны злоумышленника, который использует старую и/или неиспользуемую учетную запись.

8.2.6
Определенные Требования к Подходу:
Неактивные учетные записи пользователей удаляются или отключаются в течение 90 дней бездействия.

Цель Индивидуального подхода:
Неактивные учетные записи пользователей не могут быть использованы

Определенные Процедуры Тестирования Подхода:

Цель:
Учетные записи, которые не используются регулярно, часто становятся объектами атак, поскольку менее вероятно, что какие-либо изменения, такие как изменение пароля, будут замечены. Таким образом, эти учетные записи могут быть более легко использованы для доступа к данным о держателях карт.

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

8.2.7
Определенные Требования к Подходу:
Учетные записи, используемые третьими лицами для доступа, поддержки или обслуживания компонентов системы через удаленный доступ, управляются следующим образом:

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

Определенные Процедуры Тестирования Подхода:

Цель:
Предоставление третьим лицам доступа к системам и сетям организации в режиме 24/7 в случае необходимости оказания поддержки увеличивает вероятность несанкционированного доступа. Этот доступ может привести к тому, что неавторизованный пользователь в среде третьей стороны или злоумышленник воспользуется всегда доступной внешней точкой входа в сеть организации. Там, где третьим лицам действительно нужен доступ 24/7, он должен быть задокументирован, обоснован, отслежен и привязан к конкретным причинам обслуживания.

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

8.2.8
Определенные Требования к Подходу:
Если сеанс пользователя простаивает более 15 минут, пользователю необходимо повторно пройти аутентификацию, чтобы повторно активировать терминал или сеанс.

Цель Индивидуального подхода:
Сеанс пользователя может быть использован только авторизованным пользователем.

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

Определенные Процедуры Тестирования Подхода:

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

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

Примеры:
Один из способов выполнить это требование - настроить автоматическую заставку, которая будет запускаться всякий раз, когда консоль простаивает в течение 15 минут, и требовать от вошедшего в систему пользователя ввода пароля для разблокировки экрана.

8.3.1
Определенные Требования к Подходу:
Весь пользовательский доступ к системным компонентам для пользователей и администраторов проверяется с помощью по крайней мере одного из следующих факторов аутентификации:

Цель Индивидуального подхода:
Доступ к учетной записи возможен только с использованием комбинации идентификатора пользователя и фактора аутентификации.

Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Это требование не заменяет требования к многофакторной аутентификации (MFA), но применяется к тем системам, которые в других случаях не подпадают под требования MFA.
Цифровой сертификат является допустимым вариантом для “того, что у вас есть”, если он уникален для конкретного пользователя.

Определенные Процедуры Тестирования Подхода:

Цель:
При использовании в дополнение к уникальным идентификаторам фактор аутентификации помогает защитить идентификаторы пользователей от взлома, поскольку злоумышленнику необходимо иметь уникальный идентификатор и скомпрометировать связанные с ним факторы аутентификации.

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

Дополнительная информация:
См. fidoalliance.org дополнительные сведения об использовании токенов, смарт-карт или биометрических данных в качестве факторов аутентификации см.

8.3.2
Определенные Требования к Подходу:
Надежная криптография используется для того, чтобы сделать все факторы аутентификации нечитаемыми во время передачи и хранения во всех компонентах системы.

Цель Индивидуального подхода:
Факторы аутентификации открытого текста не могут быть получены, выведены или повторно использованы в результате перехвата сообщений или из сохраненных данных.

Определенные Процедуры Тестирования Подхода:

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

8.3.3
Определенные Требования к Подходу:
Идентификация пользователя проверяется перед изменением любого фактора аутентификации.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Злоумышленники используют методы ”социальной инженерии", чтобы выдать себя за пользователя системы — например, позвонив в службу поддержки и действуя как законный пользователь, — чтобы изменить фактор аутентификации, чтобы они могли использовать действительный идентификатор пользователя.
Требование положительной идентификации пользователя снижает вероятность успеха такого типа атаки.

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

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

8.3.4
Определенные Требования к Подходу:
Недопустимые попытки аутентификации ограничены:

Цель Индивидуального подхода:
Фактор аутентификации не может быть угадан при переборе, онлайн-атаке.

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

Определенные Процедуры Тестирования Подхода:

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

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

8.3.5
Определенные Требования к Подходу:
Если пароли/парольные фразы используются в качестве факторов аутентификации в соответствии с требованием 8.3.1, они устанавливаются и сбрасываются для каждого пользователя следующим образом:

Цель Индивидуального подхода:
Первоначальный или сброшенный пароль/кодовая фраза, назначенные пользователю, не могут быть использованы неавторизованным пользователем.

Определенные Процедуры Тестирования Подхода:

Цель:
Если один и тот же пароль / кодовая фраза используется для каждого нового пользователя, внутренний пользователь, бывший сотрудник или злоумышленник могут знать или легко обнаружить значение и использовать его для получения доступа к учетным записям до того, как авторизованный пользователь попытается использовать пароль.

8.3.6
Определенные Требования к Подходу:
Если пароли/парольные фразы используются в качестве факторов аутентификации для удовлетворения требования 8.3.1, они соответствуют следующему минимальному уровню сложности:

Цель Индивидуального подхода:
Угаданный пароль/кодовая фраза не могут быть проверены ни с помощью онлайн-, ни с помощью оффлайн-атаки методом перебора.

Примечания по применению:
Это требование не предназначено для применения к:

Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
До 31 марта 2025 года пароли должны быть длиной не менее семи символов в соответствии с требованием 8.2.3 PCI DSS v3.2.1.

Определенные Процедуры Тестирования Подхода:

Цель:
Надежные пароли / парольные фразы могут быть первой линией защиты в сети, поскольку злоумышленник часто сначала пытается найти учетные записи со слабыми, статическими или несуществующими паролями. Если пароли короткие или легко угадываемые, злоумышленнику относительно легко найти эти слабые учетные записи и скомпрометировать сеть под видом действительного идентификатора пользователя.

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

8.3.7
Определенные Требования к Подходу:
Физическим лицам не разрешается вводить новый пароль/парольную фразу, которая совпадает с любым из последних четырех использованных паролей/парольных фраз.

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

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

Определенные Процедуры Тестирования Подхода:

Цель:
Если история паролей не ведется, эффективность смены паролей снижается, так как предыдущие пароли могут использоваться повторно снова и снова. Требование о том, чтобы пароли нельзя было использовать повторно в течение определенного периода, снижает вероятность того, что пароли, которые были угаданы или взломаны с помощью грубой силы, будут использоваться повторно в будущем.
Пароли или парольные фразы могли быть ранее изменены из-за подозрений в компрометации или из-за того, что срок действия пароля или парольной фразы превысил срок его эффективного использования, и то и другое является причиной, по которой ранее использованные пароли не следует использовать повторно.

8.3.8
Определенные Требования к Подходу:
Политики и процедуры аутентификации документируются и доводятся до сведения всех пользователей, включая:

Цель Индивидуального подхода:
Пользователи осведомлены о правильном использовании факторов аутентификации и при необходимости могут получить доступ к помощи и рекомендациям.

Определенные Процедуры Тестирования Подхода:

Цель:
Доведение политик и процедур аутентификации до сведения всех пользователей помогает им понять эти политики и соблюдать их.

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

8.3.9
Определенные Требования к Подходу:
Если пароли / парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя (т.е. в любой реализации однофакторной аутентификации), то либо:

ИЛИ

Цель Индивидуального подхода:
Необнаруженный скомпрометированный пароль/парольную фразу нельзя использовать бесконечно.

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

Определенные Процедуры Тестирования Подхода:

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

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

Дополнительная информация:
Об использовании динамического анализа для управления доступом пользователей к ресурсам см. в NIST SP 800-207 Архитектура нулевого доверия.

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

Цель Индивидуального подхода:
Пароли/парольные фразы для клиентов поставщиков услуг не могут использоваться бесконечно.

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

Определенные Процедуры Тестирования Подхода:

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

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

8.3.10.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если пароли / парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента (т.е. в любой реализации однофакторной аутентификации), то либо:

ИЛИ

Цель Индивидуального подхода:
Пароли/парольные фразы для клиентов поставщиков услуг не могут использоваться бесконечно.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не распространяется на учетные записи пользователей-потребителей, получающих доступ к информации о своих собственных платежных картах.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
До тех пор, пока это требование не вступит в силу 31 марта 2025 года, поставщики услуг могут выполнять либо требование 8.3.10, либо 8.3.10.1.

Определенные Процедуры Тестирования Подхода:

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

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

Дополнительная информация:
Для получения информации об использовании динамического анализа для управления доступом пользователей к ресурсам обратитесь к NIST SP 800-207 Архитектура нулевого доверия.

8.3.11
Определенные Требования к Подходу:
Где используются такие факторы аутентификации, как физические или логические маркеры безопасности, смарт-карты или сертификаты:

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

Определенные Процедуры Тестирования Подхода:

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

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

8.4.1
Определенные Требования к Подходу:
MFA реализован для всего неконсольного доступа к CDE для персонала с административным доступом.

Цель Индивидуального подхода:
Административный доступ к CDE не может быть получен с помощью одного фактора аутентификации.

Примечания по применению:
Требование MFA для неконсольного административного доступа применяется ко всему персоналу с повышенными или повышенными привилегиями, получающему доступ к CDE через неконсольное соединение, то есть через логический доступ, осуществляемый через сетевой интерфейс, а не через прямое физическое соединение.
MFA считается наилучшей практикой для неконсольного административного доступа к системным компонентам, которые не являются частью CDE.

Определенные Процедуры Тестирования Подхода:

Цель:
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.

Определения:
Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.

8.4.2
Определенные Требования к Подходу:
MFA реализован для всех видов доступа к CDE.

Цель Индивидуального подхода:
Доступ к CDE не может быть получен с помощью одного фактора аутентификации.

Примечания по применению:
Это требование не распространяется на:

MFA требуется для обоих типов доступа, указанных в Требованиях 8.4.2 и 8.4.3. Следовательно, применение MFA к одному типу доступа не заменяет необходимость применения другого экземпляра MFA к другому типу доступа. Если физическое лицо сначала подключается к сети организации через удаленный доступ, а затем позже инициирует подключение к CDE из сети, в соответствии с этим требованием физическое лицо будет проходить проверку подлинности с использованием MFA дважды, один раз при подключении через удаленный доступ к сети организации и один раз при подключении через неконсольный административный доступ из сети организации в CDE.
Требования MFA применяются ко всем типам системных компонентов, включая облачные, размещенные системы и локальные приложения, устройства сетевой безопасности, рабочие станции, серверы и конечные точки, и включают прямой доступ к сетям или системам организации, а также веб-доступ к приложению или функции.
MFA для удаленного доступа к CDE может быть реализован на сетевом или системном/прикладном уровне; его необязательно применять на обоих уровнях. Например, если MFA используется, когда пользователь подключается к сети CDE, его необязательно использовать, когда пользователь входит в каждую систему или приложение в CDE.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

Цель:
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.

Определения:
Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.

8.4.3
Определенные Требования к Подходу:
MFA реализуется для всего удаленного доступа к сети, исходящего из-за пределов сети организации, который может получить доступ к CDE или повлиять на него следующим образом:

Цель Индивидуального подхода:
Удаленный доступ к сети объекта не может быть получен с помощью одного фактора аутентификации.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.

Определения:
Многофакторная аутентификация (MFA) требует, чтобы пользователь представил минимум два из трех факторов аутентификации, указанных в требовании 8.3.1, прежде чем будет предоставлен доступ. Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.