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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12.3.1
Определенные требования подхода:
Для каждого требования PCI DSS, которое требует выполнения целенаправленного анализа рисков, этот анализ документируется и включает:

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

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

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

Надлежащая практика:
Рекомендуется, но не требуется, провести оценку рисков для всей организации, которая является точечной деятельностью, позволяющей организациям выявить угрозы и связанные с ними уязвимости, с целью понимания более широких и новых угроз, которые могут негативно повлиять на бизнес. Такая оценка рисков для всей организации может быть частью общей программы управления рисками, которая используется как входная информация для ежегодного обзора общей политики информационной безопасности организации (см. Требование 12.1.1).
Примеры методологий оценки рисков для оценок рисков на уровне всей организации включают, но не ограничиваются, ISO 27005 и NIST SP 800-30.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительная информация:
Смотрите NIST SP 800-131a, «Переход к использованию криптографических алгоритмов и длин ключей».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надлежащая практика:
Точное определение области включает в себя критическую оценку CDE и всех подключенных компонентов системы для определения необходимого покрытия требований PCI DSS. Мероприятия по определению области охвата, включая тщательный анализ и постоянный мониторинг, помогают обеспечить надлежащую защиту систем в области охвата. При документировании местоположений данных учетной записи организация может рассмотреть возможность создания таблицы или электронной таблицы, включающей следующую информацию:
Хранилища данных (базы данных, файлы, облако и т.д.), Включая цель хранения данных и срок хранения,
Какие элементы CHD сохраняются (PAN, дата истечения срока действия, имя владельца карты и/или любые элементы SAD до завершения авторизации),
Как защищаются данные (тип шифрования и надежность, алгоритм хеширования и надежность, усечение, токенизация),
Как регистрируется доступ к хранилищам данных, включая описание используемого механизма (механизмов) ведения журнала (корпоративное решение, уровень приложения, уровень операционной системы и т.д.).
В дополнение к внутренним системам и сетям, все подключения от сторонних организаций - например, деловых партнеров, организаций, предоставляющих услуги удаленной поддержки, и других поставщиков услуг — должны быть идентифицированы для определения включения в сферу действия PCI DSS. Как только соединения в рамках области будут идентифицированы, могут быть реализованы соответствующие средства контроля PCI DSS, чтобы снизить риск использования стороннего подключения для компрометации CDE организации.
Инструмент или методология обнаружения данных могут быть использованы для облегчения идентификации всех источников и местоположений PAN, а также для поиска PAN, который находится в системах и сетях за пределами текущего определенного CDE или в неожиданных местах в пределах определенного CDE — например, в журнале ошибок или файле дампа памяти. Этот подход может помочь гарантировать, что ранее неизвестные местоположения PAN будут обнаружены и что PAN будет либо удален, либо должным образом закреплен

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания по применению:
Использование TPSP, совместимого с PCI DSS, не делает организацию совместимой с PCI DSS и не снимает с организации ответственности за ее собственное соответствие требованиям PCI DSS.

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

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

Примеры:
Различные типы TPSP включают те, которые:

12.8.2
Определенные требования подхода:

Письменные соглашения с TPSP поддерживаются следующим образом:

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

Примечания по применимости:
Точное содержание соглашения зависит от деталей предоставляемой услуги и обязанностей, возложенных на каждую сторону. Соглашение не обязано включать точные формулировки, указанные в этом требовании.
Письменное подтверждение от TPSP — это подтверждение, в котором говорится, что TPSP несет ответственность за безопасность данных счета, которые она может хранить, обрабатывать или передавать от имени клиента или в той мере, в какой TPSP может повлиять на безопасность данных держателей карт и/или чувствительных данных аутентификации клиента.
Доказательства того, что TPSP соблюдает требования PCI DSS (например, Attestation of Compliance (AOC) PCI DSS, декларация на сайте компании, политическое заявление, матрица ответственности или другие доказательства, не включенные в письменное соглашение), не считаются письменным подтверждением, указанным в этом требовании.

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

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

Дополнительная информация:
Смотрите «Information Supplement: Third-Party Security Assurance» для получения дополнительной информации.

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

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

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

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

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

12.8.4
Определенные Требования к Подходу:
Внедрена программа для мониторинга статуса соответствия TPSP PCI DSS не реже одного раза в 12 месяцев.

Цель Индивидуального подхода:
Статус соответствия TPSP стандарту PCI DSS периодически проверяется.

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

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

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

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

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

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

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

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

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

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

Дополнительная информация:
Образец шаблона матрицы ответственности приведен в Информационном дополнении: Обеспечение безопасности третьей стороной.

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

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

Примечания по применимости:
Это требование применяется только в случае, если оцениваемая организация является поставщиком услуг.
Точное содержание соглашения зависит от деталей предоставляемой услуги и обязанностей, возложенных на каждую сторону. Соглашение не обязано включать точные формулировки, указанные в этом требовании.
Письменное подтверждение от TPSP — это подтверждение, в котором говорится, что TPSP несет ответственность за безопасность данных счета, которые она может хранить, обрабатывать или передавать от имени клиента или в той мере, в какой TPSP может повлиять на безопасность данных держателей карт и/или чувствительных данных аутентификации клиента.
Доказательства того, что TPSP соблюдает требования PCI DSS, не считаются письменным подтверждением, указанным в этом требовании. Например, Attestation of Compliance (AOC) PCI DSS, декларация на сайте компании, политическое заявление, матрица ответственности или другие доказательства, не включенные в письменное соглашение, не являются письменным подтверждением.

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

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

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

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

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

Надлежащая практика:
Если у TPSP есть Attestation of Compliance (AOC) по PCI DSS, ожидается, что TPSP предоставит его своим клиентам по запросу, чтобы продемонстрировать свой статус соответствия PCI DSS.
Если TPSP не проходил оценку по PCI DSS, он может предоставить другие достаточные доказательства, чтобы продемонстрировать, что он соответствует применимым требованиям, без прохождения формальной валидации соответствия. Например, TPSP может предоставить конкретные доказательства оценщику клиента, чтобы тот мог подтвердить, что соответствующие требования выполнены. В качестве альтернативы TPSP может пройти несколько оценок по запросу каждого из оценщиков клиентов, каждая из которых будет направлена на подтверждение того, что соответствующие требования выполнены.
TPSP должны предоставлять своим клиентам достаточные доказательства, чтобы те могли удостовериться, что объем оценки PCI DSS для TPSP покрывает услуги, применимые к клиенту, и что соответствующие требования PCI DSS были проверены и признаны выполненными.
TPSP могут определить свои обязательства по PCI DSS одинаковыми для всех своих клиентов; в противном случае это обязательство должно быть согласовано как с клиентом, так и с TPSP. Важно, чтобы клиент понимал, какие требования PCI DSS и подпункты требований TPSP согласились выполнить, какие требования являются общими для TPSP и клиента, и в случае общих требований — как эти требования делятся и кто несет ответственность за выполнение каждого подпункта. Примером способа документирования этих обязательств является матрица, которая идентифицирует все применимые требования PCI DSS и указывает, кто из сторон (клиент или TPSP) несет ответственность за выполнение того или иного требования или для которых требуется совместная ответственность.

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

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

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

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

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

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

Примеры:
Юридические требования к сообщению о компрометации включают требования большинства штатов США, Общего регламента ЕС по защите данных (GDPR) и Закона о защите персональных данных (Сингапур).

Дополнительная информация:
Для получения дополнительной информации обратитесь к Руководству по обработке инцидентов компьютерной безопасности NIST SP 800- 61 Rev. 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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