SRC Security Research & Consulting GmbH - old.bankit.byold.bankit.by/files/2014/seminars/perspectivy-i-napravleniyarazvitiya...Поставщики ПО, которое обрабатывает

SRC

Security Research &

Consulting GmbH

Особенности

реализации PCI DSS в

банках и ПЦ

Страница 2 © SRC Security Research & Consulting GmbH

Про SRC

Основание: Август 2000,

деятельность с 1.01.2001

Сотрудники: 82

Офисы: Бонн (Главный офис)

Висбаден (филиал)

SRC и PCI

2003: SRC первая компания аудитор для

MasterCard SDP и Visa AIS

2006: QSA статус в PCI SSC

2011: SRC первая (и единственная)

компания, имеющая все PCI SSC статусы

PCI DSS: QSA

PCI PA-DSS: PA-QSA

PCI ASV: Approved Scanning Vendor

PCI PTS: Security Evaluation Lab

PCI PFI: PCI Forensic Investigator

PCI P2PE: QSA (P2P2) und PA-QSA (P2PE)

PCI CP: Card Production

© SRC Security Research & Consulting GmbH Slide 3

Page 4 © SRC Security Research & Consulting GmbH

• Т1: Устанавливать и управлять конфигурацией межсетевых экранов для защиты данных платежных карт

• Т2: Не использовать установленные производителем по умолчанию системные пароли и параметры безопасности

Построение и поддержание защищенной сети

• Т3: Защищать данные платежных карт при хранении

• Т4: Шифровать данные платежных карт, передаваемые по сетям общего доступа

Защита данных платежных карт

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

• Т6: Разрабатывать и поддерживать безопасные системы и приложения

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

4 © SRC Security Research & Consulting GmbH

12 требований PCI DSS


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

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

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

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

• Т10: Отслеживать и мониторить любые доступы к сетевым ресурсам и данным платежных карт

• Т11: Регулярно тестировать системы и процессы обеспечения

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

• Т12: Поддерживать политики по информационной безопасности для сотрудников и контрагентов

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

5 © SRC Security Research & Consulting GmbH

12 требований PCI DSS

Проблемы банков и ПЦ при

подготовке к соответствию PCI DSS

Сеть не сегментирована и соответственно границы аудиты

огромны – это дорого и тяжело

Правила межсетвых экранов плохо настроены. Много

старых или забытых правил.

Данные платежных карты хранятся везде и доступ к ним не

регламентирован – можно легко получить большие

массивы карточных данных и это тяжело будет заметить и

найти виновного

Поставщики ПО, которое обрабатывает карточные данные,

поставляют софт, который плохо помогает

соответствовать стандарту.




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

записи по умолчанию.

Нет шифрования данных при хранении (файлы и таблицы

БД) находятся в открытом виде.

Патчи устанавливаются гораздо позже, чем 30 дней (как

того требует стандарт), либо не устанавливаются совсем.

Разработчики собственного софта имеют мало опыта в

безопасной разработке.

Доступ к данным платежных карт недостаточно

контролируется. Есть групповые или сервисные учетный

записи и т.д.




Существующий аудит и мониторинг действий

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

картам не позволяет однозначно идентифицировать кто и

когда сделал какое либо действие.

Сканирования сети выполняются, но результаты сканов не

удовлетворяют требованиям стандарта.

Процедуры реагирования на инциденты ИБ не работают.

Процедуры, стандарты конфигураций и политики не

задокументированы или не работают.



Стратегии скорейшего достижения

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

Этап 1: Уменьшить границы оценки PCI DSS

Логическое разделение сетевых зон с

данными, которые попадают под PCI DSS от

других зон

Максимальное уменьшение данных, которые

попадают под PCI DSS в БД, логах и т.д.

Установление зон, где маскированные и

хэшированные данные могут использоваться

вместо полных номеров карт




Этап 2: Определение быстрых побед

Реализация быстро выполняемых процессов изменений для

достижения соответствия стандарту и/или уменьшения границ

оценки в короткое время

Этап 3: Защитить данные, которые попадают под PCI DSS

во время хранения и передачи

Проверить все приложения и бизнес транзакции для выявления

отображения данных, которые попадают под PCI DSS

Защищать данных, которые попадают под PCI DSS при

хранении (шифрование)

Защищать данных, которые попадают под PCI DSS при

передаче (шифрование)




Этап 4: Усилить управление безопасностью

Внедрить / Усилить политики безопасности

Определение внутреннего плана

реагирования на инциденты и процедуры

эскалации

Принять PCI DSS в контракты с третьими

сторонами

Уведомить сотрудников

Жизненный цикл PCI DSS

с Октября 2010

PCI DSS 3.0

Применим с

1.1.2014

Обязателен с

1.1.2015

PCI DSS 2.0

Применим до

31.12.2014

Слайд 12 © SRC Security Research & Consulting GmbH

Неприятные изменения для банков

в версии стандарта 3.0

Требование 9

Новое требование 9.9:

Защищайте устройства точек продажи (POS) которые

принимают платежные данные от несанкционированного или

неавторизованного изменения или замены.

– С 1 Июля, 2015

Новые требования 9.9.1-9.9.3:

Поддерживайте в актуальном состоянии список всех

устройств (модель, расположение, серийный номер).

Периодически проверяйте поверхность устройства на

предмет несанкционированного или неавторизованного

изменения или замены.

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

несанкционированное или неавторизованное изменение или

замену устройств. Слайд 13 © SRC Security Research & Consulting GmbH

Неприятные изменения для банков

в версии стандарта 3.0

Требование 9 (продолжение):

Влияние:

Усилие на создание и поддержание списка всех POS -

устройств (сравнимо с требованием 2.4 Реестр всех

компонентов)

Внедрить процесс для регулярного мониторинга

манипуляций устройств (замена, изменение и т.д.) что

требует знаний как это сделать (как обычно манипулируют

устройствами и как обнаружить манипуляции)

Усилия на обучение сотрудников контролю доступа к POS

устройствам.

Слайд 14 © SRC Security Research & Consulting GmbH

ASV сканирования

ASV сканирование – это сканирование внешне доступных IP

адресов, которые используются при передаче данных

платежных карт (Web, почта, туннели с партнерами и т.д.)

Проводится компаниями, которые имеют ASV статус.

Проводится автоматизироваными средствами

Тр. 11.2.2: Проводить ежеквартально внешние

сканирования компанией, которая имеет статус Approved

Scanning Vendor (ASV), утвержденной Советом (PCI SSC).

Тр. 11.2.2.b: Проверить результаты последний четырех

внешних сканирований и убедиться, что они

удовлетворяют требованиям ASV Program Guide (например,

нет уязвимостей выше уровня 4.0 по CVSS и нет

автоматических ошибок). Page 15 © SRC Security Research & Consulting GmbH

Внутренние сканирования

Могут выполняться самостоятельно с помощью ПО Nessus,

nmap, MaxPatrol и т.д.

Сканированию подлежат все хосты в границах аудита

Тр. 11.2.1.a Проверить результаты сканирований и

убедиться, что за последние 12 месяцев было проведено

четыре квартальных сканирования.

Тр. 11.2.1.b Проверить отчеты сканирований и убедиться,

что процесс сканирования включает повторные

сканирования до получения успешных результатов или

пока все определенные как критичные уязвимости в

соответствии с Требованием 6.2 PCI DSS не будут

устранены.


Тест на проникновение

Тест на проникновение – это не автоматическое

сканирование сети!

Нет требований к тестеру по наличию каких либо

сертификатов. Но необходима методология.

Тест должен выполняться на уровне сети (внешний и

внутренний) и на уровне приложений.

Тест на сетевом уровне включает сетевые устройства и ОС.

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

можно эксплуатировать, и повторить тест чтобы это

проверить.

Если для отделение среды данных держателей карт

используется сегментация от других сетей, необходимо

выполнить тест на проникновение для проверки того что

методы сегментации действуют и эффективны.


Подготовка к тесту на проникновение


Соответствие/сертификация


Почему компании имеют сертификат PCI DSS,

но всё равно мы читаем в новостях о их

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

Пройти аудит и получить сертификат не

значит соответствовать стандарту

постоянно!

Нет 100% защиты. Мы живем в реальном

мире и никто/ничто не совершенно.

PCI DSS минимально необходимый

уровень защиты.


Вопросы


SRC

Security Research & Consulting GmbH

Graurheindorfer Str. 149a

53117 Bonn

Тел. +49-(0)228-2806-166

Тел. Киев +38-050-311-58-48

Факс: +49-(0)228-2806-199

E-mail: [email protected]

[email protected]

WWW: www.src-gmbh.de

Контакты

Documents

SRC Security Research & Consulting GmbH - old.bankit.byold.bankit.by/files/2014/seminars/perspectivy-i-napravleniyarazvitiya...Поставщики ПО, которое обрабатывает