Теория и практика SSDL

1. Практика внедрения в организациях
«Цикла безопасной разработки»
Качалин Алексей
Зам. Генерального директора ЗАО «ПМ»
ЗАО «Перспективный мониторинг»

2. Анализ ИБ
Инф. Систем
Анализ ПО
Практики SDL
Исследования
и Разработка
О Компании
• Исследовательское подразделение ГК ИнфоТеКС
• Специализация: исследования и
инструментальный анализ ИБ, методы и средства
атак на информационные системы
• Услуги ЗАО «ПМ»
– Инструментальный анализ ИБ
– Тест на проникновение
– Анализ ПО
– Расследование инцидентов

3. ЦИКЛ БЕЗОПАСНОЙ РАЗРАБОТКИ

4. Безопасность разработки - требование рынка
• Уязвимости и инциденты ИБ
– Больше не «приватный вопрос», не всегда возможно
контролировать раскрытие информации
– Раскрытие информации об уязвимостях используемых
компонентов
– Обращения к регулятору с вопросами от пользователей
• Необходимость реакции на обращение об
уязвимости, инцидентах
– Взаимодействие с «атакующим» сообществом
• Требования НПА и регуляторов
• Требования 3-их лиц по гарантиям ИБ

5. Условия внедрения безопасной
разработки
• Осязаемые результаты: отдача от инвестиций
– Возврат инвестиций
– Снижение количества инцидентов
– Оперативность реагирования на инциденты
• Встраивание в существующий процесс
разработки (заказа и эксплуатации ПО)
• Применение к имеющимся продуктам
• Вовлечение команды (мотивация
исполнителя) на дополнительные практики ИБ
5

6. Безопасная разработка:
этапы осознания проблем
 Реагирование
 Проверка и выпуск продукта
 Разработка
 Проектирование
 Требования
 Подготовка команды
 Внедрение цикла безопасной разработки

7. Реагирование на инциденты
• Продукт эксплуатируется
– «Отключить» нельзя
– Обслуживаются процессы (в т.ч. критические)
• Подрядчик/команда разработки работы сдали
• Анализ проблемы?
– В системе «боевые» данные – нельзя «передать»
на исследование/воспроизведение проблемы
Даже самый «безобидный» сценарий – сработал
сканер уязвимостей уже достаточно плохо

8. Источники сигналов об инцидентах ИБ в ПО
• Публикация уязвимости в используемом компоненте
• Публикация «обращения» в Интернет
• Внешние обращения – звонки/письма:
– Сообщения о «странном поведении программы» (нет явного
подозрения на проблемы ИБ)
– Попытки шантажа и ультиматумы
– Оскорбления и троллинг
– Готовый метод компрометации ИБ (пошаговый, в виде PoCE)
• Внутренние обращения
– Указания на строчку кода
– Развёрнутый анализ с обоснованием неизбежности уязвимости
Система учета обращений/багов необходима, но нужно
выстраивать процесс реагирования!
8

9. Пример: Взаимодействие с исследователями ИБ
9

10. Проверка и выпуск - «Обречены на релиз»
На этом этапе никто не рассматривает возможность
отказаться от выпуска продукта или существенно сдвинуть
сроки
• Релизное тестирование – исправить нельзя убрать
• Дорогие и длительные работы с сюрпризами
– Сертификация продукта
– Проверки сторонними ИБ-экспертами
• Внезапно - проблемы
– Уязвимость сторонних компонентов
– Быстрые исправления выявленных ошибок – костыли и
проблемы «на будущее»
– Отключение «проблемных» сценариев

11. Разработка: ловушки инструментов и практик
• Безопасность не в приоритете
– Удобство среды разработки
– Использование знакомых компонентов
– Борьба с унаследованным кодом
• Безопасный продукт?
– Утечки памяти, переполнение буфера, падения/повисания
– Архитектор потребует «безопасные» опции компилятора
• Ловушка – бессистемное использование инструментов не-
специалистами ИБ
– Анализаторы кода
– Генераторы нагрузки без тонкой настройки
– Системы автоматизированного тестирования
• Менеджер форсирует: бюджет, сроки, функционал
– Унаследованный долг: было 500 предупреждений, будет 507 – ок?

12. Проектирование
• «Безопасные решения» мешают красивой
архитектуре – лёгкая жертва
– Ограничения гибкости и расширяемости
– Дополнительные операции (журналирование)
– Затруднение сопровождения (обфускация)
• Исправление известных проблем дорого и «не
оплачено»
– Удаление «вшитых» паролей
• Ревью дизайна архитектуры – не частая процедура
– Ревью безопасности? На это нет времени
– Моделирование угроз
– Анализ рисков ИБ

13. Требования (на развитие продукта)
Требования от заказчика на развитие функциональных характеристик продукта могут не учитывать
текущего состояния продукта и реализованных сценариев
• Анализ требований
– Моделирование актуальных и возможных угроз
• Анализ сценариев с точки зрения ИБ - предложение дополнительных «контролей» ИБ
– Обоснованность (необходимость) и достаточность набора мер ИБ
• Оценка уровня безопасности продукта после реализации требований
– Прозрачность управления уровнем ИБ продукта/продуктовой линейки
– Ранжирование известных уязвимостей и исправление
– Группировка и привязка к релизам исправления уязвимостей
– Возможность построения «общей картины» по срезу (проект/продукт/менеджер)
• Прогноз - как изменится окружение (использование) продукта с точки зрения
ИБ?
• Менеджера продукта формирует требования на проект
– Унаследованный продукт, технологический долг
– Динамика развития функционала, архитектурные компромиссы
– Внешние и внутренние ИБ-риски предлагаемого проекта и продукта в целом
– Факторы ИБ как элемент оценки качества работы (обоснования необходимости затрат)

14. Обучение и мотивация: примеры
Каждой роли в создании продукта, проекте, компании необходима информация о
специфичных аспектах безопасной разработки
• Демонстрация эксплуатации уязвимостей – для
разработчиков
• Обзор комплексных атак на аналогичные системы – для
архитекторов
• Планирование работ по анализу продуктов – для
менеджеров разработки
• Практика выработки метрик для оценки состояния ИБ
продукта – для менеджеров продуктов
Обучение позволяет повысить компетенцию и, что часто важнее -
осведомлённость о проблемах ИБ

15. Выбор проектов для внедрения
безопасной разработки
• Проекты по развитию существующих продуктов
– Критичность
• Распространение на рынке
• Критичность сценариев
– «Агрессивность» среды
• Подверженность атакам на распространённые
заимствованные компоненты
• Возможность доступа для анализа
– Компактность продукта
• Новые продукты
• Пилотные и исследовательские проекты
• Все проекты со значимыми угрозами
15

16. Итого:
• Внедрение SDL - это сложный процесс, должен быть
организован и поддержан руководством
• Разрозненные практики ИБ – расходы на иллюзию
безопасности
• Многое зависит от автоматизации и инструментов
– Инструменты определяют отдельные сценарии
– Корректность и взаимосвязь процессов определяются
практиками
• Реагирование дороже предотвращения
– Дополнительные риски – непрогнозируемые сроки
• Предотвращение не бесплатно
– Корректное бюджетирование
– Безопасность – в «системе ценностей» менеджмента
16

17. Безопасная разработка:
этапы осознания проблем
 Реагирование
 Проверка и выпуск продукта
 Разработка
 Проектирование
 Требования
 Подготовка команды
 Внедрение цикла безопасной разработки

18. худшая из угроз - Неведение
Инструментальный анализ и аналитика ИБ ИС
Расследование инцидентов ИБ
Разработка инструментов сбора и анализа
данных в ИС
Центр компетенций ИБ
Исследования и аналитика технологий ИБ
Тренинги по практике ИБ