Построение Secure Development Lifecycle

1. Построение Secure
Development Lifecycle
!
Владимир Стыран, БМС Консалтинг

2. Кто эти люди?..
• БМС Консалтинг
• Мы делаем пентесты, много и часто
• Black Box, Grey Box, социальная инженерия…
• АБС, ДБО, биллинг, инфраструктура, веб- и прочие
приложения
• “Apparently, if you can test pens, you can test
everything.” - H.D. Moore

3. Что у нас позади
• Мы видим “картинку” снаружи и она нас пугает
• Domain Admin по внешнему вектору: 1 из 5-ти
• Domain Admin по внутреннему вектору: 3 из 5-ти
• В каждом “взрослом” пентесте: root, oracle, 100+
логинов/паролей пользователей, web shells…

4. Наши впечатления
• Типы граблей (по частоте обнаружения)
• Bad/default/no credentials
• Bad/no patch management
• Passwords for candy
• Application errors
• Bad session management
• Все остальные
17%
4%
13%
9%
22%
35%

5. Угрозы и стек технологий

6. Какие варианты?
• Борьба за безопасность “готовой” системы - сизифов труд
• Путь “Penetrate & Patch” ведет в никуда (хотя мы, конечно же, не против)
• Пентесты покрывают чуть больше половины известных угроз
• Infinity Maxim: There are an unlimited number of security vulnerabilities for a
given security device, system, or program, most of which will never be
discovered (by the good guys or bad guys).
• Лучший способ избавиться от уязвимости - не дать ей
возникнуть
• “Идеальный” план: построение полноценного процесса
Secure Development Lifecycle

7. Secure Development
Lifecycle
• “Изобретен” Microsoft под давлением сообщества
• Включает ряд организационных и технических
процессов
• И средства их автоматизации

8. Плоды SDL

9. Плоды SDL

10. Этапы SDL
• Обучение
• Требования
• Дизайн
• Реализация
• Проверка
• Релиз
• Реагирование
vs. Чик-чик и в продакшн!

11. Обучение
• Разработка программы обучения
• “Внешние” условия: требования, стандарты, законодательство
• Методики и технологии разработки
• Обучение команды и оценка результатов
• Метрики/критерии обучения
• Минимальная частота тренингов (на реже N раз в год)
• Минимальный групповой порог подготовки (не мнее 80% команды)
• Актуализация программы

12. Требования
• Утверждение требований безопасности до начала проекта
• Внешние (PCI, PII, HIPPA…) и внутренние (оценка рисков)
факторы
• Требования безопасности (т.н. негативные требования)
устанавливают, документируют (и тестируют) так же, как
позитивные требования к функционалу
• Минимальные требования безопасности (в терминах
пороговых значений качества)
• Назначение аналитика по безопасности

13. Дизайн
• Определение и документирование архитектуры
безопасности и механизмов защиты
• Использование техник безопасного дизайна:
многослойность защиты, управление версиями, принцип
наименьших привилегий, оценка рисков
• Моделирование угроз в контексте дизайна проекта,
выполняемых функций, обрабатываемых данных,
размещения в инфраструктуре, уникальных особенностей
• Минимизация угроз и рисков путем сужения “поверхности
атаки”

14. Реализация
• Использование техник безопасного кодирования: проверка ввода,
экранирование символов, параметризация запросов…
• Статический анализ по мере готовности исходного кода
• Реакция на уязвимости: исправление, документирование
• Использование одобренных инструментов и параметров
редактирования, контроля версий, сборки
• Использование средств ОС: ASLR, DEP, SElinux, apparmor…
• Отказ от незащищенных и устаревших библиотек, API,
криптографических алгоритмов
• Особое внимание к онлайн-сервисам: XSS, SQLi…

15. Проверка
• Переоценка модели угроз с учетом проделанной работы
• Пересмотр дизайна с учетом новых угроз (изменение “поверхности атаки”)
• Тестирование негативных требований
• Динамический анализ по мере готовности объектного кода
• Фаззинг, брут, стресс-тесты и прочее для файлового и пользовательского
ввода, API, сетевых подключений и т.д.
• Упор на анализ защищенности кода и тестирование безопасности
• Специфические тесты для онлайн-сервисов
• Реакция на уязвимости: исправление, документирование

16. Релиз
• Создание плана реагирования на инциденты и уязвимости,
обнаруживаемые в системе
• Обеспечение возможности выпуска исправлений
безопасности
• Финальная оценка защищенности
• Принятие/отклонение релиза
• Архивирование проекта
• Обновление документации
• Сохранение исходного кода для потомков (code escrow)

17. Реагирование
• Выполнение плана реагирования на инциденты,
составленного на стадии релиза

18. SDL для Agile
• Вернемся в реальность: по “классическому” SDLC уже
никто не работает
• В Agile SDL практики классифицированы не по этапам
SDLC, а по частоте выполнения
• Every-sprint: самые важные, повторять для каждого
релиза
• One-time: менее критичные, выполнять одноразово
• Bucket: все остальные, выполнять по мере надобности

19. One-time
• Из требований
• Требования безопасности
• Оценка рисков
• Из дизайна
• Требования к дизайну
• Сужение поверхности атаки
• Из релиза
• Создание плана реагирования

20. Every-sprint
• Из дизайна
• Моделирование угроз
• Из реализации
• Использование одобренных инструментов
• Отказ от старого хлама (API, библиотеки и т.д.)
• Статический анализ кода
• Из релиза
• Финальная оценка защищенности, принятие и архивирование

21. Bucket
• Из требований
• Минимальные требования безопасности
• Из проверки
• Динамический анализ приложения
• Фаззинг и прочие издевательства
• Пересмотр модели угроз и “поверхности” атаки

22. Ключевые концепции
• Производство защищенного кода требует
усовершенствования процессов разработки
• Один лишь поиск багов не делает софт безопаснее
• Риски это проблема менеджера, а не разработчика
• Постоянный пересмотр процессов SDL
• Непрерывное обучение, культура безопасности
• Инструменты и автоматизация
• Поощрение и последствия

23. Gartner
AST MQ
Сегмент продуктов
автоматизированного
тестирования
защищенности
приложений в 2013 г.

24. Подведем итог
• Угрозы двигаются на уровень приложений
• Сегмент инструментов автоматизации созрел
• SDL внедряет безопасность в процессы и
культуру разработки
• Результаты измеримы и впечатляют
• SDL Agile-у не враг

25. Спасибо за внимание!
!
vladimir_styran@bms-consulting.com
+380(67) 659 1342