Информационная безопасность в индустрии платежных карт

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

Стандарт PCI DSS был разработан Советом по стандартам безопасности данных индустрии платежных карт PCI SSC (Payment Card Industry Security Standards Council), который был учрежден международными платежными системами Visa, MasterCard, American Express, JCB, Discover. Стандарт регламентирует предопределенный перечень требований, как с технической, так и с организационной стороны, подразумевая комплексный подход с высокой степенью требовательности к обеспечению безопасности данных платежных карт (ДПК).

# На кого распространяются требования стандарта PCI DSS?

В первую очередь стандарт определяет требования к организациям, в информационной инфраструктуре которых хранятся, обрабатываются или передаются данные платёжных карт, а также к организациям, которые могут влиять на безопасность этих данных. Цель стандарта достаточно очевидна - обеспечить безопасность обращения платёжных карт. С середины 2012 года все организации, вовлечённые в процесс хранения, обработки и передачи ДПК должны соответствовать требованиям PCI DSS, и компании на территории Российской Федерации не являются исключением.

Чтобы понять, попадает ли ваша организация под обязательное соблюдение требований стандарта PCI DSS, предлагаем воспользоваться несложной блок-схемой.

Рисунок 1. Определение необходимости соответствия стандарту PCI DSS

Первым делом следует ответить на два вопроса:

• Хранятся, обрабатываются или передаются ли данные платежных карт в вашей организации?
• Могут ли бизнес-процессы вашей организации непосредственно влиять на безопасность данных платежных карт?

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

# Каковы требования стандарта PCI DSS?

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

Таблица 1. Верхнеуровневые требования стандарта PCI DSS

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

# Как можно подтвердить соответствие стандарту PCI DSS?

Существуют различные способы подтверждения соответствия требованиям стандарта PCI DSS, которые заключаются в проведении внешнего аудита (QSA), внутреннего аудита (ISA) или самооценки (SAQ) организации. Особенности каждого из них проиллюстрированы в таблице.

Таблица 2. Способы подтверждения соответствия стандарту PCI DSS

Несмотря на кажущуюся простоту представленных способов, клиенты зачастую сталкиваются с непониманием и затруднениями при выборе соответствующего способа. Примером тому являются возникающие вопросы, приведенные ниже.

# В какой ситуации необходимо проводить внешний аудит, а в какой - внутренний? Или же достаточно ограничиться самооценкой организации?

Ответы на эти вопросы зависят от типа организации и количества обрабатываемых транзакций в год. Нельзя руководствоваться случайным выбором, поскольку существуют документированные правила, регулирующие, какой способ подтверждения соответствия стандарту будет использовать организация. Все эти требования устанавливаются международными платёжными системами, наиболее популярными из них в России являются Visa и MasterCard. Даже существует классификация, согласно которой выделяют два типа организаций: торгово-сервисные предприятия (мерчанты) и поставщики услуг.

Торгово — сервисное предприятие - это организация, принимающая платежные карты к оплате за товары и услуги (магазины, рестораны, интернет-магазины, автозаправочные станции и прочее).

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

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

Допустим, торгово-сервисное предприятие обрабатывает до 1 млн транзакций в год с применением электронной коммерции. По классификации Visa и MasterCard (рис. 2) организация будет относиться к уровню 3. Следовательно, для подтверждения соответствия PCI DSS необходимо проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV (Approved Scanning Vendor) и ежегодная самооценка SAQ. В таком случае организации не нужно заниматься сбором свидетельств соответствия, поскольку для текущего уровня в этом нет необходимости. Отчётным документом будет выступать заполненный лист самооценки SAQ.

ASV-сканирование (Approved Scanning Vendor) - автоматизированная проверка всех точек подключения информационной инфраструктуры к сети Интернет с целью выявления уязвимостей. Согласно требованиям стандарта PCI DSS, такую процедуру следует выполнять ежеквартально.

Или же рассмотрим пример с поставщиком облачных услуг, который обрабатывает более 300 тысяч транзакций в год. Согласно установленной классификации Visa или MasterCard, поставщик услуг будет относиться к уровню 1. А значит, как указано на рисунке 2, необходимо проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV, а также внешнего ежегодного QSA аудита.

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

Рисунок 2. Классификация уровней и требования подтверждения соответствия стандарту PCI DSS

# Представляет ли однократное нарушение сроков ASV-сканирования серьёзный риск с точки зрения соответствия PCI DSS?

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

Нарушение расписания внешнего сканирования на уязвимости влечет за собой наложение дополнительных требований к системе менеджмента информационной безопасности в организации. Во-первых, необходимо будет все же провести ASV-сканирование на уязвимости, добиться «зеленого» отчета. А во-вторых, потребуется разработать дополнительную процедуру, которая не будет допускать подобных нарушений расписания в будущем.

В заключение

Основные выводы можно выразить цитатой Петра Шаповалова, инженера по защите информации ООО «Дейтерий» :

«Несмотря на то, что на территории Российской Федерации уже начала функционировать своя Национальная система платежных карт (НСПК), требования международных платежных систем не упразднили. Наоборот, в последнее время от Visa и MasterCard участились письма банкам-эквайерам о том, чтобы последние требовали соответствия стандарту PCI DSS от платежных шлюзов, торгово-сервисных предприятий, подключенных к ним, а также от поставщиков услуг, которые могут влиять на безопасность карточных данных. В связи с этим вопрос соответствия требованиям стандарту PCI DSS становится важным не только для крупных игроков индустрии платежных карт, но и для небольших торгово-сервисных предприятий.

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

В качестве примера компании, предоставляющей услуги по управляемым сервисам PCI DSS (не только аренда инфраструктуры PCI DSS, но и её администрирование в соответствии с требованиями стандарта), можно привести

Директор департамента ау-
дита компании "Информ-
защита"

Ведущий специалист компа-
нии "Информзащита"

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

Подробно:

Теория PCI DSS

О стандарте PCI DSS было сказано и написано уже многое, его требования размещены в открытом доступе (например, по адресу: www.pcisecuritystandards.org), и с ними может подробно ознакомиться каждое заинтересованное лицо. Исходя из этого, в первой части статьи мы коротко остановимся лишь на некоторой ключевой информации, касающейся целей внедрения стандарта PCI DSS и сфер его применения.

Историческая справка

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

С этой целью в 2004г. был разработан единый набор требований к безопасности данных - Payment Card Industry Data Security Standard, объединивший в себе требования ряда программ по безопасности таких платежных систем как Visa, MasterCard, American Express, Discover Card и JCB. Впоследствии для развития и продвижения стандарта PCI DSS в сентябре 2006г. был создан специальный Совет по стандартам безопасности – PCI Security Standards Council, в который вошли представители данных платежных систем. Изначально международные платежные системы требовали от своих участников и торгово-сервисных предприятий обеспечить соответствие стандарту на территории США и Западной Европы, применяя штрафные санкции за невыполнение данных требований.

Для других регионов требования PCI DSS были также обязательны, но никаких санкций за их невыполнение предусмотрено не было. Однако с сентября 2006 года Visa Int. объявила, что за непрохождение аудита по стандарту PCI DSS торгово-сервисными предприятиями (merchants) и поставщиками услуг (service providers – процессинговые центры, платежные шлюзы, Интернет-провайдеры), работающими с Visa Int. на территории стран региона CEMEA, к которым относится, в том числе, и Россия, будут взиматься штрафы. Собственно, именно это и послужило стимулом к внедрению стандарта российскими банками.

Сферы применения PCI DSS

Действие PCI DSS распространяется на все торгово-сервисные предприятия и поставщиков услуг, работающих с международными платежными системами, т.е. на всех тех, кто передает, обрабатывает и хранит данные держателей карт. Сейчас актуальна версия стандарта PCI Data Security Standard v. 1.1, основные отличия которой от предыдущей касаются конкретизации и расширения некоторых требований. В таблице 1 приведены различные типы данных и требования к обеспечению их безопасности, которые выдвигает PCI DSS.

Также в зависимости от количества обрабатываемых транзакций каждой компании присваивается определенный уровень с соответствующим набором требований, которые должны выполняться для подтверждения соответствия стандарту. Процедуры подтверждения соответствия могут включать в себя ежегодное прохождение аудита, ежеквартальные сканирования сети или ежегодное заполнение листа самооценки (Self Assessment Questionnaire – специальная анкета, разработанная PCI SSC для самооценки компаний).

Нужно отметить, что для выполнения аудита и ежеквартальных сканирований своих сетей компании должны привлекать стороннюю организацию, имеющую статус Qualified Security Assessor (для проведения аудита) или Approved Scanning Vendor (для проведения сканирования сети). Данные статусы присваиваются Советом по стандартам безопасности.

Процедура аудита

В рамках аудита реализуется несколько последовательных этапов, различающихся по своей трудоемкости и длительности.

Этапы аудита:

1. Проверка документов и определение зоны контроля. На данном этапе аудиторы анализируют и проверяют пакет необходимой документации клиента – компании, выступающей заказчиком прохождения аудита на соответствие требованиям стандарта PCI DSS . В числе данных документов: схема сети с указанием всех подключений к части сети, в которой производится хранение, обработка или передача данных, содержащих информацию о держателях карт, реестр ресурсов, стандарты и политики, принятые в компании, документированные процедуры и процессы. Зона контроля (Scope) включает в себя:

• все устройства и сетевые сегменты, в которых производится хранение, обработка или передача данных, содержащих информацию о держателях платежных карт;
• все сетевые сегменты и устройства, подключенные к этим сегментам (в том числе активное сетевое оборудование).
• Зона контроля может быть довольно обширной, особенно в том случае, если внутри сеть компании не сегментирована и (в случае, если речь идет о кредитной организации) для отделения процессингового центра от остальной сети банка не используются внутренние межсетевые экраны. Используя специальную методику, аудитор делает репрезентативную выборку (Sampling) тех устройств, которые непосредственно будут подлежать проверке в ходе аудита.

ПРАКТИКА

Теперь, коснувшись общей информации о стандарте PCI DSS и процедуре аудита, мы считаем целесообразным остановиться на практических аспектах данной проблематики, а также привести немного статистики. Сразу хотелось бы оговориться относительно достоверности информации, предоставляемой авторами настоящей статьи, – на сегодняшний день компания «Информзащита» является единственной российской компанией, обладающей статусами Qualified Security Assessor и Approved Scanning Vendor и сертифицированной на выполнение аудита информационных систем компаний, а также сканирование их сетей в соответствии с требованиями стандарта PCI DSS . В течение 2007г.

«Информзащита» успешно провела более 15 соответствующих аудитов крупных банков и процессинговых центров в РФ и других странах СНГ. В процессе исполнения данных проектов аудиторами компании был накоплен богатый практический опыт реализации необходимых процедур, отточена методика проведения аудита, аккумулировано и проанализировано огромное количество информации, касающейся несоответствий требованиям стандарта, а также основных причин этих несоответствий.

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

Диаграмма 1. Среднее количество
выявленных несоответствий по
каждому из требований PCI DSS.

Диаграмма 2. Доля не применимых
проверок для различных
требований стандарта PCI DSS.

Основные несоответствия и их причины

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

Распространённые мифы о PCI DSS

1. «Внутренних» злоумышленников не существует. Отчего-то многие до сих пор считают, что все угрозы связаны с действиями «внешних» злоумышленников, и поэтому основные усилия по IT-защите направлены на обеспечение безопасности периметра сети. При этом вопросы защиты ресурсов внутри сети часто вообще не рассматриваются или им не уделяется должного внимания. По статистике, более 70% инцидентов, связанных с информационной безопасностью, происходит по вине инсайдеров.
2. Треки нужны для претензионной работы и поэтому должны храниться вместе с журналами транзакций. Такой подход противоречит требованиям стандарта PCI DSS, в соответствии с которыми данные треков должны удаляться сразу после процедуры авторизации, т. к. именно эти данные чрезвычайно ценны для злоумышленников, и их компрометация позволяет им впоследствии изготавливать поддельные платежные карты и выполнять мошеннические транзакции.
3. Данные платежных карт вообще не следует удалять , вдруг они когданибудь кому-нибудь понадобятся. Такой подход сегодня принципиально ошибочен. Если раньше политикой безопасности регламентировались минимальные сроки хранения данных, то теперь стандарт PCI DSS требует, напротив, ограничения максимальных сроков хранения определенных данных, т. е. в компании должна быть реализована задокументированная политика хранения данных, четко определяющая необходимый для поддержания бизнес-процессов период хранения данных и требования к процедурам их последующего уничтожения.
4. Подключения по выделенным каналам являются защищенными по определению . Многие компании ошибочно полагают, что если они подключат своих клиентов и партнеров по выделенным каналам связи, такое соединение защищать не придется, защищать следует только подключения через Интернет. На самом деле выделенные каналы также требуют защиты, а именно шифрования передаваемых данных и соответствующей настройки VPN и средств межсетевого экранирования.
5. Cоответствия PCI DSS можно достичь, просто разработав комплект нормативной документации, поскольку на практике аудиторы ограничиваются проверкой документов и интервью с персоналом. Это в корне неверно: помимо вышеперечисленного аудиторы осуществляют также проверку настроек ПО и анализ содержимого файлов и таблиц баз данных, а также проверку соответствия сведений, указанных в предоставленных им документах, реальному положению вещей в компании.

Проблемные требования стандарта PCI DSS

Теперь приведем немного статистики, касающейся наиболее проблемных, с точки зрения соответствия PCI DSS, требований стандарта, несоответствия которым наиболее часто обнаруживаются в ходе аудиторской проверки. Как наглядно демонстрирует диаграмма 1, наиболее «проблемными» для компаний по количеству несоответствий являются следующие требования стандарт PCI DSS.

по пунктам:

• № 11: Необходимо проводить регулярное тестирование систем и процессов обеспечения безопасности.
• № 2: Необходимо запретить использование параметров безопасности и системных паролей, задаваемых производителями по умолчанию.
• № 3: Необходимо защищать хранимые данные держателей карт.
• № 10: Необходимо отслеживать и проводить мониторинг всех попыток доступа к сетевым ресурсам и данным держателей карт.
• № 8: Необходимо назначать уникальный идентификатор каждому, кто имеет доступ к компьютеру.
• № 12: Необходимо поддерживать и совершенствовать политику информационной безопасности.

Несоответствия перечисленным выше требованиям выявляются чаще всего. В то же время выполнение следующих требований стандарта обычно не вызывает больших трудностей:

• № 9: Необходимо ограничивать физический доступ к данным держателей карт.
• № 4: Необходимо шифровать данные держателей карт при их передаче по открытым, публичным сетям.
• № 7: Необходимо ограничивать доступ к данным держателей карт по принципу необходимого знания.

Важно отметить, что вышеописанные значения несоответствий рассчитаны с учетом применимости проверок к компаниям. Так, например, большинство компаний, где «Информзащита» проводила аудит, не занимается разработкой собственного ПО, поэтому многие проверки на соответствие Требованию 6 (Необходимо разрабатывать и поддерживать защищенные системы и приложения) к ним применить нельзя. Доля неприменимых проверок для различных требований стандарта приведена на диаграмме 2.

Как показывает диаграмма, к банкам и процессинговым центрам применимы в среднем около 70% всех проверок (из 232 содержащихся в стандарте). Очень многие вопросы безопасности в компаниях реализуются в рамках исторически сложившихся практик, которые далеко не всегда соответствуют требованиям стандарта PCI DSS или даже внутренней политике безопасности компании. Поэтому ниже мы привели перечень наиболее часто встречающихся несоответствий требованиям стандарта.

1. Необходимые для обеспечения бизнеспроцессов сетевые протоколы и политики межсетевого экранирования незадокументированы.
2. Авторизационные данные хранятся в журналах транзакций ATM, POS-терминалов и т.д.
3. Внутреннее сканирование уязвимостей сетевых устройств не проводится. 4. Не определена политика хранения данных, т.е. нет четкой установки, где и какие данные платежных карт хранить и когда их нужно удалять.
4. Должным образом не обеспечивается контроль целостности приложений и операционных систем серверов.
5. Не стандартизированы настройки операционных систем и приложений, в том числе с точки зрения обеспечения безопасности.
6. Не устанавливаются вообще или устанавливаются несвоевременно обновления безопасности на серверы процессинга, так как для их установки необходимо перезагружать серверы и останавливать работу.
7. В случае использования ПО собственной разработки последнее ничем не регламентировано, и разработчики всегда поддерживают продукционную систему самостоятельно как наиболее компетентные специалисты.
8. Парольная политика применяется в основном только в доменах Windows. На Unix-серверах, в базах данных, и к приложениям парольная политика применяется крайне редко.
9. Регистрация событий не рассматривается как источник информации для мониторинга уровня безопасности и расследования инцидентов.
10. Обучение рядовых сотрудников в части информационной безопасности обычно ограничивается единственным инструктажем при приеме на работу.

Таким образом, ознакомившись с приведенным списком основных несоответствий требованиям стандарта PCI DSS, вы можете попытаться «примерить» его на свою компанию и заранее постараться устранить выявленные несоответствия. В заключение хотелось бы отметить, что компаниям, в которых процессы управления IT и IT-безопасностью реализованы в соответствии с ITIL, COBiT и другими современными IT-стандартами, намного проще выполнить все требования PCI DSS, нежели компаниям, где исторически всей автоматизацией и безопасностью процессинга управляли несколько специалистов, действовавших на собственное усмотрение и без документирования своей деятельности.

Текст статьи читайте в журнале "ПЛАС" 2 (132) ’2008 сс. 12

В нескольких ранних публикация мы с вами уже рассматривали некоторые международные стандарты в области информационной безопасности. Однако, преимущественно они относились к in-house , т.е. внутренней инфраструктуре компании. Наиболее явственно понимание ИБ приходит, когда безопасность напрямую связана с финансами, когда в цифрах показывает свое существенное влияние на бизнес. Поэтому сегодня мы поговорим о безопасности в финансовых институтах, таких как банки, кредитные организации, платежные агенты и т.д. Все они занимаются денежными переводами, а значит попадают по действие отраслевого стандарта PCI DSS (Payment Card Industry Data Security Standard)

Стандарт PCI DSS предназначен для обеспечения безопасности обработки, хранения и передачи данных о держателях платежных карт в информационных системах компаний, работающих с международными платежными системами Visa , MasterCard и другими. Стандарт разработан сообществом PCI Security Standards Council , в которое входят мировые лидеры на рынке платежных карт, такие как American Express , Discover Financial Services, JCB, MasterCard Worldwide и Visa International . Требования стандарта PCI DSS распространяются на все компании , которые обрабатывают, хранят или передают данные о держателях платежных карт (банки, процессинговые центры, сервис-провайдеры, системы электронной торговли и др.). В России соответствие стандарту PCI DSS стало обязательным к применению в соответствующих организациях с 2007 года.

Согласно результатам исследования Analysys Mason , примерно 42% поставщиков облачных сервисов соблюдают стандарты безопасности данных отрасли платежных карточек (PCI DSS, Payment Card Industry Data Security Standard). Они действуют во всем мире и касаются всех организаций, которые обрабатывают кредитные карты, а также хранят или передают информацию об их держателях. Этот стандарт был введен, чтобы дать отрасли платежных карт больше контроля за конфиденциальными данными и исключить возможность их утечки. Также, он призван гарантировать защиту потребителей от мошенничества или кражи идентификационной информации при использовании ими кредитных карт.

Как по классификации Visa, так и по классификации MasterCard, системы, обрабатывающие, хранящие или передающие данные о более чем 6млн транзакций в год, относятся к первому уровню (Level 1) и обязаны ежегодно проходить аудит .

ИСТОРИЯ РАЗВИТИЯ СТАНДАРТА

1.0 — первоначальная версия стандарта.

1.1 — принята в сентябре 2006 года.

1.2 — принята в октябре 2008 года.

2.0 — принята в октябре 2010 года.

3.0 — принята в ноябре 2013 года.

3.1 — принята в апреле 2015 года.

PCI DSS, версия 3.0

`Новая версия PCI-DSS 3.0 превратит стандарт в органичную часть обычных бизнес-операций, — рассказал eWeek Боб Руссо, главный управляющий совета Payment Card Industry Security Standards Council (PCI SSC). — Мы хотим попытаться отучить людей считать, что PCI-DSS можно заняться раз в год, а потом про него не думать. В реальной обстановке нередко возникают бреши`.

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

Один из аспектов критики стандарта PCI-DSS — отсутствие ясности в его положениях. Например, стандарт может потребовать, чтобы организация развернула Web Application Firewall (WAF) без детализации нужной конфигурации сетевого экрана или даже объяснения, почему он так необходим. Такую критику в четкой и резкой форме высказывали члены PCI SCC, и это потребовало разработки нового улучшенного стандарта.

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

Так, в случае WAF новый стандарт будет объяснять, что умеет делать эта технология и какие типы рисков она поможет смягчить.

Одно из важных изменений в стандарте PCI-DSS 3.0 связано с использованием паролей. В последние три года PCI SCC провел ряд исследований по надежности паролей, которые помогли сформулировать новые требования.

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

В стандарте PCI-DSS 3.0 постоянно подчеркивается необходимость гибкости при управлении безопасностью, которая должна обеспечиваться различными постоянно совершенствуемыми способами.

PCI DSS, версия 2.0

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

Несмотря на то, что стандарт версии 2.0 вступил в силу с 1 января 2011 года, участники индустрии платежных карт могут использовать предыдущую версию до конца 2011 года. Подобная инициатива Совета PCI SSC позволяет выполнить постепенный переход на новую версию. Следующая версия будет подготовлена Советом PCI SSC в течение трехлетнего жизненного цикла.

Требования стандарта PCI DSS

PCI DSS определяет следующие шесть областей контроля и 12 основных требований по безопасности.

Построение и сопровождение защищённой сети

Не смотря на всю открытость стандарты у многих накапливаются вопросы. На некоторые из них, мы и попытаемся ответить ниже.

1. На кого распространяются требования стандарта PCI DSS?

В первую очередь стандарт определяет требования к организациям, в информационной инфраструктуре которых хранятся, обрабатываются или передаются данные платёжных карт, а также к организациям, которые могут влиять на безопасность этих данных. Цель стандарта достаточно очевидна — обеспечить безопасность обращения платёжных карт. С середины 2012 года все организации, вовлечённые в процесс хранения, обработки и передачи ДПК должны соответствовать требованиям PCI DSS , и компании на территории Российской Федерации не являются исключением. Чтобы понять, попадает ли ваша организация под обязательное соблюдение требований стандарта PCI DSS , предлагаем воспользоваться несложной блок-схемой.

Первым делом следует ответить на два вопроса:

• Хранятся, обрабатываются или передаются ли данные платежных карт в вашей организации?
• Могут ли бизнес-процессы вашей организации непосредственно влиять на безопасность данных платежных карт?

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

2. Каковы требования стандарта PCI DSS?

Для соответствия стандарту необходимо выполнение требований, которые в общих чертах представлены двенадцатью разделами, приведёнными в таблице ниже:

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

3. Как можно подтвердить соответствие стандарту PCI DSS?

Существуют различные способы подтверждения соответствия требованиям стандарта PCI DSS , которые заключаются в проведении внешнего аудита (QSA) , внутреннего аудита (ISA) или самооценки (SAQ) организации.

Особенности каждого из них проиллюстрированы в таблице.

Несмотря на кажущуюся простоту представленных способов, клиенты зачастую сталкиваются с непониманием и затруднениями при выборе соответствующего способа. Примером тому являются возникающие вопросы, приведенные ниже.

4. В какой ситуации необходимо проводить внешний аудит, а в какой — внутренний? Или же достаточно ограничиться самооценкой организации?

Ответы на эти вопросы зависят от типа организации и количества обрабатываемых транзакций в год. Нельзя руководствоваться случайным выбором, поскольку существуют документированные правила, регулирующие, какой способ подтверждения соответствия стандарту будет использовать организация. Все эти требования устанавливаются международными платёжными системами, наиболее популярными из них в России являются Visa и MasterCard . Даже существует классификация, согласно которой выделяют два типа организаций: торгово-сервисные предприятия (мерчанты) и поставщики услуг.

Торгово-сервисное предприятие — это организация, принимающая платежные карты к оплате за товары и услуги (магазины, рестораны, интернет-магазины, автозаправочные станции и прочее). Торгово-сервисноепредприятие — это организация, принимающая платежные карты к оплате за товары и услуги (магазины, рестораны, интернет-магазины, автозаправочные станции и прочее).

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

Допустим, торгово-сервисное предприятие обрабатывает до 1 млн транзакций в год с применением электронной коммерции. По классификации Visa и MasterCard (рис. 2) организация будет относиться к уровню 3. Следовательно, для подтверждения соответствия PCI DSS необходимо проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV (Approved Scanning Vendor) и ежегодная самооценка SAQ. В таком случае организации не нужно заниматься сбором свидетельств соответствия, поскольку для текущего уровня в этом нет необходимости. Отчётным документом будет выступать заполненный лист самооценки SAQ.

ASV-сканирование (Approved Scanning Vendor) — автоматизированная проверка всех точек подключения информационной инфраструктуры к сети Интернет с целью выявления уязвимостей. Согласно требованиям стандарта PCI DSS, такую процедуру следует выполнять ежеквартально.

Или же рассмотрим пример с поставщиком облачных услуг, который обрабатывает более 300 тысяч транзакций в год. Согласно установленной классификации Visa или MasterCard , поставщик услуг будет относиться к уровню 1. А значит, как указано на рисунке 2, необходимо проведение ежеквартального внешнего сканирования уязвимостей компонентов информационной инфраструктуры ASV, а также внешнего ежегодного QSA аудита.

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

Привет, %username%!
Этот пост мы подготовили для тех, кто работает в сфере интернет-коммерции и планирует принимать (или уже принимает) платежи на собственном сайте. Мы расскажем о международном стандарте безопасности данных PCI DSS. Поговорим о его основных требованиях к информационной инфраструктуре, которая обеспечивает обработку и обеспечение безопасности данных банковских карт. Также мы рассмотрим основные причины прохождения сертификации и возможности, которые получает сертифицированная компания.

PCI DSS (Payment Card Industry Data Security Standard) - стандарт безопасности данных индустрии платежных карт. Стандарт разработан международными платежными системами Visa и MasterCard. Любая организация, планирующая принимать и обрабатывать данные банковских карт на своем сайте, должна соответствовать требованиям PCI DSS.

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

• Level 4 позволяет обрабатывать до 20 тыс. транзакций в год. Для подтверждения соответствия требованиям PCI DSS требуется ежеквартальное сканирование внешних адресов на наличие уязвимостей (ASV-сканирование) и заполнение листа самооценки (Annual Self-Assessment Questionnaire , SAQ)
• Level 3 позволяет обрабатывать от 20 тыс. до 1млн. транзакций в год. Для прохождения сертификации требуется как ежеквартальное ASV-сканирование, так и заполнение листа самооценки (SAQ).
• Level 2 позволяет обрабатывать от 1 млн. до 6 млн. транзакций в год. Для подтверждения соответствия требованиям PCI DSS требуется ежеквартальное ASV-сканирование и заполнение листа самооценки (SAQ). Однако, после 30 июня 2012 года для заполнения SAQ на этом уровне будет необходимо либо отправлять собственных сотрудников на специализированный тренинг, либо привлекать компанию-аудитора (PCI QSA).
• Сертификация на соответствие требованиям PCI DSS Level 1 проводится только с привлечением независимого аудитора (QSA) и позволяет обрабатывать более 6 млн. транзакций в год. Процедура сертификации включает в себя обследование информационной инфраструктуры компании, разработку рекомендаций и нормативных документов, необходимых для соответствия стандарту, консультационную поддержку при внедрении.

• Конверсия. Компании опасаются потери части оплат при переходе из корзины на отдельную платежную страницу.
• Имидж. Иногда крупные компании не хотят, чтобы для ввода данных банковской карты клиент переходил с сайта компании на сайт сторонней организации (банка или процессингового центра).
• Технические задачи. Компании нужно построить собственную высокотехнологичную схему проведения платежей, ориентированную на специфику бизнеса.

Но самостоятельная работа с банками дает компании не только преимущество в адаптации платежной системы «под себя». Она обязывает компанию взять на себя борьбу с мошенническими операциями при обработке данных банковских карт на своем сайте. Иными словами, компании необходимо построить собственную систему мониторинга и борьбы с мошенническими операциями (анти-фрод). Задача анти-фрод системы – фильтрация операций, определяемых как мошеннические, по ряду признаков (например, несовпадение банка-эмитента со страной оплаты или проживания плательщика).

На стадии построения и отладки анти-фрод системы много времени «съест» сбор и анализ данных об операциях по банковским картам. Цель сбора данных – выявление отличительных признаков мошеннических операций. В процессе сбора статистики компании придется столкнуться с большим объемом «charge-back» операций.

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

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

Для принятия взвешенного решения о выборе способа обработки данных банковских карт, необходимо оценивать все составляющие процесса от подачи документов до поддержки кардхолдеров. Для того чтобы принять решение было проще, мы провели сравнение двух основных подходов по приему и обработке данных банковских карт: если ввод данных осуществляется на стороннем сайте (например, ПЦ) – и если данные вводят на сайте предприятия с последующей авторизацией платежа в банке.

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

К компаниям, работающим только с платёжным шлюзом и не принимающих на своем данных банковских карт клиентов, относятся только требования департамента рисков платежного шлюза (ПЦ). Они касаются сайта предприятия e-commerce, корректности контента и ценовых предложений, организационной формы компании.

Если после прочтения этого поста у Вас появились вопросы – пишите в комментарии. Со стороны аудитора и специалиста по требованиям стандарта PCI DSS Вас проконсультирует Евгений Безгодов aka

Стандарт PCI DSS

История стандарта

В последние годы по всему миру участились случаи взлома банковских информационных систем, а также факты мошенничества и кражи данных держателей карт. Подобная нездоровая тенденция послужила одной из главных причин, побудившей международные платежные системы объединить свои усилия и принять дополнительные меры для защиты своих клиентов. С 2001 г. платежные системы начали разрабатывать собственные программы обеспечения информационной безопасности для снижения рисков мошенничества - в VISA это были программы Cardholder Information Security Program (CISP) и Account Information Security (AIS), в MasterCard была разработана программа Site Data Protection (SDP). В 2004 г. был разработан единый набор требований к безопасности данных - Payment Card Industry Data Security Standard 1.0, объединивший в себе требования ряда программ по безопасности платежных систем VISA Int., MasterCard, American Express, Discover Card и JCB.

Впоследствии, в сентябре 2006 г., для развития и продвижения стандарта PCI DSS, был создан специальный Совет по безопасности - PCI Security Standards Council. Основными функциями Совета по безопасности являются разработка и публикация стандартов PCI и всей сопутствующей документации, определение требований к компаниям, планирующим получить сертификацию для проведения аудитов по PCI DSS («QSA») и сканирований («ASV»), осуществление непосредственно самой сертификации, проведение обучающих тренингов для будущих QSA-аудиторов, а также осуществление контроля качества проведенных аудиторами работ. Официальным источником информации о стандартах PCI является сайт Совета по безопасности, там можно найти:

Ответы на частые вопросы - FAQ;

Описание рисков, связанных с каждым требованием стандарта - Navigating PCI DSS Document;

Тексты стандартов PCI DSS, PA DSS и PCI PED на различных языках.

В свою очередь международные платежные системы принимают отчетность по результатам аудитов и оценивают работу QSA.

Обновленная версия стандарта PCI DSS 1.1 вышла в сентябре 2006 г., в ноябре 2008 г. вышла версия 1.2 и текущая версия 2.0 на момент написания книги была принята в ноябре 2010 г. Несмотря на большое количество различных версий, по сути набор требований не претерпел существенных изменений, новые версии стандарта в основном содержали уточнение требований и исправление ошибок.

Сферы применения PCI DSS

Действие стандарта PCI DSS распространяется на все торгово-сервисные предприятия (merchants) и поставщиков услуг (service providers), работающих с международными платежными системами, т. е. на всех тех, кто передает, обрабатывает и хранит данные держателей карт. В табл. 2.1 проиллюстрированы различные типы данных и требования к ним, которые выдвигает PCI DSS.

Также в зависимости от количества обрабатываемых транзакций каждой платежной системой компании присваивается определенный уровень с соответствующим набором требований, которые должны выполняться в обязательном порядке. Это может быть (1) ежегодное прохождение аудита, (2) ежеквартальные сканирования сети или (3) ежегодное заполнение листа самооценки (Self Assessment Questionnaire - специальная анкета, разработанная PCI SSC для самооценки компаний).

Требования Стандарта безопасности данных платежных приложений (PA DSS) являются производными от требований Стандарта безопасности данных индустрии платежных карт (PCI DSS) и Процедур аудита безопасности PCI DSS (PCI DSS Security Audit Procedures). Эти документы, с которыми можно ознакомиться на сайте PC PCI, содержат подробное описание требований безопасности данных, которые торгово-сервисные предприятия и сервис-провайдеры должны соблюдать для соответствия стандарту PCI DSS (следовательно, какое приложение платежной системы необходимо использовать для обеспечения соответствия этому стандарту).

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

Ниже приведены несколько способов использования приложений платежных систем, при которых требования стандарта PCI DSS нарушаются:

Хранение данных магнитной полосы карты в сети клиента после авторизации;

Использование приложений, для корректной работы которых требуется отключение клиентами программного обеспечения, которое должно применяться для соблюдения требований стандарта PCI DSS (например, антивирусных программ или межсетевых экранов);

Использование производителями незащищенных методов подключения к этим приложениям для технической поддержки клиента.

При использовании защищенных приложений платежных систем в среде, соответствующей требованиям стандарта PCI DSS, уменьшается вероятность нарушения безопасности, приводящая к компрометации полных данных магнитной полосы, кодов проверки подлинности карты (CAV2, CID, CVC2, CVV2), ПИН-кодов и ПИН-блоков и, в результате, - к осуществлению злоумышленниками мошеннических операций.

Описание требований стандарта

Все требования стандарта сгруппированы в 12 разделов, объединенных в 6 групп:

Построение и поддержание защищенной сети:

требование 1 : установка и администрирование конфигурации межсетевых экранов для защиты данных держателей карт;

требование 2 : не должны использоваться системные пароли и другие параметры безопасности, установленные производителем по умолчанию;

Защита данных держателей карт:

требование 3 : должна быть обеспечена защита данных держателей карт при хранении;

требование 4 : должно быть обеспечено шифрование передачи данных держателей карт по сетям общего пользования;

Реализация программы управления уязвимостями:

требование 5 : должно использоваться регулярно обновляемое антивирусное программное обеспечение;

требование 6 : должна обеспечиваться безопасность при разработке и поддержке систем и приложений;

Реализация мер по строгому контролю доступа:

требование 7 : доступ к данным держателей карт должен быть ограничен в соответствии со служебной необходимостью;

требование 8 : каждому лицу, имеющему доступ к вычислительным ресурсам, должен быть назначен уникальный идентификатор;

требование 9 : физический доступ к данным держателей карт должен быть ограничен;

Регулярный мониторинг и тестирование сетей:

требование 10 : должен отслеживаться и контролироваться любой доступ к сетевым ресурсам и данным держателей карт;

требование 11 : должно выполняться регулярное тестирование систем и процессов обеспечения безопасности;

Поддержание политики информационной безопасности:

требование 12

Каждое из 12 общих требований содержит ряд «подтребований» и процедур их проверки, которые, с одной стороны, обеспечивают (как минимум в теории) однообразие контроля требований аудиторам и, с другой стороны, часто детализируют само требование. Также для понимания сути требования и/или процедуры проверки бывает полезно учитывать, в какой группе находится данное требование. Описание требований приведено для версии стандарта PCI DSS 2.0.

Построение и поддержание защищенной сети

Требование 1 : установка и администрирование конфигурации межсетевых экранов для защиты данных держателей карт.

Данное обобщенное требование содержит 18 требований и 25 процедур оценки их соответствия, регламентирующих различные аспекты применения межсетевых экранов для защиты сегментов сети, обрабатывающих данные платежных карт, такие как:

Сегментация сети на различные зоны безопасности и размещение серверов в них;

Необходимость документирования и поддержания актуальности схемы сети, перечня разрешенных протоколов;

Настройка конкретных правил фильтрации трафика;

Необходимость регламентирования процесса внесения изменений в конфигурации межсетевых экранов;

Настройка правил фильтрации трафика на мобильных компьютерах.

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

Тем не менее при правильной реализации риск несанкционированного доступа в сеть после выполнения всех требований этого раздела существенно снижается.

Требование 2: не должны использоваться системные пароли и другие параметры безопасности, установленные производителем по умолчанию.

Данное обобщенное требование содержит 23 требования и соответствующие им процедуры оценки, регламентирующие различные аспекты настройки серверов, сетевого оборудования, приложений и баз данных, в частности:

Разработка стандартов безопасной настройки, определяющих конкретные параметры безопасности для каждого вида используемых систем;

Изменение параметров систем, установленных по умолчанию;

Разделение важных функций между различными серверами;

Удаление ненужного или неиспользуемого функционала;

Регламентация используемых протоколов взаимодействия;

Обеспечение безопасного удаленного доступа администраторов для управления системами.

Как правило, реализация данного набора требований требует определенного времени как на разработку необходимых параметров безопасности, так и на тестирование их работоспособности и применение на всех системных компонентах. Для большой организации этот процесс может затянуться на несколько месяцев.

Но в результате безопасность систем существенно возрастает, особенно в совокупности с правильно настроенным межсетевым экраном и вовремя устанавливаемыми обновлениями безопасности. По сути, реализация требований 1, 2 и 6 в полном объеме могли бы предотвратить более 90 % случившихся взломов систем с последующими утечками данных платежных карт.

Защита данных держателей карт

Требование 3 : должна быть обеспечена защита данных держателей карт при хранении.

Данное обобщенное требование содержит 15 требований и соответствующих им процедур оценки, определяющих, как необходимо обрабатывать, хранить и защищать непосредственно данные платежных карт (такие как PAN, TRACK, PINBLOCK и т. п.), в том числе:

Необходимо хранить номера карт только в тех местах и в течение такого срока, которые явно определены бизнес-целями;

Соблюдать политику по уничтожению номеров карт после истечения срока их обоснованного хранения;

Ограничивать доступ сотрудников к номерам карт в приложениях;

Маскировать, шифровать, использовать другие способы затруднения получения полного номера карт при хранении;

Жесткие запреты хранения критичных данных карт, используемых для авторизации после ее завершения;

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

Необходимо отметить следующее: так как стандарт разрабатывался в первую очередь для снижения рисков мошенничества в инфраструктурах торгово-сервисных предприятий и поставщиков сервиса (таких как платежные шлюзы, процессинговые центры и т. п.), вопросы защиты и хранения данных платежных карт в банковских организациях в рамках их выпуска не рассмотрены достаточно подробно. В результате при подтверждении соответствия стандарту в банках, где осуществляется и эквайринг, и выпуск карт на базе решения некоторых вендоров (таких как OpenWay, например), возникает ситуация, при которой в одной базе данных могут храниться критичные данные авторизации как сохраненные в процессе выпуска карт, так и сохраненные после авторизации. В этом случае необходимо рассматривать каждое место хранения данных в привязке к процессу, в рамках которого они возникают, - ведь в стандарте запрещено хранить критичные данные, возникшие только в результате авторизации, но ничего не сказано о данных, возникающих в рамках выпуска карт.

Наиболее проблемным при внедрении всего стандарта обычно считается требование 3.4 (приведение номеров карт при хранении к нечитаемому виду путем использования шифрования, маскирования и т. п.), поскольку это требует:

Доработки/замены прикладного программного обеспечения, используемого для обработки карт, включая изменение алгоритмов поиска номеров карт, в частности по маске;

Обновления базы данных, поскольку, например, в СУБД Oracle шифрование хорошо поддерживается начиная с 10-й версии;

Апгрейда оборудования на более производительное, поскольку шифрование требует больших аппаратных ресурсов;

Обеспечения шифрования резервных копий баз данных;

Серьезной проработки и регламентации вопросов управления ключами шифрования для каждого ПО, которое его поддерживает (включая генерацию, распределение, обеспечение безопасности и уничтожение).

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

Данное обобщенное требование содержит 3 требования и 9 соответствующих им процедур оценки, регламентирующих вопросы шифрования данных платежных карт при передаче их по открытым каналам связи, с использованием программ мгновенного обмена сообщениями (таких как Skype, ICQ и т. п.) и через беспроводные сети.

Необходимо заметить, что в рамках данного требования каналы GSM считаются публичными и требуют криптозащиты трафика. И это несмотря на то, что во многих сетях мобильных операторов реализовано шифрование, а, например, каналы FrameRelay считаются достаточно защищенными и не требуют дополнительного шифрования. А с точки зрения используемых алгоритмов для шифрования можно использовать не только сертифицированную российскую криптографию, но также и другие алгоритмы с достаточной криптозащитой (например, AES 256).

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

Реализация программы управления уязвимостями

Требование 5 : должно использоваться регулярно обновляемое антивирусное программное обеспечение.

Данное обобщенное требование содержит всего 3 требования и 6 соответствующих им процедур оценки, описывающих особенности применения и управления системами антивирусной защиты.

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

Требование 6 : должна обеспечиваться безопасность при разработке и поддержке систем и приложений.

Данное обобщенное требование содержит 24 требования и 32 соответствующие им процедуры оценки, регламентирующие вопросы поддержки и обновления систем и регламентирующие вопросы разработки.

Реализация данных требований обычно вызывает серьезные сложности по ряду причин:

1) в большинстве российских компаний обновления безопасности на внутренние серверы, особенно на базы данных, практически никогда не ставились, так как, по мнению администраторов, безопасность обеспечивают внешние межсетевые экраны, а любое обновление может нарушить работоспособность системы, что чревато намного большими проблемами, чем гипотетический взлом. К сожалению, эту логику администраторов вполне понимают и злоумышленники. И, как правило, очень успешно используют уязвимость внутренних серверов для получения доступа к данным пластиковых карт;

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

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

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

Для веб-приложений и этого недостаточно - для дополнительной защиты необходимо устанавливать специальные межсетевые экраны перед веб-серверами или проводить специализированные проверки кода ежегодно.

Реализация мер по строгому контролю доступа

Требование 7: доступ к данным держателей карт должен быть ограничен в соответствии со служебной необходимостью.

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

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

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

Данное обобщенное требование содержит 18 требований и 25 соответствующих им процедур оценки, обеспечивающих две важные задачи безопасности - обеспечение мониторинга действий каждого пользователя в любой системе и снижение риска несанкционированного доступа с использованием чужого пароля. Для этого описаны требования по:

Длине, сложности и частоте смены паролей;

Использованию двухфакторной аутентификации при удаленном доступе;

Автоматической блокировке сеансов работы в случае бездействия пользователя;

Хранению паролей в системах в нечитаемом виде;

Удалению неиспользуемых учетных записей;

Запрету прямого доступа к базам данных, содержащим данные платежных карт для всех пользователей, за исключением администраторов СУБД.

Большинство требований достаточно просто реализуются штатными средствами операционных систем и баз данных, а для повышения уверенности, что все системные компоненты будут настроены корректно, настройки, обеспечивающие выполнение этих требований, рекомендуется включать в стандарты конфигурирования (см. Требование 2).

Требование 9 : физический доступ к данным держателей карт должен быть ограничен.

Данное обобщенное требование содержит 20 требований и 28 соответствующих им процедур оценки, регламентирующих вопросы физической защиты серверов и сетевого оборудования:

Систем видеонаблюдения и контроля доступа в помещения;

Визуальной идентификации посетителей;

Учета, контроля перемещения и защиты отчуждаемых носителей, содержащих данные платежных карт;

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

Обычно к моменту принятия решения о внедрении стандарта PCI DSS большинство требований данного раздела в банковской организации уже выполняется. Особенно в случае, если банк занимается выпуском платежных карт самостоятельно - ведь для выпуска платежных карт предъявлены намного более серьезные требования по физической защите помещений. Вместе с требованием 5 (антивирусная защита) это требование является наиболее простым и понятным в реализации. Особенно если сравнивать его с требованием 3 (защита данных платежных карт) и требованием 10 (протоколирование и мониторинг доступа).

Регулярный мониторинг и тестирование сетей

Требование 10 : должен отслеживаться и контролироваться любой доступ к сетевым ресурсам и данным держателей карт.

Данное обобщенное требование содержит 27 требований и 29 соответствующих им процедур оценки, регламентирующих вопросы протоколирования и мониторинга событий, включая особенности:

Перечня и состава протоколируемых событий;

Удаленного хранения и защиты собранных журналов аудита;

Синхронизации времени между источниками событий и системой мониторинга;

Периода хранения журналов аудита.

Практика показывает, что одна из самых серьезных проблем на пути к соответствию PCI DSS - организация процесса мониторинга событий ИБ. C точки зрения стандарта организовать процесс можно различными способами: централизованно/децентрализованно, средствами автоматизации или без оных и т. п. Для обычного российского банка, имеющего собственный процессинг, организация мониторинга событий информационной безопасности могла бы выглядеть так:

Сбор событий автоматизирован;

Мониторинг в рабочее время обеспечивает квалифицированный сотрудник из подразделения безопасности;

В ночное время реагирование обеспечивается только на наиболее критичные события, которые поступают дежурному сотруднику и от которого не требуется знаний по ИБ, а требуется реагирование по инструкции (в норме задействуются уже существующие круглосуточные службы поддержки пользователей).

Необходимо отметить важные особенности системы мониторинга событий ИБ применительно к задачам обеспечения и поддержания соответствия стандарту.

1. В систему мониторинга должны собираться события ИБ от всех типов ресурсов в области действия стандарта:

Операционных систем серверов;

Сетевое оборудование;

Веб-серверы (если используются для обработки карт);

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

2. Настройки протоколирования данных ресурсов должны обеспечивать регистрацию (а система мониторинга, в свою очередь, - сбор, обработку и хранение) всех типов событий, приведенных в п. 10.2.1- 10.2.7 стандарта PCI DSS (если имеют смысл для данного типа ресурса), а именно:

Доступ к данным платежных карт (специфично для каждой из форм хранения данных - либо файлы, либо объекты базы данных);

Успешное использование привилегированных административных полномочий и управление системными объектами (управление учетными записями и их правами, старт/остановка сервисов, конфигурирование сетевого оборудования, изменение параметров аудита, изменение протоколов аудита, изменение реестра операционной системы, изменение словарей и сегментов базы данных, создание/монтирование в операционной системе устройств/каналов и др.);

Все события, связанные с работой систем аутентификации (успешный вход в систему, ошибки аутентификации пользователей, ошибки и сбои системы аутентификации);

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

3. В систему мониторинга должны также попадать сообщения от специализированных средств защиты (или мониторинг событий от них организуется децентрализованно):

Межсетевые экраны;

Средства антивирусной защиты;

Средства контроля целостности и др.

4. Должен обеспечиваться совокупный период хранения зарегистрированных событий информационной безопасности не менее одного года при включенном уровне протоколирования событий на источниках согласно требованиям 10.2.1-10.2.7 стандарта PCI DSS (см. пункт 2 данного списка). Если хранить такой объем событий в системе невозможно (в связи с их объемом и стоимостью хранилища), нужно продумывать решение по архивированию событий (в ручном или автоматическом режиме).

Требование 11 : должно выполняться регулярное тестирование систем и процессов обеспечения безопасности.

Данное обобщенное требование содержит 9 требований и 23 соответствующих им процедуры оценки, регламентирующие аспекты периодического тестирования защищенности и частично вопросы обнаружения потенциальных несанкционированных вторжений/изменений в системах, в частности:

Необходимость ежеквартального (или при изменении конфигурации сети или защищаемых серверов) внешнего сканирования с привлечением сертифицированной организации;

платежных систем и расчетов

Необходимость ежеквартального (или при изменении конфигурации сети или защищаемых серверов) внутреннего сканирования уязвимостей с использованием специальных программных средств;

Выявление несанкционированных беспроводных точек доступа;

Выявление несанкционированной активности в сети и/или изменения в файловых системах серверов;

Проведение ежегодных (или при изменении конфигурации сети или защищаемых серверов) внутренних и внешних тестов на проникновение.

Особенностью выполнения этих требований является то, что банку недостаточно просто провести сканирование или заказать тест на проникновение. Требование считается выполненным только в том случае, если в ходе тестирования/сканирования не было обнаружено серьезных уязвимостей. И при этом были протестированы все серверы/устройства и службы, которые входят в область применения стандарта. Более того, к моменту ежегодной проверки нужно показать, что на протяжении всего прошлого года своевременно проводились сканирования и оперативно устранялись уязвимости (в случае их наличия). Внутренние сканирования и тесты на проникновения могут проводиться любыми квалифицированными сотрудниками - как изнутри компании, так и приглашенными извне, тогда как внешнее сканирование должно проводиться сертифицированной компанией, имеющей статус Approved Scanning Vendor (ASV).

Поддержание политики информационной безопасности

Требование 12 : должна поддерживаться политика, регламентирующая деятельность всех сотрудников.

Данное обобщенное требование содержит 36 требований и 39 соответствующих им процедур оценки, регламентирующих аспекты нормативно правового обеспечения информационной безопасности, и организации защиты, включая:

Наличие политики безопасности и процедур, описывающих типовые операции обеспечения защиты;

Документированное распределение ответственности за различные аспекты обеспечения безопасности, мониторинга и контроля;

Наличие программы повышения осведомленности и обучения сотрудников в вопросах обеспечения защиты;

Проверку сотрудников на благонадежность перед принятием на работу;

Контроль договорных обязательств в части защиты при передаче данных платежных карт сторонним организациям;

Документирование и периодическое тестирование и обновление плана реагирования на инциденты безопасности;

Обеспечение круглосуточного мониторинга и реагирования на инциденты информационной безопасности.

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