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

1. Жизненный цикл обеспечения безопасности (Microsoft SDL)Валерий Берестецкий,Microsoft Corporation 24.11.2009, г.Киев Жизненный цикл безопасностиМоделирование угрозВалерий Берестецкий,Microsoft Corporation 27.11.2008, Одесса

2. Мои функции в МС • Отдел по разработке медицинских приложений (Health Solutions Group) – группа обеспечения безопасности: руководитель программы и инженер по безопасности • Наши задачи: • Обеспечение соответствия выпускаемых продуктов требованиям безопасности в МС, моделирование и сдерживание угроз, тестирование выпускаемых продуктов на безопасность • Помощь группам отдела в следовании процессу SDL • Помощь группам отдела в тестировании продуктов на безопасность • Консультирование сотрудников по вопросам безопасности, проведение семинаров, разработка инструментов, исследования • Связь между производственными группами и советниками по безопасности МС

3. Обзор предлагаемого материала • Немного истории • С чего все началось и как развивалось • Введение в SDL • Что такоеSDL, зачем и как его использовать • Процесс SDL • Роли участников процесса SDL • Фазы процесса SDL, как они соответствуют фазам процесса разработки ПО (SDLC) • Средства поддержки процесса SDL • SDL Agile – оптимизация SDL для ускоренной разработки приложений • Модель оптимизации SDL для внедрения вне МС

4. Безопасность в разработках МС: немного истории Жизненный цикл безопасностиМоделирование угрозВалерий Берестецкий,Microsoft Corporation 27.11.2008, Одесса

5. История работынад безопасностьюв МС

6. Введение в SDL Жизненный цикл безопасностиМоделирование угрозВалерий Берестецкий,Microsoft Corporation 27.11.2008, Одесса

7. Жизненный цикл обеспечения безопасности - The Security Development Lifecycle(SDL) • Современные методы разработки не обеспечивают безопасность ПО • Чтобы усовершенствовать безопасность продукта нужны специальные инженерные усилия • Существует много процессов обеспечения безопасности – но только один SDL • SDL доказал свою состоятельность для многих продуктов МС в течение нескольких лет • SDL на самом деле улучшает безопасность продукта

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

9. SDL в действии (2) Over 50% Умен

10. Как повысить безопасность продуктов? • Просто поиск ошибок не делает продукт безопасным • Необходимо уменьшить вероятность проникновения проблем безопасности в программына различных этапах разработки. Для этого требуются: • усовершенствование процесса разработки • постоянное направленное участие всех дисциплин – менеджмента, разработчиков и тестировщиков • специальное обучение, повышение квалификации • надлежащий инструментарий: специальные программные средства

11. Der Speigel «В начале времен» (до SDL) – кошмар «бластера» Всего лишь две строчки кода RPCSS (Remote Procedure Call Services – сервис, доступный через ЛАНдля исполнения на машине пользователя) while (*pwszTemp != L'\\') *pwszServerName++ = *pwszTemp++; привели к • >1,500,000 зараженных компьютеров • 3,370,000 звонков в службу сопровожденияв сентябре 2003г. (при обычном количестве около 350,000) • Огромное количество негативных комментариев в адрес МС в различных СМИ (напр. журнал «Шпигель»)

12. SDL демонстрирует результаты “We actually consider Microsoft to be leading the software [industry] now in improvements in their security development life cycle [SDL].” “В настоящее время мы признаем за Майкрософтом фактическое лидерство в программной индустрии по внедрению процесса разработки безопасности” John Pescatore Vice President and Distinguished Analyst Gartner, Inc http://www.crn.com/sections/coverstory/coverstory.jhtml?articleId=179103240

13. Процесс SDL Жизненный цикл безопасностиМоделирование угрозВалерий Берестецкий,Microsoft Corporation 27.11.2008, Одесса

14. Жизненный цикл обеспечения безопасности (SDL): шаги и процессы Использов.Средстви лучшихпрактик Созд.документови спец.средств Подго-товкапланареагиров. Рывок Финальн.ОбзорБезопас-ности Сопровожди реагиро-вание Обучение Обзор арх. и «атакуемой поверхности» Начало,регистрация спродукта Лучшиепрактики Модели-рованиеугроз Тестир.взломом Традиционные шаги и процессы Жизненного Цикла Безопасности Тестирование и проверка Списки компонент Критерии качестваАрх. документы Планы по времени ЭлектроннаяПодпись + CheckpointExpress ВЫПУСК Поддержка,Обновления Спецификациидизайна Функциональные Спецификации Разработка нового кода Исправление ошибок Постановка Дизайн Разработка Верификация Выпуск Поддержка

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

16. SDL: Постановка (уточнение требований к продукту) Использов.Средстви лучшихпрактик Созд.документови спец.средств Подго-товкапланареагиров. Рывок Финальн.ОбзорБезопас-ности Сопровожди реагиро-вание Обучение Обзор арх. и «атакуемой поверхности» Начало,регистрация продукта Лучшиепрактики Модели-рованиеугроз Тестир.взломом Традиционные шаги и процессы Жизненного Цикла Безопасности Тестирование и проверка Списки компонент Критерии качестваАрх. документы Планы по времени ЭлектроннаяПодпись + CheckpointExpress ВЫПУСК Поддержка,Обновления Спецификациидизайна Функциональные Спецификации Разработка нового кода Исправление ошибок Постановка Дизайн Разработка Верификация Выпуск Поддержка

17. SDL: Постановка (2) • Возможность рассматривать работу по обеспечению безопасности как часть проекта, планировать эту работу и выделять необходимые ресурсы • Группа разработки определяет требования по безопасности для выпускаемого продукта • Назначение ответственного за безопасность • Представители всех дисциплин проходят профилированное обучение • Программа обучения обязывает всех сотрудников проходить курсы по безопасности как минимум раз в год • Имеются различные курсы для разных категорий, опыта и области знаний

18. Курсы по безопасности в МС • Типы дефектов безопасности • Анализ кода на безопасность • Новые средства безопасности в Windows Vista • Практики безопасного программирования • Дефекты безопасности в деталях • Доверяемый интерфейс • Использование библиотеки фаззинга • Безопасность в .NET Framework • Основы безопасной разработки, дизайна и тестирования • Введение в фаззинг • Моделирование угроз • Методы защиты от угроз безопасности и из внедрение • Введение в Криптографию • Принципы безопасного дизайна, проверенные временем • Оценка и управление дефектами • Анализ и уменьшение атакуемой поверхности • Основы безопасности для руководителей • Введение в SDL и FSR

19. Ресурсы

20. SDL: Дизайн Использов.Средстви лучшихпрактик Созд.документови спец.средств Подго-товкапланареагиров. Рывок Финальн.ОбзорБезопас-ности Сопровожди реагиро-вание Обучение Обзор арх. и «атакуемой поверхности» Начало,регистрация продукта Лучшиепрактики Модели-рованиеугроз Тестир.взломом Традиционные шаги и процессы Жизненного Цикла Безопасности Тестирование и проверка Списки компонент Критерии качестваАрх. документы Планы по времени ЭлектроннаяПодпись + CheckpointExpress ВЫПУСК Поддержка,Обновления Спецификациидизайна Функциональные Спецификации Разработка нового кода Исправление ошибок Постановка Дизайн Разработка Верификация Выпуск Поддержка

21. SDL: Дизайн (2) • Применение лучших практик по безопасности: • Установить и задокументировать критические компоненты безопасности • Следовать принципам безопасного дизайна • Модульный дизайн • Разрешать минимальные привилегии • Задокументировать и минимизировать «атакуемую поверхность» - моделирование угроз • Удовлетворить крипто-стандарты • Не использовать MD4, MD5, SHA1 • Гибкость замены крипто-алгоритмов • Установить «Планку ошибок безопасности» и следовать ей позже во время разработки • Убедиться в том, что продукты и услуги следуютстандарту приватности • Если нужно, задать дополнительные критерии безопасности

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

23. Уязвимость, угроза, атака (2) • Не понимая сути угроз, создавать безопасные продукты невозможно • Угроза и уязвимость – это не одно и то же • Угроза неустранима • Как злоумышленник попытается атаковать систему? Ресурс Сдерживание Угроза Атака Уязвимость

24. Аутентификация – подбор, недостаточная аутентификация, небезопасное восстановление паролей Авторизация – предсказуемое значение идентификатора сессии, перехват сессии, недостаточная авторизация, отсутствие таймаута Атаки на клиентов – подмена содержимого, межсайтовый скриптинг Несанкционированное выполнение кода – переполнение буфера, атака на функции форматирования строк, LDAP-, Хpath- и SQL-инъекции Получение доступа к информации – выявление структуры директорий, идентификация приложений на сервере, предсказуемость расположения ресурсов Логические атаки – загрузка серверов, приводящая к отказу в обслуживании, злоупотребление функциональностью, недостаточная проверка процессов Категории атак по направленности

25. Систематический обзор архитектуры с точки зрения атакующего Определение ресурсов, угроз, уязвимостей, механизмов защиты и рисков Имеет большое значение для тестирования безопасности Использование модели “STRIDE” Подробнее – в следующей сегодняшней презентации Моделирование угроз

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

27. SDL: Разработка Использов.Средстви лучшихпрактик Созд.документови спец.средств Подго-товкапланареагиров. Рывок Финальн.ОбзорБезопас-ности Сопровожди реагиро-вание Обучение Обзор арх. и «атакуемой поверхности» Начало,регистрация продукта Лучшиепрактики Модели-рованиеугроз Тестир.взломом Традиционные шаги и процессы Жизненного Цикла Безопасности Тестирование и проверка Списки компонент Критерии качестваАрх. документы Планы по времени ЭлектроннаяПодпись + CheckpointExpress ВЫПУСК Поддержка,Обновления Спецификациидизайна Функциональные Спецификации Разработка нового кода Исправление ошибок Требования Дизайн Разработка Верификация Выпуск Поддержка

28. Требования к средствам разработки Улучшения в Visual Studio, начиная с версии 2005 (компиляция с ключом /GS) Переход на более безопасныебиблиотеки C/C++ Не использовать «небезопасные» функции (http://msdn2.microsoft.com/en-us/library/bb288454.aspx) Использование инструментов статического анализа Использование ASLR Использование последних версий компиляторов и и ХML-парсеров ...и многое, многое другое SDL: Разработка (2)

29. SDL: Верификация Использов.Средстви лучшихпрактик Созд.документови спец.средств Подго-товкапланареагиров. Рывок Финальн.ОбзорБезопас-ности Сопровожди реагиро-вание Обучение Обзор арх. и «атакуемой поверхности» Начало,регистрация сSWI Лучшиепрактики Модели-рованиеугроз Тестир.взломом Традиционные шаги и процессы Жизненного Цикла Безопасности Тестирование и проверка Списки компонент Критерии качестваАрх. документы Планы по времени ЭлектроннаяПодпись + CheckpointExpress ВЫПУСК Поддержка,Обновления Спецификациидизайна Функциональные Спецификации Разработка нового кода Исправление ошибок Требования Дизайн Разработка Верификация Выпуск Поддержка

30. SDL: Верификация (2) • Кодирование завершено – делается тест безопасности как нового, так и ранее существовавшего кода • «Фаззинг» для тестирования обработки данных (обработка намеренно некачественных входных данных) • Файлы, RPC, ActiveX, DCOM • Те же методы используют хакеры и исследователи в области безопасности • Анализаторы безопасности: • статические (FxCop, PreFast) • Динамические (AppVerifier, Binscope, CAT.NET) • другие инструменты • Тесты на основе модели угроз • Tестирование взломом

31. SDL: Выпуск продуктаФинальный Обзор Безопасности (FSR) Использов.Средстви лучшихпрактик Созд.документови спец.средств Подго-товкапланареагиров. Рывок Финальн.ОбзорБезопас-ности Сопровожди реагиро-вание Обучение Обзор арх. и «атакуемой поверхности» Начало,регистрация продукта Лучшиепрактики Модели-рованиеугроз Тестир.взломом Традиционные шаги и процессы Жизненного Цикла Безопасности Тестирование и проверка Списки компонент Критерии качестваАрх. документы Планы по времени ЭлектроннаяПодпись + CheckpointExpress ВЫПУСК Поддержка,Обновления Спецификациидизайна Функциональные Спецификации Разработка нового кода Исправление ошибок Требования Дизайн Разработка Верификация Выпуск Поддержка

32. SDL: Выпуск продукта (2) • Задача: проверить что все требования SDL выполнены • Обзор всей проделанной работы по безопасности перед выпуском продукта, поиск слабых мест • Независимый взгляд на готовность выпуска с точки зрения безопасности • Шаги • Специальный вопросник SDLTrack (автоматизация SDL в МС) • Обзор дизайна и моделей угроз • Анализ поверхности атаки • Проверка средств построения продукта • Анализ известных ошибок • Результаты тестирования взломом • Оценка плана реагирования • Дополнительные критерии

33. Готовность оперативно среагировать на информацию о уязвимости и/или взломе План реагирования помогает избежать проблем в сопровождении продукта Четко определенная и предсказуемая политика ответа на информацию об уязвимости или взломе Поддержка всего кода, включая общие компоненты и промежуточные версии SDL: Выпуск продукта (3) – план реагирования

34. Заключение SDL существенно повышает безопасность выпускаемых продуктов при: • Поддержке руководства • Оснащении надлежащими инструментами • Постоянном усовершенствовании • Внимании со стороны всех дисциплин

35. Средства поддержки процесса SDL Жизненный цикл безопасностиМоделирование угрозВалерий Берестецкий,Microsoft Corporation 27.11.2008, Одесса

36. Средства безопасности в Visual Studio (начиная с версии 2005) • Улучшенная защита от переполнения буфера (/GS) • Средства фаззинга – подачи на вход намеренно некорректных данных • Статический анализ исходного кода (/analyze) – ранее PreFastдля неуправляемого кода • Бинарный анализатор Binscope – проверка того, что dllи сборки построены в соответствии с требованиями SDL • Динамический анализ (AppVerifier) – верификатор кода в процессе исполнения • Безопасные стандартные библиотеки (Safe CRT) • Встроенный FxCop – анализатор управляемого кода • CAT.NET – статический анализатор кода на уязвимости (распространенные типы атак) • Подробнее – в отдельной презентации

37. 2A 00 00 00 00 00 00 00 00 00 00 00 Переполнение буфера • Возможность переписывать памятьв соседнюю с буфером область • Переполнение ведет к исполнению вредоносного кода • Опустошение буфера может привести к отказу в обслуживании • Как правило, случается только в C/C++ int x = 42;char zip[6];strcpy(zip, userinput);printf("x = %i\n", x);

38. Защита от переполнения буфера • /GS и /SAFESEH • Помогает осложнить использование ошибок переполнения буфера вредоносным кодом • Внедряет специальный набор байтов (cookie)в стек для того, чтобы перед возвратом проверить на переполнение • Помогла ограничить вред Blaster на Windows 2003 • /SAFESEH – предотвращает подмену обработчика исключений • /GS – не панацея!

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

40. SDL и фаззинг • Внутренние требования SDL • Фаззинг файлов для всех продуктов, читающих и разбирающих файлы • Фаззинг внешних RPC интерфейсов • Фаззинг ActiveX • Постоянно обновляются • Средства фаззинга • MiniFuzz • Codenomicon Test Tools • Spike (unix/linux) • Peach (open source) • и т.д.

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

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

43. Безопасные стандартные библиотеки • Safe CRT • Многие библиотечные функции упразднены • strcpy, memcpy, strcat, etc. • Заменены более безопасными версиями • strcpy_s, strcat_s, memcpy_s… • #define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1 • Сводит исправление кода к минимуму • Автоматически заменяет вызовы стандартных функций на безопасные

44. Встроенный FxCop • FxCop, средство, долгое время использовавшееся разработчиками управляемого кода, теперь часть Visual Studio, начиная с версии 2005 • Статический анализ управляемого кода • Можно выбрать желаемые проверки в свойствах проекта • Находит проблемы • Безопасности • Быстродействия • Надежности

45. Улучшенная работа с прерываниями • Когда случается прерывание по безопасности, не всегда просто понять в чем дело • Класс исключения (SecurityException) усовершенствован с тем чтобы содержать больше информации • Visual Studio показывает эту информацию и советы по устранению проблемы в специальном всплывающем диалоге

46. CAT.NET • Статический анализатор безопасности • Используется как отдельное средство и как приложение к Visual Studio • Сканирует dll’ы и сборки, выявляет потоки информации между методами и сборками • Движок сканирует основную сборку приложения и все сборки, на которые есть ссылки (помодульно) • Затем анализирует все найденные методы • Наконец, выводит отчет о найденных проблемах, позволяя перейти прямо к проблемному месту в коде • Конфигурируемые типы атак: межсайтовый скриптинг, SQL-инъекция, перенаправление на сайт, контролируемый пользователем и многое другое

47. SDL Agile – оптимизация SDL для ускоренной разработки приложений Жизненный цикл безопасностиМоделирование угрозВалерий Берестецкий,Microsoft Corporation 27.11.2008, Одесса

48. Зачем нужен SDL/A • Классический SDL хорош для водопадной модели разработки и относительно длительных проектов • Разработчики интерактивных служб и веб-приложений все чаще используют ускоренную, ориентированную на «спринты» модель разработки • Процесс SDL нужно видоизменить, чтобы он лучше вписывался в процедуры ускоренной разработки • От групп, выпускающих продукт или обновление каждые три недели, невозможно ожидать исполнения всех требований SDL при каждом выпуске

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

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