По материалам статьи автора, опубликованной в журнале «ПЛАС» № 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-аудит.
Окт