Соответствие стандарту pci. Подготовка к сертификации PCI DSS

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

Андрей Гайко
Сертифицированный QSA-аудитор Digital Security

Что такое mPOS

Мобильное платежное решение (mPOS) состоит из следующих основных компонентов:

• мобильное устройство – смартфон или планшет, к которому подключается считывающее устройство;
• платежное приложение для мобильного устройства – программное обеспечение, через интерфейс которого продавец производит ввод данных для оплаты и обмен данными с процессингом. Также через данное ПО возможна верификация владельца карты с использованием подписи;
• считывающее устройство – выделяются два вида считывающих устройств: Pin Entry Device (PED), устройство считывания карты и ввода PIN-кода. Подключается к мобильному устройству посредством Bluetooth, через аудиоразъем или mini-USB; Secure Card Reader (SCR), устройство считывания карты. Обычно подключается к мобильному устройству через аудиоразъем.

Под мобильным платежным решением будем понимать программно-аппаратную платформу для торгово-сервисных предприятий (далее – ТСП), позволяющую принимать платежи от физических лиц посредством смартфона/планшета и подключенного к нему считывающего устройства. Посредством mPOS возможно принимать оплату как бесконтактным способом (банковской картой, загруженной в мобильный телефон клиента с поддержкой NFC (далее – NFC-карта), или бесконтактной банковской картой), так и по обычным пластиковым картам (с магнитной полосой и/или EMV-чипом).

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

На стороне сервис-провайдера или банка-эквайера, которые занимаются приемом и дальнейшей обработкой данных при mPOS-платежах, используется back-end система (платежный шлюз), схожая с теми, что используются при интернет- или обычном POS-эквайринге.

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

Схема информационных потоков содержит 8 основных этапов (см. рис. 1):

• этап 1. Сотрудник ТСП подключает считывающее устройство к мобильному устройству (смартфону или планшету), имеющему интернет-соединение. Запускает специальное мобильное приложение и в нем вводит сведения о покупке и сумму платежа;
• этап 2. Клиент вставляет, прокатывает или подносит банковскую карту к считывающему устройству. В случае NFC-карты клиент на своем смартфоне открывает приложение "Кошелек" (Walet), выбирает действующую банковскую карту и подносит смартфон к считывающему устройству. В зависимости от параметров, заданных в карте, запрашивается ввод PIN-кода. В этом случае клиент вводит PIN-код посредством PIN-pad, который может быть встроен в считывающее устройство;
• этап 3. Считывающее устройство считывает карточные данные, шифрует их и передает в мобильное устройство сотрудника ТСП;
• этап 4. Мобильное устройство сотрудника отправляет зашифрованные данные в платежный шлюз, и из платежного шлюза данные передаются в эквайринговую систему. Кроме карточных данных, в зависимости от настроек, дополнительно могут быть переданы сведения о mPOS, транзакции, покупаемом товаре или услуге;
• этап 5. Авторизационный запрос из эквайринговой системы передается в МПС. После обработки запроса результат (принято или отклонено) возвращается в эквайринговую систему. Если карта, по которой происходит оплата, выпущена тем же банком, через который осуществляется эквайринг, то запрос в МПС не передается;
• этап 6. Результат авторизационного запроса передается в мобильное устройство;
• этап 7. Если для карты требуется подпись ее владельца, то в мобильном приложении выводится соответствующая форма, и клиент расписывается (стилусом или пальцем);
• этап 8. Сотрудник ТСП в мобильном платежном приложении выбирает метод отправки чека клиенту. Возможна отправка по SMS, электронной почте или на печать на локальное кассовое устройство.

В реализации описанного выше процесса могут участвовать следующие компании:

• разработчики mPOS-устройств – осуществляют разработку и выпуск аппаратных средств, которые безопасно считывают карточные данные и PIN-код;
• разработчики платежного ПО для мобильного устройства и/или платежного шлюза – разрабатывают клиентское ПО для ТСП и, возможно, ПО платежного шлюза;
• разработчики платформы – компании-разработчики, создающие единую аппаратную и программную часть mPOS-решения для ее дальнейшей продажи сервис-провайдерам mPOS-решений или эквайерам;
• сервис-провайдеры mPOS-решений – компании, выпускающие конечный продукт для ТСП. Компаниями данного типа являются банки-эквайеры или так называемые платежные посредники (payment facilitators). Эти компании могут либо самостоятельно разрабатывать все компоненты мобильного платежного решения, либо лицензировать отдельные компоненты разных производителей и интегрировать их между собой. Платежные посредники, за исключением банков-эквайеров, являются чем-то средним между сервис-провайдером и ТСП. Их клиентами являются ТСП, для которых взаимодействие с банком-эквайером становится прозрачным процессом, так как ответственность за расчеты с ТСП ложится на платежного посредника;
• дистрибьюторы – компании, продвигающие на рынке те или иные mPOS-решения различных производителей и выполняющие функцию перепродажи mPOS-решения ТСП;
• платежный сервис-провайдер (процессинговая компания, платежный шлюз) – компания, которая является посредником между сервис-провайдером mPOS-решений и банком-эквайером. Он обеспечивает информационное взаимодействие между мобильным устройством ТСП и эквайером;
• эквайер – банк-эквайер или процессинговый центр, подключенный к МПС, обеспечивающий авторизацию платежей. Банки-эквайеры, с которыми сотрудничают сервис-провайдеры mPOS-решений, могут использоваться для расчетов с ТСП.

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

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

Виды сертификации

Первые рекомендации по безопасности мобильных платежных решений были выпущены Visa в 2011 г. В них содержались общие рекомендации для разработчиков и ТСП в части безопасности использования мобильных платежных решений. В 2012 г. Советом PCI SSC были выпущены более детальные рекомендации для разработчиков. На сегодняшний день МПС и PCI SSC почти каждый год выпускают обновленные рекомендации по безопасности mPOS.

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

Стандарты PCI SSC

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

Несмотря на то, что выполнение большинства требований безопасности ложится на различных сервис-провайдеров и банки, банки-эквайеры вправе потребовать от ТСП заполнения листов самооценки (SAQ) соответствующего типа (SAQ P2PE-HW в случае использования ТСП P2PE-решения, SAQ B-IP в случае использования mPOS со считывателем, сертифицированным по PCI PTS). В таблице указаны компоненты mPOS-решений, соответствующий стандарт, которому компонент должен соответствовать, и компания, ответственная за реализацию требований.

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

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

PCI PTS
Стандарт PCI PTS регламентирует требования к безопасности для Point of interaction devices (POI) и Hardware Security Modules (HSM). Считывающее устройство, подключаемое к мобильному устройству, является POI. Как упоминалось выше, в mPOS-решениях используется два класса POI: PIN Entry Device (PED) и Secure Card Reader (SCR). В зависимости от того, к POI какого типа относится считывающее устройство, определяются группы требований PCI PTS, которым устройство должно соответствовать.

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

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

PA-DSS
Для mPOS-решений PA-DSS в обязательном порядке применим к прошивкам устройств, считывающим карточные данные. Для программного обеспечения, устанавливаемого на мобильное устройство сотрудника ТСП, данный стандарт является рекомендательным. Это связано с тем, что мобильное устройство является недоверенной и слабоконтролируемой средой. Например, на устройстве может быть выполнен jailbreak, который на порядок снижает безопасность устройства и не гарантирует безопасности установленного платежного приложения. Именно поэтому МПС запрещают использовать мобильные устройства для ввода PIN-кода и требуют, чтобы данные от считывающего устройства приходили в мобильное ПО в зашифрованном виде и далее в том же виде передавались в эквайринг. В этом случае данные платежных карт не будут в открытом виде обрабатываться и храниться в мобильном устройстве, а значит, и требования PA-DSS не применимы.

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

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

В перечень всех основных компонентов экосистемы mPOS входит:

• считывающее устройство;
• платежное приложение для мобильного устройства;
• платежный шлюз;
• эквайринговая система, подключенная к МПС.

В отличие от PCI DSS, который распространяется только на информационную инфраструктуру, PCI P2PE является более комплексным и распространяется не только на инфраструктуру, но и на считывающие устройства и программное обеспечение POI-терминалов (в приложении к mPOS – это считывающие устройства). Стандарт состоит из 6 доменов, требования которых основаны на действующих стандартах PCI: считывающие устройства должны удовлетворять требованиям PCI PTS SRED; программное обеспечение считывающих устройств – PA-DSS; управление ключами шифрования – PCI PIN Security Requirements; платежная информационная инфраструктура ТСП – PCI DSS. Если решение сертифицировано по PCI P2PE, это значит, что данные между всеми подсистемами (от считывателя к мобильному устройству в ПО, от ПО в процессинг и далее) передаются в шифрованном виде, и все подсистемы выполняют требования соответствующих стандартов PCI.

По требованиям P2PE могут быть сертифицированы как отдельные компоненты, так и готовые решения.

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

О стандарте

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 и оказывает экспертную поддержку по выполнению требований стандарта.

В нескольких ранних публикация мы с вами уже рассматривали некоторые международные стандарты в области информационной безопасности. Однако, преимущественно они относились к 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.

Организации, хранящие, обрабатывающие и передающие данные платежных карт международных платежных систем (Visa, MasterCard, American Express, Discover, JCB), обязаны выполнять требования стандарта PCI DSS. Платежными системами определены периодичность и форма подтверждения соответствия требованиям стандарта, а также санкции за их невыполнение и компрометацию данных платежных карт.

Для помощи организациям в выполнении требований стандарта компания «Информзащита» предлагает различные варианты услуги по обеспечению соответствия PCI DSS, учитывающие задачи и специфику клиента. В их числе:

• PCI DSS Compliance. Услуга предполагает приведение уровня информационной безопасности компании в соответствие требованиям стандарта PCI DSS c «нуля». Включает в себя:
• Предварительный аудит с разработкой плана приведения в соответствие;
• Непосредственно этап приведения;
• Финальный сертификационный аудит.
• Поддержание соответствия требованиям PCI DSS. Услуга предполагает помощь организациям, уже имеющим сертификат соответствия PCI DSS и заинтересованным в его очередном подтверждении.
• Сертификационный аудит PCI DSS. Услуга предназначена для организаций, самостоятельно реализовавших требуемые PCI DSS меры защиты и заинтересованных только в итоговой оценке соответствия.
• Сертификация программного обеспечения по требованиям стандарта PA-DSS. В 2008 году Советом по безопасности индустрии платежных карт (PCI SSC) принят стандарт безопасности платежных приложений – Payment Application Data Security Standard (PA-DSS), направленный на поддержку выполнения требований стандарта PCI DSS. По требованиям платежных систем VISA и MasterCard все «коробочные» приложения, участвующие в обработке транзакций авторизации или проведении расчетов по платежным картам, должны быть сертифицированы по стандарту PA-DSS.
  Платежными системами VISA и MasterСard определен срок по завершению перехода агентов и предприятий торгово-сервисной сети на использование сертифицированных приложений – 1 июля 2012 г.
  Сертификацию приложений на соответствие стандарту PA-DSS может проводить только аудитор, имеющий статус PA-QSA. «Информзащита» – первая в России компания, имеющая данный статус.
  Специалисты «Информзащиты» с 2009 года проводят аудиты на соответствие стандарту PA-DSS. За время проведения работ нами сертифицировано более 10 приложений: процессинговое программное обеспечение, приложения платежных терминалов и электронной коммерции. Накопленный опыт позволяет определить оптимальную для разработчика схему проведения подготовительных работ и сертификации. Внедрение требований обеспечения безопасной разработки и сопровождения программного обеспечения осуществляется с учетом существующих процессов. Уровень итоговых документов и наработанная практика обеспечивают минимальный срок прохождения обязательной процедуры контроля качества со стороны PCI SSC.
• Поддержание соответствия программного обеспечения требованиям стандарта PA-DSS. Изменения, вносимые в сертифицированные PA-DSS платежные приложения, подлежат анализу и в ряде случаев влекут за собой обязательную процедуру повторной сертификации. Объем и отчетные документы проводимой сертификации зависит от типа изменений.
  Сертифицированные аудиторы Информзащиты обладают опытом в формировании политик релизов с учетом требований стандарта и реалий вендора, проведения повторной сертификации для всех определенных стандартом типов изменений, согласовании итоговых документов с PCI SSC.
  Подход к обеспечению повторных сертификаций формируется на основании пожеланий разработчика и ориентируется на существующую практику выпуска обновлений со стороны разработчика приложений.
• Сканирование PCI ASV, сканирование WEB приложений. Компания «Информзащита» является сертифицированным (сертификат №4159-01-08) поставщиком сканирований PCI ASV. Сканирование PCI ASV обеспечивает выполнение пункта 11.2.2 стандарта PCI DSS. Помимо формального соответствия стандарту, сканирование PCI ASV позволяет оценить защищенность Вашего внешнего сетевого периметра, выявить уязвимости и некорректные конфигурации.
• Комплексный тест на проникновение по требованиям PCI DSS. Услуга включает практическую оценку возможности осуществления несанкционированного доступа к данным платежных карт или сетевым ресурсам, обрабатывающим данные платежных карт (требование пункта 11.3 PCI DSS).
• Разработка для банков-эквайеров программы соответствия мерчантов требованиям PCI DSS. Согласно требованиям международных платежных систем, банки-эквайеры несут ответственность за выполнение своими мерчантами требований стандарта PCI DSS. В рамках услуги осуществляется разработка программы контроля соответствия мерчантов требованиям стандарта PCI DSS на основе программ безопасности международных платежных систем Account Information Security и Site Data Protection.
• Помощь в заполнении листа самооценки PCI DSS. Услуга предназначена для мерчантов и сервис-провайдеров с небольшими объемами транзакций. В рамках услуги компания «Информзащита» оказывает помощь в проведении оценки соответствия с заполнением листа самооценки PCI DSS.

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

Компания «Информзащита» первой в РФ получила статусы QSA и ASV, дающие право выполнять сертификационные аудиты PCI DSS и внешние ASV-сканирования. По количеству сертифицированных QSA-аудиторов «Информзащита» превосходит другие российские компании. Таким образом, с каждым клиентом работает персональный специалист. Компания успешно прошла контроль качества отчетов со стороны PCI SSC, подтвердивший высокое качество предоставляемых клиентам услуг. С 2006-го года компания выполнила для банков, независимых процессинговых центров, сервис-провайдеров, дата-центров и мерчантов более 90 проектов по приведению к соответствию и сертификации PCI DSS.

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

Правила и рамки информационного пентестинга представлены в методологиях
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.