Заголовок

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

WatchAlert and Mobilize

ResourcesAssess and

StabilizeResolve

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 andorganization. Первые три вокруг 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