Требования безопасности 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)    Следует обеспечить защиту общедоступных веб-приложений от известных атак (а также регулярно учитывать новые угрозы и уязвимости) одним из следующих методов:
• проверять приложение на наличие уязвимостей с использованием методов ручного или автоматического анализа защищенности приложений не реже одного раза в год, а также после внесения изменений. Примечание. Данная оценка отличается от сканирования на наличие уязвимостей в требовании 9.
• Перед общедоступным веб- приложением должно быть установлено техническое средство для постоянной проверки всего трафика (например, веб-брандмауэр) с целью обнаружения и предупреждения веб- атак.
9)    Следует проводить внешнее и внутреннее сканирование сети на наличие уязвимостей не реже одного раза в квартал, а также после внесения значительных изменений (например, установки новых системных компонентов, изменения топологии сети, изменения правил межсетевых экранов, обновления продуктов).
10)    Небезопасная передача данных.
•    Изучить политики и процедуры разработки ПО и опросить ответственных сотрудников, чтобы убедиться, что при программировании предпринимаются меры по предотвращению небезопасных коммуникаций, обеспечивающие надлежащую аутентификацию и шифрование всех критичных коммуникаций. (№ПП-614-2007г. «О мерах по организации криптографической защиты информации в Республики Узбекистан»).
Приложения, которые не шифруют надлежащим образом сетевой трафик с применением стойких криптографических методов, подвергаются повышенному риску взлома и утечки данных держателей карт.
11)    Следует проводить внешний тест на проникновение не реже одного раза в год, а также после любой значительной модификации или обновления инфраструктуры и приложений (например, обновления операционной системы, добавления подсети, установки веб-сервера).
12)    Следует проводить внутренний тест на проникновение не реже одного раза в год, а также после любой значительной модификации или обновления инфраструктуры и приложений (например, обновления операционной системы, добавления подсети, установки веб-сервера).
13)    Межсайтовый скриптинг (XSS).
•    Изучить политики и процедуры разработки ПО и опросить ответственных сотрудников, чтобы убедиться, что при программировании предпринимаются меры по предотвращению межсайтового скриптинга (XSS), в том числе:
a)    проверка всех параметров перед их включением в код;
b)    использование контекстно-зависимого изолирования.
Межсайтовый скриптинг (XSS) происходит, когда приложение отправляет предоставленные пользователем данные в веб-браузер без предварительной проверки или шифрования этого содержимого. Межсайтовый скриптинг позволяет злоумышленникам выполнять сценарии в браузере жертвы для захвата сеансов пользователя, изменения вида веб- сайтов, возможного внедрения червей и т.д
14)    Подделка межсайтовых запросов (CSRF).
•    Изучить политики и процедуры разработки ПО и опросить ответственных сотрудников, чтобы убедиться, что при программировании предпринимаются меры по предотвращению подделки межсайтовых запросов и обеспечению того, чтобы приложения не полагались на учетные данные для проверки подлинности и токены, автоматически отправляемые браузерами.
В случае подделки межсайтовых запросов (CSRF) браузер жертвы отправляет предварительно авторизованный запрос в уязвимое веб-приложение, что позволяет злоумышленнику совершить любые действия, которые может совершить жертва (например, обновление сведений о счете, совершение покупок или даже вход в приложение).

15)    Противодействие взлому механизмов аутентификации и управления сеансами.
•    Изучить политики и процедуры разработки ПО и опросить ответственных сотрудников, чтобы убедиться, что при программировании предпринимаются меры по противодействию взлому механизмов аутентификации и управления сеансами, в том числе:
а) сеансовые токены (например, cookies) помечаются как "безопасные";
б) отсутствие идентификатора сеанса в URL-адресе;
в) внедрение соответствующих ограничений по длительности сеанса и ротации идентификаторов после успешного входа.
Безопасная аутентификация и управление сессией не позволят злоумышленнику взломать подлинные учетные данные, ключи или сеансовые токены, с помощью которых можно выдать себя за авторизованного пользователя.

Рекомендации
16)    При использовании WEB приложений, для упрощения мер безопасности рекомендуем поставщикам услуг при совершении ввода карточных данных клиентами, переадресовать на web сайты поставщиков в которых уже организованы и соблюдены все необходимые меры безопасности.
17)    Использовать сканеры уязвимости для разработанных платежных приложений.
18)    Ознакомиться стандартом безопасности данных индустрии платежных карт PCI-DSS https://ru.wikipedia.org/wiki/PCI_DSS
Требования PCI DSS применимы к организациям и средам, в которых осуществляется хранение, обработка или передача банковских данных (данных держателей карт и (или) критичных аутентификационных данных). Некоторые требования PCI DSS также могут быть применены к организациям, передавшим платежные операции или управление информационной средой держателей карт (CDE) третьим лицам. Кроме того, организации, передавшие платежные операции или управление информационной средой держателей карт (CDE) третьим лицам, обязуются гарантировать, что защита банковских данных осуществляется третьими лицами в соответствии с применимыми требованиями PCI DSS.

Источник: uzcard.uz