Презентация на Cisco ERC Security Day 2015

1. #root
это только начало
Владимир Стыран

2. почему я?
• Специалист по ИБ с 2005 г.
• Работодатели:
• интеграторы, телеком операторы, финансовые
услуги, ИТ-компании
• Клиенты:
• банки, страховые, телеком, нефте- и газодобыча,
промышленность
• Руковожу практикой Application Security в крупной
ИТ-компании
• Являюсь сооснователем Berezha Security –
поставщика качественных и доступных пентест-услуг

3. почему я?
“Доктор, я очень хочу root-а.”

4. что происходит?

5. у всех проблемы
сложности!

6. сложности клиента

7. сложности клиента
• Более 2/3 взломов выявляются спустя
9+ мес. от компрометации
• В 96% случаев жертва узнает о
взломе “со стороны”
• Объективно оценить защищенность
собственными силами невозможно
• Выбрать качественного поставщика
очень непросто
• И еще тысяча и одна сложность

8. сложности рынка
• Дефицит информации о потребностях
клиента
• аналитика – прогнозирование тенденций
на основе истории
• показания клиента – часто не имеют
отношения к реальности
• вендоры ПО и услуг – редко объективны
• Итого: пилоты, “тестирования”,
консультации и т.д., и после этого…

9. сложности пентестера

10. сложности пентестера
• Скоуп пентеста зачастую не отражает
реальные потребности клиента
• Большинство пентестов “умирают”
сразу после завершения
• Системные уязвимости не
исправляются. Никогда.
• Мы не можем исправлять
собственные находки

11. почему пентесты?
• Пентест – самый эффективный способ проверить
уровень защищенности системы, приложения или
организации
• быстрый – несколько недель
• недорогой – масштабируется по скоупу
• продуктивный – actionable результат
• После завершения пентеста аргументы в пользу выбора
средств защиты становятся очевидны… ну почти

12. хороший пентест
• Не-бинарный результат
• Дает достаточно
информации о рисках
• Дает достаточно
информации о защите
• Нацелен на результат…
в хорошем смысле

13. как это происходило?

14. как это происходит сейчас?

15. как это происходит?
• Целью пентеста является выявление возможности
нарушения или обхода политики ИБ с высокой
вероятностью
• наличие уязвимости
• отсутствие или слабость контроля (средства
защиты)
• простота эксплуатации
• доступность бюджета/средств для атаки

16. как это происходит?

17. как пентест поможет
поставщику?
• Выявление реальных
потребностей и ожиданий
клиента
• Демонстрация эффективности
средств защиты в ходе пилота/
демо тестирования
• Возможность проверки средств
защиты после внедрения
• Маркетинговый потенциал

18. выявление потребностей
• Качественный отчет о пентесте содержит
• Общее заключение
• Обобщенные результаты
• Системные рекомендации
• Описание уязвимостей
• Подробные рекомендации

19. выявление потребностей
• Качественный отчет о пентесте содержит
• Общее заключение
• Обобщенные результаты
• Описание успешных атак
• Системные рекомендации
• Описание уязвимостей
• Подробные рекомендации

20. перед внедрением и после
• Ручные или автоматические атаки на средство
защиты для визуализации состояний “до” и
“после” с внятной статистикой
• Привлечение “независимых экспертов” для
проверки и подтверждения эффективности
внедренного контроля
• Генерация ответов на вопросы клиента типа “а
что если…”

21. маркетинговый потенциал

22. “классический” подход
Клиент Поставщик
Домашняя работа Пресейл, маркетинг
RFI Индикативное предложение
RFP Коммерческое предложение
Тестирование Пилот

23. “классический” подход
Клиент Поставщик
Тендер Боль
“Отжим” скидки Боль
Согласование с юристами Боль
Внедрение Боль
Поддержка Боль

24. давайте по-другому!

25. (pen)test-driven подход
1. Отчет о пентесте, оценка качества
2. Нет отчета? Давайте сделаем!
3. Дополнительные вводные
• регуляторный режим
• миссия, визия, ценности
• внутренние требования
• удобство, удобство, удобство
4. КП? С гарантией защиты стресс-тестированием
5. Пилот? С симуляцией действий атакующего
6. Высокая цена? Прямая демонстрация качества

26. примеры?
• Симуляция уже известного инцидента, произошедшего в прошлом
• Выявление инцидента “in action” в ходе пентеста
• Выбор и демонстрация SIEM для визуализации методов раннего
обнаружения
• Клиент-сайд атака на теле-сотрудника
• Демонстрация средств NAC для исключения слабого звена до
достижения нужного уровня защищенности
• DDoS-диверсия во время более серьезной атаки
• Интеграция Cyber Threat Defence, SIEM/SOC и средств защиты от
DDoS для выявления аномального поведения

27. что дальше?

28. спасибо за внимание!
• sapran@berezhasecurity.com
• twitter.com/saprand
• securegalaxy.blogspot.com