Презентация с конференции PaymentSecurity 2016

1. Методы выполнения
требования 6.6 PCI DSS
– практический выбор
Денис Безкоровайный
CISSP, CISA, CCSK
ProtoSecurity
denis@protosecurity.ru
https://protosecurity.ru
+7 (499) 647-5967, доб.101
+7 (916) 999-3964

2. О чем пойдет речь
• Обзор требования 6.6
• Варианты реализации
• Реализовывать самому, или обращаться к внешним
подрядчикам?
• Сравнение вариантов
• Считаем TCO
https://protosecurity.ru 2

3. Требование 6.6 PCI DSS
Постоянно управлять новыми угрозами и
уязвимостями общедоступных веб-
приложений и обеспечить этим приложениям
защиту от известных атак одним из
следующих методов:
• Ручной или автоматизированный анализ
защищенности
• Автоматизированное техническое средство
(например, межсетевой экран уровня веб-
приложений)
https://protosecurity.ru 3

4. Анализ защищенности ручной или
автоматизированный
https://protosecurity.ru 4
Достоинства Недостатки
Автоматизированный
• Просто реализовать «для
комплаенса»
• Не все типы уязв-тей выявляются
• Риск запуска с параметрами по
умолчанию и на этом все
• Трудоемкий отсев ложных
срабатываний
Ручной
• Больше потенциально выявляемых
уязвимостей
• Трудоемко и долго
• Сложно масштабируемо

5. Кто выполняет анализ защищенности?
https://protosecurity.ru 5
Достоинства Недостатки
Внешний подрядчик
• Специалисты узкой области «в аренду»
• Масштабируемо для множества
приложений
• Нет аффилированности с разработкой
• Высокая стоимость работ на
больших объемах
Собственными силами
• При больших объемах проще
контролировать
• Дорогостоящий персонал узкой
специализации
(нанять/взрастить)

6. Варианты реализации WAF
Надстройка над существующим
приложением/сервером
Отдельное аппаратное/виртуальное устройство
Облачный сервис
https://protosecurity.ru 6

7. Надстройка над существующим
приложением/сервером
Плюсы
Легко подключить с базовыми правилами
Бесплатно или очень дешево
Минусы
Ограниченный функционал (наборы правил)
Часто использует мощности защищаемого
приложения
Трудоемкость написания новых правил
Сложность внедрения и
эксплуатации ***
Стоимость
$
https://protosecurity.ru 7

8. WAF как отдельное
аппаратное/виртуальное устройство
Плюсы
Более обширный функционал
Отдельное устройство (мощности)
Минусы
Сложно масштабировать и использовать в
динамических веб-инфраструктурах
Стоимость
Сложность внедрения и
эксплуатации ****
Стоимость
$$$$
https://protosecurity.ru 8

9. WAF как облачный сервис
Плюсы
Просто подключается, подходит для всех
типов размещения веб-приложений
Все плюсы облачного сервиса
Минусы
Все минусы облачного сервиса
Ограниченный функционал (часто нет
возможности расширения правил)
Зависимость от внешнего сервиса
(требования к SLA поставщика)
Сложность внедрения и
эксплуатации **
Стоимость
$$
https://protosecurity.ru 9

10. «Облачный WAF»
Ваши серверы
Хакеры
Боты
DDoS
Спаммеры
Легитимные пользователи
Web Application Firewall
WAF попал в scope!
https://protosecurity.ru 10

11. Размещение и управление
Web Application Firewall
Заказчик Подрядчик
WAF
https://protosecurity.ru 11

12. https://protosecurity.ru 12

13. Полная стоимость владения
13
• Стоимость ПО
• Стоимость железа
• Стоимость поддержки
• Ресурсы датацентра
• Внедрение
• Обучение сотрудников
• Персонал для сопровождения
• Обслуживание «железа»
• Настройка ПО
• Мониторинг и реагирование
• Амортизация и обновление «железа» https://protosecurity.ru

14. Такие разные исходные данные
• Инструменты ИТ/ИБ
• Балансировщики, серверы доступа к приложениям
• Команда сотрудников
• Есть ли ресурсы на самостоятельный анализ или сопровождение
• Бюджет
• Ресурсы датацентра
• Инфраструктура веб-приложения
• Расположено внутри или снаружи, резервные площадки
• Количество приложений и их сложность
https://protosecurity.ru 14

15. Сравнение TCO (пример)
https://protosecurity.ru 15

16. Сравнение TCO (пример)
https://protosecurity.ru 16

17. Compliance и защищенность
• Checkbox compliance:
• ИЛИ аудит ИЛИ Web Application Firewall
• Повышение защищенности
• аудит И Web Application Firewall
• Каждый вариант имеет свои плюсы и минусы
• Комбинация ручного + автоматизированного анализ
• Аудит – для compliance 1 раз в год или при изменениях
• Необходимо, но не достаточно
https://protosecurity.ru 17

18. Заключение
• Compliance – повод и руководство к действию повысить
реальную защищенность
• Для публичных веб-приложений разумно использовать оба
рекомендованных метода в различных комбинациях
• Пример критериев выбора методов реализации – TCO
https://protosecurity.ru 18

19. https://protosecurity.ru 19

20. Задайте вопрос
или поделитесь своей историей
info@protosecurity.ru
https://protosecurity.ru/