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

Вопрос:
Распространяется ли требование стандарта на пароль доступа в ОС (имеется ввиду его известность только лишь одному пользователю)? Ведь даже если пароль известен второму лицу, то оно никоим образом не получает доступа к данным ДДК, т.к. на компьютере их нет, а для доступа в сетевое приложение нужен отдельный уникальный пароль.

Более того, к данному компьютеру всё равно имеет доступ служба ИТ (для целей администрирования) да ещё и с администраторскими полномочиями (Очевиден и, наверное, не вызывает оспаривания тот факт, что пользователь на своём компьютере должен быть ограничен в правах (дабы не устанавливать сторонний софт, не подключать модемы и т.д.). Частично есть на это указание и в требованиях стандарта (1.4.b Проверить, что настройки персонального межсетевого экрана выполнены в соответствии со стандартами организации и не могут быть изменены пользователем.; 7.1.2 Назначение привилегий пользователям должно быть основано на их должностных обязанностях.).

В свете этого ещё раз повторю вопрос: обязательна ли уникальность пароля на доступ в ОС, если при этом нет возможности ознакомления с ДДК? Понимаю, что тут можно в качестве возражения привести пункт 8.5.3 "Установка уникального первоначального пароля для каждого пользователя и его немедленное изменение при первом входе пользователя". Но меня интересует вопрос распространения и сопровождения паролей на доступ в ОС централизовано Службой информационной безопасности - пароль знает только использующий его сотрудник и сотрудник Службы, сгенерировавший и ввёдший его в систему. В качестве компенсационной меры может быть журналирование, с фиксацией станций, с которых осуществляется вход, с последующим контролем отсутствия входов с посторонних станций.

В противном случае администраторский пароль надо отдавать в единоличное владение рядового пользвателя, что тоже противоречит ряду требований стандарта, а также несёт ряд неоправданно обременительных процедур администрирования (например, для утановки патча сотрудник должен быть на месте и помнить помимо своего пароля ещё и дополнительный) и рисков ИБ.

Молчание знак согласия?

Здравствуйте.

Если компьютер для доступа к сетевому приложению ДПК входит в область применения стандарта, то требование 8.5 на него распространяется.
Требование 8.1. на доступ к данным выполняется, но не выполняется на доступ к системным компонентам.
При компрометации компьютера (а эксплуатация ненадежных или известных всем паролей - первый шаг к компрометации) можно получить возможность скомпрометировать приложение с данными платежных карт. Тут же возникают проблемы с расследованием возможных инцидентов, поскольку даже если логгирование настроено хорошо, нет возможности определить конкретного пользователя.
Решением проблемы может служить двухфакторная аутентификация, когда после захода в ОС запускается терминальный клиент, для доступа к которому дополнительно требуется персональный «токен».

"Если компьютер для доступа к сетевому приложению ДПК входит в область применения стандарта, то требование 8.5 на него распространяется." - Я и хочу определиться - входит при таких обстоятельствах в ДДК или нет.

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

"Решением проблемы может служить двухфакторная аутентификация, когда после захода в ОС запускается терминальный клиент, для доступа к которому дополнительно требуется персональный «токен»." - Для доступа к сетевому приложению (а не к терминальному клиенту) мы используем двухфакторную аутентификацию (индивидуально для каждого пользователя ПИН-код + eToken). Каюсь, ранее я не указал конкретную процедуру доступа к сетевому приложению, указав только, что она осуществляется в соответствии с требованиями PCI DSS.

При таких условиях возможно (без нарушений требований PCI DSS) использование пользователем пароля на доступ в ОС с одновременным знанием данного пароля сотрудником Службы информационной безопасности? Повторюсь - на доступ к сетевому приложению требуется ПИН-код и eToken.

В описанных вами условиях компьютер входит в область применения стандарта и его требования по защите ДПК выполняются, если действительно на компьютере не остается НИКАКИХ следов ДПК (логи, временные файлы и т.п.).
Остальные реализованные меры (ограничение прав пользователя на АРМ; индивидуальный пароль в ОС, генерируемый и известный только сотруднику Службы ИБ; журналирование с фиксацией станций, с которых осуществляется вход) необходимо оформить как компенсационные меры

Дарья, спасибо.