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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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