По материалам статьи автора, опубликованной в журнале «ПЛАС» № 7 (183) ’2012

Представляю вниманию читателей вторую статью цикла, посвященного обзору индустрии платежных карт и системе сертификации PCI DSS. В ней пойдет речь об определении области применимости требовании стандарта в инфраструктуре компании, а также о методах ее сужения — с целью минимизации затрат на приведение инфраструктуры в соответствие требованиям стандарта PCI DSS.

Область применимости требований стандарта PCI DSS

В предыдущей статье цикла мы рассмотрели структуру индустрии платежных карт и выяснили, для каких именно ее участников обязательно соответствие требованиям международного стандарта безопасности данных индустрии платежных карт — PCI DSS. Кроме того, там же были описаны способы подтверждения соответствия и методика их выбора.

В сегодняшнем материале мы сосредоточимся на отдельно взятой компании и рассмотрим ее информационную инфраструктуру, вовлеченную в процесс обработки карточных данных.

Прежде всего, согласимся со вполне очевидным тезисом о том, что информационная инфраструктура по своей природе гетерогенна и многослойна. Существует уровень бизнес-приложений, которые для работы используют файлы и базы данных. Последние — вместе с приложениями — работают на серверах, которые, в свою очередь, опираются на уровень сетевого взаимодействия. Сегодня все чаще к такой структуре добавляется еще один уровень — уровень среды виртуализации.

Обеспечение информационной безопасности — процесс комплексный и многофакторный. Когда стоит задача защитить определенный вид данных, в нашем случае — данных о держателях платежных карт, нельзя ограничиться применением защитных мер лишь на каком-то одном отдельном уровне. Так, если мы внедрим межсетевые экраны и забудем о безопасности web-приложений, то злоумышленник непременно воспользуется такой оплошностью. Точно также, если будут защищены приложения и сетевая инфраструктура, но возможность прямого взаимодействия с базой данных останется, то смысла в наших действиях все равно не будет.

Таким образом, если мы действительно хотим защитить данные — мы должны действовать на всех уровнях: безопасно обрабатывать данные в приложениях, безопасно хранить их в базах данных на безопасно настроенных серверах, взаимодействующих в безопасной сети. Естественно, не должна быть забыта и физическая защита, особенно в том случае, если инфраструктура расположена в стенах подконтрольного нам здания.

Важно помнить, что соответствовать требованиям стандарта PCI DSS должна не вся информационная инфраструктура компании, а только та ее часть, в которой обрабатываются карточные данные, а если быть точным — все компоненты информационной инфраструктуры, хранящие, обрабатывающие и передающие данные о держателях платежных карт, плюс смежные информационные системы. Под смежными в данном случае понимаются те системы, соединения с которыми не защищены корректно настроенными межсетевыми экранами.

Эквайринг или эмиссия?

Следует также различать области QSA-аудита от области применимости требований стандарта PCI DSS. Заметим, что для многих организаций эти области совпадают, однако исключением из этого правила являются банки, которые осуществляют в своей информационной инфраструктуре как процесс эквайринга платежных карт, так и процесс их эмиссии, обрабатывая при этом карточные данные. Поэтому область применимости требований стандарта PCI DSS для банков — это компоненты как из эквайринговой части инфраструктуры, так и из эмиссионной. Таким образом, везде, где есть хотя бы один номер карты (PAN) — неважно, «своей» карты, или карты, эмитированной другим банком, — применимы требования стандарта PCI DSS.

С областью же QSA-аудита ситуация не так однозначна. На сегодня порядок таков: эквайринговая часть инфраструктуры, то есть те компоненты, где хотя бы теоретически может быть обработан, передан или сохранен номер карты, эмитированной другим банком, обязательно входит в область QSA-аудита. Эмиссионная же часть — т. е. все компоненты, где обрабатываются только номера «своих» карт, включается в область QSA-аудита по желанию аудируемого банка. Эта информация была получена автором статьи на ежегодном мероприятии PCI Security Standards Council European Community Meeting от представителей топ-менеджмента международных платежных систем — Майкла Грина (Michael Green), вице-президента MasterCard Worldwide, и Шейна Болфе (Shain Balfe), менеджера по безопасности Visa Europe. Тем не менее, и тут есть исключение: по прямому требованию международной платежной системы эмиссионная часть информационной инфраструктуры банка также может быть включена в область QSA-аудита.

На практике это выглядит следующим образом. QSA-аудиторы компании Deiteriy на этапе предварительного аудита проводят полное обследование банка. Затем, основываясь на полученных результатах и комментариях аудиторов к ним, специалисты банка принимают решение о том, включать ли всю инфраструктуру банка в процесс внедрения PCI DSS или же, если объемы планируемых работ существенно различаются, заняться на первом этапе проекта только эквайринговой частью, а эмиссионную часть оставить на более поздний этап доработки. Такой подход позволяет банку поэтапно расходовать средства на достижение соответствия стандарту PCI DSS, и больше соответствует духу риск-ориентированного подхода к обеспечению информационной безопасности.

Вид	Обозначение	Определение
Номер карты	PAN	Номер, идентифицирующий платежную карту, наносится на ее лицевую сторону.
Имя держателя карты	CHNAME	Имя и фамилия человека, которому банк предоставил право распоряжения платежной картой, наносится на ее лицевую сторону.
Дата окончания срока действия карты	EXPDATE	Дата, при наступлении которой платежная карта становится недействительна, наносится на ее лицевую сторону.
Сервисный код	SCODE	Служебное значение, содержащееся на магнитной полосе (чипе) карты.
Содержимое магнитной полосы или чипа	TRACK	Вся информация, содержащаяся на магнитной полосе (чипе) карты.
Проверочное значение	CVV2 / CVC2	Значение, используемое для авторизации платежной транзакции без считывания магнитной полосы (чипа) карты, наносится на ее оборотную сторону.
ПИН-код и его шифрограмма	PIN и PINBLOCK	Значение, используемое для авторизации платежной транзакции на банкоматах и POS-терминалах, и его шифрограмма (ПИН-блок).

 

Описание информационной инфраструктуры

Описание области информационной инфраструктуры, на которую распространяются требования стандарта PCI DSS, состоит из трех компонентов — схемы сетевого уровня, схемы потоков данных о держателях карт и перечня компонентов информационной инфраструктуры. Согласно правилам проведения QSA-аудита, все эти три компонента в обязательном порядке должны присутствовать в отчете о соответствии (Report on Compliance, ROC), подготовленном QSA-аудитором.

Таким образом, наличие в отчете подробной схемы сети, детального описания потоков данных о держателях карт, а также перечня компонентов, входящих в область аудита — это признаки качественной работы QSA-аудитора в соответствии с официальной процедурой. Заказчику мы советуем обращать внимание на это в первую очередь, поскольку полнота и точность описания области, в которой был выполнен аудит, является предметом проверки процедуры контроля качества (Quality Assurance, QA), выборочно выполняемой регулятором отрасли — Советом PCI SSC.

Рис. 1. Пример упрощенной схемы информационной инфраструктуры банка на сетевом уровне

Рис. 2. Пример упрощенной схемы потоков карточных данных в сети банка

Сужение области применимости требований стандарта PCI DSS

Для чего необходимо сужать область применимости стандарта PCI DSS? Формальный и буквальный подход к внедрению стандарта PCI DSS — гарантированный способ сделать проект бесконечным, и по срокам, и по деньгам. Никто, разумеется, не запрещает организации привести в соответствие лучшим мировым практикам всю сеть компании, включая те ее сегменты, где критичных данных никогда не было, нет и не предвидится. Однако такой вариант «внедрения стандартов PCI DSS» не отвечает духу риск-ориентированного подхода к обеспечению информационной безопасности: избыточные меры защиты вредны для организации, — и не только по причине заметных расходов. В процессе снижения рисков, связанных с безопасностью данных, следует искать не «абсолютной защиты», а компромисса между защищенностью и функциональностью бизнес-процессов, иначе можно необратимо снизить эффективность ежедневной работы сотрудников, а процедуру их доступа к рабочей информации сделать неприятной рутиной. Поэтому очевидно, что защитные меры нужно применять точечно — именно там, где они действительно нужны.

Лучшим способом сужения области применимости PCI DSS, исходя из самого ее определения, является модернизация бизнес-процессов, ведущая к упорядочению потоков карточных данных внутри организации и к снижению количества компонентов, которые задействованы в обработке, передаче или хранении этих данных. Когда потоки данных упорядочены, их можно компактно разместить внутри ограниченного сегмента информационной инфраструктуры.

Там, где нет прямой необходимости использовать номер карты в открытом виде — скажем, если он используется лишь как уникальный идентификатор клиента, — его лучше заменить на что-то другое. Например, вместо номера карты можно использовать уникальное значение — токен, который может эффективно выполнять функцию идентификации, но при этом не будет так критичен с точки зрения конфиденциальности, как номер карты. Можно использовать и хэш-значение от номера карты, или его маскированное значение вида 1234 56** **** 7890. Эти данные уже не являются карточными, и на них не распространяются требования PCI DSS.

Следствием минимизации количества компонентов, обрабатывающих карточные данные, будет также повышение уровня безопасности, поскольку в инфраструктуре уменьшится количество потенциально уязвимых мест.

Для изоляции компактного сегмента обработки данных о держателях карт от остальной информационной инфраструктуры организации применяются два основных метода: это межсетевое экранирование и шифрование передаваемых данных. Идеологию их применения понять несложно: серверы, на которых работают карточные приложения и базы данных, следует собрать в один сегмент, который будет отделен от остальной сети корректно настроенными межсетевыми экранами. Все выходящие за пределы изолированного сегмента потоки карточных данных следует шифровать: это может быть VPN, SSL, пересылка зашифрованного архива или любой другой механизм безопасной передачи данных. При наличии описанной конфигурации, за локализацию проблемы защиты карточных данных в изолированном сегменте можно не беспокоиться.

Рабочие станции пользователей лучше всего оставить вне области применимости требований стандарта PCI DSS, применяя для них различные механизмы удаленного и терминального доступа. Естественно, при этом канал связи с выделенным сегментом обработки карточных данных должен быть зашифрован, а для доступа пользователей следует применять надежные механизмы аутентификации.

Следующая, третья, статья нашего цикла, посвященного управлению соответствием PCI DSS, будет посвящена тому, как выполнить требования стандарта PCI DSS в изолированном сегменте и о том, как успешно пройти сертификационный QSA-аудит.