Учет требований безопасности при разработке программных продуктов

Часть 2

Алексей Федоров

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

Ключевые концепции модели угроз

Проверка архитектуры и дизайна на соответствие требованиям безопасности

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

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

Дополнительные ресурсы

В предыдущей части данного обзора, посвященного учету требований безопасности при разработке программных продуктов, мы обсудили общий подход к учету требований безопасности, определение целей и задач, связанных с обеспечением безопасности, а также шаблон практических действий по обеспечению безопасности, учитывающий различные классы уязвимостей. Во второй части материала мы продолжим обсуждение данной темы и коснемся вопросов моделирования угроз, аудита архитектуры и кода приложения, а также аудита процесса развертывания приложения на соответствие требованиям безопасности.

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

Моделирование угроз помогает понять и идентифицировать наиболее вероятные угрозы и уязвимости, специфичные для конкретного приложения или конкретного сценария использования приложения. Применение моделей угроз помогает идентифицировать:

• требования по обеспечению безопасности;
• возможные угрозы;
• возможные уязвимости и способы их предотвращения.

Моделирование угроз выполняется для идентификации того, когда и где для снижения рисков может потребоваться большее число ресурсов. Существует множество уязвимостей, угроз, атак, и вероятность того, что создаваемое приложение столкнется одновременно со всеми, очень низка. Также маловероятно, что компании потребуется решение всех потенциальных проблем, связанных с безопасностью. Моделирование угроз является инструментом, который позволяет определить, где именно необходимо сосредоточить усилия.

Моделирование угроз начинается на фазе создания архитектуры и дизайна приложения. Перед созданием модели угроз необходимо однозначно сформулировать требования по безопасности приложения. По мере продвижения от фазы создания архитектуры и дизайна приложения к фазе разработки в модель угроз добавляются выявленные в процессе работы над проектом новые угрозы — то есть моделирование угроз является итеративным процессом, который необходимо периодически повторять. При повторах следует обращать внимание на детализацию модели угроз по мере того, как становится доступной информация о среде, в которой будет выполняться приложение; в процессе разработки модель угроз должна пополняться фактами, выявленными при дизайне и разработке приложения; а также по мере появления информации о новых сценариях использования приложения и его новых конфигурациях.

Моделирование угроз состоит из пяти основных шагов (рис. 1). Обновление и улучшение модели достигается за счет итеративного повторения шагов с 2-го по 5-й. Детали добавляются по мере продвижения в цикле разработки программного продукта и более внимательного рассмотрения дизайна приложения (см. рис. 1).

Рис. 1. Итеративный процесс моделирования угроз

Пять основных шагов, выполняемых при моделировании угроз, приведены в табл. 1.

Таблица 1. Шаги, выполняемые при моделировании угроз

По мере итеративной работы над моделью угроз следует также учитывать требования по обеспечению основной функциональности приложения, а также требования по его производительности и доступности. Таким образом можно добиться баланса во всех аспектах создаваемого программного продукта.

В табл. 2 показана входная и выходная информация для каждого шага моделирования угроз.

Таблица 2. Входная и выходная информация для каждого шага моделирования угроз

Ключевые концепции модели угроз

Процесс моделирования угроз оптимизирован для оказания помощи в идентификации уязвимостей в создаваемых приложениях. В табл. 3 собраны ключевые концепции и рекомендации, основанные на опыте выполнения проектов различной сложности.

Таблица 3. Входная и выходная информация для каждого шага моделирования угроз

Моделирование угроз — это структурированная деятельность для идентификации угроз и уязвимостей разрабатываемых программных продуктов. Создание модели угроз должно начинаться на этапе создания архитектуры и дизайна приложения, при этом изначальная модель должна постоянно обновляться и улучшаться по мере того, как появляется информация о дизайне и способах реализации приложения.

Проверка архитектуры и дизайна на соответствие требованиям безопасности

Проверка архитектуры и дизайна приложения позволит проанализировать их на соответствие требованиям безопасности. В такой анализ должно включаться рассмотрение вопросов, связанных с развертыванием, инфраструктурой, общей архитектурой приложения, его дизайном, а также архитектурой и дизайном каждого физического и логического звена приложения.

Существует три основных аспекта при проверке архитектуры и дизайна приложения на соответствие требованиям безопасности:

• рассмотрение архитектуры приложения должно происходить в соответствии с инфраструктурой и сценариями развертывания;
• рассмотрение дизайна приложения должно происходить в соответствии со всеми категориями уязвимостей, определенных на предыдущих фазах работы над проектом;
• позвенный компонентный анализ приложения должен включать рассмотрение механизмов обеспечения безопасности в каждом из ключевых компонентов системы, включая слой представления, слой бизнес-логики и слой доступа к данным.

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

• развертывание и инфраструктура — проанализируйте дизайн приложения с точки зрения среды, в которой оно будет развернуто. Изучите соответствующие требования по поддержке стандартов. Рассмотрите ограничения, налагаемые инфраструктурой и уже существующими механизмами обеспечения безопасности;
• шаблоны обеспечения безопасности — детально проанализируйте различные критичные компоненты приложения, включая механизмы аутентификации, авторизации, проверки вводимых данных, управления исключениями и т.п. Используйте классы уязвимостей в качестве руководства по анализу ключевых компонентов приложения;
• позвенный анализ — детально проанализируйте все звенья и уровни приложения, изучите способы реализации механизмов безопасности для слоя представления, слоя бизнес-логики и слоя доступа к данным.

На рис. 2 показаны три основных аспекта проверки архитектуры и дизайна приложения.

Рис. 2. Три основных аспекта проверки архитектуры и дизайна приложения

Для выполнения проверки архитектуры и дизайна приложения рекомендуется использовать заранее подготовленные списки проверяемых критериев. Примеры таких списков приводятся в табл. 4 и 5. На основе стандартных списков вы можете создавать собственные, в которых будут отражаться проверяемые критерии, специфичные и уникальные для разрабатываемого приложения.

Таблица 4. Пример критериев для развертывания и инфраструктуры

При качественном выполнении анализа архитектуры и дизайна приложения на соответствующих стадиях проекта появляется возможность снижения рисков, связанных с угрозами и уязвимостями. Устранение уязвимостей на ранних стадиях проекта менее затратно по сравнению с исправлением ошибок на более поздних этапах.

Таблица 5. Пример критериев для анализа архитектуры и дизайна
приложения и проверки ввода

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

Весь код приложения должен быть подвергнут проверке с целью обнаружения возможных уязвимостей. Данная деятельность должна итерационно выполняться на фазах разработки и тестирования программного продукта.

Корректно проведенный анализ кода, как никакая другая деятельность, сможет сделать код приложения максимально безопасным. Множество ошибок может быть устранено именно на этапе проверки — прежде, чем код попадет к команде тестировщиков. Помимо этого результаты проверки кода могут послужить отличным механизмом для передачи знаний всем членам проектной команды.

Чтобы проведение анализа кода было эффективным, необходимо определить, что представляет собой плохой код и что является результатом проверки. Для управления процессом проверки можно руководствоваться требованиями по обеспечению безопасности для разрабатываемого программного продукта. В зависимости от этих требований должны быть отранжированы выявленные уязвимости и потенциальные угрозы. Для более предметного анализа кода следует использовать созданные ранее модели угроз. Анализ кода на предмет установления подверженности определенным угрозам поможет обнаружить гораздо больше ошибок, чем любой общий анализ.

Анализ кода состоит из четырех шагов, показанных на рис. 3, а их суть описана ниже:

1. Определение целей анализа кода на предмет безопасности. На этом шаге определяются цели и ограничения для анализа кода.
2. Выполнение первичного анализа. Используйте первичный статический анализ для обнаружения начального набора ошибок и выявления того, где вероятнее всего будут обнаружены ошибки на следующих итерациях.
3. Поиск проблем, связанных с безопасностью. На этом шаге выполняется более тщательная проверка кода для обнаружения уязвимостей в системе безопасности, которые чаще всего встречаются в приложениях. Рекомендуется использовать результаты, полученные на шаге 2.
4. Поиск проблем, связанных с безопасностью, уникальных для архитектуры данного приложения. Окончательный анализ должен быть посвящен поиску ошибок, характерных для архитектуры данного приложения. Этот шаг наиболее важен в тех случаях, когда используются собственные механизмы обеспечения безопасности или механизмы снижения рисков, связанных с безопасностью (рис. 3).

Рис. 3. Шаги, выполняемые при анализе кода

В табл. 6 приведена входная и выходная информация для каждого шага деятельности, связанной с анализом кода.

Таблица 6. Входная и выходная информация для каждого шага деятельности,
связанной с анализом кода

При анализе кода необходимо придерживаться следующих рекомендаций для достижения наиболее эффективных результатов:

• анализ блоков кода — это механизм, используемый для пошаговой проверки логических условий в коде. На первом шаге анализа идентифицируются блоки, содержащие циклы, конструкции switch, if, try/catch. На втором шаге выясняются условия, при которых выполняется каждый программный блок. На третьем шаге анализируется следующий блок кода;
• анализ потоков данных — это механизм, используемый для трассировки данных от точки ввода до точки вывода. Так как в приложении может быть множество потоков данных, используйте список целей анализа кода и список областей кода для детального анализа, составленные на шаге 2. Процесс анализа выглядит следующим образом:

- для каждой точки ввода определите уровень доверия к источнику данных;

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

- перейдите к следующей точке входа.

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

Каждый список вопросов организован вокруг наиболее характерных ошибок, приводящих к появлению уязвимостей на уровне всего приложения. В табл. 7 приведены примеры проблемных областей.

Таблица 7. Примеры проблемных областей

При анализе кода можно использовать как индивидуальные, так и групповые проверки. В первом случае подразумевается, что только один из членов проектной группы выполнит анализ всего кода. Во втором случае, который является очень эффективным, анализ кода проводят несколько членов проектной группы. Для первого анализа можно выбрать человека, незнакомого с исходным кодом, — в этом случае мы получим свежий взгляд на возможные проблемы. Однако анализ, проводимый специалистом, знакомым с кодом, поможет обнаружить более мелкие ошибки.

В любом случае при анализе кода необходимо выполнить ряд шагов:

• ознакомить всех участников анализа с задачей;
• дать общее представление о структуре кода, модулях и т.п.;
• выполнить анализ кода;
• составить подробное описание найденных ошибок и уязвимостей.

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

• бизнес-аналитик — описывает задачи, решаемые приложением, и задачи, связанные с обеспечением безопасности; при анализе кода отвечает за представление задач с точки зрения бизнеса;
• архитектор — описывает назначение приложения и его архитектуру; обычно отвечает за представление задач с точки зрения системной архитектуры;
• разработчик — описывает детали реализации, структуру приложения; выполняет анализ кода, отвечает за обнаружение уязвимостей и ошибок;
• тестировщик — выполняет анализ кода, находит ошибки и уязвимости, заносит найденную информацию в планы тестирования.

Деятельность, связанная с анализом кода, является мощным инструментом для снижения числа ошибок и уязвимостей в разрабатываемом программном продукте. Процесс должен быть итеративным — уроки, полученные на первой итерации, должны стать входной информацией для последующей итерации.

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

После того как приложение развернуто, необходимо убедиться в том, что неверные конфигурационные настройки не повлияют на стабильность и уязвимость приложения.

Безопасность приложения зависит от безопасности инфраструктуры, в которой оно будет развернуто. При анализе процесса развертывания следует обращать внимание на конфигурацию сетевого окружения, а также среды, в которой будет работать программный продукт.

Анализ конфигурации и связанных с этим вопросов должен проводиться по категориям, показанным на рис. 4.

Рис. 4. Категории для анализа процесса развертывания

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

В табл. 8 приведены категории безопасности сервера, которые следует использовать в качестве основы для анализа процесса развертывания.

Таблица 8. Категории безопасности сервера, которые следует использовать
в качестве основы для анализа процесса развертывания

Анализ процесса развертывания позволит убедиться в том, что меры, принятые для обеспечения безопасности приложения, не будут сведены на нет за счет неверной конфигурации инфраструктуры, в которой данное приложение будет выполняться. Систематический анализ на основе приведенных выше категорий поможет вам определить и устранить уязвимости во всех компонентах сервера, предназначенного для выполнения программного продукта.

Дополнительные ресурсы

В данном обзоре мы рассмотрели общие рекомендации по учету требований безопасности при разработке программных продуктов. Ниже приведены ссылки на ресурсы, содержащие более подробную информацию:

• дополнительную информацию по обеспечению требований безопасности при разработке программных продуктов можно получить на сайте Microsoft по адресу: http://msdn.microsoft.com/securityengineering;
• дополнительная информация по моделированию угроз доступна на сайте Microsoft по адресу: http://msdn.microsoft.com/threadmodeling;
• полный набор списков проверяемых критериев доступен на сайте Microsoft по адресу: http://msdn.microsoft.com/library/en-us/dnpag2/html/Security/ChecklistsIndex.asp;
• дополнительная информация по выполнению анализа архитектуры и дизайна приложения доступна на сайте Microsoft по адресу: http://msdn.microsoft.com/library/en-us/dnpag2/html/securityarchanddesign reviewindex.asp;
• дополнительную информацию по проведению анализа кода можно получить на сайте Microsoft по адресу: http://msdn. microsoft. com/library/en-us/dnpag2/html/SecurityCodeReviewIndex.asp;
• дополнительную информацию по проведению анализа процесса развертывания приложения можно получить на сайте Microsoft по адресу: http://msdn.microsoft.com/library/en-us/dnpag2/html/SecurityDeploymentReviewIndex.asp.

КомпьютерПресс 4'2007