Выступление Валерия Боронина, посвященное процессу безопасной разработки, его преимуществам и особенностям.

1. Заголовок
ptsecurity.com
Построение процесса
безопасной разработки
Что это означает на практике
для разработчиков и их руководителей?
Валерий Боронин

2. ЗаголовокВалерий Боронин
• В разработке и R&D более 20 лет
• Начинал еще под Windows 3.1
• Достиг определенных высот разработчиком
режима ядра под Windows (до 2009)
• В безопасности с прошлого тысячелетия ;-)
• Работал CTO небольшой компании (30+ человек)
• Директором по исследованиям большой
(«Лаборатория Касперского», 2500+ человек, 2009–2014)
• Сейчас отвечаю за направление безопасной разработки
(SDL / SSDL) в Позитиве
• Мы с командой создаем новый продукт
по автоматизации безопасной разработки

3. Заголовок
О чем поговорим в начале?
• Зачем нужна безопасность?
• Что такое защищенное приложение?
• Почему ПО небезопасно?
• Разработчики и безопасность
• Что такое SDL/SSDL = безопасная разработка?
• Зачем нужна?
• Какие проблемы решает?

4. ЗаголовокЗачем нужна безопасность вашим заказчикам?
Отраслевые
требования
Государственное
регулирование
Доступность
бизнеса
Капитализация
Статистика
нарушений
Требования
заказчика
Предыдущий
плохой опыт

5. ЗаголовокПоследствия проблем с безопасностью
Доверие
Деньги
Данные
утекшие
Время
на восстановление
Ущерб
по инциденту
Заказчики
Репутация
Безопасность на стыке с надежностью:
у вас 5 компонентов в e-commerce
приложении с 98% uptime каждый?
Ожидайте 150 мин простоя в день! *
*Источник: книга Gary McGraw (https://www.garymcgraw.com/)

6. ЗаголовокЗачем? Наши реалии
Большинство
обнаруживаемых
уязвимостей –
типовые,
общеизвестные,
хорошо описанные.
Статистика по распределению уязвимостей веб-приложений за 2015 год
Источник: по данным аналитического центра Positive Technologies (серым цветом – 2014 год)

7. Заголовок
59%
80%
100% 100%
65%
20%
Черный/серый ящик Белый ящик
Высокий Средний Низкий
Почему мы об этом говорим?
Источник: по данным аналитического центра Positive Technologies за 2015 год
56%
69%
88%
100% 100% 100%
44%
38%
75%
0%
20%
40%
60%
80%
100%
120%
PHP Java Другие
Высокий Средний Низкий

8. ЗаголовокЧто такое защищенное ПО?
• Обычно подразумевается:
• Безопасная разработка
• Контроль целостности
• Правильная эксплуатация
• …а по версии ФСТЭК?
• + документация и конфигурации
• + инфраструктура среды разработки
• + люди
Хорошо работает то, что хорошо управляется © В. В. Путин

9. ЗаголовокЧто такое защищенное ПО?
Быть на шаг впереди,
в постоянном ожидании сбоя.
Работать даже тогда, когда твоего сбоя
яростно ожидает оппонент.
Защищенное ПО гораздо больше
вкладывает в учет проблемных кейсов,
чем не имеющих проблем.
На шаг впереди – вот девиз
проектировщиков и других
безопасных разработчиков.
Источник: вступительное слово
к замечательной книге Gary McGraw (первопроходца в SDL)

10. ЗаголовокПочему ПО небезопасно?
1. Ломать – не строить!
2. Безопасность – ассиметрична
3. В основе многих классов уязвимостей –
проблемы с дизайном (design issues)
или бизнес-логикой (business logic issues)
4. Инструменты для тестирования
на безопасность продаются как решение проблемы
небезопасного ПО (таблетки не существует)
5. Защищенное ПО – дуально.
Надо атаковать и защищаться, эксплуатировать
и проектировать, ломать и строить –
одновременно
I know when I’m writing code I’m not thinking
about evil, I’m just trying to think about
functionality © Scott Hanselman
Почему простого цикла разработки или
анализа-исправления кода недостаточно?
Полный разбор в блестящем анализе
от Геннадия Махметова

11. ЗаголовокЧто же делать?
• Нужно
• Проактивное проектирование
+
• Exploit-driven тестирование
+
• Все это на базе управления рисками
Три основания безопасной /
защищенной разработки:
управление рисками,
лучшие практики
и Знание
Program testing can be used to show the
presence of defects, but never their
absence © Dijkstra

12. ЗаголовокРазработчики и безопасность
Стандартные отговорки:
• Сроки горят (время)
• Нет ресурсов (бюджета, экспертизы,
инструментов, …) на обеспечение
безопасных практик
• Мы стартап – нам нужно быстрее
стать популярными и заработать
много денег
• …
Shortage of skill or shortage
of discipline?
Знать мало – надо
применять!

13. ЗаголовокЦикл [безопасной] разработки
• SDLC – Systems / Software
Development Life Cycle
• SSDLC – Secure Software
Development Life Cycle
• SDLC – Secure / Security
Development Life Cycle
• SSDL – Secure Software
Development
• SDL – Secure Development
Lifecycle (MSFT)
SDLC

14. ЗаголовокSDLC vs SDL / SSDL
SDLC SSDL
«Просто» разработка ПО
Жизненный Цикл
«Безопасная» разработка ПО

15. ЗаголовокЗачем нужен SDL? Взгляд руководителя
• Риски и минимизация ущерба
• Стоимость разработки
• Соответствие требованиям

16. ЗаголовокЗачем нужен SDL? Взгляд руководителя
• Риски и минимизация ущерба
• Стоимость разработки
• Соответствие требованиям

17. ЗаголовокЗачем нужен SDL? Взгляд руководителя
• Риски и минимизация ущерба
• Стоимость разработки
• Соответствие требованиям

18. ЗаголовокСтоимость разработки
Источник: книга Gary McGraw, 2008

19. ЗаголовокСтоимость разработки
NIST: исправлять ошибки после выпуска дороже
в 30 раз, чем на стадии разработки дизайна

20. ЗаголовокСтоимость разработки
Источник: HP ‘The New Attack Vector: Applications Reduce risk
and cost by designing in security.’
Исправлять ошибки после выпуска дороже в 30–100 раз,
чем на стадии разработки требований

21. ЗаголовокСтоимость разработки

22. ЗаголовокНо почему четырежды?
Исследование Aberdeen:
• Предотвращение одной уязвимости почти полностью покрывает годовые затраты
на повышение безопасности разработки
• Предотвратить проблему с безопасностью в 4 раза дешевле,
чем разбираться с ее последствиями
Исследование Forrester:
• Разработка безопасного ПО еще не стала широко распространенной практикой
• Компании, применяющие методы SDL, демонстрируют
гораздо более быстрый возврат инвестиций
BSIMM (позже) & McGrow (в книге) еще более категоричны:
• Разрыв между теми, кто применяет, и теми, кто ждет, нарастает с ускорением
• Пугают тем, что скоро HR начнут массово искать SDL-certified людей ;-)
• В результате не перестроившиеся начнут вылетать с рынка

23. ЗаголовокФакты из мира качества
Inspections
+ static
analysis
+ formal
testing > 99%
efficient
Quality
excellence
has ROI > $15
for each $1
spent
Источник: http://namcookanalytics.com/software-quality-survey-state-art/

24. ЗаголовокБезопасность – это дорого (1 / 2)
Источник: http://namcookanalytics.com/software-quality-survey-state-art/

25. ЗаголовокБезопасность – это дорого (2 / 2)
Источник: http://namcookanalytics.com/software-quality-survey-state-art/

26. ЗаголовокБезопасность – трудно найти и трудно исправить
HIGHLIGHTS FROM
THE 2015 WORLD SW
QUALITY REPORT
…
Security is the most
pressing concern
Источник: http://namcookanalytics.com/software-quality-survey-state-art/

27. ЗаголовокЗачем нужен SDL? Взгляд разработчика
1. Качественный код
(безопасное и качественное ПО)
2. Больше времени на работу
(и собственное развитие!)
3. Проактивность Реактивность
(быть причиной)
…Все правильно сделал! 

28. Заголовок
Минуточку! Попрошу поподробнее!
• Применимость
• Когда разработка становится безопасной?
• Роли, ответственность, квалиф. требования
• Обязательные активности (16 практик)
• Дополнительные активности
• О чем еще стоит упомянуть?
• Процедура проверки безопасности приложения
• Так этих SDL’ей… много и они разные?!
Что же такое SDL? Из чего состоит?

29. ЗаголовокSecurity Development Lifecycle (SDL) – must have
Обучение
• Начальное
обучение
безопасности
Требования
• Определение
требований
по безопасности
• Оценка рисков
• Create Quality
Gates/Bug Bars
Дизайн
• Установить
требования к
дизайну
• Анализ
поверхности
атаки
• Моделирование
угроз
Реализация
• Выбор
инструментов
• Блокирование
запрещенных
функций
• Статический
анализ
Проверка
• Динамический
анализ
• Fuzz Testing
• Проверка
поверхности
атаки
Выпуск
• План
реагирования
на инциденты
• Финальный
анализ
безопасности
• Доверенный
выпуск
Реагирование
• Выполнение
плана
реагирования
http://www.microsoft.com/security/sdl/default.aspx
  
Технология и процессОбучение Ответственность
Education, accountability, and clear objectives are critical components to any successful software security initiative © McGraw

30. ЗаголовокЧто такой упрощенный SDL?
• Модель помогает определить
текущий уровень зрелости компании
и разработать план действий
по внедрению соответствующих
процессов для реализации
полноценного цикла
безопасной разработки
• Так когда разработка
становится безопасной?  Зрелость Организации

31. ЗаголовокSDL. Применимость
Ваше приложение:
• Работает в бизнес- или корпоративном окружении?
• Обрабатывает / хранит персональные данные
или sensitive информацию?
• Взаимодействует по сети / другим каналам
передачи информации?
• Практика показывает, что сложно
найти приложение, которому не показан SDL

32. ЗаголовокSDL. Люди: формализация ролей и обязанностей
•Советник по безопасности /
конфиденциальности (снаружи)
• Аудитор (подчиненная роль)
• Эксперт (подчиненная роль)
• Можно совмещать аудитора с экспертом
• Советников тоже можно совмещать
•Руководители групп по безопасности /
конфиденциальности (изнутри)
• Отвечают за координацию и отслеживание
вопросов безопасности на проекте + сообщают
состояние Советнику и другим ЗЛ
• Можно совмещать роли security и privacy champions

33. ЗаголовокSDL. Фаза 1 – Обучение
1. Все задействованные сотрудники
в технических ролях (Devs, QA, PMs)
2. Не реже 1 раза в год
3. Знания для выполнения остальных фаз
+ как работаем по новому процессу
• Обследовать подготовленность организации
по темам безопасности и защиты данных (privacy)
• При необходимости создать стандартные курсы обучения
Безопасность –
дело каждого!
Разработать критерии качества программы обучения
Содержимое должно покрывать темы со следующего слайда
Определить частоту тренингов
Разработчик должен пройти не менее Х тренингов в год
Определить минимальный приемлемый порог тренингов в группе разработки
75% техперсонала должны пройти базовые тренинги до выпуска беты

34. ЗаголовокSDL. Фаза 1 – Обучение. Чему учить?
1. Безопасный дизайн
• Уменьшение поверхности атаки
• Наименьшие привилегии
• Многослойная защита
• Безопасные настройки по умолчанию
2. Моделирование угроз
3. Безопасное кодирование
(переполнение буфера, XSS,
SQL-инъекции, криптография)
4. Тестирование безопасности
• Разница с функциональным тестированием
• Оценка рисков
• Методы тестирования безопасности
Безопасность –
дело каждого!
• 5. Защита информации / Privacy /
Соответствие требованиям
• Персональные данные, ФЗ 152
и отраслевые стандарты
• Трансграничная передача данных
• Обработка, хранение и т. п.
чувствительных данных – ФЗ №242
• 6. …
• …
• Trusted user interface design
• …

35. ЗаголовокSDL Фаза 2 – Требования
Возможность заложить
безопасный фундамент для проекта
• Определение требований
по безопасности (разово)
SDL Practice #2: Establish Security
and Privacy Requirements
• Определить и задокументировать
порог отбраковки продукта по ошибкам,
связанным с безопасностью
и защитой данных (разово)
SDL Practice #3: Create Quality Gates/Bug Bars
• Оценка рисков SDL Practice #4: Perform Security
and Privacy Risk Assessments (разово)

36. ЗаголовокSDL Фаза 3 – Проектирование
1. Архитектурные требования (разово)
• Определить и задокументировать архитектуру безопасности
и идентифицировать критические компоненты безопасности
2. Анализ / сокращение поверхности атаки (разово)
• Задокументировать поверхность атаки продукта
• Ограничить ее установками по умолчанию
3. Моделирование угроз
• Определить угрозы и меры снижения угроз
• Систематический пересмотр свойств продукта и его архитектуры
с точки зрения безопасности
• Определить критерии выпуска обновления продукта в связи
с изменением в безопасности продукта

37. ЗаголовокSDL Threat Modeling Tool (TMT) – справочно
• Формализует и упрощает моделирование угроз так,
чтобы им мог заниматься архитектор
Обучает созданию диаграмм угроз
Анализ угроз и мер защиты
Интеграция с багтрекером
Отчеты по угрозам и уязвимостям

38. ЗаголовокSDL. Фаза 4 – Реализация
Разработка кода и ревью процессов, документации
и инструментов, необходимых для безопасного
развертывания и эксплуатации разрабатываемого продукта
• Использование утвержденных / доверенных
средств и их аналогов
• Практики безопасного программирования
• Статический анализ кода
Конкретно:
Поиск случаев использования запрещенных API
Применение механизмов защиты предоставляемых ОС
Использование безопасных версий библиотек и фреймворков
Соблюдение специфических требований безопасности (XSS, SQL-инъекции…)

39. ЗаголовокSDL. Фаза 5 – Проверка (Тестирование)
Начните тестирование
как можно раньше. В идеале –
как только появился готовый
для этого код
• Динамический анализ
• Фаззинг – файлами, вводом данных
в интерфейсные элементы
и код сетевой подсистемы
• Повторно проверьте модели угроз,
риски, поверхность атаки.
Все ли вы учли?
• Начните планирование процесса реагирования на обнаружение уязвимостей в выпущенном продукте – см. следующую стадию
• При необходимости выполнить security push (с каждым разом все реже)
• Не является заменой работе над безопасностью в процессе разработки
• Ревью кода
• Тестирование на проникновение
• Ревью дизайна и архитектуры в свете вновь обнаруженных угроз

40. ЗаголовокSDL. Фаза 5 – Проверка: инструменты (справочно)
BinScope Binary Analyzer
• Убедиться что SDL соблюден
при компиляции и сборке
MiniFuzz File Fuzzer
• !exploitable в WinDbg
• DAST
RegexFuzer
• DAST
Attack Surface Analyzer
• Анализ снимков системы
• Измеряет потенциальную
поверхность атаки на приложение и ОС
AppVerifier
• Динамический анализ системы
MSF Agile + SDL шаблоны для TFS
• Автоматически создает процессы
соблюдения SDL в момент создания нового
спринта или выполнения check in
• Контролирует выполнение всех
необходимых процессов безопасности
CMMI Шаблоны SDL для TFS
• SDL требования как задачи
• SDL-based check-in policies
• Создание отчета Final Security Review
• Интеграция с инструментами
сторонних производителей
• Библиотека пошаговых указаний SDL how-to

41. ЗаголовокSDL. Фаза 6 – Выпуск: план реагирования
• Создать политики поддержки продукта
• Создать план реагирования на инциденты безопасности
• Группа инженерной поддержки: ресурсы внутри
и снаружи организации для адекватной реакции
на обнаружение уязвимостей и защиту от атак
• Контактные данные лиц, доступных 24x7x365
• 3–5 инженеров
• 3–5 специалистов из маркетинга
• 1–2 менеджеров верхнего уровня
• Обратите внимание на:
• Необходимость выпуска экстренных обновлений
вашего продукта из-за уязвимостей в унаследованном коде
• От других групп в той же организации
• Сторонних производителей
• Включенном в ваш продукт
• Лицензионные условия, возможность вносить изменения,
имена файлов, версии, контактные данные и т. п.
• Может быть необходимость обновлять продукт
после обновления ОС и т. п. http://www.microsoft.com/security/msrc/whatwedo/responding.aspx
Watch
Alert and Mobilize
Resources
Assess and
Stabilize
Resolve
Reporting
Analysis and Mitigation
Create Fix
Update Models
Test Fix
Выпуск
Lessons Learned
Provide Guidance

42. ЗаголовокSDL Фаза 6 – Выпуск: Final Security Review (FSR)
Проверить продукт на соответствие требованиям SDL и отсутствие известных
уязвимостей.
Получаем независимое заключение готовности продукта к выпуску.
FSR не является:
• Тестом на проникновение. Запрещено ломать и обновлять продукт
• Первой проверкой безопасности продукта
• Процессом финальной подписи продукта и отправки его в тираж
FSR должен обязательно включать три возможных результата окончательной
проверки безопасности:
1. Можно выпускать
2. Можно выпускать с ограничениями (и есть план по их душу)
3. FSR с эскалацией (на руководство Компании)
Ключевая концепция: эта фаза не используется как точка для завершения всех задач,
пропущенных на предыдущих стадиях

43. ЗаголовокSDL. Фаза 6 – Выпуск: заверить релиз и – в Архив
• План реагирования на инциденты безопасности создан
• Документация для клиентов обновлена
• Создан централизованный архив всего, что поможет
• С сервисным обслуживанием релиза
• Снизить стоимость поддержки
в долгосрочной перспективе
• Обязательно включить в архив
• Исходники
• Приватные отладочные символы
• Модели угроз
• Документацию –
техническую и пользовательскую
• Планы реагирования
• Лицензионные и прочие Servicing Terms
для используемого стороннего ПО

44. ЗаголовокSDL. Фаза 7 – Реагирование на инциденты
• Инцидент случился? Идем по заранее созданному плану
• Выполняем активности по плану
реагирования на инциденты безопасности
• Выпускаем обновления в соответствии
с графиком релизов
• Пересчитываем риски
• Информируем клиентов
• Публикуем информацию
• Выгоды планового реагирования
• Понятно, что происходит
• Есть ответственные
• Удовлетворенность клиента растет
• Собираем данные для будущих разработок
• Проводим тренинги
Не если,
а когда!

45. ЗаголовокSDL. Дополнительные меры – что бы сделать еще?
1. Сode review глазом
• Важные компоненты
• Где храним, обрабатываем,
передаем sensitive данные
• Криптография
2. Анализ уязвимостей схожих
приложений (конкурентов)
3. Тесты на проникновение (но сделать до FSR!)
Улучшаем процесс дальше:
1. Анализ первопричин Исследование причин появления найденных уязвимостей (из-за чего она
возникла – человеческая ошибка? Несовершенство процесса? Ошибка автоматизации?)
2. Регулярное обновление процесса

46. ЗаголовокSDL. Процедура проверки безопасности приложения
• Специальные меры по хранению артефактов
через приложение со строгим
контролем доступа (RBAC)
• Руководители групп безопасности
и конфиденциальности обеспечивают
ввод данных и их корректность
• Их используют Советники,
обеспечивая среду для FSR и для
анализа, а также подтверждения
выполнения всех требований
Обязательно хранить:
• Требования безопасности
и конфиденциальности для организации
• Функц. и тех. требования для разрабатываемого приложения
• Рабочий контекст приложения (Ex: процедура отслеживания)

47. ЗаголовокCisco SDL – так их, оказывается, много и они разные?!
1. Требования
(Product Security Requirements)
2. 3rd Party Security
3. Проектирование
(Secure Design)
4. Реализация
(Secure Coding)
5. Оценка
(Secure Analysis)
6. Тестирование
(Vulnerability Testing)

48. ЗаголовокСравнение SDL – справочно
Cisco SDL Microsoft SDL PA-DSS SDL РС БР ИББС-2.6-2014)
Обучение
разработчиков
Secure Design, Secure Coding Training Обучение -
Отслеживание
уязвимостей
3rd Party Security Implementation (частично) Выявление уязвимостей Эксплуатация
Определение
требований к ИБ
Product Security Requirements Requirements Проектирование Проектирование
Создание модели
угроз
Secure Design Design Оценка рисков
Разработка технического задания
(рекомендательно)
Практики безопасной
разработки
Secure Coding Implementation Создание -
Анализ кода Secure Analysis Implementation Анализ кода
Создание и тестирование
(рекомендательно)
Тестирование
безопасности
Vulnerability Testing Verification, Release
Тестирование
безопасности
Создание и тестирование
Выпуск релиза - Release Выпуск Прием и ввод в действие
Поддержка - Response Поддержка Сопровождение и модернизация
Вывод из
эксплуатации
- Снятие с эксплуатации
Источник: http://www.slideshare.net/arekusux/sdl-38135128

49. ЗаголовокSoftware Assurance Maturity Model (SAMM)
Модели Software Assurance Maturity Model (SAMM) и Building Security In Maturity Model (BSIMM)
для оценки текущего уровня зрелости, а также в качестве методологической основы для построения
процессов обеспечения безопасности разработки.
В рамках предлагаемых методик выделяются четыре основных направления развития процессов управления
безопасностью разработки или бизнес-функций: корпоративное управление (Governance), разработка
(Construction), контроль (Verification), развертывание и эксплуатация (Deployment).

50. ЗаголовокBuilding Security In Maturity Model (BSIMM)

51. ЗаголовокThe Building Security In Maturity Model (BSIMM)

52. Заголовок
Практические выводы
• Основные заблуждения про SDL – снимаем
• C чего начинать, в каком порядке?
• Disclaimer – о чем обязан предупредить
• C чем будут трудности у руководителя
• Предостережения разработчику
• Как преодолевать (тезисно и справочно)
• Знание – Сила! И другие полезности
Что важно, что забрать с собой

53. ЗаголовокСнимаем основные заблуждения об SDL
• SDL независим от платформы и языка разработки
• SDL подходит для разных сценариев разработки включая
бизнес-приложения и онлайн-сервисы
• SDL применим к разным методологиям разработки,
таким как водопад и agile
• Успешная реализация SDL предполагает автоматизацию
с помощью инструментов. Вы можете использовать
инструменты от других компаний
• SDL подходит организациям любого размера.
От разработчика-одиночки до огромных корпораций

54. ЗаголовокПочему независимы от процессов и методологий?
Потому что привязка идет к артефактам!

55. ЗаголовокПро автоматизацию
Качество и полнота выходных данных, полученных на каждом этапе / фазе, очень
важны. The SDL process does benefit from investments in effective tools & automation
but the real value lies in comprehensive & accurate results.

56. ЗаголовокВнедрение SDL – вариант от MSFT SDL Team, 2014

57. ЗаголовокВнедрение SDL – еще вариант
1. Обучение
2. Практики безопасного программирования
3. Тестирование безопасности и анализ кода
4. Процедуры выпуска и поддержки
5. Отслеживание уязвимостей, реестр ПО
6. Формальное определение требований к ИБ
7. Планы реагирования на инциденты
8. Моделирование угроз, анализ поверхности атак
9. Внешний анализ

58. ЗаголовокДобавь безопасность в твой процесс разработки!

59. ЗаголовокНе делай то, что делает MSFT, делай, что сделал!
Предупреждение от Securosis
Adopting MS-SDL wholesale is a little like a child
putting on adult clothes because they want to be
‘big’. You cannot drop that particular process into
your development organization and have it fit.
More likely you will break everything. Your team
will need to change their skills and priorities, and
though it sounds cliche, people are resistant to
change. Existing processes need to be adjusted
to accommodate secure development processes
and techniques. You will need new tools, or to
augment existing ones. You will need a whole new
class of metrics and tracking. And everything you
pick the first time will need several iterations of
alteration and adjustment before you get it right –
this isn’t Microsoft’s first attempt either.

60. Заголовок«Стандартные» затыки – менеджерам на заметку
Не надо:
• Слишком полагаться на тестирование на поздних этапах цикла
• Управлять без измерений
• Обучать, не оценив
• Начинать без достаточной поддержки руководства
• Политические риски
• Бюджетные риски
• Стандартные для дисциплины Управление Изменениями
(организационными, в частности) – у нас максимум сложности: люди,
процессы, технологии
Обучение, ответственность и ясные цели – ключевые компоненты успеха
любой программы по безопасности

61. Заголовок3 предостережения – разработчикам
• Не надо думать о безопасности ПО как о проблемах кодирования.
McGraw метко называет это явление «парад багов»
• Неверно убеждение, что software security про то, как грамотно адаптировать
или использовать различные фичи или соглашения по безопасности.
Software security скорее про страховку, чем про фичи / функциональность
• Последнее предупреждение – не полагайтесь чересчур на чеклисты. Тот
же STRIDE в моделировании угроз. Чеклисты устаревают без обновления
по результатам открытий и не всегда полны
Основанный на фичах подход к безопасности зовут иногда ‘cookbook’ approach. Конечно,
поможет с рецептом, но просто чтение книги без включения плиты и пробы блюда вряд ли сделает из
вас хорошего повара.
Опыт – самый могущественный учитель.

62. ЗаголовокСтроим успешную программу по безопасности
• Сделай план под себя: выявляй зависимости и планируй. Пошаговые изменения – см.
дальше. Знай, как у тебя все работает, и ищи грамотный путь улучшить с использованием
лучших практик
• Выкатывай отдельные инициативы аккуратно: найди чемпиона для каждой и надели
ответственностью. Не оставляй без помощи – коучинг и наставничество. Пилоты
и прототипы – не надо на всех сразу накатывать сырое
• Обучай людей: разработчики и архитекторы могут не подозревать, как много тут от них
зависит. Обучение и воспитание
• Заложи основу метрикам: измеряй и оценивай прогресс. Метрики (в т. ч. относительно
себя прошлого и по бизнес-показателям) и измерения – без них никуда в любой большой
организации. В идеале надо накрыть четыре зоны: project, process, product and
organization. Первые три вокруг artifact or activity в разработке, четвертая, чтобы
определять тренды вокруг первых трех
• Установи и поддерживай способность к постоянным изменениям: создавай условия
путем постоянных измерений и оценки результатов, периодически переводя внимание
на отстающие аспекты своей программы повышения уровня безопасной разработки

63. ЗаголовокРекомендации от первопроходцев SDL
• Перестать кровоточить / Stop the bleeding
• SAST или переход на процесс анализа рисков
• Собери все, что назрело / Harvest the low-hanging fruit
• Хороший барометр, готова ли организация меняться реально
• Заложи основание / Establish a foundation
• Создай контроль изменений / Creating change control programs
• Построй анализ первопричин / Building root-cause analysis function
• Создай контур обратной связи / Setting up critical feedback loop
• Усиляй сильные качества / Craft core competencies
• Развивай то, что дает различия / Develop differentiators
• Строй все, что осталось / Build out nice-to-haves

64. ЗаголовокДля мастодонтов это может выглядеть так: PDCA
Первая волна (первая фаза) проведение инвентаризации,
оценки и анализа текущего уровня зрелости разработки
с точки зрения безопасности. Внедрение или повышение уровня базовых практик безопасности.
Создание рабочей группы безопасности приложений. Целевое обучение участников группы.
Подготовка плана повышения уровня зрелости разработки с точки зрения ИБ.
Вторая волна (вторая и третья фазы) – реализация плана повышения уровня зрелости разработки
с точки зрения ИБ. В рамках второй фазы проводятся основные активности, осуществляется
внедрение основных технических и организационных механизмов, разработка необходимой
документации. Проводится массовое обучение сотрудников практикам безопасной разработки
и приемам использования внедряемых инструментов, разработчикатываются метрики оценки
практик безопасности.
Третья фаза позволяет оценить успешность мероприятий второй фазы, исправить явные недочеты
и подготовить план повышения уровня зрелости для третей волны.
Третья волна (четвертая и пятая фазы) – в рамках третьей волны реализуется план повышения
уровня зрелости с учетом опыта третьей фазы. Также внедряются дополнительные организационные
и технические механизмы, необходимость которых была выявлена в ходе реализации второй
и третьей фазы. В рамках пятой фазы проводится сопровождение внедренных практик безопасности
и оценка эффективности текущего уровня зрелости.
Оценочная продолжительность каждой из фаз – 6 месяцев.
PDCA = Plan – Do – Check - Act

65. ЗаголовокЗнание – Сила. Как можно организовать?
Software Security Unified Knowledge Architecture Seven knowledge catalogs (principles, guidelines, rules, vulnerabilities, exploits,
attack patterns, and historical risks) are grouped into three knowledge categories (prescriptive knowledge, diagnostic knowledge,
and historical knowledge).
Experience, Expertise, and Security
Software developers place a high premium on knowledge. Experience is king, and expertise is very valuable.

66. Заголовок
ptsecurity.com
Выгоды и выводы
• Для разработчиков
• Для руководителей

67. ЗаголовокВыгоды SDL / SSDL для разработчиков
1. Меньше времени на переделывание и отладку
2. Меньше времени на тестирование
3. Меньше времени на поддержку и проще развитие
4. Отлов проблем как можно раньше
5. Избегаем повторяющихся security issues
6. Избегаем несогласованных уровней безопасности
7. Повышаем экспертизу и опыт в безопасности
8. Выше продуктивность + чаще укладываемся в сроки
1. Качественный код
2. Больше времени
на работу и развитие
3. Проактивность

68. ЗаголовокВыгоды SDL / SSDL для руководителей
Более защищенная, безопасная и надежная разработка, которая:
• Увеличивает ROI и качество ВАШЕГО продукта / сервиса
• Снижает риски (в т. ч. «завалить» проект, получить качество продукта
ниже ожиданий, превысить бюджет или сроки, а также связанные
с интеллектуальной собственностью)
• Минимизирует возможный ущерб и стоимость инцидентов
• Снижает стоимость разработки, поддержки
и общую стоимость владения
• Помогает соответствовать требованиям (compliance)
• Повышает уровень удовлетворенности у Заказчика и Команды
• Повышает продуктивность
• Уменьшает сроки / график / расписание

69. ЗаголовокНе пора ли применить SDL / SSDL?
Исследование Aberdeen
Предотвращение одной уязвимости почти полностью покрывает
годовые затраты на повышение безопасности разработки
Исследование Forrester
Компании, применяющие
методы SDL, демонстрируют
гораздо более быстрый
возврат инвестиций
Предотвратить проблему с безопасностью
в 4 раза дешевле, чем разбираться
с ее последствиями!

70. Заголовок
Подведем итог
• Атаки переходят на уровень приложений
Are your product Popular? Next Target!
• Разработка защищенного кода с помощью процесса
безопасной разработки – экономия денег Компании,
снижение рисков и повышение качества продукта
•Пора попробовать SDL!

71. ЗаголовокЧто почитать (1 / 2)
• Building Security In – обязательно к прочтению
• Дао безопасности от Геннадия Махметова
• SDL by Microsoft все про SDL от MSFT
• Книга по SDL от Ховарда и Липнера
(главный за SDL в Microsoft)
• Упрощенный SDL на русском (и оригинал)
• SDL Best Practices for Developers, BUILD 2014
(45 min video)
• Alexey Sintsov SDLC Implement me or Die
(SDL+DevOps)
• Алексей Бабенко Цикл безопасной разработки SDL
• Andrey Beshkov on SDL & ALM (1, 2)
• Nazar Tymoshyk on SDL & Agile (1, 2, 3)

72. ЗаголовокЧто почитать (2 / 2)
• Безопасное программирование
http://cwe.mitre.org
http://owasp.org
• Общие базы данных уязвимостей
http://www.securityfocus.com
http://nvd.nist.gov
http://secunia.com
• Информация по внешнему обучению
http://www.sans.org/security-training.php
• Материалы для организации внутреннего обучения
OWASP Code Review Project
OWASP Top 10 Project
http://www.sans.org/top25-software-errors
http://www.cert.org/secure-coding

73. ЗаголовокМоделирование угроз. Ссылки
1. Application Threat Modeling на сайте OWASP
2. Статья с описанием подхода на Хабре от Владимира Кочеткова, PT
3. Обнаружение недостатков безопасности при помощи STRIDE
(MSDN Magazine)
4. The STRIDE Threat Model на сайте Microsoft
5. Microsoft Threat Modeling Tool 2016

74. ЗаголовокМинутка рекламы
Ищем
• SDL/SSDL сообщество – тех,
кому интересна «жизнь по SSDL»
• Тех, кто готов делиться опытом,
уже живет или находится в процессе
перехода на SDL
• Разработчиков на С#, QA,
фронтендеров, аналитиков
в Новосибирск bit.ly/PT_Novosibirsk_job
• …и другие города тоже
www.ptsecurity.com/about/vacancy

75. ЗаголовокПара видео - как мы живем, работаем, отдыхаем :)
Backstage
Positive Technologies 13 лет!
https://youtu.be/1_zNxMHyCZk
Присоединяйтесь!
Будем работать по / в цикле
безопасной разработки вместе :)

76. Заголовок
Thank You!
ptsecurity.com