Построение Secure Development Lifecycle
4 likes737 views
Документ обсуждает важность построения безопасного цикла разработки (secure development lifecycle, SDL) в контексте современных угроз и уязвимостей программного обеспечения. Он описывает этапы SDL, включая обучение, требования, дизайн, реализацию, проверку и релиз, акцентируя внимание на предотвращении уязвимостей и интеграции безопасности в процесс разработки. Документ также подчеркивает необходимость адаптации SDL к методологиям Agile и применения автоматизированных инструментов тестирования для обеспечения безопасности приложений.
Построение 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. Спасибо за внимание! ! [email protected] +380(67) 659 1342