Агитация и пропаганда, апрельские тезисы про безопасную разработку

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

2. О себе/О нас
• О себе:
– занимаюсь ИБ/ПО с 2000 года
• ЗАО «ПМ»
– Аналитические и
инструментальный анализ ПО и
ИС
– С 2012 года – работаем по
направлению повышения
безопасности разработки
– Принимаем участие в работе с
регуляторами ИБ

3. Жизненный цикл ПО*: где ИБ?
30.05.2017 3
Проектирование
Требования
Разработка
Тестирование
Выпуск
Эксплуатация
Сертификация
Вывод из эксплуатации
*Аналогичная ситуация с
• Итеративными моделями разработки
• Моделью непрерывного размещения

4. Угрозы-2015: ИБ в широком смысле
• Уязвимость технологий (мобильные, облака),…
• Безопасность приложений
– проблемы внешних сервисов (связанных облачных сервисов)
• ИБ-катастрофы
– ИБ-провалы платформ-2014 Apple iOS, MS
– Shellshock, уязвимости TLS/SSL : Goto Fail, Heartbleed, POODLE, WinShock
– Мегаутечки из торговых сетей
• Риски инноваций
– Снижение эффективности СЗИ: «облачные атаки на СКЗИ» – норма
– Атаки на Интернет Вещей, АСУ ТП – мейнстрим
– Новые сценарии потребления – норма BYOx
• Проблемы обработки уязвимостей
– Неловкое саморазоблачение Drupal
– Проблема политики раскрытия уязвимостей
• Обучение Растущий разрыв в потребностях и уровне/количестве специалистов ИБ
• Вмешательство государств
– Гос. Программы по кибервооружениям (Китай, США)
– Санкции и запреты
Если нас «сломают»  Когда нас «сломают»

5. Если нас «сломают» 
Когда нас «сломают»

6. В условиях допустимой небезопасности
Насколько часты будут попытки атак?
Как часто будут атаки успешны?
Каковы будут последствия успешной атаки?
Когда обнаружим атаку/последствия?
Сможем эффективно противодействовать?


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

8. Как часто будут атаки успешны?
Уязвимость
• Свойство системы
– Наличие ошибки, недочета, слабости
– Наличие возможности эксплуатации
– Наличие метода, инструмента
• Компенсация ненадежности окружения
– Не обязательно программная
Необходимо учитывать при проектировании
• Уязвимости технологий, платформ, сторонних компонентов
• Превентивные механизмы, «security controls»
– Ограничение возможности доступа или эксплуатации

9. Каковы будут последствия успешной атаки?
• Отказ или несанкционированные
действия
• Атака – редко «атомарна»
• Развитие успешной атаки
– «Закрепление» в системе
– Устранение следов атаки и
несанкционированных
активностей
– Поиск новых целей и векторов атак
«Безопасная по построению» или
полная компрометация?

10. Когда обнаружим атаку/последствия?
• Фиксация изменения состояния
• Возможность анализа
изменения состояния
• Наблюдение: проведение такого
анализа
Встроенные механизмы защиты,
позволяющие обнаружить
компрометацию
• Самозащита механизмов защиты

11. Сможем эффективно противодействовать?
• Скорость реакции
– Сократить окно уязвимости (Window of Vulnerability)
• Локализовать инцидент
– Выявить первопричину компрометации
– Выявить первопричину уязвимости (ошибку)
• Разработать исправление
– Не позволяющее «обойти» себя
– Или атаковать аналогичную уязвимость
• Надежно устранить уязвимости
– Улучшить процесс разработки, не повторять ошибку в будущем
Культура разработки, надёжный целостный базовый уровень ИБ
• Практика, методики и инструменты
• Осведомленность и понимание методов атак

12. Безопасность– это тяжело
• Дорого
– Дополнительные требования
– Проектирование, разработка
• Сдвиги сроков
– Дополнительное тестирование
и доработка
• Инструменты и методики
• Компетенции в ИБ
Почему же тогда нужно заниматься
безопасностью? «…мы делаем сервис… в случае
возникновения проблем мы обратимся
за анализом уязвимостей»
Руководитель службы эксплуатации сервиса

13. Если компрометация неизбежна –
думать о безопасности выгодно
 Мониторинг и
реагирование
 Проверка и выпуск
продукта
 Разработка
 Проектирование
 Требования
 Подготовка команды
 Внедрение цикла
безопасной разработки
«…мы хотим сделать
новый сервис:…, насколько
это будет безопасно?»

14. Мифы и предубеждения
• Дорого и долго
– Дороже переделывать
– Заказчик может оплатить, если объяснить ему возможные риски
• Сложно, не понятно как
– Есть описания практик, паттернов/антипаттернов
– Есть (бесплатные) инструменты
– Есть «с кем поговорить об этом»
• Никому не нужно
– Требования регуляторов отраслевых, государственных
– Обеспокоенность правообладателей контента
• Да никому наш продукт и не интересен
– Не планируете его успех и тиражирование?
– Каждый раз начинаете «с нуля»?
Вы хотите управлять рисками и спать по ночам и продуктивно работать
или тушить пожары?

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

16. Как «читать» уязвимость
16
The CVE Identifier CVE-2014-0160 was released on April 7,
2014—the same day the Heartbleed bug was made public.
This type of weakness is described in detail by CWE-130: Improper
Handling of Length Parameter Inconsistency. The second weakness is an
out-of-bounds memory read, which is described inCWE-125: Out-of-
Bounds Read. These CWEs were first defined more than eight years ago
CAPEC-540: Overread Buffers defines the general pattern commonly
used by an attacker including how the attack is crafted, its potential
severity and consequences

17. 17

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

19. Анализ рисков ИБ готового продукта
Обработка ИБ-рисков
1. Избегать
– Организационные меры
2. Передать
– Регламенты для сотрудников
– Ответственность внешнего
аудитора
3. Минимизировать
– Исследовать безопасность
готовой системы
4. Стабилизация
– Фиксация практик
5. Своевременность процессов
Вероятность
Критичность
Повышение
уровня
защищенности
Пентесты Фиксация
практик
Контроль компонентов???
Контроль разработчика???
Процессы разработки
ИС разработчика

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

21. Модель действий атакующего
Общая модель
• Разведка
• Вооружиться
• Доставка
• Эксплуатировать
уязвимость
• Установка
• Получить канал
управления
• Действовать согласно
целям
21
Методы анализа ПО
• Статические
– Аудит исходного кода
– Реверс-инжиниринг
• Динамические
– Фаззинг
– Ручное тестирование
• Комбинированные
• Анализ архитектуры ПО
(Логические ошибки)

22. Инструменты и средства
• Инструменты
– Языки программирования
– Расширяемые инструменты
(скрипты)
• Python for hackers
– Фреймворки
– Специализированные
средства
– Дистрибутивы ИБ ОС
– Сервисы
– Заказная разработка
• Разрушающие
• Этические/не этические
методы
• Источники информации
– Методики
– Базы уязвимостей
– Закрытые форумы
– Репозиторий кода
– Форумы, переписка
• Заметные/скрытые
– Через сервисы (3rd party)
– Стенд
– Атака на клиента
– Атака на площадку
• В определенный момент

23. Цели, задачи, средства?
Инструменты: отладка
• Возможности по отладке кода,
предоставляемые процессором
Отладочные регистры и Last Branch
Recording в IA-32 и Intel 64
• Отладчики и отладочный API ptrace(),
Debugging Tools for Windows
• Dynamic Binary Instrumentation (DBI,
динамическое инструментирование
бинарного кода)
– PIN, DynamoRIO, Valgrind
• Intermediate Representation (IR,
промежуточное представление кода)
– Valgrind, LLVM и инструменты на
их базе (Fuzzgrind, KLEE, S²E)
• Эмуляция PIN, Ether, S²E
Инструменты: фаззинг
• Scapy- интерактивное средство манипуляции
сетевыми пакетами с функцией smart-фаззинга.
Позволяет описывать форматы сетевых сообщений и на
основании описанных форматов проводить
интеллектуальное фазз-тестирование. Используемые
способы манипуляции данными - генерация.
• Sulley- фаззинг-фреймворк, позволяющий описывать
сложных структуры данных, но нами больше используется
для фаззинга несложных полнотекстовых протоколов, к
примеру, MFTP.
• FuzzDB- база данных готовых векторов атак.
Используется нами при интеллектуальном
генерационном фаззинге. Количество векторов 35845 в
23-х категориях.
• Zzuf- многоцелевой прозрачный мутирующий фаззер.
Библиотеки данного инструмента используется нами при
слепом (black-box) фаззинге - мутация набора собранных с
помощью сетевого сниффера сообщений.
• BurpIntruder - утилита входящая в набор Burp
Suite использующийся для пентеста веб-приложений.

24. Пример подхода: Фаззинг
• Обвязка/инструментация
• Профилировка данных
• Шаблон и мутация
• Прогон, обнаружение сбоя
• Анализ данных сбоя
Данные по интерфейсам:
– Пользовательский ввод
– Файлы
– Сетевые порты
– API
24
Fuzztime
0 tn
Fuzzing
tn
Dump
tn tn
DumpFuzzing
tn
Analysis
Armed
OK
CORRUPTED
Data
D’
…
Mutator
D’’
Dump

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

26. Безопасная разработка: есть рецепты
Практики
«первопроходцев»
Доклады и презентации
Инструменты

27. Ловушки инструментов и практик “as is”
«Статический анализ кода? Мы конечно делаем»
• Выбор инструментов и компонентов
– Удобство среды разработки
– Использование знакомых компонентов
– Борьба с унаследованным кодом
• «Безопасное программирование» это достаточное ИБ?
– Утечки памяти, переполнение буфера, падения/повисания
– Безопасные опции компилятора
• Инструменты безопасности при разработке
– Анализаторы кода
– Генераторы нагрузки без тонкой настройки
– Системы автоматизированного тестирования
• Практики управления
– Менеджер форсирует: бюджет, сроки, функционал

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

29. Пример: OWASP. Содержание методики
OWASP Testing Guide 4.0 (2014)
1. Сбор информации
2. Анализ конфигураций
3. Идентификации пользователей
4. Аутентификации пользователей
5. Авторизации пользователей
6. Управление сессиями
7. Фильтрация переданных данных
8. Обработка ошибок
9. Анализ используемых
криптографических алгоритмов
10. Анализ бизнес-логики приложения
11. Анализ клиентской части
приложения
OWASP TOP 10
• A1 Внедрение кода
• A2 Некорректная аутентификация и
управление сессией
• A3 Межсайтовый скриптинг (XSS)
• A4 Небезопасные прямые ссылки на
объекты
• A5 Небезопасная конфигурация
• A6 Утечка чувствительных данных
• A7 Отсутствие контроля доступа к
функциональному уровню
• A8 Подделка межсайтовых запросов
(CSRF)
• A9 Использование компонентов с
известными уязвимостями
• A10 Невалидированные редиректы
29

30. Модели Системы и сценариев для ИБ
• Модель позволяет
– Формализовать и согласовать представление о
предмете
– Удобно обсуждать предмет (в идеале – всем)
• Договариваться и доносить точку зрения
• Анализ и описания для анализа ИБ
– Не должны быть «плохой копией КД» – свой угол
рассмотрения
– Не должны быть «калькой с НПА» – адекватные
модели

31. Требования: а ваш лог полезен для ИБ?
31

32. Достаточное и
необходимая
информация
в ПО
32
• Метаданные
• Отладочная информация
• Старые копии модулей
• Избыточное логирование
Для некоторых задач
атакующему не требуется
преодолевать криптографию
Passwords. Don’t hardcode
them mmkey?
Твит != 140 символов

33. Heartbleed яркий пример
«Внешний» компонент >> Разработка >>
Публикация уязвимости >> Патч? >>
Доступные цели
• Полный поиск HTTPS на всём IPv4
• 89.1% - неуязвимы (нет openssl)
• 6.0% support heartbeat messages, not vulnerable,
• 4.9% уязвимы
1 400 000 уязвимых серверов
33

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

35. Внедряем
Цикл
Безопасной
Разработки

36. Цикл Безопасной Разработки  Свод Знаний
Детализация
 1. Перечень практик
 1.1. Домен практик
 1.1.1. Описание практики
 1.1.1.1. Методика проверок
 1.1.1.1.1. Инструкция
 Домены (Разделы) практик
 Мониторинг и реагирование
 Проверка и выпуск продукта
 Разработка
 Проектирование
 Требования
 Сторонние компоненты
 Соответствие требованиям регуляторов
 Инструменты и системы разработки
 Подготовка команды

37. Cвой SDL. Так просто?
Basic Standardized
(Activities are
expert led)
Advanced
(Activities are led
by central security
team)
Dynamic
(Activities are co-
led by product
teams and central
security team)
Training, Policy
Organizational
Capabilities
+ Setting baseline and goals
for SDL
+ Executive support: Tacit
+ Enterprise coverage: Few
SDL pilot project
+/- Training: Basic concepts
+/- Basic security bug tracking
- Executive support: Explicit
- Enterprise coverage: New,
high risk project
- Training: Common baseline
- Central security team exists
- Executive support: SDL
mandated and enforced
- Enterprise coverage: All
project with meaningful risk
+/- Training: Custom training
- SDL is adopted to the
development methodology
Requirements
Design
Undefined or inconsistent - Risk assessment
+/- Threat models: Piloted to
high-risk modules
- Functional requirements for
security and privacy
- Standard security solutions
+/- Threat models: Created
with expert assistance
- Threat models:
Independently created by
product group
Implementation Undefined or inconsistent + Compiler defense
- Banned functions
- Cross-site scripting and SQL
injection defenses
+/- Static analysis tools - In-house, product-specific
security tools development
and customization
Verification Undefined or inconsistent - File fuzzing
- Basic Web application
scanning
+ Penetration testing by third
party as appropriate
+/- Comprehensive fuzzing
and Web application scanning
- Threat model validated
- In-house development and
customization tools to:
+ Detect vulnerabilities
- Audit compliance with SDL
Release
Response
Undefined or inconsistent - Final Security Review: Verify
internal and external
compliance
+ Project archiving
+ Response: Basic
+ Response plan in place,
incident tracking
- Basic root-cause analysis
- Real-time incident tracking
- Advanced root-cause analysis
and formal feedback into
policy

38. Процесс внедрения ЦБР
• Модель зрелости должна быть
– Подходящая этапность внедрения
• Методика
– Домены
– Соответствующая области
практика построения моделей
• Инструменты, лучшие практики

39. Стратегия внедрения
безопасной разработки
39
Проект
Проект
Проект
Проект
Продукт
Установка
Уста
новк
а
!

40. Стратегия внедрения
безопасной разработки
40
Проект
Проект
Проект
Проект
Продукт
Установка
Уста
новк
а

41. Измеримость – взгляд разработчика
• Продуктовый менеджмент
– Интенсивность разработки
• База внедрений
– перспективы развития
• Разработка:
технологические тренды,
тех.долг и архитектура
• Установка и
сопровождение
– «Агрессивность среды»
– Инциденты

42. Итого: ЦБР и ИБ – во имя добра
• Реагирование дороже предотвращения
– Игнорирование проблем – ещё дороже
• Чем компактнее коллектив и «моложе»
продукт – тем больше шансов внедрить
безопасную разработку
• Внедрение процесса полезно само по себе
– Осведомленность о методах и инструментах
ИБ
• Небольшие дополнения к введённым практикам
– Улучшение процессов разработки
• Снятие критических рисков и «пожаров»
42

43. худшая из угроз - Неведение
Инструментальный анализ
ПО и ИС
Внедрение практик
безопасной разработки
Мониторинг ИБ
Качалин Алексей
@kchln
kachalin@advancedmonitoring.ru

44. Безопасность: Риски и Качество
• Типы рисков
– Известные Известные - типовые
риски в предметной области
идентифицируемы, оцениваемы
достаточно точно
– Известные Неизвестные-
идентифицируемы, не
оцениваемы
– Неизвестные Неизвестные –
неидентифицируемые, сложно
оценить по степени влияния
• 3 метода обработки
– Избегать– переработать план,
снизить вероятность
реализации
– Передать - третья сторона
– Минимизировать последствия.
Остаточные риски
• «Цена» качества
– Соответствие
• Стоимость
предотвращения/гарантии
качества
• Стоимость проверки
– Несоответствие
• Внутренняя цена
(переделки, ненужная
работа)
• Внешняя цена (репутация,
иски, обработки
обращений)

45. Связь со стратегическим управлением
Предотвращение Реагирование
Обвинение  Прощение
Количественная  Качественная
Достоверное знание  Приближенная,
неполная информация
Независимость  Взаимозависимость
(безопасности и других свойств)
Ограничение  Открытость
(в обмене информацией)
Структура и продукт  Люди и процессы