Post on 08-Jul-2015
description
transcript
Построение 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