Страх и ненависть DevSecOps

Митап на тему "Безопасность", 22-08-2018
Шабалин Юрий, Swordfish Security

Доклад посвящен проблемам перехода от классической модели Application Security к процессу DevSecOps. Разбираем, как правильно подойти к встраиванию процесса безопасной разработки в процесс DevOps, как при этом ничего не сломать и превратить его в DevSecOps. Проясним основные этапы тестирования на безопасность, какие инструменты можно применять, посмотрим чем они отличаются и как их правильно настроить. Ну и конечно же подводные камни, которые встречаются в любом процессе, пробуем их избежать или хотя бы подготовиться к столкновению.

Transcript

1. Yury Shabalin Chief Security Architect Страх и ненависть DevSecOps
2. Спикер конференций: Zer0Nights, PHDays, RISSPA, OWASP Yury Shabalin Chief Security Architect § Разработка § Внедрение SSDL § Анализ исходного кода § Безопасность мобильных приложений § Android Bughunter 2
3. 1. Application Security - о чём это? 2. Классический подход, и почему он больше не работает 3. Изменяем процессы, переход к DevSecOps 4. Основные этапы, инструменты, подводные камни 5. Небольшое демо О чём пойдёт речь? 3
4. Application Security - о чём это? 4 SDLC, где S – это Security Основная задача не обнаружение уязвимостей, а предотвращение их появления
5. Подходы к построению бывают разные 5 OWASP OpenSAMM BSIMM Что же выбрать? Microsoft
6. 6 BSIMM
7. Классический подход 7 Security
8. Проблемы классического подхода 8 Проблемы: • Инструменты ИБ стоят отдельно от разработки • Особенности процесса разработки не учитываются • Проверки ИБ проходят перед релизом • Требования ИБ непонятны и противоречивы К чему это приводит: • Большое количество новых уязвимостей • Увеличение сроков выпуска релиза • Перекладывание ответственности
9. Переход к DevSecOps 9 VS
10. 10 С чего начать? Просто включить инструменты в процесс DevOps недостаточно. Важно взаимодействие и понимание между участниками процесса
11. Главное люди, а не инструменты 11 • Важнее люди, а не инструменты § Не нужно сразу покупать дорогие инструменты и потом под них пытаться сделать процесс • Перед началом опишите цели и продумайте стратегию развития • Опишите процесс, как он будет устроен, обсудите с потенциальными участниками
12. Change Your Mind 12 Разработка + ИБ + DevOps= 1 love • Качество продукта – общая цель • Одна сторона без помощи другой хороших результатов не получит • У сотрудников ИБ свои знания, у разработчиков – свои, помогайте друг другу • Проводите семинары, обучение, совместные тренинги • Не держите в себе экспертизу, делитесь
13. Общайтесь на одном языке 13 • Начните с того, что уже есть: § Приведите в порядок требования § Создайте портал, где будет вся необходима информация в доступном и понятном виде § Проведите обучение, вовлеките в процесс § Вооружите знаниями (гайдлайны по безопасной разработке, семинары) • Используйте инструментарий и наработки разработчиков • Используйте Security Champions
14. Security Champions 14 Что делать, если команда ИБ небольшая? Привлекайте коллег, заинтересованных в разработке – Security Champions SECURITY CHAMPION Обязанности: • Единый интерфейс в команду • Работа с инструментальным стеком ИБ • Консультирование команды по вопросам ИБ • Проведение код-ревью, тренингов Мотивация: • Профессиональное развитие в новой области и расширение технического кругозора • Прокачка технических, управленческих и лидерских навыков • Повышение рыночной стоимости
15. 15 Этапы тестирования Тестирование на проникновение Качество результатов автомат. ручное Высокие Трудозатраты Низкие Средние 20% 80% • Скрытые уязвимости • Логические ошибки • Ошибки архитектуры • Дефекты реализации • «Мертвый» код • «Закладки» • Общий уровень качества кода и отклонения от стандартов Статический анализ (SAST) Контроль Open Source (OSA) Динамический анализ (DAST) • Контроль библиотек в периметре • Известные уязвимости в Open Source • Лицензионные ограничения • Мониторинг новых уязвимостей в используемых компонентах • Недекларированное поведение • Утечки памяти • Перерасход ресурсов • Ошибки аутентификации • Back doors, вредоносный код • Ошибки конфигурации • Несоответствие политикам ИБ компании
16. Статический анализ (SAST) 16 Возможности • Анализ кода на наличие уязвимостей • Не то же самое, что SonarQube :) • При анализе применяется ряд подходов: • Pattern-анализ • DataFlow-анализ • Анализ конфигураций • Выявление уязвимостей в коде на раннем этапе Риски • Долгое время сканирования • Высокий уровень False Negative или False Positive • Отсутствие интеграций • Отсутствие или чрезмерная сложность кастомизации • Отсутствие поддержки необходимых языков
17. 17 Основные требования • Низкий уровень False Positive • Возможность кастомизации инструмента • Инкрементальные сканирования • Интеграция в CI • Интеграция в процесс code review • Интеграция со средой разработки (Intellij IDEA, Android Studio, etc) • Понимание Roadmap развития продукта Статический анализ (SAST)
18. SAST Competitive Landscape 18
19. SAST OpenSource Landscape 19
20. 20 • Интеграция на уровне CVS • По событию – pull request, commit • Обратная связь – показываем статус проверки • Интеграция с системой code review • Дефолтный ревьюер – технический пользователь AppSec • Ревьюер видит статус тестов по ИБ • Запрет Merge, если тест по ИБ не пройден • Интеграция с SonarQube • Включение результатов в отчет Sonar Интеграция в процесс
21. 20 • Интеграция на уровне CVS • По событию – pull request, commit • Обратная связь – показываем статус проверки • Интеграция с системой code review • Дефолтный ревьюер – технический пользователь AppSec • Ревьюер видит статус тестов по ИБ • Запрет Merge, если тест по ИБ не пройден • Интеграция с SonarQube • Включение результатов в отчет Sonar Интеграция в процесс
22. Интеграция в процесс 21 • Интеграция на уровне CI • На одном уровне с автотестами, unit-тестами и т.д. • Разделение по этапам разработки (dev, test, prod…) • Наличие уязвимостей не является show stopper для проведения функционального тестирования, но может останавливать сборку, если она идёт в промышленную среду
23. 22 • Не нужно сразу отправлять разработчикам все найденные баги без разбора • Сформируйте технический долг, который будете разбирать постепенно, сообщайте только о новых уязвимостях в только что написанном коде Интеграция в процесс
24. Анализ Open Source (OSA) 23 Возможности • Анализ используемых Open Source библиотек на наличие известных уязвимостей • Уязвимости в открытых и закрытых источниках • Уязвимости в баг-трекерах • Наличие собственной исследовательской команды • Анализ лицензионной чистоты • Контроль библиотек в периметре организации • Мониторинг новых уязвимостей в компонентах, использующихся в промышленной среде Риски • Недостаточная информация об уязвимостях • Отсутствие интеграций • Отсутствие разделения политик на основании этапа разработки • Сложность интеграции
25. 24 Основные требования • Низкий уровень False Positive • Удобство использования • Различные политики для различных этапов разработки • Мониторинг компонент в промышленной среде • Возможность контроля библиотек в контуре организации • Наличие интеграций • Поддержка различных систем сборки и языков • Возможность анализа Docker-образов • Понимание Roadmap развития продукта Анализ Open Source (OSA)
26. OSA Competitive Landscape 25
27. Интеграция в процесс 26 • Контроль библиотек, которые скачиваются из внешних источников • Интеграция в CI • На одном уровне с автотестами, unit-тестами и т.д. • Разделение по этапам разработки (dev, test, prod…) • Наличие уязвимостей не является show stopper для проведения функционального тестирования, но может останавливать сборку, если она идёт в промышленную среду • Интеграция в среду разработки • Проверка на наличие уязвимостей до коммита в CVS • Интеграция в CD • Мониторинг появления новых уязвимостей в промышленной среде
28. 27 Интеграция в процесс
29. Динамический анализ (DAST) 28 Возможности • Анализ развёрнутого приложения на наличие уязвимостей • Имитация работы пользователя с приложением • Отправка «зловредных» паттернов и анализ ответа сервера • Тестирование всех возможных параметров запроса (параметры, заголовки, формы и т.д.) • Поиск известных уязвимостей • Fuzzing • Проверка конфигурации сервера Риски • Высокая нагрузка на сеть\сервер приложения • Отсутствие интеграций • Возможность изменения настроек анализируемого приложения • Отсутствие поддержки необходимых технологий • Сложность настройки
30. 29 Основные требования • Низкий уровень False Positive • Наличие интеграций • Поддержка различных технологий • Удобство записи последовательности логина • Возможность настройки интенсивности сканирования • Возможность исключения из скоупа тестирования определенных адресов Динамический анализ (DAST)
31. DAST Competitive Landscape 30
32. Интеграция в процесс 31 • Интеграция в CD • Запуск сканирования после установки приложения на стенд • Сканирование после успешного проведения интеграционного тестирования • Идеально – отдельный стенд для тестирования • До начала тестирования необходимо записать последовательность логина • Наличие уязвимостей не является show stopper для проведения функционального или ручного тестирования, но может останавливать сборку, если она идёт в промышленную среду • Тестирование системы администрирования – только ручное
33. 32 Дефекты ИБ, какие они? Not all Software Quality issues are AppSec issues. But all AppSec issues are Software Quality issues. Sherif Mansour, Expedia
34. Каждый процесс нуждается в контроле 33 Для понимания, как работает процесс и где его нужно улучшить: • Производственные метрики • Метрики с инструментов • Метрики из дефект-трекеров • Обеспечение полной прозрачности процесса для всех участников в полностью автоматическом режиме. • Статистика по практикам и их применению • Любые данные могут быть полезны • Но не просто данные ради данных, а метрики - ради метрик Чем больше данных, тем больше разрезов можно построить. От верхнеуровневых до деталей каждого процесса
35. Как работает у нас? 34
37. Key Takeaways 36 • Инструменты не главное • Сначала продумать процесс – затем внедрять инструменты • Качество продукта – общая цель • Дефекты ИБ = Функциональные дефекты • Выбирайте инструменты исходя из требований к своему процессу • Разговаривайте на одном языке и используйте общие инструменты
38. 37 • Автоматизируйте всё, что двигается • Всё, что не двигается – двигайте и автоматизируйте • Начните с того, что уже есть: требования, архитектура, частичные проверки, тренинги, гайдлайны • Если размер команды ИБ небольшой – используйте Security Champions. • Не нужно сразу применять все практики на все проекты – двигайтесь итерационно Единого стандарта нет – экспериментируйте и пробуйте различные подходы Key Takeaways
39. Telegram: @Mr_R1p Linkedin: https://www.linkedin.com/in/yuryshabalin/ yshabalin@swordfishsecurity.com