PCI DSS 3.0: к чему готовиться?
0 likes1,342 views
Документ описывает обновления и требования нового стандарта PCI DSS 3.0, включая акцент на безопасность, мониторинг и разделение ответственности между поставщиками услуг и клиентами. В стандарте введены новые типы самооценок (SAQ) и уточнены правила хранения критических данных. Основное внимание уделяется важности соблюдения стандартов конфигурации и процедуры оценки соответствия для обеспечения безопасности данных держателей карт.
PCI DSS 3.0: к чему готовиться?
- 1. Журналы регистрации событий PCI DSS 3.0: к чему готовиться? Андрей Гайко QSA-‐аудитор © 2002—2014 , Digital Security
- 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 не подключенный ни к одному другому устройству (в т.ч. ПК, мобильный телефон, планшет) для взаимодействия с платежным шлюзом; • сохраняют только бумажные отчеты или бумажные копии квитанций с данными о держателях карт, и эти документы не хранятся в электронном виде; • не хранят ДДК в электронном виде.
- 12. © 2002—2014 Digital Security 12
- 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 несет ответственность каждый поставщик услуг, а за какие несет ответственность сама организация.
- 40. © 2002—2014 Digital Security FAQ PCI DSS 3.0: к чему готовиться? 40 Windows XP
- 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