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

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

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

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

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

Рассматривать стандарт мы будем неформально и с разных точек зрения: с позиции системного администратора, поле деятельности которого подвергается аудиту, и с позиции аудитора. А также местами будем «подглядывать» и из-за той стороны баррикад, со стороны тех, ради кого обычно весь этот цирк затевается – злоумышленники.

 

Группа поддержки PCI DSS

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

  1. Глоссарий (Glossary);
  2. Стандарт безопасности данных индустрии платежных карт (Payment Card Industry Data Security Standard);
  3. Требования и процедуры оценки информационной безопасности (PCI DSS Security Audit Procedures);
  4. Процедуры сканирования безопасности (PCI DSS Security Scanning Procedures);
  5. Требования, предоставляемые QSA-аудиторам (PCI DSS Validation Requirements for Qualified Security Assessors);
  6. Требования, предъявляемые к вендорам услуг сканирования (PCI DSS Validation Requirements for Approved Scanning Vendors);
  7. Ориентирование в PCI DSS (Navigating PCI DSS Document);
  8. Приоритезированный подход к достижению соответствия PCI DSS (Prioritized Approach for PCI DSS);
  9. Листы самооценки (PCI DSS Self-Assessment Questionnaire);
  10. Дополнительная документация (уточнения некоторых требований стандарта и дополнительная информация для стороны, предоставляющей услуги).

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

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

  • «Ориентирование в PCI DSS»(пункт 7) представляет собой обзор 12 требований PCI DSS (пункт 1) с целью улучшения их понимания сотрудниками организации, которая подлежит сертификации;
  • «Приоритезированный подход» (пункт 8) подскажет отправную точку и направление, в котором нужно двигаться проверяемой организации, чтобы вывести свою информационную безопасность на необходимый уровень, обеспечив защиту от актуальных угроз, и, как следствие, подготовить свою инфраструктуру к аудиту.
  • Листы самооценки и инструкция по их заполнению позволяют организации провести самоконтроль на соответствие стандарту PCI DSS – полезное мероприятие, причем не только в момент, когда вот-вот аудитор начнет трясти все и вся в поисках несоответствий, но и прекрасно подходит в качестве профилактических мер, проводимых внутренней службой безопасности.

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

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

 

Поле битвы – сегмент

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

Если взглянуть на таблицу, которая иллюстрирует элементы данных пластиковых карт и соответствующие им меры защиты, то можно заметить, что такие элементы, как CVV2 (Card Verification Value 2 – код проверки подлинности карты платежной системы Visa) и CVC2 (аналогичный код платежной системы MasterCard) относятся к критичным аутентификационным данным, а значит, не подлежат хранению. Тем не менее, в пользовательской практике встречаются случаи, когда торгово-сервисное предприятие с целью упрощения жизни своим клиентам не требует повторного ввода этого кода на своем веб-ресурсе. Таким организациям приходится выбирать между сертификатом PCI DSS (и, как следствие, безопасностью своих бизнес-процессов) и излишней псевдозаботой о своих пользователях, ведь CVC2 и CVV2 являются одним из ключевых звеньев при совершении финансовых online-операций.

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

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

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

  1. грамотная сегментация способна сократить временные и, в некоторых случаях, финансовые расходы на проведение оценки соответствия;
  2. наличие в системе беспроводных сетей как средств обработки данных о держателях – результат некорректной процедуры сегментации или же ее отсутствия;
  3. привлечение третьих сторон в бизнес-процесс влечет к дополнительным временным затратам на проверку этих сторон аудитором, который должен отчетливо понимать роль исследуемой компании и ее поставщиков услуг (третьих сторон) в платежной индустрии.
 

А что насчет второй версии?

Теперь проведем краткий обзор основных требований стандарта PCI DSS v2.0 (обновление от 28 октября 2010 года). 12 требований объединены в группы по типам процедур аудита безопасности.

Первая группа – «Построение и обслуживание защищенной сети» (требования 1 и 2). С первого требования становится понятно, насколько важен процесс сегментации целевой инфраструктуры и на основе каких средств, собственно, строится этот процесс – межсетевой экран. Аксиома: межсетевой экран – основа обеспечения безопасности. Грамотное проектирование циркулируемого трафика приводит в порядок всю инфраструктуру в целом. Тем не менее, в последней версии стандарта все же делается некоторое смягчение формулировки первого требования и подразумевается факт фильтрации и блокировки трафика не только средствами межсетевого экрана.

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

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

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

Следующая группа, объединяющая в себе требования 5 и 6, называется «Управление уязвимостями». Уязвимости есть, и ими надо грамотно управлять, а именно: своевременно устанавливать актуальные обновления, в том числе и на антивирусное программное обеспечение, разрабатывать и использовать безопасные приложения, в том числе и веб-ориентированные. Без пентеста или, на крайний случай, сканирования не разберешься… Но о пентестах речь вообще отдельная, поэтому вернемся-ка мы к ним мы в требовании 11.

Следующие три требования (7, 8 и 9) объединены в группу «Внедрение строгих мер контроля доступа» и носят организационно-технический характер обеспечения защиты информации с использованием как организационных мер обеспечения безопасности, так и механизмов физического доступа и мониторинга.

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

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

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

 

Это слишком близко…

И вот аудитор на пороге офиса заказчика. Если руководитель компании относится к процессу аудита, как к экзамену на первом курсе высшего заведения, то и процедура оценки соответствия будет представлять из себя сплошную «тягомотину» ради галочки в отчете.

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

 

INFO

Недавно обновленная версия стандарта (PCI DSS v2.0 от 28 октября 2010 года) практически не претерпела радикальных изменений. Обновления требований носят разъяснительный и уточнительный характер.

 

WWW

 

DVD

На диске находится подборка переведенных на русский язык официальных поддерживающих документов стандарта PCI DSS v1.2.

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии