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 включают изменения, связанные с самим компонентом, а также те, которые влияют на то, как он выполняет свои функции безопасности.

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

Цель:
Следование структурированному процессу управления изменениями для всех изменений в контролях сетевой безопасности (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 после завершения процесса авторизации запрещено.

Надлежащая практика:
Для организации может быть приемлемо хранить 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 до авторизации разрешено, определяется организациями, управляющими программами соблюдения стандартов (например, платёжными брендами и эквайерами). Для получения дополнительных критериев обратитесь в эти организации.
Это требование применяется ко всем хранилищам SAD, даже если PAN отсутствует в среде.
Смотрите Требование 3.2.1 для дополнительного требования, которое применяется, если SAD хранятся до завершения авторизации.
Эмитенты и компании, поддерживающие эмиссионные услуги, где существует законная и документированная бизнес-необходимость для хранения SAD, не обязаны выполнять это требование. Законная бизнес-необходимость — это необходимость для выполнения функции, предоставляемой эмитентом или для эмитента.
Смотрите Требование 3.3.3 для требований, специально предназначенных для этих организаций.
Это требование не заменяет требования по управлению блоками PIN, и оно не означает, что правильно зашифрованный блок PIN нужно зашифровывать снова.
Это требование является хорошей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью учтено в процессе оценки по стандарту PCI DSS.

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

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

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

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

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

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

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

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

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 оставался нечитаемым. Реализация криптографических хешей с ключами и соответствующими процессами управления ключами в соответствии с требованием 3.5.1.1 является дополнительным действительным контролем для предотвращения сопоставления.

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

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

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

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

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

Определения:
Смотрите Приложение G для определения "криптографического хеша с ключом" и информации о соответствующих алгоритмах криптографического хеширования с ключами и дополнительных ресурсах.

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

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

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

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

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

Дополнительная информация:
Если доступно, следование руководствам поставщиков по укреплению безопасности и лучшим отраслевым практикам поможет защитить 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 в открытых, публичных сетях не может быть прочитан или перехвачен в процессе передачи.

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

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

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

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

Дополнительная информация:
Рекомендации поставщиков и лучшие отраслевые практики могут быть использованы для получения информации о соответствующей силе шифрования, специфичной для используемой методологии шифрования.
Для получения дополнительной информации о сильной криптографии и безопасных протоколах см. отраслевые стандарты и лучшие практики, такие как NIST SP 800-52 и SP 800-57.
Для получения информации о доверенных ключах и сертификатах см. практическое руководство NIST Cybersecurity Practice Guide Special Publication 1800-16, "Securing Web Transactions: Transport Layer Security (TLS) Server Certificate Management".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры:
Электронная почта, мгновенные сообщения, 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.
Выполнение этого требования для технических и автоматизированных средств защиты от фишинга не означает выполнение Требования 12.6.3.1 по обучению безопасности. Выполнение этого требования не означает также выполнение требования по предоставлению персоналу обучения безопасности, и наоборот.
Это требование является лучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью учтено в ходе оценки PCI DSS.

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

Надлежащая практика:
При разработке антифишинговых мер организациям рекомендуется использовать комплексный подход. Например, использование технологий для предотвращения подделки, таких как Domain-based Message Authentication, Reporting & Conformance (DMARC), Sender Policy Framework (SPF) и Domain Keys Identified Mail (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. Это требование касается процесса активного мониторинга источников уязвимостей в отрасли и определения организацией ранга риска, который будет связан с каждой уязвимостью.

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

Надлежащая практика:
Методы оценки уязвимостей и присвоения уровней риска могут различаться в зависимости от среды организации и стратегии оценки рисков.
При присвоении рангов риска организациям рекомендуется использовать формальную, объективную и обоснованную методологию, которая точно отражает риски уязвимостей, относящихся к организации, и приводит к правильному приоритету для их устранения.
Ранжирование риска должно, как минимум, выявлять все уязвимости, которые считаются "высоким риском" для среды. В дополнение к рангу риска уязвимости могут быть признаны "критическими", если они представляют немедленную угрозу для среды, воздействуют на критические системы и/или могут привести к потенциальному компромиссу, если их не устранить. Примеры критических систем могут включать системы безопасности, устройства и системы с публичным доступом, базы данных и другие системы, которые хранят, обрабатывают или передают данные держателей карт.
Процессы управления уязвимостями в организации должны быть интегрированы с другими процессами управления — например, управлением рисками, управлением изменениями, управлением патчами, реагированием на инциденты, безопасностью приложений, а также с правильным мониторингом и журналированием этих процессов. Этот процесс должен включать несколько источников информации об уязвимостях, включая признанные в отрасли базы данных уязвимостей (например, Национальную базу данных уязвимостей США), CERT, RSS-каналы, информацию от поставщиков и третьих сторон, а также уязвимости, выявленные через внутренние и внешние сканирования уязвимостей (Требования 11.3.1 и 11.3.2). Это поможет обеспечить правильное выявление и устранение всех уязвимостей. Процессы должны поддерживать постоянную оценку уязвимостей. Например, уязвимость, изначально идентифицированная как низкий риск, может стать более высокоопасной позже. Кроме того, уязвимости, индивидуально считающиеся низким или средним риском, могут в совокупности представлять высокий или критический риск, если они присутствуют на одной и той же системе или если они эксплуатируются на низкорисковой системе, которая может привести к доступу к CDE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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
Определенные Требования к Подходу:
Все скрипты на странице платежа, которые загружаются и выполняются в браузере потребителя, управляются следующим образом:

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

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

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

Надлежащая практика:
Скрипты могут быть авторизованы вручную или с помощью автоматизированных процессов (например, рабочего процесса). Когда страница платежа загружается в встроенный фрейм (iframe), ограничение местоположения, с которого страница платежа может быть загружена, с использованием политики безопасности содержимого (CSP) родительской страницы может помочь предотвратить подмену страницы платежа несанкционированным контентом.
Когда организация включает встроенную страницу платежа/форму TPSP/платежного процессора на своем вебсайте, организация должна ожидать, что TPSP/платежный процессор предоставит доказательства того, что они выполняют это требование в соответствии с оценкой PCI DSS TPSP/платежного процессора и Требованием 12.9.

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

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
Определенные Требования к Подходу:
Живые PAN (номера карт) не используются в пред-продакшн средах, за исключением случаев, когда эти среды включены в CDE (среда, под защитой PCI DSS) и защищены в соответствии со всеми применимыми требованиями PCI DSS.

Цель Индивидуального Подхода:
Живые PAN не могут присутствовать в пред-продакшн средах, которые находятся вне CDE.

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

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

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
Определенные требования к подходу:
Если пароли/фразы-пароли используются как единственный фактор аутентификации для доступа пользователя (т.е. в любой реализации однофакторной аутентификации), то необходимо выполнить одно из следующих условий:

ИЛИ

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

Примечания по применимости:
Это требование не применяется к компонентам системы, входящим в область действия, где используется многофакторная аутентификация (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 на обоих уровнях. Например, если MFA используется при подключении пользователя к сети CDE, не обязательно применять MFA при входе пользователя в каждую систему или приложение внутри CDE.
Это требование является лучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью учтено при оценке PCI DSS.

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

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

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

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

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

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

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

8.5.1
Определенные требования к подходу:
Системы многофакторной аутентификации (MFA) реализуются следующим образом:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все эти элементы влияют на уровень риска для учетных записей приложений и систем и могут повлиять на безопасность систем, к которым обращаются учетные записи системы и приложений.
Субъекты должны соотносить выбранную ими частоту изменения паролей/паролей приложений и системы с выбранной ими сложностью для этих паролей /парольных фраз – т.е. сложность должна быть более строгой, когда пароли / парольные фразы меняются нечасто, и может быть менее строгой, когда меняются чаще. Например, более длительная частота смены более оправдана, когда сложность паролей/парольных фраз установлена на 36 буквенно-цифровых символов с прописными и строчными буквами, цифрами и специальными символами.
Рекомендуется учитывать необходимость смены пароля не реже одного раза в год, длину пароля/парольной фразы не менее 15 символов и сложность паролей/парольной фразы, состоящей из буквенно-цифровых символов, прописных и строчных букв и специальных символов.

В дальнейшем:
Информация Для получения информации об изменчивости и эквивалентности надежности паролей для паролей/парольных фраз различных форматов см. отраслевые стандарты (например, текущую версию NIST SP 800- 63 Digital Identity Guidelines).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цель:
Ограничение доступа к сетевым разъемам (или сетевым портам) не позволит злоумышленникам подключаться к легкодоступным сетевым разъемам и получать доступ к CDE или системам, подключенным к CDE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.4.5
Определенные Требования к Подходу:
Ведутся журналы инвентаризации всех электронных носителей с данными о держателях карт.

Цель Индивидуального подхода:
Ведется точный учет хранящихся электронных носителей.

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

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

9.4.5.1
Определенные Требования к Подходу:
Инвентаризация электронных носителей с данными о держателях карт проводится не реже одного раза в 12 месяцев.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошая практика:
Организации могут рассмотреть возможность внедрения защиты от вмешательства и несанкционированной замены для:

Дополнительная информация:
Дополнительные лучшие практики по предотвращению сканирования (skimming) доступны на веб-сайте PCI SSC.

9.5.1.1
Определенные Требования к Подходу:
Поддерживается актуальный список устройств POI, включая:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.2.1.6
Определенные Требования к Подходу:
Журналы аудита фиксируют следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надлежащая практика:
Ежедневная проверка журналов (7 дней в неделю, 365 дней в году, включая праздничные дни) сводит к минимуму количество времени и вероятность потенциального нарушения. Средства сбора, анализа и оповещения журналов, централизованные системы управления журналами, анализаторы журналов событий и решения для управления информацией о безопасности и событиями (SIEM) являются примерами автоматизированных инструментов, которые можно использовать для удовлетворения этого требования.
Ежедневный просмотр событий безопасности — например, уведомлений или предупреждений, которые идентифицируют подозрительные или аномальные действия, — а также журналов критически важных системных компонентов и журналов систем, выполняющих функции безопасности, таких как брандмауэры, идентификаторы/IP-адреса, системы мониторинга целостности файлов (FIM) и т.д., необходим для выявления потенциальные проблемы.
Определение “события безопасности” будет отличаться для каждой организации и может включать в себя рассмотрение типа технологии, местоположения и функции устройства. Организации могут также пожелать поддерживать базовый уровень “нормального” трафика, чтобы помочь выявить аномальное поведение.
Объект, который использует сторонних поставщиков услуг для выполнения служб просмотра журналов, отвечает за предоставление поставщикам услуг контекста среды объекта, чтобы он понимал среду объекта, имел базовый уровень “нормального” трафика для объекта и мог обнаруживать потенциальные проблемы безопасности и предоставлять точные исключения и уведомления об аномалиях.

10.4.1.1
Определенные требования подхода:
Используются автоматизированные механизмы для проведения обзора журналов аудита.

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

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

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

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

Дополнительная информация:
Для дополнительной информации см. приложение "Эффективный ежедневный мониторинг журналов".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.5.1
Определенные требования подхода:
Сохраняйте историю журналов аудита не менее 12 месяцев, при этом последние три месяца должны быть немедленно доступны для анализа.

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

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

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

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

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

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

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

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

Примеры:
Протокол сетевого времени (NTP) является одним из примеров технологии синхронизации времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры:
Методы, которые могут быть использованы, включают, но не ограничиваются, беспроводными сетевыми сканами, физическими/логическими проверками компонентов системы и инфраструктуры, сетевым контролем доступа (NAC) или беспроводными IDS/IPS. NAC и беспроводные IDS/IPS являются примерами инструментов автоматического мониторинга.

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

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

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

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

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

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

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

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

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

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

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

11.3.1.1
Определенные требования подхода:
Все другие применимые уязвимости (которые не классифицируются как высокорисковые или критические уязвимости в соответствии с рейтингами рисков уязвимостей организации, определенными в Требовании 6.3.1) управляются следующим образом:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания по применению:
Для первоначального соответствия требованиям PCI DSS не требуется, чтобы в течение 12 месяцев было выполнено четыре проходных сканирования, если оценщик проверяет: 1) самым последним результатом сканирования было проходное сканирование, 2) организация имеет задокументированные политики и процедуры, требующие проверки не реже одного раза в три месяца, и 3) уязвимости, отмеченные в результаты сканирования были исправлены, как показано в повторном сканировании (-ах).
Однако в последующие годы после первоначальной оценки PCI DSS необходимо проходить сканирование не реже одного раза в три месяца.
Инструменты сканирования ASV могут сканировать широкий спектр типов и топологий сетей. Любые особенности целевой среды (например, балансировщики нагрузки, сторонние поставщики, интернет-провайдеры, конкретные конфигурации, используемые протоколы, помехи при сканировании) должны быть согласованы между ASV и клиентом сканирования.
Обратитесь к Руководству по программе ASV, опубликованному на веб-сайте PCI SSC, для получения информации об обязанностях клиента сканирования, подготовке к сканированию и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надлежащая практика:
Некоторые соображения при выборе квалифицированного ресурса для проведения тестирования на проникновение включают:

Дополнительная информация:
Дополнительные рекомендации см. в Информационном дополнении: Руководство по тестированию на проникновение на веб-сайте PCI SSC.

11.4.3
Определенные Требования к Подходу:
Выполняется внешнее тестирование на проникновение:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11.4.7
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг с несколькими арендаторами: Поставщики услуг с несколькими арендаторами поддерживают своих клиентов для внешнего тестирования на проникновение в соответствии с требованиями 11.4.3 и 11.4.4.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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