Перевод тематической статьи

Методология разработки безопасного програмного обеспечения

Eduardo B. Fernandez
Перевод: Угниченко Д.А.

1. Введение

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

• 1) Исследовать конечный промышленный код и попытаться найти возможные проблемы, например, условия, при которых возможным является переполнение буфера. [13].
• 2) Планировать безопасность с самого начала процесса разработки.

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

 Мы представляем здесь методологию построения безопасного программного обеспечения. Этот подход использует основные принципы безопасности и объектно-ориентированной разработки. Мы рассматриваем объектно-ориентированное проектирование, Унифицированный язык моделирования (UML), и шаблоны [1,12] как основное средство создания хорошо спроектированного программного обеспечения. UML - применяется для того, чтобы визуально моделировать объектно-ориентированные системы и является на сегодняшний день одним из наиболее распространенных стандартов для разработки программного обеспечения. Другая важная особенность в разработке программного обеспечении - понятие шаблона. Шаблон воплощает знание и опыт разработчиков программного обеспечения и может быть многократно использован в новых приложениях. Шаблон решает конкретную проблему в данном контексте и может быть приспособлен, чтобы соответствовать различным ситуациям. Шаблоны анализа могут использоваться, чтобы встроить концептуальные модели [5], и шаблоны безопасности могут использоваться, чтобы встроить безопасные системы [8]. Шаблоны могут воплотить классические хорошие принципы безопасности [18].

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

2. Разработка безопасного программного обеспечения

Как обозначено ранее, способ, которым программное обеспечение разработано (программный процесс) и определенная используемая методология, очень важны, чтобы разработать безопасные системы. Прежде всего, важна методология разработки. D [16] и [17] подчеркивается значение сокрытия информации и инкапсуляции. Это указывает на то, что объектно-ориентированный подход должен быть более предпочтительным по отношению к процедурному подходу. Как мы увидим в дальнейшем, есть другие преимущества объектно-ориентированной методологии, которые важны для безопасности. Основная идея в предложенной методологии - то, что принципы безопасности должны быть применены в каждой стадии разработки и что каждая стадия может быть проверена на согласие с этими принципами. Сначала мы создадим краткий скелет описания безопасного цикла разработки программного обеспечения, который мы считаем необходимым, чтобы построить безопасные системы, и затем мы обсудим каждую стадию более подробно. Иллюстрация 1 показывает жизненный цикл безопасного программного обеспечения, указывая, где принципы безопасности могут быть применены и где мы можем сделать их последующую ревизию для согласия с политикой безопасности.
Рисунок 1. Жизненный цикл ПО.

• Этап анализа:
  Аналитические шаблоны могут быть использованы для построения концептуальной модели более эффективным и надежным способом. [5] Мы можем построить абстрактную модель, в которой повторяемые приложения шаблона Авторизации (см. ниже) воплощают права, определенные в способах использования. Фактически, шаблоны анализа могут быть построены с предопределенными правами авторизации в соответствии с их ролями. Это делает задачу определения и распределения ролей еще легче.
• Этап проектирования:
  Интерфейсы пользователя должны соответствовать способам их использования. Интерфейсы могут быть сделаны безопасными путём их разработки на базе шаблонов Авторизации. Безопасные интерфейсы принуждают к использованию авторизации в тот момент, когда пользователи взаимодействуют с системой. И, наконец, компоненты могут быть сделаны безопасными путём использования правил JAAS, определенных в соответствии с правилами авторизации для JAVA компонент или путем использования .NET авторизаций для компонент .NET. Диаграммы развертывания систем могут определить безопасные способы конфигурации, которые должны быть использованы администраторами безопасности. Разноуровневая архитектура необходима на данном этапе для обеспечения ограничений по безопасности, объявленных на уровне безопасности [4]. На каждом уровне мы используем шаблоны для демонстрации соответствующих механизмов безопасности.
• Этап реализации:
  На данном этапе требуется отображение в коде правил безопасности, определенных для конкретного приложения. Т.к. эти правила выражены классами, ассоциациями и ограничениями, они также могут быть реализованы как дополнительные классы. Нам также необходимо выбрать специфические пакеты безопасности, например, сетевой фильтр или приложение, реализующее криптографические функции.

 В конце каждой стадии мы можем выполнить ревизии, чтобы проверить, что выполняется установленная политика безопасности. В случае необходимости, ограничения безопасности могут быть сделаны более точными при использовании (Объектный Язык Ограничения)(OCL) вместо ограничений, записанных в текстовом виде. Шаблоны для моделей защиты определяют самый высокий уровень. На каждом более низком уровне мы применяем шаблоны к определенным механизмам, которые проводят в жизнь эти модели. Таким образом, мы можем определить шаблоны для файловых систем, для документов сети, для компонентов J2EE, и т.д. Мы можем также оценить степень защищенности новой или существующей системы, используя шаблоны. Шаблоны помогают понять структуру безопасности каждого компонента, что позволяет осуществить дальнейшее оформление закономерностей и определить безопасные интерфейсы. Если система не содержит соответствующий шаблон тогда, она не может поддержать соответствующую безопасную модель или механизм. Мы можем объединить различные типы шаблонов, чтобы получить различные функциональные возможности и качество. Например, [14] объединяет RBAC, фильтр, и шаблоны подключения (последние два - шаблоны для распределенных систем). Мы проанализируем эти стадии подробно в следующем разделе.

3. Подробности некоторых стадий

3.1 Архитектурные уровни

 Опыт показал, что хороший способ построения надежных систем состоит в том, чтобы структурировать их в ряд иерархических уровней. Уровни абстракции проводят в жизнь нисходящие единственные функциональные зависимости. Модуль A, как говорят, зависит от B всякий раз, когда действие B, или изменение к B, или полная неработоспособность B, может затронуть А [15].

 Некоторые важные проблемы для иерархий: какие функции включать в каждый уровень и сколько безопасности мы должны достигнуть в каждом уровне намеченного уровня безопасности для целой системы. Не все уровни должны быть одинаково безопасными, более низкие уровни более важны и нуждаются в более сильной защите. Безопасность и другие нефункциональные требования затрагивают все архитектурные уровни системы. Уровневой архитектурный шаблон [1] является, поэтому хорошей отправной точкой, дабы применить эти требования. Используя уровни, мы можем определить шаблоны на всех уровнях, которые вместе осуществляют безопасную или надежную систему. Основная идея шаблона Уровней - декомпозиция системы в иерархические уровни абстракции, где более высокие уровни используют службы более низких уровней. Мы обсудили ранее, почему все эти уровни должны быть координированы, чтобы обеспечить безопасность [4] и выразить то, как определение нефункциональных спецификаций должно быть сделано на определенном уровне [2].

 Концептуальные модели предприятия, и статические и динамичные, определены на прикладном уровне. Именно здесь должна быть применены политики безопасности (и другие типы). На этом уровне хорошо понята семантика приложения, и роли могут использоваться, чтобы применить политику необходимости; то есть, мы можем определить необходимые права согласно функциям каждой роли [3]. Другие нефункциональные аспекты также определены здесь, например, необходимая степень надежности. Более низкие уровни проводят в жизнь ограничения, определенные в более высоких уровнях. Каждый уровень имеет свой собственный механизм безопасности и должен участвовать в предписании ограничений безопасности. Например, система управления базой данных реализует функцию разрешений в приложении, ограничивая доступ к элементам базы данных; это ограничение размножено вниз, чтобы управлять доступом к файлам, где эти данные постоянно находятся.

3.2 Случаи использования и возможные атаки

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

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

3.3 Санкционированные приложения

 Мы используем матрицу права доступа и RBAC как модели справочной информации. Многоуровневые модели также возможны, но когда они используется на прикладном уровне то являются слишком сложными; однако, они полезны на более низких уровнях. Когда мы применяем модель матрицы права доступа, следующий шаг должен определить шаблоны, которые представляют правила разрешения или политику, как показано в иллюстрации 3 [6]. Эта модель описывает вход матрицы права доступа, (s, o, t, p, f), где s - тема, o - объект защиты, t тип доступа, p предикат, сдерживающий приложение правила, и f флажок копии, указывая, может ли право быть передано [17]. Классы иллюстрации 3 - абстрактные классы, и определенные модели разрешения определены реальными классами. Концептуальные или специфические (конкретные для конкретной системы) модели могут быть построены, с использованием шаблоны анализа [5], и мы разработали коллекцию этих шаблонов для аспектов, таких как материальные запасы, обработка заказов, и другие. Эти шаблоны безопасности могут быть применены к шаблонам анализа, чтобы определить семантические подсистемы, которые комбинируют преимущества шаблонов с преимуществами определения разрешения высокого уровня. В этом случае, у пользователя шаблона была бы структура, дающая возможность определить права, которые требует его приложение. Например, в [8] мы показали шаблон анализа для безопасной системы учетной записи. В той модели аудитор уполномочен проверить несоответствия в заготовке, в то время как готовый содержатель уполномочен исправить или корректировать эти несоответствия. Точно так же готовый менеджер может добавить новые склады, и т.д. Определенные права для каждой роли исходят из случаев использования и получены как в [3]. У каждого случая использования есть ряд агентов, кто взаимодействует с системой. Если агентам дают права согласно их функциям, то в случаях использования системы, мы осуществляем политику необходимости. Начинаясь с шаблонов на прикладном уровне мы должны определить шаблоны для более низких уровней. Например, мы разработали шаблоны для операционных систем [7, 9], системы сетевой защиты [10], и другие механизмы безопасности. Для систем, которые используют веб-службы, мы разработали шаблоны безопасности для прикладных систем сетевой защиты и координации утверждения [11].

3.4 Обеспечьте системную архитектуру

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

Рисунок 2. Системная архитектура с использованием безопасных механизмов.

4. Заключения

 Комбинация многослойной архитектуры с шаблонами служит основой, чтобы разработать систематический подход многократного использования для создания систем, которые удовлетворяют определенным нефункциональным требованиям. Шаблоны безопасности воплощают хорошие принципы дизайна и при использовании них, проектировщик неявно применяет эти принципы. Необходимо провести работу, чтобы добавить больше шаблонов в каждом уровне и собрать и объединить эти шаблоны. Мы работаем теперь в каталоге шаблонов безопасности [19]. Мы также должны определить рекомендации, чтобы применить методологию более точно на каждом уровне. Наконец, мы должны оценить эту методологию в реальной среде; пока мы применяем это к определенным примерам, таким как распространенные медицинские отчеты, интернет-голосование, и распространяли финансовые учреждения.

5. Ссылки

• [1] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland, and M. Stal., Patternoriented software architecture, Wiley 1996.
• [2 ] E. B. Fernandez and R. B. France, ``Formal specification of real-time dependable systems", Proc. of First IEEE Int. Conf. on Eng. of Complex Comp. Systems, Fort Lauderdale, FL, November 6-10, 1995, 342-348.
• [3] E.B.Fernandez and J.C.Hawkins, “Determining role rights from use cases”, Procs. 2nd ACM Workshop on Role-Based Access Control, November 1997, 121-125.
• [4] E.B.Fernandez, "Coordination of security levels for Internet architectures", Procs. 10th Intl. Workshop on Database and Expert Systems Applications, 1999, 837-841.
• [5] E.B. Fernandez and X. Yuan, “Semantic analysis patterns”, Procs. of 19th Int. Conf. on Conceptual Modeling, ER2000, 183-195
• [6] E B. Fernandez and R.Y. Pan, “A pattern language for security models”, Procs. of PLoP 2001, http://jerry.cs.uiuc.edu/~plop/plop2001/accepted_submissions/accepted-papers.html
• [7] E.B.Fernandez, "Patterns for operating systems access control", Procs. of PLoP 2002.
• [8] E.B.Fernandez, “Layers and non-functional patterns”, Procs of ChiliPLoP, 2003. Phoenix, March 10-15, 2003.
• [9] E.B.Fernandez and J.C.Sinibaldi, "More patterns for operating systems access control", Procs. EuroPLoP 2003.
• [10] E. B. Fernandez, M. M. Larrondo-Petrie, N. Seliya, N. Delessy, and A. Herzberg, "A Pattern Language for Firewalls ", Procs. of PLoP 2003.
• [11] E.B. Fernandez, "Two patterns for web services security", to appear in Procs. of the International Symposium on Web Services and Applications, Las Vegas, NV, June 2004.
• [12] E. Gamma, R. Helm,R. Johnson, and J. Vlissides, Design patterns –Elements of reusable object-oriented software, Addison-Wesley 1995.
• [13] M. Howard and D. LeBlanc, Writing secure code, (2nd Ed.), Microsoft Press, 2003.
• [14] V. Hays, M. Loutrel, and E.B.Fernandez, “The Object Filter and Access Control framework”, Procs. Pattern Languages of Programs (PLoP2000) Conference.
• [15] P.G.Neumann, “On hierarchical design of computer systems for critical applications”, IEEE Trans. on Software Eng., vol. SE-12, No 9, September 1986, 905-920.
• [16] P.G.Neumann, “The role of software engineering”, Comm. of the ACM, Vol. 36, No 5, May 1993, 114.
• [17] C.P.Pfleeger, Security in computing, 3rd. Ed., Prentice-Hall, 2003.
• [18] J.H.Saltzer and M.D.Schroeder, “The protection of information in computer systems”, Procs. of the IEEE, Vol. 63, No 9, 1975, 1278-1308.
• [19] M. Schumacher, E.B.Fernandez, D. Hybertson, and F. Buschmann, Security Patterns, to be published by J. Wiley & Sons, 2004.