Платежные карты, безопасность данных, требования и процедуры аудита безопасности (стр. 7 )

Требование	Процедура тестирования/аудита	Соответствует	Не соответствует	Дата устранения/ комментарий
Примечание – Уязвимости, перечисленные в 6.5.1 – 6.5.10, уже были описаны в [8], когда была опубликована версия 1.2 [1]. Однако при обновлении [8] необходимо обеспечить соответствие требованиям настоящего предстандарта.	6.5.в Убедиться, что применяются процессы разработки ПО, которые гарантируют, что веб-приложения не будут в последующем подвержены уязвимостям:
6.5.1 Исполнение сценариев атак типа "межсайтовый скриптинг"	6.5.1 Исполнение сценариев атак типа "межсайтовый скриптинг" (проверить все параметры перед включением)
6.5.2 Ошибки внедрения кода, в частности SQL-кода. Также следует учитывать ошибки внедрения LDAP - и Xpath-кодов, а также другие ошибки внедрения кода	6.5.2 Ошибки внедрения кода, в частности SQL-кода. (Проверить входные данные и убедиться, что данные пользователя не могут изменить значения команд и запросов)
6.5.3 Выполнение вредоносных файлов	6.5.3 Выполнение вредоносного кода (проверка входных данных на наличие полученных от пользователей имен файлов и самих файлов, содержащих вредоносный код)
6.5.4 Небезопасные прямые ссылки на объекты	6.5.4 Небезопасные прямые ссылки на объекты (не предоставлять пользователям доступ к ссылкам на внутренние объекты)
6.5.5 Подделка межсайтового запроса	6.5.5 Подделка межсайтового запроса (нельзя полагаться только на авторизацию учетных данных и средства аутентификации, автоматически предоставляемые обозревателями)
6.5.6 Утечка информации и неправильная обработка ошибок	6.5.6 Утечка информации и неправильная обработка ошибок (не допускать утечки информации при обработке сообщений об ошибках или других средств)
6.5.7 Прерванная аутентификация и управление сеансами	6.5.7 Прерванная аутентификация и управление сеансами (осуществлять авторизацию пользователей и защищать учетные данные и сеансовые идентификаторы должным образом)
6.5.8 Небезопасное хранение криптографических материалов	6.5.8 Небезопасное хранение криптографических материалов (не допускать уязвимостей, связанных с хранением криптографических материалов)

Окончание таблицы 7

Требование	Процедура тестирования/аудита	Соответствует	Не соответствует	Дата устранения/ комментарий
6.5.9 Небезопасные коммуникации	6.5.9 Небезопасные коммуникации (шифровать все коммуникации аутентификации и критически важные коммуникации)
6.5.10 Невозможность ограничения доступа пользователей к URL-адресам	6.5.10 Невозможность ограничения доступа пользователей к URL-адресам (систематически контролировать доступ на уровне представления и бизнес-логику всех URL-адресов)
6.6 Необходимо постоянно нейтрализовать новые угрозы и устранять новые уязвимости в общедоступных веб-приложениях, которые также должны защищаться от известных атак с помощью одного из приведенных ниже методов: – анализ веб-приложений с помощью ручных или автоматизированных средств или методов оценки безопасности приложений от уязвимостей не реже чем один раз в год или после внесения в них любых изменений; – установка МЭ веб-приложений до точки подключения веб-приложения к общедоступной сети	6.6 Удостовериться, что для общедоступных веб-приложений реализован один из следующих методов: а) убедиться, что анализ общедоступных веб-приложений проводится (с помощью ручных или автоматизированных средств или методов оценки безопасности приложений от уязвимостей) с учетом следующего: 1) не реже одного раза в год; 2) после каждого изменения кода; 3) организацией, специализирующейся в области безопасности приложений; 4) с целью устранения всех уязвимостей; 5) после внесения исправлений в веб-приложение выполняется его повторный анализ; б) убедиться, что установлен МЭ веб-приложений, применяется до точки подключения веб-приложения к общедоступной сети, чтобы обнаруживать и предотвращать атаки из сети Интернет. Примечание – Под организацией, специализирующейся в области безопасности приложений, понимается сторонняя организация, подразделение клиента или эксперты, которые специализируются в области безопасности приложений и могут доказать, что они не входят в группу разработчиков ПО.

5.5 Обеспечение мер строгого управления доступом

5.5.1 Требование 7: Ограничить доступ к данным держателей платежных карт в соответствии со служебной необходимостью

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

Таблица 8

Требование	Процедура тестирования/аудита	Соответствует	Не соответствует	Дата устранения/ комментарий
7.1 Доступ к системным компонентам и данным держателей платежных карт должен быть предоставлен только тем сотрудникам, которым он необходим для выполнения их должностных обязанностей. Ограничение доступа включает следующие меры:	7.1 Ознакомиться с документированными правилами управления доступом и удостовериться, что они включают следующие положения:
7.1.1 Права доступа привилегированных пользователей ограничены минимально необходимыми привилегиями, необходимыми для выполнения их должностных обязанностей	7.1.1 Убедиться, что права доступа привилегированных пользователей ограничены минимально необходимыми привилегиями, необходимыми для выполнения их должностных обязанностей
7.1.2 Назначение привилегий осуществляется в соответствии с должностью сотрудника и выполняемыми им функциями	7.1.2 Убедиться, что привилегии назначаются сотрудникам в соответствии с должностью и выполняемыми функциями (другое название – контроль доступа, основанный на ролях, или RBAC)
7.1.3 Для предоставления привилегий необходимо наличие формы допуска с перечнем запрашиваемых привилегий, утвержденной руководством	7.1.3 Убедиться, что для предоставления привилегий требуется наличие формы допуска с перечнем запрашиваемых привилегий, утвержденной руководством
7.1.4 Использование автоматизированных систем контроля доступа	7.1.4 Убедиться, что для контроля доступа используются автоматизированные системы контроля доступа

Окончание таблицы 8

Требование	Процедура тестирования/аудита	Соответствует	Не соответствует	Дата устранения/ комментарий
7.2 Для многопользовательских системных компонентов должна быть реализована система контроля доступа, ограничивающая доступ по принципу служебной необходимости, запрещающая любой доступ без специальных исключений. Система контроля доступа должна включать следующие характеристики:	7.2 Ознакомиться с настройками системы и документацией производителя и удостовериться, что система контроля доступа реализована и включает следующие характеристики:
7.2.1 Распространение на все системные компоненты	7.2.1 Убедиться, что системы контроля доступа используются на всех системных компонентах
7.2.2 Назначение привилегий сотрудникам в соответствии с должностью и выполняемыми функциями	7.2.2 Убедиться, что системы контроля доступа настроены на предоставление сотрудникам привилегий в соответствии с их должностями и выполняемыми функциями
7.2.3 Запрет любого вида доступа по умолчанию	7.2.3 Убедиться, что системы контроля доступа по умолчанию запрещают любые виды доступа. Примечание – Некоторые системы контроля доступа по умолчанию разрешают любой доступ, если не заданы специальные исключения.

5.5.2 Требование 8: Присвоить уникальный идентификатор (ID) каждому лицу, имеющему доступ к компьютеру

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

Таблица 9

Требование	Процедура тестирования/аудита	Соответствует	Не соответствует	Дата устранения/ комментарий
8.1 Каждому пользователю должен быть присвоен уникальный идентификатор до предоставления доступа к системным компонентам или данным держателей платежных карт	8.1 Убедиться, что каждому пользователю присваивается уникальный идентификатор для предоставления доступа к системным компонентам или данным держателей платежных карт

Продолжение таблицы 9