Технические аспекты достижения PCI соответствия

Технические аспекты достижения PCI соответствия

Понимание – ключ к решению всех проблем

•Александр Поляков, Digital Security•Руководитель направления аудита ИБ, PCI QSA,PA-QSA

•Руководитель исследовательской лаборатории DSecRG

© 2002—2010, Digital Security

Понимание!

2

• Все непременно сталкиваются с проблемами на пути к

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

• Стараются выполнить требование не задумываясь о ЦЕЛИ

• В итоге:

• появляется множество вопросов о целесообразности

• проблемы с реализацией технических требований

• требования реализуются не безопасно

• появляются уязвимости

• высокая вероятность инцидентов



Понимание - ключ к решению всех проблем

3

• Рассмотрим нюансы требований

• Поймѐм, почему они были созданы, и на что направлены

• К каким рискам приводят невыполнение или неправильное

выполнение

• Как правильно выполнить требования

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

компенсирующие меры



Начнѐм

4

• Следует всегда задумываться для чего создано требование

• Мысли как хакер: подумай как можно нарушить безопасность, если это

требование не выполняется

• Такой подход поможет:

• адекватно удовлетворить требование и обеспечить безопасность

• исключить ошибки в трактовке

• сократить объем работы

• придумать безопасные компенсирующие меры

• Готовы?



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

5

• Протоколировать события необходимо!

• Существует ряд требований, конкретизирующих как это делать

• Основная цель ведения журналов протоколирования:

• понимание того КТО, КОГДА и К ЧЕМУ получил доступ

• Кроме того:

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

невозможно подделать

• ЗАЧЕМ?

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

• Для расследования инцидентов



Протоколирование событий 10.2. Зачем?

6

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

Не обсуждается

• 10.2.2 Любые действия, совершенные с использованием

административных полномочий.

DEBUG функции

• 10.2.3 Любой доступ к записям о событиях в системе.

Для предотвращения возможной модификации

• 10.2.4 Неуспешные попытки логического доступа.

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

• 10.2.5 Использование механизмов идентификации и аутентификации.

Кто и Откуда зашѐл

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

Чтобы нельзя было незаметно отключить (exploit)

• 10.2.7 Создание и удаление объектов системного уровня.

Для предотвращения возможной модификации




7

10.3 Для каждого события каждого системного компонента должны быть

записаны как минимум следующие параметры:

• 10.3.1 Идентификатор пользователя.

• 10.3.2 Тип события.

• 10.3.3 Дата и время.

• 10.3.4 Успешным или неуспешным было событие.

• 10.3.5 Источник события.

• 10.3.6 Идентификатор или название данных, системного

компонента или ресурса, на которые повлияло событие.


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

нарушения, что необходимо в случае расследования инцидентов


Ха ха, а я не буду и что тогда ?

8

• В результате расследования инцидентов, по мимо всего прочего, важным

фактором в стоимости ущерба будет считаться количество

скомпрометированных записей, так как штрафы выплачиваются в

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

• Если невозможно подтвердить количество скомпрометированных записей, то

считается, что были скомпрометированы ВСЕ записи

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

интересах

SANS Institute 2009 – ―PCI DSS and Incident Handling: What is required before, during and after an incident‖http://www.sans.org/reading_room/whitepapers/compliance/pci_dss_and_incident_handling_what_is_required_before_during_and_after_an_incident_33119


Необходимо чѐтко понимать на что направлено требование, это в

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

http://www.sans.org/reading_room/whitepapers/compliance/pci_dss_and_incident_handling_what_is_required_before_during_and_after_an_incident_33119




Протоколирование событий 10.5. Зачем? И как?

9


• Журналы протоколирования событий должны быть защищены

от изменений.

• Ряд подпунктов конкретизирующих требование.

• Смысл ясен – предотвратить неавторизированные изменения

• Техническая реализация не очевидна

Пример. Требование 10.5.5: Следует использовать приложения контроля

целостности файлов для защиты журналов регистрации событий от

несанкционированных изменений (однако добавление новых данных не должно вызывать

тревожного сигнала).

Одно из возможных решений - WORM devices. (Write Once Read Many)

Tape-based WORM: the best choice for HIPAA-compliant storage

http://findarticles.com/p/articles/mi_m0BRZ/is_1_25/ai_n13783558/

http://findarticles.com/p/articles/mi_m0BRZ/is_1_25/ai_n13783558/



10

Требование 10.7 Журналы регистрации событий должны храниться не

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

трех месяцев

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

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

совершаемой атаки.

• Информация для определения длительности и потенциального ущерба,

нанесенного системе (или системам).

• Множество инцидентов, раскрытых в 2008 году были начаты в 2007 и

ранне



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

11


Самые распространенные вопросы:

• ―Зачем протоколировать доступ и в приложении и в СУБД и в ОС ?‖

• ―Надо ли протоколировать все действия во всех системах?

• ―Как нам разобраться в этой горе ненужных записей?‖

Необходимо при любых возможных векторах атаки уметь отследить

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

журналов протоколирования.

Информация от МПС Visa:

Each and every log does not necessarily have to log all the data as specified in the details under 10.2 and 10.3, as

long as the specified log items and events can be easily gathered in the event of a compromise from the various

logs and/or logging tools in use.

Источник:http://usa.visa.com/download/merchants/pci_clarification_assessors.pdf

http://usa.visa.com/download/merchants/pci_clarification_assessors.pdf


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

12


Правильный случай


Протоколирование событий. Неправильный случай

13


Неправильный случай


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

14


Возможно только если

пользователи приложения

являются Пользователями

СУБД и происходит

сквозная аутентификация, а

также при соблюдении ряда

других требований.

Возможный случай


Протоколирование событий. Как? (организационно)

15

• Не обязательно протоколировать весь доступ во всех приложениях

• Необходимо чѐтко понимать возможные пути атаки для того чтобы

адекватно настроить протоколирование событий

• Уметь обосновать это своему QSA

• В противном случае лучше протоколировать ВСЁ

• Или обратиться к специалистам

В итоге:

• Существенно сократится объѐм работы по анализу журналов и занятое

место на диске


Необходимо чѐтко понимать, на что направлено требование, это

поможет сократить затраты ресурсов


Протоколирование событий. Как? (технически)

16

• Наиболее простой способ - использовать проверенные решения,

например Oracle FGA:

• возможна реализация всех перечисленных требований

• Множество примеров в Интернете

• возможно отслеживать к чьим конкретно карточным данным был

получен доступ

• Альтернатива – системные триггеры.



Пример 2. Вариант применения шифрования

17


http://superconductor.voltage.com/2010/11/its-possible-to-comply-with-the-pci-dss-yet-provide-essentially-

no-protection-to-credit-card-numbers-heres-why--secti.html

• Есть одно или несколько приложений, которое хранит PAN в СУБД.

• Согласно требованию 3.3 - в одной из таблиц находятся маскированные

PAN (только первые 6 и последние 4 символа).

• Следуя требованию 3.4 в другой таблице PAN хранится в виде хеш –

значения (используется sha1).

Compliant or not?

http://superconductor.voltage.com/2009/11/its-possible-to-comply-with-the-pci-dss-yet-provide-essentially-no-protection-to-credit-card-numbers-heres-why--secti.html









































Вариант применения шифрования. Где ошибка?

18


• Злоумышленник, получивший доступ к СУБД, знает

маскированный PAN, вида:

1234 56XX XXXX 3456

• Злоумышленник знает хеш-значение этого PAN:

0xdeed2a88e73dccaa30a9e6e296f62be238be4ade

• Злоумышленнику необходимо сгенерировать 1000000 возможных

хешей, сравнить их с искомым, и получить в итоге верный PAN.

• На среднем компьютере перебор занимает 2 секунды.

Основная цель требования - предотвратить получение

злоумышленником PAN – не выполнена. Хотя формально всѐ ОК!

Необходимо чѐтко понимать, на что направлено требование, слепое

соответствие не всегда означает безопасность


Пример 3. Парольные политики

19

Дано:

• Есть старое приложение которое не имеет ―тонких настроек‖ парольной

политики, таких как, к примеру, использование спецсимволов и цифр.

• 8.5.11: требование использования в пароле как цифр, так и букв.

Смысл:

• Требование направлено на уменьшение вероятности подбора пароля

при получении хеша.

• С точки зрения взломщика имеет значение только количество

возможных комбинаций пароля.

• Количество комбинаций зависит от длины (можем на это влиять) и

алфавита (не можем на это влиять).



Пароли. Решение

20

• Количество возможных комбинаций учитывая требования 8.5.11

(Цифры) и 8.5.10 (7 символов) составляет:

(26+10)^7 = 78 364 164 096

• Сконфигурировав рассматриваемое нами приложение на

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

возможных комбинаций:

(26)^8 = 208 827 064 576

• Количество возможных комбинаций больше => безопасность даже

выше.

Основная цель требований - уменьшить вероятность подбора пароля -

выполнена!


Необходимо чѐтко понимать, на что направлено требование, это

иногда позволит найти выход из “безвыходной” ситуации


Пример 4. Виртуализация

21


• Как применяются требования PCI DSS к виртуальным машинам?

• Если Сервер виртуальных машин (HOST) входит в область аудита,

входят ли в область аудита гостевые операционные системы (GUEST)?

• Если гостевая машина (GUEST) входит в область аудита, входят ли в

область аудита:

• сервер виртуальных машин (HOST)?

• другие гостевые машины?


Виртуализация

22



Виртуализация

23


Необходимо чѐтко понимать, на что направлено требование. Это

исключит небезопасные настройки

• Как применяются требования PCI DSS к виртуальным машинам?

Также, как и к физическим

• Если Сервер(хост виртуальных машин) входит в область аудита

входят ли в область аудита гостевые операционные системы?

Да, так как есть практические реализации атак

• Если гостевая машина (GUEST) входит в область аудита входят

ли в область аудита:

• сервер виртуальных машин (HOST) - ДА

• другие гостевые машины? – зависит от настроек


Виртуализация. Как исключить из области аудита

24


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

виртуальной инфраструктуры

• Убедиться, что виртуальные сервера изолированы друг от друга

на сетевом и физическом (SAN) уровне

• Убедиться что в наличии есть формальные документированные

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

Подробности: http://pciguru.wordpress.com/2009/06/27/server-virtualization-and-pci/

http://pciguru.wordpress.com/2009/06/27/server-virtualization-and-pci/







32


Преимущества

• сократит возможные финансовые потери

• поможет сократить затрату ресурсов

• позволит найти выход из ―безвыходной‖ ситуации

• поможет избежать небезопасной настройки

• слепое соответствие не всегда означает безопасность


Понимать самим или обращаться к специалистам – решать вам

25

32

• Официальные документы

http://pcidss.ru/files/pub/pdf/pcidss_v1.2_english.pdf

https://www.pcisecuritystandards.org/pdfs/pci_dss_saq_navigating_dss.pdf

• Дополнительная информация

http://pcidss.ru/compliance/

https://www.pcisecuritystandards.org/

http://pcianswers.com/

http://forum.paymentsecuritypros.com/


Где искать ответы на вопросы?

© 2002—2010, Digital Security 26

http://pcidss.ru/files/pub/pdf/pcidss_v1.2_english.pdf

https://www.pcisecuritystandards.org/pdfs/pci_dss_saq_navigating_dss.pdf

http://pcidss.ru/compliance/

https://www.pcisecuritystandards.org/

http://pcianswers.com/

http://forum.paymentsecuritypros.com/


ВОПРОСЫ

27

www.dsec.ru

www.pcidss.ru


Technology

Технические аспекты достижения PCI соответствия