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

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

1. Что такое сертификация PCI DSS?

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

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

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

2. Кем был разработан стандарт PCI DSS?

Стандарт PCI DSS разработан Советом по стандартам безопасности индустрии платежных карт (Payment Card Industry Security Standards Council, PCI SSC). PCI SSC был основан ведущими международными платежными системами — Visa, MasterCard, American Express, JCB, Discover. Информацию о своей деятельности PCI SSC публикует на своем сайте https://www.pcisecuritystandards.org

3. Для кого требования стандарта PCI DSS являются обязательными?

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

PCI DSS в Украине

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

Входят ли банкоматы в область применения стандарта PCI DSS?

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

4. Нужна ли какая-то техническая база для проведения аудита и сертификации по PCIDSS? Есть ли привязка требований стандарта PCI DSS к конкретным решениям — оборудованию, программному обеспечению, технологиям?

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

5. Сколько по времени занимает услуга сертификации по PCI DSS?

Время проведения аудита зависит от размера области применения стандарта PCI DSS, а также от особенностей инфраструктуры компании. В среднем аудит на объекте компании длится 3-5 дней (с выездом сотрудника в офис компании).

Однако, при подготовке к сертификации на соответствие PCI DSS необходимо принимать во внимание ряд важных моментов.

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

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

6. Как часто нужно проходить аудит?

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

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

7. Что получает клиент по итогам сертификации по PCI DSS?

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

Если информационная система компании соответствует стандарту PCI DSS по результатам сертификационного аудита, Заказчик получает сертификат соответствия после одобрения PCI SSC (PCI Security Standard Council).

8. Кто проводит аудит? Как стать аудитором по PCI DSS?

Аудит на соответствие требованиям стандарта PCI DSS имеют право проводить компании, имеющие статус QSA (Qualified Security Assessor).

Аудиторы бывают двух статусов:

Статусы QSA (Qualified Security Assessor) и ASV (Authorized Scanning Vendor)

QSA-аудитор выполняет аудит по PCI DSS (ежегодный аудит на объекте компании)

ASV-аудитор выполняет сканирование. Сканирование проводится для компаний с меньшими транзакциями (ежеквартальное сканирование, выполняемое сертифицированным поставщиком услуг (ASV))

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

Как стать аудитором PCI DSS?

Необходимо пройти курсы в Америке в PCI SSC и сдать экзамены. Также можно обучение проходить дистанционно и сдать экзамены после обучения.

Программы и расписание обучения приведены на официальном сайте https://www.pcisecuritystandards.org

9. Чем отличаются сертификации PCI DSS от PA-DSS?

Для безопасности платежных приложений Советом был разработан стандарт PA-DSS (Payment Application Data Security Standard), являющийся с одной стороны развитием предписания Visa PABP (Payment Application Best Practices), а с другой стороны - адаптацией требований стандарта PCI DSS к приложениям.

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

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

10. Есть ли в Украине аудиторы PCI DSS?

Есть. Но немного. В России есть больше таких аудиторов.

SBSB не имеет право проводить сертификацию PCI DSS. Мы можем рекомендовать партнерские компании, которые занимаются этим.

11. Сколько стоит услуга сертификации по PCI DSS?

Четких тарифов не существует. Существуют цены на человеко-часы, курс евро, объем работ. Но сегодняшний день сертификационный аудит стоит не менее 13.000 EUR.

Дополнительно будут оплачиваться проведение идентификации и сканирование на уязвимость беспроводных точек доступа и проведение предварительного аудита на соответствие (от 2,500 EUR).


В своей работе мы уделяем огромное внимание вопросам информационной безопасности. Публикации по соответствующей тематике уже неоднократно появлялись в нашем блоге (см., например, ; отдельные аспекты затронуты также ).
Совсем недавно произошло ещё одно важное событие: мы получили сертификат соответствия требованиям стандарта PCI DSS v3.0.
Это несомненно должно заинтересовать клиентов, чья деятельность так или иначе связана с электронными платёжными системами и банковскими картами: представителей финансового и банковского сектора, интернет-магазины и других.

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

PCI DSS: общие сведения

Аббревиатура PCI DSS означает Payment Card Data Security Standard — стандарт безопасности данных индустрии платёжных карт. Стандарт PCI DSS представляет собой документ, определяющий требования к поставщикам услуг и торгово-сервисным предприятиям по обеспечению безопасности обращения карт. Первая версия стандарта появилась в январе 2005 года. На сегодняшний день актуальной является третья версия стандарта (полный текст см. на английском языке см. , на русском языке — ) Она содержит 241 требование, распределенные по 12 разделам:

  1. Защита вычислительной сети.
  2. Конфигурация компонентов информационной инфраструктуры.
  3. Защита хранимых данных о держателях карт.
  4. Защита передаваемых по сети данных о держателях карт.
  5. Антивирусная защита информационной инфраструктуры.
  6. Разработка и поддержка информационных систем.
  7. Управление доступом к данным о держателях карт.
  8. Механизмы аутентификации.
  9. Физическая защита информационной инфраструктуры.
  10. Протоколирование событий и действий.
  11. Контроль защищённости информационной инфраструктуры.
  12. Управление информационной безопасностью.

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

Советом PCI SSC разработаны также следующие документы:

  • стандарт PCI PA DSS (Payment Card Industry Payment Application Data Security Standard, стандарт безопасности данных в приложениях индустрии платёжных карт) —определяет требования к приложениям, обрабатывающим персональные данные владельцев карт, а также к процессу их разработки;
  • руководства PCI PTS (Payment Card Industry PIN Transaction Security) — содержат требования к устройствам, обрабатывающим PIN-коды платёжных карт (POS-терминалам, шифрующим PIN-клавиатурам, аппаратным модулям безопасности).

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

Внедрение PCI DSS: основные этапы

Согласно официальным документами, процесс внедрения PCI DSS подразделяется на следующие этапы:

  • анализ исходного уровня соотвестствия;
  • приведение к требуемому уровню соответствия;
  • подтверждение соответствия;
  • поддержка соответствия.

Рассмотрим процесс внедрения PCI DSS более подробно. Для оценки соответствия выполняется аудит. Его проводит сторонняя организация, имеющая специальную сертификацию от PCI SSC. Мы в качестве аудитора привлекатели немецкую компанию SRC Security Research and Consulting GmbH.
Процедура аудита включает интервью с сотрудниками организации-заказчика, изучение информационных систем, а также изучение и анализ внутренней нормативной документации. Результатом этого этапа является определение сферы применимости требований PCI DSS в информационной инфраструктуре заказчика.
После того, как определена сфера применимости и собрана вся необходимая информация, разрабатываются рекомендации по внедрению PCI DSS.
На основе этих рекомендаций вносятся конкретные изменения в информационную инфраструктуру: модернизируется оборудование, дорабатывается программное обеспечение, внедряются системы защиты информации, разрабатывается необходимая документация.

На следующем этапе проводится специализированный аудит. В случае успешного прохождения аудита составляется Отчёт о соответствии (англ. Report on Compliance). Организация-заказчик заполняет также лист самооценки (Self-Assessment Questionnaire, SAQ). Форма этого документа зависит от специфики обработки карточных данных в организации.

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

PCI DSS: что сделано у нас

Наши дата-центры сертифицированы на уровне обеспечения физической безопасности. Таким образом, в рамках сертификата PCI DSS нами выполняются требования разделов 9, 11 (частично) и 12. Рассмотрим эти требования более подробно.

Раздел 9: физическая защита информационной инфраструктуры

Охрана наших дата-центров осуществляются в режиме 24/7/365. Все дата-центры оснащены системами защиты от несанкционированного доступа как в периметр здания, так и в серверные помещения. На входе имеется пост вооружённой охраны. Для исключительных случаев предусмотрена и кнопка тревожной сигнализации.

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

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

Раздел 11: контроль защищённости информационной инфраструктуры

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

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

Раздел 12: управление информационной безопасностью

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

Заключение

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

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

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

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

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

Подробно:

Теория PCI DSS

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

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

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

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

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

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

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

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

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

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

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

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

  1. Проверка документов и определение зоны контроля. На данном этапе аудиторы анализируют и проверяют пакет необходимой документации клиента – компании, выступающей заказчиком прохождения аудита на соответствие требованиям стандарта PCI DSS . В числе данных документов: схема сети с указанием всех подключений к части сети, в которой производится хранение, обработка или передача данных, содержащих информацию о держателях карт, реестр ресурсов, стандарты и политики, принятые в компании, документированные процедуры и процессы. Зона контроля (Scope) включает в себя:
  • все устройства и сетевые сегменты, в которых производится хранение, обработка или передача данных, содержащих информацию о держателях платежных карт;
  • все сетевые сегменты и устройства, подключенные к этим сегментам (в том числе активное сетевое оборудование).
  • Зона контроля может быть довольно обширной, особенно в том случае, если внутри сеть компании не сегментирована и (в случае, если речь идет о кредитной организации) для отделения процессингового центра от остальной сети банка не используются внутренние межсетевые экраны. Используя специальную методику, аудитор делает репрезентативную выборку (Sampling) тех устройств, которые непосредственно будут подлежать проверке в ходе аудита.
  • Оценка соответствия на месте (On-site audit). После того как решен вопрос с выборкой и завершена проверка необходимых документов, начинается этап On-site audit, т. е. этап проверки реализации требований стандарта PCI DSS непосредственно на месте, т. е. на территории клиента. Аудиторы проверяют реализацию методов защиты и их соответствие требованиям PCI DSS согласно процедурам аудита, насчитывающим более 230 проверок.
  • Подготовка и распространение отчета. После окончания процедуры проверки на месте начинается работа над подготовкой отчета. Если компания соответствует по всем пунктам требованиям стандарта, то в международную платежную систему, с которой она работает, посылается соответствующий отчет (ROC для Visa Int. и COV для MasterCard Worldwide).
  • Подготовка плана по устранению несоответствий. Если в ходе проверки было найдено хотя бы одно несоответствие, проверяемая компания составляет план по устранению несоответствий (action plan). В этом плане должны быть указаны конкретные даты исправления обнаруженных несоответствий, а также те способы и меры, с помощью которых каждое из них планируется исправить.
  • ПРАКТИКА

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

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

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

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

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

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

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

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

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

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

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

    по пунктам:

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

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

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

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

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

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

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

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

    № 4 (180) ’2012

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

    Индустрия платежных карт

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

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

    Рис. 1. Торгово-сервисные предприятия и поставщики услуг

    Стандарты PCI DSS и PCI PA-DSS

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

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

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

    Объектом применения родственного стандарта PA-DSS, в отличие от PCI DSS, является конкретное платежное приложение, разрабатываемое для продажи неограниченному кругу конечных пользователей — участников индустрии платежных карт. Примерами таких приложений являются программные модули POS-теминалов, авторизационные приложения, а также иные коробочные решения для обработки карточных транзакций. С июля 2012 года согласно требованиям международных платежных систем Visa и MasterCard мерчанты обязаны использовать только сертифицированные по стандарту PA-DSS платежные приложения. Контроль над выполнением этого требования возложен на банки-эквайеры. Существует перечень из тринадцати вопросов, которые позволяет более точно сказать, попадает приложение под программу сертификации по PA-DSS или нет. Этот документ доступен на официальном сайте Совета PCI SSC.

    Внедрение PCI DSS

    Классический проект по внедрению стандарта PCI DSS в организации обычно состоит из следующих этапов:

    • Анализ исходного уровня соответствия
    • Приведение к требуемому уровню соответствия
    • Подтверждение соответствия
    • Поддержка соответствия

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

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

    Рис. 2. Типовой проект по внедрению PCI DSS

    Отдельно следует сказать про варианты подтверждения соответствия стандарту PCI DSS. Для участников индустрии платежных карт существуют три способа подтвердить соответствие — это внешний аудит, внутренний аудит, и заполнение листа самооценки. Внешний аудит выполняется сотрудником внешней аудиторской организацией (Qualified Security Assessor, QSA), сертифицированной Советом PCI SSC. Внутренний аудит проводится прошедшим обучение и сертифицированным по программе Совета PCI SSC аудитором (Internal Security Assessor, ISA). Третий вариант подтверждения выполняется самостоятельно сотрудниками организации путем заполнения листа самооценки (Self-Assessment Questionnaire, SAQ). Правила, регулирующие, каким именно способом подтверждается соответствие стандарту, определяются международными платежными системами индивидуально для разных видов мерчантов и поставщиков услуг, но могут быть переопределены банками-эквайерами. Актуальная версия правил в общем виде всегда доступна на официальных сайтах международных платежных систем.

    Следует отметить, что форма листа самооценки SAQ бывает нескольких типов (A, B, C, C-VT, D), а выбор типа листа зависит от специфики обработки карточных данных в организации. Схема применимости различных вариантов подтверждения соответствия приведена в таблице.

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

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

    Вариант Применимость Количество проверочных процедур
    SAQ A Мерчанты, выполняющие card-not-present транзакции, отдавшие все функции по электронной обработке, хранению и передаче карточных данных поставщику услуг, подтвердившему соответствие PCI DSS. 13
    SAQ B Мерчанты, использующие POS-терминалы, использующие телефонную линию, не передающие карточные данные через Интернет, и не имеющие электронных хранилищ карточных данных. 29
    SAQ C Мерчанты, использующие POS-терминалы или платежные приложения, передающие карточные данные через Интернет, и не имеющие электронных хранилищ карточных данных. 40
    SAQ C-VT Мерчанты, использующие через Интернет виртуальные веб-терминалы от поставщика услуг, подтвердившего соответствие PCI DSS, и не имеющие электронных хранилищ карточных данных. 51
    SAQ D Все мерчанты и все поставщики услуг, кроме тех, кому согласно требованиям МПС или эквайера необходим ISA- или QSA-аудит. 288
    ISA-аудит Все мерчанты, кроме тех, кому согласно требованиям МПС или эквайера необходим QSA-аудит. 288
    QSA-аудит Все мерчанты и все поставщики услуг. 288

    24.09.2008 Ростислав Сергеев

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

    Действие PCI DSS распространяется на торгово-сервисные предприятия и поставщиков услуг, работающих с международными платежными системами, т. е. на всех, кто передает, обрабатывает и хранит данные держателей карт. Это касается как общих данных - номер карты (Primary Account Number, PAN), имя держателя карты, код обслуживания, дата выдачи и истечения срока действия, так и критичных данных авторизации (sensitive authentication data) - полное содержание магнитной полосы, коды CVC2/CVV2/CID и PIN-блок. Элементы данных необходимо защищать, если они хранятся совместно с номером карты, а по завершении процедуры авторизации критичные данные не должны сохраняться даже в зашифрованном виде. Требования стандарта PCI DSS не применяются, если не выполняется хранение, обработка или передача номера карты (PAN).

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

    НЕМНОГО ИСТОРИИ

    Первая редакция стандарта PCI DSS (1.0) была разработана в 2004 г. на основе требований к безопасности данных платежных систем Visa, Master Card, American Express, Discover Card и JCB. В сентябре 2006 г. вышла новая редакция PCI DSS 1.1, а для развития и продвижения стандарта был создан специальный совет по стандартам безопасности - PCI Security Standards Council (PCI SSC), в который вошли представители перечисленных платежных систем.

    Поначалу международные платежные системы требовали от участников программы и торгово-сервисных предприятий обеспечить соответствие стандарту только на территории США и Западной Европы, причем нарушители подвергались штрафам. Для других регионов никаких санкций предусмотрено не было. Однако с сентября 2006 г. жесткие правила выполнения аудита по стандарту были распространены на регион CEMEA, в который входит и Россия, что послужило стимулом для внедрения PCI DSS российскими банками, процессинговыми центрами и торгово-сервисными организациями. В ноябре 2008 г. планируется выход новой редакции стандарта PCI DSS - 1.2, где будут учтены лучшие практики по безопасности, замечания организаций-членов PCI SSC и ряд других новшеств (см. врезку «Ожидаемые изменения в стандарте PCI DSS»).

    В зависимости от числа обрабатываемых за год транзакций (до 120 тыс., до 600 тыс., до 6 млн, более 6 млн) компании присваивается определенный уровень с обязательным набором требований по безопасности. Процедуры подтверждения соответствия стандарту включают ежегодный аудит, ежеквартальное сканирование сети на наличие уязвимостей и, в некоторых случаях, заполнение листа самооценки (Self Assessment Questionauire). Для выполнения аудита и сканирования сетей компании должны привлекать стороннюю организацию, имеющую статус Qualified Security Assessor (QSA, для аудита) и Approved Scanning Vendor (ASV, для сканирования сети). Упомянутые статусы присваиваются советом PCI Security Standards Council, и их список размещен на сайте https://www.pcisecuritystandards.org . Там же можно найти официальный текст стандарта PCI DSS на английском языке (https://www.pcisecuritystandards.org/pdfs/pci%20dss%20v1-1.pdf).

    В данный момент в этом списке присутствуют три российские компании: московские «Информзащита» и «Инфосистемы Джет», а также Digital Security из Санкт-Петербурга (см. врезку «Аудит по-российски»). На сайте компании «Информзащита» опубликованы неофициальный перевод стандарта PCI DSS на русский язык (http://www.infosec.ru/files/articles/2284/Стандарт%20PCI%20DSS%201_1.pdf) и три сопутствующих документа на русском языке: «Процедуры аудита безопасности PCI DSS», «Ориентирование в PCI DSS: понимание требований» и «Процедуры сканирования безопасности».

    АУДИТ СЕТИ

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

    Процедура аудита реализуется поэтапно: (1) проверка документов и определение зоны контроля, (2) оценка соответствия на месте, (3) подготовка и распространение отчета и (4) подготовка плана по устранению несоответствий. Зона контроля охватывает все устройства и сетевые сегменты, в которых производится обработка или передача данных о держателях платежных карт, а также все сетевые сегменты и устройства, подключенные к перечисленным сегментам (в том числе активное сетевое оборудование). Таким образом, зона контроля может быть довольно обширной, особенно если внутренняя сеть компании не сегментирована и для отделения процессингового центра от остальной сети банка не используются внутренние межсетевые экраны.

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


    Для подтверждения соответствия стандарту необходимо выполнить каждое его требование, если таковое применимо (см. Рисунок 1 и врезку «Шесть задач и 12 основных требований стандарта PCI DSS»). Как показывает практика, наиболее проблемными для компаний оказываются требования 11, 2, 3, 10, 8 (в порядке убывания числа несоответствий), в то время как выполнение требований 9, 4 и 7 обычно не вызывает трудностей, а требование 6 имеет отношение только к тем компаниям, которые занимаются разработкой ПО.

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

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

    ПОСТРОЕНИЕ И ПОДДЕРЖАНИЕ ЗАЩИЩЕННОЙ СЕТИ

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

    Конфигурирование МСЭ должно удовлетворять следующим требованиям:

      Формализация и документирование процесса утверждения и тестирования всех соединений с внешними сетями, а также изменений, вносимых в конфигурацию МСЭ;

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

      Размещение МСЭ на каждом канале подключения к Internet, а также на границе между каждой демилитаризованной зоной и внутренней сетью;

      Описание групп, ролей и обязаннос-тей в отношении логического управления сетевыми компонентами;

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

      Документирование и обоснование применения всех протоколов, за исключением HTTP, SSL, SSH и VPN;

      Документирование всех небезопасных протоколов (например, FTP) с указанием причины использования протокола и реализованных механизмов защиты;

      Ежеквартальный пересмотр правил для МСЭ и маршрутизаторов и своевременное удаление ненужных, некорректных и устаревших правил;

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

    Конфигурация МСЭ должна запрещать любой трафик, поступающий от неблагонадежных сетей и устройств, за исключением протоколов, необходимых для функционирования среды платежных карт. Кроме того, она вводит ограничения для установления соединения между публично доступными серверами (включая любые подключения из беспроводных сетей) и любыми системными компонентами, на которых хранятся данные платежных карт (например, с базами данных, журналами регистрации событий, файлами трассировки и т.п.). Для фильтрации и экранирования трафика и запрета прямых маршрутов для входящего и исходящего трафика Internet предусматривается демилитаризованная зона, а исходящий от приложений платежных карт трафик ограничивается IP-адресами внутри DMZ.

    В соответствии с Требованием 2 стандарта PCI DSS запрещается использовать параметры безопасности и системные пароли, заданные производителем по умолчанию, поскольку эти данные хорошо известны в хакерских сообществах и могут применяться злоумышленниками для компрометации систем. В частности, для беспроводных сред должны быть изменены значения ключей WEP, идентификаторов сетей (SSID), пароли и строки SNMP. Необходимо отключить широковещательную рассылку SSID и осуществлять шифрование и аутентификацию при помощи технологии WPA и WPA2.

    Для всех системных компонентов следует разработать стандарты конфигурирования, учитывающие все известные уязвимости и рекомендации по обеспечению безопасности (составленные, например, организациями SANS, NIST и CIS). На каждом сервере должна быть реализована только одна основная функция, т.е. сервер Web, сервер баз данных и сервер DNS развертываются на различных устройствах. Все необязательные и небезопасные протоколы и сервисы отключаются, избыточный функционал, например, сценарии, драйверы, файловые подсистемы и неиспользуемые серверы Web, удаляется, а административный доступ, если он осуществляется не с консоли, шифруется. При управлении с помощью интерфейса Web рекомендуется использовать технологии SSH, VPN или SSL/TLS.

    ЗАЩИТА ДАННЫХ ПЛАТЕЖНЫХ КАРТ

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

    Хранение данных платежных карт должно быть сведено к минимуму - это касается как объема хранимой информации, так и продолжительности хранения. Для хранения и уничтожения данных платежных карт следует разработать соответствующую политику. Хранение критичных данных авторизации запрещается (даже в зашифрованном виде). Отображаемые номера PAN необходимо маскировать (максимальным количеством разрешенных при отображении цифр являются первые шесть и последние четыре цифры): независимо от места хранения, они приводятся к нечитаемому виду с помощью одного из перечисленных ниже способов: 1) стойкие односторонние хеш-функции (хешированные индексы); 2) усечение; 3) Index Token и PAD; 4) надежная криптография совместно с процессами и процедурами управления ключами. Это же касается и номера PAN счета.

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

      Обеспечивают дополнительный уровень сегментации/абстракции (например, на сетевом уровне);

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

      Ограничивают логический доступ к базе данных (независимо от Active Directory или LDAP);

      Позволяют предотвратить/обнаружить известные виды атак на приложения или базы данных.

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

    В рамках Требования 4 стандарта PCI DSS обеспечивается шифрование данных платежных карт, передаваемых по сетям общего пользования: Internet, Wi-Fi, GSM и GPRS.

    РЕАЛИЗАЦИЯ ПРОГРАММЫ УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ

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

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

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

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

    РЕАЛИЗАЦИЯ МЕР ПО СТРОГОМУ КОНТРОЛЮ ДОСТУПА

    В рамках этой задачи должны быть реализованы три требования стандарта (7-9).

    Требование 7 обязывает предоставлять доступ к данным платежных карт только в случае служебной необходимости. Чем больше людей имеют такой доступ, тем выше риск злонамеренного использования учетных записей. Для многопользовательских систем предусматривается механизм предоставления доступа по принципу необходимого знания (need-to-know), т.е. доступ запрещается, если он не разрешен явным образом. В соответствии с Требованием 8 каждому лицу, имеющему доступ к вычислительным ресурсам, присваивается уникальный идентификатор. В результате, действия с критичными данными и системами смогут выполнять только авторизованные пользователи, а все их операции будут отслеживаться. В дополнение к назначению уникального идентификатора должен использоваться, по крайней мере, один из следующих механизмов аутентификации: пароль, биометрические или технические устройства аутентификации (SecureID, сертификаты или открытые ключи).

    Для предоставления удаленного доступа служащим компании, администраторам или третьим лицам должна быть реализована двухфакторная идентификация, что выполняется при помощи либо технологий RADIUS или TACACS и аппаратных устройств аутентификации, либо VPN (на базе протоколов SSL/TLS или IPSEC) и пользовательских сертификатов.

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

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

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

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

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

    РЕГУЛЯРНЫЙ МОНИТОРИНГ И ТЕСТИРОВАНИЕ СЕТЕЙ

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

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

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

    ПОДДЕРЖАНИЕ ПОЛИТИКИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

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

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

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

    ВЫСОКИЙ ОРИЕНТИР

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

    Ростислав Сергеев - заместитель главного редактора «Журнала сетевых решений/LAN». С ним можно связаться по адресу: [email protected] .

    Ожидаемые изменения в стандарте PCI DSS

    Выход релиза 1.2 запланирован на ноябрь 2008 г. Как ожидается, он будет содержать следующие изменения и дополнения:

      Учет текущих лучших практик по безопасности и замечаний организаций-членов Совета (PCI SSC);

      Уточнение границ применения стандарта и требований к отчетности;

      Исключение пересекающихся требований и консолидация требований к документированию;

      Разъяснение и уточнение подпунктов всех 12 требований без внесения новых элементов;

      Доработка FAQ и глоссария.

    Аудит по-российски

    На российском рынке услуги аудита в соответствии с требованиями QSA предоставляют всего несколько компаний. Первой статус QSA весной 2006 г. получила компания «Информзащита», когда вопрос о необходимости обеспечения соответствия стандарту PCI DSS в банках еще не поднимался. В России PCI Data Security Standard вступил в действие в сентябре 2006 г., после того как международная платежная система VISA утвердила стандарт как обязательный на территории региона CEMEA.

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

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

      Оценка соответствия платежной системы стандарту PCI DSS;

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

      Сертификационный аудит;

      Послесертификационная поддержка.

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

    Как отмечает Максим Эмм, директор департамента аудита компании «Информзащита», в целом, для большинства организаций, в первый раз столкнувшихся с необходимостью обеспечить соответствие требованиям западного стандарта, объем работы оказывается весьма значительным. В первую очередь, это касается документирования процессов управления и обеспечения безопасности, поскольку разработка процедур, стандартов и других документов требует немалых усилий. Во вторую очередь, это вопросы управления инфраструктурой ИТ, включая контроль изменения конфигураций, стандарты конфигурирования типовых элементов инфраструктуры ИТ и т.п. Меньше всего проблем возникает в области физической безопасности - у банков защита реализована на достаточно высоком уровне. Впрочем, задачу несколько облегчает то, что из 232 требований стандарта не все применимы к конкретному банку, например, в финансовых учреждениях в России, в отличие от США, не используются беспроводные технологии, зачастую не разрабатывается собственное программное обеспечение и т.п.

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

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

    Шесть задач и 12 основных требований стандарта PCI DSS

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

    Задача 2. Защита данных платежных карт.
    Требование 3: При хранении данные платежных карт следует надежно защитить.
    Требование 4: Данные платежных карт, передаваемые по сетям общего пользования, необходимо шифровать.

    Задача 3. Реализация программы управления уязвимостями.
    Требование 5: Обязательное использование и регулярное обновление антивирусного ПО.
    Требование 6: Обеспечение безопасности при разработке и поддержке систем и приложений.

    Задача 4. Реализация мер по строгому контролю доступа.
    Требование 7: Доступ к данным платежных карт должен быть ограничен в соответствии со служебной необходимостью.
    Требование 8: Каждому лицу, имеющему доступ к вычислительным ресурсам, назначается уникальный идентификатор.
    Требование 9: Физический доступ к данным платежных карт следует ограничить.

    Задача 5. Регулярный мониторинг и тестирование сетей.
    Требование 10: Доступ к сетевым ресурсам и данным платежных карт следует конт-ролировать.
    Требование 11: Системы и процессы обеспечения безопасности необходимо регулярно тестировать.

    Задача 6. Поддержание политики информационной безопасности.
    Требование 12: Деятельность сотрудников и контрагентов регламентируется в рамках политики информационной безопасности.