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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительная информация:
Смотрите следующее для получения дополнительной информации о фишинге:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЛИ

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

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

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

ИЛИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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