Построение процесса безопасной разработки - Стачка 2016

Стачка 2016ptsecurity.com

Валерий Боронин

Построение процесса безопасной разработки - что это означает на практике для разработчиков и их руководителей?

Валерий БоронинВ разработке и R&D более 20 лет

Начинал еще под Windows 3.1

Достиг определенных высот разработчиком режима ядра под Windows (до 2009)

В безопасности с прошлого тысячелетия ;-)

Работал CTO небольшой компании (30+ человек)

Директором по исследованиям большой (Лаборатория Касперского, 2500+ человек, 2009-2014)

Сейчас отвечаю за направление безопасной разработки (SDL / SSDL) в Позитиве.

Мы с командой создаем новый продукт по автоматизации безопасной разработки.

23 апреля 2016 Стачка, Ульяновск 2

http://www.linkedin.com/in/boronin

mailto:[email protected]?subject=Стачка 2016 SSDL

1.Зачем нужна безопасность?

2.Что такое защищенное

приложение?

3.Почему ПО небезопасно?

4.Разработчики и Безопасность

5.Что такое SDL/SSDL =

безопасная разработка?

6.Зачем нужна?

7.Какие проблемы решает?

О чем поговорим в начале?

Зачем нужна безопасность Вашим заказчикам?


Отраслевые требования

Государственное регулирование

Доступность Бизнеса

КапитализацияСтатистика нарушений

Требования Заказчика

Предыдущий плохой опыт

Последствия проблем с безопасностью


Доверие

Деньги

Данныеутекшие

ВремяНа восстановление

Ущербпо инциденту

Заказчики

Репутация

Безопасность на стыке с надежностью:у вас 5 компонентов в e-commerce

приложении с 98% uptime каждый? Ожидайте 150 мин простоя в день!*

*Источник: книга Gary McGraw (https://www.garymcgraw.com/)

https://www.garymcgraw.com/

Зачем? Наши реалии


Большинство обнаруживаемых

уязвимостей –типовые,

общеизвестные, хорошо описанные.

Статистика по распределению уязвимостей web приложений за 2015 год

Источник: по данным аналитического центра Positive Technologies, серым - 2014

http://www.ptsecurity.ru/analytics

Почему мы об этом говорим?


Источник: по данным аналитического центра Positive Technologies за 2015

59%

80%

100% 100%

65%

20%

Черный/серый ящик Белый ящик

Высокий Средний Низкий

56%

69%

88%

100% 100% 100%

44%

38%

75%

0%

20%

40%

60%

80%

100%

120%

PHP Java ДругиеВысокий Средний Низкий

http://www.ptsecurity.ru/analytics

Обычно подразумевается:

Безопасная разработка

Контроль целостности

Правильная эксплуатация

…а по версии ФСТЭК?

+ документация и конфигурации

+ инфраструктура среды разработки

+ люди

Что такое защищенное ПО?

23 апреля 2016 Стачка, 2016, Ульяновск 8

Хорошо работает то, что хорошо управляется В. В. Путин

Быть на шаг впереди, в постоянном ожидании сбоя.

Работать даже тогда, когда твоего сбоя яростно ожидает оппонент.

Защищенное ПО гораздо больше вкладывает в учет проблемных кейсов, чем не имеющих проблем.

На шаг впереди – вот девиз проектировщиков и других безопасных разработчиков.

Что такое защищенное ПО?


Источник: вступительное слово к замечательной книге Gary McGraw (первопроходец в SDL)

https://www.garymcgraw.com/

http://www.garymcgraw.com/

VS.

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

Почему простого цикла разработки \ анализа-исправления кода недостаточно?

Полный разбор в блестящем анализе от Геннадия Махметова

http://makhmetov.ru/news/dao.html

Нужно

проактивноепроектирование

+

exploit-drivenтестирование

+

все это на базе управления рисками

Что же делать?


Три основания безопасной \ защищенной разработки:

управление рисками, лучшие практики и

Знание

“Program testing can be used to show thepresence 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? Взгляд руководителя




Источник: McGraw book, 2008



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

https://www.microsoft.com/en-us/SDL/Resources/faq.aspx?0364be84-b686-49f9-9e24-29d86e2af994=True



Источник: 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 $1spent

*Источник: http://namcookanalytics.com/software-quality-survey-state-art/

http://namcookanalytics.com/software-quality-survey-state-art/

Безопасность - это дорого – 1 / 2





Безопасность - это дорого – 2 / 2





Безопасность – трудно найти и трудно исправить

HIGHLIGHTS FROM THE2015 WORLD SW QUALITY REPORT

…Security is the most

pressing concern




1. Качественный код (безопасное и качественное ПО)

2. Больше времени на работу (и собственноеразвитие!)

3. ПроактивностьРеактивность(быть причиной)

…Все правильно сделал!

Зачем нужен SDL? Взгляд разработчика


1.Применимость

2.Когда разработка становится безопасной?

3.Роли, ответственность, квалиф. требования

4.Обязательные активности (16 практик)

5.Дополнительные активности

6.О чем еще стоит упомянуть?

7.Процедура проверки безопасности

приложения

8.Так этих SDL’ей …много и разных?!

Минуточку! Попрошу поподробнее! Что же такое SDL? Из чего состоит?

Security Development Lifecycle (SDL) – must have


Обучение•Начальное

обучение безопасности

Требования•Определение

требований по безопасности

•Оценка рисков

•Create Quality Gates/Bug Bars

Дизайн•Установить

требования к дизайну

•Анализ поверхности атаки

•Моделированиеугроз

Реализация•Выбор

инструментов

•Блокирование запрещенных функций

•Статический анализ

Проверка•Динамический

анализ

•Fuzz Testing

•Проверка поверхности атаки

Выпуск•План

реагирования на инциденты

•Финальный анализ безопасности

•Доверенный выпуск

Реагирование

•Выполнение плана реагирования

http://www.microsoft.com/security/sdl/default.aspx

Технология и процессОбучение Ответственность

McGraw - Education, accountability, and clear objectives are critical components to any successful software security initiative.

http://www.microsoft.com/security/sdl/default.aspx

Модель помогает определить текущий уровень зрелости компании и разработать пландействий по внедрению соответствующих процессов для реализации полноценного цикла безопасной разработки

Так когда разработка становится безопасной?

Что такой упрощенный SDL?


Зрелость Организации

SDL – Применимость

Ваше приложение:

Работает в бизнес- или корпоративном окружении?

Обрабатывает \ хранит персданные или sensitive информацию?

Взаимодействует по Сети \ другим каналампередачи информации?

Практика показывает, что сложно найти приложение, которому не показан SDL.23 апреля 2016 Стачка, Ульяновск 31

Советник по безопасности \конфиденциальности (снаружи)

• Аудитор (подчиненная роль)

• Эксперт (подчиненная роль)

• Можно совмещать аудитора с экспертом

• Советников тоже можно совмещать

Руководители групп по безопасности \конфиденциальности (изнутри)

• отвечает за координацию и отслеживание вопросов безопасности на проекте + сообщает состояние Советнику и другим ЗЛ

• можно совмещать роли security и privacy champions

SDL – Люди - формализация ролей и обязанностей


SDL Фаза 1 - Обучение

1. Все задействованные сотрудники в технических ролях (Devs, QA, PMs)

2. Не реже 1 раза в год

3. Знания для выполнения остальных фаз + как работаем по новому процессу

Обследовать подготовленность организации по темам безопасности и защиты данных (privacy)

При необходимости создать стандартные курсы обучения


Разработать критерии качества программы обученияСодержимое должно покрывать темы со след слайда

Определить частоту тренинговРазработчик должен пройти не менее Х тренингов в год

Определить минимальный приемлемый порог тренингов в группе разработки75% техперсонала должны пройти базовые тренинги до выпуска беты

Безопасность – дело каждого!

https://www.microsoft.com/en-us/sdl/process/training.aspx

1. Безопасный дизайн

уменьшение поверхности атаки

наименьшие привилегии

многослойная защита

безопасные настройки по умолчанию

2. Моделирование угроз

3. Безопасное кодирование(переполнение буфера, XSS, SQL инъекции, криптография)

4. Тестирование безопасности

разница с функциональным тестированием

оценка рисков

методы тестирования безопасности

5. Защита информации \ Privacy \Соответствие требованиям

Персданные, ФЗ 152 и отраслевые стандарты

Трансграничная передача данных

Обработка, хранение и т.п. чувствительных данных – ФЗ 242

6. …

…

Trusted user interface design

…

SDL Фаза 1 – Обучение: чему учить?

Безопасность – дело каждого!


https://www.microsoft.com/en-us/sdl/process/training.aspx

Возможность заложить безопасный фундамент для проекта

Определение требований по безопасности (разово) SDL Practice #2: Establish Security and Privacy Requirements

Определить и задокументировать порог отбраковки продукта по ошибкам связанным с безопасностью и защитой данных (разово) SDL Practice #3: Create Quality Gates/Bug Bars

Оценка рисков SDL Practice #4: Perform Security and Privacy Risk Assessments (разово)

SDL Фаза 2 - Требования


https://www.microsoft.com/en-us/sdl/process/requirements.aspx

http://www.microsoft.com/security/sdl/process/requirements.aspx

http://www.microsoft.com/security/sdl/process/requirements.aspx

https://www.microsoft.com/en-us/sdl/process/requirements.aspx

SDL Фаза 3 - Проектирование

1. Архитектурные требования (разово)

Определить и задокументировать архитектуру безопасности и идентифицировать критические компоненты безопасности

2. Анализ / сокращение поверхности атаки (разово)

Задокументировать поверхность атаки продукта.

Ограничить ее установками по умолчанию

3. Моделирование угроз

Определить угрозы и меры снижения угроз

Систематический пересмотр свойств продукта и его архитектуры с точки зрения безопасности

Определить критерии выпуска обновления продукта в связи с изменением в безопасности продукта


https://www.microsoft.com/en-us/sdl/process/design.aspx

SDL Threat Modeling Tool (TMT) - справочноФормализует и упрощает моделирование угроз так чтобы им мог заниматься архитектор


Обучает созданию диаграмм угрозАнализ угроз и мер защитыИнтеграция с багтреккером

Отчеты по угрозам и уязвимостям

SDL Фаза 4 - Реализация

Разработка кода и ревью процессов, документации и инструментов необходимых для безопасного развертывания и эксплуатации разрабатываемого продукта

Использование утвержденных \ доверенных средств и их аналогов

Практики безопасного программирования

Статический анализ кода


Конкретно: Поиск случаев использования запрещенных APIПрименение механизмов защиты предоставляемых ОСИспользование безопасных версий библиотек и фреймворковСоблюдение специфических требований безопасности (XSS, SQL иньекции…)

http://www.microsoft.com/security/sdl/process/implementation.aspx

http://www.ptsecurity.com/AI

Начните тестирование как можно раньше. В идеале как только появился готовый для этого код.

Динамический анализ

Фаззинг – файлами, вводом данных в интерфейсные элементы и код сетевой подсистемы

Повторно проверьте модели угроз, риски, поверхность атаки. Все ли вы учли?

SDL Фаза 5 – Проверка (Тестирование)


• Начните планирование процесса реагирования на обнаружение уязвимостей в выпущенном продукте – см след стадию

• При необходимости выполнить “security push” (с каждым разом все реже)• Не является заменой работе над безопасностью в процессе разработки• Ревью кода• Тестирование на проникновение• Ревью дизайна и архитектуры в свете вновь обнаруженных угроз

http://www.microsoft.com/security/sdl/process/verification.aspx

BinScope Binary Analyzer

Убедиться что SDL соблюден при компиляции и сборке

MiniFuzz File Fuzzer

!exploitable в WinDbg

DAST

RegexFuzer

DAST

Attack Surface Analyzer

Анализ снимков системы

Измеряет потенциальную поверхность атаки на приложение и ОС

AppVerifier

Динамический анализ системы

MSF Agile + SDL шаблоны для TFS

Автоматически создает процессы соблюдения SDL в момент создания нового спринта или выполнения check in.

Контролирует выполнение всех необходимых процессов безопасности

CMMI Шаблоны SDL для TFS

SDL требования как задачи

SDL-based check-in policies

Создание отчета Final Security Review

Интеграция с инструментами сторонних производителей

Библиотека пошаговых указаний SDL how-to

SDL Фаза 5 – Проверка: Инструменты (справочно)


http://www.microsoft.com/security/sdl/process/verification.aspx

Создать политики поддержки продукта

Создать план реагирования на инциденты безопасности

Группа инженерной поддержки ресурсы внутри и снаружи организации для адекватной реакции на обнаружение уязвимостей и защиту от атак

контактные данные лиц, доступных 24x7x365

• 3-5 инженеров

• 3-5 специалистов из маркетинга

• 1-2 менеджеров верхнего уровня

Обратите внимание на

необходимость выпуска экстренных обновлений вашего продукта из-за уязвимостей в унаследованном коде

• от других групп в той же организации

• сторонних производителей

включенном в ваш продукт

Лицензионные условия, возможность вносить изменения, имена файлов, версии, контактные данные и т.п.

может быть необходимость обновлять продукт после обновления ОС и т.п.

SDL Фаза 6 – Выпуск: план реагирования


WatchAlert and Mobilize

ResourcesAssess and

StabilizeResolve

Reporting

Analysis and Mitigation

Create Fix

Update Models

Test Fix

Выпуск

Lessons Learned

Provide Guidance

http://www.microsoft.com/security/msrc/whatwedo/responding.aspx

http://www.microsoft.com/security/sdl/process/release.aspx

http://www.microsoft.com/security/msrc/whatwedo/responding.aspx

SDL Фаза 6 – Выпуск: Final Security Review (FSR)Проверить продукт на соответствие требованиям SDL и отсутствие известных уязвимостей.

Получаем независимое заключение готовности продукта к выпуску

FSR не является:

Тестом на проникновение. Запрещено ломать и обновлять продукт.

Первой проверкой безопасности продукта

Процессом финальной подписи продукта и отправки его в тираж

FSR должен обязательно включать три возможных результата окончательной проверки безопасности:

1. можно выпускать

2. можно выпускать с ограничениями (и есть план по их душу)

3. FSR с эскалацией (на руководство Компании)


Ключевая концепция: Эта фаза не используется как точка для завершения всех задач пропущенных на предыдущих стадиях


План реагирования на инциденты безопасности создан

Документация для клиентов обновлена

Создан централизованный архив всего, что поможет с сервисным обслуживанием релиза

снизить стоимость поддержки в долгосрочной перспективе

Обязательно включить в архивИсходники

Приватные отладочные символы

Модели угроз

Документацию –техническую и пользовательскую

Планы реагирования

Лицензионные и прочие servicing terms для используемого стороннего ПО

SDL Фаза 6 – Выпуск: Заверить релиз и – в Архив



Инцидент случился? Идем по заранее созданному плану.

Выполняем активности по плану реагирования на инциденты безопасности

выпускаем обновления в соответствии с графиком релизов

Пересчитываем риски

Информируем клиентов

Публикуем информацию

Выгоды планового реагирования

Понятно что происходит

Есть ответственные

Удовлетворенность клиента растет

Собираем данные для будущих разработок

Проводим тренинги

SDL Фаза 7 – Реагирование на инциденты


Не если, а когда!


1. Сode review глазом

важные компоненты

где храним, обрабатываем, передаем sensitive данные

криптография

2. Анализ уязвимостей схожих приложений (конкурентов)

3. Тесты на проникновение (но сделать до FSR!)

SDL – Доп. меры – что бы сделать еще?


Улучшаем процесс дальше:

1. Анализ первопричин Исследование причин появления найденных уязвимостей (из-за чего она возникла – человеческая ошибка? несовершенство процесса? ошибка автоматизации?)

2. Регулярное обновление процесса

Специальные меры по хранению артефактов через приложение со строгим контролем доступа (RBAC)

Руководители групп безопасности и конфиденциальности обеспечивают ввод данных и их корректность

Их используют Советники, обеспечивая среду для FSR и для анализа, а также подтверждениявыполнения всех требований

Обязательно хранить

требования безопасности и конфиденциальности для организации

функц. и тех. требования для разрабатываемого приложения

рабочий контекст приложения (Ex: процедура отслеживания)

SDL – Процедура проверки безопасности приложения


1. Требования (Product Security Requirements)

2. 3rd Party Security

3. Проектирование(Secure Design)

4. Реализация (Secure Coding)

5. Оценка (Secure Analysis)

6. Тестирование (Vulnerability Testing)

Cisco SDL – так их, оказывается, много и разных?!


http://www.cisco.com/c/en/us/about/security-center/security-programs/secure-development-lifecycle.html

Cisco SDL Microsoft SDL PA-DSS SDL РС БР ИББС-2.6-2014)

Обучение разработчиков Secure Design, Secure Coding Training Обучение -

Отслеживание уязвимостей

3rd Party Security Implementation (частично) Выявление уязвимостей Эксплуатация

Определение требований к ИБ

Product Security Requirements Requirements Проектирование Проектирование

Создание модели угроз Secure Design Design Оценка рисковРазработка технического задания (рекомендательно)

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

Secure Coding Implementation Создание -

Анализ кода Secure Analysis Implementation Анализ кодаСоздание и тестирование (рекомендательно)

Тестирование безопасности

Vulnerability Testing Verification, ReleaseТестирование безопасности

Создание и тестирование

Выпуск релиза - Release Выпуск Прием и ввод в действие

Поддержка - Response Поддержка Сопровождение и модернизация

Вывод из эксплуатации - Снятие с эксплуатации

Сравнение SDL – справочно

Источник


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)


http://bsimm2.com/

1.Основные заблуждения про SDL - снимаем

2.C чего начинать, в каком порядке?

3.Disclaimer – о чем обязан предупредить

4.C чем будут трудности у руководителя

5.Предостережения разработчику

6.Как преодолевать (тезисно и справочно)

7.Знание – Сила! И другие полезности

Практические выводы, что важно, что забрать с собой

Снимаем основные заблуждения об 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.


https://securosis.com/blog/firestarter-secure-development-lifecycle-your-doing-it-wrong

«Стандартные» затыки – менеджерам на заметку

Не надо

Слишком полагаться на тестирование на поздних этапах цикла

Управлять без измерений

Обучать, не оценив

Начинать без достаточной поддержки руководства

Политические риски

Бюджетные риски

Стандартные для дисциплины Управление Изменениями (организационными, в частности) – у нас максимум сложности: люди, процессы, технологии


Обучение, ответственность и ясные цели – ключевые компоненты успеха любой программы по безопасности.

1. Не надо думать о безопасности ПО как о проблемах кодирования. McGraw метко называет это явление «парад багов».

2. Неверно убеждение, что software security про то как грамотно адаптировать или использовать различные фичи или соглашения по безопасности. Software security скорее про страховку, чем про фичи \ функциональность.

3. Последнее предупреждение – не полагайтесь чересчур на чеклисты. Тот же STRIDE в моделировании угроз. Чеклисты устаревают без обновления по результатам открытий и не всегда полны.

3 Предостережения - разработчикам


Основанный на фичах подход к безопасности зовут иногда "cookbook"approach. Конечно, поможет с рецептом, но просто чтение книги безвключения плиты и пробы блюда вряд ли сделает из вас хорошего повара.

Опыт – самый могущественный учитель.

Строим успешную программу по безопасности1. Сделай план под себя: Выявляй зависимости и планируй. Пошаговые

изменения – см дальше. Знай как у тебя все работает и ищи грамотный путь улучшить с использованием лучших практик.

2. Выкатывай отдельные инициативы аккуратно: найди чемпиона для каждой и надели ответственностью. Не оставляй без помощи – коучинги наставничество. Пилоты и прототипы – не надо на всех сразу накатывать сырое.

3. Обучай людей: разработчики и архитекторы могут не подозревать как много тут от них зависит. Обучение и воспитание.

4. Заложи основу метрикам: Меряй и оценивай прогресс. Метрики (в т. ч. относительно себя прошлого и по бизнес-показателям) и измерения –без них никуда в любой большой организации. В идеале надо накрыть 4 зоны: project, process, product, and organization. Первые 3 вокруг artifact or activity в разработке, 4я чтобы определять тренды вокруг первых трех.

5. Установи и поддерживай способность к постоянным изменениям: Создавай условия путем постоянных измерений и оценки результатов периодически переводя внимание на отстающие аспекты своей программы повышения уровня безопасной разработки.


3 фундаментальных шага: (1) оцени и планируй (2) строй и пилотируй и (3) распространяй и улучшай!

Рекомендации от первопроходцев SDL

1. Перестать кровоточить \ Stop the bleeding.

SAST или переход на процесс анализа рисков

2. Собери все, что назрело \ Harvest the low-hanging fruit.

Хороший барометр, готова ли организация меняться реально

3. Заложи основание \ Establish a foundation.

Создай контроль изменений \ Creating change control programs

Построй анализ первопричин \ Building root-cause analysis function

Создай контур обратной связи \ Setting up critical feedback loop

4. Усиляй сильные качества \ Craft core competencies.

5. Развивай то, что дает различия \ Develop differentiators.

6. Строй все, что осталось \ Build out nice-to-haves.


Для мастодонтов это может выглядеть так: 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. Проактивность

20-40%

Выгоды SDL / SSDL для руководителейБолее защищенная, безопасная и надежная разработка, которая

1. Увеличивает ROI и качество ВАШЕГО продукта\сервиса

2. Снижает риски (в т.ч. «завалить» проект, получить качество продукта ниже ожиданий, превысить бюджет или сроки, а также связанные с Интеллектуальной Собственностью)

3. Минимизирует возможный ущерб и стоимость инцидентов

4. Снижает стоимость разработки, поддержки и общуюстоимость владения

5. Помогает соответствовать требованиям (compliance)

6. Повышает уровень удовлетворенности у Заказчика и Команды

7. Повышает продуктивность

8. Уменьшает сроки \ график \ расписание


Не пора ли применить SDL / SSDL?

Исследование Aberdeen: Предотвращение одной уязвимости почти полностью покрывает годовыезатраты на повышение безопасности разработки

Исследование Forrester:Компании применяющие методы SDL демонстрируют гораздо более быстрый возврат инвестиций


Предотвратить проблему с безопасностью в 4 раза дешевле, чем разбираться с ее последствиями.



Подведем итогАтаки переходят на уровень приложений.Are your product Popular? Next Target!

Разработка защищенного кода с помощью процесса безопасной разработки –экономия денег Компании, снижение рискови повышение качества продукта

Пора попробовать SDL!

ptsecurity.com

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)Алексей Бабенко Цикл безопасной

разработки SDLAndrey Beshkov on SDL & ALM (1, 2)Nazar Tymoshyk on SDL & Agile (1, 2, 3)

Что почитать 1 \ 2


http://www.swsec.com/

http://makhmetov.ru/articles/dao-of-software-security.html

https://www.microsoft.com/en-us/sdl/

http://www.amazon.com/Security-Development-Lifecycle-Michael-Howard/dp/0735622140

https://www.microsoft.com/ru-RU/download/confirmation.aspx?id=12379

http://go.microsoft.com/?linkid=9708425

https://channel9.msdn.com/Events/Build/2014/2-546

http://www.slideshare.net/DefconRussia/sdlc-38863452

http://www.slideshare.net/arekusux/sdl-38135128

http://www.slideshare.net/abeshkov/

http://www.slideshare.net/abeshkov/microsoft-sdl

https://www.techdays.ru/videos/7396.html

http://www.slideshare.net/NazarTymoshyk

http://www.slideshare.net/NazarTymoshyk/security-as-a-new-metric-for-business-product-and-development-lifecycle

http://www.slideshare.net/NazarTymoshyk/agile-and-secure-sdlc

http://www.slideshare.net/NazarTymoshyk/agile-and-secure-development

http://www.amazon.com/Security-Development-Lifecycle-Michael-Howard/dp/0735622140

Что почитать 2 \ 2Безопасное программирование

http://cwe.mitre.orghttp://owasp.org

Общие базы данных уязвимостейhttp://www.securityfocus.comhttp://nvd.nist.govhttp://secunia.com

Информация по внешнему обучениюhttp://www.sans.org/security-training.php

Материалы для организации внутреннего обученияOWASP Code Review ProjectOWASP Top 10 Projecthttp://www.sans.org/top25-software-errorshttp://www.cert.org/secure-coding


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

https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_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

Моделирование угроз – Ссылки


https://www.owasp.org/index.php/Application_Threat_Modeling

http://habrahabr.ru/post/129386/

http://msdn.microsoft.com/ru-ru/magazine/cc163519.aspx#S10

http://msdn.microsoft.com/en-US/library/ee823878(v=cs.20).aspx

http://blogs.microsoft.com/cybertrust/2015/10/07/whats-new-with-microsoft-threat-modeling-tool-2016/

Стачка 2016

ptsecurity.com

Спасибо!

Вопросы?

- Вопросы, Идеи, Уточнения

- А давайте попробуем <> ?!

- Хочу работать вместе!

mailto:[email protected]?subject=Стачка 2016 SSDL

Ищем

SDL/SSDL сообщество –тех, кому интересна “жизнь по SSDL”

Кто готов делиться опытом – уже живет или в процессе перехода на SDL

разработчиков на С#, QA, фронтендеров, аналитиковв Новосибирскbit.ly/PT_Novosibirsk_job

…и другие города тоже www.ptsecurity.com/about/vacancy

Минутка Рекламы


http://bit.ly/PT_Novosibirsk_job

http://www.ptsecurity.com/about/vacancy

Раздатка для Стачки


Пара видео - как мы живем, работаем, отдыхаем )


Backstage

Positive Technologies 13 лет!https://youtu.be/1_zNxMHyCZk

Присоединяйтесь!Будем работать по \ в цикле безопасной разработки вместе )

https://youtu.be/1_zNxMHyCZk

https://youtu.be/RKa9FnfMyig

https://youtu.be/1_zNxMHyCZk