Текст книги "Безопасность карточного бизнеса : бизнес-энциклопедия"

Автор книги: А. Алексанов

сообщить о нарушении

Текущая страница: 8 (всего у книги 28 страниц)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• СУБД;

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

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

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

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

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

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

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

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

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

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

• IDS/IPS;

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

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

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

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

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

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

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

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

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

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

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

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


[Закрыть].

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

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

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

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

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

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

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

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

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

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

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

Применение компенсационных мер

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

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

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

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

Итак, примем как факт, что если номера карт обращаются в системе – применимые требования PCI DSS нужно выполнять.

Теперь обратимся к требованиям платежных систем (в первую очередь VISA и MasterCard), ведь это именно они определяют, что компании должны делать, чтобы с ними работать.

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

У каждой платежной системы есть своя программа: для VISA – это Account Information Security (AIS) Programme[70]70
  Подробнее см. далее подраздел «Описание программы Visa AIS».


[Закрыть], для MasterCard – это Site Data Protection (SDP) Program[71]71
  Описание SDP приведено далее в подразделе «Описание программы MasterCard SDP».


[Закрыть].

Программы немного различаются, но очевиден единый подход к оценке риска – чем больше данных платежных карт проходит через организацию, тем более жесткие требования к ее проверке на соответствие стандарту. При этом максимальный уровень проверки – это проведение ежегодного аудита с привлечением сертифицированного аудитора QSA, а также проведение ежеквартальных сканирований с привлечением сертифицированной компании ASV. Минимальный уровень проверки – это самостоятельное заполнение опросного листа или даже (в случае с MasterCard для торгово-сервисных организаций 3-го и 4-го уровней) отсутствие каких-либо требований (их определяет банк-эквайрер).

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

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

Данную позицию Совет по безопасности PCI (PCI SSC) изложил в своем FAQ.

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

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

Рассмотрим требования наиболее распространенных платежных систем VISA и MasterCard к области проверки выполнения требований стандарта PCI DSS в регионе CEMEA, которые они доводят до аудиторов QSA:

• VISA – в область проверки в ходе ежегодного аудита должны входить как минимум все системы, поддерживающие процессы авторизации платежей, клиринга и сеттлмента (от англ. settlement – урегулирование), а также фрод-мониторинга, разрешения диспутов и поддержки клиентов (колл-центры);

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

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

• исключаемые из области проверки ИТ-системы должны быть отделены межсетевым экраном (разумеется, правильно сконфигурированным в соответствии с требованиями стандарта);

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

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

Особенно интересен тот факт, что не требуется проверять и сети банкоматов (что выглядит странным, так как они участвуют в авторизации непосредственным образом). Стоит заметить, что с учетом опыта последних инцидентов с вирусами на банкоматах МПС (в частности, VISA) рекомендует для снижения подобных рисков реализовать для банкоматов те же защитные меры, что вошли в стандарт PCI DSS, но это именно рекомендации. Члены платежной системы вправе рассмотреть их эффективность, вправе даже привлечь QSA-аудиторов для оценки их выполнения. Но невыполнение банками ряда требований PCI DSS на банкоматах не может быть классифицировано аудиторами как несоответствие стандарту PCI DSS, препятствующее получению сертификата соответствия в рамках определенной самими платежными системами области проведения сертификационного аудита PCI Validation Scope (для сравнения – на Западе аудиторы проверяют и банкоматы тоже).

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

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

Описание программы VISA AIS

Применимость стандарта безопасности данных PCI в организациях, работающих с VISA

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

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

Инструменты проверки соответствия

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

Инструменты проверки

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

2. Процедуры сканирования безопасности описывают директивы для проведения сканирования безопасности сети в соответствии с PCI DSS.

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

3. Процедуры аудита безопасности – документ, используемый для проверки соответствия организаций, которые должны пройти onsite-аудит.

Кто может проверять соответствие?

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

Сканирование и onsite-аудит. Сканирование сети и onsite-аудит должны проводиться квалифицированным аудитором систем безопасности (Qualified Security Assessor).

Необходимые действия

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

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

Дополнительно эквайреры должны предоставить VISA отчеты о соответствии по своим ТСП уровней 1, 2 и 3 как минимум дважды в год. VISA оставляет за собой право запросить у эквайрера отправку документации о проверке соответствия по конкретному ТСП.

Дата 30 сентября 2009 г. была определена VISA Inc. как крайний срок хранения запрещенных конфиденциальных данных для ТСП уровня 1 и 2. После этой даты платежная система имеет право потребовать от эквайреров подтверждения того, что ТСП уровня 1 и 2 не хранят конфиденциальные данные (такие как данные магнитной полосы, треки, CVV2 или данные PIN) после авторизации транзакции, что является нарушением правил VISA. В отношении эквайреров, не предоставивших МПС до указанной выше даты (30 сентября 2009 г.) форму аттестата соответствия (Attestation of Compliance Form), подтверждающую, что все ТСП уровней 1 и 2 не хранят запрещенных конфиденциальных данных, VISA Inc. имеет право применить соответствующие меры по контролю рисков, вплоть до наложения штрафов. При этом оговаривается, что эта дата (30 сентября 2009 г.) не превалирует над более ранними сроками хранения конфиденциальных данных, определенными в конкретных регионах и соответствующими принудительными программами, установленными ранее (табл. 2.3).

Крайний срок проведения аудита соответствия стандарту PCI DSS для ТСП уровня 1 – 30 сентября 2010 г. К этой дате VISA Inc. требовала от эквайреров предоставить форму аттестата соответствия (Attestation of Compliance Form) по каждому ТСП уровня 1, показывающую, что каждое ТСП прошло успешный аудит соответствия PCI DSS. В отношении эквайреров, не предоставивших платежной системе форму аттестата соответствия, подтверждающую, что каждое ТСП уровня 1 прошло проверку соответствия PCI DSS, после этой даты VISA имеет право применить соответствующие меры по контролю рисков, вплоть до наложения штрафов. При этом указанная дата (30 сентября 2010 г.) не превалирует над более ранними сроками хранения конфиденциальных данных, определенными в конкретных регионах и соответствующими принудительными программами, уже введенными в действие.

Сервис-провайдеры второго уровня не включаются в список PCI DSS Compliant Service Providers, доступный на сайте VISA. Для включения в данный список сервис-провайдер второго уровня должен пройти процедуры проверки соответствия для первого уровня.

Начиная с 1 февраля 2009 г. VISA требует от сервис-провайдеров уровня 1 отправки Attestation of Compliance Form (аттестат соответствия) и раздела «Executive Summary» (результаты проведенного аудита) отчета о соответствии (Report on Compliance, ROC). Сервис-провайдеры уровня 2 отправляют заполненный самоопросник (Self-Assessment Questionnaire, SAQ) версии D. VISA не рассматривает содержимое самоопросника, так как за точность заполнения самоопросника SAQ отвечают эмитенты и эквайреры.

В случае компрометации

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

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

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