ПОСТРОЕНИЕ КОМПЛЕКСНОЙ многоуровневой защиты ИНФОРМАЦИОННО-ПРОГРАМНОГО ОБЕСПЕЧЕНИЯ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ

Защита от несанкционированного использования компьютерных ресурсов (2й уровень защиты):

криптографическое закрытие файлов с секретной информацией;

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

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

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

периодическое глубокое тестирование оборудования компьютера для предупреждения его перебоев и отказов;

диагностирования и устранения логических и физических дефектов дисковой памяти;

восстановление разметки дисков и корневых каталогов при их разрушении;

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

восстановления работоспособности компьютера после возникновения перебоев и отказов или заражения вирусами.

Постановка задания. Существующие руководящие принципы для защиты программного обеспечения на прикладном уровне сосредоточились на обеспечении активной безопасности. Практика создания проектов обычно Использует такую ​​технологию разработки. Как только проект спроектирован, уязвимые ресурсы идентифицируются и защищаются. Затем постепенно вводится разработка безопасности на каждом цикле жизни приложения. Степень защищенности, которой должен соответствовать ресурс, должна базироваться на анализе риска. Анализ рисков может быть далее уточнены при помощи исследований атак. Деревья нападения наносят на карту цели нападавшего к сценариям, Которые ведут к тем целям. Однако они слишком детализированы и не обеспечивают глобальную картину нападений. Другой недостаток использования отдельного нападения и анализа уязвимости состоит в том, что анализ принимает полный проект. Возрастающие и эволюционные изменения в системе сводят на нет результаты более ранних исследований. Чтобы использовать возможности требуемых новых исследований, метод построения защищенном программного обеспечения должен поддерживать достаточно высокую стойкость среды требований, средств, нападений, обороноспособности, подверженности и уязвимости. К безопасности нужно Обратиться во всех действиях, во всех стадиях процесса разработки программного обеспечения и жизненного цикла. Любая уязвимость может стать причиной нарушения безопасности. Исследования показали, что нападения могут быть следствием не только посторонних, но также и от лиц, имеющих высокий уровень доступа. Системы могут быть скомпрометированы или пол непригодным при нападении на любой контрольный пункт, даже несвязанный с обработкой конфиденциальной информации. Пути развития программного обеспечения и определенная специфическая методология очень важны для создания безопасных систем . Важность ЭТИХ принципов и существующих исследований указывает, что объектноориентированный подход является предпочтенее процедурного подхода.

Основная часть. В основу предлагаемой методологии положеные принципы безопасности, Которые Должны быть применены в каждой стадии разработки, и каждая стадия может быть проверена на согласование с темы принципами. Фактически некоторые подходы к объектноориентированному развитию уже подчеркивают испытания на каждой стадии. Набросок цикла разработки безопасного программного обеспечения предложен в работе , однако Уточним описание каждой из стадий этого цикла. Рис.1 показывает цикл жизни безопасного программного обеспечения. Белые стрелки показывают, где безопасность может быть применена и черные стрелки, где мы можем проверить соответствие с политикой безопасности. Вот этапа требований мы генерируем безопасные случаи использования. Вот этапе анализа мы генерируем правила разрешения, Которые применяются к концептуальной модели. Вот этапа Проекта мы предписываем правила через архитектуру. На этапе выполнения, развертывания и обслуживания требуется осуществление языка контрмерам и правил. Обратите внимание, что проверка безопасности и испытание происходят в каждой стадии проектирования и реализации.

Стадия требований. Случаи использования определяют требуемые взаимодействия с системой. Применяя принцип, что безопасность должна начаться с самых высоких уровней, имеет смысл связыва нападения, Чтобы использовать и развивать то, что мы называе безопасными случаями использования (UCs). Мы изучаем каждое действие в пределах случая использования и видим, какие нападения являются возможным. Мы тогда определяем, какая политика остановил бы Эти нападения. Вот случаев использования мы можем также определить Необходимые права для каждого участника и таким образом применить политику «знать только то, что необходимо». Обратите внимание, что набор всех случаев использования определяет все использования системы, и от всех случаев использования мы можем определить все права для каждого участника. Тестирование безопасности для полной системы может также быть определено на Этой стадии.

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

Security test cases Рис. 1. Жизненный цикл безопасного программного обеспечения

Стадия проекта (эскиз). Рассматриваются некоторые возможные нападения на систему. Механизмы проекта отобраны, Чтобы остановить Эти нападения. Пользовательские интерфейсы Должны соответствовать случаям использования и могут использоваться, Чтобы предписать разрешения, определенные в стадии анализа. Безопасные интерфейсы предписывают разрешения, когда пользователи взаимодействуют с системой. Компоненты могут быть защищены, Используя правила разрешения для Java или. NET компонентов. Распределение обеспечивает другое измерение, где ограничения безопасности могут быть применены. Диаграммы развертывания могут определить безопасные конфигурации, Которые используются администратором безопасности. Многослойная архитектура необходима, Чтобы предписать ограничения безопасности, определенные на прикладном уровне. В каждом уровне мы используем образцы, Чтобы представит Соответствующие механизмы безопасности. Ограничения безопасности Должны быть нанесеные на карту между уровнями.

Стадия выполнения. Эта стадия требует отражения в коде правил безопасности, определенные в стадии проекта (эскиза). Поскольку Эти правила выражены как классы, ассоциации и ограничения, они могут быть осуществлены как классы в объектноориентированных языках. В Этой стадии мы можем также выбрать определенные Секретные пакеты, например, брандмауэр, шифровальный пакет.

Развертывание и стадия обслуживания. Наша методология Еще не обращается к проблемам в ЭТИХ стадиях. Когда программное обеспечение находится в использовании, другие проблемы безопасности могут быть обнаружены пользователями. Эти проблемы могут быть решены внесения исправлений, хотя количество внесенных исправлений после применения нашего подхода должно быть значительно меньшим по сравнения с текущими системами.

Описание стадии требований

Важный аспект требований безопасности систематическое и точное внесение в список возможных нападений к системе. С этим внесение в список мы можем решить, какие определенные механизмы защиты использовать. Было несколько попыток рассмотреть атаки для определения требований к безопасности системы. В нашем подходе мы рассматриваем каждое действие в каждом случае использования и смотрим, как это может быть разрушено внутренним или внешним нападавших. Вот этого списка мы можем вы вести, какая политика необходима для предотвращения или смягчения атак. Учет и анализ нападений обеспечивает систематический и Относительно полный список возможных нападений. Каждое идентифицированное нападение может быть проанализирован, Чтобы видеть, как это может быть достигнуто в определенной окружающей среде. Список может тогда использоваться, Чтобы вести проект и выбирать механизмы безопасности. Это может также использоваться для того, Чтобы оценить заключительный проект, Анализируя, может ли защищенность системы остановить все Эти нападения. Как мы указали ранее, так как случаи использования определяют все взаимодействия с системой, мы можем найти права, необходимые для ЭТИХ ролей, для реализации возложенных функций.

Существующие мировые системы обеспечения безопасности предполагают использование политик безопасности, использование которых реализует требуемый механизм защиты. На основании нашего анализа мы можем теперь узнать, какая политика необходима, Чтобы остановить Указанные нападения. Для этого мы можем выбрать из обычных политик, используемых в безопасных системах. Это должно закончиться минимальным набором механизмов (устройств) в отличие от подхода, основанного на накопление всех механизмов по принципу их возможной полезности.

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

Описание стадии анализа. Традиционно для реализации стадии анализа используется тип анализа, основанный на семантическом шаблоне анализа (semantic analysis pattern, SAP). Семантический образец анализа - образец, Который описывает небольшой набор последовательных случаев использования, Которые вместе описывают основное общее применение. Случаи использования отбираются таким образом, что вариант применения может соответствовать разнообразными ситуациям. Используя SAP, мы развивалы методологию, Чтобы строить концептуальную модель систематически. Чтобы использовать методологию необходимо, вопервых, иметь хорошее собрание шаблонов (методов).

Описание стадии проекта. Мы можем теперь перенести архитектуру безопасности стадии анализа к стадии проекта. Один подход ограничения безопасности состоит в том, Чтобы использовать modelviewcontroller (MVC) шаблон. Каждое Представление соответствует интерфейсу для случая использования, и мы можем предписывать права роли в ЭТИХ интерфейс.

Модель проекта может быть сделана более определенной, специализируя это для специфического языка. Например, это могло быть выполнено для Java и J2EE компонентов, Используя классы, а также возможно определить права в J2EE компонентах. Эта безопасность определена в дескрипторе развертывания, Который написан в XML. Безопасность в J2EE базируется на ролях и сделках, что хорошо для реализуемой нами модели. Например, если класс объявлен как компонент, его описатель может определить, что Treatmentlnstance может только быть изменен докторами. Этот подход добавляет вторую линию защиты против ошибок администратора. Точно так же компоненты могут получить доступ к постоянным данным в относительных базах данных, Используя JDBC.