Критерии определения безопасности компьютерных систем

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
Оранжевая книга, 1985 год

Критерии определения безопасности компьютерных систем (англ. Trusted Computer System Evaluation Criteria) — стандарт Министерства обороны США, устанавливающий основные условия для оценки эффективности средств компьютерной безопасности, содержащихся в компьютерной системе. Критерии используются для определения, классификации и выбора компьютерных систем, предназначенных для обработки, хранения и поиска важной или секретной информации.

Критерии, часто упоминающиеся как Оранжевая книга, занимают центральное место среди публикаций «Радужной серии» Министерства обороны США. Изначально выпущенные Центром национальной компьютерной безопасности — подразделением Агентства национальной безопасности в 1983 году и потом обновлённые в 1985.

Аналогом Оранжевой книги является международный стандарт ISO/IEC 15408, опубликованный в 2005 году. Это более универсальный и совершенный стандарт, но вопреки распространенному заблуждению, он не заменял собой Оранжевую книгу в силу разной юрисдикции документов — Оранжевая книга используется исключительно Министерством Обороны США, в то время как ISO/IEC 15408 ратифицировали множество стран, включая Россию.

Содержание

Основные сведения[править | править код]

Критерии оценки доверенных компьютерных систем — стандарт Министерства обороны США (англ. Department of Defense Trusted Computer System Evaluation Criteria, TCSEC, DoD 5200.28-STD, December 26, 1985), более известный под именем «Оранжевая книга» (англ. "Orange Book") из-за цвета обложки.

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

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

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

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

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

Вслед за «Оранжевой книгой» появилась целая «Радужная серия». Наиболее значимой в ней явилась интерпретация «Оранжевой книги» для сетевых конфигураций (англ. National Computer Security Center. Trusted Network Interpretation, NCSC-TG-005, 1987), где в первой части интерпретируется «Оранжевая книга», а во второй части описываются сервисы безопасности, специфичные для сетевых конфигураций.

Основные цели и средства[править | править код]

Политики[править | править код]

Политики безопасности должны быть подробными, четко определёнными и обязательными для компьютерной системы. Есть две основных политики безопасности:

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

Ответственность[править | править код]

Индивидуальная ответственность в независимости от политики должна быть обязательной. Есть три требования по условиям ответственности:

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

Гарантии[править | править код]

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

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

Документирование[править | править код]

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

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

Основные понятия[править | править код]

Безопасная система[править | править код]

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

Доверенная система[править | править код]

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

Политика безопасности[править | править код]

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

Уровень гарантированности[править | править код]

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

Подотчетность[править | править код]

В группе «Подотчетность» должны быть следующие требования:

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

Доверенная вычислительная база[править | править код]

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

Монитор обращений[править | править код]

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

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

  1. Изолированность (неотслеживаемость работы).
  2. Полнота (невозможность обойти).
  3. Верифицируемость (возможность анализа и тестирования).

Ядро безопасности[править | править код]

Конкретная реализация монитора обращений, обладающая гарантированной неизменностью.

Периметр безопасности[править | править код]

Это граница доверенной вычислительной базы.

Механизмы реализации безопасности[править | править код]

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

Иначе — добровольное управление доступом.

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

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

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

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

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

Метки безопасности[править | править код]

Предусмотрены метки для субъектов (степень благонадежности) и объектов (степень конфиденциальности информации). Метки безопасности содержат данные об уровне секретности и категории, к которой относятся данные. Согласно «Оранжевой книге», метки безопасности состоят из двух частей — уровня секретности и списка категорий. Уровни секретности, поддерживаемые системой, образуют упорядоченное множество, которое может выглядеть, например, так:

  • совершенно секретно;
  • секретно;
  • конфиденциально;
  • не секретно.

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

Главная проблема, которую необходимо решать в связи с метками, это обеспечение их целостности. Во-первых, не должно быть непомеченных субъектов и объектов, иначе в меточной безопасности появятся легко используемые бреши. Во-вторых, при любых операциях с данными метки должны оставаться правильными. В особенности это относится к экспорту и импорту данных. Например, печатный документ должен открываться заголовком, содержащим текстовое и/или графическое представление метки безопасности. Аналогично при передаче файла по каналу связи должна передаваться и ассоциированная с ним метка, причем в таком виде, чтобы удаленная система могла её разобрать, несмотря на возможные различия в уровнях секретности и наборе категорий.

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

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

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

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

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

Разделы и классы[править | править код]

Критерии делятся на 4 раздела: D, C, B и A, из которых наивысшей безопасностью обладает раздел A. Каждый дивизион представляет собой значительные отличия в доверии индивидуальным пользователям или организациям. Разделы C, B и A иерархически разбиты на серии подразделов, называющиеся классами: C1, C2, B1, B2, B3 и A1. Каждый раздел и класс расширяет или дополняет требования указанные в предшествующем разделе или классе.

D — Минимальная защита[править | править код]

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

C — Дискреционная защита[править | править код]

  • C1 — Дискреционное обеспечение секретности.
  • C2 — Управление доступом
    • Более чётко оформленное дискреционное управление доступом.
    • Индивидуальные учётные записи, вход под которыми возможен через процедуру авторизации.
    • Журнал контроля доступа к системе.
    • Изоляция ресурсов.

B — Мандатная защита[править | править код]

  • B1 — Защита с применением мета-безопасности
    • Мандатное управление доступом к выбранными субъектам и объектам.
    • Все обнаруженные недостатки должны быть устранены или убраны каким-либо другим способом.
    • Маркировка данных
  • B2 — Структурированная защита
    • Чётко определённая и документированная модель правил безопасности.
    • Применение расширенного дискреционного и мандатного управления доступом ко всем объектам и субъектам.
    • Скрытые каналы хранения.
  • B3 — Домены безопасности
    • Соответствие требованиям монитора обращений.
    • Структурирование для исключения кода, не отвечающего требованиям обязательной политики безопасности.
    • Поддержка администратора системы безопасности.
    • Примером подобной системы является XTS-300, предшественница XTS-400.

A — Проверенная защита[править | править код]

  • A1 — Проверенный дизайн.
    • По функциям идентично B3.
    • Формализованный дизайн и проверенные техники, включающие высокоуровневую спецификацию.
    • Формализованные процедуры управления и распространения.
    • Примером подобной системы является SCOMP, предшественница XTS-400.
  • Выше A1
    • Системная архитектура демонстрирующая, что требования самозащиты и полноценности для мониторов обращений были выполнены в соответствии с «Базой безопасных вычислений» (коллекцией программного и аппаратного обеспечения необходимых для обязательной политики безопасности в операционных системах ориентированных на безопасность).

Классы безопасности[править | править код]

В критериях впервые введены четыре уровня доверия — D, C, B и A, которые подразделяются на классы. Классов безопасности всего шесть — C1, C2, B1, B2, B3, A1 (перечислены в порядке ужесточения требований).

Уровень D[править | править код]

Данный уровень предназначен для систем, признанных неудовлетворительными.

Уровень C[править | править код]

Иначе — произвольное управление доступом.

Класс C1[править | править код]

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

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

Класс C2[править | править код]

В дополнение к C1:

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

Уровень B[править | править код]

Также именуется — принудительное управление доступом.

Класс B1[править | править код]

В дополнение к C2:

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

Класс B2[править | править код]

В дополнение к B1:

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

Класс B3[править | править код]

В дополнение к B2:

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

Уровень A[править | править код]

Носит название — верифицируемая безопасность.

Класс A1[править | править код]

В дополнение к B3:

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

Краткая классификация[править | править код]

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

  • уровень C — произвольное управление доступом;
  • уровень B — принудительное управление доступом;
  • уровень A — верифицируемая безопасность.

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

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

См. также[править | править код]

Ссылки[править | править код]