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

!Владимир Стыран, БМС Консалтинг

Кто эти люди?..• БМС Консалтинг

• Мы делаем пентесты, много и часто

• Black Box, Grey Box, социальная инженерия…

• АБС, ДБО, биллинг, инфраструктура, веб- и прочие приложения

• “Apparently, if you can test pens, you can test everything.” - H.D. Moore

Что у нас позади

• Мы видим “картинку” снаружи и она нас пугает

• Domain Admin по внешнему вектору: 1 из 5-ти

• Domain Admin по внутреннему вектору: 3 из 5-ти

• В каждом “взрослом” пентесте: root, oracle, 100+ логинов/паролей пользователей, web shells…

Наши впечатления• Типы граблей (по частоте обнаружения)

• Bad/default/no credentials

• Bad/no patch management

• Passwords for candy

• Application errors

• Bad session management

• Все остальные

17%

4%

13%

9%22%

35%

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

Какие варианты?• Борьба за безопасность “готовой” системы - сизифов труд

• Путь “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

Secure Development Lifecycle

• “Изобретен” Microsoft под давлением сообщества

• Включает ряд организационных и технических процессов

• И средства их автоматизации

Плоды SDL

Плоды SDL

Этапы SDL• Обучение

• Требования

• Дизайн

• Реализация

• Проверка

• Релиз

• Реагирование

vs. Чик-чик и в продакшн!

Обучение• Разработка программы обучения

• “Внешние” условия: требования, стандарты, законодательство

• Методики и технологии разработки

• Обучение команды и оценка результатов

• Метрики/критерии обучения

• Минимальная частота тренингов (на реже N раз в год)

• Минимальный групповой порог подготовки (не мнее 80% команды)

• Актуализация программы

Требования• Утверждение требований безопасности до начала проекта

• Внешние (PCI, PII, HIPPA…) и внутренние (оценка рисков) факторы

• Требования безопасности (т.н. негативные требования) устанавливают, документируют (и тестируют) так же, как позитивные требования к функционалу

• Минимальные требования безопасности (в терминах пороговых значений качества)

• Назначение аналитика по безопасности

Дизайн• Определение и документирование архитектуры безопасности и механизмов защиты

• Использование техник безопасного дизайна: многослойность защиты, управление версиями, принцип наименьших привилегий, оценка рисков

• Моделирование угроз в контексте дизайна проекта, выполняемых функций, обрабатываемых данных, размещения в инфраструктуре, уникальных особенностей

• Минимизация угроз и рисков путем сужения “поверхности атаки”

Реализация• Использование техник безопасного кодирования: проверка ввода, экранирование символов, параметризация запросов…

• Статический анализ по мере готовности исходного кода

• Реакция на уязвимости: исправление, документирование

• Использование одобренных инструментов и параметров редактирования, контроля версий, сборки

• Использование средств ОС: ASLR, DEP, SElinux, apparmor…

• Отказ от незащищенных и устаревших библиотек, API, криптографических алгоритмов

• Особое внимание к онлайн-сервисам: XSS, SQLi…

Проверка• Переоценка модели угроз с учетом проделанной работы

• Пересмотр дизайна с учетом новых угроз (изменение “поверхности атаки”)

• Тестирование негативных требований

• Динамический анализ по мере готовности объектного кода • Фаззинг, брут, стресс-тесты и прочее для файлового и пользовательского ввода, API, сетевых подключений и т.д.

• Упор на анализ защищенности кода и тестирование безопасности

• Специфические тесты для онлайн-сервисов

• Реакция на уязвимости: исправление, документирование

Релиз• Создание плана реагирования на инциденты и уязвимости, обнаруживаемые в системе

• Обеспечение возможности выпуска исправлений безопасности

• Финальная оценка защищенности

• Принятие/отклонение релиза

• Архивирование проекта • Обновление документации

• Сохранение исходного кода для потомков (code escrow)

Реагирование

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

SDL для Agile• Вернемся в реальность: по “классическому” SDLC уже никто не работает

• В Agile SDL практики классифицированы не по этапам SDLC, а по частоте выполнения

• Every-sprint: самые важные, повторять для каждого релиза

• One-time: менее критичные, выполнять одноразово

• Bucket: все остальные, выполнять по мере надобности

One-time• Из требований

• Требования безопасности

• Оценка рисков

• Из дизайна

• Требования к дизайну

• Сужение поверхности атаки

• Из релиза

• Создание плана реагирования

Every-sprint• Из дизайна

• Моделирование угроз

• Из реализации

• Использование одобренных инструментов

• Отказ от старого хлама (API, библиотеки и т.д.)

• Статический анализ кода

• Из релиза

• Финальная оценка защищенности, принятие и архивирование

Bucket• Из требований

• Минимальные требования безопасности

• Из проверки

• Динамический анализ приложения

• Фаззинг и прочие издевательства

• Пересмотр модели угроз и “поверхности” атаки

Ключевые концепции• Производство защищенного кода требует усовершенствования процессов разработки

• Один лишь поиск багов не делает софт безопаснее

• Риски это проблема менеджера, а не разработчика

• Постоянный пересмотр процессов SDL

• Непрерывное обучение, культура безопасности

• Инструменты и автоматизация

• Поощрение и последствия

Gartner AST MQ

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

Подведем итог• Угрозы двигаются на уровень приложений

• Сегмент инструментов автоматизации созрел

• SDL внедряет безопасность в процессы и культуру разработки

• Результаты измеримы и впечатляют

• SDL Agile-у не враг

Спасибо за внимание!

!vladimir_styran@bms-consulting.com

+380(67) 659 1342