pci dss 3.2

Секция 1Обзор стандарта PCI DSS

© ООО «Дейтерий», 2010 – 2016 | 192012, Россия, Санкт-Петербург, пр. Обуховской Обороны д. 271, лит. А | +7 (812) 361-61-55 | www.deiteriy.com | [email protected]

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

Банк-эквайер – банк, предоставляющий услуги эквайринга.

Банк-эмитент – банк, выпустивший платежную карту.

Международная платежная система (МПС) – сообщество банков, установившее правилаобращения платежных карт (Visa, MasterCard, American Express, Discovery, JCB).

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

Торгово-сервисное предприятие (ТСП) – организация, принимающая платежные карты к оплатеза товары и услуги.

Эквайринг – процесс приема платежных карт к оплате за товары и услуги. Различаютбанкоматный (Automated Teller Machine, ATM) эквайринг – выдачу наличных по платежной картес использованием банкомата, торговый (Point of Sale, POS) эквайринг – прием платежных карт коплате за товары и услуги торгово-сервисных предприятий с использованием POS-терминалов иИнтернет-эквайринг – прием платежных карт к оплате за товары и услуги с использованиемсредств электронной коммерции.

Эмиссия – процесс выпуска (персонализации) платежных карт.


1-3 Эмиссия платежных карт МПС Visa и MasterCard


1-4 Две стадии эквайринга по картам МПС Visa и MasterCard


1-5 Авторизация – шаг 1


1-13 Клиринг и взаиморасчет – шаг 1


1-20 Банки-принципалы и аффилированные банки


1-21 Платежные шлюзы


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


1-23 Распределение ответственности за безопасность данных


1-24 Стандарты безопасности данных индустрии платежных карт

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

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

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

Руководства PCI PTS (Payment Card Industry PIN Transaction Security) – набор руководящихдокументов, содержащих требования к устройствам, обрабатывающим персональныйидентификационный номер – PIN. К таким устройствам относятся POS-терминалы, шифрующиеPIN-клавиатуры (EPP), аппаратные модули безопасности (HSM).


1-25 Стандарты безопасности данных индустрии платежных карт

Стандарт PCI P2PE (Payment Card Industry Point-to-Point Encryption) – набор руководящихдокументов, содержащих требования к решениям, обеспечивающим шифрование «точка-точка» ипозволяющим защитить данные платежных карт от точки ввода карточных данных на стороне ТСПдо точки безопасного расшифрования на стороне эквайера.

Стандарт PCI TSP (Payment Card Industry Token Service Provider) – набор дополнительныхтребований безопасности для поставщиков услуг токенизации.

Стандарты Card Production – стандарты безопасности Logical Security и Physical Security дляэмитентов платежных карт.

Стандарт DESV (Designated Entities Supplemental Validation) – набор дополнительных требованийдля организаций, которым международные платежные системы или банк-эквайер присвоилистатус Designated Entity.


1-26 Стандарт PCI DSS

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

Примеры бизнес-процессов (сервисов):• ATM- и POS-эквайринг в процессинговом центре;• торгово-сервисное предприятие электронной коммерции (Интернет-магазин);• платежный шлюз электронной коммерции;• производство и персонализация платежных карт;• размещение оборудования в машинных залах центра обработки данных;• предоставление виртуальной инфраструктуры центра обработки данных (в т. ч. MSP).

Критерий применимости: хранение, обработка или передача хотя бы одного номера карты какой-либо из пяти международных платежных систем – участниц Совета PCI SSC (Visa, MasterCard,American Express, JCB и Discover) в рамках какого-либо бизнес-процесса организации.

Критерий соответствия: выполнение 100% применимых требований стандарта PCI DSS.

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

Регулярность подтверждения соответствия: ежегодно.


1-27 Стандарт PCI PA-DSS

Объект применения: приложение, которое хранит, обрабатывает или передает данные одержателях карт (платежное приложение), а также процесс его разработки.

Критерий применимости: хранение, обработка или передача хотя бы одного номера карты (PAN)какой-либо из пяти международных платежных систем – участниц Совета PCI SSC (Visa,MasterCard, American Express, JCB и Discover) в процессе авторизации транзакции или выполнениявзаиморасчетов. Не применим к приложениям, разработанным самостоятельно для собственныхнужд, а также к приложениям, разработанным на заказ для одного заказчика.

Критерий соответствия: выполнение 100% применимых к приложению требований стандарта.

Способ подтверждения соответствия: проверка безопасности приложения аудиторскойорганизацией (PA-QSA), сертифицированной Советом PCI SSC.

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


1-28 Структура стандарта PCI DSS

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

1. Защита вычислительной сети.

2. Конфигурация компонентов информационной инфраструктуры.

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

4. Защита передаваемых данных о держателях карт.

5. Антивирусная защита информационной инфраструктуры.

6. Разработка и поддержка информационных систем.

7. Управление доступом к данным о держателях карт.

8. Механизмы аутентификации.

9. Физическая защита информационной инфраструктуры.

10. Протоколирование событий и действий.

11. Контроль защищенности информационной инфраструктуры.

12. Управление информационной безопасностью.


1-29 Способы подтверждения соответствия стандарту PCI DSS

Внешний аудит (QSA) Внутренний аудит (ISA) Самооценка (SAQ)

Выполняется внешнейаудиторской организацией(Qualified Security Assessor,QSA), сертифицированнойСоветом PCI SSC.

Выполняется внутреннимпрошедшим обучение исертифицированным попрограмме Совета PCI SSCаудитором (Internal SecurityAssessor, ISA).

Выполняется самостоятельнопутем заполнения листасамооценки (Self-AssessmentQuestionnaire, SAQ).

В ходе проверки QSA-аудиторысобирают свидетельствавыполнения требованийстандарта и сохраняют их втечение трех лет.

В ходе проверки ISA-аудиторысобирают свидетельствавыполнения требованийстандарта и сохраняют их втечение трех лет.

Сбор свидетельств выполнениятребований стандарта нетребуется.

По результатам QSAподготавливает Отчет оСоответствии (Report onCompliance, ROC).

По результатам ISAподготавливает Отчет оСоответствии (Report onCompliance, ROC).

Отчетным документомявляется самостоятельнозаполненный лист самооценкиSAQ.


1-30 Обязательные независимые проверки защищенности

Проверка Описание

Требование 11.2 PCI DSSВнешнее сканированиеуязвимостей компонентовинформационнойинфраструктуры (ASV)

Выполняется ежеквартально поставщиком услуг сканирования(Approved Scanning Vendor, ASV), сертифицированным СоветомPCI SSC.

Сканированию подлежат все внешние IP-интерфейсыинформационной инфраструктуры в рамках областиприменимости требований стандарта PCI DSS.

Требование 11.3 PCI DSSВнешнее и внутреннеетестирование на проникновение(pentest)

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

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




Требование 11.2 PCI DSSВнешнее сканированиеуязвимостей компонентовинформационнойинфраструктуры (ASV)

Выполняется ежеквартально поставщиком услуг сканирования(Approved Scanning Vendor, ASV), сертифицированным СоветомPCI SSC.

Сканированию подлежат все внешние IP-интерфейсыинформационной инфраструктуры в рамках областиприменимости требований стандарта PCI DSS.

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

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




Требование 11.3 PCI DSSВнешнее и внутреннеетестирование на проникновение(pentest)

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

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

(*) После 1 февраля 2018 года поставщикам услуг необходимобудет проводить тестирование на проникновение в частипроверки корректности сегментации сети не реже одного разав шесть месяцев.


1-33 Контроль защищенности внешних веб-приложений


Требование 6.6 PCI DSSКонтроль защищенностивнешних (публичных) веб-приложений

Существует три варианта выполнения требования:

• сканирование уязвимостей приложения при помощиспециализированного сканера безопасности веб-приложений;

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

• установка перед веб-приложением межсетевого экранаприкладного уровня (Web Application Firewall, WAF).


1-34 Уровни и требования международных платежных систем

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

Классификация определяет два типа организаций, это торгово-сервисные предприятия(мерчанты) и поставщики услуг.

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

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

Международные платежные системы и банк-эквайер могут дополнительно присвоить статусDesignated Entity организации, которая обрабатывает большие объемы данных платежных картили была неоднократно замечена в ходе расследований инцидентов ИБ, связанных с их утечкой.Этот статус будет обязывать организацию проходить дополнительную сертификацию DESV.


1-35 Классификация Visa, торгово-сервисные предприятия

Уровень КритерииПодтверждение

соответствия PCI DSS

1

• обработка более 6 млн. транзакций в год, или

• решение Visa о назначении уровня 1

• QSA или ISA ежегодно

• ASV ежеквартально

2

• обработка от 1 до 6 млн. транзакций в год • SAQ ежегодно


3

• обработка от 20 тыс. до 1 млн. транзакций в год сприменением электронной коммерции

• SAQ ежегодно


4

• обработка до 20 тыс. транзакций в год с применениемэлектронной коммерции, или до 1 млн. транзакций в годиным способом

• SAQ ежегодно (рекомендовано)

• ASV ежеквартально (если применимо)


1-36 Классификация MasterCard, торгово-сервисные предприятия



1

• обработка более 6 млн. транзакций в год, или

• решение MasterCard о назначении уровня 1, или

• уровень 1 согласно критериям Visa, или

• компрометация карточных данных



2

• обработка от 1 до 6 млн. транзакций в год, или

• уровень 2 согласно критериям Visa



3

• обработка от 20 тыс. до 1 млн. транзакций в год сприменением электронной коммерции, или

• уровень 3 согласно критериям Visa

• SAQ ежегодно


4• все остальные • SAQ ежегодно



1-37 Классификация Visa, поставщики услуг



1

• обработка более 300 тыс. транзакций в год*, или

• процессинг, напрямую подключенный к VisaNet (черезVisaNet Extended Access Server, VEAS), (VNP),независимоот количества транзакций

• QSA ежегодно


2

• обработка менее 300 тыс. транзакций в год • SAQ ежегодно


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


1-38 Классификация MasterCard, поставщики услуг



1

• обработка более 300 тыс. транзакций в год*, или

• внешний процессинг (Third Party Processor, TPP),независимо от количества транзакций

• QSA ежегодно


2

• обработка менее 300 тыс. транзакций в год • SAQ ежегодно


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


Секция 2Внедрение стандарта PCI DSS


2-2 Внедрение стандарта PCI DSS

Пятью международными платежными системами – Visa Inc., MasterCard Worldwide, AmericanExpress, JCB International и Discover Financial Services были предприняты усилия по объединениюсобственных программ международных платежных систем по обеспечению безопасностикарточных данных, таких как Visa Account Information Security (AIS) и MasterCard Site DataProtection (SDP).

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

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

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

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


2-3 Мотивация внедрения PCI DSS в мировой практике

Отношения «Кнут» «Пряник»

МПС –Эквайер

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

• штраф от 25 до 200 тыс. долларов;

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

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

Эквайер –Мерчант

• расторжение или не заключениедоговора эквайринга.

• снижение размера комиссии запроведение транзакции.

Эквайер –Поставщик услуг

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

• совместные проекты пообслуживанию мерчантов.

Мерчант –Поставщик услуг

иПоставщик услуг –Поставщик услуг



2-4 Мотивация внедрения PCI DSS в российской практике

Отношения «Кнут» «Пряник»

МПС –Эквайер

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

• штраф от 25 до 200 тыс. долларов;

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

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

Эквайер –Мерчант

• расторжение или не заключениедоговора эквайринга.

• снижение размера комиссии запроведение транзакции.

Эквайер –Поставщик услуг


• совместные проекты пообслуживанию мерчантов.

Мерчант –Поставщик услуг

иПоставщик услуг –Поставщик услуг



2-5 Роль и место процесса внедрения PCI DSS в организации

В компании без выделенных ИТ и ИБ подразделений(малый магазин)

В компании с выделенным ИТ-подразделением(средний магазин, платежный шлюз)

В компании с выделенными ИТ- и ИБ-подразделениями(крупный магазин, крупный поставщик услуг, банк)


2-6 Процесс внедрения PCI DSS в общем виде


2-7 Внедрение PCI DSS собственными силами

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

** - невозможно самостоятельно подтвердить соответствие в случае, когда требуется QSA-аудит.

*** - внутренний ISA аудитор должен быть обучен и сертифицирован Советом PCI SSC.


2-8 Внедрение PCI DSS с минимальным уровнем аутсорсинга

* - тест на проникновение может быть выполнен квалифицированным персоналом консультанта.

** - лист самооценки SAQ может быть заполнен консультантом, что сокращает затраты времени иснижает вероятность ошибки при заполнении.

*** - QSA-аудит может выполняться только консультантом, сертифицированным Советом PCI SSC.


2-9 Внедрение PCI DSS со средним уровнем аутсорсинга

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

** - консультант выдает рекомендации, ИТ- и ИБ-подразделения организации их внедряют.

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


2-10 Внедрение PCI DSS с максимальным уровнем аутсорсинга

* - консультант-интегратор разрабатывает и внедряет необходимые технические иорганизационные решения.

** - консультант-интегратор выполняет регулярные процедуры и ведет необходимые записи.


2-11 Типовой проект по внедрению PCI DSS (средний аутсорсинг)


2-12 Этапы проекта по внедрению PCI DSS

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

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

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


2-13 Этапы проекта по внедрению PCI DSS (продолжение)

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

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

ASV-сканирование – автоматизированное сканирование внешнего периметра сети на наличиеуязвимостей, которое выполняется при помощи сканера, предоставляемого сертифицированнымпоставщиком услуг сканирования (Approved Scanning Vendor, ASV).

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


2-14 Этапы проекта по внедрению PCI DSS (продолжение)

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

Заполнение листа самооценки SAQ – выполнение мероприятий по самооценке соответствияинформационной инфраструктуры организации требованиям стандарта PCI DSS. В ходе этойпроцедуры заполняется лист самооценки (Self Assessment Questionnaire, SAQ), разработанныйСоветом PCI SSC. Форма листа SAQ бывает нескольких типов (A, A-EP, B, B-IP, C, C-VT, P2PE, D),выбор типа листа зависит от специфики обработки карточных данных в организации.

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


2-15

Вариант ПрименимостьКол-во

вопросов

SAQ A

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

24

(было 14)

SAQ A-EP

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

192

(было 139)

SAQ B

Мерчанты, использующие механические импринтеры или выделенные POS-терминалы, использующие телефонную линию, не передающие карточныеданные через Интернет, и не имеющие электронных хранилищ карточныхданных.Не применим к электронной коммерции.

41

SAQ B-IP

Мерчанты, использующие выделенные POS-терминалы, прошедшие проверку насоответствие стандарту PCI PTS, использующие IP-соединение с процессинговымцентром, и не имеющие электронных хранилищ карточных данных.Не применим к электронной коммерции.

83

Продолжение таблицы на следующем слайде…

Применение листов самооценки PCI DSS 3.2


2-16 Применение листов самооценки PCI DSS 3.2

Вариант ПрименимостьКол-во

вопросов

SAQ C-VT

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

79

(было 74)

SAQ C

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

158

(было 140)

SAQ P2PE

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

33

(было 35)

SAQ DВсе мерчанты и все поставщики услуг, кроме тех, кому согласно требованиям МПСили эквайера необходим ISA- или QSA-аудит. 415


2-17 Применение листов самооценки PCI DSS 3.2


Что изменилось в SAQ A 3.2?

• Добавили технические требования 2.1, 8.1.1, 8.1.3, 8.2, 8.2.3, 8.5.• Добавили требование о наличии плана реагирования на инцидент в случае взлома.• Добавили возможность указать информацию о QIR (Qualified Integrator and Reseller).• Уточнили, что ДДК из отчетов торгово-сервисное предприятие может сохранять только на

бумажных носителях.• Косметические исправления.• Добавили в Appendix A3 текст о возможной применимости DESV к торгово-сервисному

предприятию.

Что изменилось в SAQ A-EP 3.2?

• Расширили перечень требований в части 1, 4, 5, 6, 7, 8, 10 и 11 разделов PCI DSS.• Добавили Appendix A2 для торгово-сервисных предприятий, которые используют

небезопасные версии протоколов SSL и TLS.• Изменения аналогичные SAQ A 3.2.

Секция 3Область применимости требований PCI DSS


3-2 Определение области применимости стандарта PCI DSS

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

Смежная информационная система – это система, соединение с которой не защищено корректнонастроенным межсетевым экраном.


3-3 Данные платежных карт

Вид Обозначение Определение

Номер карты PANНомер, идентифицирующий платёжную карту,наносится на её лицевую сторону.

Имя держателя карты CHNAMEИмя и фамилия человека, которому банк предоставилправо распоряжения платёжной картой, наносится наеё лицевую сторону.

Дата окончаниясрока действия карты

EXPDATEДата, после которой платёжная карта становитсянедействительной, наносится на её лицевую сторону.

Сервисный код SCODEСлужебное значение, содержащееся на магнитнойполосе (чипе) карты.

Содержимое магнитной полосы / чипа

TRACKВся информация, содержащаяся на магнитной полосе(чипе) карты.

Проверочное значение CVV2 / CVC2Значение, используемое для авторизации платёжнойтранзакции без считывания магнитной полосы (чипа)карты, наносится на её оборотную сторону.

ПИН-коди его шифрограмма

PIN и PINBLOCKЗначение, используемое для авторизации платёжнойтранзакции на банкоматах и POS-терминалах, и егошифрограмма (ПИН-блок).


3-4 Категории данных платежных карт (ДПК)

Категория Вид Правила хранения

Данные о держателях карт (ДДК)

PANПри хранении следует применять один из методов защиты согласно требованию 3.4 стандарта PCI DSS.

CHNAME

Разрешается хранить.EXPDATE

SCODE

Критичные аутентификационные

данные (КАД)

TRACK

Запрещается хранить после авторизации транзакции,даже в зашифрованном виде.

CVV2 / CVC2

PIN и PINBLOCK


3-5 Информационная инфраструктура организации

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

* – определение информационной инфраструктуры взято из публикации «Theorizing about theDesign of Information Infrastructures: Design Kernel Theories and Principles», O. Hanseth, K. Lyytinen.


3-6 Описание информационной инфраструктуры

Информационная инфраструктура может быть описана следующими тремя элементами*:

1. Перечень компонентов информационной инфраструктуры по уровням:

• приложения;

• хранилища данных (базы данных и плоские файлы);

• компьютеры;

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

2. Схема сетевой инфраструктуры;

3. Схема потоков данных (прикладной инфраструктуры).

* – согласно официальной процедуре QSA-аудита, утвержденной Советом PCI SSC, каждый Отчет оСоответствии (Report on Compliance, ROC) должен содержать в себе все три элемента описанияинформационной инфраструктуры организации в рамках области аудита: перечень компонентов,схему сети и схему потоков данных.


3-7 Инфраструктура банка (упрощенная) – схема сети


3-8 Инфраструктура банка (упрощенная) – компоненты

Приложения

НазваниеНа каком компьютере

установленоКакие хранилища использует

PA-DSS

Карточный фронт-офис• Сервер приложений

карточного фронт-офиса• БД карточного фронт-офиса +

Карточный бэк-офис• Сервер приложений

карточного бэк-офиса

• БД карточного бэк-офиса

• Сетевая папка на сервере приложений карточного бэк-офиса

+

АБС • Сервер приложений АБС • БД АБС -

Интернет-банк• Веб-сервер Интернет-банка

• БД Интернет-банка -

Приложение для выпуска карт

• Компьютер для персонализации карт

• БД карточного бэк-офиса +



Хранилища данных

Тип НазваниеНа каком компьютере

установленоКакие ДДК хранит

БД БД карточного фронт-офисаСервер БДкарточного фронт-офиса

PAN

БДБД карточного бэк-офиса

Сервер БДкарточного бэк-офиса

PAN

БДБД АБС Сервер БД АБС -

БДБД Интернет-банка Сервер БД Интернет-банка PAN

ФайлыСетевая папка на сервере приложений карточногобэк-офиса

Сервер приложенийкарточного бэк-офиса

PAN



Компьютеры

Название IP-интерфейсы ОС

Сервер приложений карточного фронт-офиса 10.10.8.2 Windows Server 2008

Сервер приложений карточного бэк-офиса 10.10.8.4 Windows Server 2008

Сервер приложений АБС 10.10.8.6 Red Hat Enterprise Linux 6

Веб-сервер Интернет-банка 192.168.110.8 Red Hat Enterprise Linux 6

Сервер БД карточного фронт-офиса 10.10.8.3 Windows Server 2008

Сервер БД карточного бэк-офиса 10.10.8.5 Windows Server 2008

Сервер БД АБС 10.10.8.7 Red Hat Enterprise Linux 6

Сервер БД Интернет-банка 192.168.110.9 Red Hat Enterprise Linux 6

Рабочая станция 1 192.168.110.101 Windows 7 Professional

Рабочая станция 2 192.168.110.102 Windows 7 Professional

Компьютер для персонализации карт 10.10.8.15 Windows 7 Professional

HSM 1 10.10.8.11 -

HSM 2 10.10.8.12 -



Активное сетевое оборудование

Название IP-интерфейсы Модель

Маршрутизатор 1

LAN10.10.8.251

Cisco 2800 Series WAN white IPx.x.x.x

Маршрутизатор 2

LAN10.10.8.252

Cisco ASA 5500 Series LAN192.168.110.252

WAN white IPy.y.y.y


3-12 Инфраструктура банка (упрощенная) – потоки ДДК


3-13 Область применимости PCI DSS в инфраструктуре банка

Голубым цветом отмечены компоненты,обрабатывающие, хранящие и передающие ДДК


3-14 Область аудита PCI DSS

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

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

В большинстве случаев область аудита совпадает с областью применимости PCI DSS.

Исключением из этого правила являются банки, обладающие собственной как эквайринговой, таки эмиссионной инфраструктурой. На момент 2012 года для них существует неофициальноеправило МПС Visa и MasterCard, гласящее, что приводить в соответствие требованиям PCI DSSследует как эквайринговую, так и эмиссионную инфраструктуру, однако при этом в областьсертификационного аудита входит только эквайринговая часть. Эмиссионная инфраструктураможет быть включена в область аудита по желанию эмитента (это приветствуется) или поотдельному требованию международной платежной системы*.

* – эта информация получена в октябре 2010 года в ходе ежегодного мероприятия PCI SSCEuropean Community Meeting 2010 от главы службы безопасности МПС Visa Europe – Шейна Болфе(Shane Balfe) и вице-президента по безопасности МПС MasterCard Майкла Грина (Michael Green).


3-15 Инфраструктура банка (упрощенная) – потоки ДДК - эмиссия


3-16 Область аудита PCI DSS в инфраструктуре банка

Желтым цветом отмечены компоненты, обрабатывающие,хранящие и передающие только эмиссионные (свои) ДДК


3-17 Смежные информационные системы в инфраструктуре банка

Красным цветом отмечены компоненты, относящиеся ксмежным информационным системам


3-18 Потоки ДДК между участниками процесса эквайринга


3-19 Платежный шлюз – схема сети (упрощенная)


3-20 Платежный шлюз – потоки ДДК


3-21 Платежный шлюз – область применимости PCI DSS



3-22 Интернет-магазин – схема сети

Этот Интернет-магазин принимает ДДК на своем сайте


3-23 Интернет-магазин – потоки ДДК



3-24 Интернет-магазин – область применимости PCI DSS




3-25 Розничный магазин – схема сети


3-26 Розничный магазин – потоки ДДК


3-27 Розничный магазин – область применимости PCI DSS



Секция 4Сужение области применимости стандарта PCI DSS


4-2 Сужение области применимости PCI DSS

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

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

• снижает затраты на обеспечение безопасности данных о держателях карт и выполнениетребований стандарта PCI DSS.


4-3 Методы сужения области применимости PCI DSS

Уменьшить размер области применимости требований PCI DSS можно следующими способами:

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

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

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

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


4-4 Область применимости PCI DSS в инфраструктуре банка

- обработка ДДК эквайринга - обработка ДДК эмиссии - смежные системы


4-5 Потоки ДДК в инфраструктуре банка

- потоки ДДК эквайринга - потоки ДДК эмиссии


4-6 Шаг 1 - избежать обработки, хранения и передачи ДДК

Согласно бизнес-требованиям

рассматриваемого банка, приложение Интернет-

банка может оперировать маскированными значениями PAN

Можно организовать терминальный доступ к ДПК (тонкий клиент)

с двухфакторной аутентификацией


4-7 Шаг 1 - избежать обработки, хранения и передачи ДДК

- потоки ДДК эквайринга - потоки ДДК эмиссии - не ДДК


4-8 Шаг 2 - шифровать передаваемые ДДК

Можно зашифровать канал связи для тонкого

клиента (например, использовать VPN)

- потоки ДДК эквайринга - потоки ДДК эмиссии - нет ДДК в открытом виде


4-9 Шаг 2 - шифровать передаваемые ДДК

- потоки ДДК эквайринга - потоки ДДК эмиссии - нет ДДК в открытом виде


4-10 Результат выполнения шагов 1 и 2



4-11 Шаг 3 - отделить смежные информационные системы

Теперь ничто не мешает отделить сегмент 192.168.110.x

межсетевым экраном на Маршрутизаторе 2

Приложение и БД АБС можно выделить в отдельный

сегмент сети



4-12 Результат выполнения шага 3

- обработка ДДК эквайринга - обработка ДДК эмиссии


4-13 Результат сужения области применимости PCI DSS в банке

- обработка ДДК эквайринга - обработка ДДК эмиссии


4-14 Область применимости PCI DSS в розничном магазине


4-15 Потоки ДДК в розничном магазине


4-16 Применение токенизации

Согласно бизнес-требованиям

рассматриваемого магазина, ERP-система

может оперировать уникальными

идентификаторами клиентов вместо PAN



- обработка ДДК эквайринга - смежные системы


4-19 Применение сегментации

ERP-систему и рабочую станцию можно

выделить в отдельный сегмент сети

- обработка ДДК эквайринга - смежные системы


4-20 Применение сегментации

- обработка ДДК эквайринга


4-21 Результат сужения области применимости PCI DSS в магазине

- обработка ДДК эквайринга


Секция 5Выполнение требований PCI DSS


5-2 Метод приоритетного подхода

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

В ответ на закономерный вопрос: «С выполнения какого требования стандарта лучше начинатьего внедрение?» Советом PCI SSC был разработан документ под названием «Приоритетныйподход к выполнению требований стандарта PCI DSS».

Приоритетный подход рекомендует выполнять требования в шесть этапов:

1. Удаление КАД и ограничение хранения ДДК.

2. Защита периметра, внутренних и беспроводных сетей.

3. Обеспечение безопасности приложений, БД и ОС.

4. Мониторинг и контроль доступа.

5. Защита хранимых данных.

6. Внедрение системы менеджмента информационной безопасности.

* - вариантами подтверждения соответствия стандарту PCI DSS являются: заполнение листасамооценки (SAQ), выполнение внутреннего ISA-аудита и выполнение внешнего QSA-аудита.


5-3 Этап 1. Удаление КАД и ограничение хранения ДДК

Согласно требованиям раздела 3 стандарта PCI DSS, критичные аутентификационные данные(КАД), к которым относятся TRACK, CVV2, PIN или PIN-block, после авторизации транзакциихранить запрещается. Единственным исключением является хранение КАД эмитентом дляобеспечения возможности авторизации транзакции.

Номера карт (PAN), относящиеся к данным о держателях карт (ДДК), хранить можно, при этом онидолжны быть защищены в соответствии с требованием 3.4 стандарта PCI DSS.

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

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

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

«Если тебе это больше не нужно – не храни это» –золотое правило обеспечения безопасности индустрии платежных карт.



Иногда найти, где именно в информационной инфраструктуре организации спрятались КАД и ДДКбывает очень непросто. Задача несколько облегчается тем, что у каждого вида ДДК или КАД естьсвои излюбленные места:

1. PAN - обитает практически везде, но особенно предпочитает:

• таблицы баз данных с журналами транзакций;

• файлы протоколирования событий приложений фронт-офиса;

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

• таблицы баз данных бэк-офиса;

• журналы протоколирования событий на банкоматах (ATM), их контрольная лента;

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

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

• АБС банка;

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

• автоматизированные системы риск-менеджмента и фрод-мониторинга.



2. CVV2 - в особенности любит все, что связано с электронной коммерцией:

• хранилища данных и журналы, связанные с платежными системами Интернет-магазина;

• Лог-файлы входящих запросов веб-серверов (например, Apache).

• таблицы баз данных бэк-офиса.

Если организация не занимается Интернет-эквайрингом, то найти у неё в информационнойинфраструктуре CVV2 почти невозможно.

3. TRACK - он есть везде, где есть кард-ридер:

• таблицы баз данных с журналами card-present транзакций;

• файлы протоколирования событий приложений фронт-офиса;

• журналы протоколирования событий на банкоматах (ATM), их контрольная лента;

• в розничных магазинах – в журналах встроенных в кассовое решение POS-приложений;

• системы персонализации карт.

4. PIN/PIN-блок - в открытом виде PIN практически не встречается, зато в виде шифрограммы(PIN-блок) является верным спутником TRACK там, где есть card-present транзакции:

• файлы протоколирования событий старых приложений фронт-офиса;

• таблицы баз данных с журналами card-present транзакций старых приложений.


5-6 Этап 2. Защита периметра, внутренних и беспроводных сетей

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

На этом этапе следует решить три задачи:

• защитить вычислительную сеть организации путем корректной настройки маршрутизаторов имежсетевых экранов, а также организации выделенного защищенного внутреннего (CardholderData Environment, CDE) и пограничного DMZ-сегмента* сети;

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

• обеспечить безопасность передаваемых ДДК путем шифрования каналов связи, по которымони передаются (можно применять широкий спектр решений от различных VPN до SSL).

* - основное правило организации CDE и DMZ таково: все компоненты, хранящие ДДК, должныбыть расположены в CDE, при этом все внешние соединения должны иметь возможностьустанавливать соединения только с компонентами, расположенными в DMZ. Все соединения изCDE во внешнюю среду должны также иметь возможность устанавливать соединения только скомпонентами в DMZ.


5-7 Этап 2. Защита периметра, внутренних и беспроводных сетей

DMZ CDE


5-8 Этап 3. Обеспечение безопасности приложений, БД и ОС

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

На этом этапе следует решить четыре задачи:

• наладить процесс безопасной поддержки информационной инфраструктуры, внедривпроцедуры управления изменениями. Хорошей практикой будет внедрение такого элемента изруководства ITIL-ITSM как база данных управления конфигурациями Configuration ManagementDatabase (CMDB). Необходимо обеспечить регулярное обновление программного обеспечения,как минимум – установку критических патчей. Если в организации ведется разработкапрограммного обеспечения, следует выделить под неё отдельную среду разработки, несвязанную с производственными системами.

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

• разработать и внедрить организационные процедуры управления логическим и физическимдоступом к данным. Лучшим вариантом будет внедрение метода управления доступом,основанного на ролях пользователей в бизнес-процессах (Role-Based Access Control, RBAC);

• внедрить средства антивирусной защиты информационной инфраструктуры.


5-9 Этап 4. Мониторинг и контроль доступа

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

На этом этапе следует решить три задачи:

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

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

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


5-10 Этап 5. Защита хранимых данных

Информационная инфраструктура защищена и можно приступить к защите самих данных одержателях карт, хранящихся в её ядре – среде данных о держателях карт (Cardholder DataEnvironment, CDE).

После того, как были удалены все критичные аутентификационные данные, хранимые данные одержателях карт представлены только номером карты (PAN).

При хранении номера карты следует применять один из методов защиты согласно требованию 3.4стандарта PCI DSS:• шифрование;• маскирование (1234 56xx xxxx 7890);• однонаправленная хеш-функция*;• токенизация**.

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

** – токен – уникальный идентификатор транзакции или карты, используемый вместо PAN.


5-11 Этап 6. Внедрение системы менеджмента ИБ

Информационная безопасность – это процесс, который имеет начало, но не имеет конца, и имнеобходимо управлять. Для закрепления внедренных методов защиты данных о держателях картследует внедрить процессы информационной безопасности, выполняемые на практике в строгомсоответствии с документированными процедурами. Хорошим решением здесь будет следованиерекомендациям таких стандартов, как ISO 27001 и СТО БР ИББС-1.0.

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

Одноуровневая – содержит минимально необходимые инструкции и стандарты конфигурации.Может вестись в виде записей в системе JIRA или на движке WIKI.

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

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


5-12 Этап 6. Внедрение системы менеджмента ИБ

В компании без выделенных ИТ и ИБ подразделений(малый магазин)

В компании с выделенным ИТ-подразделением(средний магазин, платежный шлюз)

В компании с выделенными ИТ- и ИБ-подразделениями(крупный магазин, крупный поставщик услуг, банк)

Одноуровневая

Двухуровневая

Трехуровневая


5-13 Цикл развития стандарта PCI DSS


Совет PCI SSC – международный регулятор в сфере безопасностииндустрии платежных карт – применяет трехлетний циклразвития стандартов PCI:

Первый год:Внедрение в индустрию

(28 апреля опубликована версия 3.2;версия 3.1 действует до 28 октября)

Второй год:Сбор обратной связи

(действует одна версия: 3.2)

Третий год:Согласование новой версии(публикация ожидается осенью;рекомендуемые требования 3.2

становятся обязательными)

2017

Версия 3.2 стандарта PCI DSS?

• опубликована 28 апреля 2016 года;

• до 28 октября 2016 года официально действуют обе версии – и старая 3.1, и новая 3.2;

• часть новых требований вступит в силу в феврале 2018 года.


PCI DSS версии 3.2, что нас ждет?5-14

Разновидности нововведений:

• терминологические и косметические;

• для всех организаций, применяющих PCI DSS;

• только для поставщиков услуг (не

мерчантов).



Терминология и косметика:

• убраны конкретные примеры «стойких» и

«нестойких» протоколов и алгоритмов,

поскольку практика показала, что это может

измениться в любой момент.



5-17


• «двухфакторная аутентификация» заменена

на «мультифакторную».

pas****d


PCI DSS версии 3.2, что нас ждет?

5-18


• видеонаблюдение или СКУД, или обе

технологии вместе.



5-19

Изменения для всех:

• для любого удаленного доступа к

сертифицируемой по PCI DSS среде нужно

включить мультифакторную аутентификацию.



5-20

Изменения для всех:

• при внесении любых изменений в

сертифицированную инфраструктуру следует

проверять выполнение требований PCI DSS.



5-21

Изменения для поставщиков услуг:

• архитектуру системы шифрования нужно

документировать.



5-22


• контролировать работоспособность всех

систем безопасности.




• тестирование напроникновениедля проверкисегментации средыпроводить не режеодного раза вшесть месяцев.



5-24


• разработать и выполнять программу

поддержки соответствия требованиям

стандарта PCI DSS.



5-25


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

= выборочный внутренний аудит



5-26

SSL и TLS:

• до 30 июня 2016 года все поставщики услуг

должны обеспечить поддержку протокола TLS

версии не ниже версии 1.1;

• до 30 июня 2018 года полностью отказаться от

использования небезопасных версий

протоколов (прощай SSL всех версий и TLS 1.0).



5-27 Компенсационные меры и причины их применения

Наиболее распространёнными причинами применения компенсационных мер на сегодняявляются:

• зависимость бизнес-процессов организации от устаревшего, неподдерживаемогопроизводителем программного обеспечения или оборудования;

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

• существенные бюджетные ограничения;

• до недавнего времени – отсутствие в России хостинг-провайдеров, сертифицированных постандарту PCI DSS.


5-28 Требования к компенсационным мерам

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

Компенсационная мера должна снижать риск в той же степени, что и требование стандарта.

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

Компенсационная мера не должна противоречить другим требованиям стандарта PCI DSS.

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


Секция 6Сертификационный QSA-аудит


6-2 Сертификационный QSA-аудит

Сертификационный QSA-аудит – это внешняя независимая аудиторская проверка соответствияорганизации требованиям стандарта PCI DSS, выполняемая QSA-аудиторами,сертифицированными Советом PCI SSC.

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

* - другими вариантами подтверждения соответствия стандарту PCI DSS являются заполнениелиста самооценки (SAQ) и выполнение внутреннего ISA-аудита.


6-3 Когда можно приступать к сертификационному QSA-аудиту?

Вопрос Да / Нет

К сертификационному аудиту рекомендуется приступать, если дан ответ «Да» на все вопросы:

Выполнены ли все задачи, предусмотренные планом или рекомендациями поприведению организации в соответствие PCI DSS?

Выполняются ли на практике все требования внутренних нормативныхдокументов по информационной безопасности?

Выполнено ли ASV-сканирование и тестирование на проникновение?

Устранены ли уязвимости, если они были выявлены в ходе ASV-сканированияи тестирования на проникновение?

Проведено ли повторное сканирование и тестирование после исправления,подтвердившее отсутствие критичных уязвимостей?


6-4 Процедура сертификационного QSA-аудита

Сертификационный QSA-аудит выполняется при личном присутствии QSA-аудитора в офисесертифицируемой компании. Официальным статусом QSA должен обладать каждый аудитор,выполняющий проверки в процессе сертификационного QSA-аудита. Проверить действительныйстатус QSA-аудитора можно на официальном сайте Совета PCI SSC www.pcisecuritystandards.org.

В ходе аудита аудиторами выполняются следующие действия:

• Определение области аудита;

• Интервьюирование сотрудников;

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

• Наблюдение за функционированием информационных систем;

• Изучение внутренних нормативных документов;

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

• Сбор свидетельств выполнения требований PCI DSS (копии документов и записей, снимкиэкрана, фотографии)*.

* - свидетельства сохраняются у QSA-компании в течение трех лет с момента аудита и могут быть влюбой момент предоставлены Совету PCI SSC в рамках программы контроля качества услуг QSA.


http://www.pcisecuritystandards.org/

6-5 Результаты сертификационного QSA-аудита

Итог Поставщик услуг (в т. ч. банк) Торгово-сервисное предприятие

Подтверждено 100%

соответствие

QSA предоставляет заказчику:

• Отчет о Соответствии (ROC);

• Свидетельство о Соответствии (AOC);

• Сертификат Соответствия.

QSA предоставляет МПС:

• Свидетельство о Соответствии;

• Резюме Отчета о Соответствии;

• Отчет о Соответствии (по запросу).


• Отчет о Соответствии (ROC);

• Свидетельство о Соответствии (AOC);

• Сертификат Соответствия.

Торгово-сервисное предприятие позапросу предоставляет Отчет оСоответствии своему банку-эквайеру.

Выявлены несоответствия


• Отчет о соответствии (ROC)*.

• Свидетельство о соответствии (АОС).


• Отчет о соответствии (ROC)*.

• Свидетельство о соответствии (АОС).

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


6-6 Стандартизованный шаблон Отчета о соответствии (ROC 3.0)


pci dss 3.2

Technology