Шпаргалка по соблюдению требований стандарта касаемо беспроводных сетей.
Не так давно в сети развернулась дискуссия относительно противоречивости мнений аудиторов различных компаний, толчком к которой явилось мнение о передаче номеров платежных карт в открытом виде во внутренней сети компании. Тема оказалось достаточно интересной и её подхватили авторитетные в области информационной безопасности специалисты, что ещё больше «подлило масла в огонь», а вместе с тем добавило замешательства специалистам относительно выполнений требований стандарта PCI DSS. Попробуем разобраться, опираясь на официальные документы консула, в ставшем «камнем преткновения» вопросе.
При использовании небезопасных (передающих логин и пароль пользователя в открытом виде, таких как: telnet, ftp), всегда имеются риски компрометации серверов и данных платежных карт, которые в них обрабатываются. Подобные риски компрометации имеются и при использовании ненужных для бизнеса протоколов и сервисов, которые также могут содержать уязвимости, т.к. их никто не исправляет (например, потому что сервис никто не использует и не администрирует). Данные виды рисков, в соответствии с требованиями стандарта, каждая организация должна осознавать и стараться минимизировать.
Выполнение требования 1.1.5 направлено на решение этой задачи и включает в себя: документирование всех необходимых для ведения бизнеса протоколов и сервисов, а также обоснование их применения. Небезопасные протоколы также можно использовать, но только в случае если разработаны и описаны защитные меры при их использовании.Часто приходится сталкиваться с неправильной интерпретацией требований 8.1, 8.5.8 и 8.5.16.b стандарта PCI DSS и адресуемых ими рисков:
- «в стандарте написано, что нельзя использовать групповые идентификаторы для выполнения административных задач и других критичных функций, но наши пользователи не имеют полномочий на изменение данных, а значит можно под одной учетной записью работать»;
- «в стандарте написано идентификаторы пользователей, а к администраторам систем эти требования не относятся»;
- «в стандарте написано, что нельзя использовать встроенные идентификаторы, то есть нельзя пользоваться учетной записью oracle или root». Как следствие, непонимание сути требования приводит к неправильной его реализации.
Эта статья является продолжением начатой темы про соответствие стандарту (PCI compliance) и проверкой соответствия (PCI Validation).
Итак, начнем с области применения стандарта PCI DSS. Несмотря на то, что исходно стандарт PCI DSS разрабатывался в основном для крупных торгово-сервисных организаций (миллионы транзакций в год) и сервис-провайдеров и нацелен на снижение рисков утечки данных «чужих» платежных карт в рамках, в основном, процессов авторизации, его требования должны выполнять любые компании, в которых происходит обработка, хранение или передача как минимум PAN.
Данную позицию PCI SSC (организация, ответственная за разработку стандарта PCI DSS) изложила в ответе на один из вопросов аудиторов Информзащиты в своем FAQ.
Сложности при выполнении требований стандарта испытывают банки, которые занимаются выпуском платежных карт, их системы, обеспечивающие выпуск карт, особенно если они интегрированы с АБС, в большинстве случаев разрабатывались без оглядки на требования PCI DSS такие, как шифрование PAN, протоколирование доступа к PAN и т.п. Доработка существующих систем (или замена, что может быть даже дешевле) под выполнение требований по безопасности — задача затратная и по времени, и по ресурсам и для бизнеса не совсем очевидная особенно сейчас, в условиях мирового финансового кризиса.
