Что включает в себя политика безопасности согласно оранжевой книге

3.2. «Оранжевая книга»

3.2. «Оранжевая книга»

Стандарт «Критерии оценки доверенных компьютерных систем» /Trusted Computer System Evaluation Criteria/, более известный как «Оранжевая книга», [26] был разработан Министерством Обороны США в 1983 г. и стал первым в истории общедоступным оценочным стандартом в области информационной безопасности.

Требования «Оранжевой книги» имеют следующую структуру:

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

«Оранжевая книга» определяет четыре группы классов защищённости:

A – содержит единственный класс A1.

B – содержит классы B1, B2 и B3.

С – содержит классы C1 и C2.

D – содержит единственный класс D1.

Требуемый уровень защищённости системы возрастает от группы D к группе A, а в пределах одной группы – с увеличением номера класса. Каждый класс характеризуется определённым фиксированным набором требований к подсистеме обеспечения информационной безопасности, реализованной в АС.

Приведём краткие характеристики каждого из классов защищённости.

1. Группа D – минимальная защита.

К данной категории относятся те системы, которые были представлены для сертификации по требованиям одного из более высоких классов защищённости, но не прошли испытания.

Данная группа характеризуется наличием дискреционного управления доступом и регистрации действий субъектов.

3. Группа B – мандатная защита

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

4. Группа A – верифицированная защита

Группа характеризуется применением формальных методов верификации корректности функционирования механизмов управления доступом. Требуется дополнительная документация, демонстрирующая, что архитектура и реализация ядра безопасности отвечает требованиям безопасности. Функциональные требования совпадают с классом B3, однако на всех этапах разработки АС требуется применение формальных методов верификации систем защиты.

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

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

Стараясь не отстать от развивающихся информационных технологий, разработчики «Оранжевой книги» вплоть до 1995 г. выпустили целый ряд вспомогательных документов, известных как «Радужная серия». Эти документы содержали рекомендации по применению положений «Оранжевой книги» для различных категорий автоматизированных систем, а также вводили ряд дополнительных требований. Наибольший интерес в «Радужной серии» представляют три документа: «Интерпретация для защищённых сетей», «Интерпретация для защищённых СУБД» и «Руководство по управлению паролями».

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

Источник

«Оранжевая книга» США

С 1983 по 1988 год Министерство обороны США и Национальный комитет компьютерной безопасности разработали систему стандартов в области компьютерной безопасности, которая включает более десяти документов. Этот список возглавляют «Критерии оценки безопасности компьютерных систем», которые по цвету обложки чаще называют «Оранжевой книгой». В 1995 году Национальный центр компьютерной безопасности США опубликовал «Пояснения к критериям безопасности компьютерных систем», объединившие все имеющиеся на тот момент дополнения и разъяснения к «Оранжевой книге».

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

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

Основные элементы политики безопасности

Рассмотрим перечисленные элементы подробнее.

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

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

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

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

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

Метки безопасности


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

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

Описанный способ управления доступом называется принудительным, поскольку он не зависит от воли субъектов (даже системных администраторов). После того как зафиксированы метки безопасности субъектов и объектов, оказываются зафиксированными и права доступа. В терминах принудительного управления нельзя выразить предложение «разрешить доступ к объекту X еще и для пользователя Y». Конечно, можно изменить метку безопасности пользователя Y, но тогда он, скорее всего, получит доступ ко многим дополнительным объектам, а не только к X.

Принудительное управление доступом реализовано во многих вариантах операционных систем и СУБД, отличающихся повышенными мерами безопасности. В частности, такие варианты существуют для SunOS и СУБД Ingres. Независимо от практического использования принципы принудительного управления являются удобным методологическим базисом для начальной классификации информации и распределения прав доступа. Удобнее мыслить в терминах уровней секретности и категорий, чем заполнять неструктурированную матрицу доступа.

Классы безопасности

Итак, ниже следуют критерии оценки надежных компьютерных систем.

Требования к политике безопасности

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

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

( Примечание. Поскольку классы B1 и B2 не упоминаются, требования к ним в плане добровольного управления доступом те же, что и для C2. Аналогично, требования к классу A1 те же, что и для B3.)

Повторное использование объектов:


Метки безопасности:


Целостность меток безопасности:


Принудительное управление доступом:

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

Требования к подотчетности


Идентификация и аутентификация:


Предоставление надежного пути:


Аудит:

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

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

Требования к гарантированности


Архитектура системы:


Целостность системы:


Анализ тайных каналов передачи информации:


Надежное администрирование:


Надежное восстановление:


Тестирование:

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

Верификация спецификаций архитектуры:


Конфигурационное управление:


Надежное распространение:


Требования к документации


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


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


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


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

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

Источник

Введена в действие «Оранжевая книга»

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

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

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

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

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

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

Механизмы безопасности

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

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

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

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

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

Классы безопасности

Класс C2 (в дополнение к C1):

Класс B1 (в дополнение к C2):

Класс B2 (в дополнение к B1):

Класс B3 (в дополнение к B2):

Класс A1 (в дополнение к B3):

Такова классификация, введенная в «Оранжевой книге». Коротко ее можно сформулировать так:

Информационная безопасность распределенных систем. Рекомендации X.800


Сетевые сервисы безопасности

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

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

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

Таблица 5.1. Распределение функций безопасности по уровням эталонной семиуровневой модели OSI
Функции безопасностиУровень
1234567
Аутентификация+++
Управление доступом+++
Конфиденциальность соединения++++++
Конфиденциальность вне соединения+++++
Избирательная конфиденциальность++
Конфиденциальность трафика+++
Целостность с восстановлением++
Целостность без восстановления+++
Избирательная целостность+
Целостность вне соединения+++
Неотказуемость+

«+» данный уровень может предоставить функцию безопасности;

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

Сетевые механизмы безопасности

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

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

«+» механизм пригоден для реализации данной функцию безопасности;

«-» механизм не преднозначен для реализации данной функции безопасности.

Администрирование средств безопасности

Согласно рекомендациям X.800, усилия администратора средств безопасности должны распределяться по трем направлениям:

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

Обязанности администратора механизмов безопасности определяются перечнем задействованных механизмов. Типичный список таков:

Мы видим, что администрирование средств безопасности в распределенной ИС имеет много особенностей по сравнению с централизованными системами.

Стандарт ISO/IEC 15408 «Критерии оценки безопасности информационных технологий»


Основные понятия

По историческим причинам данный стандарт часто называют «Общими критериями» (или даже ОК). Мы также будем использовать это сокращение.

Как и «Оранжевая книга», ОК содержат два основных вида требований безопасности:

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

В свою очередь, угрозы характеризуются следующими параметрами:

Уязвимые места могут возникать из-за недостатка в:

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

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

Семейства в пределах класса различаются по строгости и другим нюансам требований.

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

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

Задание по безопасности содержит совокупность требований к конкретной разработке, выполнение которых обеспечивает достижение поставленных целей безопасности.

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

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

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

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

Перечислим классы функциональных требований ОК:

Опишем подробнее два класса, демонстрирующие особенности современного подхода к ИБ.

Класс «Приватность» содержит 4 семейства функциональных требований.

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

Установление доверия безопасности, согласно «Общим критериям», основывается на активном исследовании объекта оценки.

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

Всего в ОК 10 классов, 44 семейства, 93 компонента требований доверия безопасности. Перечислим классы:

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

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

На уровне 6 реализация должна быть представлена в структурированном виде. Анализ соответствия распространяется на проект нижнего уровня.

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

На этом мы заканчиваем краткий обзор «Общих критериев».

Гармонизированные критерии Европейских стран

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

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

Гармонизированные критерии Европейских стран явились для своего времени весьма передовым стандартом, они создали предпосылки для появления «Общих критериев».

Интерпретация «Оранжевой книги» для сетевых конфигураций

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

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

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

Для обеспечения непрерывности функционирования могут применяться следующие защитные меры:

Данное утверждение является теоретической основой декомпозиции распределенной ИС в объектно-ориентированном стиле в сочетании с криптографической защитой коммуникаций.

Источник

Введена в действие «Оранжевая книга»

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

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

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

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

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

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

Механизмы безопасности

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

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

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

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

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

Классы безопасности

Класс C2 (в дополнение к C1):

Класс B1 (в дополнение к C2):

Класс B2 (в дополнение к B1):

Класс B3 (в дополнение к B2):

Класс A1 (в дополнение к B3):

Такова классификация, введенная в «Оранжевой книге». Коротко ее можно сформулировать так:

Информационная безопасность распределенных систем. Рекомендации X.800


Сетевые сервисы безопасности

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

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

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

Таблица 5.1. Распределение функций безопасности по уровням эталонной семиуровневой модели OSI
Функции безопасностиУровень
1234567
Аутентификация+++
Управление доступом+++
Конфиденциальность соединения++++++
Конфиденциальность вне соединения+++++
Избирательная конфиденциальность++
Конфиденциальность трафика+++
Целостность с восстановлением++
Целостность без восстановления+++
Избирательная целостность+
Целостность вне соединения+++
Неотказуемость+

«+» данный уровень может предоставить функцию безопасности;

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

Сетевые механизмы безопасности

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

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

«+» механизм пригоден для реализации данной функцию безопасности;

«-» механизм не преднозначен для реализации данной функции безопасности.

Администрирование средств безопасности

Согласно рекомендациям X.800, усилия администратора средств безопасности должны распределяться по трем направлениям:

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

Обязанности администратора механизмов безопасности определяются перечнем задействованных механизмов. Типичный список таков:

Мы видим, что администрирование средств безопасности в распределенной ИС имеет много особенностей по сравнению с централизованными системами.

Стандарт ISO/IEC 15408 «Критерии оценки безопасности информационных технологий»


Основные понятия

По историческим причинам данный стандарт часто называют «Общими критериями» (или даже ОК). Мы также будем использовать это сокращение.

Как и «Оранжевая книга», ОК содержат два основных вида требований безопасности:

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

В свою очередь, угрозы характеризуются следующими параметрами:

Уязвимые места могут возникать из-за недостатка в:

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

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

Семейства в пределах класса различаются по строгости и другим нюансам требований.

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

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

Задание по безопасности содержит совокупность требований к конкретной разработке, выполнение которых обеспечивает достижение поставленных целей безопасности.

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

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

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

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

Перечислим классы функциональных требований ОК:

Опишем подробнее два класса, демонстрирующие особенности современного подхода к ИБ.

Класс «Приватность» содержит 4 семейства функциональных требований.

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

Установление доверия безопасности, согласно «Общим критериям», основывается на активном исследовании объекта оценки.

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

Всего в ОК 10 классов, 44 семейства, 93 компонента требований доверия безопасности. Перечислим классы:

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

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

На уровне 6 реализация должна быть представлена в структурированном виде. Анализ соответствия распространяется на проект нижнего уровня.

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

На этом мы заканчиваем краткий обзор «Общих критериев».

Гармонизированные критерии Европейских стран

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

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

Гармонизированные критерии Европейских стран явились для своего времени весьма передовым стандартом, они создали предпосылки для появления «Общих критериев».

Интерпретация «Оранжевой книги» для сетевых конфигураций

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

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

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

Для обеспечения непрерывности функционирования могут применяться следующие защитные меры:

Данное утверждение является теоретической основой декомпозиции распределенной ИС в объектно-ориентированном стиле в сочетании с криптографической защитой коммуникаций.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *