Модель оптимизации Microsoft SDL

Общие сведения о реализации
процесса Microsoft SDL
2 февраля 2010 г.
Жизненный цикл обеспечения безопасности при разработке (SDL): основные концепции
1
Последние сведения см. на веб-сайте http://www.microsoft.com/sdl.
Настоящий документ предоставляется в состоянии «как есть». Представленная в нем информация и обзоры, в том числе
URL-адреса и ссылки на другие веб-сайты в Интернете могут быть изменены без уведомления. Вы принимаете на себя весь
риск, связанный с его использованием.
Этот документ не дает вам никаких юридических прав на какую-либо интеллектуальную собственность для какого-либо
продукта Microsoft. Вы можете копировать этот документи использовать его для внутренних целей в качестве справочных
сведений.
© Корпорация Microsoft (Microsoft Corporation), 2010. Все права защищены.
Лицензируется по некоммерческой непортированной лицензии Creative Commons версии 3.0 с сохранением условий .
Общие сведения о реализации процесса Microsoft SDL
1
Содержание
Введение .......................................................................................................................................... 3
Общие сведения о жизненном цикле обеспечения безопасности
при разработке (Майкрософт) ........................................................................................................ 3
Обеспечение безопасности при разработке в корпорации Майкрософт .................................... 4
Модель оптимизации Microsoft SDL ............................................................................................... 5
Применимость процесса SDL ......................................................................................................... 6
Роли, ответственность и навыки сотрудников, отвечающих за безопасность .......................... 6
Общие сведения о действиях по обеспечению безопасности в рамках SDL ............................ 7
Обязательные действия по обеспечению безопасности ............................................................. 8
Требования при подготовке к SDL. Обучение мерам безопасности ...................................... 8
Первый этап. Требования .......................................................................................................... 9
Второй этап. Проектирование ................................................................................................. 11
Третий этап. Реализация ......................................................................................................... 12
Четвертый этап. Проверка ....................................................................................................... 13
Пятый этап. Выпуск .................................................................................................................. 13
Дополнительные действия по обеспечению безопасности ....................................................... 15
Другие требования процесса........................................................................................................ 15
Анализ первопричин ..................................................................................................................... 15
Периодические обновления процесса ......................................................................................... 16
Процедура проверки безопасности приложения ........................................................................ 16
Заключение .................................................................................................................................... 18
Приложение A. Схема процесса SDL .......................................................................................... 19
Общие сведения о реализации процесса Microsoft SDL
2
Введение
В этой статье иллюстрируются основные концепции жизненного цикла обеспечения безопасности
при разработке (Security Development Lifecycle, SDL) корпорации Майкрософт и обсуждаются
конкретные действия по обеспечению безопасности, которые должны быть выполнены
в соответствии с процессом SDL.
В этой статье рассматриваются следующие вопросы.



Краткое описание процесса Microsoft SDL.
Общие сведения о модели оптимизации Microsoft SDL; особое внимание уделяется
обеспечению соответствия процесса Microsoft SDL модели оптимизации.
Обсуждение отдельных компонентов Microsoft SDL, включая перечисленные ниже.




Роли и обязанности участников процесса разработки приложений.
Обязательные действия по обеспечению безопасности.
Дополнительные действия по обеспечению безопасности.
Процедура проверки безопасности приложения.
Методология, описанная в настоящей статье, устанавливает минимальный порог соответствия
процессу SDL. В то же время каждая организация уникальна, и группы разработчиков должны
применять SDL в соответствии со своими возможностями и имеющимися ресурсами, но не нарушая
при этом безопасности организации.
Следует отметить, что в данном документе описываются исключительно методологии обеспечения
безопасности при разработке программного обеспечения, которые применяются для построения
приложений и веб-служб для внешнего или внутреннего использования. В рамках организации
существуют и другие методологии (например, принципы ИТ-безопасности), которые
предназначены для борьбы с угрозами «операционной» безопасности. Хотя группы, занимающиеся
администрированием таких процессов, могут быть связаны теми же технологическими
и регулятивными контекстами, что и группы разработчиков программного обеспечения, они
обычно не занимаются созданием приложений, предназначенных для использования в средах со
значимыми угрозами безопасности.
Везде, где это возможно, приводятся ссылки на открытые источники информации. Кроме того,
в документ включены веб-ссылки на конкретные обсуждения процессов и инструментов и на другие
вспомогательные материалы.
Общие сведения о жизненном цикле обеспечения безопасности
при разработке (Майкрософт)
Жизненный цикл обеспечения безопасности при разработке (Security Development Lifecycle, SDL) —
это процесс обеспечения безопасности в сфере разработки программного обеспечения. Процесс SDL,
который является инициативой компании и обязательной политикой с 2004 г., сыграл важнейшую
роль во внедрении принципов безопасности и конфиденциальности как в программное обеспечение,
так и в корпоративную культуру Майкрософт. Сочетая в себе как глобальный, так и практический
подход, процесс SDL призван уменьшить число уязвимостей в программном обеспечении и уровень
их серьезности. SDL позволяет обеспечить безопасность и конфиденциальность на всех этапах
процесса разработки.
Общие сведения о реализации процесса Microsoft SDL
3
В основе Microsoft SDL лежат три основных принципа — обучение, непрерывное усовершенствование
процесса и отчетность. Постоянное обучение инженеров группы разработки ПО является
критически важным. Соответствующие инвестиции в пополнение общей базы знаний помогают
организациям оперативно реагировать на изменения технологии и среды угроз безопасности.
Поскольку угрозы безопасности все время меняются, в процессе SDL самое пристальное внимание
уделяется пониманию причин и последствий наличия уязвимых мест в системе безопасности.
Необходимо регулярно выполнять оценку процедур SDL и вносить изменения при появлении новых
технологий или новых угроз. Для оценки эффективности обучения выполняется сбор данных;
показатели, полученные в ходе работы, используются для подтверждения соответствия процесса
нормативам, а показатели, полученные после выпуска продукта, помогают спланировать будущие
изменения. Кроме того, процесс SDL требует архивирования всех данных, необходимых для
обслуживания приложения в кризисной ситуации. Имея детально разработанные планы связи
и реагирования в случае нарушения безопасности, организация может предоставить краткие
и обоснованные инструкции всем заинтересованным сторонам.
Обеспечение безопасности при разработке в корпорации
Майкрософт
В настоящем документе описывается применение процесса Microsoft
SDL к технологиям разработки, которые обычно используются в других
организациях (не в Майкрософт). Содержание этой статьи тесно
взаимосвязано с опубликованным описанием процесса, который
применяется при разработке продуктов и служб Майкрософт. Однако
следует отметить, что в корпорации Майкрософт основные концепции,
описанные в этой статье, расширены, и SDL применяется как процесс,
отражающий деловые и технические контексты организации. Процесс
SDL в том виде, в котором он используется в Майкрософт, основан на
ключевых принципах, изложенных в этой статье. Он применялся
к сотням продуктов Майкрософт, запущенных в различных
операционных системах и на различных аппаратных платформах. Те же
ключевые принципы группы инженеров Майкрософт используют
в более чем сотне стран по всему миру для решения уникальных задач
по обеспечению безопасности и конфиденциальности, возникающих
при таком широком спектре технологий.
В процессе Microsoft SDL,
описанном в настоящей
статье, особое внимание
уделяется применению
проверенных
рекомендаций по
обеспечению
безопасности на
определенных этапах
жизненного цикла
разработки программного
обеспечения. Этот
процесс не зависит от
конкретной технологии
и может использоваться
не только на крупных
предприятиях, но и в
организациях любого
масштаба.
Корпорация Майкрософт придает большое значение прозрачности процесса обеспечения
безопасности и конфиденциальности. В ответ на просьбы пользователей предоставить более
подробные сведения о том, как корпорация Майкрософт обеспечивает безопасность своих
продуктов и служб с помощью процесса SDL, на веб-сайте www.microsoft.com/sdl был опубликован
подробный отчет (на английском языке).
Общие сведения о реализации процесса Microsoft SDL
4
Модель оптимизации Microsoft SDL
Если интеграция принципов обеспечения безопасности при разработке в существующий процесс
разработки выполняется ненадлежащим образом, она может оказаться сложной и дорогостоящей.
Успех или неудача интеграции часто зависит от таких факторов, как масштаб организации,
имеющиеся ресурсы (время, навыки сотрудников и выделенные средства), а также поддержка
руководства. Влияние этих факторов можно свести к минимуму путем четкого понимания
компонентов технологии обеспечения безопасности при разработке и установки приоритетов
реализации в соответствии с уровнем подготовки группы разработчиков. Для этого и была создана
модель оптимизации SDL.
Модель оптимизации SDL построена на основе пяти функциональных областей, которые в первом
приближении соответствуют этапам жизненного цикла разработки ПО:





обучение, политика и организация;
требования и проектирование;
реализация;
проверка;
выпуск и реагирование.
Кроме того, в модели оптимизации SDL определены четыре уровня зрелости для технологий
и возможностей в этих областях: базовый, стандартный, расширенный и динамический.
Модель оптимизации SDL имеет четыре уровня зрелости: от базового уровня, согласно которому
процессы, обучение и применение специальных средств если и присутствуют, то в небольшом объеме, до
динамического уровня, для которого характерно полное соответствие SDL во всей организации.
Полное соответствие SDL означает эффективные процессы, высокий уровень обучения инженеров,
применение специальных инструментов и строгую отчетность перед заинтересованными
сторонами, как внутренними, так и внешними по отношению к данной организации.
В данной статье в основном рассматриваются
задачи и процессы, необходимые для
достижения расширенного уровня зрелости.
Это означает, что организация, которая
может продемонстрировать свои достижения
в каждой из пяти функциональных областей,
упомянутых выше, может в достаточной
степени
претендовать
на
следование
рекомендациям Microsoft SDL.
В отличие от других моделей зрелости
программного
обеспечения,
модель
оптимизации Microsoft SDL сфокусирована
строго на улучшениях процесса разработки.
Рис. 1. Модель оптимизации SDL с функциональными областями Она предлагает грамотное, обоснованное
и уровнями зрелости
руководство по переходу от более низких
уровней зрелости процесса к более высоким
и позволяет избежать подхода «список
списков», характерного для других моделей
оптимизации.
Общие сведения о реализации процесса Microsoft SDL
5
Применимость процесса SDL
Очень важно, чтобы организация имела четкие представления о типах проектов, к которым будет
применяться технология Microsoft SDL. Практика показывает, что эту технологию следует применять
к приложениям, имеющим один или несколько из следующих признаков:



приложение развернуто в бизнес-среде или на предприятии;
приложение обрабатывает персональные данные или другие конфиденциальные сведения;
приложение регулярно подключается к Интернету или другим сетям.
Учитывая распространенность компьютерных технологий и развитие среды угроз безопасности,
легче перечислить проекты разработки приложений, к которым применять технологии
обеспечения безопасности, такие как в SDL, не нужно.
Роли, ответственность и навыки сотрудников, отвечающих
за безопасность
Процесс SDL включает общие условия и описания функций для ролей безопасности
и конфиденциальности. Эти роли заполняются на этапе определения требований процесса SDL. Они
носят консультативный характер и обеспечивают организационную структуру, необходимую для
определения, каталогизации и решения вопросов безопасности и конфиденциальности,
возникающих в проекте разработки программного обеспечения. Сюда входят следующие роли.

Роли проверяющих и советников. Эти роли предназначены для контроля безопасности
и конфиденциальности проекта. Они наделены полномочиями утверждать или отклонять планы
по обеспечению безопасности и конфиденциальности, предложенные группой проекта.

Советник по безопасности и советник по конфиденциальности.
Эти роли заполняются экспертами не из группы проекта. Эту роль
может занимать либо компетентный член независимой
централизованной группы в рамках организации, специально
уполномоченный для выполнения такого рода проверок, либо
внешний по отношению к организации специалист. Лицо,
выполняющее эту задачу, должно принадлежать к двум следующим
подчиненным ролям.



Для этих ролей
рекомендуется
создавать
централизованную
внутреннюю группу
советников, которая
обеспечивает знание
конкретной
организации и ее
внутренних процессов
в добавление к
функциям внешних
экспертов.
Аудитор. Этот специалист должен наблюдать за каждым
этапом процесса разработки программного обеспечения
и подтверждать успешное выполнение каждого требования
безопасности.
Советник
должен
иметь
возможность
подтвердить (или не подтвердить) соответствие требованиям
безопасности и конфиденциальности без вмешательства со стороны группы проекта.
Эксперт. Специалист, выбранный для роли советника, должен обладать доказанным
опытом в вопросах безопасности.
Сочетание ролей советников. Роль советника по безопасности можно сочетать с ролью
советника по конфиденциальности, если кандидат обладает соответствующими навыками
и опытом.
Общие сведения о реализации процесса Microsoft SDL
6

Руководители групп. На роли руководителей групп следует назначать экспертов из группы
проекта. Эти роли отвечают за согласование, принятие и отслеживание минимальных
требований безопасности и конфиденциальности и обеспечение надежных каналов связи с
советниками и лицами, ответственными за принятие решений, в ходе проекта разработки ПО.

Руководитель по безопасности и руководитель по конфиденциальности. Этот сотрудник
(или группа сотрудников) не несет единоличной ответственности за то, чтобы в выпуске
программного обеспечения были решены все вопросы безопасности, но отвечает за
координацию и отслеживание вопросов безопасности для проекта. Кроме того, эта роль
должна сообщать состояние советнику по безопасности и другим заинтересованным
сторонам (например, руководителям групп разработчиков и тест-инженеров) в группе
проекта.

Сочетание ролей. Так же как и в случае роли советника по безопасности
и конфиденциальности, обязанности ролей руководителей можно сочетать, если кандидат
обладает соответствующими навыками и опытом.
Общие сведения о действиях по обеспечению безопасности
в рамках SDL
Если говорить упрощенно, Microsoft SDL представляет собой набор
обязательных действий по обеспечению безопасности, перечисленных
в порядке их выполнения и сгруппированных по этапам стандартного
жизненного цикла разработки ПО. Если каждое такое действие
выполнять независимо, многие из них могли бы обеспечить некоторое
повышение уровня безопасности. Однако опыт, накопленный
в корпорации Майкрософт, показывает, что выполнение действий по
обеспечению безопасности в рамках процесса разработки ПО
позволяет обеспечить более высокую степень безопасности, чем
выполнение тех же действий по отдельности или без единого плана.
Особое внимание
следует уделять
точности выходных
данных на каждом этапе
проекта. Непонятные
отчеты с неполными
или неверными
сведениями — это
пустая трата времени
и ресурсов.
Для выполнения поставленных целей по обеспечению безопасности и конфиденциальности группа
проекта или советник по безопасности могут предложить дополнительные действия. Для краткости
изложения подробное описание каждого действия по обеспечению безопасности не приводится.
Рис. 2. Жизненный цикл обеспечения безопасности при разработке (Майкрософт): упрощенная схема
Общие сведения о реализации процесса Microsoft SDL
7
Базовый принцип, который следует отметить, состоит в том, что организация должна уделять самое
пристальное внимание качеству и полноте выходных данных, полученных на каждом этапе проекта.
Если в организации реализованы расширенный и динамический уровни модели оптимизации SDL,
следует ожидать некоторого усложнения процесса обеспечения безопасности. С другой стороны,
совершенно неважно, например, получена ли модель рисков в результате совещания с группой
разработчиков, записана ли она как примечание в документе Microsoft Word или разработана
с использованием специального инструмента, такого как средство моделирования рисков SDL.
Конечно, от вложений в эффективные инструменты и автоматизацию процесс SDL только выиграет,
но сосредоточить усилия необходимо именно на получении полных и точных результатов.
Для удобства изложения подробная схема процесса SDL вынесена в Приложение A. На этой схеме
показаны действия по обеспечению безопасности (от обучения сотрудников до выпуска
приложения), которые используются в гипотетическом проекте. В этот пример включены как
обязательные, так и дополнительные задачи.
Обязательные действия по обеспечению безопасности
Если к проекту разработки ПО решено применить процесс Microsoft SDL (см. раздел Применимость
процесса SDL), для реализации этого процесса группа разработчиков должна успешно выполнить
шестнадцать обязательных действий по обеспечению безопасности. Эффективность этих действий
признана экспертами по безопасности и конфиденциальности и постоянно подтверждается в ходе
строгой ежегодной процедуры оценки. Как упоминалось выше, группы разработчиков могут счесть
необходимыми и другие операции, но список обязательных процедур всегда должен включать
шестнадцать действий, описанных в данном документе.
Требования при подготовке к SDL. Обучение мерам безопасности
SDL, рекомендация 1. Требования к обучению
Все члены группы разработчиков ПО должны пройти соответствующее обучение, чтобы получить
знания по основам безопасности и быть в курсе последних тенденций в сфере безопасности
и конфиденциальности.
Сотрудники,
выполняющие
технические
роли
(разработчики,
тест-инженеры и руководители программ) и принимающие непосредственное участие в разработке
ПО, должны проходить хотя бы один новый курс по вопросам безопасности ежегодно.
Базовый обучающий курс по безопасности ПО должен освещать основные темы, примеры которых
приведены ниже.


Обеспечение безопасности при проектировании приложений, включая следующие вопросы:
 уменьшение количества возможных направлений для злоумышленных атак;
 подробные сведения о защите;
 принцип предоставления минимальных прав;
 параметры по умолчанию для обеспечения безопасности.
Моделирование рисков, включая следующие вопросы:
 общие сведения о моделировании рисков;
 влияние модели рисков на проектирование;
 ограничения кода в соответствии с моделью рисков.
Общие сведения о реализации процесса Microsoft SDL
8



Написание безопасного кода, включая следующие вопросы:
 переполнения буфера (для приложений, написанных на языках C и C++);
 ошибки целочисленных арифметических операций (для приложений, написанных
на языках C и C++);
 запуск скриптов между сайтами (для управляемого кода и веб-приложений);
 внедрение кода SQL (для управляемого кода и веб-приложений);
 слабая криптографическая защита.
Проверка безопасности, включая следующие вопросы:
 различия между проверкой безопасности и функциональным тестированием;
 оценка рисков;
 способы проверки безопасности.
Конфиденциальность, включая следующие вопросы:
 типы конфиденциальных данных;
 рекомендации по обеспечению конфиденциальности при проектировании;
 оценка рисков;
 рекомендации по обеспечению конфиденциальности при разработке;
 рекомендации по тестированию конфиденциальности.
Перечисленные темы обучения позволяют обеспечить соответствующие базовые знания для
технических специалистов. Если позволяют время и ресурсы, может потребоваться дополнительное
обучение, возможные темы которого приведены ниже:




дополнительные сведения по проектированию и архитектуре защищенных приложений;
проектирование надежного интерфейса пользователя;
подробные сведения об уязвимых местах системы безопасности;
внедрение специальных методов защиты от угроз.
Первый этап. Требования
SDL, рекомендация 2. Требования безопасности
Упреждающее планирование безопасности и конфиденциальности является важнейшим аспектом
разработки защищенных систем. Требования к надежности для проекта ПО лучше всего определять
на самых ранних этапах планирования. Такое раннее формулирование требований позволяет
группам разработчиков определять основные этапы и конечные результаты, причем интеграция
безопасности и конфиденциальности выполняется таким образом, что вероятность нарушения
планов и графиков сводится к минимуму. Анализ требований безопасности и конфиденциальности
выполняется в самом начале проекта и предусматривает составление списка минимальных
требований безопасности для работы приложения в планируемой оперативной среде, а также
подробное документирование и развертывание системы отслеживания уязвимых мест в рабочих
элементах.
Общие сведения о реализации процесса Microsoft SDL
9
SDL, рекомендация 3. Контрольные условия качества и панели ошибок
Контрольные условия качества и панели ошибок используются для задания минимально
приемлемых уровней безопасности и конфиденциальности. Определение этих условий в начале
работы над проектом позволяет рабочим группам лучше понять риски, связанные с вопросами
безопасности, а также найти и исправить ошибки безопасности в ходе разработки. Группа проекта
должна согласовать контрольные условия качества (например, перед возвратом кода все
предупреждения компилятора должны быть рассортированы и исправлены) для каждого этапа
разработки. Затем эти условия должен утвердить советник по безопасности; он также может при
необходимости добавить уточнения и более строгие требования безопасности для конкретного
проекта. Кроме того, группа проекта должна продемонстрировать соответствие согласованным
контрольным условиям качества, Это позволит выполнить окончательную проверку безопасности.
Панель ошибок — это контрольное условие качества, которое применяется ко всему проекту
разработки ПО в целом. Она используется для определения порогов серьезности уязвимых мест
системы безопасности — например, для определения отсутствия известных уязвимостей с оценкой
«критическая» или «важная» в приложении на момент его выпуска. Строгость уже заданной панели
ошибок никогда не должна уменьшаться. Динамически изменяющаяся панель ошибок представляет
собой переменную цель, которая плохо поддается пониманию при организации разработки.
SDL, рекомендация 4. Оценка рисков безопасности и конфиденциальности
Оценки рисков безопасности и конфиденциальности — это обязательные процедуры, позволяющие
определить функциональные аспекты программного обеспечения, которые требуют серьезной
проверки. В ходе таких оценок необходимо получить следующие сведения.
1.
2.
3.
4.
5.
6.
(Безопасность) Для каких компонентов проекта перед выпуском потребуется моделирование
рисков?
(Безопасность) Для каких компонентов проекта перед выпуском потребуется анализ
обеспечения безопасности при проектировании?
(Безопасность) Для каких компонентов проекта потребуется тестирование на проникновение,
выполняемое взаимно согласованной группой (внешней по отношению к группе проекта), если
такое тестирование необходимо?
(Безопасность) Существуют ли дополнительные требования к тестированию или анализу,
которые советник по безопасности считает необходимыми для защиты от угроз?
(Безопасность) Какова конкретная область требований нечеткого тестирования?
(Конфиденциальность) Какова оценка влияния на конфиденциальность? Ответ на этот вопрос
базируется на приведенных ниже положениях.

P1: высокий риск нарушения конфиденциальности. Функция, продукт или служба хранит или
передает персональные данные, изменяет параметры или сопоставления для типов файлов
либо устанавливает программное обеспечение.

P2: умеренный риск нарушения конфиденциальности. К операциям, влияющим на
конфиденциальность в функции, продукте или службе, относятся только разовая
инициированная пользователем анонимная передача данных (например, пользователь
щелкает ссылку, и приложение переходит к веб-сайту).

P3: низкий риск нарушения конфиденциальности. Никакие операции, выполняемые в рамках
функции, продукта или службы, не влияют на конфиденциальность. Анонимные и персональные
данные не передаются, персональные данные не хранятся на компьютере, параметры от имени
пользователя не изменяются, программное приложение не устанавливается.
Общие сведения о реализации процесса Microsoft SDL
10
Второй этап. Проектирование
SDL, рекомендация 5. Требования проектирования
Надежность структуры проекта лучше всего закладывать на ранних стадиях его жизненного цикла.
На этапе проектирования очень важно детально рассмотреть вопросы безопасности
и конфиденциальности. Если решение вопросов безопасности и конфиденциальности выполняется
в самом начале жизненного цикла проекта, оно обходится гораздо дешевле. Группы проекта не
должны откладывать решение проблем безопасности и конфиденциальности и создание
соответствующих функций до последних стадий разработки проекта.
Кроме того, для групп проекта очень важно понимать различия между защищенными функциями
и функциями защиты. Можно реализовать функции защиты, которые на самом деле не защищены.
Защищенные функции — это функции, которые правильно выстроены
с точки зрения безопасности, включая строгую проверку всех данных
Метод формального
исключения или отсрочки
перед обработкой или реализацию библиотек для служб шифрования
ошибок должен
с использованием сильной криптографической защиты. Термин
рассматриваться как
функции защиты описывает компоненты программы, имеющие
неотъемлемая часть
отношение к безопасности, такие как проверка подлинности Kerberos
любого процесса
разработки ПО. В основе
или брандмауэр.
многих приложений лежат
унаследованные структура
Комплекс мер, связанных с требованиями проектирования, состоит из
и код, поэтому, возможно,
ряда обязательных действий. Сюда, например, входят создание
потребуется отложить
технических условий на проектирование для безопасности
некоторые операции
и конфиденциальности, проверка технических условий и составление
по оценке уровня
безопасности и
списка минимальных требований проектирования для шифрования.
конфиденциальности из-за
Технические условия проектирования должны описывать функции
технических ограничений.
обеспечения безопасности или конфиденциальности, с которыми
пользователи будут непосредственно взаимодействовать, например
функции, в которых требуется проверка подлинности пользователя для доступа к определенным
данным или согласие пользователя перед применением компонента с высоким риском нарушения
конфиденциальности. Кроме того, все технические условия проектирования должны описывать
способы безопасной реализации каждой возможности, которую предоставляет данный компонент
или функция. Технические условия проектирования рекомендуется сверять с функциональной
спецификацией приложения. Функциональная спецификация должна:


точно и полно описывать предполагаемое применение компонента или функции;
описывать способы развертывания компонента или функции с обеспечением безопасности.
SDL, рекомендация 6. Уменьшение количества возможных направлений для злоумышленных атак
Уменьшение количества возможных направлений для злоумышленных атак тесно связано
с моделированием рисков, хотя этот подход позволяет рассматривать вопросы безопасности
немного под другим углом. Уменьшение количества возможных направлений для злоумышленных
атак — это способ снизить риски, предоставляя злоумышленникам меньше возможностей для
использования возможных слабых мест или уязвимостей. Этот подход предполагает закрытие или
ограничение доступа к системным службам, применение принципа предоставления минимальных
прав и организацию многоуровневой системы защиты везде, где это возможно.
Общие сведения о реализации процесса Microsoft SDL
11
SDL, рекомендация 7. Моделирование рисков
Моделирование рисков используется в средах с высокой
вероятностью нарушения безопасности. Эта процедура позволяет
группе разработчиков рассмотреть, задокументировать и обсудить
последствия выбора разных вариантов проектирования для
безопасности в контексте планируемой рабочей среды, объединяя эти
данные в четкую структуру. Кроме того, моделирование рисков
позволяет рассматривать вопросы безопасности на уровне
компонента или приложения. В моделировании рисков принимают
участие члены рабочей группы: руководители программы или проекта,
разработчики и тест-инженеры. Моделирование рисков — это
основная задача анализа безопасности, которая выполняется на этапе
проектирования ПО.
Для моделирования
рисков рекомендуется
использовать средство
моделирования рисков
SDL. В основе этого
инструмента лежит
классификация
рисков STRIDE.
Третий этап. Реализация
SDL, рекомендация 8. Использование утвержденных инструментов
Каждая группа разработчиков должна составить и опубликовать список утвержденных
инструментов и связанных с ними проверок безопасности, таких как параметры и предупреждения
компилятора и компоновщика. Такой список для группы проекта должен утвердить советник по
безопасности. В общем случае группе разработчиков рекомендуется использовать последнюю
версию утвержденных инструментов, что позволяет применить все новые функции защиты
и анализа безопасности.
SDL, рекомендация 9. Отказ от небезопасных функций
Многие часто используемые функции и программные интерфейсы в среде современных угроз не
могут считаться безопасными. Группы проекта должны проанализировать все функции
и программные интерфейсы, которые предполагается использовать в проекте разработки ПО,
и отказаться от тех из них, которые будут признаны небезопасными. Как только черный список будет
определен, группа проекта должна с помощью файлов заголовков (таких, как banned.h и strsafe.h),
более новых компиляторов или инструментов сканирования кода проверить код (включая код,
унаследованный из других программ) на наличие запрещенных функций, а затем заменить эти
функции на более безопасные аналоги.
SDL, рекомендация 10. Статический анализ
Группы проекта должны выполнять статический анализ исходного
кода. Такой анализ обеспечивает масштабируемую возможность
проверки безопасности кода и может помочь убедиться в выполнении
политик создания безопасного кода. Сам по себе статический анализ
обычно не может заменить ручную проверку кода. Члены группы
безопасности и советники по безопасности должны четко понимать
все сильные и слабые стороны инструментов статического анализа
и при необходимости заменять эти инструменты другими средствами
или проверкой вручную.
Общие сведения о реализации процесса Microsoft SDL
В общем случае группы
разработчиков должны
определить оптимальную
частоту выполнения
статического анализа,
которая позволит
сохранить баланс между
производительностью
и обеспечением
достаточного уровня
безопасности.
12
Четвертый этап. Проверка
SDL, рекомендация 11. Динамический анализ программы
Для того чтобы убедиться, что все функции программы работают так, как планировалось,
необходима проверка ПО во время выполнения. Такая проверка предполагает выбор
инструментов, которые во время работы приложения отслеживают возможные повреждения
памяти, права пользователей и другие важные вопросы безопасности. В процессе SDL для
обеспечения нужного уровня проверки безопасности используются такие инструменты времени
выполнения, как AppVerifier, а также другие технологии, например нечеткое тестирование.
SDL, рекомендация 12. Нечеткое тестирование
Нечеткое тестирование — это специальный вид динамического анализа, при котором путем
намеренного ввода в приложение неверно сформированных или случайных данных вызывается сбой
программы. Стратегия нечеткого тестирования разрабатывается на основе данных о планируемом
использовании приложения, технических условий проектирования и функциональной спецификации.
Советник по безопасности может потребовать проведения дополнительных нечетких тестов или
увеличения области и длительности нечеткого тестирования.
SDL, рекомендация 13. Анализ модели рисков и возможных направлений для злоумышленных атак
Очень часто приложение в значительной мере отклоняется от функциональной спецификации
и технических условий проектирования созданных в ходе этапов формирования требований
и проектирования разработки ПО. Таким образом, очень важно выполнить повторный анализ
моделей рисков и возможных направлений для злоумышленных атак после того, как создание кода
конкретного приложения будет завершено. Такой анализ позволяет убедиться, что все изменения,
внесенные в систему в ходе проектирования и реализации, учтены, а любые новые векторы атак,
созданные в результате таких изменений, проверены и обезврежены.
Пятый этап. Выпуск
SDL, рекомендация 14. План реагирования на инциденты
Каждый выпуск ПО, к которому применяются требования SDL, должен иметь план реагирования на
инциденты. Даже программы, в которых на момент выпуска отсутствуют известные уязвимости,
могут быть не защищены от новых угроз, которые появятся в будущем. План реагирования на
инциденты должен включать следующие компоненты.




Определенная группа инженерной поддержки. Если размер группы не позволяет выделить
ресурсы инженерной поддержки, — план реагирования на аварийную ситуацию, где должны
быть указаны специалисты, отвечающие за инженерную поддержку, маркетинг, связь
и управление, к которым следует обращаться в первую очередь при возникновении экстренных
случаев, связанных с безопасностью.
Контактные данные лиц, имеющих право принимать решения и доступных 24 часа в сутки,
семь дней в неделю.
Планы обеспечения безопасности для кода, унаследованного от других групп в той же организации.
Планы обеспечения безопасности для лицензированного кода сторонних производителей,
включая имена файлов, версии, исходный код, контактные данные этих сторонних производителей
и (при необходимости) разрешение на внесение изменений, подтвержденное договором.
Общие сведения о реализации процесса Microsoft SDL
13
SDL, рекомендация 15. Окончательная проверка безопасности
Окончательная проверка безопасности — это тщательное изучение всех действий по обеспечению
безопасности, выполненных до выпуска приложения. Такую проверку выполняет советник по
безопасности с помощью штатных разработчиков, а также руководителей групп безопасности
и конфиденциальности. Окончательная проверка безопасности не предполагает ни операций типа
«проникновение и исправление», ни выполнения ранее пропущенных действий по обеспечению
безопасности. Обычно в ходе такой проверки выполняется изучение моделей рисков, запросов
исключений, производительности и выходных данных различных инструментов на предмет
соответствия ранее определенным контрольным условиям качества или панелям ошибок.
Существует три возможных результата окончательной проверки безопасности.



Окончательная проверка безопасности пройдена. Все проблемы безопасности
и конфиденциальности, обнаруженные в ходе проверки, решены полностью или частично.
Окончательная проверка безопасности пройдена с исключениями. Все проблемы
безопасности и конфиденциальности, обнаруженные в ходе проверки, решены полностью или
частично и (или) все исключения удовлетворительно разрешены. Проблемы, которые нельзя
решить (например, уязвимости, вызванные проблемами унаследованного кода «уровня
проектирования»), заносятся в журнал и исправляются в следующем выпуске.
Окончательная проверка безопасности с эскалацией. Если рабочей группе не удалось
выполнить все требования SDL, а советник по безопасности и группа продукта не смогли
прийти к приемлемому соглашению, советник по безопасности может не утвердить проект,
который, в свою очередь, не будет выпущен. В этой ситуации рабочие группы должны либо
попытаться соблюсти те требования SDL, которые можно выполнить до выпуска, либо
предоставить решение высшему руководству.
SDL, рекомендация 16. Выпуск и архив
Выпуск программного обеспечения для производства или для Интернета зависит от завершения
процесса SDL. Советник по безопасности, назначенный для данного выпуска, должен подтвердить
(с помощью окончательной проверки безопасности или других данных), что группа проекта
выполнила требования безопасности. Аналогично перед выпуском любого продукта, имеющего
хотя бы один компонент с оценкой влияния на конфиденциальность, равной P1, советник по
конфиденциальности проекта должен подтвердить, что группа проекта выполнила требования
конфиденциальности.
Кроме того, все релевантные данные должны быть заархивированы, что позволит выполнять
обслуживание программного обеспечения после выпуска. К таким данным относятся все
спецификации и технические условия, исходный код, двоичные файлы, закрытые символы, модели
рисков, документация, планы реагирования в аварийной ситуации, условия лицензионного
соглашения и обслуживания для любого ПО сторонних производителей, а также любые другие
сведения, необходимые для выполнения задач обслуживания после выпуска.
Общие сведения о реализации процесса Microsoft SDL
14
Дополнительные действия по обеспечению безопасности
Дополнительные действия по обеспечению безопасности обычно выполняются в том случае, если
приложение предполагается использовать в потенциально опасных средах или сценариях. Такие
действия часто определяются советником по безопасности как часть согласованного набора
дополнительных требований, что позволяет обеспечить более высокий уровень анализа
безопасности для некоторых компонентов ПО. Примеры дополнительных задач по обеспечению
безопасности, приведенные в этом разделе, не должны рассматриваться как исчерпывающий
список таких задач.
Ручная проверка кода
Ручная проверка кода — это дополнительная задача в SDL, которую обычно выполняют
высококвалифицированные специалисты из группы безопасности приложения и (или) советник по
безопасности. Хотя средства анализа позволяют найти и отметить большую часть уязвимостей, их
работа все же несовершенна. Соответственно, ручная проверка кода обычно сфокусирована на
потенциально небезопасных компонентах приложения. Чаще всего это те компоненты, в которых
обрабатываются или хранятся конфиденциальные сведения, например персональные данные.
Кроме того, ручная проверка используется для анализа других потенциально небезопасных
функций, например реализации шифрования.
Тестирование на проникновение
Тестирование на проникновение — это анализ безопасности теста
модуля
для
программной
системы,
который
выполняют
высококвалифицированные
специалисты,
имитирующие
действия
злоумышленника.
Цель
такого
тестирования
—
обнаружение
потенциальных уязвимостей, которые являются результатом ошибок
кода, сбоев в настройке системы или других слабых мест оперативного
развертывания. Тесты на проникновение часто выполняются в сочетании
с автоматической и ручной проверкой кода, что позволяет обеспечить
более высокий, чем обычно, уровень анализа.
Любые проблемы,
обнаруженные в ходе
тестирования на
проникновение,
должны быть решены
до того, как выпуск
проекта будет
утвержден.
Анализ уязвимостей аналогичных приложений
Часто надежные источники сведений об уязвимостях программного обеспечения можно найти
в Интернете. В некоторых случаях анализ уязвимостей, найденных в аналогичных приложениях,
может пролить свет на потенциальные проблемы проектирования или реализации
разрабатываемого ПО.
Другие требования процесса
Анализ первопричин
Хотя анализ первопричин обычно не является частью процесса разработки ПО, он играет важную
роль в обеспечении безопасности приложения. После обнаружения новой, не известной ранее
уязвимости следует провести анализ и точно установить причину сбоя процессов безопасности.
Уязвимости могут вызываться рядом причин, включая человеческий фактор, сбой средства или
ошибку политики. Целью анализа первопричин является точное определение природы сбоя. Эти
сведения помогают учитывать ошибки того же типа в будущих редакциях SDL.
Общие сведения о реализации процесса Microsoft SDL
15
Периодические обновления процесса
Угрозы безопасности постоянно совершенствуются, и процесс, который используется для
обеспечения безопасности ПО, тоже не может стоять на месте. Организации должны применять
сведения, полученные в результате таких операций, как анализ первопричин, изменения политик
и усовершенствование технологии и автоматизации, к процессу SDL согласно определенному
графику. Вообще говоря, ежегодного обновления должно быть достаточно. Исключение из этого
правила делается тогда, когда обнаруживаются новые, не известные ранее типы уязвимостей.
В этом случае необходим срочный внеплановый выпуск новой редакции SDL, чтобы обеспечить
своевременное обезвреживание угроз.
Процедура проверки безопасности приложения
Организациям, разрабатывающим защищенные приложения, конечно же, требуются инструменты
для проверки соответствия процессам Microsoft SDL. Доступ к централизованным данным
разработки и тестирования помогает принимать решения во многих случаях, таких как
окончательная проверка безопасности, обработка исключений требований SDL и аудиты
безопасности. В процедуру проверки безопасности приложения вовлечен ряд различных
процессов и действующих лиц.
 Для отслеживания соответствия SDL следует использовать специально выделенное приложение,
которое служит центральным хранилищем для всех артефактов процесса SDL, включая заметки
по проектированию и реализации, модели рисков, переданные файлы журналов инструментов
и другие данные аттестации процессов, а также дополнительные сведения. Так же как любая
важная программа, такое приложение должно использовать элементы управления доступом,
позволяющие обеспечить следующие положения.





С приложением могут работать только полномочные пользователи.
Строгое разделение ролей. Например, разработчику может быть разрешено использовать
приложение и загружать данные, но запрещено получать доступ к функциям, с которыми
могут работать только советники по безопасности и конфиденциальности, руководители
групп безопасности и тест-инженеры.
Руководители групп безопасности и конфиденциальности отвечают за то, чтобы данные,
необходимые для объективной оценки, были правильно классифицированы и введены
в приложение отслеживания.
Сведения, введенные в приложение отслеживания, используют советники по безопасности
и конфиденциальности, что позволяет обеспечить среду для окончательной проверки
безопасности.
Советники по безопасности и конфиденциальности отвечают за анализ данных, введенных
в приложение отслеживания (включая результаты окончательной проверки безопасности
и дополнительные
задачи
обеспечения
безопасности,
назначенные
советниками),
и подтверждение как выполнения всех требований, так и удовлетворительного разрешения
всех исключений.
Общие сведения о реализации процесса Microsoft SDL
16
В этом документе в основном рассматривается расширенный уровень модели оптимизации SDL,
согласно которому простейших процедур отслеживания зачастую оказывается недостаточно.
Вместе с тем организации с менее сложными процессами или меньшими пулами ресурсов,
использующие базовый или стандартный уровень модели оптимизации SDL, могут, вероятно,
применять более простую процедуру отслеживания.
Очень важно, чтобы в ходе отслеживания и проверки были тщательно задокументированы
следующие данные:



требования безопасности и конфиденциальности для организации (например, отсутствие
известных критических уязвимостей на момент выпуска);
функциональные и технические требования для разрабатываемого приложения;
рабочий контекст приложения.
Например, если группа разработчиков создает приложение управления процессами для работы в
потенциально опасной среде, необходимо выделить время и ресурсы для создания и обслуживания
процедуры отслеживания, что позволит субъектам безопасности и конфиденциальности
организации, высшему руководству и соответствующим третьим сторонам (таким, как аудиторы
соответствия или специалисты по оценке) выполнять объективный анализ. Иначе говоря, попытка
сэкономить на процессе отслеживания неизбежно приведет к появлению проблем в будущем,
обычно в аварийной ситуации. Необходимо создать надежные системы, которые помогут ответить
на важные вопросы в критический момент.
Общие сведения о реализации процесса Microsoft SDL
17
Заключение
Целью этой статьи является предоставление простой базы, позволяющей на практике включить
в процесс разработки ПО действия по обеспечению безопасности. В статье описан ряд отдельных,
не защищенных авторским правом действий по обеспечению безопасности при разработке,
которые в сочетании с эффективной автоматизацией процесса и четким руководством по
политикам образуют шаги, позволяющие организации действительно добиться соответствия
процессу Microsoft SDL (согласно расширенному уровню модели оптимизации SDL).
Хотя описанный выше процесс предполагает минимальный порог соответствия SDL, процесс SDL не
является чем-то неизменным. Группы разработчиков должны принять этот документ за основу при
реализации SDL в соответствии со временем и ресурсами, которыми располагает организация,
и принятыми в ней нормами деловой практики.
Упомянутые в статье технические принципы обычно рассматриваются как признанные
рекомендации по обеспечению безопасности, и не только по отношению к продуктам Майкрософт
или платформе Windows. Их можно применять к различным операционным системам, аппаратным
платформам и методологиям разработки. Даже если использовать не весь комплекс мер, а только
некоторые из предложенных технологий, это, вероятно, может оказать положительное влияние на
безопасность и конфиденциальность разрабатываемого приложения.
Можно было бы возразить, что даже простое сочетание процедур по обеспечению безопасности
может привести к глобальному повышению безопасности и конфиденциальности, превышающему
эффект от отдельных задач. Однако угрозы безопасности в современной компьютерной среде,
которые когда-то исходили от неопытных злоумышленников, совершавших финансовые
преступления, чтобы потешить свое эго, теперь превратились в оружие в войнах национального
масштаба. Такая эволюция угроз безопасности является серьезным аргументом в пользу
чего-нибудь более существенного, чем обычный «кусочный» подход к обеспечению безопасности
приложений.
Microsoft
SDL
—
это
доступный
процесс,
позволяющий
повысить
безопасность
и конфиденциальность программного обеспечения. Он применялся к сотням программ и к сотням
миллионов строк рабочего кода. Процесс SDL состоит из обязательных действий, которые
соответствуют стандартному процессу разработки ПО, и при этом он достаточно гибок и дает
возможность добавлять другие политики и технологии, что позволяет создать методологию
разработки приложений, уникальную для каждой организации. Сочетание процесса, обучения
и инструментов создает ощутимые преимущества, такие как возросшая предсказуемость,
технические знания и более защищенное программное обеспечение, которое позволяет добиться
снижения рисков как для организации, так и для пользователей.
Общие сведения о реализации процесса Microsoft SDL
18
Приложение A. Схема процесса SDL
Обучение
Обучение мерам
безопасности
проводилось?
Нет
Полное базовое
обучение
Требования
Требования
безопасн./
конфиденц.?
Выполнение всех
подзадач
Нет
Проектирование
Требования
проектирования?
Да
Да
Нет
Назначение
советников и
руководителей
групп
Безопасность
Мин.
требования?
Нет
Определение
минимальных
критериев
безопасности
Нет
Выбор средства
отслеживания
ошибок в рабочих
элементах
Нет
Выбор
компиляторов,
средств, флагов и
параметров
Небезопасные
API?
Консультация с
советниками для
проверки
Статический
анализ
Нет
Нет
Отказ от
небезопасных
функций и API
Задание
контрольных
условий качества
и панелей ошибок
Да
Возможные
направления
для
злоумышленных
атак
Динамический
анализ?
Нет
Проведение
тестов проверки
во время
выполнения
Нечеткие тесты?
Нет
Периодическое
выполнение
статического
анализа кода
Консультация с
советниками для
проверки
Анализ моделей
рисков и уменьшения
количества возможных
направлений для
злоумышленных
атак?
Нет
Нечеткое
тестирование всех
программных
интерфейсов
План
реагирования?
Нет
Документирование
процедур
реагирования при
аварии
Реагирование
КОНЕЦ
Нечеткие тесты?
Нет
Проверка всех
действий по
обеспечению
безопасности и
конфиденциальност
и
Нет
Архивация всех
соотв. технических
данных
Да
Нет
Сверка моделей
с готовым кодом
проекта
Архив выпуска?
Да
Да
Тесты на
проникновение?
(дополнительно)
Выпуск
Да
Да
Нет
Тестирование путем
выполнения атак
для критических
компонентов
Да
Да
Нет
Проверка
Да
Да
Шифрование
Да
Оценка риска?
Консультация с
советниками для
проверки
Да
Отслеживание
ошибок?
Нет
Да
Конфиденциаль
ность
Да
Контрольные
условия качества
Нет
Да
Да
Динамический
анализ
Да
Да
Эксперты
определены?
Да
Выполнение всех
подзадач
Нет
Реализация
Нет
Многоуровневая
защита и
минимальные
права
Нет
Оценка рисков с
помощью STRIDE
Да
Нет
Определение
риска с помощью
оценки угроз
безопасности и
конфиденциальн
ости
Модели рисков?
Да
Общие сведения о реализации процесса Microsoft SDL
19