PCI DSS 3.0: к чему готовиться?

Журналы регистрации событий PCI DSS 3.0: к чему готовиться?

Андрей Гайко QSA-‐аудитор

© 2002—2014 , Digital Security

© 2002—2014 Digital Security

Главные новости

PCI DSS 3.0: к чему готовиться?

•  Опубликован официальный перевод стандарта

•  Опубликованы сопровождающие документы

•  Выпущен шаблон ROC для PCI DSS 3.0

•  Добавили новые типы SAQ

2


Изменения в новой версии PCI DSS


3

Business as Usual

Расширенные проверочные процедуры

Новая колонка «Пояснения»

Внимание на безопасности, а не на соответствии

Способствует полноте оценки

Пояснения включены в руководство

1

3

2


Изменения в новой версии PCI DSS: Business-‐as-‐usual


4

Мониторинг Проверка корректной работы средств защиты: МЭ, IDS/IPS, антивируса, системы контроля целостности, средств разграничения доступа.

Реагирование на отказы работы средств защиты

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

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

технического механизма) во избежание повторного возникновения причины отказа;

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

Изменение инфраструктуры

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

Изменение организации Формальное ревью области действия Стандарта и приминимости требований вследствие изменении организационной структуры.

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

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


Изменения в новой версии PCI DSS: Разделение ответственности


Стороны должны четко определить:

•  какие требования предъявляются к поставщику услуг?

•  какие службы и системные компоненты входят в область проверки поставщика услуг на соответствие требованиям PCI DSS?

•  какие требования предъявляются к клиенту поставщика услуг?

5


Изменения в новой версии PCI DSS: Разделение ответственности


Поставщик услуг (третья сторона) может подтвердить соответствие требованиям двумя способами:

1.  Самостоятельно пройти оценку соответствия PCI DSS и представить доказательство соответствия своим клиентам (АОС, отредактированный ROC).

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

6


Изменения в новой версии PCI DSS: Хранение критичных данных


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

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

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

Стандарт PCI DSS 3.0, стр.8

7


Изменения в новой версии PCI DSS: Изменение в таблице требований


8

«Понимание назначения требований» «PCI DSS 2.0 Требования и процедуры аудита безопасности»

«PCI DSS 3.0 Требования и процедуры аудита безопасности»


Новые типы SAQ


SAQ D

9

SAQ D for Service Providers

SAQ D for Merchants

SAQ A-‐EP – предназначен ТОЛЬКО для e-‐commerce мерчантов, которые принимают платежи на своем сайте, но через стороннюю сертифицированную по PCI DSS организацию. При этом мерчант не хранит, не обрабатывает и не передает ДДК в любом виде -‐ в ИТ-‐системах или на бумаге.

SAQ B-‐IP – предназначен для мерчантов, использующих отдельностоящие POI-‐терминалы (сертифицированные по PCI PTS), подключенные к платежному шлюзу, и не хранящие ДДК в электронном виде. Не предназначен для e-‐commerce.




10

SAQ A-‐EP Предназначен для мерчантов, которые: •  выполняют прием платежей только посредством e-‐commerce транзакций;

•  всю обработку ДДК предоставляют на аутсорсинг сторонней компании, которая является платежным процессором и соответствует PCI DSS;

•  не принимают платежи на своем сайте, но обеспечивают перенаправление клиентов на страницу оплаты сторонней компании, соответствующей PCI DSS;

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

•  размещают свой веб-‐сайт на серверах хостинга, который соответствует всем необходимым требованиям PCI DSS в части касающейся поставщиков услуг хостинга (в т.ч. требованиям приложения А Стандарта);

•  все элементы платежной страницы веб-‐сайта, предоставляют клиенту со своего сайта или платежного процессора, соответствующего PCI DSS;

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

•  подтверждают, что вся обработка ДДК происходит на стороне сторонней компании, которая соответствует PCI DSS;

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




11

SAQ B-‐IP Предназначен для мерчантов, которые: •  используют только отдельностоящие POI (точки взаимодействия – считыватели карт в

т.ч. SCR) сертифицированные по PCI PTS подключенные по IP к платежному шлюзу;

•  используют отдельностоящие POI сертифицированные по PTS POI и указанные на сайте Совета (за исключением SCR);

•  используют отдельностоящие POI не подключенные к инфраструктуре мерчанта или изолированные (например, выделенные в отдельный сегмент)

•  производят только один тип транзакций – от сертифицированного по PCI PTS POI к платежному шлюзу;

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

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

•  не хранят ДДК в электронном виде.

© 2002—2014 Digital Security 12


Требование 1


13

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


Требование 1.1.3


14

Процесс приема платежей с веб-‐страниц клиентов


Требование 1.1.3


15

Процесс приема платежей с веб-‐страниц клиентов

№ этапа! Описание этапа, метода передачи и/или обработки! Протокол

передачи!Обрабатываемые/

передаваемые на этапе ДДК!Механизм защиты

ДДК!

1" Покупатель на сайте клиента совершает покупку. С сайта клиента , покупателя перенаправляют на страницу оплаты Организации. Покупатель в форму оплаты вводит реквизиты пластикой карты. Данные передаются на WAF где расшифровываются и анализируются на соответствие политикам безопасности веб-‐приложения. "

h�ps" PAN, exp.date, Cardholder name"

Шифрование с использованием алгоритма 3DES"

2" Данные после анализа передаются на обработку веб-‐серверу FRONTSRV." h�p" PAN, exp.date, Cardholder name"

нет"

3" …" h�p" PAN, exp.date, Cardholder name"

нет"




16

•  Теперь необходимо идентифицировать все системные компоненты.

•  На основании перечня системных компонентов и диаграммы потоков данных определяется как полнота области оценки, так и эффективность сегментации.

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

2.4 Вести учет системных компонентов, на которые распространяется действие стандарта PCI DSS.




17

Ничего нового.

Более подробно расписаны требования к управлению ключами, документированию процедур.




18

Ничего нового.

Расширили перечень общедоступных сетей. Теперь это:

•  Интернет;

•  беспроводные технологии, включая протоколы 802.11 и Bluetooth;

•  технологии сотовой связи, например GSM, CDMA;

•  GPRS;

•  спутниковые средства связи.




19

•  Раньше нужно было защищать только «подверженные вирусным атакам» системы.

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

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

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




20

•  Отключение или изменение настроек антивируса только после согласования с руководством.

6.3 Разработать безопасные внутренние и внешние приложения (включая административный доступ к приложениям через веб-‐интерфейс) с соблюдением следующих требований: � � •  согласно требованиям PCI DSS (например, в отношении безопасной

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

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

цикла разработки ПО. Примечание. Требование относится к любому ПО собственной разработки и заказному ПО, разработанному третьим лицом.




21

Разделение ответственности между заказчиком и вендором.

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




22

6.5.10 Противодействие взлому механизмов аутентификации и управления сеансами.




23

•  Необходимо внедрить, реализовать и поддерживать процесс Разделения полномочий (Separa�on/Segrega�on of Du�es, SoD)

7.1.1 Определение прав доступа для каждой должности, включая: •  системные компоненты и ресурсы данных, доступ к которым

необходим для каждой должности для выполнения должностных обязанностей;

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




24

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

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

стойкость, сравнимые с указанными выше параметрами.




25

•  Уход от направленности на пароли, как на основное средство аутентификации.

•  Ввод понятия парольной фразы.

•  Инструкции для пользователей по каждому методу аутентификации.




26

Вопрос: Как определить требования к парольной фразе?

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




27

NIST Special Publica�on 800-‐63-‐1 Electronic Authen�ca�on Guideline

Длина Пользовательский, 94 символа ASCII Произвольный,

94 символа ASCII По словарю По словарю + требования к сложности 7 22 27 46.1 8 24 30 52.7 10 26 32 65.9

12 28 34 79.0 14 30 36 92.2 16 32 38 105.4 18 34 40 118.5 20 36 42 131.7 22 38 44 144.7 24 40 46 158.0 30 46 52 197.2




28

Вопрос: Так какие будут требования к парольной фразе?

Ответ: Минимум 30 букв нижнего регистра.

Для большей стойкости можно добавить обязательное наличие букв в разном регистре И спец.символов.




29

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

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

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

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




30

•  Бейджи больше не обязательное требование.

•  Достаточно эффективного метода отличия сотрудников от посетителей.

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

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

уволенного сотрудника или средств идентификации посетителей с истекшим сроком действия (например, бейджей).




31

•  Физический доступ должен администрироваться.

9.3 Контролировать физический доступ сотрудников к критичным помещениям следующим образом: •  права доступа сотрудников должны быть утверждены на основании

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

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




32

•  Контроль и учет устройств считывания карт (вступит в силу с 1 июля 2015 г.): POS, ATM, кард-‐ридеры для доступа в помещения с банкоматами и т.д.

•  Обучение сотрудников методам распознавания взлома и подмены устройств. Разработка обучающих материалов.

Перечень тем обучения приведен в требовании 9.9.3.

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




33

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

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

•  инициализации журналов, остановка или приостановка ведения журналов.

10.2.1 Любой доступ пользователя к данным держателей карт.

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

10.2.6 Инициализация, остановка или приостановка ведения журналов протоколирования событий.




34

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

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

•  Теперь так же надо изучать аномалии, обнаруженные во время проверки (требование 10.6.3).

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




35

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

•  Актуально для ретейла.

11.1.1 Вести список авторизованных беспроводных точек доступа с указанием их необходимости для ведения дел.




36

Необходима полноценная методика:

•  методика должна включать тестирование на наличие механизмов сегментации и уменьшения области действия Стандарта;

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

•  регламентирует хранение результатов тестов;

•  обязательна с 30 июня 2015 г.

11.3 Внедрить методологию проведения тестирования на проникновение.




37

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

•  Надо проверять корректность изолирования систем входящих в скоуп, от систем не входящих в скоуп.

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




38

•  Термин «мониторинг целостности файлов» заменен на «механизм обнаружения изменений», то есть суть – в фиксации любых изменений в инфраструктуре.

•  Новое требование 11.5.1. Надо реагировать на любые срабатывания этого механизма. Надо фиксировать все

изменения в инфраструктуре и на каждое реагировать.

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




39

•  Цель требования – обеспечить понимание организацией требований PCI DSS, которые согласились выполнять поставщики.

•  Поставщики услуг должны давать клиентам письменное согласие с тем, что они ответственны за безопасность

передаваемых им на обработку ДДК (с июля 2015 г.) (требование 12.9).

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


FAQ


40

Windows XP


FAQ


41

А что, если мы не хотим мигрировать?

Тогда: •  не сможете обновить EMV-‐ядро;

•  не сможете использовать PA-‐DSS софт; •  возникнут проблемы с поддержанием соответствия требованиям PCI DSS;

•  не сможете использовать новый дополнительный функционал для АТМ в будущем.


FAQ


42

Microso¢ Custom Support Agreement (CSA)

или

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


FAQ


43

CSA: •  организация должна обладать статусом

Microso¢ Premier Customer;

•  при наличии статуса, должна платить минимум $200,000 в год за CSA;

•  каждый год взнос будет расти; •  будет действовать только 2 года.


FAQ


44

Компенсационные меры: •  мониторинг специализированных рассылок и иных источников

информации на предмет наличия сведений об уязвимостях для EoL ОС; •  своевременное обновление антивирусных баз; •  своевременное обновление сигнатур IDS/IPS, для обнаружения новых

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

устаревшая ОС в выделеном сегменте сети; •  белые списки ПО; •  удаление неиспользуемого/лишнего ПО и компонентов; •  отключение всех портов (USB, COM).


FAQ


45

Примеры миграции: •  Sco�abank •  Сеть из 2500 банкоматов •  Удаленная миграция с XP на 7 •  €120 за банкомат


FAQ


46

Очевидное-‐невероятное: •  0day Remote Code Execu�on CVE-‐2014-‐1776 Vulnerability in Internet Explorer Could Allow Remote Code Execuvon Published: April 26, 2014


FAQ


47

Мораль:

Чем дольше ждете, тем больше потратите


Примеры схем и таблиц


48

В случае вопросов или предложений по улучшению схем и таблиц пишите: [email protected]

Примеры схем в формате Visio h�p://goo.gl/D9OYPr

Описание требований к схемам h�p://goo.gl/q57qYf

Перечни сведений об инфраструктуре h�p://goo.gl/PDwGBY


Полезные ссылки


49

h�p://ru.pcisecuritystandards.org/minisite/en/

Русско-‐язычная версия официального сайта Совета. На сайте выложены русские версии документов PCI DSS 2.0 и 3.0, PA-‐DSS 2.0 и 3.0, SAQ и т.д.

h�ps://www.pcisecuritystandards.org/approved_companies_providers/approved_scanning_vendors.php

Перечень компаний, предоставляющих услуги ASV-‐сканирования, необходимого для выполнения требования 11.2.2

h�ps://www.google.ru/search?q=penetra�on+tes�ng+course h�ps://www.google.ru/search?q=Pentest+training

Поиск курсов обучения по тестированию на проникновение

h�p://sectools.org/tag/vuln-‐scanners/ h�p://www.scmagazine.com/2013-‐vulnerability-‐assessment-‐tools/slideshow/1167/

Перечень сканеров уязвимостей

h�ps://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools h�p://sectools.org/tag/web-‐scanners/

Перечень сканеров уязвимостей веб-‐приложений

Спасибо за внимание!


Спасибо за внимание!


50

Андрей Гайко QSA-‐аудитор [email protected]

Technology

PCI DSS 3.0: к чему готовиться?