Жизненный цикл обеспечения безопасности

Жизненный цикл безопасностиМоделирование угроз

Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса

1

Жизненный цикл обеспечения безопасности

(Microsoft SDL)

Валерий Берестецкий, Microsoft Corporation 24.11.2009, г.Киев

Мои функции в МС• Отдел по разработке медицинских приложений (Health Solutions

Group) – группа обеспечения безопасности: руководитель программы и инженер по безопасности

• Наши задачи:– Обеспечение соответствия выпускаемых продуктов требованиям

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

– Помощь группам отдела в следовании процессу SDL – Помощь группам отдела в тестировании продуктов на

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

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

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

Обзор предлагаемого материала• Немного истории

– С чего все началось и как развивалось

• Введение в SDL– Что такое SDL, зачем и как его использовать

• Процесс SDL– Роли участников процесса SDL– Фазы процесса SDL, как они соответствуют фазам процесса разработки

ПО (SDLC)

• Средства поддержки процесса SDL

• SDL Agile – оптимизация SDL для ускоренной разработки приложений

• Модель оптимизации SDL для внедрения вне МС



4

Безопасность в разработках МС: немного истории

История работы над безопасностью в МС 2002-2003 • Билл Гейтс пишет письмо о безопасности всем работникам

• “Security Push” – первое направленное усилие по безопасности в .NET Framework 1.0 и Windows Server 2003

• Финальный Обзор Безопасности (FSR) для Windows Server 2003 оказался эффективным

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

2004 • Mенеджмент компании соглашается требовать от всех продуктов следования SDL , если это признается необходимым

• SDL вступил в силу внутри компании

2005 • SDL расширен за счет “фаззинга”, дополнительных средства статического анализа, крипто стандартов и т.д. …

• SDL начинает распространяться вне компании

2006 • Дополнения в SDL : приватность, запрещенные API, компиляторы VS2005, и т.д. …

• Просьбы о дополнительной информации об SDL– Образование, программные средства, поддержка...

2007-2008 • Оптимизация процесса SDL по результатам его анализа и использования

• Дальнейшее распространение SDL вне МС

2009 • Дополнения в SDL: средства обеспечения безопасности при работе с БД, сетевой фаззинг, усовершенствование процесса (SDL Agile)



6

Введение в SDL

Жизненный цикл обеспечения безопасности - The Security Development Lifecycle (SDL)

• Современные методы разработки не обеспечивают безопасность ПО

• Чтобы усовершенствовать безопасность продукта нужны специальные инженерные усилия

• Существует много процессов обеспечения безопасности – но только один SDL– SDL доказал свою состоятельность для многих

продуктов МС в течение нескольких лет– SDL на самом деле улучшает безопасность продукта

SDL в действии (немного статистики)

SDL в действии (2)

Over 50%Умен

Как повысить безопасность продуктов?• Просто поиск ошибок не делает продукт безопасным• Необходимо уменьшить вероятность

проникновения проблем безопасности в программы на различных этапах разработки. Для этого требуются:– усовершенствование процесса разработки– постоянное направленное участие всех

дисциплин – менеджмента, разработчиков и тестировщиков

– специальное обучение, повышение квалификации

– надлежащий инструментарий: специальные программные средства

«В начале времен» (до SDL) – кошмар «бластера»

Всего лишь две строчки кода RPCSS (Remote Procedure Call Services – сервис, доступный через ЛАН для исполнения на машине пользователя)while (*pwszTemp != L'\\')

*pwszServerName++ = *pwszTemp++;

привели к– >1,500,000 зараженных компьютеров– 3,370,000 звонков в службу сопровождения в сентябре 2003г.

(при обычном количестве около 350,000)– Огромное количество негативных комментариев в адрес МС

в различных СМИ (напр. журнал «Шпигель»)

Der Speigel

“We actually consider Microsoft to be leading the software [industry] now in improvements in their security development life cycle [SDL].”

John PescatoreVice President and Distinguished Analyst

Gartner, Inchttp://www.crn.com/sections/coverstory/coverstory.jhtml?articleId=179103240

SDL демонстрирует результаты

“В настоящее время мы признаем за Майкрософтом фактическое лидерство в программной индустрии по внедрению процесса разработки безопасности”



13

Процесс SDL

Обучение

Начало,регистрация с

продукта

Лучшиепрактики

Обзор арх. и «атакуемой поверхности»

Использов.Средстви лучшихпрактик

Созд.документов

и спец.средств

Подго-товкаплана

реагиров.

Рывок

Тестир.взломом

Финальн.Обзор

Безопас-ности

Сопровожди реагиро-

вание

Списки компонентКритерии качества

Арх. документыПланы по времени

Спецификациидизайна Тестирование и проверка

Разработка нового кода Исправление ошибок

ЭлектроннаяПодпись + Checkpoint

Express

ВЫПУСК

Поддержка,Обновления

Постановка Дизайн Разработка Верификация Выпуск Поддержка

Жизненный цикл обеспечения безопасности (SDL): шаги и процессы

Модели-рование

угроз

ФункциональныеСпецификации

Традиционные шаги и процессы Жизненного Цикла Безопасности

Что же такое SDL в Майкрософте? Это в первую очередь хорошо управляемый процесс,

который– Задает конкретные измеримые требования к выпуску ПО– Приложим к разработке большинства аппаратных и

программных систем, т.е. достаточно универсален– Полностью поддерживается руководством МС– Раз в полгода пересматривается и совершенствуется– Обладает встроенными средствами обратной связи– Четко прописывает роли участников– Охватывает все этапы разработки и сопровождения ПО– Требует примерно 10% занятости всех ресурсов– Оснащен необходимым программным инструментарием– Для удобства восприятия и применения вписывается в

известную модель водопада

Обучение

Начало,регистрация

продукта







реагиров.

Рывок





вание






Express

ВЫПУСК



SDL: Постановка (уточнение требований к продукту)


угроз



SDL: Постановка (2)

• Возможность рассматривать работу по обеспечению безопасности как часть проекта, планировать эту работу и выделять необходимые ресурсы

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

• Назначение ответственного за безопасность• Представители всех дисциплин проходят

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

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

и области знаний

Курсы по безопасности в МС– Основы безопасной

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

– Введение в фаззинг– Моделирование угроз– Методы защиты от угроз

безопасности и из внедрение– Введение в Криптографию– Принципы безопасного

дизайна, проверенные временем

– Оценка и управление дефектами

– Анализ и уменьшение атакуемой поверхности

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

– Введение в SDL и FSR

– Типы дефектов безопасности

– Анализ кода на безопасность

– Новые средства безопасности в Windows Vista

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

– Дефекты безопасности в деталях

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

фаззинга– Безопасность в .NET

Framework

Ресурсы

Обучение


продукта







реагиров.

Рывок





вание






Express

ВЫПУСК



SDL: Дизайн


угроз



SDL: Дизайн (2)Применение лучших практик по безопасности:

• Установить и задокументировать критические компоненты безопасности

• Следовать принципам безопасного дизайна• Модульный дизайн• Разрешать минимальные привилегии• Задокументировать и минимизировать

«атакуемую поверхность» - моделирование угроз

• Удовлетворить крипто-стандарты• Не использовать MD4, MD5, SHA1• Гибкость замены крипто-алгоритмов

• Установить «Планку ошибок безопасности» и следовать ей позже во время разработки

• Убедиться в том, что продукты и услуги следуют стандарту приватности

• Если нужно, задать дополнительные критерии безопасности

Уязвимость, угроза, атака

Уязвимость, угроза, атака (2)• Не понимая сути угроз, создавать безопасные

продукты невозможно • Угроза и уязвимость – это не одно и то же• Угроза неустранима• Как злоумышленник попытается атаковать

систему?

Угроза

РесурсСдерживание

Уязвимость

Атака

Категории атак по направленности• Аутентификация – подбор, недостаточная аутентификация,

небезопасное восстановление паролей• Авторизация – предсказуемое значение идентификатора

сессии, перехват сессии, недостаточная авторизация, отсутствие таймаута

• Атаки на клиентов – подмена содержимого, межсайтовый скриптинг

• Несанкционированное выполнение кода – переполнение буфера, атака на функции форматирования строк, LDAP-, Хpath- и SQL-инъекции

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

• Логические атаки – загрузка серверов, приводящая к отказу в обслуживании, злоупотребление функциональностью, недостаточная проверка процессов

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

• Систематический обзор архитектуры с точки зрения атакующего

• Определение ресурсов, угроз, уязвимостей, механизмов защиты и рисков

• Имеет большое значение для тестирования безопасности

• Использование модели “STRIDE”• Подробнее – в следующей сегодняшней

презентации

Классификация стандартных угроз

Угроза Защита

Spoofing – подмена информации Проверка подлинности

Tampering – манипулирование данными

Обеспечение целостности данных

Repudiation – аннулирование ответственности

Обеспечение невозможности аннулирования

Information Disclosure – раскрытие информации

Обеспечение конфиденциальности

Denial of Service – отказ в обслуживании

Обеспечение доступности

Elevation of Privilege – несанкционированное повышение прав доступа

Обеспечение надлежащей авторизации доступа

Обучение


продукта







реагиров.

Рывок





вание






Express

ВЫПУСК


Требования Дизайн Разработка Верификация Выпуск Поддержка

SDL: Разработка


угроз



SDL: Разработка (2)• Требования к средствам разработки

• Улучшения в Visual Studio, начиная с версии 2005 (компиляция с ключом /GS)

• Переход на более безопасные библиотеки C/C++• Не использовать «небезопасные» функции (

http://msdn2.microsoft.com/en-us/library/bb288454.aspx)

• Использование инструментов статического анализа• Использование ASLR• Использование последних версий компиляторов и и

ХML-парсеров• ...и многое, многое другое

http://msdn2.microsoft.com/en-us/library/bb288454.aspx

http://msdn2.microsoft.com/en-us/library/bb288454.aspx

Обучение

Начало,регистрация с

SWI







реагиров.

Рывок





вание






Express

ВЫПУСК



SDL: Верификация


угроз



SDL: Верификация (2)• Кодирование завершено – делается тест

безопасности как нового, так и ранее существовавшего кода

• «Фаззинг» для тестирования обработки данных (обработка намеренно некачественных входных данных)o Файлы, RPC, ActiveX, DCOMo Те же методы используют хакеры и

исследователи в области безопасности• Анализаторы безопасности:

o статические (FxCop, PreFast)o Динамические (AppVerifier, Binscope,

CAT.NET) o другие инструменты

• Тесты на основе модели угроз• Tестирование взломом

Обучение


продукта







реагиров.

Рывок





вание






Express

ВЫПУСК



SDL: Выпуск продуктаФинальный Обзор Безопасности (FSR)


угроз



SDL: Выпуск продукта (2)

• Задача: проверить что все требования SDL выполнены– Обзор всей проделанной работы по безопасности

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

зрения безопасности• Шаги

– Специальный вопросник SDLTrack (автоматизация SDL в МС)

– Обзор дизайна и моделей угроз– Анализ поверхности атаки– Проверка средств построения продукта– Анализ известных ошибок– Результаты тестирования взломом– Оценка плана реагирования– Дополнительные критерии

SDL: Выпуск продукта (3) – план реагирования

• Готовность оперативно среагировать на информацию о уязвимости и/или взломе

• План реагирования помогает избежать проблем в сопровождении продукта

• Четко определенная и предсказуемая политика ответа на информацию об уязвимости или взломе

• Поддержка всего кода, включая общие компоненты и промежуточные версии

Заключение

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

• Поддержке руководства • Оснащении надлежащими инструментами• Постоянном усовершенствовании• Внимании со стороны всех дисциплин



35

Средства поддержки процесса SDL

Средства безопасности в Visual Studio (начиная с версии 2005)• Улучшенная защита от переполнения буфера (/GS)• Средства фаззинга – подачи на вход намеренно

некорректных данных• Статический анализ исходного кода (/analyze) – ранее

PreFast для неуправляемого кода• Бинарный анализатор Binscope – проверка того, что dll и

сборки построены в соответствии с требованиями SDL• Динамический анализ (AppVerifier) – верификатор кода в

процессе исполнения• Безопасные стандартные библиотеки (Safe CRT)• Встроенный FxCop – анализатор управляемого кода• CAT.NET – статический анализатор кода на уязвимости

(распространенные типы атак)• Подробнее – в отдельной презентации

Переполнение буфера• Возможность переписывать память в соседнюю с

буфером область• Переполнение ведет к исполнению вредоносного

кода• Опустошение буфера может привести к отказу в

обслуживании• Как правило, случается только в C/C++

00 00 00 00

00 00 00 00

2A 00 00 00int x = 42;char zip[6];strcpy(zip, userinput);printf("x = %i\n", x);

Защита от переполнения буфера

• /GS и /SAFESEH• Помогает осложнить использование ошибок

переполнения буфера вредоносным кодом• Внедряет специальный набор байтов (cookie) в

стек для того, чтобы перед возвратом проверить на переполнение

• Помогла ограничить вред Blaster на Windows 2003

• /SAFESEH – предотвращает подмену обработчика исключений

• /GS – не панацея!

Фаззинг – автоматическое тестирование безопасности

• Фаззинг – метод поиска проблем в безопасности путем подачи намеренно некорректных данных на вход программным интерфейсам, обрабатывающим:– Файлы– Сетевые порты– API

• На основании найденных в прошлом уязвимостей, считается что большую их часть можно было найти, используя фаззинг

SDL и фаззинг• Внутренние требования SDL

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

– Фаззинг внешних RPC интерфейсов– Фаззинг ActiveX– Постоянно обновляются

• Средства фаззинга– MiniFuzz– Codenomicon Test Tools– Spike (unix/linux)– Peach (open source)– и т.д.

Статический анализ кода• Опция /analyze• Статический анализ исходного кода• Основана на внутреннем средстве PreFast• Находит дополнительные ошибки во время

компиляции– Приведения типов– Быстродействия– Безопасности– Операций с памятью

Динамический анализ• Анализ времени выполнения• Основан на средстве Application Verifier• Приложение может быть запущено в режиме

отладки/анализа и автоматически остановлено когда происходит ошибка

• Проверки на– Совместимость– Стабильность– Проблемы безопасности

Безопасные стандартные библиотеки• Safe CRT• Многие библиотечные функции упразднены

– strcpy, memcpy, strcat, etc.• Заменены более безопасными версиями

– strcpy_s, strcat_s, memcpy_s…• #define

_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1 – Сводит исправление кода к минимуму– Автоматически заменяет вызовы стандартных

функций на безопасные

Встроенный FxCop• FxCop, средство, долгое время

использовавшееся разработчиками управляемого кода, теперь часть Visual Studio, начиная с версии 2005

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

проекта• Находит проблемы

– Безопасности– Быстродействия– Надежности

Улучшенная работа с прерываниями

• Когда случается прерывание по безопасности, не всегда просто понять в чем дело

• Класс исключения (SecurityException) усовершенствован с тем чтобы содержать больше информации

• Visual Studio показывает эту информацию и советы по устранению проблемы в специальном всплывающем диалоге

CAT.NET• Статический анализатор безопасности• Используется как отдельное средство и как приложение к

Visual Studio• Сканирует dll’ы и сборки, выявляет потоки информации между

методами и сборками• Движок сканирует основную сборку приложения и все сборки,

на которые есть ссылки (помодульно)• Затем анализирует все найденные методы• Наконец, выводит отчет о найденных проблемах, позволяя

перейти прямо к проблемному месту в коде• Конфигурируемые типы атак: межсайтовый скриптинг, SQL-

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



47

SDL Agile – оптимизация SDL для ускоренной разработки

приложений

• Классический SDL хорош для водопадной модели разработки и относительно длительных проектов

• Разработчики интерактивных служб и веб-приложений все чаще используют ускоренную, ориентированную на «спринты» модель разработки

• Процесс SDL нужно видоизменить, чтобы он лучше вписывался в процедуры ускоренной разработки

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

Зачем нужен SDL/A

• В SDL/A не является необходимым выполнение всех требований при подготовке каждого выпуска (или в каждом спринте)

• Каждое требование SDL является важным, и не может быть пропущено – противоречие?

• В рамках короткого цикла выпуска просто нет времени на выполнение всех требований SDL параллельно с разработкой компонентов

• Поэтому в SDL/A определены три уровня частоты требований (т.е., как часто требование должно выполняться), и каждое требование SDL отнесено в одну из этих трех категорий

Основные принципы SDL/A

• Обязательные требования - должны выполняться для каждого выпуска независимо от того, насколько краток спринт. Факторы отбора – критичность уязвимостей и простота автоматизации. Примеры – предотвращение XSS, моделирование угроз

• Стартовые требования - те, которые группа разработки продукта должна выполнить один раз в самом начале работы над проектом, и никогда больше не должна к ним возвращаться. Факторы отбора – однократность исполнения на протяжении всего проекта. Примеры – настройка системы отслеживания ошибок, разработка плана реагирования на инцидент безопасности

• Направленные комплекты требований - остальные требования SDL, не попавшие ни в группу обязательных, ни в группу стартовых, помещаются в один из трех комплектов требований: проверки безопасности, обзора проекта и планов реагирования. Пример - требование SDL о тестировании процедур обработки ввода методом Монте-Карло помещается в комплект проверки безопасности. В SDL/A при подготовке каждого выпуска должно быть выполнено только одно требование из каждого комплекта.

Категории требований SDL/A



51

Оптимизация SDL для внедрения вне МС

Оптимизационная модель внедрения SDL

Обучение персонала, организационные планы и мероприятия

Постановка и дизайн

Разработка

Выпуск и сопровождение

Базовыйуровень

СтандартныйУровень

ПродвинутыйУровень

ДинамическийУровень

Оптимизационная модель внедрения SDL – базовый уровень готовности

•Планы и мероприятия для всех этапов SDL либо вовсе не определены, либо неконкретны•Организация начинает знакомиться с SDL•Цели внедрения SDL только начинают формироваться

Оптимизационная модель внедрения SDL – стандартный уровень готовности

• Обучение персонала, организационные планы и мероприятия: поддержка руководства по умолчанию, есть несколько пилотных проектов, введено обучение основным концепциям безопасности

•Постановка и дизайн: оценка рисков безопасности, моделирование угроз для задач с высоким уровнем риска•Разработка: использование защиты при компиляции, учет запрещенных функций, защиты от межсайтового скриптинга и SQL-инъекции•Верификация: фаззинг, сканирование веб-приложений, тестирование взлома •Выпуск и сопровождение: финальный обзор безопасности, архивирование проекта, базовый уровень сопровождения

Оптимизационная модель внедрения SDL – продвинутый уровень готовности

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

Оптимизационная модель внедрения SDL – динамический уровень готовности

•Обучение персонала, организационные планы и мероприятия: руководство внедряет SDL как обязательный процесс для всех проектов с существенным уровнем риска, вводится специализированное обучение, SDL адаптируется к методологии разработки (классическая или ускоренная)•Постановка и дизайн: моделирование угроз делается непосредственно в группах разработки•Разработка: создаются новые инструменты обеспечения безопасности•Верификация: создаются новые инструменты верификации безопасности для выявления уязвимостей и проверки следования SDL•Выпуск и сопровождение: учет инцидентов в реальном времени, анализ результатов и обеспечение обратной связи

Ресурсы• «The Security Development Lifecycle», ISBN 10: 0-7356-2214-0• «Writing Secure Code», 2-е издание, ISBN 10: 0-7356-1722-8• Обзор SDL (MSDN)

http://msdn.microsoft.com/en-us/security/cc448177.aspx • Дайджесты, вебкасты, блоги

http://www.microsoft.com/communities/default.mspx • Microsoft Learning and Certification

http://www.microsoft.com/learning/default.mspx • Trial Software and Virtual Labs

http://www.microsoft.com/technet/downloads/trials/default.mspx• Набор ресурсов по безопасности для разработчиков

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0fcba3c7-bc30-47b0-a2f8-2e702720998a

http://msdn.microsoft.com/en-us/security/cc448177.aspx

http://www.microsoft.com/communities/default.mspx

http://www.microsoft.com/learning/default.mspx

http://www.microsoft.com/technet/downloads/trials/default.mspx

Вопросы?



59

Спасибо за внимание!

[email protected]

Documents

Жизненный цикл обеспечения безопасности