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

FAQ по PCI DSS для тех, кто интересуется сертификацией

# На кого распространяются требования стандарта 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

Внешний аудит QSA (Qualified Security Assessor)	Внутренний аудит ISA (Internal Security Assessor)	Самооценка SAQ (Self Assessment Questionnaire)
Выполняется внешней аудиторской организацией QSA , сертифицированной Советом PCI SSС.	Выполняется внутренним прошедшим обучение и сертифицированным по программе Совета PCI SSC аудитором .Может быть проведен только в случае, если первично соответствие было подтверждено QSA-аудитом.	Выполняется самостоятельно путём заполнения листа самооценки.
В результате проверки QSA -аудиторы собирают свидетельства выполнения	В результате проверки ISA -аудиторы , как и при внешнем аудите, собирают свидетельства выполнения требований стандарта и сохраняют их в течение трёх лёт.	Сбор свидетельств выполнения требований стандарта не требуется.
По результатам проведённого аудита подготавливается отчёт о соответствии - ROC (Report on Compliance).	Самостоятельно заполняется лист самооценки SAQ .

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

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

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

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

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

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

Рисунок 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

Внимание! Эта статья о шине PCI и её производных PCI64 и PCI-X("Пи-си-ай Икс")! Не путайте её с более новой шиной ("Пи-си-ай Экспресс"), которая полностью несовместима с шинами, описанными в данном FAQ.

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

PCI 2.1 - отличалась от 2.0 возможностью одновременной работы нескольких bus-master устройств (т.н. конкурентный режим), а также появлением универсальных карт расширения, способных работать как в 5В, так и в 3.3В слотах. Способность работать с 3.3В картами и наличие соответствующих линий питания в версии 2.1 являлась опциональной.Появились расширения PCI66 и PCI64.

PCI 2.2 - версия базового стандарта шины, допускающая подключение карт расширения с сигнальным напряжением как 5В, так и 3.3В. 32-битные версии этих стандартов являлись наиболее распространённым типом слотов на на момент написания FAQ. Используются слоты типа 32-бита, 5В.
Cделанные в соответствии с этими стандартами карты расширения имеют универсальный разъём и способны работать практически во всех более поздних разновидностях слотов шины PCI, а также, в некоторых случаях, и в слотах 2.1.

PCI 2.3 - следующая версия общего стандарта на шину PCI, слоты расширения, соответствующие этому стандарту, несовместимы с картами PCI 5В, несмотря на продолжающееся использование 32-битных слотов с 5В-ключом. Карты расширения имеют универсальный разъём, но не способны работать в 5В-слотах ранних версий (до 2.1 включительно).
Напоминаем, что напряжение питания (не сигнальное!) 5В сохраняется абсолютно на всех версиях разъёмов шины PCI.

PCI 64 - расширение базового стандарта PCI, появившееся в версии 2.1, удваивающее число линий данных, и, следовательно, пропускную способность. Cлот PCI64 является удлинённой версией обычного PCI-слота. Формально совместимость 32-битных карт с 64-битным слотами (при условии наличия общего поддерживаемого сигнального напряжения) полная, а совместимость 64-битной карты с 32-битным слотами является ограниченной (в любом случае произойдёт потеря производительности), точные данные в каждом конкретном случае можно узнать из спецификаций устройства.
Первые версии PCI64 (производные от PCI 2.1)использовали слот PCI 64-бита 5В и работали на тактовой частоте 33МГц.

PCI 66 - появившееся в версии 2.1 расширение стандарта PCI с поддержкой тактовой частоты 66МГц, также, как и PCI64 позволяет удвоить пропускную способность. Начиная с версии 2.2 использует 3.3В-слоты (32-битный вариант на ПК практически не встречается), карты имеют универсальный либо 3.3В форм-фактор. (Имелись и основанные на версии 2.1 казуистически редкие на рынке ПК 5В 66МГц решения, подобные слоты и платы были совместимы только между собой)

PCI 64/66 - комбинация двух вышеописанных технологий, позволяет учетверить скорость передачи данных по сравнению с базовым стандартом PCI, и использует 64 бита 3.3В слоты, совместимые только с универсальными и 3.3В 32-битными картами расширения. Карты стандарта PCI64/66 имеют универсальный (имеющий ограниченную совместимость с 32-битными слотами) либо 3.3В форм-фактор(последний вариант принципиально не совместим с 32-битными 33МГц слотами популярных стандартов)
В настоящее время под термином PCI64 подразумевается именно PCI64/66, поскольку 33МГц 5В 64-битные слоты не применяются уже достаточно давно.

PCI-X 1.0 - Расширение PCI64 с добавлением двух новых частот работы, 100 и 133МГц, а также механизма раздельных транзакций для улучшения производительности при одновременной работе нескольких устройств. Как правило, обратно совместима со всеми 3.3В и универсальными PCI-картами.
PCI-X карты обычно выполняются в 64-бит 3.3В формате и имеют ограниченную обратную совместимость со слотами PCI64/66, а некоторые PCI-X карты - в универсальном формате и способны работать (хотя практической ценности это почти не имеет) в обычном PCI 2.2/2.3.
В сложных случаях для того, чтобы быть полностью уверенным в работоспособности выбранной вами комбинации из мат.платы и карты расширения, случае надо посмотреть таблицы совместимости (compatibility lists) производителей обоих устройств.

PCI-X 2.0 - дальнейшее расширение возможностей PCI-X 1.0, добавлены скорости в 266 и 533МГц, а также коррекция ошибок чётности при передаче данных.(ECC). Допускает расщепление на 4 независимых 16-битных шины, что применяется исключительно во встраиваемых и промышленных системах, сигнальное напряжение снижено до 1.5В, но сохранена обратная совместимость разъёмов со всеми картами, использующими сигнальное напряжение 3.3В.

PCI-X 1066/PCI-X 2133 - проектируемые будущие варианты шины PCI-X, c результирующими частотами работы 1066 и 2133МГц соответственно, изначально предназначенные для подключения 10 и 40Гбит Ethernet адаптеров.

Для всех вариантов шины PCI-X существуют следующие ограничения по количеству подключаемых к каждой шине устройств:
66МГц - 4
100МГц - 2
133МГц - 1 (2, если одно или оба устройства не находятся на платах расширения, а уже интегрированы на одну плату вместе с контроллером)
266,533МГц и выше -1.

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

СompactPCI - стандарт для разъёмов и карт расширения, применяемый в промышленных и встраиваемых компьютерах. Механически не совместим ни с одним из "общих" стандартов.

MiniPCI - стандарт для плат и разъёмов для интеграции в ноутбуки (обычно используется для адаптеров беспроводной сети) и непосредственно на поверхность . Также механически ни с чем кроме себя не совместим.

Типы PCI-карт расширения:

Сводная таблица конструктивов карт и слотов в зависимости от версии стандарта:

Cводная таблица совместимости карт и слотов в зависимости от версии и конструктива:

	Карты
Слоты	PCI 2.0/2.1 5B	PCI 2.1 универсальный	PCI 2.2/2.3 универсальный	PCI64/5B (33МГц)	PCI64/универсальный	PCI64/3.3B	PCI-X/3.3B	PCI-X универсальный
PCI 2.0	Совместимы	Совместимы	Несовместимы		Ограниченно совместимы с потерей производительности	Несовместимы
PCI 2.1	Совместимы	Совместимы	Ограниченно совместимы	Ограниченно совместимы с потерей производительности	Ограниченно совместимы с потерей производительности	Несовместимы
PCI 2.2	Совместимы			Ограниченно совместимы с потерей производительности	Ограниченно совместимы с потерей производительности	Несовместимы	Несовместимы	Ограниченно совместимы с потерей производительности
PCI 2.3	Несовместимы	Ограниченно совместимы	Совместимы	Несовместимы	Ограниченно совместимы с потерей производительности	Несовместимы	Несовместимы	Ограниченно совместимы с потерей производительности
PCIБ 64/5B(33МГц)	Совместимы	Совместимы	Ограниченно совместимы	Совместимы	Ограниченно совместимы с потерей производительности	Несовместимы	Несовместимы	Ограниченно совместимы с потерей производительности
PCI64/3.3B	Несовместимы	Ограниченно совместимы	Совместимы	Несовместимы	Совместимы	Совместимы	Ограниченно совместимы с потерей производительности	Ограниченно совместимы с потерей производительности
PCI-X	Несовместимы	Ограниченно совместимы	Совместимы	Несовместимы	Совместимы

О стандарте

PCI DSS (Payment Card Industry Data Security Standard) - стандарт безопасности данных индустрии платёжных карт, разработанный Советом по стандартам безопасности индустрии платёжных карт (Payment Card Industry Security Standards Council, PCI SSC), который учредили Visa, MasterCard, American Express, JCB и Discover.

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

PCI DSS - комплексное руководство по безопасности

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

Совет PCI DSS сформулировал ключевые требования по организации защиты данных в документе «Стандарт безопасности данных индустрии платёжных карт (PCI DSS). Требования и процедуры оценки безопасности. Версия 3.0». Эти требования сгруппированы таким образом, чтобы упростить процедуру аудита безопасности.

Скачать PCI DSS на русском языке.

Требования и процедуры оценки безопасности PCI DSS

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

• Требование 1. «Установить и поддерживать конфигурацию межсетевых экранов для защиты данных о держателях карт».
• Требование 2. «Не использовать пароли к системам и другие параметры безопасности, заданные производителем по умолчанию».

Защищать данные о держателях карт

• Требование 3. «Защищать хранимые данные о держателях карт».
• Требование 4. «Шифровать данные о держателях карт при их передаче через общедоступные сети».

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

• Требование 5. «Защищать все системы от вредоносного ПО и регулярно обновлять антивирусное ПО».
• Требование 6. «Разрабатывать и поддерживать безопасные системы и приложения ».

Внедрять строгие меры контроля доступа

• Требование 7. «Ограничивать доступ к данным о держателях карт в соответствии со служебной необходимостью».
• Требование 8. «Идентифицировать и аутентифицировать доступ к системным компонентам».
• Требование 9. «Ограничивать физический доступ к данным о держателях карт».

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

• Требование 10. «Отслеживать и вести мониторинг всего доступа к сетевым ресурсам и данным о держателях карт».
• Требование 11. «Регулярно тестировать системы и процессы безопасности»

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

• Требование 12. «Поддерживать политику информационной безопасности для всех работников».

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

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

Что такое PCI DSS?

PCI DSS – это сокращение от Payment Card Industry Data Security Standard, что означает – стандарт безопасности данных индустрии платёжных карт. Стандарт PCI DSS был разработан советом PCI SSC (Payment Card Industry Security Standards Council, что в переводе означает Совет по стандартам безопасности индустрии платежных карт). Члены-основатели совета PCI SSC - международные платёжные системы Visa, MasterCard, American Express, JCB International и Discover Financial Services – согласились принять общий стандарт безопасности в качестве части технических требований для каждой из их программ соответствия безопасности данных. Кроме того каждый член-основатель признает квалифицированных советом PCI SSC аудиторов систем безопасности (Qualified Security Assessors, QSA) и утверждённых поставщиков услуг сканирования (Approved Scanning Vendors, ASV). К последним относится наш партнер Comodo , чей лицензированный сервис сканирования HackerGuardian PCI Scanning Service в ближайшее время будет доступен для заказа на нашем сайте.

Кому нужна сертификация PCI DSS?

О безопасности данных платежных карт должны заботиться все, кто работает с платежными картами или каким-либо образом влияет на их безопасность, а это могут быть:

• Торгово-сервисные компании любого размера
• Финансовые учреждения
• Поставщики кассовых терминалов
• Производители технических средств ЭВМ и программного обеспечения, словом, все кто создает и использует международную инфраструктуру для обработки платежей.

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

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

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

Контрольные объекты	Требования PCI DSS
Создание и поддержка безопасной сети	1. Установка и поддержка конфигурации файервола для защиты данных владельцев платежных карт
	2. Отказ от использования,параметров по умолчанию для систем паролей и других параметров безопасности
Защита данных владельцев платежных карт	3. Защита полученных данных владельцев платежных карт
	4. Шифрование передачи данных владельцев платежных карт по открытым публичным сетям
Поддержка программы по управлению уязвимостями	5. Использование и регулярное обновление антивирусного ПО на всех системах, которые обычно подвергаются действию вредоносных программ
	6. Разработка и поддержка защищенных систем и приложений
Внедрение строгого контроля доступа	7. Ограничение доступа к данным владельцев платежных карт по принципу служебной необходимости
	8. Присвоение уникального идентификационного номера каждому человеку с доступом к ЭВМ
	9. Ограничение физического доступа к данным владельцев платежных карт
Регулярный мониторинг и проверка сетей	10. Отслеживание и мониторинг доступа к ресурсам сетей и данным владельцев платежных карт
	11. Регулярная проверка систем и процессов безопасности
Поддержка политики безопасности информации	12. Поддержка политики, адресованной на обеспечение безопасности данных

Прочитать наиболее актуальные и полные стандарты PCI DSS можно на официальном сайте Совета по стандартам безопасности по ссылке: https://ru.pcisecuritystandards.org

Уровни сертификации PCI DSS

Сертификация PCI DSS определяет четыре уровня торгово-сервисных предприятий и два уровня поставщиков услуг в зависимости от количества проводимых транзакций с платежными картами Visa (включая кредитные, дебетовые и предоплаченные карты) в течение 12 месяцев.

Visa определяет следующие уровни торгово-сервисных предприятий:

Уровень	Описание	Сертификация PCI DSS включает:
4	Торгово-сервисные предприятия, обрабатывающие менее 20 тыс. транзакций в год в области электронной торговли, а также Все остальные торгово-сервисные предприятия, не перечисленные в остальных уровнях, которые обрабатывают до 1 млн. транзакций в год, независимо от канала их получения.	Ежегодно: рекомендовано заполнение анкеты самооценки безопасности (SAQ); Ежеквартально: рекомендовано ASV-сканирование; Банк-эквайер определяет требования соответствия.
3	Торгово-сервисные предприятия, обрабатывающие 20 тыс. - 1 млн. транзакций в области электронной торговли в год.
2	Торгово-сервисные предприятия, обрабатывающие 1-6 млн. транзакций в год, независимо от канала их получения.	Ежегодно: заполнение анкеты самооценки безопасности (SAQ); Ежеквартально: рекомендовано ASV-сканирование.
1	Торгово-сервисные предприятия, которые обрабатывают более 6 млн. транзакций в год, независимо от канала их получения.	Ежегодно: аудит, выполняемый утвержденным аудитором систем безопасности (QSA-аудит); Ежеквартально: ASV-сканирование на наличие уязвимостей.

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

Правила и рамки информационного пентестинга представлены в методологиях
OSSTMM и OWASP . Впоследствии полученные данные можно легко
адаптировать для проведения оценки соответствия с какими-либо промышленными
стандартами и "лучшими мировыми практиками", такими как, Cobit ,
стандартами серии ISO /IEC 2700x , рекомендациями CIS /SANS /NIST /etc
и – в нашем случае – стандартом PCI DSS .

Безусловно, накопленных данных, полученных в процессе тестирования на
проникновение, для проведения полноценной оценки по промышленным стандартам
будет недостаточно. Но на то он и пентест, а не аудит. Кроме того, для
осуществления такой оценки в полном объеме одних лишь технологических данных по
любому будет мало. Для полноценной оценки требуется интервьюирование сотрудников
различных подразделений оцениваемой компании, анализ распорядительной
документации, различных процессов ИТ/ИБ и много еще чего.

Что касается тестирования на проникновение в соответствии с требованиями
стандарта по защите информации в индустрии платежных карт, – он не намного
отличается от обычного тестирования, проводимого с использованием методик
OSSTMM и OWASP . Более того, стандартом PCI DSS рекомендуется
придерживаться правил OWASP при проведении как пентеста (AsV), так и
аудита (QSA).

Основные отличия тестирования по PCI DSS от тестирования на
проникновение в широком смысле этого слова заключаются в следующем:

1. Стандартом не регламентируется (а значит и не требуется) проведение атак с
   использованием социальной инженерии.
2. Все проводимые проверки должны максимально минимизировать угрозу "Отказа в
   обслуживании" (DoS). Следовательно, проводимое тестирование должно
   осуществляться методом "серого ящика" с обязательным предупреждением
   администраторов соответствующих систем.
3. Основная цель такого тестирования – это попытка осуществления
   несанкционированного доступа к данным платежных карт (PAN, Cardholder Name и
   т.п.).

Под методом "серого ящика" (gray box) подразумевается выполнение различного
рода проверок с предварительным получением дополнительной информации об
исследуемой системе на разных этапах тестирования. Это позволяет снизить риск
отказа в обслуживании при проведении подобных работ в отношении информационных
ресурсов, функционирующих в режиме 24/7.

В общем случае тестирование на проникновение по требованиям PCI должно
удовлетворять следующим критериям:

• п.11.1(b) – Анализ защищенности беспроводных сетей
• п.11.2 – Сканирование информационной сети на наличие уязвимостей (AsV)
• п.11.3.1 – Проведение проверок на сетевом уровне (Network-layer
  penetration tests)
• п.11.3.2 – Проведение проверок на уровне приложений (Application-layer
  penetration tests)

На этом теория заканчивается, и мы переходим к практике.

Определение границ проводимого исследования

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

• сегментация сети (пользовательская, технологическая, ДМЗ, процессинг и
  т.д.);
• межсетевое экранирование на границах подсетей (ACL/МСЭ);
• используемые Web-приложения и СУБД (как тестовые, так и продуктивные);
• используемые беспроводные сети;
• какие-либо детали обеспечения безопасности, которые необходимо учесть в
  ходе проведения обследования (например, блокировка учетных записей при N
  попытках неправильной аутентификации), особенности инфраструктуры и общие
  пожелания при проведении тестирования.

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

Network-layer penetration tests

Для начала стоит провести анализ пробегающего мимо сетевого трафика с помощью
любого сетевого анализатора в "неразборчивом" режиме работы сетевой карты
(promiscuous mode). В качестве сетевого анализатора для подобных целей
замечательно подходит или CommView. Чтобы выполнить этот этап, хватит 1-2 часов работы
снифера. По прошествии этого времени накопится достаточно данных для проведения
анализа перехваченного трафика. И в первую очередь при его анализе следует
обратить внимание на следующие протоколы:

• протоколы коммутации (STP, DTP и т.п.);
• протоколы маршрутизации (RIP, EIGRP и т.д.);
• протоколы динамической конфигурации узла (DHCP, BOOTP);
• открытые протоколы (telnet, rlogin и т.п.).

Что касается открытых протоколов, – вероятность того, что они попадутся во
время снифания проходящего мимо трафика в коммутируемой сети, достаточно мала.
Однако, если такого трафика много, то в обследуемой сети явно наблюдаются
проблемы в настройках сетевого оборудования.

Во всех остальных случаях присутствует возможность проведения красивых атак:

• классической атаки MITM (Man in the middle) в случае, когда используется
  DHCP, RIP
• получение роли корневого узла STP (Root Bridge), что позволяет
  перехватывать трафик соседних сегментов
• перевод порта в магистральный режим с помощью DTP (enable trunking);
  позволяет перехватывать весь трафик своего сегмента
• и др.

Для реализации атак на протоколы коммутации доступен замечательный инструмент
Yersinia. Предположим, что в процессе анализа трафика были выявлены пролетающие
мимо DTP-пакеты (смотри скриншот). Тогда отправка пакета DTP ACCESS/DESIRABLE
может позволить перевести порт коммутатора в магистральный режим. Дальнейшее
развитие этой атаки позволяет прослушивать свой сегмент.

После тестирования канального уровня стоит переключить внимание на третий
уровень OSI. Дошла очередь и до проведения атаки ARP-poisoning. Тут все просто.
Выбираем инструмент, например,

и обговариваем с сотрудниками ИБ детали проведения этой атаки (в том числе,
необходимость в проведении атаки, направленной на перехват одностороннего SSL).
Все дело в том, что в случае успешной реализации атаки ARP-poisoning в отношении
всего своего сегмента может наступить ситуация, когда компьютер атакующего не
справится с потоком поступающих данных и, в конечном счете, это может стать
причиной отказа в обслуживании целого сегмента сети. Поэтому наиболее правильным
будет выбрать единичные цели, например, рабочие места администраторов и/или
разработчиков, какие-либо определенные сервера (возможно контроллер домена,
СУБД, терминальный сервер, etc).

Успешно проведенная атака ARP-poisoning позволяет получить в открытом виде
пароли к различным информационным ресурсам – СУБД, каталогу домена (при
понижении проверки подлинности NTLM), SNMP-community string и пр. В менее
удачном случае могут быть получены хеш-значения от паролей к различным системам,
которые нужно будет за время проведения пентеста постараться восстановить по
радужным таблицам (rainbow tables), по словарю или атакой "в лоб". Перехваченные
пароли могут использоваться где-то еще, и впоследствии это также необходимо
подтвердить или опровергнуть.

Кроме того, стоит проанализировать весь перехваченный трафик на присутствие
CAV2/CVC2/CVV2/CID/PIN, передаваемых в открытом виде. Для этого можно пропустить
сохраненный cap-файл через NetResident и/или
.
Второй, кстати, замечательно подходит для анализа накопленного трафика в целом.

Application-layer penetration tests

Переходим на четвертый уровень OSI. Тут, в первую очередь, все сводится к
инструментальному сканированию обследуемой сети. Чем его проводить? Выбор не так
уж и велик. Первоначальное сканирование можно выполнить с использованием Nmap в
режиме "Fast scan" (ключи -F -T Aggressive|Insane), а на следующих этапах
тестирования проводить сканирование по определенным портам (ключ -p), например,
в случаях обнаружения наиболее вероятных векторов проникновения, связанных с
уязвимостями в определенных сетевых сервисах. Параллельно стоит запустить сканер
безопасности – Nessus или XSpider (у последнего результаты помясистей будут) в
режиме выполнения только безопасных проверок. При проведении сканирования на
уязвимости необходимо также обращать внимание на присутствие устаревших систем
(например, Windows NT 4.0), потому как стандартом PCI запрещается их
использование при обработке данных держателей карт.

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

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

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

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

1. Эксплуатация уязвимостей в сетевых сервисах

В далеком прошлом осталось время, когда эксплоитинг был уделом избранных,
способных хотя бы собрать чужой код и (о Боже!) подготовить свой шелл-код.
Сейчас эксплуатация уязвимостей в сетевых сервисах, таких как переполнение
буфера и иже с ними, доступна каждому. Причем, процесс все больше напоминает
игру в жанре "квест". Взять хотя бы Core Impact, в котором весь пентест сводится
к клацанью мышкой по различным выпадающим менюшкам в красивой GUI-обертке.
Подобный инструментарий здорово экономит время, которого при внутреннем пентесте
не так уж и много. Потому шутки шутками, а фичисет, реализованный в Core Impact,
позволяет, особо не утруждаясь, последовательно выполнить эксплуатацию, поднятие
привилегий, сбор информации и удаление следов своего пребывания в системе. В
связи с чем Core Impact пользуется особой популярностью у западных аудиторов и
пентестеров.

Из общедоступных инструментов подобного рода можно упомянуть следующие
сборки: Core Impact, CANVAS, SAINTexploit и всеми любимый Metasploit Framework.
Что касается первой тройки, – это все коммерческие продукты. Правда, некоторые
старые версии коммерческих сборок утекали в свое время в интернет. При желании
можно отыскать их в глобальной сети (естественно, исключительно с целью
самообразования). Ну а весь бесплатный свежачок сплоитов доступен и в Metasploit
Framework. Конечно, существуют zero-day сборки, но это уже совсем другие деньги.
Кроме того, бытует спорное мнение, что при проведении пентеста их использование
является не совсем честным.

На основе данных сетевого сканирования можно немного поиграть в хакеров:).
Предварительно согласовав список мишеней, провести эксплуатацию обнаруженных
уязвимостей, а после выполнить поверхностный локальный аудит захваченных систем.
Собранная на уязвимых системах информация может позволить повысить свои
привилегии и на других ресурсах сети. То есть, если в процессе проведения атаки
ты порутал винду, то не лишним будет снять с нее базу SAM (fgdump) для
последующего восстановления паролей, а также секреты LSA (Cain&Abel), в которых
зачастую может храниться в открытом виде много полезной информации. К слову,
после проведения всех работ собранная информация о паролях может расцениваться в
контексте соответствия или несоответствия требованиям стандарта PCI DSS (п. 2.1,
п.2.1.1, п.6.3.5, п.6.3.6, п.8.4, п.8.5.x).

2. Анализ разграничения доступа

Анализ разграничения доступа необходимо выполнять на всех информационных
ресурсах, на которые удалось реализовать НСД. И на общих файловых ресурсах
Windows (SMB), на которых открыт анонимный доступ – тоже. Зачастую это позволяет
получить дополнительную информацию о ресурсах, которые не были обнаружены во
время сетевого сканирования, или наткнуться на другую информацию, различной
степени конфиденциальности, хранимую в открытом виде. Как я уже говорил, при
проведении тестирования по PCI, в первую очередь, поиск направлен на обнаружение
данных держателя карт. Поэтому важно понимать, как могут выглядеть эти данные и
искать их во всех информационных ресурсах, к которым имеется соответствующий
доступ.

3. Атака типа брутфорс

Необходимо, как минимум, проверить дефолты и простые комбинации логин-пароль.
Подобные проверки требуется провести, прежде всего, в отношении сетевого
оборудования (в том числе, для SNMP) и интерфейсов удаленного администрирования.
При проведении AsV-сканирования по PCI DSS не разрешается осуществлять "тяжелый"
брутфорс, который может привести к состоянию DoS. Но в нашем случае речь идет
про внутренний пентест по PCI, а потому в разумном виде и без фанатизма стоит
осуществить атаку по подбору простых комбинаций паролей к различным
информационным ресурсам (СУБД, WEB, ОС и т.п.).

Очередной этап – это анализ защищенности Web-приложений. При пентесте по PCI
про глубокий анализ Web речи не идет. Оставим это QSA-аудиторам. Здесь
достаточно осуществить blackbox-сканирование с выборочной верификацией
эксплуатабельных server/client-side уязвимостей. В дополнение к уже упомянутым
сканерам безопасности можно воспользоваться сканерами, заточенными под анализ
Web. Идеальное решение – это, безусловно, HP WebInspect или
(который, кстати, на "отлично" детектит баги в AJAX). Но все это –
дорогая и непозволительная роскошь, а раз так, то нам подойдет и w3af, который в
последнее время набирает обороты в плане детектирования различного рода
уязвимостей в Web-приложениях.

По поводу ручной верификации уязвимостей в Web! Необходимо, как минимум,
проверить механизмы аутентификации и авторизации, использование простых
комбинаций логин-пароль, дефолтов, а также всеми любимые SQL–инъекции,
инклудинг-файлов и выполнение команд на сервере. Что касается client-side
уязвимостей, то, кроме верифицирования возможности эксплуатации уязвимости, тут
более ничего не требуется. А вот с server-side необходимо немного повозиться,
ибо все-таки пентест, хоть и по PCI DSS. Как я отмечал ранее, мы ищем PAN,
Cardholder Name и CVC2/CVV2 опционально. Вероятнее всего, подобные данные
содержатся в СУБД, а потому в случае нахождения SQL-инъекции стоит оценить имена
таблиц, колонок; желательно сделать несколько тестовых выборок, чтобы
подтвердить или опровергнуть присутствие подобных данных в базе в
незашифрованном виде. Если столкнулся с Blind SQL-иъекцией, то лучше натравить
на Web-сервер (с
ключом --dump-all), который на текущий момент работает с MySQL, Oracle,
PostgreSQL и Microsoft SQL Server. Этих данных будет достаточно для демонстрации
использования уязвимости.

Дальнейший этап – это анализ защищенности СУБД. Опять же, есть отличный
инструмент – AppDetective от "Application Security Inc.", но это дорогое
удовольствие. К сожалению, аналогичного сканера безопасности, который бы выдавал
такой объем информации, как это умеет AppDetective, и поддерживал столько же
СУБД, в настоящее время не существует. И потому приходится брать на вооружение
множество отдельных, несвязанных между собой продуктов, которые заточены под
работу с определенными вендорами. Так, для ораклятины минимальный набор
пентестера будет следующим:

• Oracle Database Client – окружение для работы с СУБД
• Toad for Oracle – клиент для работы с PL/SQL
• Oracle Assessment Kit – брут пользователей и SID’ов баз
• различные сценарии на языке PL/SQL (например, аудит конфигурации или
  возможность спуститься на уровень выполнения команд ОС)

Заключительный этап тестирования на проникновения по PCI – это анализ
защищенности беспроводных сетей, вернее, даже не анализ, а поиск точек доступа,
использующих уязвимые конфигурации, таких как Open AP, WEP и WPA/PSK. С другой
стороны, стандарт PCI не запрещает проводить более глубокий анализ, в том числе
с восстановлением ключей для подключения к беспроводной сети. Потому имеет смысл
осуществить подобного рода работы. Основным же инструментом на этом этапе,
конечно, будет aircrack-ng. Дополнительно можно провести атаку, направленную на
беспроводных клиентов, известную как "Caffe Latte", с использованием все того же
инструмента. При проведении обследования беспроводных сетей можно смело
руководствоваться данными с сайта
Wirelessdefence.org .

Вместо заключения

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

WWW

pcisecuritystandards.org - PCI Security Standards Council.
pcisecurity.ru – портал,
посвященный PCI DSS от Информзащиты.
pcidss.ru – портал, посвященный
PCI DSS от Digital Security.
isecom.org/osstmm - Open
Source Security Testing Methodology Manual.
owasp.org - Open Web Application
Security Project.