Microsoft Office System 2007

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

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

Общий подход к учету требований безопасности

Определение целей и задач, связанных с обеспечением безопасности

   Ролевая матрица

   Использование функциональных требований

Руководство по обеспечению безопасности

   Шаблон практических действий

Изменения в современном мире, в немалой степени связанные с проникновением информационных технологий во все сферы жизнедеятельности человека, требуют по-новому взглянуть на вопросы обеспечения безопасности при разработке программных продуктов. Это прежде всего касается приложений, автоматизирующих деятельность предприятий, обрабатывающих конфиденциальные бизнес-данные, взаимодействующих с другими компонентами систем автоматизации, пересылающих данные через Интернет и т.п. Несмотря на то что в большинстве случаев нарушения систем безопасности, утечки информации и нанесения вреда деятельности компаний ключевым остается человеческий фактор, полноценный учет всех требований безопасности и выполнение этих требований в процессе разработки программных продуктов могут существенно снизить вероятность взлома систем безопасности.
Наш обзор, посвященный учету требований безопасности при разработке программных продуктов, мы начнем с простого утверждения: учет требований безопасности не может быть реализован после написания кода приложения — нормой должно стать обеспечение безопасности во всех фазах цикла разработки программного обеспечения. Меры, связанные с удовлетворением требований безопасности, могут включать определение целей и задач, связанных с обеспечением безопасности, применение принципов написания безопасных приложений, выполнение анализа архитектуры и дизайна на соответствие требованиям безопасности, аудит кода, тестирование на соответствие требованиям, безопасное развертывание и т.п. Перечисленные выше меры являются интегральной частью методологии Microsoft Solutions Framework (MSF) Agile, которая поддерживается в Microsoft Visual Studio Team System.
В статье мы рассмотрим назначение основных действий, связанных с обеспечением создания безопасных приложений, а также способы включения этих действий в соответствующие этапы разработки программных продуктов: создание концепции приложения, разработка архитектуры и дизайна, написание кода, тестирование и развертывание приложения.

Общий подход к учету требований безопасности

Начнем с того, что перечислим основные шаги и рекомендованные подходы к учету требований безопасности при разработке программных продуктов:

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

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

Таблица 1. Действия, связанные с обеспечением безопасности создаваемых приложений

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

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

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

Действия, связанные с безопасностью, в общем цикле разработки приложения

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

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

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

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

1. Определение целей и задач, связанных с обеспечением безопасности. Если они не определены, то будет трудно получить положительные результаты от выполнения других действий.
2. Аудит архитектуры и дизайна на соответствие требованиям безопасности. Ошибки, допущенные на этапе дизайна, наиболее трудоемки для устранения. Выполнив на ранних стадиях аудит архитектуры и дизайна на соответствие требованиям безопасности, можно избежать дорогостоящих переделок на более поздних этапах создания приложения.
3. Моделирование угроз. Использование механизма моделирования угроз позволит не только сфокусироваться на решении конкретных задач, связанных с устранением угроз, но и улучшит качество всего программного продукта, а также позволит скорректировать планы тестирования — включить в них тесты на обнаружение конкретных атак и реакций на них.
4. Аудит кода на соответствие требованиям безопасности. Как мы уже отмечали, ошибки, допущенные на стадии дизайна, наиболее трудоемки для устранения. В то же время наиболее частыми являются ошибки, появившиеся на этапе разработки. Проведение аудита кода на соответствие требованиям безопасности поможет сократить время, необходимое для тестирования и обнаружения несоответствий на более поздних этапах проекта.
5. Аудит процесса развертывания на соответствие требованиям безопасности. Любые усилия по обеспечению безопасности приложения могут быть сведены на нет неверными настройками и опциями конфигурации.
6. Руководство по обеспечению безопасности. Использование проверенных практик и принципов дизайна приложения даст уверенность в том, что создаваемое приложение безопасно, начиная с самых ранних стадий его разработки.
7. Тестирование на соответствие требованиям безопасности. Необходимость в тестировании приложений вряд ли подлежит сомнению — тестирование на соответствие требованиям безопасности поможет убедиться в том, что действия, выполненные на предыдущих этапах проекта, привели к желаемым результатам.

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

Определение целей и задач, связанных с обеспечением безопасности

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

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

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

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

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

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

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

Таблица 2. Категории обобщенных требований по обеспечению безопасности

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

Ролевая матрица

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

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

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

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

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

• обладатели ролей могут использовать только выданные им привилегии;
• изменение привилегий доступно обладателям только той роли, у которой есть функция «изменение привилегии».

Использование функциональных требований

Набор требований по обеспечению безопасности можно получить в результате детального изучения списка функциональных требований для создаваемой системы. Каждое требование должно рассматриваться через призму конфиденциальности, целостности и доступности — так называемый принцип CIA (Confidentiality, Integrity, Availability). Такой подход обеспечивает очень эффективный механизм для создания списка по обеспечению безопасности, основанного на известных характеристиках системы.

Рассмотрим следующий пример, в котором приведен краткий список требований к системе:

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

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

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

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

Таблица 4. Пример требований по обеспечению безопасности на основе выявленных уязвимостей

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

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

Руководство по обеспечению безопасности

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

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

• выполняемые действия (actionable) — рекомендация должна ассоциироваться с определенной уязвимостью, которая может быть устранена с помощью данной рекомендации;
• существенную уязвимость (relevant) — рекомендация должна ассоциироваться с уязвимостью, которая может повредить разрабатываемому приложению;
• инженерное решение (impactful) — приводимые в рекомендации решения должны обладать воздействием на всю систему.

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

Шаблон практических действий

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

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

Таблица 5. Классы уязвимостей, наиболее часто встречающихся в приложениях

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

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

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

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

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

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

Таблица 6. Основные рекомендации по обеспечению безопасности

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

***

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

КомпьютерПресс 11'2006