Безопасность - критически важный элемент любого программного решения. Элемент, который, рано или поздно, но заставит вспомнить о себе. Скупой платит дважды, а в данном случае – минимум четырежды. Безопасность и качество кода – связаны напрямую. Поэтому положение дел и с тем и с другим редко находят достаточно хорошим даже в самых успешных проектах – всегда хочется бОльшего. А где-то бывает просто необходим качественный переход и точечными мерами кардинально ситуацию уже не исправить, нужен системный подход. Вот почему наладить процесс обеспечения и повысить уровень зрелости безопасности разработки, повысить качество кода – хотят многие руководители и разработчики. Как это сделать системно и в согласии? Какие риски для одних, какие трудозатраты для других? И стоит ли овчинка выделки? Об этом и поговорим. 2016/05/10: загружена версия для оффлайна.

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

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

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

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

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

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

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

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

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

10. VS.
1. Ломать – не строить!
2. Безопасность – ассиметрична.
3. В основе многих классов
уязвимостей – проблемы с
дизайном (design issues) или
бизнес-логикой (business logic
issues)
4. Инструменты для тестирования
на безопасность продаются как
решение проблемы
небезопасного ПО (таблетки не
существует)
5. Защищенное ПО – дуально.
Надо атаковать и защищаться,
эксплуатировать и
проектировать, ломать и строить
- одновременно.
Почему ПО небезопасно?
23 апреля 2016 Стачка, 2016, Ульяновск 10
«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
тестирование
+
все это на базе
управления рисками
Что же делать?
23 апреля 2016 Стачка, 2016, Ульяновск 11
Три основания безопасной
защищенной разработки:
управление рисками,
лучшие практики и
Знание
“Program testing can be used to show the
presence of defects, but never their
absence” - Dijkstra

12. Стандартные отговорки:
Сроки горят (время)
Нет ресурсов (бюджета,
экспертизы,
инструментов, …) на
обеспечение безопасных
практик
Мы стартап – нам нужно
быстрее стать
популярными и
заработать много денег
…
Разработчики и Безопасность
23 апреля 2016 Стачка, 2016, Ульяновск 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
Цикл [безопасной] разработки
23 апреля 2016 Стачка, 2016, Ульяновск 13

14. SDLC vs SDL / SSDL
23 апреля 2016 Стачка, Ульяновск 14
SDLC SSDL
«Просто» разработка ПО
Жизненный Цикл
«Безопасная» разработка ПО

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

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

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

18. Стоимость разработки
23 апреля 2016 Стачка, Ульяновск 18
Источник: McGraw book, 2008

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

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

21. Стоимость разработки
23 апреля 2016 Стачка, Ульяновск 21

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

23. Факты из мира качества
23 апреля 2016 Стачка, Ульяновск 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
23 апреля 2016 Стачка, Ульяновск 24
*Источник: http://namcookanalytics.com/software-quality-survey-state-art/

25. Безопасность - это дорого – 2 / 2
23 апреля 2016 Стачка, Ульяновск 25
*Источник: 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. 1. Качественный код
(безопасное и
качественное ПО)
2. Больше времени на
работу (и собственное
развитие!)
3. Проактивность
Реактивность
(быть причиной)
…Все правильно сделал!

Зачем нужен SDL? Взгляд разработчика
23 апреля 2016 Стачка, Ульяновск 27

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

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

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

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

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

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

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

35. Возможность заложить
безопасный фундамент для
проекта
Определение требований по
безопасности (разово) 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 (разово)
SDL Фаза 2 - Требования
23 апреля 2016 Стачка, Ульяновск 35

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

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

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

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

40. 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
SDL Фаза 5 – Проверка: Инструменты (справочно)
23 апреля 2016 Стачка, Ульяновск 40

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

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

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

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

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

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

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

48. 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 Поддержка Сопровождение и модернизация
Вывод из эксплуатации - Снятие с эксплуатации
Сравнение SDL – справочно
Источник
23 апреля 2016 Стачка, Ульяновск 48

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

50. Building Security In Maturity Model (BSIMM)
23 апреля 2016 Стачка, Ульяновск 50

51. The Building Security In Maturity Model (BSIMM)
23 апреля 2016 Стачка, Ульяновск 51

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

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

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

55. Про автоматизацию
23 апреля 2016 Стачка, Ульяновск 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
23 апреля 2016 Стачка, Ульяновск 56

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

58. Добавь Безопасность в твой процесс разработки!
23 апреля 2016 Стачка, Ульяновск 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.
23 апреля 2016 Стачка, Ульяновск 59

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

61. 1. Не надо думать о безопасности ПО как о проблемах
кодирования. McGraw метко называет это явление «парад
багов».
2. Неверно убеждение, что software security про то как
грамотно адаптировать или использовать различные фичи
или соглашения по безопасности. Software security скорее
про страховку, чем про фичи функциональность.
3. Последнее предупреждение – не полагайтесь чересчур на
чеклисты. Тот же STRIDE в моделировании угроз. Чеклисты
устаревают без обновления по результатам открытий и не
всегда полны.
3 Предостережения - разработчикам
23 апреля 2016 Стачка, Ульяновск 61
Основанный на фичах подход к безопасности зовут иногда "cookbook"
approach. Конечно, поможет с рецептом, но просто чтение книги без
включения плиты и пробы блюда вряд ли сделает из вас хорошего повара.
Опыт – самый могущественный учитель.

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

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

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

65. Знание – Сила. Как можно организовать?
23 апреля 2016 Стачка, Ульяновск 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. Выше продуктивность + чаще укладываемся в сроки
23 апреля 2016 Стачка, Ульяновск 67
1. Качественный код
2. Больше времени на
работу и развитие
3. Проактивность
20-
40%

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

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

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

71. 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)
Что почитать 1 2
23 апреля 2016 Стачка, 2016, Ульяновск 72

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
23 апреля 2016 Стачка, 2016, Ульяновск 73

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

74. Стачка 2016
ptsecurity.com
Спасибо!
Вопросы?
- Вопросы, Идеи, Уточнения
- А давайте попробуем <> ?!
- Хочу работать вместе!

75. Ищем
SDL/SSDL сообщество –
тех, кому интересна “жизнь
по SSDL”
Кто готов делиться
опытом – уже живет или в
процессе перехода на SDL
разработчиков на С#, QA,
фронтендеров,
аналитиков
в Новосибирск
bit.ly/PT_Novosibirsk_job
…и другие города тоже
www.ptsecurity.com/about/
vacancy
Минутка Рекламы
23 апреля 2016 Стачка, 2016, Ульяновск 76

76. Раздатка для Стачки
23 апреля 2016 Стачка, Ульяновск 77

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