PCI DSS как перейти с версии 2.0 на 3.0

© ООО «Дейтерий», 2010 – 2013 | 192236, Россия, Санкт-Петербург, ул. Софийская д. 8-1Б | +7 (812) 361-61-55 | www.deiteriy.com | [email protected]

Стандарт PCI DSS: как перейти с версии 2.0 на 3.0

Сергей Шустиков Генеральный директор Deiteriy

CISA, PCI QSA, PCI PA-QSA

27 февраля 2014 года, семинар RISSPA

2 Цикл развития стандарта PCI DSS


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

Внедрение в индустрию (действуют обе версии: 2.0 и 3.0)

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

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

Третий год: Согласование новой версии

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

3.0 2015

3 Что делать в 2014 году?


«Я впервые начинаю готовиться к подтверждению соответствия PCI DSS, какую версию мне выбрать?»

- PCI DSS 3.0.

«Я долго готовился к подтверждению соответствия PCI DSS, а тут новая версия стандарта вышла, что мне делать?»

- подтвердить соответствие PCI DSS 2.0 и постепенно переходить на 3.0.

«Я подтвердил соответствие PCI DSS 2.0 в 2013 году, какую версию мне выбрать в 2014?»

- зависит от...

4 Обзор существенных изменений


Категория Было в версии 2.0 Стало в версии 3.0

Уточнение -

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

Изменение

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

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

Изменение -

Необходимо вести полный перечень компонентов информационной инфраструктуры с описанием их свойств и функций

Уточнение Расширен перечень способов хранения криптографических ключей, в том числе добавлены HSM

5 Обзор существенных изменений (продолжение)



Уточнение - Документированные процедуры SDLC распространяются на приложения, разрабатываемые на заказ

Уточнение Присутствовало неявно

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

Изменение Отдельные требования о длине и сложности пароля

Увеличена гибкость путем объединения в одно требование о длине и/или сложности пароля

Изменение (активно с 1 июля 2015 года)

-

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


- Добавлено требование о необходимости борьбы с подменой POS-терминалов

6 Обзор существенных изменений (продолжение)



Уточнение Следует ежедневно читать и анализировать все журналы протоколирования событий

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


- Определены требования к методике теста на проникновение и необходимость её документирования

7 Переход на версию PCI DSS 3.0


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

8 Задачи перехода на версию PCI DSS 3.0


Задача №1: Взять перечень логов из требования 10.6.1 и проверить, что все они пишутся и анализируются ежедневно:

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



Задача №2: Доработать процедуру ежегодного анализа рисков, включив в нее принятие решения о том, как часто должны анализироваться остальные логи, не вошедшие в перечень требования 10.6.1. Составить перечень таких логов и проверить, что они ведутся и анализируются.



Задача №3: Проверить, что критичные аутентификационные данные не хранятся нигде в информационной инфраструктуре, даже в отсутствии полных номеров карт.

Типовые места: • логи SMS-шлюзов мобильной коммерции; • схемы псевдо-рекуррентных транзакций; • логи PIN-клавиатур в debug-режиме.



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

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



Задача №5: Проверить, что собственные разработчики программного обеспечения проходят обучение по вопросам, как не допускать общеизвестные уязвимости в коде и как безопасно обрабатывать данные в оперативной памяти.



Задача №6: Создать и постоянно поддерживать в актуальном состоянии перечень POS-терминалов с указанием производителя, модели, месторасположения и серийного номера. Задача №7: Организовать периодическую инвентаризацию всех POS-терминалов и проверку, что они не подменены и их конфигурация не претерпела несанкционированных изменений. Задача №8: Организовать регулярное обучение для работников о том, что нельзя подпускать посторонних к POS-терминалам, можно использовать только проверенные терминалы, а также о том, как опознать попытки мошенничества с POS-терминалами и куда о них сообщать.



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



Задача №11: После завершения проекта по переходу организации на PCI DSS 3.0 проверить, что все произведенные изменения в конфигурациях, технологиях и бизнес-процессах учтены во внутренних нормативных документах. Задача №12: Проверить, что все регулярные процедуры, предусмотренные стандартом PCI DSS, корректно отражены во внутренних нормативных документах. Задача №13: Составить и постоянно поддерживать в актуальном состоянии перечень компонентов информационной инфраструктуры.



Задача №14: Довести новые и обновленные внутренние нормативные документы, а также новые знания до сведения сотрудников, создать атмосферу осведомленности о рисках.

17 Что делать в 2014 году?


«Я подтвердил соответствие PCI DSS 2.0 в 2013 году, какую версию мне выбрать в 2014?»

- зависит от... ...сроков выполнения перечисленных задач в вашей организации. Если эта цель достижима до даты очередного подтверждения соответствия – выбирайте версию PCI DSS 3.0, в ином случае – PCI DSS 2.0. Помните: в 2015 году альтернативы не будет!

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


19 Спасибо!


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

Вопросы?

[email protected]

www.pcidsstraining.ru

Technology

PCI DSS как перейти с версии 2.0 на 3.0