Как построить защищенную информационную систему. Книга
Рефераты >> Программирование и компьютеры >> Как построить защищенную информационную систему. Книга

Функциональные требования разбиты на классы, ко­торые, в свою очередь состоят из разделов. Структура функциональных требований приведена на рис. 2.14.

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

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

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

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

Рис. 2.14. Структура функциональных требований «Единых критериев».

Рис. 2.15. Пример иерархического ранжирования функциональных требований «Единых критериев»

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

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

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

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

1. Название. Уникальное название требования, кото­рое используется для ссылок на него из профиля и про­екта защиты.

2. Содержание. Функциональный состав требования. «Единые критерии» разрешают использовать требова­ния только целиком, что обеспечивает их стандартиза­цию.

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

Таксономия классов функциональных требований «Единых критериев» показана на рис. 2.16.

Рис. 2.16. Таксономия классов функциональных требовании «Единых критериев».

Набор классов функциональных требований «Еди­ных критериев» отличается, других стандартов, во-первых, своей всеобъемлющей полнотой (76 требова­ний), а, во-вторых, многоуровневым подходом к обес­печению безопасности. Впервые отдельные классы требований направлены на обеспечение безопасности самих средств защиты, контроль за эксплуатацией сис­темы, обеспечение конфиденциальности сеансов дос­тупа к системе и организацию обмена информацией. Таксономия функциональных требований для всех классов «Единых критериев» показана на рис. 2.17, 2.18 и 2.19.

Рис. 2.17. Таксономия функциональных требований классов защита информации и безопасность защиты «Единых критериев».

Рис. 2.18 Таксономия функциональных требований классов идентификации и аутентификации.

Рис. 2.19. Таксономия функциональных требований классов контроль за использованием ресурсов, обеспечение прямого взаимодействия, контроль доступа к системе, конфиденциальность доступа к системе и информационный обмен «Единых критериев».

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

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

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

Ранжирование функциональных требований пред­ставлено в Приложении III.

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

Как и функциональные требования, требования аде­кватности жестко структурированы и регламентируют все этапы проектирования, создания и эксплуатации ИТ-продукта очень детально и подробно.

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


Страница: