7.2. Стандарт «Критерии оценки надежности компьютерных систем» («Оранжевая книга»)

Исторически первым оценочным стандартом, получившим широкое распространение и оказавшим огромное влияние на базу стандартизации ИБ во многих странах, стал стандарт Министерства обороны США «Критерии оценки доверенных компьютерных систем».

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

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

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

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

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

Степень доверия оценивается по двум основным критериям [1].

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

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

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

Рассматриваемые компоненты вне вычислительной базы могут не быть доверенными, однако это не должно влиять на безопасность системы в целом. В результате, для оценки доверия безопасности ИС авторы стандарта рекомендуют рассматривать только ее вычислительную базу.

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

Монитор обращений должен обладать тремя качествами:

Изолированность. Необходимо предупредить возможность отслеживания работы монитора.

Полнота. Монитор должен вызываться при каждом обращении, не должно быть способов обойти его.

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

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

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

Согласно «Оранжевой книге», политика безопасности должна обязательно включать в себя следующие элементы [1]:

• произвольное управление доступом;

• безопасность повторного использования объектов;

• метки безопасности;

• принудительное управление доступом.

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

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

Для реализации принудительного управления доступом с субъектами и объектами ассоциируются метки безопасности. Метка субъекта описывает его благонадежность, метка объекта – степень конфиденциальности содержащейся в нем информации.

Согласно «Оранжевой книге», метки безопасности состоят из двух частей – уровня секретности и списка категорий. Уровни секретности образуют упорядоченное множество, а списки категорий – неупорядоченное. Назначение последних – описать предметную область, к которой относятся данные.

Принудительное (или мандатное) управление доступом основано на сопоставлении меток безопасности субъекта и объекта.

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

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

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

Если понимать политику безопасности как правила разграничения доступа, то механизм подотчетности является дополнением подобной политики. Цель подотчетности - в каждый момент времени знать, кто работает в системе и что делает. Средства подотчетности делятся на три категории:

• идентификация и аутентификация;

• предоставление доверенного пути;

• анализ регистрационной информации.

Обычный способ идентификации – ввод имени пользователя при входе в систему. Стандартное средство проверки подлинности (аутентификации) пользователя - пароль.

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

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

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

Переходя к пассивным аспектам защиты, укажем, что в «Оранжевой книге» рассматривается два вида гарантированности - операционная и технологическая.

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

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

• архитектура системы;

• целостность системы;

• проверка тайных каналов передачи информации;

• доверенное администрирование;

• доверенное восстановление после сбоев.

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

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

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

Согласно "Оранжевой книге", в комплект документации надежной системы должны входить следующие тома:

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

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

• Тестовая документация.

• Описание архитектуры.

Разумеется, на практике требуется еще по крайней мере один том - Письменное изложение политики безопасности данной организации.

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

• Как входить в систему? Как вводить имя и пароль? Как менять пароль? Как часто это нужно делать? Как выбирать новый пароль?

• Как защищать файлы и другую информацию? Как задавать права доступа к файлам? Из каких соображений это нужно делать?

• Как импортировать и экспортировать информацию, не нарушая правил безопасности?

• Как уживаться с системными ограничениями? Почему эти ограничения необходимы? Какой стиль работы сделает ограничения необременительными?

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

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

• Каковы основные защитные механизмы?

• Как администрировать средства идентификации и аутентификации? В частности, как заводить новых пользователей и удалять старых?

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

• Как администрировать средства протоколирования и аудита? Как выбирать регистрируемые события? Как анализировать результаты?

• Как администрировать средства принудительного управления доступом? Какие уровни секретности и категории выбрать? Как назначать и менять метки безопасности?

• Как генерировать новую, переконфигурированную надежную вычислительную базу?

• Как безопасно запускать систему и восстанавливать ее после сбоев и отказов? Как организовать резервное копирование?

• Как разделить обязанности системного администратора и оператора?

Тестовая документация содержит описания тестов и их результаты. По идее она проста, но зачастую весьма пространна. Кроме того, тестовая документация должна содержать план тестирования и условия, налагаемые на тестовое окружение.

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

Классы безопасности. В рассматриваемом стандарте определены подходы к ранжированию информационных систем по степени надежности. В "Оранжевой книге" рассматривается четыре уровня безопасности (надежности) — D, С, В и А. [1]

Эти классы безопасности обозначают следующее:

D1 – неудовлетворительная безопасность;

С1, С2 – произвольное управление доступом;

В1, В2, В3 – принудительное управление доступом;

А1 – верифицированная защита.

По мере перехода от уровня С к А к надежности систем предъявляются все более жесткие требования. Уровни С и В подразделяются на классы (С1, С2, В1, В2, ВЗ) с постепенным возрастанием надежности. Таким образом, всего практически используются шесть классов безопасности – С1, С2, В1, В2, ВЗ, А1. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять приводимым далее требованиям. Поскольку при переходе к каждому следующему классу требования только добавляются, то дополнительно вписываются только новые, что присуще данному классу, группируя требования в согласии с предшествующим изложением.

Каждый класс безопасности включает набор требований с учетом элементов политики безопасности и требований к гарантированности.

Так, для класса С1 требования предусматривают следующее:

– С учетом политики безопасности:

• Надежная вычислительная база должна управлять доступом именованных пользователей к именованным объектам. Механизм управления (права для владельца/группы/прочих, списки управления доступом) должен позволять пользователям специфицировать разделение файлов между индивидами и/или группами;

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

– С учетом гарантированности:

• Надежная вычислительная база должна поддерживать область, защищенную от внешних воздействий (в частности, от изменения команд и/или данных) и от попыток слежения за ходом работы. Ресурсы, контролируемые базой, могут составлять определенное подмножество всех субъектов и объектов системы.

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

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

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

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

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

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

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

Однако следует отметить, что описанный подход был ориентирован на оценку отдельных программно-технических комплексов, поэтому в 1987 году Национальным центром компьютерной безопасности США была дополнительно опубликована интерпретация «Оранжевой книги» для сетевых конфигураций [1].