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

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

Нормативно-правовые акты

Государственный стандарт республики Узбекистан. Руководство по внедрению системы управления информационной безопасностью O‘z DSt ISO/IEC 27003:2014 (ISO/IEC 27003:2010, MOD).

Стандарт Безопасности Данных Индустрии Платежных Карт (PCI) Требования и процедуры аудита безопасности.

1)    Этот документ содержит минимальный набор требований для защиты данных держателей карт, который может быть расширен дополнительными регулирующими механизмами и методами сокращения рисков, а также требованиями и распоряжениями, законодательства. Кроме того, в соответствии с законодательством или нормативными требованиями может требоваться особая защита данных, идентифицирующих личность, или других элементов данных (например, имени держателя карты). Требование не заменяет собой законы, правительственные распоряжения или иные требования законодательства.
2)    Хранение данных держателей карт должно быть ограничено только необходимым минимумом. Должны быть разработаны политики, процедуры и процессы хранения и уничтожения данных, соответствующие следующим минимальным требованиям к хранению данных держателей карт:
а) количество данных и сроки их хранения должны быть ограничены только необходимыми для выполнения требований бизнеса, законодательства и иных регулирующих требований;
б) процессы безопасного удаления данных, хранение которых более не является необходимым;
3)    Следует маскировать основной номер держателя карты при его отображении (максимально возможное количество знаков для отображения – первые шесть и последние четыре), чтобы только сотрудники с обоснованной коммерческой необходимостью могли видеть весь основной номер держателя карты.
4)    PAN (номер карты) должен быть представлен в нечитаемом виде во всех местах хранения (включая данные на съемных носителях, в резервных копиях и журналах протоколирования событий). Для этого следует использовать любой из следующих методов:
• функция стойкого однонаправленного хеширования (должен быть хеширован весь основной номер держателя карты);
Их использование целесообразно тогда, когда нет необходимости в восстановлении основного номера держателя карты.
Примечание. При наличии доступа одновременно к маскированному и хешированному номерам карты для злоумышленника не составит большого труда восстановить данные исходного PAN.
• усечение (хеширование не может использоваться для замещения усеченного сегмента основного номера держателя карты);
Цель усечения заключается в том, что хранится только часть (не больше шести первых и четырех последних цифр) основного номера держателя карты.
Примечание. При наличии доступа одновременно к маскированному и хешированному номерам карты для злоумышленника не составит большого труда восстановить данные исходного PAN.
• использование механизмов OneTime-Pad («одноразовых блокнотов», хранение которых должно быть безопасным) и использование и хранение ссылок на данные вместо самих данных (токены, index tokens);
Одноразовый блокнот – это система, в которой секретный ключ, сгенерированный случайным образом, используется только один раз для шифрования сообщения, которое затем расшифровывается с помощью соответствующего одноразового блокнота и ключа.
Токен – это криптографический параметр, который заменяет основной номер держателя карты на основе заданного индекса для получения непредсказуемого значения.
• стойкие криптографические алгоритмы совместно с процессами и процедурами управления ключами.
Назначение стойкого криптографического алгоритма заключается в том, что шифрование основывается на использовании проверенных стандартизованных алгоритмов с высокой стойкостью ключей шифрования (а не собственных алгоритмов).
5)    Производственные данные (действующие PAN) не должны использоваться для тестирования и разработки.
6)    Отделить среды разработки/тестирования и производственного функционирования программного обеспечения друг от друга и при этом внедрить механизмы разграничения доступа.
7)    При передачи карточных данных запрещается использовать открытые проколы http. (на web сайтах где вводятся номера карт в полном виде, протокол http запрещается)
8)    Проверить программный код приложений на наличие потенциальных уязвимостей (вручную или автоматически) перед передачей готовых приложений заказчикам или переводом их в производственный режим с соблюдением следующих минимальных требований:
• изменения программного кода должны контролироваться лицами, иными, чем создавший его автор, и лицами, знакомыми с методиками контроля кода (code review techniques) и методами безопасного программирования (secure coding practices);
• контроль программного кода обеспечивает его разработку в соответствии с основными принципами безопасного программирования;
• все необходимые корректировки вносятся до выпуска программного обеспечения;
• результаты контроля кода рассматриваются и утверждаются руководством до выпуска программного обеспечения.
Примечание. Данное требование по осуществлению контроля кода (code reviews) применимо ко всему разрабатываемому программному коду (как внутренних, так и общедоступных приложений) как составная часть жизненного цикла разработки системы. Контроль кода может проводиться компетентным внутренним персоналом или третьими сторонами. В отношении веб-приложений, которые находятся в публичном доступе, также подлежат применению дополнительные меры по защите от появляющихся угроз и уязвимостей после внедрения.
9)    Следует обеспечить защиту общедоступных веб-приложений от известных атак (а также регулярно учитывать новые угрозы и уязвимости) одним из следующих методов:
• проверять приложение на наличие уязвимостей с использованием методов ручного или автоматического анализа защищенности приложений не реже одного раза в год, а также после внесения изменений.
• Перед общедоступным веб- приложением должно быть установлено техническое средство для постоянной проверки всего трафика (например, веб-брандмауэр) с целью обнаружения и предупреждения веб- атак.
10)    Следует проводить внешнее и внутреннее сканирование сети на наличие уязвимостей не реже одного раза в квартал, а также после внесения значительных изменений (например, установки новых системных компонентов, изменения топологии сети, изменения правил межсетевых экранов, обновления продуктов).
11)    Небезопасная передача данных.
•    Изучить политики и процедуры разработки ПО и опросить ответственных сотрудников, чтобы убедиться, что при программировании предпринимаются меры по предотвращению небезопасных коммуникаций, обеспечивающие надлежащую аутентификацию и шифрование всех критичных коммуникаций
Приложения, которые не шифруют надлежащим образом сетевой трафик с применением стойких криптографических методов, подвергаются повышенному риску взлома и утечки данных держателей карт.
12)    Следует проводить внешний тест на проникновение не реже одного раза в год, а также после любой значительной модификации или обновления инфраструктуры и приложений (например, обновления операционной системы, добавления подсети, установки веб-сервера).
13)    Следует проводить внутренний тест на проникновение не реже одного раза в год, а также после любой значительной модификации или обновления инфраструктуры и приложений (например, обновления операционной системы, добавления подсети, установки веб-сервера).
14)    Межсайтовый скриптинг (XSS).
•    Изучить политики и процедуры разработки ПО и опросить ответственных сотрудников, чтобы убедиться, что при программировании предпринимаются меры по предотвращению межсайтового скриптинга (XSS), в том числе:
a)    проверка всех параметров перед их включением в код;
b)    использование контекстно-зависимого изолирования.
Межсайтовый скриптинг (XSS) происходит, когда приложение отправляет предоставленные пользователем данные в веб-браузер без предварительной проверки или шифрования этого содержимого. Межсайтовый скриптинг позволяет злоумышленникам выполнять сценарии в браузере жертвы для захвата сеансов пользователя, изменения вида веб- сайтов, возможного внедрения червей и т.д
15)    Подделка межсайтовых запросов (CSRF).
•    Изучить политики и процедуры разработки ПО и опросить ответственных сотрудников, чтобы убедиться, что при программировании предпринимаются меры по предотвращению подделки межсайтовых запросов и обеспечению того, чтобы приложения не полагались на учетные данные для проверки подлинности и токены, автоматически отправляемые браузерами.
В случае подделки межсайтовых запросов (CSRF) браузер жертвы отправляет предварительно авторизованный запрос в уязвимое веб-приложение, что позволяет злоумышленнику совершить любые действия, которые может совершить жертва (например, обновление сведений о счете, совершение покупок или даже вход в приложение).
16)    Противодействие взлому механизмов аутентификации и управления сеансами.
•    Изучить политики и процедуры разработки ПО и опросить ответственных сотрудников, чтобы убедиться, что при программировании предпринимаются меры по противодействию взлому механизмов аутентификации и управления сеансами, в том числе:
а) сеансовые токены (например, cookies) помечаются как «безопасные»;
б) отсутствие идентификатора сеанса в URL-адресе;
в) внедрение соответствующих ограничений по длительности сеанса и ротации идентификаторов после успешного входа.
Безопасная аутентификация и управление сессией не позволят злоумышленнику взломать подлинные учетные данные, ключи или сеансовые токены, с помощью которых можно выдать себя за авторизованного пользователя.

17)    Каждый планируемый процесс новой услуги партнеров должны внедряется согласованно с Управлением Информационной Безопасности «ЕОПЦ». Запуск услуги в эксплуатацию без предварительного согласования с Управлением ИБ запрещается, в случае обнаружения не согласованности, Управление ИБ оставляет за собой право отключения данной услуги без предупреждения.
18)    При хранении и передачи критичных карточных данных (PAN), Управление ИБ будет организовывать проверки на соответствие требованиям безопасности согласно 12 детализированных требований стандарта PCI-DSS, и по выявленным несоответствиям Управление ИБ предоставляет предписание на исправление недостатков с установленным сроком выполнения, а в случае не выполнения требований и предписаний в установленный срок, Управление ИБ оставляет за собой право отключения услуги по согласованию с руководством.

Требования ИБ, компаниям работающие с международными платёжными системами Visa и MasterCard.
Все компании, работающие с международными платёжными системами Visa и MasterCard обязаны пройти сертификацию по стандарту PCI-DSS. В зависимости от количества обрабатываемых транзакций, каждой компании присваивается определённый уровень с соответствующим набором требований, которые они должны выполнять. В рамках требований стандарта предусматриваются ежегодные аудиторские проверки компаний, а также ежеквартальные сканирования сетей.

Дополнительные требования ИБ для поставщиков услуг хостинга с общей средой
Согласно требованиям PCI-DSS 12.8 и 12.9 все поставщики услуг, имеющие доступ к данным держателей карт (включая поставщиков услуг хостинга с общей средой) должны выполнять требования PCI-DSS. В дополнение к этому, требование 2.6 говорит о том, что поставщики услуг хостинга с общей средой должны обеспечивать безопасность сред и данных каждого клиента. Таким образом, поставщики услуг с общей средой (хостинг — провайдеры) должны дополнительно выполнять требования, перечисленные в приложениях PCI-DSS.
Исходя из выше изложенного, если поставщики услуг, имеющие доступ к данным держателей карт (включая поставщиков услуг хостинга с общей средой) не имеют актуальный сертификат соответствия стандарту PCI-DSS, «ЕОПЦ» оставляет право отключения услуги до предоставления сертификата соответствия стандарту PCI-DSS (Сертификат не должен быть просроченным).

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Введите псоедовательность цифр *