Требования безопасности UzCard при использовании карточных данных для поставщиков услуг через сети интернет

01.05.2016

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

1)    Хранение данных держателей карт должно быть ограничено только необходимым минимумом. Должны быть разработаны политики, процедуры и процессы хранения и уничтожения данных, соответствующие следующим минимальным требованиям к хранению данных держателей карт:
а) количество данных и сроки их хранения должны быть ограничены только необходимыми для выполнения требований бизнеса, законодательства и иных регулирующих требований;
б) процессы безопасного удаления данных, хранение которых более не является необходимым;
2)    Следует маскировать основной номер держателя карты при его отображении (максимально возможное количество знаков для отображения – первые шесть и последние четыре), чтобы только сотрудники с обоснованной коммерческой необходимостью могли видеть весь основной номер держателя карты.
3)    PAN (номер карты) должен быть представлен в нечитаемом виде во всех местах хранения (включая данные на съемных носителях, в резервных копиях и журналах протоколирования событий). Для этого следует использовать любой из следующих методов:
• функция стойкого однонаправленного хеширования (должен быть хеширован весь основной номер держателя карты);
Их использование целесообразно тогда, когда нет необходимости в восстановлении основного номера держателя карты.
• усечение (хеширование не может использоваться для замещения усеченного сегмента основного номера держателя карты);
Цель усечения заключается в том, что хранится только часть (не больше шести первых и четырех последних цифр) основного номера держателя карты.
Примечание. При наличии доступа одновременно к маскированному (усеченному) и хешированному номерам карты для злоумышленника не составит большого труда восстановить данные исходного PAN.
• использование механизмов OneTime-Pad ("одноразовых блокнотов", хранение которых должно быть безопасным) и использование и хранение ссылок на данные вместо самих данных (токены, index tokens);
Одноразовый блокнот – это система, в которой секретный ключ, сгенерированный случайным образом, используется только один раз для шифрования сообщения, которое затем расшифровывается с помощью соответствующего одноразового блокнота и ключа.
Токен – это криптографический параметр, который заменяет основной номер держателя карты на основе заданного индекса для получения непредсказуемого значения.
• стойкие криптографические алгоритмы совместно с процессами и процедурами управления ключами.
Назначение стойкого криптографического алгоритма заключается в том, что шифрование основывается на использовании проверенных стандартизованных алгоритмов с высокой стойкостью ключей шифрования (а не собственных алгоритмов).
4)    Производственные данные (действующие PAN) не должны использоваться для тестирования и разработки.
5)    Отделить среды разработки/тестирования и производственного функционирования программного обеспечения друг от друга и при этом внедрить механизмы разграничения доступа.
6)    При передачи карточных данных запрещается использовать открытые проколы http. (на web сайтах где вводятся номера карт в полном виде, протокол http запрещается).
7)    Проверить программный код приложений на наличие потенциальных уязвимостей (вручную или автоматически) перед передачей готовых приложений заказчикам или переводом их в производственный режим с соблюдением следующих минимальных требований:
• изменения программного кода должны контролироваться лицами, иными, чем создавший его автор, и лицами, знакомыми с методиками контроля кода (code review techniques) и методами безопасного программирования (secure coding practices);
• контроль программного кода обеспечивает его разработку в соответствии с основными принципами безопасного программирования;
• все необходимые корректировки вносятся до выпуска программного обеспечения;
• результаты контроля кода рассматриваются и утверждаются руководством до выпуска программного обеспечения.
Примечание. Данное требование по осуществлению контроля кода (code reviews) применимо ко всему разрабатываемому программному коду (как внутренних, так и общедоступных приложений) как составная часть жизненного цикла разработки системы. Контроль кода может проводиться компетентным внутренним персоналом или третьими сторонами. В отношении веб-приложений, которые находятся в публичном доступе, также подлежат применению дополнительные меры по защите от появляющихся угроз и уязвимостей после внедрения, как определено в требовании 8.
8)    Следует обеспечить защиту общедоступных веб-приложений от известных атак (а также регулярно учитывать новые угрозы и уязвимости) одним из следующих методов:
• проверять приложение на наличие уязвимостей с использованием методов ручного или автоматического анализа защищенности приложений не реже одного раза в го