Исследование и обоснование возможностей автоматизации процедуры анализа защищенности автоматизированных систем

Формализация основных понятий и отношений информационной безопасности, введение классификации требований и угроз безопасности, определение операций над требованиями создают предпосылки для разработки прототипа экспертной системы (ЭС) анализа защищенности АС, опирающегося на концепцию оценивания безопасности, выраженную в «Единых критериях». Построение ЭС на основе «Единых критериев» позволяет обеспечить ее соответствие современному состоянию ИТ и международным стандартам информационной безопасности, а также возможность повторного использования результатов оценивания безопасности.

Введение

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

Идентификация целей и задач создания экспертной системы анализа защищенности автоматизированных систем

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

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

Разработка ЭС в области анализа защищенности АС возможна по следующим причинам:

1. Cуществуют эксперты в области информационной безопасности, которые решают задачу анализа защищенности значительно лучше, чем начинающие специалисты.
2. В настоящее время все эксперты в области информационной безопасности стараются придерживаться общей схемы проведения оценивания безопасности АС. С этой целью разрабатываются единые критерии, процедуры и методики оценивания.
3. «Единые критерии» устанавливают общую схему оценивания безопасности, определяет формальный язык, систему понятий и структур данных для формулирования утверждений относительно безопасности АС, а также определяют классификацию требований безопасности, систему формальных обозначений для них, а также классы и уровни защищенности АС. Таким образом понятия и методы, используемые при решении задачи анализа защищенности являются четко сформулированными и закрепленными соответствующими стандартами. Кроме того в мире накоплен огромный опыт в области проектирования, разработки и оценивания безопасности АС, являющийся достоянием небольшого числа специалистов.
4. Задача анализа защищенности легко допускает разбиение на меньшие, более быстро решаемые и относительно независимые подзадачи (на основе классификационного подхода, предполагающего категорирование объектов информационной безопасности по различным критериям), каждая из которых может быть выбрана для создания ЭС.

Применение ЭС в области анализа защищенности АС является оправданным по следующим причинам:

1. Использование человека-эксперта в области информационной безопасности затруднительно, т. к. экспертов мало и их услуги дороги. Тиражирование ЭС практически без дополнительных затрат позволит решить эту проблему.
2. Разработка ЭС оправдана, когда происходит недопустимая утрата человеческого опыта. В результате кадровых перемещений, выхода на пенсию, перевода по службе в военных ведомствах важнейший опыт работы, накопленный сотрудниками, уходит вместе с ними. Закрепление ценного опыта в экспертной системе может свести к минимуму эти потери.

И наконец, разработка ЭС для анализа защищенности АС уместна, т. к. решение задач этой предметной области полностью соответствует методам инженерии знаний. Действительно, задача анализа защищенности АС обладает следующими характеристиками:

1. Решение задачи анализа защищенности может быть естественным образом получено посредством манипулирования символами (т. е. с помощью символьных рассуждений), а не с числами, как принято в математических моделях и в традиционных программах.
2. Задача анализа защищенности имеет эвристическую природу, и, как показывают многочисленные исследования формальных методов в теории безопасных систем, не может быть гарантировано решена с помощью алгоритмов.
3. Сложность задачи анализа защищенности приводит к тому, что человеку необходимо затратить годы учения и практики, чтобы стать в ней экспертом.

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

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

Создание ЭС анализа защищенности АС преследует следующие цели:

• создание базы знаний в области информационной безопасности;
• автоматизация процессов разработки и оценивания профилей и проектов защиты АС;
• улучшение качества проводимых оцениваний безопасности АС и качества разрабатываемых СЗИ за счет использования знаний наиболее квалифицированных экспертов;
• формализация основных понятий и методов информационной безопасности;
• использование ЭС в качестве справочной системы в учебном процессе.

ЭС анализа защищенности АС позволит автоматизировать  и существенно повысить эффективность решения следующих задач:

1.     Разработка новых профилей защиты для различных классов АС

Задачу разработки профиля защиты можно разделить на несколько подзадач:

а) Определение окружения безопасности

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

б) Определение целей и задач защиты

• определение целей и задач защиты ИТ
• определение других целей и задач защиты, не относящиеся к сфере ИТ

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

• определение функциональных требований безопасности
• определение требований адекватности механизмов безопасности
• определение необязательных требований к ИТ-окружению

Для решения перечисленных задач ЭС должна предоставлять пользователю следующие возможности:

1. Определение угроз безопасности, правил политики безопасности и условий функционирования в диалоговом режиме. При этом пользователь должен иметь возможность выбора угроз, правил и условий из БЗ по ключевым словам и другим атрибутам. ЭС отслеживает связи между угрозами, правилами и условиями и предлагает добавить или удалить из окружения безопасности те или иные угрозы, правила и условия.
2. В случае отсутствия в БЗ отдельных видов угроз, правил и условий, ЭС должна предоставлять удобные диалоговые средства для добавления в БЗ соответствующих определений и связей.
3. Автоматическое формирование множества целей и задач защиты на основе определенного на предыдущем шаге окружения безопасности, а также определение и объяснение связей между ними и окружением безопасности.
4. В случае отсутствия в БЗ отдельных видов задач защиты ЭС должна предоставлять удобные диалоговые средства для добавления в БЗ соответствующих определений и связей.
5. Автоматическое формирование ЭС множества требований безопасности на основе определенного на предыдущем шаге множества целей и задач защиты, а также определение и объяснение связей между ними и задачами защиты.
6. В случае отсутствия в БЗ отдельных требований безопасности ЭС должна предоставлять удобные диалоговые средства для добавления в БЗ соответствующих определений и связей.
7. Предоставление пользователю возможности выбора из БЗ профиля или профилей защиты, принимаемых за основу при разработке нового профиля защиты. ЭС автоматически отслеживает взаимосвязи и противоречия между профилями защиты, контролирует целостностность, полноту и непротиворечивость профиля защиты, помогает устранить избыточные требования и обнаружить узкие места, требующие добавления новых требований безопасности.
8. ЭС должна в наглядной форме представлять взаимосвязи между требованиями безопасности и окружением безопасности. Пользователь должен иметь возможность определить  для защиты от каких угроз, с учетом каких условий функционирования и действующих правил политики безопасности предназначается данное требование безопасности.
9. Автоматическое формирование обоснования целей и задач защиты и требований безопасности.

2.     Разработка проектов защиты

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

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

3.     Оценивание профилей и проектов защиты

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

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

4.     Формирование БЗ в области информационной безопасности

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

а) Создание реестра профилей и проектов защиты

б) Создание модели знаний, описывающей свойства защищенных систем

в) Создание диалоговых средств извлечения знаний о предметной области

г) Создание формализованного представления для основных понятий и структур данных предметной области

5.     Использование ЭС в качестве информационно-справочной системы в процессе подготовки специалистов области информационной безопасности

Возможны следующие области применения ЭС в процессе обучения:

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

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

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

Объект оценивания (TOE) — ИТ-продукт или система, безопасность которых требуется оценить.

Профиль защиты (PP) — структура данных, описывающая определенный класс защищенных систем в терминах угроз безопасности, задач защиты и требований безопасности, предъявляемых к этим системам. Целостность этой структуры данных определяется соответствием выраженных в профиле защиты требований безопасности задачам защиты, а также соответствием задач защиты угрозам безопасности. Структура профиля защиты и совокупность требований, которые он может содержать, определены в «Единых критериях».

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

Исходными данными для разработки профиля защиты являются:

• Единые критерии оценивания безопасности ИТ;
• Знания экспертов о назначении, основных свойствах и особенностях рассматриваемого класса АС;
• Представления экспертов об окружении безопасности, в котором эксплуатируются подобные системы (возможных угрозах и политиках безопасности).

Выводными данными являются:

• задачи защиты;
• требования безопасности;
• обоснование профиля защиты.

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

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

А) выполнение задач защиты позволяет эффективно противодействовать всем определенным в Профиле защиты угрозам безопасности.

Б) сформулированные задачи защиты полностью перекрывают все определенные в Профиле защиты политики безопасности.

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

1. Результатом объединения множеств Целей защиты, соответствующих отдельным компонентам требований безопасности,  является множество всех задач защиты;
2. Требования безопасности не противоречят друг другу;
3. Были учтены все зависимости между компонентами требований;
4. Выбор уровня адекватности оценивания и дополняющих его требований адекватности является оправданным.

Для получения выводных данных ЭС использует БЗ в состав которой входят:

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

Разработка профиля защиты при помощи ЭС выглядит следующим образом:

Шаг 1: Определение окружения безопасности

1. Определение угроз безопасности
2. Определение правил политики безопасности
3. Определение предположений, которые будут сделаны относительно окружения безопасности и условий функционирования ОО

Шаг 2: Определение задач защиты

Шаг 3: Определение требований безопасности

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

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

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

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

Угроза безопасности определяется следующими атрибутами:

1. Источник угрозы, описываемый моделью нарушителя
2. Вид атаки, указывает на принадлежность к тому или иному известному виду атак, согласно их классификации
3. Способ атаки, указывает на принадлежность к тому или иному известному способу атаки данного вида, согласно их классификации
4. Объект атаки (ресурс АС, против которого направлена атака)
5. Последствия (результат) осуществления угрозы (описание последствий и оценка вероятного ущерба)
6. Условия (предпосылки) возникновения угрозы безопасности, такие как наличие определенных видов изьянов защиты, нарушения технологического процесса проектирования и разработки ПО и т. п. (описание может содержать ссылки на известные ИЗ)
7. Жизненный цикл угрозы, который состоит из следующих процессов:

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

В качестве примера рассмотрим модель угрозы безопасности T.ACCESS:

Идентификатор угрозы: T.ACCESS

Название угрозы: НСД к информации

Вид угрозы: угроза конфиденциальности и целостности информации

Адресат: ОО (или окружение безопасности)

Описание угрозы: Пользователь может получить доступ к ресурсам АС или выполнить операции, на которые ему не было предоставлено соответствующих прав

Модель нарушителя: Можно выделить следующие категории потенциальных нарушителей:

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

Вид атаки: использование штатных средств для осуществления НСД к информации АС

Способ атаки: подбор или воровство пароля, использование слабостей защиты

Цель: Изменение настроечной информации КСЗ, включающего в себя МЭ, средства мониторинга и разграничения доступа, подсистему аутентификации и т. п.

Объект атаки: БД

Последствия: раскрытие конфиденциальной информации, нарушение целостности критичной информации, Х р. — материальный ущерб.

Предпосылки: ошибка средств разграничения доступа

Связь с другими угрозами: T.FLAW, T.FAIL

Жизненный цикл угрозы:

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

Угрозу T.ACCESS можно рассматривать в качестве совокупности множества часных угроз. Так, в зависимости от уровня возможностей нарушителя, она делиться на 4 части T.ACCESS.1, T.ACCESS.2, T.ACCESS.3, T.ACCESS.4. Таким образом T.ACCESS = T.ACCESS.1 È T.ACCESS.2 È T.ACCESS.3 È T.ACCESS.4.

Угрозу НСД со стороны оператора АС в свою очередь можно разделить на несколько угроз, в зависимости от вида атаки:

T.ACCESS.1 = T.ACCESS.1.1 È T.ACCESS.1.2 È T.ACCESS.1.3 È …

Угрозы, из которых состоит T.ACCESS.1 также различаются по способу и объекту атаки.

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

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

1. угроза (ИД угрозы, название угрозы, вид угрозы, адресат, описание угрозы, ИД модели нарушителя, ИД вида атаки, ИД способа атаки, цель атаки, объект атаки, предпосылки атаки, последствия)
2. жизненный_цикл_угрозы (ИД угрозы, зарождение, развитие, проникновение в АС, проникновение в критичную информацию, инициализация, результат действия, регенерация)
3. модель_нарушителя (ИД нарушителя, уровень возможностей, мотивация)
4. вид_атаки (ИД вида атаки, описание вида атаки)
5. способ_атаки (ИД способа атаки, ИД вида атаки, описание способа атаки)
6. объект_атаки (ИД объекта, название, характеристика)
7. связь_между_угрозами (ИД угрозы, ИД угрозы, характер связи)

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

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

• предположения относительно применения ОО;
• предположения относительно физической защиты отдельных частей ОО;
• предположения относительно взаимодействия ОО с окружающей средой (например, предположение о том, что МЭ является единственным связующим звеном между внешней и внутренней сетью);
• предположения относительно персональных аспектов окружения безопасности (например, предположение относительно пользовательских ролей и степени доверия к ним).

Предположение относительно окружения безопасности A.USER определяется следующими атрибутами:

1. Идентификатор предположения: A.USER
2. Тип предположения: персональный аспект
3. Описание: пользователям ОО предоставляются необходимые полномочия для доступа к информации ОО.

Предположение может быть представленно в виде отношения реляционной модели данных:

Предположение (ИД, Тип, Описание).

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

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

Правило (ИД правила, Описание)

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

1. Задачи защиты для ОО, решаемые на программно-техническом уровне при помощи соответствующих механизмов безопасности ОО (возможно совместно с механизмами безопасности среды функционирования ОО).
2. Задачи защиты для среды функционирования ОО, решаемые на процедурном и административных уровнях управления при помощи соответствующих организационных мер.

Задача защиты может быть представлена следующим отношением реляционной модели данных:

Задача (ИД задачи, вид задачи, описание)

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

1. Функциональные требования безопасности для ОО, определяющие набор функций безопасности ОО, необходимых для решения задач защиты.
2. Требования адекватности механизмов безопасности ОО.
3. Требования безопасности для среды функционирования ОО, включающие в себя любые функциональные требования безопасности или требования адекватности, предъявляемые к аппаратному, микропрограммному и/или программному обеспечению среды функционирования ОО, от которых зависит безопасность ОО.
4. Каждое требование безопасности, кроме этого, характеризуется принадлежностью к определенному классу, семейству и компоненту требований безопасности, в соответствии с классификацией, принятой в «Единых критериях». На основании этой принадлежности каждому требованию присваивается уникальное обозначение. Например, FAU_GEN.1.2 означает следующее:

• ‘F’ показывает, что требование является функциональным;
• ‘AU’ показывает, что требование относится к классу «аудит безопасности»;
• ‘GEN’ показывает, что требование принадлежит семейству «генерация данных аудита безопасности» внутри этого класса;
• ‘1’ показывает, что требование относится к компоненту «генерация данных аудита» внутри этого семейства;
• ‘2’ показывает, что требования является вторым элементом внутри этого компонента.

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

Требование (ИД класса, ИД семейства, ИД компонента, ИД элемента, описание)

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

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

Определенная гибкость при определении требований безопасности достигается за счет использования следующих операций над требованиями «Единых критериев»:

1) назначение (assignment)

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

2) повторение (iteration)

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

3) выбор (selection)

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

4) уточнение (refinement)

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

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

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

1.     Введение

1.1.         Идентификационная информация

1.2.         Обзор профиля защиты

2.     Описание ОО

3.     Окружение безопасности

3.1.         Предположения относительно среды функционирования

3.2.         Угрозы безопасности

3.3.         Правила политики безопасности

4.     Задачи защиты

4.1.         Задачи защиты для ОО

4.2.         Задачи защиты для среды функционирования ОО

5.     Требования безопасности

5.1.         Функциональные требования

5.2.         Требования адекватности

5.3.         Требования к среде функционирования

6.     Обоснование

6.1.         Обоснование задач защиты

6.2.         Обоснование требований безопасности

7.     Замечания по использованию профиля защиты

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

Профиль_защиты (идентификатор, обзор, описание ОО, обоснование задач, обоснование требований, замечания по использованию)

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

Связь_профиль_защиты_угроза (ИД профиля защиты, ИД угрозы)

Связь_профиль_защиты_задача (ИД профиля защиты, ИД задачи)

Связь_профиль_защиты_требование (ИД профиля защиты, ИД требования)

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

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

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

Связь_угроза_задача (ИД угрозы, ИД задачи, обоснование, комментарий)

Поле «обоснование» этого отношения используется для автоматического составления обоснования для проекта защиты.

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

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

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

Связь_компонентов_требований (ИД компонента, ИД компонента, вид связи, комментарий)

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

Связь_задача_требование (ИД задачи, ИД требования, описание связи);

Связь_угроза_задача (ИД угрозы, ИД задачи, описание связи).

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

ЭС анализа защищенности АС должна включать в себя следующие основные компоненты:

1) Диалоговая интерфейсная подсистема извлечения знаний

         — подсистема объяснения

         — подсистема ввода знаний

2) База знаний

         — БД профилей защиты

         — БД проектов защиты

         — БД требований «Единых критериев»

         — база знаний правил логического вывода

3) Подсистема логического вывода

         — механизм вывода задач защиты из угроз безопасности;

         — механизм вывода требований безопасности из задач защиты;

         — механизм обратного вывода;

         — механизм верификации профиля защиты.

Попытаемся определить наиболее общие требования к подсистемам ЭС.

Требования к интерфейсной подсистеме:

1. Интерфейсная подсистема должна предоставлять формы ввода данных, для всех объектов информационной безопасности, в том числе угроз безопасности, задач защиты, требований безопасности, функций безопасности, ресурсов АС, объектов и субъектов доступа, видов доступа, правил политики безопасности, предположений о среде функционирования, категорий нарушителей безопасности, профилях защиты, проектах защиты.
2. Возможность поиска по ключевым словам и по образцу любых объектов базы знаний
3. Автоматическая проверка уникальности вводимых данных и целостности базы знаний
4. Возможность определения связей и зависимостей между объектами базы знаний
5. Диалоговый принцип общения пользователя с системой
6. Возможность использования профилей и проектов защиты, уже имеющихся в базе знаний, для определения новых профилей и проектов защиты
7. Возможность группирования объектов базы знаний и просмотра различных классов объектов и выбора объектов из группы по ключевым словам и различным атрибутам
8. Поддержка четырех видов операций над требованиями безопасности: назначение, повторение, выбор и уточнение.

Требования к базе знаний:

База знаний ЭС должна содержать следующие основные компоненты:

1. Все объекты информационной безопасности перечисленные в требованиях к интерфейсной подсистеме
2. Зависимости между всеми компонентами базы знаний
3. Правила логического вывода
4. Реестр профилей и проектов защиты
5. Описание функций и механизмов безопасности различных средств защиты информации

Требования к подсистеме логического вывода:

1. Определение задач защиты, соответствующих определенному множеству угроз безопасности
2. Определение требований безопасности, соответствующих определенному множеству задач защиты
3. Определение функций безопасности соответствующих определенному множеству требований безопасности
4. Обратный вывод
5. Верификация профилей и проектов защиты (проверка соответствия между различными уровнями абстрактного представления АС)
6. Определение связей и зависимостей между основными объектами информационной безопасности (угрозами безопасности, задачами защиты и требованиями безопасности)

Александр Астахов, 1996