Общая структура требований TCSEC

В «Оранжевой книге» предложены четыре категории требований: политика, подотчетность, гарантии и документирование, в рамках кото­рых сформулированы базовые требования безопасности. Рассмотрим не­которые из них подробнее. • Политика

Требование 1. Политика безопасности. Система должна поддер­живать точно определенную политику безопасности (мандатную или дис­креционную). Возможность доступа субъектов к объектам должна опре­деляться на основании их идентификации и набора правил управления доступом.

• Подотчетность (аудит)

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

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

• Гарантии (корректность)

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

Требование 5. Непрерывность защиты. Все средства защиты (в том числе и реализующие данное требование) должны быть защищены от несанкционированного вмешательства и/или отключения, причем эта защита должна быть постоянной и непрерывной в любом режиме функ­ционирования системы защиты и компьютерной системы в целом. Данное требование распространяется на весь жизненный цикл компьютерной сис­темы. Кроме того, его выполнение является одной из ключевых аксиом, используемых для формального доказательства безопасности системы.

• Документирование

Требование 6. Документирование. В каждом классе необходимо выделять набор документов, который адресован разработчикам, пользова­телям и администраторам системы в соответствии с их полномочиями. Эта документация может состоять из:

• Руководства пользователя по особенностям безопасности.

• Руководства по безопасным средствам работы.

• Документации о тестировании.

• Проектной документации.

Классы защищенности компьютерных систем по TCSEC «Оранжевая книга» предусматривает четыре группы критериев, ко­торые соответствуют различной степени защищенности: от минимальной (группа D) до формально доказанной (группа А). Каждая группа включает один или несколько классов. Группы D и А содержат по одному классу (классы D и А соответственно), группа С-классы Cl, C2, а группа В -классы Bl, B2, ВЗ, характеризующиеся различными наборами требований защищенности. Уровень защищенности возрастает от группы D к группе А, а внутри группы - с увеличением номера класса. Усиление требований осуществляется с постепенным смещением акцентов от положений, опре­деляющих наличие в системе каких-то определенных механизмов защиты, к положениям обеспечивающих высокий уровень гарантий того, что сис­тема функционирует в соответствии требованиям политики безопасности. Например, по реализованным механизмам защиты классы ВЗ и А1 иден­тичны.

Все эти требования могут быть представлены в виде таблицы.

Таблица 2

Требования	С1		ВЗ	А1
1. Требование 1	—		—	—
2. Требование 2	—		+	=
3. Требование 3	—		+	+

«-» - нет требований по этому классу

«+» - новые или дополнительные требования

«=» - требования совпадают с требованиями предыдущего класса

Перечень требований по Оранжевой книге в виде таблицы можно по­смотреть в Приложении 2. Опишем смысл требований в словесной форме.

Так как центральным объектом исследования и оценки по ТС SEC является доверительная база вычислений (Trusted Computing Base, TCB), необходимо коротко познакомиться с этим понятием.

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

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

Таким образом, монитор ссылок должен удовлетворять трем требо­ваниям:

• ни один запрос на доступ субъекта к объекту не должен прохо­дить мимо монитора ссылок;

• целостность монитора ссылок должна строго контролироваться;

• представление монитора ссылок должно быть достаточно про­стым для доказательства корректности его работы.

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

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

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

Основной причиной выделения программного обеспечения ТСВ сис­темы является необходимость независимости свойства безопасности сие-

темы от программного обеспечения системы, не входящего в состав ТСВ. Программное обеспечение ТСВ системы обычно много компактнее и проще, чем программное обеспечение системы в целом.

Возвращаясь к ТС SEC...