ПОСТРОЕНИЕ КОМПЛЕКСНОЙ многоуровневой защиты ИНФОРМАЦИОННО-ПРОГРАМНОГО ОБЕСПЕЧЕНИЯ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ |
24-02-2024 |
Security test cases Рис. 1. Жизненный цикл безопасного программного обеспечения
Стадия проекта (эскиз). Рассматриваются некоторые возможные нападения на систему. Механизмы проекта отобраны, Чтобы остановить Эти нападения. Пользовательские интерфейсы Должны соответствовать случаям использования и могут использоваться, Чтобы предписать разрешения, определенные в стадии анализа. Безопасные интерфейсы предписывают разрешения, когда пользователи взаимодействуют с системой. Компоненты могут быть защищены, Используя правила разрешения для Java или. NET компонентов. Распределение обеспечивает другое измерение, где ограничения безопасности могут быть применены. Диаграммы развертывания могут определить безопасные конфигурации, Которые используются администратором безопасности. Многослойная архитектура необходима, Чтобы предписать ограничения безопасности, определенные на прикладном уровне. В каждом уровне мы используем образцы, Чтобы представит Соответствующие механизмы безопасности. Ограничения безопасности Должны быть нанесеные на карту между уровнями.
Стадия выполнения. Эта стадия требует отражения в коде правил безопасности, определенные в стадии проекта (эскиза). Поскольку Эти правила выражены как классы, ассоциации и ограничения, они могут быть осуществлены как классы в объектноориентированных языках. В Этой стадии мы можем также выбрать определенные Секретные пакеты, например, брандмауэр, шифровальный пакет.
Развертывание и стадия обслуживания. Наша методология Еще не обращается к проблемам в ЭТИХ стадиях. Когда программное обеспечение находится в использовании, другие проблемы безопасности могут быть обнаружены пользователями. Эти проблемы могут быть решены внесения исправлений, хотя количество внесенных исправлений после применения нашего подхода должно быть значительно меньшим по сравнения с текущими системами.
Описание стадии требований
Важный аспект требований безопасности систематическое и точное внесение в список возможных нападений к системе. С этим внесение в список мы можем решить, какие определенные механизмы защиты использовать. Было несколько попыток рассмотреть атаки для определения требований к безопасности системы. В нашем подходе мы рассматриваем каждое действие в каждом случае использования и смотрим, как это может быть разрушено внутренним или внешним нападавших. Вот этого списка мы можем вы 11
Информационная безопасность, № 1 (1), 2009
вести, какая политика необходима для предотвращения или смягчения атак. Учет и анализ нападений обеспечивает систематический и Относительно полный список возможных нападений. Каждое идентифицированное нападение может быть проанализирован, Чтобы видеть, как это может быть достигнуто в определенной окружающей среде. Список может тогда использоваться, Чтобы вести проект и выбирать механизмы безопасности. Это может также использоваться для того, Чтобы оценить заключительный проект, Анализируя, может ли защищенность системы остановить все Эти нападения. Как мы указали ранее, так как случаи использования определяют все взаимодействия с системой, мы можем найти права, необходимые для ЭТИХ ролей, для реализации возложенных функций.
