Моделирование угроз
advertisement
Жизненный цикл безопасности Жизненный цикл Моделирование угроз обеспечения безопасности (Microsoft SDL) Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса Валерий Берестецкий, Microsoft Corporation 24.11.2009, г.Киев 1 Мои функции в МС • Отдел по разработке медицинских приложений (Health Solutions Group) – группа обеспечения безопасности: руководитель программы и инженер по безопасности • Наши задачи: – Обеспечение соответствия выпускаемых продуктов требованиям безопасности в МС, моделирование и сдерживание угроз, тестирование выпускаемых продуктов на безопасность – Помощь группам отдела в следовании процессу SDL – Помощь группам отдела в тестировании продуктов на безопасность – Консультирование сотрудников по вопросам безопасности, проведение семинаров, разработка инструментов, исследования – Связь между производственными группами и советниками по безопасности МС Обзор предлагаемого материала • Немного истории – С чего все началось и как развивалось • Введение в SDL – Что такое SDL, зачем и как его использовать • Процесс SDL – Роли участников процесса SDL – Фазы процесса SDL, как они соответствуют фазам процесса разработки ПО (SDLC) • Средства поддержки процесса SDL • SDL Agile – оптимизация SDL для ускоренной разработки приложений • Модель оптимизации SDL для внедрения вне МС Жизненный цикл безопасностив разработках МС: Безопасность Моделирование угроз немного истории Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса 4 История работы над безопасностью в МС 2002-2003 • • • • • 2004 • • 2005 • • 2006 • • 2007-2008 • • 2009 • Билл Гейтс пишет письмо о безопасности всем работникам “Security Push” – первое направленное усилие по безопасности в .NET Framework 1.0 и Windows Server 2003 Финальный Обзор Безопасности (FSR) для Windows Server 2003 оказался эффективным Подобные усилия применяются к другим продуктам Обучение в области безопасности рапространяется на всю компанию Mенеджмент компании соглашается требовать от всех продуктов следования SDL , если это признается необходимым SDL вступил в силу внутри компании SDL расширен за счет “фаззинга”, дополнительных средства статического анализа, крипто стандартов и т.д. … SDL начинает распространяться вне компании Дополнения в SDL : приватность, запрещенные API, компиляторы VS2005, и т.д. … Просьбы о дополнительной информации об SDL – Образование, программные средства, поддержка... Оптимизация процесса SDL по результатам его анализа и использования Дальнейшее распространение SDL вне МС Дополнения в SDL: средства обеспечения безопасности при работе с БД, сетевой фаззинг, усовершенствование процесса (SDL Agile) Жизненный цикл безопасности Введениеугроз в SDL Моделирование Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса 6 Жизненный цикл обеспечения безопасности - 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 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 Жизненный цикл безопасности Процесс SDL Моделирование угроз Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса 13 Жизненный цикл обеспечения безопасности (SDL): шаги и процессы Обучение Начало, Лучшие регистрация с практики продукта Обзор арх. и «атакуемой поверхности» Моделирование угроз Использов. Созд. Подго- Рывок Финальн. Обзор Средств документов товка и лучших и спец. плана БезопасТестир. практик средств реагиров. ности взломом Сопровожд и реагирование Традиционные шаги и процессы Жизненного Цикла Безопасности Списки компонент Критерии качества Арх. документы Планы по времени Постановка Спецификации дизайна Функциональные Спецификации Дизайн Тестирование и проверка Разработка нового кода Разработка Исправление ошибок Верификация В Электронная Ы Подпись + П Checkpoint У Express С К Выпуск Поддержка, Обновления Поддержка Что же такое SDL в Майкрософте? Это в первую очередь хорошо управляемый процесс, который – Задает конкретные измеримые требования к выпуску ПО – Приложим к разработке большинства аппаратных и программных систем, т.е. достаточно универсален – Полностью поддерживается руководством МС – Раз в полгода пересматривается и совершенствуется – Обладает встроенными средствами обратной связи – Четко прописывает роли участников – Охватывает все этапы разработки и сопровождения ПО – Требует примерно 10% занятости всех ресурсов – Оснащен необходимым программным инструментарием – Для удобства восприятия и применения вписывается в известную модель водопада SDL: Постановка (уточнение требований к продукту) Обучение Начало, регистрация продукта Лучшие практики Обзор арх. и «атакуемой поверхности» Моделирование угроз Использов. Созд. ПодгоРывок Финальн. Обзор Средств документов товка и лучших и спец. плана БезопасТестир. практик средств реагиров. ности взломом Сопровожд и реагирование Традиционные шаги и процессы Жизненного Цикла Безопасности Списки компонент Критерии качества Арх. документы Планы по времени Постановка Спецификации дизайна Функциональные Спецификации Дизайн Тестирование и проверка Разработка нового кода Разработка Исправление ошибок Верификация В Электронная Ы Подпись + П Checkpoint У Express С К Выпуск Поддержка, Обновления Поддержка SDL: Постановка (2) • Возможность рассматривать работу по обеспечению безопасности как часть проекта, планировать эту работу и выделять необходимые ресурсы • Группа разработки определяет требования по безопасности для выпускаемого продукта • Назначение ответственного за безопасность • Представители всех дисциплин проходят профилированное обучение • Программа обучения обязывает всех сотрудников проходить курсы по безопасности как минимум раз в год • Имеются различные курсы для разных категорий, опыта и области знаний Курсы по безопасности в МС – – – – – – – – – – Основы безопасной разработки, дизайна и тестирования Введение в фаззинг Моделирование угроз Методы защиты от угроз безопасности и из внедрение Введение в Криптографию Принципы безопасного дизайна, проверенные временем Оценка и управление дефектами Анализ и уменьшение атакуемой поверхности Основы безопасности для руководителей Введение в SDL и FSR – – – – – – – – Типы дефектов безопасности Анализ кода на безопасность Новые средства безопасности в Windows Vista Практики безопасного программирования Дефекты безопасности в деталях Доверяемый интерфейс Использование библиотеки фаззинга Безопасность в .NET Framework Ресурсы SDL: Дизайн Обучение Начало, регистрация продукта Лучшие практики Обзор арх. и «атакуемой поверхности» Моделирование угроз Использов. Созд. Подго- Рывок Финальн. Обзор Средств документов товка и лучших и спец. плана БезопасТестир. практик средств реагиров. ности взломом Сопровожд и реагирование Традиционные шаги и процессы Жизненного Цикла Безопасности Списки компонент Критерии качества Арх. документы Планы по времени Постановка Спецификации дизайна Функциональные Спецификации Дизайн Тестирование и проверка Разработка нового кода Разработка Исправление ошибок Верификация В Электронная Ы Подпись + П Checkpoint У Express С К Выпуск Поддержка, Обновления Поддержка SDL: Дизайн (2) Применение лучших практик по безопасности: • Установить и задокументировать критические компоненты безопасности • Следовать принципам безопасного дизайна • Модульный дизайн • Разрешать минимальные привилегии • Задокументировать и минимизировать «атакуемую поверхность» - моделирование угроз • Удовлетворить крипто-стандарты • Не использовать MD4, MD5, SHA1 • Гибкость замены крипто-алгоритмов • Установить «Планку ошибок безопасности» и следовать ей позже во время разработки • Убедиться в том, что продукты и услуги следуют стандарту приватности • Если нужно, задать дополнительные критерии безопасности Уязвимость, угроза, атака Уязвимость, угроза, атака (2) • Не понимая сути угроз, создавать безопасные продукты невозможно • Угроза и уязвимость – это не одно и то же • Угроза неустранима • Как злоумышленник попытается атаковать систему? Ресурс Сдерживание Угроза Атака Уязвимость Категории атак по направленности • • • • • • Аутентификация – подбор, недостаточная аутентификация, небезопасное восстановление паролей Авторизация – предсказуемое значение идентификатора сессии, перехват сессии, недостаточная авторизация, отсутствие таймаута Атаки на клиентов – подмена содержимого, межсайтовый скриптинг Несанкционированное выполнение кода – переполнение буфера, атака на функции форматирования строк, LDAP-, Хpathи SQL-инъекции Получение доступа к информации – выявление структуры директорий, идентификация приложений на сервере, предсказуемость расположения ресурсов Логические атаки – загрузка серверов, приводящая к отказу в обслуживании, злоупотребление функциональностью, недостаточная проверка процессов Моделирование угроз • Систематический обзор архитектуры с точки зрения атакующего • Определение ресурсов, угроз, уязвимостей, механизмов защиты и рисков • Имеет большое значение для тестирования безопасности • Использование модели “STRIDE” • Подробнее – в следующей сегодняшней презентации Классификация стандартных угроз Угроза Защита Spoofing – подмена информации Проверка подлинности Tampering – манипулирование данными Обеспечение целостности данных Repudiation – аннулирование ответственности Обеспечение невозможности аннулирования Information Disclosure – раскрытие информации Обеспечение конфиденциальности Denial of Service – отказ в обслуживании Обеспечение доступности Elevation of Privilege – несанкционированное повышение прав доступа Обеспечение надлежащей авторизации доступа SDL: Разработка Обучение Начало, регистрация продукта Лучшие практики Обзор арх. и «атакуемой поверхности» Моделирование угроз Использов. Созд. Подго- Рывок Финальн. Обзор Средств документов товка и лучших и спец. плана БезопасТестир. практик средств реагиров. ности взломом Сопровожд и реагирование Традиционные шаги и процессы Жизненного Цикла Безопасности Списки компонент Критерии качества Арх. документы Планы по времени Требования Спецификации дизайна Функциональные Спецификации Дизайн Тестирование и проверка Разработка нового кода Разработка Исправление ошибок Верификация В Электронная Ы Подпись + П Checkpoint У Express С К Выпуск Поддержка, Обновления Поддержка SDL: Разработка (2) • • • • • • Требования к средствам разработки • Улучшения в Visual Studio, начиная с версии 2005 (компиляция с ключом /GS) Переход на более безопасные библиотеки C/C++ • Не использовать «небезопасные» функции (http://msdn2.microsoft.com/enus/library/bb288454.aspx) Использование инструментов статического анализа Использование ASLR Использование последних версий компиляторов и и ХML-парсеров ...и многое, многое другое SDL: Верификация Обучение Начало, Лучшие регистрация с практики SWI Обзор арх. и «атакуемой поверхности» Моделирование угроз Использов. Созд. Подго- Рывок Финальн. Обзор Средств документов товка и лучших и спец. плана БезопасТестир. практик средств реагиров. ности взломом Сопровожд и реагирование Традиционные шаги и процессы Жизненного Цикла Безопасности Списки компонент Критерии качества Арх. документы Планы по времени Требования Спецификации дизайна Функциональные Спецификации Дизайн Тестирование и проверка Разработка нового кода Разработка Исправление ошибок Верификация В Электронная Ы Подпись + П Checkpoint У Express С К Выпуск Поддержка, Обновления Поддержка SDL: Верификация (2) • • • • • Кодирование завершено – делается тест безопасности как нового, так и ранее существовавшего кода «Фаззинг» для тестирования обработки данных (обработка намеренно некачественных входных данных) o Файлы, RPC, ActiveX, DCOM o Те же методы используют хакеры и исследователи в области безопасности Анализаторы безопасности: o статические (FxCop, PreFast) o Динамические (AppVerifier, Binscope, CAT.NET) o другие инструменты Тесты на основе модели угроз Tестирование взломом SDL: Выпуск продукта Финальный Обзор Безопасности (FSR) Обучение Начало, регистрация продукта Лучшие практики Обзор арх. и «атакуемой поверхности» Моделирование угроз Использов. Созд. Подго- Рывок Финальн. Обзор Средств документов товка и лучших и спец. плана БезопасТестир. практик средств реагиров. ности взломом Сопровожд и реагирование Традиционные шаги и процессы Жизненного Цикла Безопасности Списки компонент Критерии качества Арх. документы Планы по времени Требования Спецификации дизайна Функциональные Спецификации Дизайн Тестирование и проверка Разработка нового кода Разработка Исправление ошибок Верификация В Электронная Ы Подпись + П Checkpoint У Express С К Выпуск Поддержка, Обновления Поддержка SDL: Выпуск продукта (2) • Задача: проверить что все требования SDL выполнены – Обзор всей проделанной работы по безопасности перед выпуском продукта, поиск слабых мест – Независимый взгляд на готовность выпуска с точки зрения безопасности • Шаги – Специальный вопросник SDLTrack (автоматизация SDL в МС) – Обзор дизайна и моделей угроз – Анализ поверхности атаки – Проверка средств построения продукта – Анализ известных ошибок – Результаты тестирования взломом – Оценка плана реагирования – Дополнительные критерии SDL: Выпуск продукта (3) – план реагирования • Готовность оперативно среагировать на информацию о уязвимости и/или взломе • План реагирования помогает избежать проблем в сопровождении продукта • Четко определенная и предсказуемая политика ответа на информацию об уязвимости или взломе • Поддержка всего кода, включая общие компоненты и промежуточные версии Заключение SDL существенно повышает безопасность выпускаемых продуктов при: • • • • Поддержке руководства Оснащении надлежащими инструментами Постоянном усовершенствовании Внимании со стороны всех дисциплин Жизненный цикл безопасности Средства поддержки процесса Моделирование SDLугроз Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса 35 Средства безопасности в Visual Studio (начиная с версии 2005) • Улучшенная защита от переполнения буфера (/GS) • Средства фаззинга – подачи на вход намеренно некорректных данных • Статический анализ исходного кода (/analyze) – ранее PreFast для неуправляемого кода • Бинарный анализатор Binscope – проверка того, что dll и сборки построены в соответствии с требованиями SDL • Динамический анализ (AppVerifier) – верификатор кода в процессе исполнения • Безопасные стандартные библиотеки (Safe CRT) • Встроенный FxCop – анализатор управляемого кода • CAT.NET – статический анализатор кода на уязвимости (распространенные типы атак) • Подробнее – в отдельной презентации Переполнение буфера • Возможность переписывать память в соседнюю с буфером область • Переполнение ведет к исполнению вредоносного кода • Опустошение буфера может привести к отказу в обслуживании • Как правило, случается только в C/C++ int x = 42; char zip[6]; strcpy(zip, userinput); printf("x = %i\n", x); 2A 00 00 00 00 00 00 00 00 00 00 00 Защита от переполнения буфера • /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инъекция, перенаправление на сайт, контролируемый пользователем и многое другое Жизненный цикл SDL Agile – оптимизация SDL для безопасности ускоренной разработки Моделирование угроз приложений Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса 47 Зачем нужен SDL/A • • • • Классический SDL хорош для водопадной модели разработки и относительно длительных проектов Разработчики интерактивных служб и вебприложений все чаще используют ускоренную, ориентированную на «спринты» модель разработки Процесс SDL нужно видоизменить, чтобы он лучше вписывался в процедуры ускоренной разработки От групп, выпускающих продукт или обновление каждые три недели, невозможно ожидать исполнения всех требований SDL при каждом выпуске Основные принципы SDL/A • • • • В SDL/A не является необходимым выполнение всех требований при подготовке каждого выпуска (или в каждом спринте) Каждое требование SDL является важным, и не может быть пропущено – противоречие? В рамках короткого цикла выпуска просто нет времени на выполнение всех требований SDL параллельно с разработкой компонентов Поэтому в SDL/A определены три уровня частоты требований (т.е., как часто требование должно выполняться), и каждое требование SDL отнесено в одну из этих трех категорий Категории требований SDL/A • • • Обязательные требования - должны выполняться для каждого выпуска независимо от того, насколько краток спринт. Факторы отбора – критичность уязвимостей и простота автоматизации. Примеры – предотвращение XSS, моделирование угроз Стартовые требования - те, которые группа разработки продукта должна выполнить один раз в самом начале работы над проектом, и никогда больше не должна к ним возвращаться. Факторы отбора – однократность исполнения на протяжении всего проекта. Примеры – настройка системы отслеживания ошибок, разработка плана реагирования на инцидент безопасности Направленные комплекты требований - остальные требования SDL, не попавшие ни в группу обязательных, ни в группу стартовых, помещаются в один из трех комплектов требований: проверки безопасности, обзора проекта и планов реагирования. Пример - требование SDL о тестировании процедур обработки ввода методом Монте-Карло помещается в комплект проверки безопасности. В SDL/A при подготовке каждого выпуска должно быть выполнено только одно требование из каждого комплекта. Жизненный цикл безопасности Оптимизация SDL для внедрения Моделирование угроз вне МС Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса 51 Оптимизационная модель внедрения 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=e n&FamilyID=0fcba3c7-bc30-47b0-a2f8-2e702720998a Вопросы? Жизненный цикл Спасибо за внимание! безопасности Моделирование угроз vaberest@microsoft.com Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса 59
