Обзор Security Development Lifecycle (SDL) – чем он может помочь разработчику

АНДРЕЙ ИВАНОВ

S&C PROGRAM MANAGER

MICROSOFT RUSSIA

ANDREYI@MICROSOFT.COM

Содержание

Текущая ситуация с безопасностью ПО

Зачем вам разработка безопасного ПО?

Практика применения SDL

Текущая ситуация в мире ИБ

1 000 000 компьютеров успешно взламываются ежедневно (1 компьютер каждые 14 секунд)

39% компьютеров в мире заражены вредоносным кодом

90% крупнейших компаний столкнулись с инцидентами ИБ

Каждый седьмой пользователь интернета сталкивался с кражей (компрометацией) идентификационных данных

Каждый 14-й скачиваемый из Интернета файл заражен

Источник: http://www.infoworld.com/d/security/16-security-problems-bigger-flame-195341?source=rss_security

Недоверенная цепочка поставки

Генераторы ключей

Инфицированное бесплатное ПО

Зараженные обновления

Музыка, фильмы

Уязвимости. Уровень риска

Источник: http://www.microsoft.com/security/sir/default.aspx

Уязвимости. Сложность эксплуатации

Уязвимости. ОС, браузеры, приложения

Уязвимости MS vs Non-MS

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

Сроки запуска проекта горят

Нет ресурсов на обеспечение безопасных практик

Мы стартап – нам нужно быстрее стать популярными и заработать много денег

Зачем вам разработка безопасного ПО?

Новейшие исследования показывают однозначную связь между разработкой безопасного ПО и бизнес эффективностью компании:

◦ Исследование Aberdeen:

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

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

◦ Исследование Forrester:

◦ Разработка безопасного ПО еще не стала широко распространенной практикой

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

Стоимость устранения уязвимостей

0

5

10

15

20

25

30Относительная стоимость устранения ошибок

Требования/ Архитектура

КодированиеИнтеграция/

Тестирование компонент

Финальное тестирование

После выпуска

Выпуск

Источник: National Institute of Standards and Technology

после выпуска дороже в 30 раз

Microsoft SDL и Windows

Источник: доклад «Windows Vista One Year Vulnerability Report», блог Microsoft Security, 23 января 2008 г.

119

66

400

242

157

Windows XP Windows Vista ОС I ОС II ОС III

До введения SDL После введения SDL

Количество уязвимостей сократилось на 45 %

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

SDL и SQL Server(исследование компании NGS Software)

8

17

20

31

Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

2000 2001 2002 2003 2004 2005 2006

Количество обнаруженных и исправленных уязвимостейпо кварталам, 2000-2006 гг.

Пакет обновления 3

(SP3) для SQL Server

2000 – первый

выпуск,

разработанный с

применением

процесса SDL

Источник: Which database is more secure? Oracle vs. Microsoft (Чья СУБД безопаснее? Oracle или Microsoft?), David Litchfield, NGS Software, 21 ноября-2006 г.

Компания MidAmerican Energy

Защита конечных пользователей

http://thenextweb.com/microsoft/2012/11/02/microsofts-security-team-is-killing-it-not-one-product-on-kasperskys-top-10-vulnerabilities-list/

http://www.securelist.com/en/analysis/204792250/IT_Threat_Evolution_Q3_2012

История развития SDL

Введение: процесс Microsoft SDL

Концепция

Выпуск

Основные принципы

Защита пользователей:

сокращение количествауязвимостей;

сокращение опасностиуязвимостей.

Практический подход

Упреждение угроз - этоне просто поиск ошибок

Решение проблем безопасностина ранних стадиях

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

Безопасность после выпуска ПО

Цели

Этапы применения SDL

Обучение

Начальноеобучениепо основам безопасности

Требования

Определение владельца от бизнеса

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

Определениетребований к качеству

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

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

Анализопасныхобластей

Реализация

Выборинструментов

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

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

Проверка

Динамическоетестирование и fuzzing

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

Выпуск

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

Заключитель-ный анализбезопасности

Архиввыпусков

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

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

SDL – обязательная политика в Майкрософт с 2004 г.

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

Постоянные улучшения процессов

Фаза: Обучение

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

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

◦ Разработать критерии качества программы обучения

◦ Содержимое должно покрывать темы, безопасного дизайна, разработки, тестирования и защиты приватных данных

◦ Определить частоту тренингов

◦ Разработчик должен пройти не менее n тренингов в год

◦ Определить минимальный приемлемый порог тренингов в группе разработки

◦ 80% процентов технического персонала должны пройти минимальные обязательные тренинги до выпуска RTM версии продукта

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

Чему учить?Минимизация поверхности атаки:

◦ Безопасный дизайн (уменьшение поверхности атаки, наименьшие привилегии, многослойная защита, безопасные настройки по умолчанию)

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

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

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

◦ Соответствие требованиям регуляторов (ФЗ 152)

Источники для обучения

Как написать безопасный код на С++, Java, Perl, PHP, ASP. NET

Защищенный код для Windows Vista

Игра «Spot the vuln»

10 уязвимостей веб проектов - OWASP Top Ten

Курсы SANS

Книга по SDL

Упрощенный SDL

Фаза: Требования

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

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

◦ Назначается ответственный за безопасность

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

◦ Определить приоритет, процедуру отслеживания и исправления ошибок (bug tracking/job assignment system)

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

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

Фаза: Проектирование

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

критические компоненты безопасности

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

установками по умолчанию

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

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

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

Устаревание криптографических алгоритмов или замена слабых алгоритмов

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

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

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

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

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

Фаза: Реализация

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

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

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

Статический анализ (/analyze (PREfast), FXCop, CAT.NET)

Поиск случаев использования запрещенных API

Применение механизмов защиты предоставляемых ОС (NX, ASLR и

HeapTermination)

Соблюдение специфических требований безопасности для сетевых

сервисов (крос сайт скриптинг , SQL иньекции и.т.д)

Использование безопасных версий библиотек и фреймворков

Прочие рекомендации ( Standard Annotation Language (SAL))

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

Фаза: Проверка

Начните проверки как можно раньше. В идеале сразу же после стадии “code complete”.

Начните планирование процесса реагирования на обнаружение уязвимостей в

выпущенном продукте

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

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

сетевой подсистемы

При необходимости выполнить “security push” (с каждым разом все реже)

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

Ревью кода

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

Ревью дизайна и архитектуры в свете вновь обнаруженных угроз

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

Фаза: Проверка -Инструменты

BinScope Binary Analyzer

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

MiniFuzz File Fuzzer

◦ !exploitable

RegexFuzer

Attack Surface Analyzer

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

AppVerifier

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

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

MiniFuzz File Fuzzer• MiniFuzz основной

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

приложение поврежденные данные

– Выявляет не декларированное поведение приложения

– Используется отдельно или в составе Visual Studio и Team Foundation Server

Attack Surface Analyzer

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

Может использоваться разработчиками, тестировщиками, ИТ специалистами.

Отображает изменения вносимые в чистую копию Windows ОС после установки приложения.

Проверяет◦ Новые или измененные файлы

◦ Ключи реестра

◦ Сервисы

◦ ActiveX

◦ Открытые сетевые порты

◦ Списки доступа ACL

◦ Browser Helper Objects

◦ И.т.д

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

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

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

Software Security Incident Response Plan (SSIRP)

Контакты и ресурсы внутри организации для адекватной реакции

на обнаружение уязвимостей и защиту от атак

24x7x365 контакт с 3-5 инженерами, 3-5 специалистами

маркетинга, и 1-2 менеджеров верхнего уровня

Обратите внимание на необходимость выпуска экстренных

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

сторонних производителей включенном в ваш продукт. Так же

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

обновления ОС.

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

Фаза: Выпуск – Final Security Review (FSR)

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

уязвимостей

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

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

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

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

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

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

завершения всех задач пропущенных на предыдущих стадиях

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

Фаза: Выпуск – Архив

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

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

Создан централизованный архив исходного

кода, символов, моделей атак RTM версии

продукта

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

Фаза: Реагирование

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

плану.

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

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

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

Training Requirements Design Implementation Verification Release ResponseОбучение ТребованияПроектирование

Реализация

Проверка ВыпускРеагирова

ние

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

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

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

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

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

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

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

Основные заблуждения об SDL

SDL применим только к

коробочным продуктам

SDL предназначен для модели

водопад или спираль

Для SDL нужны инструменты

разработки Microsoft

SDL предназначен только для

Windows® ОС

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

SDL подходит для разных сценариев разработки

включая бизнес приложения (LOB) и онлайн

сервисы

SDL применим к разным методам разработки

таким как водопад, спираль и agile

Успешная реализация SDL предполагает

автоматизацию с помощью инструментов. Вы

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

компаний.

Чтобы реализовать SDL

нужно много ресурсов.

SDL подходит организациям любого размера. От

разработчика одиночки до огромных

корпораций.

Атаки переходят на уровень приложений

Разработка безопасного кода с помощью SDL – экономия денег компании

SDL существенно улучшил продукты Microsoft

Microsoft сделал процесс SDL доступным всем

Пора применять SDL

Ресурсы

www.microsoft.com/sdl

www.Secunia.org

The Simplified Implementation of the SDL

Блог об SDL

Ресурсы[HOLMES 2010]. Holmes, Graham. (2010, April 05). Cisco CSDL Announcement –http://blogs.cisco.com/security/the_cisco_secure_development_lifecycle_an_overview/

[LANE 2010]. Lane, Adrian. (2010, May 10). FireStarter: Secure Development Lifecycle – You’re Doing It Wrong. Securosis. Retrieved December 29 2010, from http://securosis.com/blog/firestarter-secure-development-lifecycle-your-doing-it-wrong

*LADD 2010+. Ladd, David. (2010, May 11). “Do what Microsoft did, not what they do”. Retrieved December 29 2010, from http://blogs.msdn.com/b/sdl/archive/2010/05/11/do-what-microsoft-did-not-what-they-do.aspx

[LARSON_LADD 2010]. Larson, Larry. Ladd, David. (2010, May 14). Security Talk: Simplified SDL with David Ladd. Channel 9. Retrieved December 29 2010, from http://channel9.msdn.com/Blogs/LarryLarsen/Security-Talk-Simplified-SDL-with-David-Ladd