Downloaded 28 times
![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](https://image.slidesharecdn.com/boronin-160510102605/85/2016-13-320.jpg)
Uploaded byValery Boronin
Построение процесса безопасной разработки - Стачка 2016
Документ освещает тему безопасной разработки программного обеспечения, подчеркивая важность безопасности для разработчиков и их руководителей. Рассматриваются такие аспекты, как причины необходимости безопасности, процессы разработки, методы тестирования и управление рисками, а также роль SDL (Security Development Lifecycle) в создании защищенных приложений. Автор делится опытом и статистикой по уязвимостям, подчеркивая, что внедрение безопасных практик на этапе разработки значительно снижает риск и затраты на устранение последствий инцидентов.
More Related Content
Similar to Построение процесса безопасной разработки - Стачка 2016
Построение процесса безопасной разработки - Стачка 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 «Просто» разработка ПО Жизненный Цикл «Безопасная» разработка ПО
- 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 ModelingTool (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 SecurityRequirements) 2. 3rd Party Security 3. Проектирование (Secure Design) 4. Реализация (Secure Coding) 5. Оценка (Secure Analysis) 6. Тестирование (Vulnerability Testing) Cisco SDL – так их, оказывается, много и разных?! 23 апреля 2016 Стачка, Ульяновск 47
- 48. Cisco SDL MicrosoftSDL 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 MaturityModel (SAMM) 23 апреля 2016 Стачка, Ульяновск 49 модели Software Assurance Maturity Model (SAMM) и Building Security In Maturity Model (BSIMM) для оценки текущего уровня зрелости, а также в качестве методологической основы для построения процессов обеспечения безопасности разработки. В рамках предлагаемых методик выделяются четыре основных направления развития процессов управления безопасностью разработки или бизнес-функций: корпоративное управление (Governance), разработка (Construction), контроль (Verification), развертывание и эксплуатация (Deployment).
- 50. Building Security InMaturity Model (BSIMM) 23 апреля 2016 Стачка, Ульяновск 50
- 51. The Building SecurityIn 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 ThreatModeling на сайте 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 Присоединяйтесь! Будем работать по в цикле безопасной разработки вместе )
Editor's Notes
- #3 www.linkedin.com/in/boronin
- #10 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.
- #24 CONCLUSIONS ON SOFTWARE QUALITYInspections + static analysis + formal testing &gt; 99% efficient. (and lower costs and schedules by &gt;20%, lower TCO by &gt;45%) Defect prevention + pre-test removal + formal test best overall Quality excellence has ROI &gt; $15 for each $1 spent High quality benefits schedules, productivity, users! Poor quality leads to cost and schedule overruns!
- #35 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.
- #36 Команда разработки определяет лидеров и консультантов по темам безопасности Назначается ответственный за безопасность Ответственный проверяет план разработки продукта, рекомендует изменения или устанавливает дополнительные требования к безопасности продукта Определить приоритет, процедуру отслеживания и исправления ошибок (bug tracking/job assignment system)
- #41 Слайд - справочный. Инструментов – миллион, показания для инструментария – индивидуальны. Подбирать нужно под себя осознанно.
- #42 Не если случится, а когда!
- #43 Обычно в ходе такой проверки выполняется изучение моделей рисков, запросов исключений, производительности и выходных данных различных инструментов на предмет соответствия ранее определенным контрольным условиям качества или панелям ошибок.
- #44 Советник по безопасности должен подтвердить (с помощью окончательной проверки безопасности или других данных), что группа проекта выполнила требования безопасности. Аналогично перед выпуском любого продукта, имеющего хотя бы один компонент с оценкой влияния на конфиденциальность, равной P1, советник по конфиденциальности проекта должен подтвердить, что группа проекта выполнила требования конфиденциальности. Кроме того, все релевантные данные должны быть заархивированы, что позволит выполнять обслуживание программного обеспечения после выпуска.
- #47 Организациям, разрабатывающим защищенные приложения, конечно же, требуются инструменты для проверки соответствия процессам Microsoft SDL. Доступ к централизованным данным разработки и тестирования помогает принимать решения во многих случаях, таких как окончательная проверка безопасности, обработка исключений требований SDL и аудиты безопасности. В процедуру проверки безопасности приложения вовлечен ряд различных процессов и действующих лиц. Для отслеживания соответствия SDL следует использовать специально выделенное приложение, которое служит центральным хранилищем для всех артефактов процесса SDL, включая заметки по проектированию и реализации, модели рисков, переданные файлы журналов инструментов и другие данные аттестации процессов, а также дополнительные сведения. […] Например, если группа разработчиков создает приложение управления процессами для работы в потенциально опасной среде, необходимо выделить время и ресурсы для создания и обслуживания процедуры отслеживания, что позволит субъектам безопасности и конфиденциальности организации, высшему руководству и соответствующим третьим сторонам (таким, как аудиторы соответствия или специалисты по оценке) выполнять объективный анализ. Иначе говоря, попытка сэкономить на процессе отслеживания неизбежно приведет к появлению проблем в будущем, обычно в аварийной ситуации. Необходимо создать надежные системы, которые помогут ответить на важные вопросы в критический момент.
- #51 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.
- #52 В 2008-м году МакГроу решил проанализировать опыт Microsoft и нескольких десятков других компаний, которые занимались безопасным программированием и внедряли в свой процесс разработки отдельные инициативы по повышению защищенности ПО. Результатом работы МакГроу стал проект The Building Security In Maturity Model (BSIMM). На сегодняшний день опубликована уже 6я версия BSIMM, вобравшая опыт 78 инициатив по безопасной разработке. В текущей версии BSIMM6 описано 112 активностей, повышающих защищенности ПО, и по каждой из активностей проект BSIMM предлагает любому желающему оценивать себя и свою зрелость в области SDL.
- #60 Применимость практик вслепую не работает: Open-source – код которым мы не владеем Тысячи вебстраниц без валидации – ест ли альтернатива WAF? Старое большое приложение – pen testing Начинаем с нуля – моделирование угроз
- #61 м
- #63 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&apos;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&apos;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&apos;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 &quot;lines of code&quot; and &quot;number of security breaches&quot; are two distinct measures that provide very little business meaning because there is no context for their values. A metric made up as &quot;number of breaches / lines of code&quot; 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.
- #65 Из практики
- #66 Подробнее смотри первоисточник – книга McGraw.
- #75 DFD (Data Flow Diagrams — диаграммы потоков данных) + STRIDE = Spoofing (подмена субъекта) Tampering (нарушение целостности) Repudiation (отказ от авторства) Information disclosure (нарушение конфиденциальности) Denial of service (отказ в обслуживании) Elevation of privilege (повышение привилегий)