SlideShare a Scribd company logo
Заголовок
ptsecurity.com
Построение процесса
безопасной разработки
Что это означает на практике
для разработчиков и их руководителей?
Валерий Боронин
ЗаголовокВалерий Боронин
• В разработке и R&D более 20 лет
• Начинал еще под Windows 3.1
• Достиг определенных высот разработчиком
режима ядра под Windows (до 2009)
• В безопасности с прошлого тысячелетия ;-)
• Работал CTO небольшой компании (30+ человек)
• Директором по исследованиям большой
(«Лаборатория Касперского», 2500+ человек, 2009–2014)
• Сейчас отвечаю за направление безопасной разработки
(SDL / SSDL) в Позитиве
• Мы с командой создаем новый продукт
по автоматизации безопасной разработки
Заголовок
О чем поговорим в начале?
• Зачем нужна безопасность?
• Что такое защищенное приложение?
• Почему ПО небезопасно?
• Разработчики и безопасность
• Что такое SDL/SSDL = безопасная разработка?
• Зачем нужна?
• Какие проблемы решает?
ЗаголовокЗачем нужна безопасность вашим заказчикам?
Отраслевые
требования
Государственное
регулирование
Доступность
бизнеса
Капитализация
Статистика
нарушений
Требования
заказчика
Предыдущий
плохой опыт
ЗаголовокПоследствия проблем с безопасностью
Доверие
Деньги
Данные
утекшие
Время
на восстановление
Ущерб
по инциденту
Заказчики
Репутация
Безопасность на стыке с надежностью:
у вас 5 компонентов в e-commerce
приложении с 98% uptime каждый?
Ожидайте 150 мин простоя в день! *
*Источник: книга Gary McGraw (https://www.garymcgraw.com/)
ЗаголовокЗачем? Наши реалии
Большинство
обнаруживаемых
уязвимостей –
типовые,
общеизвестные,
хорошо описанные.
Статистика по распределению уязвимостей веб-приложений за 2015 год
Источник: по данным аналитического центра Positive Technologies (серым цветом – 2014 год)
Заголовок
59%
80%
100% 100%
65%
20%
Черный/серый ящик Белый ящик
Высокий Средний Низкий
Почему мы об этом говорим?
Источник: по данным аналитического центра Positive Technologies за 2015 год
56%
69%
88%
100% 100% 100%
44%
38%
75%
0%
20%
40%
60%
80%
100%
120%
PHP Java Другие
Высокий Средний Низкий
ЗаголовокЧто такое защищенное ПО?
• Обычно подразумевается:
• Безопасная разработка
• Контроль целостности
• Правильная эксплуатация
• …а по версии ФСТЭК?
• + документация и конфигурации
• + инфраструктура среды разработки
• + люди
Хорошо работает то, что хорошо управляется © В. В. Путин
ЗаголовокЧто такое защищенное ПО?
Быть на шаг впереди,
в постоянном ожидании сбоя.
Работать даже тогда, когда твоего сбоя
яростно ожидает оппонент.
Защищенное ПО гораздо больше
вкладывает в учет проблемных кейсов,
чем не имеющих проблем.
На шаг впереди – вот девиз
проектировщиков и других
безопасных разработчиков.
Источник: вступительное слово
к замечательной книге Gary McGraw (первопроходца в SDL)
ЗаголовокПочему ПО небезопасно?
1. Ломать – не строить!
2. Безопасность – ассиметрична
3. В основе многих классов уязвимостей –
проблемы с дизайном (design issues)
или бизнес-логикой (business logic issues)
4. Инструменты для тестирования
на безопасность продаются как решение проблемы
небезопасного ПО (таблетки не существует)
5. Защищенное ПО – дуально.
Надо атаковать и защищаться, эксплуатировать
и проектировать, ломать и строить –
одновременно
I know when I’m writing code I’m not thinking
about evil, I’m just trying to think about
functionality © Scott Hanselman
Почему простого цикла разработки или
анализа-исправления кода недостаточно?
Полный разбор в блестящем анализе
от Геннадия Махметова
ЗаголовокЧто же делать?
• Нужно
• Проактивное проектирование
+
• Exploit-driven тестирование
+
• Все это на базе управления рисками
Три основания безопасной /
защищенной разработки:
управление рисками,
лучшие практики
и Знание
Program testing can be used to show the
presence of defects, but never their
absence © Dijkstra
ЗаголовокРазработчики и безопасность
Стандартные отговорки:
• Сроки горят (время)
• Нет ресурсов (бюджета, экспертизы,
инструментов, …) на обеспечение
безопасных практик
• Мы стартап – нам нужно быстрее
стать популярными и заработать
много денег
• …
Shortage of skill or shortage
of discipline?
Знать мало – надо
применять!
ЗаголовокЦикл [безопасной] разработки
• 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
ЗаголовокSDLC vs SDL / SSDL
SDLC SSDL
«Просто» разработка ПО
Жизненный Цикл
«Безопасная» разработка ПО
ЗаголовокЗачем нужен SDL? Взгляд руководителя
• Риски и минимизация ущерба
• Стоимость разработки
• Соответствие требованиям
ЗаголовокЗачем нужен SDL? Взгляд руководителя
• Риски и минимизация ущерба
• Стоимость разработки
• Соответствие требованиям
ЗаголовокЗачем нужен SDL? Взгляд руководителя
• Риски и минимизация ущерба
• Стоимость разработки
• Соответствие требованиям
ЗаголовокСтоимость разработки
Источник: книга Gary McGraw, 2008
ЗаголовокСтоимость разработки
NIST: исправлять ошибки после выпуска дороже
в 30 раз, чем на стадии разработки дизайна
ЗаголовокСтоимость разработки
Источник: HP ‘The New Attack Vector: Applications Reduce risk
and cost by designing in security.’
Исправлять ошибки после выпуска дороже в 30–100 раз,
чем на стадии разработки требований
ЗаголовокСтоимость разработки
ЗаголовокНо почему четырежды?
Исследование Aberdeen:
• Предотвращение одной уязвимости почти полностью покрывает годовые затраты
на повышение безопасности разработки
• Предотвратить проблему с безопасностью в 4 раза дешевле,
чем разбираться с ее последствиями
Исследование Forrester:
• Разработка безопасного ПО еще не стала широко распространенной практикой
• Компании, применяющие методы SDL, демонстрируют
гораздо более быстрый возврат инвестиций
BSIMM (позже) & McGrow (в книге) еще более категоричны:
• Разрыв между теми, кто применяет, и теми, кто ждет, нарастает с ускорением
• Пугают тем, что скоро HR начнут массово искать SDL-certified людей ;-)
• В результате не перестроившиеся начнут вылетать с рынка
ЗаголовокФакты из мира качества
Inspections
+ static
analysis
+ formal
testing > 99%
efficient
Quality
excellence
has ROI > $15
for each $1
spent
Источник: http://namcookanalytics.com/software-quality-survey-state-art/
ЗаголовокБезопасность – это дорого (1 / 2)
Источник: http://namcookanalytics.com/software-quality-survey-state-art/
ЗаголовокБезопасность – это дорого (2 / 2)
Источник: http://namcookanalytics.com/software-quality-survey-state-art/
ЗаголовокБезопасность – трудно найти и трудно исправить
HIGHLIGHTS FROM
THE 2015 WORLD SW
QUALITY REPORT
…
Security is the most
pressing concern
Источник: http://namcookanalytics.com/software-quality-survey-state-art/
ЗаголовокЗачем нужен SDL? Взгляд разработчика
1. Качественный код
(безопасное и качественное ПО)
2. Больше времени на работу
(и собственное развитие!)
3. Проактивность Реактивность
(быть причиной)
…Все правильно сделал! 
Заголовок
Минуточку! Попрошу поподробнее!
• Применимость
• Когда разработка становится безопасной?
• Роли, ответственность, квалиф. требования
• Обязательные активности (16 практик)
• Дополнительные активности
• О чем еще стоит упомянуть?
• Процедура проверки безопасности приложения
• Так этих SDL’ей… много и они разные?!
Что же такое SDL? Из чего состоит?
ЗаголовокSecurity Development Lifecycle (SDL) – must have
Обучение
• Начальное
обучение
безопасности
Требования
• Определение
требований
по безопасности
• Оценка рисков
• Create Quality
Gates/Bug Bars
Дизайн
• Установить
требования к
дизайну
• Анализ
поверхности
атаки
• Моделирование
угроз
Реализация
• Выбор
инструментов
• Блокирование
запрещенных
функций
• Статический
анализ
Проверка
• Динамический
анализ
• Fuzz Testing
• Проверка
поверхности
атаки
Выпуск
• План
реагирования
на инциденты
• Финальный
анализ
безопасности
• Доверенный
выпуск
Реагирование
• Выполнение
плана
реагирования
http://www.microsoft.com/security/sdl/default.aspx
  
Технология и процессОбучение Ответственность
Education, accountability, and clear objectives are critical components to any successful software security initiative © McGraw
ЗаголовокЧто такой упрощенный SDL?
• Модель помогает определить
текущий уровень зрелости компании
и разработать план действий
по внедрению соответствующих
процессов для реализации
полноценного цикла
безопасной разработки
• Так когда разработка
становится безопасной?  Зрелость Организации
ЗаголовокSDL. Применимость
Ваше приложение:
• Работает в бизнес- или корпоративном окружении?
• Обрабатывает / хранит персональные данные
или sensitive информацию?
• Взаимодействует по сети / другим каналам
передачи информации?
• Практика показывает, что сложно
найти приложение, которому не показан SDL
ЗаголовокSDL. Люди: формализация ролей и обязанностей
•Советник по безопасности /
конфиденциальности (снаружи)
• Аудитор (подчиненная роль)
• Эксперт (подчиненная роль)
• Можно совмещать аудитора с экспертом
• Советников тоже можно совмещать
•Руководители групп по безопасности /
конфиденциальности (изнутри)
• Отвечают за координацию и отслеживание
вопросов безопасности на проекте + сообщают
состояние Советнику и другим ЗЛ
• Можно совмещать роли security и privacy champions
ЗаголовокSDL. Фаза 1 – Обучение
1. Все задействованные сотрудники
в технических ролях (Devs, QA, PMs)
2. Не реже 1 раза в год
3. Знания для выполнения остальных фаз
+ как работаем по новому процессу
• Обследовать подготовленность организации
по темам безопасности и защиты данных (privacy)
• При необходимости создать стандартные курсы обучения
Безопасность –
дело каждого!
Разработать критерии качества программы обучения
Содержимое должно покрывать темы со следующего слайда
Определить частоту тренингов
Разработчик должен пройти не менее Х тренингов в год
Определить минимальный приемлемый порог тренингов в группе разработки
75% техперсонала должны пройти базовые тренинги до выпуска беты
ЗаголовокSDL. Фаза 1 – Обучение. Чему учить?
1. Безопасный дизайн
• Уменьшение поверхности атаки
• Наименьшие привилегии
• Многослойная защита
• Безопасные настройки по умолчанию
2. Моделирование угроз
3. Безопасное кодирование
(переполнение буфера, XSS,
SQL-инъекции, криптография)
4. Тестирование безопасности
• Разница с функциональным тестированием
• Оценка рисков
• Методы тестирования безопасности
Безопасность –
дело каждого!
• 5. Защита информации / Privacy /
Соответствие требованиям
• Персональные данные, ФЗ 152
и отраслевые стандарты
• Трансграничная передача данных
• Обработка, хранение и т. п.
чувствительных данных – ФЗ №242
• 6. …
• …
• Trusted user interface design
• …
ЗаголовокSDL Фаза 2 – Требования
Возможность заложить
безопасный фундамент для проекта
• Определение требований
по безопасности (разово)
SDL Practice #2: Establish Security
and Privacy Requirements
• Определить и задокументировать
порог отбраковки продукта по ошибкам,
связанным с безопасностью
и защитой данных (разово)
SDL Practice #3: Create Quality Gates/Bug Bars
• Оценка рисков SDL Practice #4: Perform Security
and Privacy Risk Assessments (разово)
ЗаголовокSDL Фаза 3 – Проектирование
1. Архитектурные требования (разово)
• Определить и задокументировать архитектуру безопасности
и идентифицировать критические компоненты безопасности
2. Анализ / сокращение поверхности атаки (разово)
• Задокументировать поверхность атаки продукта
• Ограничить ее установками по умолчанию
3. Моделирование угроз
• Определить угрозы и меры снижения угроз
• Систематический пересмотр свойств продукта и его архитектуры
с точки зрения безопасности
• Определить критерии выпуска обновления продукта в связи
с изменением в безопасности продукта
ЗаголовокSDL Threat Modeling Tool (TMT) – справочно
• Формализует и упрощает моделирование угроз так,
чтобы им мог заниматься архитектор
Обучает созданию диаграмм угроз
Анализ угроз и мер защиты
Интеграция с багтрекером
Отчеты по угрозам и уязвимостям
ЗаголовокSDL. Фаза 4 – Реализация
Разработка кода и ревью процессов, документации
и инструментов, необходимых для безопасного
развертывания и эксплуатации разрабатываемого продукта
• Использование утвержденных / доверенных
средств и их аналогов
• Практики безопасного программирования
• Статический анализ кода
Конкретно:
Поиск случаев использования запрещенных API
Применение механизмов защиты предоставляемых ОС
Использование безопасных версий библиотек и фреймворков
Соблюдение специфических требований безопасности (XSS, SQL-инъекции…)
ЗаголовокSDL. Фаза 5 – Проверка (Тестирование)
Начните тестирование
как можно раньше. В идеале –
как только появился готовый
для этого код
• Динамический анализ
• Фаззинг – файлами, вводом данных
в интерфейсные элементы
и код сетевой подсистемы
• Повторно проверьте модели угроз,
риски, поверхность атаки.
Все ли вы учли?
• Начните планирование процесса реагирования на обнаружение уязвимостей в выпущенном продукте – см. следующую стадию
• При необходимости выполнить security push (с каждым разом все реже)
• Не является заменой работе над безопасностью в процессе разработки
• Ревью кода
• Тестирование на проникновение
• Ревью дизайна и архитектуры в свете вновь обнаруженных угроз
ЗаголовокSDL. Фаза 5 – Проверка: инструменты (справочно)
BinScope Binary Analyzer
• Убедиться что SDL соблюден
при компиляции и сборке
MiniFuzz File Fuzzer
• !exploitable в WinDbg
• DAST
RegexFuzer
• DAST
Attack Surface Analyzer
• Анализ снимков системы
• Измеряет потенциальную
поверхность атаки на приложение и ОС
AppVerifier
• Динамический анализ системы
MSF Agile + SDL шаблоны для TFS
• Автоматически создает процессы
соблюдения SDL в момент создания нового
спринта или выполнения check in
• Контролирует выполнение всех
необходимых процессов безопасности
CMMI Шаблоны SDL для TFS
• SDL требования как задачи
• SDL-based check-in policies
• Создание отчета Final Security Review
• Интеграция с инструментами
сторонних производителей
• Библиотека пошаговых указаний SDL how-to
ЗаголовокSDL. Фаза 6 – Выпуск: план реагирования
• Создать политики поддержки продукта
• Создать план реагирования на инциденты безопасности
• Группа инженерной поддержки: ресурсы внутри
и снаружи организации для адекватной реакции
на обнаружение уязвимостей и защиту от атак
• Контактные данные лиц, доступных 24x7x365
• 3–5 инженеров
• 3–5 специалистов из маркетинга
• 1–2 менеджеров верхнего уровня
• Обратите внимание на:
• Необходимость выпуска экстренных обновлений
вашего продукта из-за уязвимостей в унаследованном коде
• От других групп в той же организации
• Сторонних производителей
• Включенном в ваш продукт
• Лицензионные условия, возможность вносить изменения,
имена файлов, версии, контактные данные и т. п.
• Может быть необходимость обновлять продукт
после обновления ОС и т. п. http://www.microsoft.com/security/msrc/whatwedo/responding.aspx
Watch
Alert and Mobilize
Resources
Assess and
Stabilize
Resolve
Reporting
Analysis and Mitigation
Create Fix
Update Models
Test Fix
Выпуск
Lessons Learned
Provide Guidance
ЗаголовокSDL Фаза 6 – Выпуск: Final Security Review (FSR)
Проверить продукт на соответствие требованиям SDL и отсутствие известных
уязвимостей.
Получаем независимое заключение готовности продукта к выпуску.
FSR не является:
• Тестом на проникновение. Запрещено ломать и обновлять продукт
• Первой проверкой безопасности продукта
• Процессом финальной подписи продукта и отправки его в тираж
FSR должен обязательно включать три возможных результата окончательной
проверки безопасности:
1. Можно выпускать
2. Можно выпускать с ограничениями (и есть план по их душу)
3. FSR с эскалацией (на руководство Компании)
Ключевая концепция: эта фаза не используется как точка для завершения всех задач,
пропущенных на предыдущих стадиях
ЗаголовокSDL. Фаза 6 – Выпуск: заверить релиз и – в Архив
• План реагирования на инциденты безопасности создан
• Документация для клиентов обновлена
• Создан централизованный архив всего, что поможет
• С сервисным обслуживанием релиза
• Снизить стоимость поддержки
в долгосрочной перспективе
• Обязательно включить в архив
• Исходники
• Приватные отладочные символы
• Модели угроз
• Документацию –
техническую и пользовательскую
• Планы реагирования
• Лицензионные и прочие Servicing Terms
для используемого стороннего ПО
ЗаголовокSDL. Фаза 7 – Реагирование на инциденты
• Инцидент случился? Идем по заранее созданному плану
• Выполняем активности по плану
реагирования на инциденты безопасности
• Выпускаем обновления в соответствии
с графиком релизов
• Пересчитываем риски
• Информируем клиентов
• Публикуем информацию
• Выгоды планового реагирования
• Понятно, что происходит
• Есть ответственные
• Удовлетворенность клиента растет
• Собираем данные для будущих разработок
• Проводим тренинги
Не если,
а когда!
ЗаголовокSDL. Дополнительные меры – что бы сделать еще?
1. Сode review глазом
• Важные компоненты
• Где храним, обрабатываем,
передаем sensitive данные
• Криптография
2. Анализ уязвимостей схожих
приложений (конкурентов)
3. Тесты на проникновение (но сделать до FSR!)
Улучшаем процесс дальше:
1. Анализ первопричин Исследование причин появления найденных уязвимостей (из-за чего она
возникла – человеческая ошибка? Несовершенство процесса? Ошибка автоматизации?)
2. Регулярное обновление процесса
ЗаголовокSDL. Процедура проверки безопасности приложения
• Специальные меры по хранению артефактов
через приложение со строгим
контролем доступа (RBAC)
• Руководители групп безопасности
и конфиденциальности обеспечивают
ввод данных и их корректность
• Их используют Советники,
обеспечивая среду для FSR и для
анализа, а также подтверждения
выполнения всех требований
Обязательно хранить:
• Требования безопасности
и конфиденциальности для организации
• Функц. и тех. требования для разрабатываемого приложения
• Рабочий контекст приложения (Ex: процедура отслеживания)
ЗаголовокCisco SDL – так их, оказывается, много и они разные?!
1. Требования
(Product Security Requirements)
2. 3rd Party Security
3. Проектирование
(Secure Design)
4. Реализация
(Secure Coding)
5. Оценка
(Secure Analysis)
6. Тестирование
(Vulnerability Testing)
ЗаголовокСравнение SDL – справочно
Cisco SDL Microsoft SDL PA-DSS SDL РС БР ИББС-2.6-2014)
Обучение
разработчиков
Secure Design, Secure Coding Training Обучение -
Отслеживание
уязвимостей
3rd Party Security Implementation (частично) Выявление уязвимостей Эксплуатация
Определение
требований к ИБ
Product Security Requirements Requirements Проектирование Проектирование
Создание модели
угроз
Secure Design Design Оценка рисков
Разработка технического задания
(рекомендательно)
Практики безопасной
разработки
Secure Coding Implementation Создание -
Анализ кода Secure Analysis Implementation Анализ кода
Создание и тестирование
(рекомендательно)
Тестирование
безопасности
Vulnerability Testing Verification, Release
Тестирование
безопасности
Создание и тестирование
Выпуск релиза - Release Выпуск Прием и ввод в действие
Поддержка - Response Поддержка Сопровождение и модернизация
Вывод из
эксплуатации
- Снятие с эксплуатации
Источник: http://www.slideshare.net/arekusux/sdl-38135128
ЗаголовокSoftware Assurance Maturity Model (SAMM)
Модели Software Assurance Maturity Model (SAMM) и Building Security In Maturity Model (BSIMM)
для оценки текущего уровня зрелости, а также в качестве методологической основы для построения
процессов обеспечения безопасности разработки.
В рамках предлагаемых методик выделяются четыре основных направления развития процессов управления
безопасностью разработки или бизнес-функций: корпоративное управление (Governance), разработка
(Construction), контроль (Verification), развертывание и эксплуатация (Deployment).
ЗаголовокBuilding Security In Maturity Model (BSIMM)
ЗаголовокThe Building Security In Maturity Model (BSIMM)
Заголовок
Практические выводы
• Основные заблуждения про SDL – снимаем
• C чего начинать, в каком порядке?
• Disclaimer – о чем обязан предупредить
• C чем будут трудности у руководителя
• Предостережения разработчику
• Как преодолевать (тезисно и справочно)
• Знание – Сила! И другие полезности
Что важно, что забрать с собой
ЗаголовокСнимаем основные заблуждения об SDL
• SDL независим от платформы и языка разработки
• SDL подходит для разных сценариев разработки включая
бизнес-приложения и онлайн-сервисы
• SDL применим к разным методологиям разработки,
таким как водопад и agile
• Успешная реализация SDL предполагает автоматизацию
с помощью инструментов. Вы можете использовать
инструменты от других компаний
• SDL подходит организациям любого размера.
От разработчика-одиночки до огромных корпораций
ЗаголовокПочему независимы от процессов и методологий?
Потому что привязка идет к артефактам!
ЗаголовокПро автоматизацию
Качество и полнота выходных данных, полученных на каждом этапе / фазе, очень
важны. The SDL process does benefit from investments in effective tools & automation
but the real value lies in comprehensive & accurate results.
ЗаголовокВнедрение SDL – вариант от MSFT SDL Team, 2014
ЗаголовокВнедрение SDL – еще вариант
1. Обучение
2. Практики безопасного программирования
3. Тестирование безопасности и анализ кода
4. Процедуры выпуска и поддержки
5. Отслеживание уязвимостей, реестр ПО
6. Формальное определение требований к ИБ
7. Планы реагирования на инциденты
8. Моделирование угроз, анализ поверхности атак
9. Внешний анализ
ЗаголовокДобавь безопасность в твой процесс разработки!
ЗаголовокНе делай то, что делает 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.
Заголовок«Стандартные» затыки – менеджерам на заметку
Не надо:
• Слишком полагаться на тестирование на поздних этапах цикла
• Управлять без измерений
• Обучать, не оценив
• Начинать без достаточной поддержки руководства
• Политические риски
• Бюджетные риски
• Стандартные для дисциплины Управление Изменениями
(организационными, в частности) – у нас максимум сложности: люди,
процессы, технологии
Обучение, ответственность и ясные цели – ключевые компоненты успеха
любой программы по безопасности
Заголовок3 предостережения – разработчикам
• Не надо думать о безопасности ПО как о проблемах кодирования.
McGraw метко называет это явление «парад багов»
• Неверно убеждение, что software security про то, как грамотно адаптировать
или использовать различные фичи или соглашения по безопасности.
Software security скорее про страховку, чем про фичи / функциональность
• Последнее предупреждение – не полагайтесь чересчур на чеклисты. Тот
же STRIDE в моделировании угроз. Чеклисты устаревают без обновления
по результатам открытий и не всегда полны
Основанный на фичах подход к безопасности зовут иногда ‘cookbook’ approach. Конечно,
поможет с рецептом, но просто чтение книги без включения плиты и пробы блюда вряд ли сделает из
вас хорошего повара.
Опыт – самый могущественный учитель.
ЗаголовокСтроим успешную программу по безопасности
• Сделай план под себя: выявляй зависимости и планируй. Пошаговые изменения – см.
дальше. Знай, как у тебя все работает, и ищи грамотный путь улучшить с использованием
лучших практик
• Выкатывай отдельные инициативы аккуратно: найди чемпиона для каждой и надели
ответственностью. Не оставляй без помощи – коучинг и наставничество. Пилоты
и прототипы – не надо на всех сразу накатывать сырое
• Обучай людей: разработчики и архитекторы могут не подозревать, как много тут от них
зависит. Обучение и воспитание
• Заложи основу метрикам: измеряй и оценивай прогресс. Метрики (в т. ч. относительно
себя прошлого и по бизнес-показателям) и измерения – без них никуда в любой большой
организации. В идеале надо накрыть четыре зоны: project, process, product and
organization. Первые три вокруг artifact or activity в разработке, четвертая, чтобы
определять тренды вокруг первых трех
• Установи и поддерживай способность к постоянным изменениям: создавай условия
путем постоянных измерений и оценки результатов, периодически переводя внимание
на отстающие аспекты своей программы повышения уровня безопасной разработки
ЗаголовокРекомендации от первопроходцев SDL
• Перестать кровоточить / Stop the bleeding
• SAST или переход на процесс анализа рисков
• Собери все, что назрело / Harvest the low-hanging fruit
• Хороший барометр, готова ли организация меняться реально
• Заложи основание / Establish a foundation
• Создай контроль изменений / Creating change control programs
• Построй анализ первопричин / Building root-cause analysis function
• Создай контур обратной связи / Setting up critical feedback loop
• Усиляй сильные качества / Craft core competencies
• Развивай то, что дает различия / Develop differentiators
• Строй все, что осталось / Build out nice-to-haves
ЗаголовокДля мастодонтов это может выглядеть так: PDCA
Первая волна (первая фаза) проведение инвентаризации,
оценки и анализа текущего уровня зрелости разработки
с точки зрения безопасности. Внедрение или повышение уровня базовых практик безопасности.
Создание рабочей группы безопасности приложений. Целевое обучение участников группы.
Подготовка плана повышения уровня зрелости разработки с точки зрения ИБ.
Вторая волна (вторая и третья фазы) – реализация плана повышения уровня зрелости разработки
с точки зрения ИБ. В рамках второй фазы проводятся основные активности, осуществляется
внедрение основных технических и организационных механизмов, разработка необходимой
документации. Проводится массовое обучение сотрудников практикам безопасной разработки
и приемам использования внедряемых инструментов, разработчикатываются метрики оценки
практик безопасности.
Третья фаза позволяет оценить успешность мероприятий второй фазы, исправить явные недочеты
и подготовить план повышения уровня зрелости для третей волны.
Третья волна (четвертая и пятая фазы) – в рамках третьей волны реализуется план повышения
уровня зрелости с учетом опыта третьей фазы. Также внедряются дополнительные организационные
и технические механизмы, необходимость которых была выявлена в ходе реализации второй
и третьей фазы. В рамках пятой фазы проводится сопровождение внедренных практик безопасности
и оценка эффективности текущего уровня зрелости.
Оценочная продолжительность каждой из фаз – 6 месяцев.
PDCA = Plan – Do – Check - Act
ЗаголовокЗнание – Сила. Как можно организовать?
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.
Заголовок
ptsecurity.com
Выгоды и выводы
• Для разработчиков
• Для руководителей
ЗаголовокВыгоды SDL / SSDL для разработчиков
1. Меньше времени на переделывание и отладку
2. Меньше времени на тестирование
3. Меньше времени на поддержку и проще развитие
4. Отлов проблем как можно раньше
5. Избегаем повторяющихся security issues
6. Избегаем несогласованных уровней безопасности
7. Повышаем экспертизу и опыт в безопасности
8. Выше продуктивность + чаще укладываемся в сроки
1. Качественный код
2. Больше времени
на работу и развитие
3. Проактивность
ЗаголовокВыгоды SDL / SSDL для руководителей
Более защищенная, безопасная и надежная разработка, которая:
• Увеличивает ROI и качество ВАШЕГО продукта / сервиса
• Снижает риски (в т. ч. «завалить» проект, получить качество продукта
ниже ожиданий, превысить бюджет или сроки, а также связанные
с интеллектуальной собственностью)
• Минимизирует возможный ущерб и стоимость инцидентов
• Снижает стоимость разработки, поддержки
и общую стоимость владения
• Помогает соответствовать требованиям (compliance)
• Повышает уровень удовлетворенности у Заказчика и Команды
• Повышает продуктивность
• Уменьшает сроки / график / расписание
ЗаголовокНе пора ли применить SDL / SSDL?
Исследование Aberdeen
Предотвращение одной уязвимости почти полностью покрывает
годовые затраты на повышение безопасности разработки
Исследование Forrester
Компании, применяющие
методы SDL, демонстрируют
гораздо более быстрый
возврат инвестиций
Предотвратить проблему с безопасностью
в 4 раза дешевле, чем разбираться
с ее последствиями!
Заголовок
Подведем итог
• Атаки переходят на уровень приложений
Are your product Popular? Next Target!
• Разработка защищенного кода с помощью процесса
безопасной разработки – экономия денег Компании,
снижение рисков и повышение качества продукта
•Пора попробовать SDL!
ЗаголовокЧто почитать (1 / 2)
• Building Security In – обязательно к прочтению
• Дао безопасности от Геннадия Махметова
• SDL by Microsoft все про SDL от MSFT
• Книга по SDL от Ховарда и Липнера
(главный за SDL в Microsoft)
• Упрощенный SDL на русском (и оригинал)
• SDL Best Practices for Developers, BUILD 2014
(45 min video)
• Alexey Sintsov SDLC Implement me or Die
(SDL+DevOps)
• Алексей Бабенко Цикл безопасной разработки SDL
• Andrey Beshkov on SDL & ALM (1, 2)
• Nazar Tymoshyk on SDL & Agile (1, 2, 3)
ЗаголовокЧто почитать (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
ЗаголовокМоделирование угроз. Ссылки
1. Application Threat Modeling на сайте OWASP
2. Статья с описанием подхода на Хабре от Владимира Кочеткова, PT
3. Обнаружение недостатков безопасности при помощи STRIDE
(MSDN Magazine)
4. The STRIDE Threat Model на сайте Microsoft
5. Microsoft Threat Modeling Tool 2016
ЗаголовокМинутка рекламы
Ищем
• SDL/SSDL сообщество – тех,
кому интересна «жизнь по SSDL»
• Тех, кто готов делиться опытом,
уже живет или находится в процессе
перехода на SDL
• Разработчиков на С#, QA,
фронтендеров, аналитиков
в Новосибирск bit.ly/PT_Novosibirsk_job
• …и другие города тоже
www.ptsecurity.com/about/vacancy
ЗаголовокПара видео - как мы живем, работаем, отдыхаем :)
Backstage
Positive Technologies 13 лет!
https://youtu.be/1_zNxMHyCZk
Присоединяйтесь!
Будем работать по / в цикле
безопасной разработки вместе :)
Заголовок
Thank You!
ptsecurity.com

More Related Content

What's hot

Разработка ПО в рамках PCI DSS
Разработка ПО в рамках PCI DSSРазработка ПО в рамках PCI DSS
Разработка ПО в рамках PCI DSSAlex Babenko
 
Безопасность и сертификация банковского ПО
Безопасность и сертификация банковского ПОБезопасность и сертификация банковского ПО
Безопасность и сертификация банковского ПОAlex Babenko
 
PT Application Inspector SSDL Edition листовка
PT Application Inspector SSDL Edition листовкаPT Application Inspector SSDL Edition листовка
PT Application Inspector SSDL Edition листовка
Valery Boronin
 
Внутреннее качество в процедурах информационной безопасности
Внутреннее качество в процедурах информационной безопасностиВнутреннее качество в процедурах информационной безопасности
Внутреннее качество в процедурах информационной безопасности
Alex Babenko
 
Опасная разработка. Дорожная карта движения к катастрофе
Опасная разработка. Дорожная карта движения к катастрофеОпасная разработка. Дорожная карта движения к катастрофе
Опасная разработка. Дорожная карта движения к катастрофе
SelectedPresentations
 
2015 02 пм качалин sdl
2015 02 пм качалин sdl2015 02 пм качалин sdl
2015 02 пм качалин sdlAlexey Kachalin
 
Кризисное управление проектами: проблемы, компромиссы, решения
Кризисное управление проектами: проблемы, компромиссы, решенияКризисное управление проектами: проблемы, компромиссы, решения
Кризисное управление проектами: проблемы, компромиссы, решения
SQALab
 
Лекция 2 тестирование и жизненный цикл ПО
Лекция 2 тестирование и жизненный цикл ПОЛекция 2 тестирование и жизненный цикл ПО
Лекция 2 тестирование и жизненный цикл ПО
Sergey Chuburov
 
Решение проблем с помощью RCA. Методики и инструменты.
Решение проблем с помощью RCA. Методики и инструменты.Решение проблем с помощью RCA. Методики и инструменты.
Решение проблем с помощью RCA. Методики и инструменты.
Alexey Evmenkov
 
Alexander Dmitriev - Практика построения ключевых процессов менеджмента инфор...
Alexander Dmitriev - Практика построения ключевых процессов менеджмента инфор...Alexander Dmitriev - Практика построения ключевых процессов менеджмента инфор...
Alexander Dmitriev - Практика построения ключевых процессов менеджмента инфор...UISGCON
 
Бизнес-модели в деятельности безопасника
Бизнес-модели в деятельности безопасникаБизнес-модели в деятельности безопасника
Бизнес-модели в деятельности безопасникаAleksey Lukatskiy
 
лекция безопасная разработка приложений
лекция  безопасная разработка приложенийлекция  безопасная разработка приложений
лекция безопасная разработка приложений
Alexander Kolybelnikov
 
Альтернативный курс по информационной безопасности
Альтернативный курс по информационной безопасностиАльтернативный курс по информационной безопасности
Альтернативный курс по информационной безопасностиAleksey Lukatskiy
 
Практика внутреннего аудита СМИБ
Практика внутреннего аудита СМИБПрактика внутреннего аудита СМИБ
Практика внутреннего аудита СМИБ
Alexey Evmenkov
 
Внедрение безопасной разработки (Infosecurity 2014)
Внедрение безопасной разработки (Infosecurity 2014)Внедрение безопасной разработки (Infosecurity 2014)
Внедрение безопасной разработки (Infosecurity 2014)
Alexey Kachalin
 
Киберучения по ИБ для топ-менеджмента
Киберучения по ИБ для топ-менеджментаКиберучения по ИБ для топ-менеджмента
Киберучения по ИБ для топ-менеджмента
Aleksey Lukatskiy
 
Мониторинг своими руками
Мониторинг своими рукамиМониторинг своими руками
Мониторинг своими руками
Sergey Soldatov
 
СМИБ - игра в долгую
СМИБ - игра в долгуюСМИБ - игра в долгую
СМИБ - игра в долгую
Alexey Evmenkov
 
пр Разработка комплекта документов по управлению ИБ (прозоров)
пр Разработка комплекта документов по управлению ИБ (прозоров)пр Разработка комплекта документов по управлению ИБ (прозоров)
пр Разработка комплекта документов по управлению ИБ (прозоров)
Andrey Prozorov, CISM, CIPP/E, CDPSE. LA 27001
 
Измерение эффективности ИБ
Измерение эффективности ИБИзмерение эффективности ИБ
Измерение эффективности ИБAleksey Lukatskiy
 

What's hot (20)

Разработка ПО в рамках PCI DSS
Разработка ПО в рамках PCI DSSРазработка ПО в рамках PCI DSS
Разработка ПО в рамках PCI DSS
 
Безопасность и сертификация банковского ПО
Безопасность и сертификация банковского ПОБезопасность и сертификация банковского ПО
Безопасность и сертификация банковского ПО
 
PT Application Inspector SSDL Edition листовка
PT Application Inspector SSDL Edition листовкаPT Application Inspector SSDL Edition листовка
PT Application Inspector SSDL Edition листовка
 
Внутреннее качество в процедурах информационной безопасности
Внутреннее качество в процедурах информационной безопасностиВнутреннее качество в процедурах информационной безопасности
Внутреннее качество в процедурах информационной безопасности
 
Опасная разработка. Дорожная карта движения к катастрофе
Опасная разработка. Дорожная карта движения к катастрофеОпасная разработка. Дорожная карта движения к катастрофе
Опасная разработка. Дорожная карта движения к катастрофе
 
2015 02 пм качалин sdl
2015 02 пм качалин sdl2015 02 пм качалин sdl
2015 02 пм качалин sdl
 
Кризисное управление проектами: проблемы, компромиссы, решения
Кризисное управление проектами: проблемы, компромиссы, решенияКризисное управление проектами: проблемы, компромиссы, решения
Кризисное управление проектами: проблемы, компромиссы, решения
 
Лекция 2 тестирование и жизненный цикл ПО
Лекция 2 тестирование и жизненный цикл ПОЛекция 2 тестирование и жизненный цикл ПО
Лекция 2 тестирование и жизненный цикл ПО
 
Решение проблем с помощью RCA. Методики и инструменты.
Решение проблем с помощью RCA. Методики и инструменты.Решение проблем с помощью RCA. Методики и инструменты.
Решение проблем с помощью RCA. Методики и инструменты.
 
Alexander Dmitriev - Практика построения ключевых процессов менеджмента инфор...
Alexander Dmitriev - Практика построения ключевых процессов менеджмента инфор...Alexander Dmitriev - Практика построения ключевых процессов менеджмента инфор...
Alexander Dmitriev - Практика построения ключевых процессов менеджмента инфор...
 
Бизнес-модели в деятельности безопасника
Бизнес-модели в деятельности безопасникаБизнес-модели в деятельности безопасника
Бизнес-модели в деятельности безопасника
 
лекция безопасная разработка приложений
лекция  безопасная разработка приложенийлекция  безопасная разработка приложений
лекция безопасная разработка приложений
 
Альтернативный курс по информационной безопасности
Альтернативный курс по информационной безопасностиАльтернативный курс по информационной безопасности
Альтернативный курс по информационной безопасности
 
Практика внутреннего аудита СМИБ
Практика внутреннего аудита СМИБПрактика внутреннего аудита СМИБ
Практика внутреннего аудита СМИБ
 
Внедрение безопасной разработки (Infosecurity 2014)
Внедрение безопасной разработки (Infosecurity 2014)Внедрение безопасной разработки (Infosecurity 2014)
Внедрение безопасной разработки (Infosecurity 2014)
 
Киберучения по ИБ для топ-менеджмента
Киберучения по ИБ для топ-менеджментаКиберучения по ИБ для топ-менеджмента
Киберучения по ИБ для топ-менеджмента
 
Мониторинг своими руками
Мониторинг своими рукамиМониторинг своими руками
Мониторинг своими руками
 
СМИБ - игра в долгую
СМИБ - игра в долгуюСМИБ - игра в долгую
СМИБ - игра в долгую
 
пр Разработка комплекта документов по управлению ИБ (прозоров)
пр Разработка комплекта документов по управлению ИБ (прозоров)пр Разработка комплекта документов по управлению ИБ (прозоров)
пр Разработка комплекта документов по управлению ИБ (прозоров)
 
Измерение эффективности ИБ
Измерение эффективности ИБИзмерение эффективности ИБ
Измерение эффективности ИБ
 

Viewers also liked

Кто сказал «WAF»?
Кто сказал «WAF»?Кто сказал «WAF»?
Кто сказал «WAF»?
Positive Development User Group
 
Технологии анализа бинарного кода приложений: требования, проблемы, инструменты
Технологии анализа бинарного кода приложений: требования, проблемы, инструментыТехнологии анализа бинарного кода приложений: требования, проблемы, инструменты
Технологии анализа бинарного кода приложений: требования, проблемы, инструменты
Positive Development User Group
 
Александр Башарин - Проведение пользовательского тестирования с большим число...
Александр Башарин - Проведение пользовательского тестирования с большим число...Александр Башарин - Проведение пользовательского тестирования с большим число...
Александр Башарин - Проведение пользовательского тестирования с большим число...
SQALab
 
Моделирование угроз для приложений
Моделирование угроз для приложенийМоделирование угроз для приложений
Моделирование угроз для приложений
SQALab
 
Современные подходы к SAST
Современные подходы к SASTСовременные подходы к SAST
Современные подходы к SAST
Vladimir Kochetkov
 
Философия Application Security
Философия Application SecurityФилософия Application Security
Философия Application Security
Vladimir Kochetkov
 
Как разработать защищенное веб-приложение и не сойти при этом с ума (вебинар)
Как разработать защищенное веб-приложение и не сойти при этом с ума (вебинар)Как разработать защищенное веб-приложение и не сойти при этом с ума (вебинар)
Как разработать защищенное веб-приложение и не сойти при этом с ума (вебинар)
Vladimir Kochetkov
 
Моделирование угроз 2.0
Моделирование угроз 2.0Моделирование угроз 2.0
Моделирование угроз 2.0
Aleksey Lukatskiy
 
Подходы к сигнатурному статическому анализу
Подходы к сигнатурному статическому анализуПодходы к сигнатурному статическому анализу
Подходы к сигнатурному статическому анализу
Positive Development User Group
 
Как разработать защищенное веб-приложение и не сойти при этом с ума? (PHDays 3)
Как разработать защищенное веб-приложение и не сойти при этом с ума? (PHDays 3)Как разработать защищенное веб-приложение и не сойти при этом с ума? (PHDays 3)
Как разработать защищенное веб-приложение и не сойти при этом с ума? (PHDays 3)
Vladimir Kochetkov
 
Source Code Analysis with SAST
Source Code Analysis with SASTSource Code Analysis with SAST
Source Code Analysis with SAST
Blueinfy Solutions
 
Тестируем производительность с помощью Selenium
Тестируем производительность с помощью SeleniumТестируем производительность с помощью Selenium
Тестируем производительность с помощью Selenium
SQALab
 
Опыт организации тестирования безопасности Web приложений в компании
Опыт организации тестирования безопасности Web приложений в компанииОпыт организации тестирования безопасности Web приложений в компании
Опыт организации тестирования безопасности Web приложений в компании
SQALab
 
Тестирование уязвимостей веб приложений
Тестирование уязвимостей веб приложенийТестирование уязвимостей веб приложений
Тестирование уязвимостей веб приложений
SQALab
 
Security as a new metric for Business, Product and Development Lifecycle
Security as a new metric for Business, Product and Development LifecycleSecurity as a new metric for Business, Product and Development Lifecycle
Security as a new metric for Business, Product and Development Lifecycle
Nazar Tymoshyk, CEH, Ph.D.
 
Заблуждения и стереотипы относительно анализа кода
Заблуждения и стереотипы относительно анализа кодаЗаблуждения и стереотипы относительно анализа кода
Заблуждения и стереотипы относительно анализа кодаRISSPA_SPb
 

Viewers also liked (16)

Кто сказал «WAF»?
Кто сказал «WAF»?Кто сказал «WAF»?
Кто сказал «WAF»?
 
Технологии анализа бинарного кода приложений: требования, проблемы, инструменты
Технологии анализа бинарного кода приложений: требования, проблемы, инструментыТехнологии анализа бинарного кода приложений: требования, проблемы, инструменты
Технологии анализа бинарного кода приложений: требования, проблемы, инструменты
 
Александр Башарин - Проведение пользовательского тестирования с большим число...
Александр Башарин - Проведение пользовательского тестирования с большим число...Александр Башарин - Проведение пользовательского тестирования с большим число...
Александр Башарин - Проведение пользовательского тестирования с большим число...
 
Моделирование угроз для приложений
Моделирование угроз для приложенийМоделирование угроз для приложений
Моделирование угроз для приложений
 
Современные подходы к SAST
Современные подходы к SASTСовременные подходы к SAST
Современные подходы к SAST
 
Философия Application Security
Философия Application SecurityФилософия Application Security
Философия Application Security
 
Как разработать защищенное веб-приложение и не сойти при этом с ума (вебинар)
Как разработать защищенное веб-приложение и не сойти при этом с ума (вебинар)Как разработать защищенное веб-приложение и не сойти при этом с ума (вебинар)
Как разработать защищенное веб-приложение и не сойти при этом с ума (вебинар)
 
Моделирование угроз 2.0
Моделирование угроз 2.0Моделирование угроз 2.0
Моделирование угроз 2.0
 
Подходы к сигнатурному статическому анализу
Подходы к сигнатурному статическому анализуПодходы к сигнатурному статическому анализу
Подходы к сигнатурному статическому анализу
 
Как разработать защищенное веб-приложение и не сойти при этом с ума? (PHDays 3)
Как разработать защищенное веб-приложение и не сойти при этом с ума? (PHDays 3)Как разработать защищенное веб-приложение и не сойти при этом с ума? (PHDays 3)
Как разработать защищенное веб-приложение и не сойти при этом с ума? (PHDays 3)
 
Source Code Analysis with SAST
Source Code Analysis with SASTSource Code Analysis with SAST
Source Code Analysis with SAST
 
Тестируем производительность с помощью Selenium
Тестируем производительность с помощью SeleniumТестируем производительность с помощью Selenium
Тестируем производительность с помощью Selenium
 
Опыт организации тестирования безопасности Web приложений в компании
Опыт организации тестирования безопасности Web приложений в компанииОпыт организации тестирования безопасности Web приложений в компании
Опыт организации тестирования безопасности Web приложений в компании
 
Тестирование уязвимостей веб приложений
Тестирование уязвимостей веб приложенийТестирование уязвимостей веб приложений
Тестирование уязвимостей веб приложений
 
Security as a new metric for Business, Product and Development Lifecycle
Security as a new metric for Business, Product and Development LifecycleSecurity as a new metric for Business, Product and Development Lifecycle
Security as a new metric for Business, Product and Development Lifecycle
 
Заблуждения и стереотипы относительно анализа кода
Заблуждения и стереотипы относительно анализа кодаЗаблуждения и стереотипы относительно анализа кода
Заблуждения и стереотипы относительно анализа кода
 

Similar to Построение процесса безопасной разработки

Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4Dima Dzuba
 
Ломать и строить. PHDays 2015
Ломать и строить. PHDays 2015Ломать и строить. PHDays 2015
Ломать и строить. PHDays 2015
Alexey Kachalin
 
ЛОМАТЬ И СТРОИТЬ, И СНОВА ЛОМАТЬ
ЛОМАТЬ И СТРОИТЬ, И СНОВА ЛОМАТЬЛОМАТЬ И СТРОИТЬ, И СНОВА ЛОМАТЬ
ЛОМАТЬ И СТРОИТЬ, И СНОВА ЛОМАТЬ
Positive Hack Days
 
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
Expolink
 
Построение Secure Development Lifecycle
Построение Secure Development Lifecycle Построение Secure Development Lifecycle
Построение Secure Development Lifecycle
Vlad Styran
 
Гибкие методологии при создании ИТ продукта.
Гибкие методологии при создании ИТ продукта.Гибкие методологии при создании ИТ продукта.
Гибкие методологии при создании ИТ продукта.
Project Management Institute (PMI) in Ufa
 
Вебинар по HP ArcSight 25.11.14
Вебинар по HP ArcSight 25.11.14Вебинар по HP ArcSight 25.11.14
Вебинар по HP ArcSight 25.11.14
DialogueScience
 
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
DialogueScience
 
Дашборды по ИБ для топ-менеджмента
Дашборды по ИБ для топ-менеджментаДашборды по ИБ для топ-менеджмента
Дашборды по ИБ для топ-менеджмента
Aleksey Lukatskiy
 
От экспериментального программирования к промышленному: путь длиной в 10 лет
От экспериментального программирования к промышленному: путь длиной в 10 летОт экспериментального программирования к промышленному: путь длиной в 10 лет
От экспериментального программирования к промышленному: путь длиной в 10 лет
Positive Development User Group
 
Обеспечение качества ПО: международный опыт
Обеспечение качества ПО: международный опытОбеспечение качества ПО: международный опыт
Обеспечение качества ПО: международный опытAleksey Lukatskiy
 
Как довести проект по информационной безопасности до ума
Как довести проект по информационной безопасности до умаКак довести проект по информационной безопасности до ума
Как довести проект по информационной безопасности до ума
InfoWatch
 
EDR investment guide for Enterprise 2017-2018
EDR investment guide for Enterprise 2017-2018EDR investment guide for Enterprise 2017-2018
EDR investment guide for Enterprise 2017-2018
Oleg Glebov
 
ИСО 27001 на практике, или будни внедренца
ИСО 27001 на практике, или будни внедренцаИСО 27001 на практике, или будни внедренца
ИСО 27001 на практике, или будни внедренца
Alexey Evmenkov
 
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015
Maxim Avdyunin
 
Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)
Andrey Bibichev
 
Umurashka codeib-presentation-v2
Umurashka codeib-presentation-v2Umurashka codeib-presentation-v2
Umurashka codeib-presentation-v2
Uladzislau Murashka
 
пр Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого...
пр Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого...пр Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого...
пр Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого...
Andrey Prozorov, CISM, CIPP/E, CDPSE. LA 27001
 
SOC vs SIEM
SOC vs SIEMSOC vs SIEM
SOC vs SIEM
Aleksey Lukatskiy
 
От экспериментального программирования к промышленному: путь длиной в 10 лет
От экспериментального программирования к промышленному: путь длиной в 10 летОт экспериментального программирования к промышленному: путь длиной в 10 лет
От экспериментального программирования к промышленному: путь длиной в 10 лет
Positive Hack Days
 

Similar to Построение процесса безопасной разработки (20)

Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4Проектирование программных систем. Занятие 4
Проектирование программных систем. Занятие 4
 
Ломать и строить. PHDays 2015
Ломать и строить. PHDays 2015Ломать и строить. PHDays 2015
Ломать и строить. PHDays 2015
 
ЛОМАТЬ И СТРОИТЬ, И СНОВА ЛОМАТЬ
ЛОМАТЬ И СТРОИТЬ, И СНОВА ЛОМАТЬЛОМАТЬ И СТРОИТЬ, И СНОВА ЛОМАТЬ
ЛОМАТЬ И СТРОИТЬ, И СНОВА ЛОМАТЬ
 
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
Solar Security. Андрей Прозоров. "5 "почему" аутсорсинга ИБ"
 
Построение Secure Development Lifecycle
Построение Secure Development Lifecycle Построение Secure Development Lifecycle
Построение Secure Development Lifecycle
 
Гибкие методологии при создании ИТ продукта.
Гибкие методологии при создании ИТ продукта.Гибкие методологии при создании ИТ продукта.
Гибкие методологии при создании ИТ продукта.
 
Вебинар по HP ArcSight 25.11.14
Вебинар по HP ArcSight 25.11.14Вебинар по HP ArcSight 25.11.14
Вебинар по HP ArcSight 25.11.14
 
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
Мониторинг событий информационной безопасности на базе решений HP ArcSight ES...
 
Дашборды по ИБ для топ-менеджмента
Дашборды по ИБ для топ-менеджментаДашборды по ИБ для топ-менеджмента
Дашборды по ИБ для топ-менеджмента
 
От экспериментального программирования к промышленному: путь длиной в 10 лет
От экспериментального программирования к промышленному: путь длиной в 10 летОт экспериментального программирования к промышленному: путь длиной в 10 лет
От экспериментального программирования к промышленному: путь длиной в 10 лет
 
Обеспечение качества ПО: международный опыт
Обеспечение качества ПО: международный опытОбеспечение качества ПО: международный опыт
Обеспечение качества ПО: международный опыт
 
Как довести проект по информационной безопасности до ума
Как довести проект по информационной безопасности до умаКак довести проект по информационной безопасности до ума
Как довести проект по информационной безопасности до ума
 
EDR investment guide for Enterprise 2017-2018
EDR investment guide for Enterprise 2017-2018EDR investment guide for Enterprise 2017-2018
EDR investment guide for Enterprise 2017-2018
 
ИСО 27001 на практике, или будни внедренца
ИСО 27001 на практике, или будни внедренцаИСО 27001 на практике, или будни внедренца
ИСО 27001 на практике, или будни внедренца
 
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015
 
Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)
 
Umurashka codeib-presentation-v2
Umurashka codeib-presentation-v2Umurashka codeib-presentation-v2
Umurashka codeib-presentation-v2
 
пр Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого...
пр Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого...пр Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого...
пр Спроси эксперта. Все, что вы хотели узнать про «дыры» в коде, но не у кого...
 
SOC vs SIEM
SOC vs SIEMSOC vs SIEM
SOC vs SIEM
 
От экспериментального программирования к промышленному: путь длиной в 10 лет
От экспериментального программирования к промышленному: путь длиной в 10 летОт экспериментального программирования к промышленному: путь длиной в 10 лет
От экспериментального программирования к промышленному: путь длиной в 10 лет
 

More from Positive Development User Group

Автоматизация построения правил для Approof
Автоматизация построения правил для ApproofАвтоматизация построения правил для Approof
Автоматизация построения правил для Approof
Positive Development User Group
 
Требования по безопасности в архитектуре ПО
Требования по безопасности в архитектуре ПОТребования по безопасности в архитектуре ПО
Требования по безопасности в архитектуре ПО
Positive Development User Group
 
Уязвимое Android-приложение: N проверенных способов наступить на грабли
Уязвимое Android-приложение: N проверенных способов наступить на граблиУязвимое Android-приложение: N проверенных способов наступить на грабли
Уязвимое Android-приложение: N проверенных способов наступить на грабли
Positive Development User Group
 
Формальная верификация кода на языке Си
Формальная верификация кода на языке СиФормальная верификация кода на языке Си
Формальная верификация кода на языке Си
Positive Development User Group
 
Механизмы предотвращения атак в ASP.NET Core
Механизмы предотвращения атак в ASP.NET CoreМеханизмы предотвращения атак в ASP.NET Core
Механизмы предотвращения атак в ASP.NET Core
Positive Development User Group
 
PT BlackBox Scanner
PT BlackBox ScannerPT BlackBox Scanner
PT BlackBox Scanner
Positive Development User Group
 
Трущобы Application Security
Трущобы Application SecurityТрущобы Application Security
Трущобы Application Security
Positive Development User Group
 

More from Positive Development User Group (7)

Автоматизация построения правил для Approof
Автоматизация построения правил для ApproofАвтоматизация построения правил для Approof
Автоматизация построения правил для Approof
 
Требования по безопасности в архитектуре ПО
Требования по безопасности в архитектуре ПОТребования по безопасности в архитектуре ПО
Требования по безопасности в архитектуре ПО
 
Уязвимое Android-приложение: N проверенных способов наступить на грабли
Уязвимое Android-приложение: N проверенных способов наступить на граблиУязвимое Android-приложение: N проверенных способов наступить на грабли
Уязвимое Android-приложение: N проверенных способов наступить на грабли
 
Формальная верификация кода на языке Си
Формальная верификация кода на языке СиФормальная верификация кода на языке Си
Формальная верификация кода на языке Си
 
Механизмы предотвращения атак в ASP.NET Core
Механизмы предотвращения атак в ASP.NET CoreМеханизмы предотвращения атак в ASP.NET Core
Механизмы предотвращения атак в ASP.NET Core
 
PT BlackBox Scanner
PT BlackBox ScannerPT BlackBox Scanner
PT BlackBox Scanner
 
Трущобы Application Security
Трущобы Application SecurityТрущобы Application Security
Трущобы Application Security
 

Построение процесса безопасной разработки

  • 1. Заголовок ptsecurity.com Построение процесса безопасной разработки Что это означает на практике для разработчиков и их руководителей? Валерий Боронин
  • 2. ЗаголовокВалерий Боронин • В разработке и R&D более 20 лет • Начинал еще под Windows 3.1 • Достиг определенных высот разработчиком режима ядра под Windows (до 2009) • В безопасности с прошлого тысячелетия ;-) • Работал CTO небольшой компании (30+ человек) • Директором по исследованиям большой («Лаборатория Касперского», 2500+ человек, 2009–2014) • Сейчас отвечаю за направление безопасной разработки (SDL / SSDL) в Позитиве • Мы с командой создаем новый продукт по автоматизации безопасной разработки
  • 3. Заголовок О чем поговорим в начале? • Зачем нужна безопасность? • Что такое защищенное приложение? • Почему ПО небезопасно? • Разработчики и безопасность • Что такое SDL/SSDL = безопасная разработка? • Зачем нужна? • Какие проблемы решает?
  • 4. ЗаголовокЗачем нужна безопасность вашим заказчикам? Отраслевые требования Государственное регулирование Доступность бизнеса Капитализация Статистика нарушений Требования заказчика Предыдущий плохой опыт
  • 5. ЗаголовокПоследствия проблем с безопасностью Доверие Деньги Данные утекшие Время на восстановление Ущерб по инциденту Заказчики Репутация Безопасность на стыке с надежностью: у вас 5 компонентов в e-commerce приложении с 98% uptime каждый? Ожидайте 150 мин простоя в день! * *Источник: книга Gary McGraw (https://www.garymcgraw.com/)
  • 6. ЗаголовокЗачем? Наши реалии Большинство обнаруживаемых уязвимостей – типовые, общеизвестные, хорошо описанные. Статистика по распределению уязвимостей веб-приложений за 2015 год Источник: по данным аналитического центра Positive Technologies (серым цветом – 2014 год)
  • 7. Заголовок 59% 80% 100% 100% 65% 20% Черный/серый ящик Белый ящик Высокий Средний Низкий Почему мы об этом говорим? Источник: по данным аналитического центра Positive Technologies за 2015 год 56% 69% 88% 100% 100% 100% 44% 38% 75% 0% 20% 40% 60% 80% 100% 120% PHP Java Другие Высокий Средний Низкий
  • 8. ЗаголовокЧто такое защищенное ПО? • Обычно подразумевается: • Безопасная разработка • Контроль целостности • Правильная эксплуатация • …а по версии ФСТЭК? • + документация и конфигурации • + инфраструктура среды разработки • + люди Хорошо работает то, что хорошо управляется © В. В. Путин
  • 9. ЗаголовокЧто такое защищенное ПО? Быть на шаг впереди, в постоянном ожидании сбоя. Работать даже тогда, когда твоего сбоя яростно ожидает оппонент. Защищенное ПО гораздо больше вкладывает в учет проблемных кейсов, чем не имеющих проблем. На шаг впереди – вот девиз проектировщиков и других безопасных разработчиков. Источник: вступительное слово к замечательной книге Gary McGraw (первопроходца в SDL)
  • 10. ЗаголовокПочему ПО небезопасно? 1. Ломать – не строить! 2. Безопасность – ассиметрична 3. В основе многих классов уязвимостей – проблемы с дизайном (design issues) или бизнес-логикой (business logic issues) 4. Инструменты для тестирования на безопасность продаются как решение проблемы небезопасного ПО (таблетки не существует) 5. Защищенное ПО – дуально. Надо атаковать и защищаться, эксплуатировать и проектировать, ломать и строить – одновременно I know when I’m writing code I’m not thinking about evil, I’m just trying to think about functionality © Scott Hanselman Почему простого цикла разработки или анализа-исправления кода недостаточно? Полный разбор в блестящем анализе от Геннадия Махметова
  • 11. ЗаголовокЧто же делать? • Нужно • Проактивное проектирование + • Exploit-driven тестирование + • Все это на базе управления рисками Три основания безопасной / защищенной разработки: управление рисками, лучшие практики и Знание Program testing can be used to show the presence of defects, but never their absence © Dijkstra
  • 12. ЗаголовокРазработчики и безопасность Стандартные отговорки: • Сроки горят (время) • Нет ресурсов (бюджета, экспертизы, инструментов, …) на обеспечение безопасных практик • Мы стартап – нам нужно быстрее стать популярными и заработать много денег • … Shortage of skill or shortage of discipline? Знать мало – надо применять!
  • 13. ЗаголовокЦикл [безопасной] разработки • SDLC – Systems / Software Development Life Cycle • SSDLC – Secure Software Development Life Cycle • SDLC – Secure / Security Development Life Cycle • SSDL – Secure Software Development • SDL – Secure Development Lifecycle (MSFT) SDLC
  • 14. ЗаголовокSDLC vs SDL / SSDL SDLC SSDL «Просто» разработка ПО Жизненный Цикл «Безопасная» разработка ПО
  • 15. ЗаголовокЗачем нужен SDL? Взгляд руководителя • Риски и минимизация ущерба • Стоимость разработки • Соответствие требованиям
  • 16. ЗаголовокЗачем нужен SDL? Взгляд руководителя • Риски и минимизация ущерба • Стоимость разработки • Соответствие требованиям
  • 17. ЗаголовокЗачем нужен SDL? Взгляд руководителя • Риски и минимизация ущерба • Стоимость разработки • Соответствие требованиям
  • 19. ЗаголовокСтоимость разработки NIST: исправлять ошибки после выпуска дороже в 30 раз, чем на стадии разработки дизайна
  • 20. ЗаголовокСтоимость разработки Источник: HP ‘The New Attack Vector: Applications Reduce risk and cost by designing in security.’ Исправлять ошибки после выпуска дороже в 30–100 раз, чем на стадии разработки требований
  • 22. ЗаголовокНо почему четырежды? Исследование Aberdeen: • Предотвращение одной уязвимости почти полностью покрывает годовые затраты на повышение безопасности разработки • Предотвратить проблему с безопасностью в 4 раза дешевле, чем разбираться с ее последствиями Исследование Forrester: • Разработка безопасного ПО еще не стала широко распространенной практикой • Компании, применяющие методы SDL, демонстрируют гораздо более быстрый возврат инвестиций BSIMM (позже) & McGrow (в книге) еще более категоричны: • Разрыв между теми, кто применяет, и теми, кто ждет, нарастает с ускорением • Пугают тем, что скоро HR начнут массово искать SDL-certified людей ;-) • В результате не перестроившиеся начнут вылетать с рынка
  • 23. ЗаголовокФакты из мира качества Inspections + static analysis + formal testing > 99% efficient Quality excellence has ROI > $15 for each $1 spent Источник: http://namcookanalytics.com/software-quality-survey-state-art/
  • 24. ЗаголовокБезопасность – это дорого (1 / 2) Источник: http://namcookanalytics.com/software-quality-survey-state-art/
  • 25. ЗаголовокБезопасность – это дорого (2 / 2) Источник: http://namcookanalytics.com/software-quality-survey-state-art/
  • 26. ЗаголовокБезопасность – трудно найти и трудно исправить HIGHLIGHTS FROM THE 2015 WORLD SW QUALITY REPORT … Security is the most pressing concern Источник: http://namcookanalytics.com/software-quality-survey-state-art/
  • 27. ЗаголовокЗачем нужен SDL? Взгляд разработчика 1. Качественный код (безопасное и качественное ПО) 2. Больше времени на работу (и собственное развитие!) 3. Проактивность Реактивность (быть причиной) …Все правильно сделал! 
  • 28. Заголовок Минуточку! Попрошу поподробнее! • Применимость • Когда разработка становится безопасной? • Роли, ответственность, квалиф. требования • Обязательные активности (16 практик) • Дополнительные активности • О чем еще стоит упомянуть? • Процедура проверки безопасности приложения • Так этих SDL’ей… много и они разные?! Что же такое SDL? Из чего состоит?
  • 29. ЗаголовокSecurity Development Lifecycle (SDL) – must have Обучение • Начальное обучение безопасности Требования • Определение требований по безопасности • Оценка рисков • Create Quality Gates/Bug Bars Дизайн • Установить требования к дизайну • Анализ поверхности атаки • Моделирование угроз Реализация • Выбор инструментов • Блокирование запрещенных функций • Статический анализ Проверка • Динамический анализ • Fuzz Testing • Проверка поверхности атаки Выпуск • План реагирования на инциденты • Финальный анализ безопасности • Доверенный выпуск Реагирование • Выполнение плана реагирования http://www.microsoft.com/security/sdl/default.aspx    Технология и процессОбучение Ответственность Education, accountability, and clear objectives are critical components to any successful software security initiative © McGraw
  • 30. ЗаголовокЧто такой упрощенный SDL? • Модель помогает определить текущий уровень зрелости компании и разработать план действий по внедрению соответствующих процессов для реализации полноценного цикла безопасной разработки • Так когда разработка становится безопасной?  Зрелость Организации
  • 31. ЗаголовокSDL. Применимость Ваше приложение: • Работает в бизнес- или корпоративном окружении? • Обрабатывает / хранит персональные данные или sensitive информацию? • Взаимодействует по сети / другим каналам передачи информации? • Практика показывает, что сложно найти приложение, которому не показан SDL
  • 32. ЗаголовокSDL. Люди: формализация ролей и обязанностей •Советник по безопасности / конфиденциальности (снаружи) • Аудитор (подчиненная роль) • Эксперт (подчиненная роль) • Можно совмещать аудитора с экспертом • Советников тоже можно совмещать •Руководители групп по безопасности / конфиденциальности (изнутри) • Отвечают за координацию и отслеживание вопросов безопасности на проекте + сообщают состояние Советнику и другим ЗЛ • Можно совмещать роли security и privacy champions
  • 33. ЗаголовокSDL. Фаза 1 – Обучение 1. Все задействованные сотрудники в технических ролях (Devs, QA, PMs) 2. Не реже 1 раза в год 3. Знания для выполнения остальных фаз + как работаем по новому процессу • Обследовать подготовленность организации по темам безопасности и защиты данных (privacy) • При необходимости создать стандартные курсы обучения Безопасность – дело каждого! Разработать критерии качества программы обучения Содержимое должно покрывать темы со следующего слайда Определить частоту тренингов Разработчик должен пройти не менее Х тренингов в год Определить минимальный приемлемый порог тренингов в группе разработки 75% техперсонала должны пройти базовые тренинги до выпуска беты
  • 34. ЗаголовокSDL. Фаза 1 – Обучение. Чему учить? 1. Безопасный дизайн • Уменьшение поверхности атаки • Наименьшие привилегии • Многослойная защита • Безопасные настройки по умолчанию 2. Моделирование угроз 3. Безопасное кодирование (переполнение буфера, XSS, SQL-инъекции, криптография) 4. Тестирование безопасности • Разница с функциональным тестированием • Оценка рисков • Методы тестирования безопасности Безопасность – дело каждого! • 5. Защита информации / Privacy / Соответствие требованиям • Персональные данные, ФЗ 152 и отраслевые стандарты • Трансграничная передача данных • Обработка, хранение и т. п. чувствительных данных – ФЗ №242 • 6. … • … • Trusted user interface design • …
  • 35. ЗаголовокSDL Фаза 2 – Требования Возможность заложить безопасный фундамент для проекта • Определение требований по безопасности (разово) SDL Practice #2: Establish Security and Privacy Requirements • Определить и задокументировать порог отбраковки продукта по ошибкам, связанным с безопасностью и защитой данных (разово) SDL Practice #3: Create Quality Gates/Bug Bars • Оценка рисков SDL Practice #4: Perform Security and Privacy Risk Assessments (разово)
  • 36. ЗаголовокSDL Фаза 3 – Проектирование 1. Архитектурные требования (разово) • Определить и задокументировать архитектуру безопасности и идентифицировать критические компоненты безопасности 2. Анализ / сокращение поверхности атаки (разово) • Задокументировать поверхность атаки продукта • Ограничить ее установками по умолчанию 3. Моделирование угроз • Определить угрозы и меры снижения угроз • Систематический пересмотр свойств продукта и его архитектуры с точки зрения безопасности • Определить критерии выпуска обновления продукта в связи с изменением в безопасности продукта
  • 37. ЗаголовокSDL Threat Modeling Tool (TMT) – справочно • Формализует и упрощает моделирование угроз так, чтобы им мог заниматься архитектор Обучает созданию диаграмм угроз Анализ угроз и мер защиты Интеграция с багтрекером Отчеты по угрозам и уязвимостям
  • 38. ЗаголовокSDL. Фаза 4 – Реализация Разработка кода и ревью процессов, документации и инструментов, необходимых для безопасного развертывания и эксплуатации разрабатываемого продукта • Использование утвержденных / доверенных средств и их аналогов • Практики безопасного программирования • Статический анализ кода Конкретно: Поиск случаев использования запрещенных API Применение механизмов защиты предоставляемых ОС Использование безопасных версий библиотек и фреймворков Соблюдение специфических требований безопасности (XSS, SQL-инъекции…)
  • 39. ЗаголовокSDL. Фаза 5 – Проверка (Тестирование) Начните тестирование как можно раньше. В идеале – как только появился готовый для этого код • Динамический анализ • Фаззинг – файлами, вводом данных в интерфейсные элементы и код сетевой подсистемы • Повторно проверьте модели угроз, риски, поверхность атаки. Все ли вы учли? • Начните планирование процесса реагирования на обнаружение уязвимостей в выпущенном продукте – см. следующую стадию • При необходимости выполнить security push (с каждым разом все реже) • Не является заменой работе над безопасностью в процессе разработки • Ревью кода • Тестирование на проникновение • Ревью дизайна и архитектуры в свете вновь обнаруженных угроз
  • 40. ЗаголовокSDL. Фаза 5 – Проверка: инструменты (справочно) BinScope Binary Analyzer • Убедиться что SDL соблюден при компиляции и сборке MiniFuzz File Fuzzer • !exploitable в WinDbg • DAST RegexFuzer • DAST Attack Surface Analyzer • Анализ снимков системы • Измеряет потенциальную поверхность атаки на приложение и ОС AppVerifier • Динамический анализ системы MSF Agile + SDL шаблоны для TFS • Автоматически создает процессы соблюдения SDL в момент создания нового спринта или выполнения check in • Контролирует выполнение всех необходимых процессов безопасности CMMI Шаблоны SDL для TFS • SDL требования как задачи • SDL-based check-in policies • Создание отчета Final Security Review • Интеграция с инструментами сторонних производителей • Библиотека пошаговых указаний SDL how-to
  • 41. ЗаголовокSDL. Фаза 6 – Выпуск: план реагирования • Создать политики поддержки продукта • Создать план реагирования на инциденты безопасности • Группа инженерной поддержки: ресурсы внутри и снаружи организации для адекватной реакции на обнаружение уязвимостей и защиту от атак • Контактные данные лиц, доступных 24x7x365 • 3–5 инженеров • 3–5 специалистов из маркетинга • 1–2 менеджеров верхнего уровня • Обратите внимание на: • Необходимость выпуска экстренных обновлений вашего продукта из-за уязвимостей в унаследованном коде • От других групп в той же организации • Сторонних производителей • Включенном в ваш продукт • Лицензионные условия, возможность вносить изменения, имена файлов, версии, контактные данные и т. п. • Может быть необходимость обновлять продукт после обновления ОС и т. п. http://www.microsoft.com/security/msrc/whatwedo/responding.aspx Watch Alert and Mobilize Resources Assess and Stabilize Resolve Reporting Analysis and Mitigation Create Fix Update Models Test Fix Выпуск Lessons Learned Provide Guidance
  • 42. ЗаголовокSDL Фаза 6 – Выпуск: Final Security Review (FSR) Проверить продукт на соответствие требованиям SDL и отсутствие известных уязвимостей. Получаем независимое заключение готовности продукта к выпуску. FSR не является: • Тестом на проникновение. Запрещено ломать и обновлять продукт • Первой проверкой безопасности продукта • Процессом финальной подписи продукта и отправки его в тираж FSR должен обязательно включать три возможных результата окончательной проверки безопасности: 1. Можно выпускать 2. Можно выпускать с ограничениями (и есть план по их душу) 3. FSR с эскалацией (на руководство Компании) Ключевая концепция: эта фаза не используется как точка для завершения всех задач, пропущенных на предыдущих стадиях
  • 43. ЗаголовокSDL. Фаза 6 – Выпуск: заверить релиз и – в Архив • План реагирования на инциденты безопасности создан • Документация для клиентов обновлена • Создан централизованный архив всего, что поможет • С сервисным обслуживанием релиза • Снизить стоимость поддержки в долгосрочной перспективе • Обязательно включить в архив • Исходники • Приватные отладочные символы • Модели угроз • Документацию – техническую и пользовательскую • Планы реагирования • Лицензионные и прочие Servicing Terms для используемого стороннего ПО
  • 44. ЗаголовокSDL. Фаза 7 – Реагирование на инциденты • Инцидент случился? Идем по заранее созданному плану • Выполняем активности по плану реагирования на инциденты безопасности • Выпускаем обновления в соответствии с графиком релизов • Пересчитываем риски • Информируем клиентов • Публикуем информацию • Выгоды планового реагирования • Понятно, что происходит • Есть ответственные • Удовлетворенность клиента растет • Собираем данные для будущих разработок • Проводим тренинги Не если, а когда!
  • 45. ЗаголовокSDL. Дополнительные меры – что бы сделать еще? 1. Сode review глазом • Важные компоненты • Где храним, обрабатываем, передаем sensitive данные • Криптография 2. Анализ уязвимостей схожих приложений (конкурентов) 3. Тесты на проникновение (но сделать до FSR!) Улучшаем процесс дальше: 1. Анализ первопричин Исследование причин появления найденных уязвимостей (из-за чего она возникла – человеческая ошибка? Несовершенство процесса? Ошибка автоматизации?) 2. Регулярное обновление процесса
  • 46. ЗаголовокSDL. Процедура проверки безопасности приложения • Специальные меры по хранению артефактов через приложение со строгим контролем доступа (RBAC) • Руководители групп безопасности и конфиденциальности обеспечивают ввод данных и их корректность • Их используют Советники, обеспечивая среду для FSR и для анализа, а также подтверждения выполнения всех требований Обязательно хранить: • Требования безопасности и конфиденциальности для организации • Функц. и тех. требования для разрабатываемого приложения • Рабочий контекст приложения (Ex: процедура отслеживания)
  • 47. ЗаголовокCisco SDL – так их, оказывается, много и они разные?! 1. Требования (Product Security Requirements) 2. 3rd Party Security 3. Проектирование (Secure Design) 4. Реализация (Secure Coding) 5. Оценка (Secure Analysis) 6. Тестирование (Vulnerability Testing)
  • 48. ЗаголовокСравнение SDL – справочно Cisco SDL Microsoft SDL PA-DSS SDL РС БР ИББС-2.6-2014) Обучение разработчиков Secure Design, Secure Coding Training Обучение - Отслеживание уязвимостей 3rd Party Security Implementation (частично) Выявление уязвимостей Эксплуатация Определение требований к ИБ Product Security Requirements Requirements Проектирование Проектирование Создание модели угроз Secure Design Design Оценка рисков Разработка технического задания (рекомендательно) Практики безопасной разработки Secure Coding Implementation Создание - Анализ кода Secure Analysis Implementation Анализ кода Создание и тестирование (рекомендательно) Тестирование безопасности Vulnerability Testing Verification, Release Тестирование безопасности Создание и тестирование Выпуск релиза - Release Выпуск Прием и ввод в действие Поддержка - Response Поддержка Сопровождение и модернизация Вывод из эксплуатации - Снятие с эксплуатации Источник: http://www.slideshare.net/arekusux/sdl-38135128
  • 49. ЗаголовокSoftware Assurance Maturity Model (SAMM) Модели Software Assurance Maturity Model (SAMM) и Building Security In Maturity Model (BSIMM) для оценки текущего уровня зрелости, а также в качестве методологической основы для построения процессов обеспечения безопасности разработки. В рамках предлагаемых методик выделяются четыре основных направления развития процессов управления безопасностью разработки или бизнес-функций: корпоративное управление (Governance), разработка (Construction), контроль (Verification), развертывание и эксплуатация (Deployment).
  • 50. ЗаголовокBuilding Security In Maturity Model (BSIMM)
  • 51. ЗаголовокThe Building Security In Maturity Model (BSIMM)
  • 52. Заголовок Практические выводы • Основные заблуждения про SDL – снимаем • C чего начинать, в каком порядке? • Disclaimer – о чем обязан предупредить • C чем будут трудности у руководителя • Предостережения разработчику • Как преодолевать (тезисно и справочно) • Знание – Сила! И другие полезности Что важно, что забрать с собой
  • 53. ЗаголовокСнимаем основные заблуждения об SDL • SDL независим от платформы и языка разработки • SDL подходит для разных сценариев разработки включая бизнес-приложения и онлайн-сервисы • SDL применим к разным методологиям разработки, таким как водопад и agile • Успешная реализация SDL предполагает автоматизацию с помощью инструментов. Вы можете использовать инструменты от других компаний • SDL подходит организациям любого размера. От разработчика-одиночки до огромных корпораций
  • 54. ЗаголовокПочему независимы от процессов и методологий? Потому что привязка идет к артефактам!
  • 55. ЗаголовокПро автоматизацию Качество и полнота выходных данных, полученных на каждом этапе / фазе, очень важны. The SDL process does benefit from investments in effective tools & automation but the real value lies in comprehensive & accurate results.
  • 56. ЗаголовокВнедрение SDL – вариант от MSFT SDL Team, 2014
  • 57. ЗаголовокВнедрение SDL – еще вариант 1. Обучение 2. Практики безопасного программирования 3. Тестирование безопасности и анализ кода 4. Процедуры выпуска и поддержки 5. Отслеживание уязвимостей, реестр ПО 6. Формальное определение требований к ИБ 7. Планы реагирования на инциденты 8. Моделирование угроз, анализ поверхности атак 9. Внешний анализ
  • 58. ЗаголовокДобавь безопасность в твой процесс разработки!
  • 59. ЗаголовокНе делай то, что делает MSFT, делай, что сделал! Предупреждение от Securosis Adopting MS-SDL wholesale is a little like a child putting on adult clothes because they want to be ‘big’. You cannot drop that particular process into your development organization and have it fit. More likely you will break everything. Your team will need to change their skills and priorities, and though it sounds cliche, people are resistant to change. Existing processes need to be adjusted to accommodate secure development processes and techniques. You will need new tools, or to augment existing ones. You will need a whole new class of metrics and tracking. And everything you pick the first time will need several iterations of alteration and adjustment before you get it right – this isn’t Microsoft’s first attempt either.
  • 60. Заголовок«Стандартные» затыки – менеджерам на заметку Не надо: • Слишком полагаться на тестирование на поздних этапах цикла • Управлять без измерений • Обучать, не оценив • Начинать без достаточной поддержки руководства • Политические риски • Бюджетные риски • Стандартные для дисциплины Управление Изменениями (организационными, в частности) – у нас максимум сложности: люди, процессы, технологии Обучение, ответственность и ясные цели – ключевые компоненты успеха любой программы по безопасности
  • 61. Заголовок3 предостережения – разработчикам • Не надо думать о безопасности ПО как о проблемах кодирования. McGraw метко называет это явление «парад багов» • Неверно убеждение, что software security про то, как грамотно адаптировать или использовать различные фичи или соглашения по безопасности. Software security скорее про страховку, чем про фичи / функциональность • Последнее предупреждение – не полагайтесь чересчур на чеклисты. Тот же STRIDE в моделировании угроз. Чеклисты устаревают без обновления по результатам открытий и не всегда полны Основанный на фичах подход к безопасности зовут иногда ‘cookbook’ approach. Конечно, поможет с рецептом, но просто чтение книги без включения плиты и пробы блюда вряд ли сделает из вас хорошего повара. Опыт – самый могущественный учитель.
  • 62. ЗаголовокСтроим успешную программу по безопасности • Сделай план под себя: выявляй зависимости и планируй. Пошаговые изменения – см. дальше. Знай, как у тебя все работает, и ищи грамотный путь улучшить с использованием лучших практик • Выкатывай отдельные инициативы аккуратно: найди чемпиона для каждой и надели ответственностью. Не оставляй без помощи – коучинг и наставничество. Пилоты и прототипы – не надо на всех сразу накатывать сырое • Обучай людей: разработчики и архитекторы могут не подозревать, как много тут от них зависит. Обучение и воспитание • Заложи основу метрикам: измеряй и оценивай прогресс. Метрики (в т. ч. относительно себя прошлого и по бизнес-показателям) и измерения – без них никуда в любой большой организации. В идеале надо накрыть четыре зоны: project, process, product and organization. Первые три вокруг artifact or activity в разработке, четвертая, чтобы определять тренды вокруг первых трех • Установи и поддерживай способность к постоянным изменениям: создавай условия путем постоянных измерений и оценки результатов, периодически переводя внимание на отстающие аспекты своей программы повышения уровня безопасной разработки
  • 63. ЗаголовокРекомендации от первопроходцев SDL • Перестать кровоточить / Stop the bleeding • SAST или переход на процесс анализа рисков • Собери все, что назрело / Harvest the low-hanging fruit • Хороший барометр, готова ли организация меняться реально • Заложи основание / Establish a foundation • Создай контроль изменений / Creating change control programs • Построй анализ первопричин / Building root-cause analysis function • Создай контур обратной связи / Setting up critical feedback loop • Усиляй сильные качества / Craft core competencies • Развивай то, что дает различия / Develop differentiators • Строй все, что осталось / Build out nice-to-haves
  • 64. ЗаголовокДля мастодонтов это может выглядеть так: PDCA Первая волна (первая фаза) проведение инвентаризации, оценки и анализа текущего уровня зрелости разработки с точки зрения безопасности. Внедрение или повышение уровня базовых практик безопасности. Создание рабочей группы безопасности приложений. Целевое обучение участников группы. Подготовка плана повышения уровня зрелости разработки с точки зрения ИБ. Вторая волна (вторая и третья фазы) – реализация плана повышения уровня зрелости разработки с точки зрения ИБ. В рамках второй фазы проводятся основные активности, осуществляется внедрение основных технических и организационных механизмов, разработка необходимой документации. Проводится массовое обучение сотрудников практикам безопасной разработки и приемам использования внедряемых инструментов, разработчикатываются метрики оценки практик безопасности. Третья фаза позволяет оценить успешность мероприятий второй фазы, исправить явные недочеты и подготовить план повышения уровня зрелости для третей волны. Третья волна (четвертая и пятая фазы) – в рамках третьей волны реализуется план повышения уровня зрелости с учетом опыта третьей фазы. Также внедряются дополнительные организационные и технические механизмы, необходимость которых была выявлена в ходе реализации второй и третьей фазы. В рамках пятой фазы проводится сопровождение внедренных практик безопасности и оценка эффективности текущего уровня зрелости. Оценочная продолжительность каждой из фаз – 6 месяцев. PDCA = Plan – Do – Check - Act
  • 65. ЗаголовокЗнание – Сила. Как можно организовать? Software Security Unified Knowledge Architecture Seven knowledge catalogs (principles, guidelines, rules, vulnerabilities, exploits, attack patterns, and historical risks) are grouped into three knowledge categories (prescriptive knowledge, diagnostic knowledge, and historical knowledge). Experience, Expertise, and Security Software developers place a high premium on knowledge. Experience is king, and expertise is very valuable.
  • 66. Заголовок ptsecurity.com Выгоды и выводы • Для разработчиков • Для руководителей
  • 67. ЗаголовокВыгоды SDL / SSDL для разработчиков 1. Меньше времени на переделывание и отладку 2. Меньше времени на тестирование 3. Меньше времени на поддержку и проще развитие 4. Отлов проблем как можно раньше 5. Избегаем повторяющихся security issues 6. Избегаем несогласованных уровней безопасности 7. Повышаем экспертизу и опыт в безопасности 8. Выше продуктивность + чаще укладываемся в сроки 1. Качественный код 2. Больше времени на работу и развитие 3. Проактивность
  • 68. ЗаголовокВыгоды SDL / SSDL для руководителей Более защищенная, безопасная и надежная разработка, которая: • Увеличивает ROI и качество ВАШЕГО продукта / сервиса • Снижает риски (в т. ч. «завалить» проект, получить качество продукта ниже ожиданий, превысить бюджет или сроки, а также связанные с интеллектуальной собственностью) • Минимизирует возможный ущерб и стоимость инцидентов • Снижает стоимость разработки, поддержки и общую стоимость владения • Помогает соответствовать требованиям (compliance) • Повышает уровень удовлетворенности у Заказчика и Команды • Повышает продуктивность • Уменьшает сроки / график / расписание
  • 69. ЗаголовокНе пора ли применить SDL / SSDL? Исследование Aberdeen Предотвращение одной уязвимости почти полностью покрывает годовые затраты на повышение безопасности разработки Исследование Forrester Компании, применяющие методы SDL, демонстрируют гораздо более быстрый возврат инвестиций Предотвратить проблему с безопасностью в 4 раза дешевле, чем разбираться с ее последствиями!
  • 70. Заголовок Подведем итог • Атаки переходят на уровень приложений Are your product Popular? Next Target! • Разработка защищенного кода с помощью процесса безопасной разработки – экономия денег Компании, снижение рисков и повышение качества продукта •Пора попробовать SDL!
  • 71. ЗаголовокЧто почитать (1 / 2) • Building Security In – обязательно к прочтению • Дао безопасности от Геннадия Махметова • SDL by Microsoft все про SDL от MSFT • Книга по SDL от Ховарда и Липнера (главный за SDL в Microsoft) • Упрощенный SDL на русском (и оригинал) • SDL Best Practices for Developers, BUILD 2014 (45 min video) • Alexey Sintsov SDLC Implement me or Die (SDL+DevOps) • Алексей Бабенко Цикл безопасной разработки SDL • Andrey Beshkov on SDL & ALM (1, 2) • Nazar Tymoshyk on SDL & Agile (1, 2, 3)
  • 72. ЗаголовокЧто почитать (2 / 2) • Безопасное программирование http://cwe.mitre.org http://owasp.org • Общие базы данных уязвимостей http://www.securityfocus.com http://nvd.nist.gov http://secunia.com • Информация по внешнему обучению http://www.sans.org/security-training.php • Материалы для организации внутреннего обучения OWASP Code Review Project OWASP Top 10 Project http://www.sans.org/top25-software-errors http://www.cert.org/secure-coding
  • 73. ЗаголовокМоделирование угроз. Ссылки 1. Application Threat Modeling на сайте OWASP 2. Статья с описанием подхода на Хабре от Владимира Кочеткова, PT 3. Обнаружение недостатков безопасности при помощи STRIDE (MSDN Magazine) 4. The STRIDE Threat Model на сайте Microsoft 5. Microsoft Threat Modeling Tool 2016
  • 74. ЗаголовокМинутка рекламы Ищем • SDL/SSDL сообщество – тех, кому интересна «жизнь по SSDL» • Тех, кто готов делиться опытом, уже живет или находится в процессе перехода на SDL • Разработчиков на С#, QA, фронтендеров, аналитиков в Новосибирск bit.ly/PT_Novosibirsk_job • …и другие города тоже www.ptsecurity.com/about/vacancy
  • 75. ЗаголовокПара видео - как мы живем, работаем, отдыхаем :) Backstage Positive Technologies 13 лет! https://youtu.be/1_zNxMHyCZk Присоединяйтесь! Будем работать по / в цикле безопасной разработки вместе :)