Стандарт PCI DSS 1_1 (1027417), страница 3
Текст из файла (страница 3)
Ключи дешифрования не должны бытьпривязаны к пользовательским учетным записям.3.5 Ключи, использующиеся для шифрования данных платежных карт, должны быть защищены отнесанкционированного разглашения и ненадлежащего использования:3.5.1 Доступ к ключам должен быть предоставлен минимальному количеству сотрудников,которым он необходим3.5.2 Должно выполняться безопасное хранение ключей. Количество мест хранения ключейдолжно быть минимизировано3.6 Должны быть полностью документированы и реализованы все процессы и процедуры управленияключами для ключей, использующихся при шифровании данных платежных карт, включаяследующие:3.6.1 Генерация стойких ключей3.6.2 Безопасное распределение ключей3.6.3 Защищенное хранение ключей3.6.4 Периодическая замена ключей:• в соответствии с рекомендациями и необходимостью связанного приложения (например,смена ключей шифрования); предпочтительно автоматически;• по крайней мере ежегодно.3.6.5 Уничтожение устаревших ключей3.6.6 Разделение ключевой информации между несколькими лицами и удвоенный контроль заключами (чтобы для восстановления ключа требовалось присутствие двух или трехчеловек, каждый из которых знает свою часть ключа)3.6.7 Предотвращение несанкционированной подмены ключей3.6.8 Замена скомпрометированных или заподозренных в компрометации ключей3.6.9 Отзыв истекших или недействительных ключей3.6.10 Требование подписания соглашения сотрудниками, ответственными за хранение ииспользование ключей, в котором подтверждается, что они понимают обязанности ипринимают ответственность по обеспечению защищенности ключей.Требование 4: Должно обеспечиваться шифрование данных платежных карт,передаваемых по сетям общего пользованияКритичная информация должна шифроваться при передаче по сетям, в которых великавероятность перехвата, модификации и изменения маршрута следования данных при их передаче.4.1 Для защиты критичных данных платежных карт при их передаче по сетям общего пользованиядолжна использоваться надежная криптография и протоколы, обеспечивающие защитупередаваемых данных, например, SSL/TLS, IPSEC.Примерами сетей общего пользования, которые находятся в области действия требованийстандарта PCI DSS, являются Интернет, Wi-Fi (IEEE 802.11x), GSM и GPRS.4.1.1 Передаваемые в беспроводных сетях данные платежных карт должны шифроваться сиспользованием технологий WPA или WPA2, IPSEC VPN или SSL/TLS.
Для обеспеченияконфиденциальности и контроля доступа к беспроводной сети никогда не следуетполагаться исключительно на WEP. В случае если используется WEP, необходимо:• в качестве минимально допустимой длины ключа шифрования использовать 104 бит, авектора инициализации – 24 бит• использовать его только совместно с технологией WPA (или WPA22), VPN или SSL/TLS• проводить ежеквартальную замену WEP-ключей (если позволяет технология –автоматически)• заменять WEP-ключи при любых изменениях в составе персонала, обладающегодоступом к ключам• ограничивать доступ на основе MAC-адресов4.2 Никогда не должна выполняться отправка номеров PAN в незашифрованном виде по электроннойпочте.2Прим.
ИЗ. Вероятно, опечатка в стандарте. WPA не может быть использован одновременно с WEP. Скореевсего имелось в виду совместное использование WEP и VPN или SSL|TLS.Copyright 2008 PCI Security Standards Council LLCPayment Card Industry (PCI) Data Security StandardСтандарт безопасности данных индустрии платежных картПеревод ЗАО НИП «Информзащита»www.infosec.ru+7 (495) 9802345Апрель 2008Страница 8Реализация программы управления уязвимостямиТребование 5: Должно использоваться и регулярно обновляться антивирусноепрограммное обеспечениеБольшое количество вирусов проникает в сеть компании в результате обмена сообщениямиэлектронной почты.
На всех системах, которые подвержены воздействию вирусов, должно бытьустановлено антивирусное программное обеспечение для их защиты от вредоносногопрограммного обеспечения.5.1 Антивирусное программное обеспечение должно быть установлено на всех системах,подверженных воздействию вирусов (персональных компьютерах и серверах).К системам, подверженным воздействию вирусов, обычно не относят операционные системына базе ОС UNIX или мейнфреймы.5.1.1 Антивирусное программное обеспечение должно обладать способностью обнаружения,удаления и защиты от различных видов вредоносного программного обеспечения(включая spyware, adware)5.2 Должна быть включена постоянная антивирусная защита, механизмы обеспечения антивируснойзащиты должны регулярно обновляться и обладать возможностью генерации журналоврегистрации событий.Требование 6: Должна обеспечиваться безопасность при разработке и поддержкесистем и приложенийЗлоумышленники используют уязвимости в системе защиты для получения привилегированногодоступа в компьютерные системы.
Большинство уязвимостей устраняются с помощьюобновлений безопасности, предоставляемых производителями. Для защиты от эксплуатацииуязвимостей внутренними и внешними злоумышленниками, а также вирусами на всех системахдолжны быть установлены последние выпущенные приемлемые обновления безопасности.Приемлемые обновления безопасности – это такие обновления, которые были в достаточнойстепени проанализированы и протестированы, чтобы определить, что их установка не приведетк конфликтам с действующими защищенными конфигурациями.
Если выполняется разработкаприложений внутри организации, большого количества уязвимостей можно избежать, используястандартные процессы разработки систем и приемы безопасного программирования.6.1 Для всех системных компонентов и программного обеспечения должны быть установлены самыепоследние обновления безопасности, предоставленные производителями. Обновлениябезопасности, относящиеся к используемым системам, должны быть установлены в течениеодного месяца с момента их выпуска.6.2 Должен существовать процесс идентификации вновь обнаруженных уязвимостей безопасности(например, подписка на рассылки, связанные с информационной безопасностью и обнаружениемуязвимостей, свободно доступные в сети Интернет). Должно выполняться обновление стандартовконфигурирования с целью устранения новых обнаруженных уязвимостей.6.3 Разработка программного обеспечения должна производиться с учетом накопленного в даннойотрасли опыта и учитывать вопросы обеспечения информационной безопасности на всех стадияхпроцесса разработки.6.3.1 До внедрения в среду эксплуатации должно выполняться тестирование всех обновленийбезопасности, а также изменений в конфигурации систем и программного обеспечения6.3.2 Должны быть разделены среды разработки, тестирования и эксплуатации6.3.3 Должно существовать разделение обязанностей в средах разработки, тестирования иэксплуатации6.3.4 Для тестирования или разработки не должно использоваться данных из средыэксплуатации (реальных номеров PAN)6.3.5 Должно выполняться удаление тестовых учетных записей и данных до внедрения в средуэксплуатации6.3.6 Учетные записи, имена пользователей и пароли в разработанном программномобеспечении должны быть удалены до внедрения этого программного обеспечения всреду эксплуатации или его передачи заказчикуCopyright 2008 PCI Security Standards Council LLCPayment Card Industry (PCI) Data Security StandardСтандарт безопасности данных индустрии платежных картПеревод ЗАО НИП «Информзащита»www.infosec.ru+7 (495) 9802345Апрель 2008Страница 96.3.7 Для идентификации потенциальных уязвимостей в разработанном программномобеспечении должен выполняться анализ кода перед запуском этого ПО в эксплуатациюили его передачей заказчику6.4 При внесении любых изменений в системы и программное обеспечение необходимо следоватьпроцедурам управления изменениями.
Эти процедуры должны включать:6.4.1 Документирование влияния, оказываемого изменением6.4.2 Утверждение руководством6.4.3 Тестирование работоспособности6.4.4 Процедуры отката6.5 Все web-приложения должны разрабатываться с учетом рекомендаций по программированиюзащищенных web-приложений, например, рекомендаций OWASP.
С целью идентификацииуязвимостей, связанных с ошибками программирования, должен выполняться анализ кодаразработанных приложений, при этом должно выполняться предотвращение следующихраспространенных уязвимостей:6.5.1 Отсутствие проверки корректности вводимых данных6.5.2 Уязвимости механизмов контроля доступа (например, злоумышленное использованиеидентификаторов пользователей)6.5.3 Уязвимости подсистемы аутентификации и управления сеансами (использование учетныхданных и сеансовых cookie)6.5.4 Атаки типа Cross-Site Scripting (XSS)6.5.5 Переполнение буфера6.5.6 Инъекции (например, SQL-инъекции)6.5.7 Некорректная обработка ошибок6.5.8 Небезопасное хранение6.5.9 Отказ в обслуживании6.5.10 Небезопасное управление конфигурациями6.6 Все web-приложения должны быть защищены от известных атак, используя один из приведенныхниже методов:• Выполнениеанализакодавсехразработанныхприложенийорганизацией,специализирующейся в области безопасности приложений, на предмет наличияраспространенных уязвимостей.• Установка межсетевого экрана прикладного уровня перед web-приложениями.Требование 6.6 до 30 июня 2008 г.
носит рекомендательный характер, после чего становитсяобязательным.Реализация мер по строгому контролю доступаТребование 7: Доступ к данным платежных карт должен быть ограничен всоответствии со служебной необходимостьюДанное требование обеспечивает то, что доступ к критичным данным может бытьосуществлен только авторизованными сотрудниками.7.1 Доступ к вычислительным ресурсам и данным платежных карт должен быть предоставлен толькотем сотрудникам, которым он необходим для выполнения должностных обязанностей.7.2 Для многопользовательских систем должен быть реализован механизм предоставления доступа,ограничивающий доступ по принципу необходимого знания (need-to-know), запрещающий любойдоступ, не разрешенный явно.Требование 8: Каждому лицу, имеющему доступ к вычислительным ресурсам,должен быть назначен уникальный идентификаторНазначение уникального идентификатора каждому лицу с правом доступа обеспечитвозможность выполнения действий над критичными данными и системами авторизованнымипользователями и отслеживания действий, выполненных конкретными авторизованнымипользователями.Copyright 2008 PCI Security Standards Council LLCPayment Card Industry (PCI) Data Security StandardСтандарт безопасности данных индустрии платежных картПеревод ЗАО НИП «Информзащита»www.infosec.ru+7 (495) 9802345Апрель 2008Страница 108.1 Каждому пользователю должно быть назначено уникальное имя пользователя до предоставлениядоступа к системным компонентам или данным платежных карт8.2 В дополнение к назначению уникального идентификатора для всех пользователей должениспользоваться по крайней мере один из следующих механизмов аутентификации:• Пароль• Устройства аутентификации (например, SecureID, сертификаты или открытые ключи)• Биометрия8.3 Для предоставления удаленного доступа в сеть служащим компании, администраторам илитретьим лицам должна быть реализована двухфакторная аутентификация.