Требование 11.2 PCI DSS о внешнем и внутреннем сканировании на наличие уязвимостей распространяется на веб-сайты ЭТ, так как они входят в среду ДДК. Если ТСП передает веб-сайт на размещение и (или) под контроль стороннего поставщика услуг хостинга на подрядной основе, у ТСП может не быть возможности контролировать процесс сканирования. Таким ТСП в отношении услуг хостинга от сторонних организаций рекомендуется следующее:
убедиться, что ASV-сканирование проводится в соответствии с требованием 11.2 PCI DSS. Если веб-сайт с интернет-магазином ТСП размещен на хостинге с разделяемой средой (несколько веб-сайтов на общем сервере), для сканирования существует два варианта:o поставщик услуг хостинга может самостоятельно проходить ASV-сканирование и предоставлять ТСП документы, подтверждающие соответствующее сканирование;
o поставщик услуг хостинга может проходить ASV-сканирование в рамках ASV-сканирования каждого из своих клиентов-ТСП.
■ В любом случае, именно ТСП обязано следить за тем, чтобы вся его инфраструктура была корректно внесена в область проверки и успешно проходила такую проверку в рамках ежеквартального ASV-сканирования.
5.6 Рекомендации по платежным приложениям
При передаче ДДК внутри сети ТСП (например, в точках входа и выхода ДДК) следует использовать протоколы SSL/TLS. Вследствие динамичности среды ЭТ и частых изменений на веб-сайтах и в веб-приложениях, а также в связи с тем, что традиционные МЭ могут не иметь возможность проверять шифрованный трафик, рекомендуется использовать пакетные веб-фильтры прикладного уровня (web-application firewall) либо дополнительные средства обнаружения вторжений. Если ТСП разрабатывает платежные приложения или приложения типа «корзина покупок» самостоятельно, ему рекомендуется придерживаться стандарта PA-DSS, т. к. это упрощает соблюдение требований PCI DSS. Рекомендуется изучить возможность использования сторонних платежных приложений, имеющих сертификат соответствия PA-DSS и включенных в список платежных приложений, одобренных Советом PCI SSC и отмеченных, как «допущенные к повторной реализации». Текущий список одобренных приложений доступен на сайте Совета PCI SSC.o Следует учесть, что некоторые МПС требуют, чтобы при использовании сторонних платежных приложений, выбирались только те, которые сертифицированы по PA-DSS. ТСП следует проконсультироваться с эквайером или представительством МПС, чтобы определить перечень применимых требований.
o Корректная установка платежного приложения является критичной для безопасности ДПК. В целях обеспечения выполнения требований PCI DSS при реализации платежного приложения, необходимо, во время его установки и настройки соблюдать «Руководство по внедрению PA-DSS» (предоставляемое разработчиком).
■ Следует регулярно проверять все ссылки (по URL, во встроенных фреймах, API) с сайта ТСП на платежный шлюз чтобы убедиться, что в ссылки не вносились изменения с целью перенаправления на несанкционированные адреса.
5.7 Организация обучения всех сотрудников
Следует убедиться, что все сотрудники обучены безопасному использованию систем и соблюдению установленных процедур. В программу обучения должно входить повышение осведомленности о потенциальных угрозах безопасности и плане действий при возникновении подозрений на нарушение безопасности. Технический персонал должен иметь навыки управления технологиями защиты информации, в том числе МЭ, цифровыми сертификатами, шифрованием SSL. Следует обучить весь персонал следить за основными вопросами ИБ, например, приемами социальной инженерии, которыми пользуются злоумышленники для получения доступа к ДДК.5.8 Прочие рекомендации
Следует назначить специальных сотрудников, которые будут следить за всеми новостями МПС и других веб-сайтов, посвященных информационной безопасностями, и сообщать обо всех новых угрозах. Следует рассмотреть возможность установки дополнительного МЭ между сервером приложений и сервером БД для снижения рисков, исходящих от подключенного к Интернету веб-сервера Количество отображений номера карты следует свести к минимуму, необходимому для оформления клиентом покупки. Например, после проверки номера карты, в квитанции об оплате или товарном чеке для клиента рекомендуется не показывать полный номер карты.5.9 Рекомендации по повышению осведомленности клиентов в вопросах безопасности
Необходимо повышать осведомленность клиентов в вопросах безопасности для того, чтобы защитить их ДПК при оплате покупок в интернет-магазинах, например, можно рекомендовать следовать следующим правилам:
Не использовать для транзакций ЭТ общедоступные, недоверенные компьютеры. Использование таких компьютеров может быть небезопасно, и на них может быть установлено программное обеспечение, перехватывающее ДПК при вводе. Не совершать покупок при подключении к незащищенной беспроводной сети (например, при подключении своего ноутбука к общедоступной беспроводной сети), если на компьютере нет персонального МЭ. При вводе ДПК в компьютер в общественных местах убедиться в отсутствии подсматривающих. Устанавливать на свой персональный компьютер актуальные обновления безопасности. Перед подключением к Интернету обязательно убедиться, что на компьютере работает антивирусное ПО с актуальной базой вирусных сигнатур и определений. Перед вводом ДПК обязательно убедиться в наличии признаков защиты подключения к веб-странице. Признаками такой защиты могут быть, например, префикс HTTPS перед адресом сайта, значок в виде замочка в верхней или нижней части браузера, зеленая подсветка адресной строки, значок пломбы. Использовать надежные пароли, которые трудно отгадать (например, не использовать в качестве пароля свой день рождения или свое имя). Хранить свои пароли в недоступном месте, например, не записывать их на листках бумаги, прикрепленных к компьютеру (особенно находясь в общественных местах), и не хранить их в файле на компьютере, который находится в общем доступе с другими пользователями.Приложение A. Применение требований PCI DSS к инфраструктуре ЭТ
В данном разделе приведены общие рекомендации для ЭТ о порядке реализации основных категорий требований PCI DSS.
В целом, требования PCI DSS распространяются и на инфраструктуры ЭТ как относящиеся к ТСП, так и на используемые ими ПЦ. Чтобы понять, какие из требований относятся к ТСП, а какие — к ПЦ ЭТ, ТСП следует определить и задокументировать (например, в виде обычной схемы) свою инфраструктуру ЭТ, включив в нее все задействованные системы и все ДДК, передаваемые сторонним организациям. Независимо от выбранного ТСП решения ЭТ и от объема ответственности, переданного сторонней организации ТСП на подрядной основе, между ТСП и ПЦ ЭТ остается подключение, которое может быть скомпрометировано. Наличие четкого представления о своей инфраструктуре ЭТ и о потоках ДДК при ведении регулярного мониторинга своих систем, упрощает ТСП своевременное обнаружение несанкционированных изменений.
Примечание. Настоящее приложение носит исключительно рекомендательный характер. Следует помнить, что должны выполняться ВСЕ применимые требования PCI DSS. Данные рекомендации определяют лишь часть потенциальных вопросов, которые следует учитывать при формировании инфраструктуры ЭТ.
Рекомендации в данном приложении не заменяют собой, не отменяют и не дополняют требования PCI DSS. Все рекомендации носят лишь справочный характер.
Требования PCI DSS | Рекомендации для ЭТ | |
Построение и обслуживание безопасной сети | 1. Установить и обеспечить функционирование МЭ для защиты ДДК | Необходимо установить МЭ между веб-сервером и сетью Интернет, а также между веб-сервером и внутренней сетью, в которой находятся серверы приложений и БД. МЭ и DMZ должны быть настроены таким образом, чтобы на веб-сервер поступал только разрешенный трафик из сети Интернет, а с веб-сервера во внутреннюю частную сеть поступал только необходимый трафик. Интернет-подключения ко внутренним узлам и сетям в обход DMZ должны быть строго запрещены. Системные компоненты, на которых хранятся ДДК, необходимо размещать во внутреннем сегменте сети, отделенном от DMZ и других недоверенных сетей. |
2. Не использовать пароли и другие системные настройки безопасности, заданные производителем по умолчанию | При использовании услуг на подрядной основе возникает множество уровней административного доступа и точек доступа к ДДК. Все ответственные стороны и владельцы систем должны быть идентифицированы и документально зафиксированы. Для определения и документирования сфер ответственности каждой из сторон, рекомендуется воспользоваться Приложением B настоящего документа. | |
Защита ДДК | 3. Обеспечить безопасное хранение ДДК | Задокументируйте все точки присутствия ДДК в инфраструктуре ЭТ (а также меры их защиты), где они хранятся, обрабатываются и передаются, включая ДДК, находящиеся у поставщиков услуг (в т. ч. хостинга). Сбору и хранению подлежит только минимальное количество данных, необходимое для оформления транзакции ЭТ, при этом период их хранения не должен превышать время, необходимое для бизнес-процессов ТСП. Не допускается использовать или позволять использовать технологии ЭТ, при которых ДДК и иная конфиденциальная информация хранятся в открытом виде в файлах cookies или временных файлах. |
4. Использовать шифрование при передаче ДДК через сети общего пользования | При передаче ДДК по сетям общего пользования (например, по сети Интернет) необходимо использовать шифрование через SSL, VPN или IPSec — например, при передаче между клиентом, веб-сервером ТСП и (или) платежными шлюзами, а также между ТСП и различными поставщиками услуг хостинга. Аналогичное шифрование можно применять при передаче критичной информации (например, учетных записей, данных о клиенте или учетной карточки клиента), а также при передаче ДДК по внутренней сети ТСП. Примечание. Обычные МЭ могут не поддерживать возможность анализа шифрованного трафика. Если адрес и порт назначения соответствуют критериям, указанным в политике МЭ, трафик будет пропущен. Для анализа содержимого шифрованного трафика рекомендуется использовать пакетные веб-фильтры прикладного уровня или технологии обнаружения вторжений. Если решение ЭТ поддерживает функцию чата или другие технологии обмена сообщениями, следует предупредить клиента (перед началом сеанса) — например, с помощью предупреждающего сообщения — что клиенту не рекомендуется отправлять ДДК по незащищенным каналам связи. В случае сервис-ориентированных решений следует убедиться, что связующее ПО для обработки сообщений использует протоколы SSL/TLS (или иные защитные меры согласно требованию 4.1 PCI DSS). |
Требования PCI DSS | Рекомендации для ЭТ | |
Поддержка программы управления уязвимостями | 5. Использовать и регулярно обновлять антивирусное ПО | Так как новые вирусы и вредоносное ПО появляются каждый день и используют все более изощренные методы обхода защитных мер, крайне важно своевременно обновлять антивирусное ПО. Антивирусная система должна регистрировать в журналах события, включая, среди прочего: Прежде чем разворачивать антивирусную систему в производственной среде, рекомендуется проверить ее в тестовой и (или) непроизводственной среде и посмотреть, не мешают ли антивирусные механизмы нормальному выполнению функций ЭТ. |
6. Разрабатывать и поддерживать безопасные системы и приложения | Приложения типа «корзины покупок» и другие платежные приложения ЭТ должны: Чтобы сделать веб-приложение неуязвимым для атак, следует придерживаться рекомендаций по безопасному программированию и разработке программ. Если приложения, приобретенные у сторонних организаций или разработанные самостоятельно, не имеют сертификата соответствия PA-DSS, они должны быть включены в область аудита PCI DSS, чтобы убедиться, что они функционируют в соответствии с требованиями PCI DSS. Однако и приложения, сертифицированные по PA-DSS, включаются в область оценки PCI DSS, чтобы убедиться в их правильной установке и использовании в соответствии с «Руководством по внедрению PA-DSS» и стандартом PCI DSS. Следует убедиться, что установлены самые последние версии ПО и что обновления безопасности, выпускаемые разработчиком, устанавливаются оперативно, как определено в требовании 6.1 PCI DSS. Это касается приложений типа «корзин покупок», веб-браузеров, операционных систем, а в случае сервис-ориентированных архитектур — связующего программного обеспечения для обработки сообщений, и сервисной шины предприятия. | |
Внедрение строгих мер контроля доступа | 7. Предоставлять доступ к ДДК только по служебной необходимости | Следует свести к минимуму количество сотрудников, которым позволено видеть ДПК. Наличие прав на просмотр незашифрованных ДПК не означает того, что сотрудники ТСП должны их видеть для выполнения своих служебных обязанностей. Многие поставщики услуг не предоставляют незашифрованные данные своим клиентам-ТСП, если только сам клиент не попросит об этом. Следует убедиться, чтобы пароли к учетным записям пользователей на всех компонентах системы ЭТ (включая, среди прочего веб-приложения, серверы, компоненты сетевой архитектуры — например, сервис-ориентированная архитектура) не предоставляют прав системного администрирования и чтобы любой административный доступ предоставлялся только пользователям, выполняющим функции администрирования в рамках своих служебных обязанностей. |
8. Назначить уникальный идентификатор каждому лицу, имеющему доступ к компьютеру | Не использовать простые пароли, такие как «пароль123» или название магазина ТСП. Вместо паролей рекомендуется использовать парольные фразы из двух и более слов, которые имеют смысл, но которые нелегко угадать. В состав таких парольных фраз рекомендуется включать буквы верхнего и нижнего регистров, цифры и спецсимволы. | |
9. Ограничить физический доступ к ДДК | У ТСП может не быть доступа к физической инфраструктуре, если оно пользуется услугами хостинга сторонней организации; в таких случаях в соглашениях со сторонними организациями следует оговаривать физическую защиту их помещений. Необходимо уничтожать электронные и бумажные носители (например, распечатки с указанием ДПК), которые уже не потребуются для служебных целей или в рамках выполнения требований законодательства. | |
Требования PCI DSS | Рекомендации для ЭТ | |
Регулярный мониторинг и тестирование сети | 10. Контролировать и отслеживать любой доступ к сетевым ресурсам и ДДК | Журналы, фиксирующие события на веб-серверах и на веб-сайтах, могут быть источником информации о подозрительной активности (как, например, ввод недопустимых данных в форму). Следует просматривать журналы событий веб-серверов и приложений типа «корзина покупок», а также ответы системы на ввод некорректных данных, чтобы удостовериться, чтобы ДДК, после внесения в систему текущих изменений, не попадали в журналы событий или сообщения об ошибках и не отправлялись никому кроме ПЦ. ТСП и всем сторонним организациям следует предусмотреть возможность обмена журналами событий, которыми пользуются стороны для наблюдения за взаимодействием друг с другом. В соглашениях со сторонними организациями следует указать, что в случае необходимости, например, при расследовании инцидентов безопасности, стороны будут обеспечивать доступ к журналам событий (имеющим отношение к предоставляемым услугам). |
11. Регулярно проверять системы и процессы, обеспечивающие безопасность | Даже если ТСП полностью передало сторонней организации все ДДК на подрядной основе, эти данные все же могут по-прежнему быть подвержены риску из-за уязвимостей на сервере ТСП. Ежеквартальное внешнее ASV-сканирование и контроль целостности файлов могут помочь в обеспечении доказательств несанкционированных изменений системы, которые позволят ТСП привести ее к состоянию, при котором она была доверенной. Проверить веб-приложение на устойчивость к атакам можно также с помощью серьезного тестирования на проникновение. Приложения, разработанные для ТСП под заказ, важно также регулярно тестировать веб-сайт на наличие уязвимостей в приложениях и вести учет обнаруженных и исправленных проблем безопасности. | |
Поддержание политики ИБ | 12. Разработать и поддерживать политику ИБ для всего персонала организации | Следует разработать политику ИБ и довести до сведения каждого его обязанности. Согласно требованию 12.8 PCI DSS: Следует тщательно изучать соглашения о качестве услуг, предоставляемых сторонними организациями и поставщиками услуг хостинга. Следует максимально изучить историю деятельности потенциальных поставщиков, обращая особое внимание на следующее: |
Приложение B. Ответственность ТСП и сторонних организаций за соблюдение стандарта PCI DSS
Если ТСП само контролирует свою инфраструктуру ЭТ, оно отвечает за обеспечение выполнения всех требований стандарта PCI DSS. Соответственно, если ТСП передает всю инфраструктуру ЭТ сторонним организациям на подрядной основе, то к нему предъявляется минимальный набор требований PCI DSS (12.8 и мониторинг состояния системы, согласно настоящей Дополнительной информации).
Настоящее приложение представляет собой пример опросника для ТСП с инфраструктурой ЭТ на полной или частично подрядной основе (частично подрядная основа описана в Разделе 3.5 настоящего документа) и может быть использовано для разделения, в рамках выбранного решения ЭТ, ответственности за выполнение требований стандарта PCI DSS между ТСП и поставщиком услуг. ТСП могут использовать данное приложение для указания в первых двух колонках стороны, ответственной за выполнение определенного требования PCI DSS, а в третьей колонке указывать информацию, подтверждающую выполнение.
Заполнение приведенной анкеты не является требованием и оставляется на усмотрение ТСП и сторонней организации.
Требования PCI DSS | Ответственность ТСП | Ответственность сторонней организации | Доказательства выполнения требования PCI DSS, представленные сторонней организацией |
Построение и обслуживание безопасной сети | 1. Установить и обеспечить функционирование МЭ для защиты ДДК | ||
2. Не использовать пароли и другие системные настройки безопасности, заданные производителем по умолчанию | |||
Защита ДДК | 3. Обеспечить безопасное хранение ДДК | ||
4. Использовать шифрование при передаче ДДК через сети общего пользования | |||
Поддержка программы управления уязвимостями | 5. Использовать и регулярно обновлять антивирусное ПО | ||
6. Разрабатывать и поддерживать безопасные системы и приложения | |||
Внедрение строгих мер контроля доступа | 7. Предоставлять доступ к ДДК только по служебной необходимости | ||
8. Назначить уникальный идентификатор каждому лицу, имеющему доступ к компьютеру | |||
9. Ограничить физический доступ к ДДК | |||
Регулярный мониторинг и тестирование сети | 10. Контролировать и отслеживать любой доступ к сетевым ресурсам и ДДК | ||
11. Регулярно проверять системы и процессы, обеспечивающие безопасность | |||
Поддержание политики ИБ | 12. Разработать и поддерживать политику ИБ для всего персонала организации |
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 |
