Contenu connexe
Similaire à PCI DSS 3.0: к чему готовиться?
Similaire à PCI DSS 3.0: к чему готовиться? (20)
PCI DSS 3.0: к чему готовиться?
- 2. ©
2002—2014
Digital
Security
Главные
новости
PCI
DSS
3.0:
к
чему
готовиться?
• Опубликован
официальный
перевод
стандарта
• Опубликованы
сопровождающие
документы
• Выпущен
шаблон
ROC
для
PCI
DSS
3.0
• Добавили
новые
типы
SAQ
2
- 3. ©
2002—2014
Digital
Security
Изменения
в
новой
версии
PCI
DSS
PCI
DSS
3.0:
к
чему
готовиться?
3
Business
as
Usual
Расширенные
проверочные
процедуры
Новая
колонка
«Пояснения»
Внимание
на
безопасности,
а
не
на
соответствии
Способствует
полноте
оценки
Пояснения
включены
в
руководство
1
3
2
- 4. ©
2002—2014
Digital
Security
Изменения
в
новой
версии
PCI
DSS:
Business-‐as-‐usual
PCI
DSS
3.0:
к
чему
готовиться?
4
Мониторинг
Проверка
корректной
работы
средств
защиты:
МЭ,
IDS/IPS,
антивируса,
системы
контроля
целостности,
средств
разграничения
доступа.
Реагирование
на
отказы
работы
средств
защиты
• восстановление
механизма
обеспечения
безопасности;
• определение
причины
отказа;
• определение
и
решение
любых
проблем
с
безопасностью,
возникших
во
время
отказа
механизма
обеспечения
безопасности;
• внедрение
нового
средства
безопасности
(например,
процесса
или
технического
механизма)
во
избежание
повторного
возникновения
причины
отказа;
• возобновление
мониторинга
механизма
безопасности,
желательно
с
временным
его
усилением
для
проверки
эффективности
работы
механизма.
Изменение
инфраструктуры
Контроль
за
изменением
инфраструктуры,
способной
повлиять
на
область
действия
PCI
DSS
–
добавление
новой
системы
(накатывание
стандарта
конф.),
вывод
из
эксплуатации,
обновление
документов/перечней.
Своевременное
применение
стандартов
конфигурации,
обновление
реестров,
области
действия.
Изменение
организации
Формальное
ревью
области
действия
Стандарта
и
приминимости
требований
вследствие
изменении
организационной
структуры.
Периодический
контроль
Проведение
оценки
соответствия
с
целью
подтверждения
того,
что
требования
PCI
DSS
выполняются,
а
сотрудники
следуют
процессам
обеспечения
безопасности.
Технологический
контроль
Контроль
статуса
поддержки
ПО
и
железа.
Своевременная
замена/миграция
на
более
современнные
средства.
- 5. ©
2002—2014
Digital
Security
Изменения
в
новой
версии
PCI
DSS:
Разделение
ответственности
PCI
DSS
3.0:
к
чему
готовиться?
Стороны
должны
четко
определить:
• какие
требования
предъявляются
к
поставщику
услуг?
• какие
службы
и
системные
компоненты
входят
в
область
проверки
поставщика
услуг
на
соответствие
требованиям
PCI
DSS?
• какие
требования
предъявляются
к
клиенту
поставщика
услуг?
5
- 6. ©
2002—2014
Digital
Security
Изменения
в
новой
версии
PCI
DSS:
Разделение
ответственности
PCI
DSS
3.0:
к
чему
готовиться?
Поставщик
услуг
(третья
сторона)
может
подтвердить
соответствие
требованиям
двумя
способами:
1. Самостоятельно
пройти
оценку
соответствия
PCI
DSS
и
представить
доказательство
соответствия
своим
клиентам
(АОС,
отредактированный
ROC).
2. Не
проводить
собственную
оценку
соответствия
PCI
DSS
и
предоставить
возможность
оценки
своих
услуг
в
ходе
проверки
соответствия
каждого
из
своих
клиентов.
6
- 7. ©
2002—2014
Digital
Security
Изменения
в
новой
версии
PCI
DSS:
Хранение
критичных
данных
PCI
DSS
3.0:
к
чему
готовиться?
Запрещается
хранить
критичные
аутентификационные
данные
после
авторизации,
даже
в
зашифрованном
виде.
Данное
требование
действует,
даже
если
PAN
отсутствует
в
среде.
Организации
должны
напрямую
связаться
со
своими
эквайерами
или
отделениями,
отвечающими
за
отдельные
торговые
марки,
чтобы
узнать,
разрешается
ли
хранить
критичные
аутентификационные
данные
до
авторизации
и
в
течение
какого
срока,
а
также
получить
информацию
о
других
требованиях
к
использованию
и
защите
данных.
Стандарт
PCI
DSS
3.0,
стр.8
7
- 8. ©
2002—2014
Digital
Security
Изменения
в
новой
версии
PCI
DSS:
Изменение
в
таблице
требований
PCI
DSS
3.0:
к
чему
готовиться?
8
«Понимание
назначения
требований»
«PCI
DSS
2.0
Требования
и
процедуры
аудита
безопасности»
«PCI
DSS
3.0
Требования
и
процедуры
аудита
безопасности»
- 9. ©
2002—2014
Digital
Security
Новые
типы
SAQ
PCI
DSS
3.0:
к
чему
готовиться?
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. ©
2002—2014
Digital
Security
Новые
типы
SAQ
PCI
DSS
3.0:
к
чему
готовиться?
10
SAQ
A-‐EP
Предназначен
для
мерчантов,
которые:
• выполняют
прием
платежей
только
посредством
e-‐commerce
транзакций;
• всю
обработку
ДДК
предоставляют
на
аутсорсинг
сторонней
компании,
которая
является
платежным
процессором
и
соответствует
PCI
DSS;
• не
принимают
платежи
на
своем
сайте,
но
обеспечивают
перенаправление
клиентов
на
страницу
оплаты
сторонней
компании,
соответствующей
PCI
DSS;
• веб-‐сайт
не
подключен
к
иным
системам
ИТ-‐инфраструктуры
(например,
веб-‐сервер
выделен
в
отдельный
сегмент);
• размещают
свой
веб-‐сайт
на
серверах
хостинга,
который
соответствует
всем
необходимым
требованиям
PCI
DSS
в
части
касающейся
поставщиков
услуг
хостинга
(в
т.ч.
требованиям
приложения
А
Стандарта);
• все
элементы
платежной
страницы
веб-‐сайта,
предоставляют
клиенту
со
своего
сайта
или
платежного
процессора,
соответствующего
PCI
DSS;
• не
хранят,
не
обрабатывают
и
не
передают
ДДК
в
электронном
виде
и
передают
все
эти
функции
по
обработке
ДДК
сторонней
организации;
• подтверждают,
что
вся
обработка
ДДК
происходит
на
стороне
сторонней
компании,
которая
соответствует
PCI
DSS;
• сохраняют
только
бумажные
отчеты
или
бумажные
копии
квитанций
с
данными
о
держателях
карт,
и
эти
документы
не
хранятся
в
электронном
виде.
- 11. ©
2002—2014
Digital
Security
Новые
типы
SAQ
PCI
DSS
3.0:
к
чему
готовиться?
11
SAQ
B-‐IP
Предназначен
для
мерчантов,
которые:
• используют
только
отдельностоящие
POI
(точки
взаимодействия
–
считыватели
карт
в
т.ч.
SCR)
сертифицированные
по
PCI
PTS
подключенные
по
IP
к
платежному
шлюзу;
• используют
отдельностоящие
POI
сертифицированные
по
PTS
POI
и
указанные
на
сайте
Совета
(за
исключением
SCR);
• используют
отдельностоящие
POI
не
подключенные
к
инфраструктуре
мерчанта
или
изолированные
(например,
выделенные
в
отдельный
сегмент)
• производят
только
один
тип
транзакций
–
от
сертифицированного
по
PCI
PTS
POI
к
платежному
шлюзу;
• используют
POI
не
подключенный
ни
к
одному
другому
устройству
(в
т.ч.
ПК,
мобильный
телефон,
планшет)
для
взаимодействия
с
платежным
шлюзом;
• сохраняют
только
бумажные
отчеты
или
бумажные
копии
квитанций
с
данными
о
держателях
карт,
и
эти
документы
не
хранятся
в
электронном
виде;
• не
хранят
ДДК
в
электронном
виде.
- 13. ©
2002—2014
Digital
Security
Требование
1
PCI
DSS
3.0:
к
чему
готовиться?
13
1.1.3
Актуальная
схема,
отображающая
потоки
данных
держателей
карт
во
всех
системах
и
сетях
- 14. ©
2002—2014
Digital
Security
Требование
1.1.3
PCI
DSS
3.0:
к
чему
готовиться?
14
Процесс
приема
платежей
с
веб-‐страниц
клиентов
- 15. ©
2002—2014
Digital
Security
Требование
1.1.3
PCI
DSS
3.0:
к
чему
готовиться?
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. ©
2002—2014
Digital
Security
Требование
2
PCI
DSS
3.0:
к
чему
готовиться?
16
• Теперь
необходимо
идентифицировать
все
системные
компоненты.
• На
основании
перечня
системных
компонентов
и
диаграммы
потоков
данных
определяется
как
полнота
области
оценки,
так
и
эффективность
сегментации.
• Без
журнала
учета
есть
риск
того,
что
некоторые
системные
компоненты
будут
забыты
или
случайно
исключены
из
конфигурационных
стандартов
организации.
2.4
Вести
учет
системных
компонентов,
на
которые
распространяется
действие
стандарта
PCI
DSS.
- 17. ©
2002—2014
Digital
Security
Требование
3
PCI
DSS
3.0:
к
чему
готовиться?
17
Ничего
нового.
Более
подробно
расписаны
требования
к
управлению
ключами,
документированию
процедур.
- 18. ©
2002—2014
Digital
Security
Требование
4
PCI
DSS
3.0:
к
чему
готовиться?
18
Ничего
нового.
Расширили
перечень
общедоступных
сетей.
Теперь
это:
• Интернет;
• беспроводные
технологии,
включая
протоколы
802.11
и
Bluetooth;
• технологии
сотовой
связи,
например
GSM,
CDMA;
• GPRS;
• спутниковые
средства
связи.
- 19. ©
2002—2014
Digital
Security
Требование
5
PCI
DSS
3.0:
к
чему
готовиться?
19
• Раньше
нужно
было
защищать
только
«подверженные
вирусным
атакам»
системы.
• Теперь
необходимо
периодически
оценивать
риски
заражения
всех
используемых
операционных
систем.
5.1.2
Проводить
периодические
проверки
для
выявления
и
оценки
рисков
заражения
вредоносным
ПО
на
системах,
которые
считаются
не
подверженными
заражению
вредоносным
ПО,
с
целью
подтверждения
отсутствия
необходимости
в
антивирусном
ПО.
- 20. 5.3
Необходимо
убедиться,
что
антивирусные
программы
работают
в
активном
режиме
и
не
могут
быть
отключены
или
изменены
пользователями
без
явного
разрешения
руководства
на
индивидуальной
основе
и
на
ограниченный
период
времени.
©
2002—2014
Digital
Security
Требование
5
PCI
DSS
3.0:
к
чему
готовиться?
20
• Отключение
или
изменение
настроек
антивируса
только
после
согласования
с
руководством.
- 21. 6.3
Разработать
безопасные
внутренние
и
внешние
приложения
(включая
административный
доступ
к
приложениям
через
веб-‐интерфейс)
с
соблюдением
следующих
требований:
• согласно
требованиям
PCI
DSS
(например,
в
отношении
безопасной
аутентификации
и
ведения
журнала);
• процесс
разработки
программного
обеспечения
должен
быть
основан
на
отраслевых
стандартах
и
(или)
известных
рекомендациях;
• информационная
безопасность
должна
учитываться
в
течение
всего
цикла
разработки
ПО.
Примечание.
Требование
относится
к
любому
ПО
собственной
разработки
и
заказному
ПО,
разработанному
третьим
лицом.
©
2002—2014
Digital
Security
Требование
6
PCI
DSS
3.0:
к
чему
готовиться?
21
Разделение
ответственности
между
заказчиком
и
вендором.
- 22. • Добавлена
новая
уязвимость
программного
кода
©
2002—2014
Digital
Security
Требование
6
PCI
DSS
3.0:
к
чему
готовиться?
22
6.5.10
Противодействие
взлому
механизмов
аутентификации
и
управления
сеансами.
- 23. ©
2002—2014
Digital
Security
Требование
7
PCI
DSS
3.0:
к
чему
готовиться?
23
• Необходимо
внедрить,
реализовать
и
поддерживать
процесс
Разделения
полномочий
(Separašon/Segregašon
of
Dušes,
SoD)
7.1.1
Определение
прав
доступа
для
каждой
должности,
включая:
• системные
компоненты
и
ресурсы
данных,
доступ
к
которым
необходим
для
каждой
должности
для
выполнения
должностных
обязанностей;
• необходимый
уровень
привилегий
(например,
пользователь,
администратор
и
т.д.)
для
доступа
к
ресурсам.
- 24. ©
2002—2014
Digital
Security
Требование
8
PCI
DSS
3.0:
к
чему
готовиться?
24
8.2
Помимо
назначения
уникального
идентификатора,
для
обеспечения
надлежащего
управления
аутентификацией
сотрудников
(не
пользователей)
и
администраторов
на
уровне
всех
системных
компонентов
должен
применяться
хотя
бы
один
из
следующих
методов
аутентификации
всех
пользователей:
• то,
что
вы
знаете
(например,
пароль
или
парольная
фраза);
• то,
что
у
вас
есть
(например,
ключи
или
смарт-‐карты);
• то,
чем
вы
обладаете
(например,
биометрические
параметры).
8.2.3
Пароли/парольные
фразы
должны
соответствовать
следующим
требованиям:
• наличие
в
пароле
не
менее
семи
символов;
• наличие
в
пароле
и
цифр,
и
букв;
• как
вариант,
пароли/парольные
фразы
должны
иметь
сложность
и
стойкость,
сравнимые
с
указанными
выше
параметрами.
- 25. ©
2002—2014
Digital
Security
Требование
8
PCI
DSS
3.0:
к
чему
готовиться?
25
• Уход
от
направленности
на
пароли,
как
на
основное
средство
аутентификации.
• Ввод
понятия
парольной
фразы.
• Инструкции
для
пользователей
по
каждому
методу
аутентификации.
- 26. ©
2002—2014
Digital
Security
Требование
8
PCI
DSS
3.0:
к
чему
готовиться?
26
Вопрос:
Как
определить
требования
к
парольной
фразе?
Ответ:
Энтропия
парольной
фразы
должна
быть
равна
энтропии
произвольного
пароля
из
7-‐ми
символов
(буквы
в
разных
регистрах,
цифры,
спец.символы).
- 27. ©
2002—2014
Digital
Security
Требование
8
PCI
DSS
3.0:
к
чему
готовиться?
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. ©
2002—2014
Digital
Security
Требование
8
PCI
DSS
3.0:
к
чему
готовиться?
28
Вопрос:
Так
какие
будут
требования
к
парольной
фразе?
Ответ:
Минимум
30
букв
нижнего
регистра.
Для
большей
стойкости
можно
добавить
обязательное
наличие
букв
в
разном
регистре
И
спец.символов.
- 29. ©
2002—2014
Digital
Security
Требование
8
PCI
DSS
3.0:
к
чему
готовиться?
29
• Даны
рекомендации
по
использованию
иных
механизмов
аутентификации
8.6
В
случае
использования
других
механизмов
аутентификации
(например,
физических
или
логических
токенов
безопасности,
смарт-‐карт,
сертификатов
и
т.д.),
эти
механизмы
должны
назначаться
следующим
образом:
• механизмы
аутентификации
должны
назначаться
для
каждой
учетной
записи
в
отдельности,
а
не
для
нескольких
учетных
записей
сразу;
• необходимо
использовать
физические
и
(или)
логические
механизмы
контроля,
чтобы
только
авторизованный
пользователь
мог
использовать
такие
механизмы
для
получения
доступа.
- 30. ©
2002—2014
Digital
Security
Требование
9
PCI
DSS
3.0:
к
чему
готовиться?
30
• Бейджи
больше
не
обязательное
требование.
• Достаточно
эффективного
метода
отличия
сотрудников
от
посетителей.
9.2
Разработать
процедуры,
позволяющие
легко
различать
персонал
организации
и
посетителей
и
включающие:
• идентификацию
новых
сотрудников
или
посетителей
(например,
путем
выдачи
бейджей);
• внесение
изменений
в
права
доступа;
• процедуры
отзыва
или
отключения
средств
идентификации
уволенного
сотрудника
или
средств
идентификации
посетителей
с
истекшим
сроком
действия
(например,
бейджей).
- 31. ©
2002—2014
Digital
Security
Требование
9
PCI
DSS
3.0:
к
чему
готовиться?
31
• Физический
доступ
должен
администрироваться.
9.3
Контролировать
физический
доступ
сотрудников
к
критичным
помещениям
следующим
образом:
• права
доступа
сотрудников
должны
быть
утверждены
на
основании
классификации
должностей
и
их
должностных
обязанностей;
• доступ
должен
быть
отозван
сразу
после
его
прекращения
и
все
механизмы
физического
доступа
(например,
ключи,
карты
доступа
и
т.д.)
должны
быть
возвращены
или
отключены.
- 32. ©
2002—2014
Digital
Security
Требование
9
PCI
DSS
3.0:
к
чему
готовиться?
32
• Контроль
и
учет
устройств
считывания
карт
(вступит
в
силу
с
1
июля
2015
г.):
POS,
ATM,
кард-‐ридеры
для
доступа
в
помещения
с
банкоматами
и
т.д.
• Обучение
сотрудников
методам
распознавания
взлома
и
подмены
устройств.
Разработка
обучающих
материалов.
Перечень
тем
обучения
приведен
в
требовании
9.9.3.
9.9
Обеспечить
защиту
устройств,
считывающих
данные
с
платежных
карт
путем
прямого
физического
взаимодействия
с
картой,
от
подделки
и
подмены.
- 33. ©
2002—2014
Digital
Security
Требование
10
PCI
DSS
3.0:
к
чему
готовиться?
33
Дополнительные
события
для
регистрации:
• факты
любого
вида
доступа
каждого
пользователя
к
ДДК;
• использование
механизмов
идентификации,
расширение
полномочий,
изменения
учетных
записей
с
правами
суперпользователя
и
администратора;
• инициализации
журналов,
остановка
или
приостановка
ведения
журналов.
10.2.1
Любой
доступ
пользователя
к
данным
держателей
карт.
10.2.5
Использование
и
изменение
механизмов
идентификации
и
аутентификации,
включая,
помимо
прочего,
создание
новых
учетных
записей,
расширение
привилегий,
а
также
все
изменения,
добавления,
удаления
учетных
записей
с
правами
суперпользователя
("root")
или
администратора.
10.2.6
Инициализация,
остановка
или
приостановка
ведения
журналов
протоколирования
событий.
- 34. ©
2002—2014
Digital
Security
Требование
10
PCI
DSS
3.0:
к
чему
готовиться?
34
• Обязательная
ежедневная
проверка
журналов
событий
систем
безопасности
и
критичных
систем.
• Периодическая
проверка
журналов
событий
менее
критичных
систем.
• Теперь
так
же
надо
изучать
аномалии,
обнаруженные
во
время
проверки
(требование
10.6.3).
10.6.2
Периодически
изучать
журналы
других
системных
компонентов
на
основании
политик
и
стратегии
управления
рисками,
определяемой
в
рамках
ежегодной
оценки
рисков.
- 35. ©
2002—2014
Digital
Security
Требование
11
PCI
DSS
3.0:
к
чему
готовиться?
35
• Необходимо
вести
реестр
используемых
беспроводных
устройств
с
указанием
их
назначения.
• Актуально
для
ретейла.
11.1.1
Вести
список
авторизованных
беспроводных
точек
доступа
с
указанием
их
необходимости
для
ведения
дел.
- 36. ©
2002—2014
Digital
Security
Требование
11
PCI
DSS
3.0:
к
чему
готовиться?
36
Необходима
полноценная
методика:
• методика
должна
включать
тестирование
на
наличие
механизмов
сегментации
и
уменьшения
области
действия
Стандарта;
• описывает
анализ
не
только
операционных
систем,
но
и
всех
остальных
компонентов,
поддерживающих
взаимодействие
на
сетевом
уровне;
• регламентирует
хранение
результатов
тестов;
• обязательна
с
30
июня
2015
г.
11.3
Внедрить
методологию
проведения
тестирования
на
проникновение.
- 37. ©
2002—2014
Digital
Security
Требование
11
PCI
DSS
3.0:
к
чему
готовиться?
37
• Тест
на
проникновение,
кроме
остальных
задач,
должен
проверять
эффективность
сегментации.
• Надо
проверять
корректность
изолирования
систем
входящих
в
скоуп,
от
систем
не
входящих
в
скоуп.
11.3.4
В
случае
использования
сегментации
для
изолирования
информационной
среды
держателей
карт
от
других
сетей
необходимо
проводить
тестирование
на
возможность
проникновения
не
реже
одного
раза
в
год
и
после
любого
изменения
механизмов/методов
сегментации
для
проверки
функционирования
и
эффективности
методов
сегментации
и
изолирования
всех
непроверенных
систем
от
проверенных.
- 38. ©
2002—2014
Digital
Security
Требование
11
PCI
DSS
3.0:
к
чему
готовиться?
38
• Термин
«мониторинг
целостности
файлов»
заменен
на
«механизм
обнаружения
изменений»,
то
есть
суть
–
в
фиксации
любых
изменений
в
инфраструктуре.
• Новое
требование
11.5.1.
Надо
реагировать
на
любые
срабатывания
этого
механизма.
Надо
фиксировать
все
изменения
в
инфраструктуре
и
на
каждое
реагировать.
11.5
Следует
внедрить
механизм
защиты
от
изменений
(например,
мониторинг
целостности
файлов)
для
оповещения
персонала
о
несанкционированных
изменениях
критичных
системных
файлов,
конфигурационных
файлов
и
файлов
данных;
сопоставительный
анализ
критичных
файлов
должен
проводиться
не
реже
одного
раза
в
неделю.
- 39. ©
2002—2014
Digital
Security
Требование
12
PCI
DSS
3.0:
к
чему
готовиться?
39
• Цель
требования
–
обеспечить
понимание
организацией
требований
PCI
DSS,
которые
согласились
выполнять
поставщики.
• Поставщики
услуг
должны
давать
клиентам
письменное
согласие
с
тем,
что
они
ответственны
за
безопасность
передаваемых
им
на
обработку
ДДК
(с
июля
2015
г.)
(требование
12.9).
12.8.5
Хранить
информацию
о
том,
за
какие
требования
стандарта
PCI
DSS
несет
ответственность
каждый
поставщик
услуг,
а
за
какие
несет
ответственность
сама
организация.
- 41. ©
2002—2014
Digital
Security
FAQ
PCI
DSS
3.0:
к
чему
готовиться?
41
А
что,
если
мы
не
хотим
мигрировать?
Тогда:
• не
сможете
обновить
EMV-‐ядро;
• не
сможете
использовать
PA-‐DSS
софт;
• возникнут
проблемы
с
поддержанием
соответствия
требованиям
PCI
DSS;
• не
сможете
использовать
новый
дополнительный
функционал
для
АТМ
в
будущем.
- 42. ©
2002—2014
Digital
Security
FAQ
PCI
DSS
3.0:
к
чему
готовиться?
42
Microso¢
Custom
Support
Agreement
(CSA)
или
компенсационные
меры
- 43. ©
2002—2014
Digital
Security
FAQ
PCI
DSS
3.0:
к
чему
готовиться?
43
CSA:
• организация
должна
обладать
статусом
Microso¢
Premier
Customer;
• при
наличии
статуса,
должна
платить
минимум
$200,000
в
год
за
CSA;
• каждый
год
взнос
будет
расти;
• будет
действовать
только
2
года.
- 44. ©
2002—2014
Digital
Security
FAQ
PCI
DSS
3.0:
к
чему
готовиться?
44
Компенсационные
меры:
• мониторинг
специализированных
рассылок
и
иных
источников
информации
на
предмет
наличия
сведений
об
уязвимостях
для
EoL
ОС;
• своевременное
обновление
антивирусных
баз;
• своевременное
обновление
сигнатур
IDS/IPS,
для
обнаружения
новых
видов
атак
на
устаревшую
ОС;
• более
частый
контроль
целостности;
• мониторинг
журналов
событий
и
выявление
подозрительных
событий;
• размещение
систем
(серверы,
АРМ,
банкоматы)
на
которых
установлена
устаревшая
ОС
в
выделеном
сегменте
сети;
• белые
списки
ПО;
• удаление
неиспользуемого/лишнего
ПО
и
компонентов;
• отключение
всех
портов
(USB,
COM).
- 45. ©
2002—2014
Digital
Security
FAQ
PCI
DSS
3.0:
к
чему
готовиться?
45
Примеры
миграции:
• Scošabank
• Сеть
из
2500
банкоматов
• Удаленная
миграция
с
XP
на
7
• €120
за
банкомат
- 46. ©
2002—2014
Digital
Security
FAQ
PCI
DSS
3.0:
к
чему
готовиться?
46
Очевидное-‐невероятное:
• 0day
Remote
Code
Execušon
CVE-‐2014-‐1776
Vulnerability
in
Internet
Explorer
Could
Allow
Remote
Code
Execuvon
Published:
April
26,
2014
- 47. ©
2002—2014
Digital
Security
FAQ
PCI
DSS
3.0:
к
чему
готовиться?
47
Мораль:
Чем
дольше
ждете,
тем
больше
потратите
- 48. ©
2002—2014
Digital
Security
Примеры
схем
и
таблиц
PCI
DSS
3.0:
к
чему
готовиться?
48
В
случае
вопросов
или
предложений
по
улучшению
схем
и
таблиц
пишите:
a.gaiko@dsec.ru
Примеры
схем
в
формате
Visio
h•p://goo.gl/D9OYPr
Описание
требований
к
схемам
h•p://goo.gl/q57qYf
Перечни
сведений
об
инфраструктуре
h•p://goo.gl/PDwGBY
- 49. ©
2002—2014
Digital
Security
Полезные
ссылки
PCI
DSS
3.0:
к
чему
готовиться?
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.
Спасибо
за
внимание!
©
2002—2014
Digital
Security
Спасибо
за
внимание!
PCI
DSS
3.0:
к
чему
готовиться?
50
Андрей
Гайко
QSA-‐аудитор
a.gaiko@dsec.ru