Жизненный цикл безопасностиМоделирование угроз
Валерий Берестецкий, 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 для внедрения вне МС
Жизненный цикл безопасностиМоделирование угроз
Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса
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)
Жизненный цикл безопасностиМоделирование угроз
Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса
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 демонстрирует результаты
“В настоящее время мы признаем за Майкрософтом фактическое лидерство в программной индустрии по внедрению процесса разработки безопасности”
Жизненный цикл безопасностиМоделирование угроз
Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса
13
Процесс SDL
Обучение
Начало,регистрация с
продукта
Лучшиепрактики
Обзор арх. и «атакуемой поверхности»
Использов.Средстви лучшихпрактик
Созд.документов
и спец.средств
Подго-товкаплана
реагиров.
Рывок
Тестир.взломом
Финальн.Обзор
Безопас-ности
Сопровожди реагиро-
вание
Списки компонентКритерии качества
Арх. документыПланы по времени
Спецификациидизайна Тестирование и проверка
Разработка нового кода Исправление ошибок
ЭлектроннаяПодпись + Checkpoint
Express
ВЫПУСК
Поддержка,Обновления
Постановка Дизайн Разработка Верификация Выпуск Поддержка
Жизненный цикл обеспечения безопасности (SDL): шаги и процессы
Модели-рование
угроз
ФункциональныеСпецификации
Традиционные шаги и процессы Жизненного Цикла Безопасности
Что же такое SDL в Майкрософте? Это в первую очередь хорошо управляемый процесс,
который– Задает конкретные измеримые требования к выпуску ПО– Приложим к разработке большинства аппаратных и
программных систем, т.е. достаточно универсален– Полностью поддерживается руководством МС– Раз в полгода пересматривается и совершенствуется– Обладает встроенными средствами обратной связи– Четко прописывает роли участников– Охватывает все этапы разработки и сопровождения ПО– Требует примерно 10% занятости всех ресурсов– Оснащен необходимым программным инструментарием– Для удобства восприятия и применения вписывается в
известную модель водопада
Обучение
Начало,регистрация
продукта
Лучшиепрактики
Обзор арх. и «атакуемой поверхности»
Использов.Средстви лучшихпрактик
Созд.документов
и спец.средств
Подго-товкаплана
реагиров.
Рывок
Тестир.взломом
Финальн.Обзор
Безопас-ности
Сопровожди реагиро-
вание
Списки компонентКритерии качества
Арх. документыПланы по времени
Спецификациидизайна Тестирование и проверка
Разработка нового кода Исправление ошибок
ЭлектроннаяПодпись + Checkpoint
Express
ВЫПУСК
Поддержка,Обновления
Постановка Дизайн Разработка Верификация Выпуск Поддержка
SDL: Постановка (уточнение требований к продукту)
Модели-рование
угроз
ФункциональныеСпецификации
Традиционные шаги и процессы Жизненного Цикла Безопасности
SDL: Постановка (2)
• Возможность рассматривать работу по обеспечению безопасности как часть проекта, планировать эту работу и выделять необходимые ресурсы
• Группа разработки определяет требования по безопасности для выпускаемого продукта
• Назначение ответственного за безопасность• Представители всех дисциплин проходят
профилированное обучение• Программа обучения обязывает всех сотрудников
проходить курсы по безопасности как минимум раз в год• Имеются различные курсы для разных категорий, опыта
и области знаний
Курсы по безопасности в МС– Основы безопасной
разработки, дизайна и тестирования
– Введение в фаззинг– Моделирование угроз– Методы защиты от угроз
безопасности и из внедрение– Введение в Криптографию– Принципы безопасного
дизайна, проверенные временем
– Оценка и управление дефектами
– Анализ и уменьшение атакуемой поверхности
– Основы безопасности для руководителей
– Введение в SDL и FSR
– Типы дефектов безопасности
– Анализ кода на безопасность
– Новые средства безопасности в Windows Vista
– Практики безопасного программирования
– Дефекты безопасности в деталях
– Доверяемый интерфейс– Использование библиотеки
фаззинга– Безопасность в .NET
Framework
Ресурсы
Обучение
Начало,регистрация
продукта
Лучшиепрактики
Обзор арх. и «атакуемой поверхности»
Использов.Средстви лучшихпрактик
Созд.документов
и спец.средств
Подго-товкаплана
реагиров.
Рывок
Тестир.взломом
Финальн.Обзор
Безопас-ности
Сопровожди реагиро-
вание
Списки компонентКритерии качества
Арх. документыПланы по времени
Спецификациидизайна Тестирование и проверка
Разработка нового кода Исправление ошибок
ЭлектроннаяПодпись + Checkpoint
Express
ВЫПУСК
Поддержка,Обновления
Постановка Дизайн Разработка Верификация Выпуск Поддержка
SDL: Дизайн
Модели-рование
угроз
ФункциональныеСпецификации
Традиционные шаги и процессы Жизненного Цикла Безопасности
SDL: Дизайн (2)Применение лучших практик по безопасности:
• Установить и задокументировать критические компоненты безопасности
• Следовать принципам безопасного дизайна• Модульный дизайн• Разрешать минимальные привилегии• Задокументировать и минимизировать
«атакуемую поверхность» - моделирование угроз
• Удовлетворить крипто-стандарты• Не использовать MD4, MD5, SHA1• Гибкость замены крипто-алгоритмов
• Установить «Планку ошибок безопасности» и следовать ей позже во время разработки
• Убедиться в том, что продукты и услуги следуют стандарту приватности
• Если нужно, задать дополнительные критерии безопасности
Уязвимость, угроза, атака
Уязвимость, угроза, атака (2)• Не понимая сути угроз, создавать безопасные
продукты невозможно • Угроза и уязвимость – это не одно и то же• Угроза неустранима• Как злоумышленник попытается атаковать
систему?
Угроза
РесурсСдерживание
Уязвимость
Атака
Категории атак по направленности• Аутентификация – подбор, недостаточная аутентификация,
небезопасное восстановление паролей• Авторизация – предсказуемое значение идентификатора
сессии, перехват сессии, недостаточная авторизация, отсутствие таймаута
• Атаки на клиентов – подмена содержимого, межсайтовый скриптинг
• Несанкционированное выполнение кода – переполнение буфера, атака на функции форматирования строк, LDAP-, Хpath- и SQL-инъекции
• Получение доступа к информации – выявление структуры директорий, идентификация приложений на сервере, предсказуемость расположения ресурсов
• Логические атаки – загрузка серверов, приводящая к отказу в обслуживании, злоупотребление функциональностью, недостаточная проверка процессов
Моделирование угроз
• Систематический обзор архитектуры с точки зрения атакующего
• Определение ресурсов, угроз, уязвимостей, механизмов защиты и рисков
• Имеет большое значение для тестирования безопасности
• Использование модели “STRIDE”• Подробнее – в следующей сегодняшней
презентации
Классификация стандартных угроз
Угроза Защита
Spoofing – подмена информации Проверка подлинности
Tampering – манипулирование данными
Обеспечение целостности данных
Repudiation – аннулирование ответственности
Обеспечение невозможности аннулирования
Information Disclosure – раскрытие информации
Обеспечение конфиденциальности
Denial of Service – отказ в обслуживании
Обеспечение доступности
Elevation of Privilege – несанкционированное повышение прав доступа
Обеспечение надлежащей авторизации доступа
Обучение
Начало,регистрация
продукта
Лучшиепрактики
Обзор арх. и «атакуемой поверхности»
Использов.Средстви лучшихпрактик
Созд.документов
и спец.средств
Подго-товкаплана
реагиров.
Рывок
Тестир.взломом
Финальн.Обзор
Безопас-ности
Сопровожди реагиро-
вание
Списки компонентКритерии качества
Арх. документыПланы по времени
Спецификациидизайна Тестирование и проверка
Разработка нового кода Исправление ошибок
ЭлектроннаяПодпись + Checkpoint
Express
ВЫПУСК
Поддержка,Обновления
Требования Дизайн Разработка Верификация Выпуск Поддержка
SDL: Разработка
Модели-рование
угроз
ФункциональныеСпецификации
Традиционные шаги и процессы Жизненного Цикла Безопасности
SDL: Разработка (2)• Требования к средствам разработки
• Улучшения в Visual Studio, начиная с версии 2005 (компиляция с ключом /GS)
• Переход на более безопасные библиотеки C/C++• Не использовать «небезопасные» функции (
http://msdn2.microsoft.com/en-us/library/bb288454.aspx)
• Использование инструментов статического анализа• Использование ASLR• Использование последних версий компиляторов и и
ХML-парсеров• ...и многое, многое другое
Обучение
Начало,регистрация с
SWI
Лучшиепрактики
Обзор арх. и «атакуемой поверхности»
Использов.Средстви лучшихпрактик
Созд.документов
и спец.средств
Подго-товкаплана
реагиров.
Рывок
Тестир.взломом
Финальн.Обзор
Безопас-ности
Сопровожди реагиро-
вание
Списки компонентКритерии качества
Арх. документыПланы по времени
Спецификациидизайна Тестирование и проверка
Разработка нового кода Исправление ошибок
ЭлектроннаяПодпись + Checkpoint
Express
ВЫПУСК
Поддержка,Обновления
Требования Дизайн Разработка Верификация Выпуск Поддержка
SDL: Верификация
Модели-рование
угроз
ФункциональныеСпецификации
Традиционные шаги и процессы Жизненного Цикла Безопасности
SDL: Верификация (2)• Кодирование завершено – делается тест
безопасности как нового, так и ранее существовавшего кода
• «Фаззинг» для тестирования обработки данных (обработка намеренно некачественных входных данных)o Файлы, RPC, ActiveX, DCOMo Те же методы используют хакеры и
исследователи в области безопасности• Анализаторы безопасности:
o статические (FxCop, PreFast)o Динамические (AppVerifier, Binscope,
CAT.NET) o другие инструменты
• Тесты на основе модели угроз• Tестирование взломом
Обучение
Начало,регистрация
продукта
Лучшиепрактики
Обзор арх. и «атакуемой поверхности»
Использов.Средстви лучшихпрактик
Созд.документов
и спец.средств
Подго-товкаплана
реагиров.
Рывок
Тестир.взломом
Финальн.Обзор
Безопас-ности
Сопровожди реагиро-
вание
Списки компонентКритерии качества
Арх. документыПланы по времени
Спецификациидизайна Тестирование и проверка
Разработка нового кода Исправление ошибок
ЭлектроннаяПодпись + Checkpoint
Express
ВЫПУСК
Поддержка,Обновления
Требования Дизайн Разработка Верификация Выпуск Поддержка
SDL: Выпуск продуктаФинальный Обзор Безопасности (FSR)
Модели-рование
угроз
ФункциональныеСпецификации
Традиционные шаги и процессы Жизненного Цикла Безопасности
SDL: Выпуск продукта (2)
• Задача: проверить что все требования SDL выполнены– Обзор всей проделанной работы по безопасности
перед выпуском продукта, поиск слабых мест– Независимый взгляд на готовность выпуска с точки
зрения безопасности• Шаги
– Специальный вопросник SDLTrack (автоматизация SDL в МС)
– Обзор дизайна и моделей угроз– Анализ поверхности атаки– Проверка средств построения продукта– Анализ известных ошибок– Результаты тестирования взломом– Оценка плана реагирования– Дополнительные критерии
SDL: Выпуск продукта (3) – план реагирования
• Готовность оперативно среагировать на информацию о уязвимости и/или взломе
• План реагирования помогает избежать проблем в сопровождении продукта
• Четко определенная и предсказуемая политика ответа на информацию об уязвимости или взломе
• Поддержка всего кода, включая общие компоненты и промежуточные версии
Заключение
SDL существенно повышает безопасность выпускаемых продуктов при:
• Поддержке руководства • Оснащении надлежащими инструментами• Постоянном усовершенствовании• Внимании со стороны всех дисциплин
Жизненный цикл безопасностиМоделирование угроз
Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса
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-
инъекция, перенаправление на сайт, контролируемый пользователем и многое другое
Жизненный цикл безопасностиМоделирование угроз
Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса
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
Жизненный цикл безопасностиМоделирование угроз
Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса
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
Вопросы?
Жизненный цикл безопасностиМоделирование угроз
Валерий Берестецкий, Microsoft Corporation 27.11.2008, Одесса
59
Спасибо за внимание!
Top Related