Безопасность - критически важный элемент любого программного решения. Элемент, который, рано или поздно, но заставит вспомнить о себе. Скупой платит дважды, а в данном случае – минимум четырежды. Безопасность и качество кода – связаны напрямую. Поэтому положение дел и с тем и с другим редко находят достаточно хорошим даже в самых успешных проектах – всегда хочется бОльшего. А где-то бывает просто необходим качественный переход и точечными мерами кардинально ситуацию уже не исправить, нужен системный подход.
Вот почему наладить процесс обеспечения и повысить уровень зрелости безопасности разработки, повысить качество кода – хотят многие руководители и разработчики. Как это сделать системно и в согласии? Какие риски для одних, какие трудозатраты для других? И стоит ли овчинка выделки? Об этом и поговорим.
2016/05/10: загружена версия для оффлайна.
Data Luxury Protection - защита данных с удовольствием!
Построение процесса безопасной разработки - Стачка 2016
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
«Просто» разработка ПО
Жизненный Цикл
«Безопасная» разработка ПО
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 раз чем на стадии разработки
требований
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).
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
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.
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
75. Ищем
SDL/SSDL сообщество –
тех, кому интересна “жизнь
по SSDL”
Кто готов делиться
опытом – уже живет или в
процессе перехода на SDL
разработчиков на С#, QA,
фронтендеров,
аналитиков
в Новосибирск
bit.ly/PT_Novosibirsk_job
…и другие города тоже
www.ptsecurity.com/about/
vacancy
Минутка Рекламы
23 апреля 2016 Стачка, 2016, Ульяновск 76
77. Пара видео - как мы живем, работаем, отдыхаем )
23 апреля 2016 Стачка, Ульяновск 78
Backstage
Positive Technologies 13 лет!
https://youtu.be/1_zNxMHyCZk
Присоединяйтесь!
Будем работать по в
цикле безопасной
разработки вместе )
Hinweis der Redaktion
www.linkedin.com/in/boronin
Secure software is, by definition, designed with failure in mind. Secure software resists failure even when that failure is devoutly wished for by the opponent. Secure software is designed for the failure case as much as or more than the success case. Designers and implementers alike envision an opponent who can think.
CONCLUSIONS ON SOFTWARE QUALITYInspections + static analysis + formal testing > 99% efficient. (and lower costs and schedules by >20%, lower TCO by >45%)
Defect prevention + pre-test removal + formal test best overall
Quality excellence has ROI > $15 for each $1 spent
High quality benefits schedules, productivity, users!
Poor quality leads to cost and schedule overruns!
Basic software security training should cover foundational concepts such as:
Secure design, including the following topics:
Attack surface reduction
Defense in depth
Principle of least privilege
Secure defaults
Threat modeling, including the following topics:
Overview of threat modeling
Design implications of a threat model
Coding constraints based on a threat model
Secure coding, including the following topics:
Buffer overruns (for applications using C and C++)
Integer arithmetic errors (for applications using C and C++)
Cross-site scripting (for managed code and Web applications)
SQL injection (for managed code and Web applications)
Weak cryptography
Security testing, including the following topics:
Differences between security testing and functional testing
Risk assessment
Security testing methods
Privacy, including the following topics:
Types of privacy-sensitive data
Privacy design best practices
Risk assessment
Privacy development best practices
Privacy testing best practices
The preceding training establishes an adequate knowledge baseline for technical personnel. As time and resources permit, training in advanced concepts may be necessary. Examples include, but are not limited to, the following:
Advanced security design and architecture
Trusted user interface design
Security vulnerabilities in detail
Implementing custom threat mitigations
Кстати, про Тестирование безопасности и разницу с функциональным тестированием:
QA Eng In functional and performance testing, the expected results are documented before the test begins, and the quality assurance team looks at how well the expected results match the actual results
Security Experts In security testing, security analysts team is concerned only with unexpected results and testing for the unknown and looking for weaknesses. They are EXPERTS.
Команда разработки определяет лидеров и консультантов по темам безопасности
Назначается ответственный за безопасность
Ответственный проверяет план разработки продукта, рекомендует изменения или устанавливает дополнительные требования к безопасности продукта
Определить приоритет, процедуру отслеживания и исправления ошибок (bug tracking/job assignment system)
Слайд - справочный. Инструментов – миллион, показания для инструментария – индивидуальны. Подбирать нужно под себя осознанно.
Не если случится, а когда!
Обычно в ходе такой проверки выполняется изучение моделей рисков, запросов исключений, производительности и выходных данных различных инструментов на предмет соответствия ранее определенным контрольным условиям качества или панелям ошибок.
Советник по безопасности должен подтвердить (с помощью окончательной проверки безопасности или других данных), что группа проекта выполнила требования безопасности. Аналогично перед выпуском любого продукта, имеющего хотя бы один компонент с оценкой влияния на конфиденциальность, равной P1, советник по конфиденциальности проекта должен подтвердить, что группа проекта выполнила требования конфиденциальности. Кроме того, все релевантные данные должны быть заархивированы, что позволит выполнять обслуживание программного обеспечения после выпуска.
Организациям, разрабатывающим защищенные приложения, конечно же, требуются инструменты для проверки соответствия процессам Microsoft SDL. Доступ к централизованным данным разработки и тестирования помогает принимать решения во многих случаях, таких как окончательная проверка безопасности, обработка исключений требований SDL и аудиты безопасности. В процедуру проверки безопасности приложения вовлечен ряд различных процессов и действующих лиц.
Для отслеживания соответствия SDL следует использовать специально выделенное приложение, которое служит центральным хранилищем для всех артефактов процесса SDL, включая заметки по проектированию и реализации, модели рисков, переданные файлы журналов инструментов и другие данные аттестации процессов, а также дополнительные сведения.
[…]
Например, если группа разработчиков создает приложение управления процессами для работы в потенциально опасной среде, необходимо выделить время и ресурсы для создания и обслуживания процедуры отслеживания, что позволит субъектам безопасности и конфиденциальности организации, высшему руководству и соответствующим третьим сторонам (таким, как аудиторы соответствия или специалисты по оценке) выполнять объективный анализ. Иначе говоря, попытка сэкономить на процессе отслеживания неизбежно приведет к появлению проблем в будущем, обычно в аварийной ситуации. Необходимо создать надежные системы, которые помогут ответить на важные вопросы в критический момент.
The Software Security Framework
The table below shows the software security framework (SSF) used to organize the 112 BSIMM activities. There are 12 practices organized into four domains.
The four domains are:
Governance: Practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice.
Intelligence: Practices that result in collections of corporate knowledge used in carrying out software security activities throughout the organization. Collections include both proactive security guidance and organizational threat modeling.
SSDL Touchpoints: Practices associated with analysis and assurance of particular software development artifacts and processes. All software security methodologies include these practices.
Deployment: Practices that interface with traditional network security and software maintenance organizations. Software configuration, maintenance and other environment issues have direct impact on software security.
В 2008-м году МакГроу решил проанализировать опыт Microsoft и нескольких десятков других компаний, которые занимались безопасным программированием и внедряли в свой процесс разработки отдельные инициативы по повышению защищенности ПО. Результатом работы МакГроу стал проект The Building Security In Maturity Model (BSIMM). На сегодняшний день опубликована уже 6я версия BSIMM, вобравшая опыт 78 инициатив по безопасной разработке. В текущей версии BSIMM6 описано 112 активностей, повышающих защищенности ПО, и по каждой из активностей проект BSIMM предлагает любому желающему оценивать себя и свою зрелость в области SDL.
Применимость практик вслепую не работает:
Open-source – код которым мы не владеем
Тысячи вебстраниц без валидации – ест ли альтернатива WAF?
Старое большое приложение – pen testing
Начинаем с нуля – моделирование угроз
м
From McGraw book, see reference at the end:
A well-architected vision and plan based on industry standards and best practices is essential to a successful software security program. Throughout this book, I have covered a number of software security touchpoints that are process agnostic and can thus be adopted regardless of an organization's software development methodology. Because every organization is different, a software security improvement program plan that involves the adoption of these best practices must be tailored to the given business and technical situation. For example, organizations that focus more attention on code than on software architecture will likely benefit more quickly from the adoption of static analysis based code review than they will from architectural analysis. First things first.
A well-defined roadmap lays out the specifics of how best to deploy software security best practices given a particular organization's approach to building (and even buying and integrating) software. Explicit strategic objectives drive prioritization of change to ensure that only those program initiatives that will provide the biggest and/or quickest return are addressed first. Executing such a roadmap is carried out in five basic steps.
Build a plan that is tailored for you: Recognize the potential dependencies between various initiatives, and plan accordingly. Focus on developing the building blocks of change. Know how your organization develops software, and determine the best way to gradually adjust what you're doing to fold in security best practices.
Roll out individual best practice initiatives carefully: Establish champions to drive and take ownership of each initiative. Coach and mentor as needed. Run a successful pilot in part of your company before you attempt to spread best practices far and wide.
Train your people: Developers and architects remain blithely unaware of security and the critical role that they play in it. Training and mentorship is a necessity.
Establish a metrics program: Apply a business-driven metrics scorecard to monitor progress and assess success. Metrics and measures (even relative metrics based on risk over time [see Chapter 2] or business metrics such as maintenance budget) are critical to making progress in any large organization.
Establish and sustain a continuous improvement capability: Create a situation in which continuous improvement can be sustained by measuring results and periodically refocusing attention on the weakest aspects of your software security program.
Establishing a Metrics Program
Measures are numeric values assigned to a given artifact, software product, or process. A metric is a combination of two or more measures that together provide some business-relevant meaning. For example, when considered separately "lines of code" and "number of security breaches" are two distinct measures that provide very little business meaning because there is no context for their values. A metric made up as "number of breaches / lines of code" provides a more interesting relative value.
Ideally, metrics and measures will focus on four primary areas: project, process, product, and organization. The first three are specific to a given artifact or activity in a software development effort, while the purpose of the latter is to determine trends across the three other areas.
Из практики
Подробнее смотри первоисточник – книга McGraw.
DFD (Data Flow Diagrams — диаграммы потоков данных) + STRIDE =
Spoofing (подмена субъекта)
Tampering (нарушение целостности)
Repudiation (отказ от авторства)
Information disclosure (нарушение конфиденциальности)
Denial of service (отказ в обслуживании)
Elevation of privilege (повышение привилегий)