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

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

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

 

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

или

или

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определенные Процедуры Тестирования Подхода:

Цель:
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.

Определения:
Многофакторная аутентификация (MFA) требует, чтобы пользователь представил минимум два из трех факторов аутентификации, указанных в требовании 8.3.1, прежде чем будет предоставлен доступ. Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.

8.5.1
Определенные Требования к Подходу:
Системы MFA реализуются следующим образом:

Цель Индивидуального подхода:
Системы MFA устойчивы к атакам и строго контролируют любые административные переопределения.

Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

Цель:
Злоумышленники могут обойти плохо настроенные системы MFA. Таким образом, это требование касается конфигурации системы (систем) MFA, которые предоставляют MFA для пользователей, получающих доступ к системным компонентам в CDE.

Определения:
Использование одного типа фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.

Дополнительная информация:
Для получения дополнительной информации о системах и функциях 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, используемым в транзакциях с использованием карты (то есть форм-фактор платежной карты, такой как карта, которую проводят пальцем, нажимают или опускают).
Это требование не предназначено для применения к компонентам ручного ввода клавиш панорамирования, таким как компьютерные клавиатуры. Это требование рекомендуется, но не обязательно, для компонентов ручного ввода клавиш панорамирования, таких как компьютерные клавиатуры.
Это требование не распространяется на коммерческие готовые устройства (COTS) (например, смартфоны или планшеты), которые являются мобильными торговыми устройствами, предназначенными для массового распространения.

Определенные Процедуры Тестирования Подхода:

Цель:
Мошенники пытаются украсть данные платежных карт, крадя и/или манипулируя устройствами и терминалами для считывания карт. Преступники будут пытаться украсть устройства, чтобы узнать, как взломать их, и они часто пытаются заменить законные устройства мошенническими устройствами, которые отправляют им данные платежной карты каждый раз, когда вводится карта.
Они также попытаются добавить компоненты “скимминга” на внешнюю сторону устройств, которые предназначены для захвата данных платежных карт до того, как они попадут на устройство — например, путем подключения дополнительного устройства чтения карт поверх обычного устройства чтения карт, чтобы данные платежной карты были захвачены дважды: один раз вредоносным компонентом, а затем легальным компонентом устройства. Таким образом, транзакции все еще могут быть завершены без перерыва, в то время как преступник “снимает” данные платежной карты во время процесса.

Надлежащая практика:
Дополнительные рекомендации по предотвращению скимминга доступны на веб-сайте 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) или беспроводные идентификаторы/IP-адреса. NAC и беспроводные идентификаторы/IP-адреса являются примерами автоматизированных средств мониторинга.

11.2.2
Определенные Требования к Подходу:
Ведется инвентаризация авторизованных точек беспроводного доступа, включая документированное бизнес-обоснование.

Цель Индивидуального подхода:
Несанкционированные точки беспроводного доступа не принимаются за авторизованные точки беспроводного доступа.

Определенные Процедуры Тестирования Подхода:

Цель:
Инвентаризация авторизованных точек беспроводного доступа может помочь администраторам быстро реагировать при обнаружении несанкционированных точек беспроводного доступа. Это помогает превентивно свести к минимуму
воздействие CDE на злоумышленников.

Надлежащая практика:
При использовании беспроводного сканера не менее важно иметь определенный список известных точек доступа, которые, хотя и не подключены к сети компании, обычно обнаруживаются во время сканирования. Эти устройства, не принадлежащие компании, часто встречаются в многоквартирных зданиях или на предприятиях, расположенных рядом друг с другом. Однако важно убедиться, что эти устройства не подключены к сетевому порту организации или через другое устройство, подключенное к сети, и им присвоен SSID, похожий на соседний бизнес. В результатах сканирования должны быть указаны такие устройства и то, как было определено, что эти устройства могут быть “проигнорированы”. Кроме того, обнаружение любых несанкционированных точек беспроводного доступа, которые определены как представляющие угрозу для CDE, должно управляться в соответствии с планом реагирования организации на инциденты в соответствии с требованием 12.10.1.

11.3.1
Определенные Требования к Подходу:
Проверка внутренних уязвимостей выполняется следующим образом:

Цель Индивидуального подхода:
Состояние безопасности всех компонентов системы периодически проверяется с помощью автоматизированных инструментов, предназначенных для обнаружения уязвимостей, действующих внутри сети. Обнаруженные уязвимости оцениваются и устраняются на основе формальной системы оценки рисков

Примечания по применению:
Для проведения внутреннего сканирования уязвимостей не требуется использовать QSA или ASV.
Внутреннее сканирование уязвимостей может выполняться квалифицированным внутренним персоналом, который разумно независим от проверяемого системного компонента (компонентов) (например, сетевой администратор не должен нести ответственность за сканирование сети), или организация может выбрать, чтобы внутреннее сканирование уязвимостей выполнялось фирмой, специализирующейся на сканировании уязвимостей.

Определенные Процедуры Тестирования Подхода:

Цель:
Быстрое выявление и устранение уязвимостей снижает вероятность использования уязвимости и потенциальной компрометации системного компонента или данных о держателях карт. Сканирование уязвимостей, проводимое не реже одного раза в три месяца, обеспечивает такое обнаружение и идентификацию.

Надлежащая практика:
Уязвимости, представляющие наибольший риск для окружающей среды (например, имеющие высокий или критический рейтинг в соответствии с требованием 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
Определенные Требования к Подходу:
Механизм обнаружения изменений (например, средства мониторинга целостности файлов) развертывается следующим образом:

Цель Индивидуального подхода:
Критически важные файлы не могут быть изменены неавторизованным персоналом без создания предупреждения.

Примечания по применению:
Для целей обнаружения изменений критическими файлами обычно являются те, которые регулярно не изменяются, но изменение которых может указывать на компрометацию системы или риск компрометации. Механизмы обнаружения изменений, такие как продукты мониторинга целостности файлов, обычно поставляются с предварительно настроенными критически важными файлами для соответствующей операционной системы. Другие важные файлы, например файлы для пользовательских приложений, должны быть оценены и определены организацией (то есть продавцом или поставщиком услуг).

Определенные Процедуры Тестирования Подхода:

Цель:
Изменения в критически важных системных, конфигурационных или содержательных файлах могут указывать на то, что злоумышленник получил доступ к системе организации. Такие изменения могут позволить злоумышленнику совершать дополнительные вредоносные действия, получать доступ к данным о держателях карт и/или осуществлять действия без обнаружения или записи.
Механизм обнаружения изменений будет обнаруживать и оценивать такие изменения в критически важных файлах и генерировать предупреждения, на которые можно реагировать в соответствии с определенными процессами, чтобы персонал мог предпринять соответствующие действия.
При неправильной реализации и отслеживании результатов решения для обнаружения изменений злоумышленник может добавлять, удалять или изменять содержимое файла конфигурации, программы операционной системы или исполняемые файлы приложений. Несанкционированные изменения, если они не будут обнаружены, могут сделать существующие меры безопасности неэффективными и/или привести к краже данных о держателях карт без заметного влияния на нормальную обработку.

Надлежащая практика:
Примеры типов файлов, которые следует отслеживать, включают, но не ограничиваются ими:

Примеры:
Решения для обнаружения изменений, такие как средства мониторинга целостности файлов (FIM), проверяют наличие изменений, дополнений и удалений в критически важных файлах и уведомляют об обнаружении таких изменений.

11.6.1
Определенные Требования к Подходу:
Механизм обнаружения изменений и несанкционированного доступа развертывается следующим образом:

Цель Индивидуального подхода:
Код или методы скимминга электронной коммерции не могут быть добавлены на страницы платежей, полученные браузером потребителя, без своевременного оповещения. Меры по борьбе со скиммингом не могут быть удалены со страниц платежей без создания оперативного предупреждения.

Примечания по применению:
Цель этого требования заключается не в том, чтобы организация устанавливала программное обеспечение в системах или браузерах своих потребителей, а скорее в том, чтобы организация использовала методы, подобные тем, которые описаны в разделе Примеры в колонке Руководства, для предотвращения и обнаружения непредвиденных действий скрипта.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

Цель:
Многие веб-страницы теперь полагаются на сборку объектов, включая активный контент (в первую очередь JavaScript), из нескольких интернет-местоположений. Кроме того, содержимое многих веб-страниц определяется с помощью систем управления контентом и управления тегами, которые, возможно, невозможно отслеживать с помощью традиционных механизмов обнаружения изменений.
Таким образом, единственное место, где можно обнаружить изменения или признаки вредоносной активности, - это браузер пользователя при создании страницы и интерпретации всего JavaScript.
Сравнивая текущую версию HTTP-заголовка и активного содержимого платежных страниц, полученных браузером пользователя, с предыдущими или известными версиями, можно обнаружить несанкционированные изменения, которые могут указывать на атаку скимминга.
Кроме того, при поиске известных признаков компрометации и элементов сценария или поведения, типичных для скиммеров, могут быть подняты подозрительные предупреждения.

Примеры:
Механизмы, которые обнаруживают изменения в заголовках и содержимом платежной страницы и сообщают об этом, включают, но не ограничиваются ими:

Часто эти механизмы основаны на подписке или облаке, но также могут основываться на пользовательских и индивидуальных решениях.

12.1.1
Определенные Требования к Подходу:
Общая политика информационной безопасности - это:

Цель Индивидуального подхода:
Стратегические цели и принципы информационной безопасности определены, приняты и известны всему персоналу.

Определенные Процедуры Тестирования Подхода:

Цель:
Общая политика информационной безопасности организации связана со всеми другими политиками и процедурами, определяющими защиту данных о держателях карт, и регулирует их.
Политика информационной безопасности отражает намерения и цели руководства в отношении защиты его наиболее ценных активов, включая данные о держателях карт.
Без политики информационной безопасности отдельные лица будут принимать свои собственные ценностные решения в отношении средств контроля, которые требуются в организации, что может привести к тому, что организация не будет выполнять свои юридические, нормативные и договорные обязательства, а также не сможет надлежащим образом защитить свои активы последовательным образом.
Для обеспечения реализации политики важно, чтобы весь соответствующий персонал в организации, а также соответствующие третьи стороны, поставщики и деловые партнеры были осведомлены о политике информационной безопасности организации и их обязанностях по защите информационных активов.

Надлежащая практика:
Политика безопасности организации определяет цель, сферу охвата, подотчетность и информацию, которая четко определяет позицию организации в отношении информационной безопасности.
Общая политика информационной безопасности отличается от отдельных политик безопасности, которые касаются конкретных технологий или дисциплин безопасности. Эта политика устанавливает директивы для всей организации, в то время как отдельные политики безопасности согласовывают и поддерживают общую политику безопасности и сообщают конкретные цели для технологий или дисциплин безопасности.
Важно, чтобы весь соответствующий персонал в организации, а также соответствующие третьи стороны, поставщики и деловые партнеры были осведомлены о политике информационной безопасности организации и их обязанностях по защите информационных активов.

Определения:
“Соответствующий” для этого требования означает, что политика информационной безопасности распространяется среди лиц, чьи роли применимы к некоторым или всем разделам политики, либо внутри компании, либо из-за услуг/функций, выполняемых поставщиком или третьей стороной

12.1.2
Определенные Требования к Подходу:
Политика информационной безопасности заключается в:

Цель Индивидуального подхода:
Политика информационной безопасности продолжает отражать стратегические цели и принципы организации.

Определенные Процедуры Тестирования Подхода:

Цель:
Угрозы безопасности и связанные с ними методы защиты быстро развиваются. Без обновления политики информационной безопасности с учетом соответствующих изменений новые меры защиты от этих угроз могут быть не приняты.

12.1.3
Определенные Требования к Подходу:
Политика безопасности четко определяет роли и обязанности в области информационной безопасности для всего персонала, и все сотрудники осознают и признают свои обязанности в области информационной безопасности.

Цель Индивидуального подхода:
Персонал понимает свою роль в защите данных о держателях карт организации.

Определенные Процедуры Тестирования Подхода:

Цель:
Без четко определенных ролей и обязанностей в области безопасности может произойти неправильное использование информационных ресурсов организации или непоследовательное взаимодействие с персоналом по информационной безопасности, что приведет к ненадежному внедрению технологий или использованию устаревших или небезопасных технологий.

12.1.4
Определенные Требования к Подходу:
Ответственность за информационную безопасность официально возлагается на главного сотрудника по информационной безопасности или другого члена исполнительного руководства, обладающего знаниями в области информационной безопасности.

Цель Индивидуального подхода:
Назначенный член исполнительного руководства отвечает за информационную безопасность.

Определенные Процедуры Тестирования Подхода: