Критерии оценки доверенных компьютерных систем - Trusted Computer System Evaluation Criteria

Оранжевая книга

Критерии определения безопасности компьютерных систем ( TCSEC ) является США правительство Министерство обороны (DoD) стандарт , который устанавливает основные требования к оценке эффективности компьютерной безопасности управления , встроенных в компьютерную систему . TCSEC использовался для оценки, классификации и выбора компьютерных систем, рассматриваемых для обработки, хранения и поиска конфиденциальной или секретной информации .

TCSEC, часто называемый « Оранжевой книгой» , является центральным элементом публикаций DoD Rainbow Series . Первоначально выпущенный в 1983 году Национальным центром компьютерной безопасности (NCSC), подразделение Агентства национальной безопасности , а затем обновленный в 1985 году, TCSEC в конечном итоге был заменен международным стандартом Common Criteria , первоначально опубликованным в 2005 году.

Основные цели и требования

24 октября 2002 года «Оранжевая книга» (также известная как DoDD 5200.28-STD) была отменена DoDD 8500.1, которая позже была переиздана как DoDI 8500.02 14 марта 2014 года.

Политика

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

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

Подотчетность

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

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

Уверенность

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

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

Документация

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

  • Руководство пользователя функций безопасности, Руководство по Trusted Facility, Тестовая документация и Проектная документация

Подразделения и классы

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

Каждое подразделение и класс расширяется или модифицируется в соответствии с требованиями непосредственно предшествующего подразделения или класса.

D - минимальная защита

  • Зарезервировано для тех систем, которые прошли оценку, но не соответствуют требованиям для более высокого уровня.

C - Дискреционная защита

  • C1 - Дискреционная защита безопасности
    • Идентификация и аутентификация
    • Разделение пользователей и данных
    • Дискреционный контроль доступа (DAC), способный применять ограничения доступа на индивидуальной основе
    • Необходимая системная документация и руководства пользователя
  • C2 - контролируемая защита доступа
    • Более мелкозернистый ЦАП
    • Индивидуальная подотчетность через процедуры входа в систему
    • Журналы аудита
    • Повторное использование объекта
    • Изоляция ресурсов
    • Примером такой системы является HP-UX.

B - Обязательная защита

  • B1 - Маркированная защита безопасности
    • Неформальное изложение модели политики безопасности
    • Метки конфиденциальности данных
    • Обязательный контроль доступа (MAC) к выбранным субъектам и объектам
    • Возможности экспорта этикеток
    • Некоторые обнаруженные недостатки необходимо устранить или устранить иным образом.
    • Технические характеристики и проверка
  • B2 - Структурированная защита
    • Модель политики безопасности четко определена и официально задокументирована
    • Применение DAC и MAC распространяется на все субъекты и объекты
    • Скрытые каналы хранения анализируются на наличие и пропускную способность
    • Тщательно разделены на критически важные для защиты и некритичные для защиты элементы
    • Дизайн и реализация позволяют проводить более всестороннее тестирование и проверку
    • Усилены механизмы аутентификации
    • Надежное управление объектом обеспечивается разделением администратора и оператора
    • Установлены строгие меры управления конфигурацией
    • Роли оператора и администратора разделены.
    • Примером такой системы была Multics.
  • B3 - Домены безопасности
    • Удовлетворяет требованиям эталонного монитора
    • Структурирована так, чтобы исключить код, который не важен для применения политики безопасности.
    • Существенная системная инженерия, направленная на минимизацию сложности
    • Определена роль администратора безопасности
    • Аудит событий, связанных с безопасностью
    • Автоматическое обнаружение неизбежного вторжения , уведомление и ответ
    • Надежный путь к TCB для функции аутентификации пользователя
    • Процедуры восстановления доверенной системы
    • Скрытые временные каналы анализируются на наличие и пропускную способность.
    • Примером такой системы является XTS-300, предшественник XTS-400.

A - Проверенная защита

  • A1 - Подтвержденный дизайн
    • Функционально идентичен B3
    • Формальные методы проектирования и проверки, включая формальную спецификацию верхнего уровня
    • Официальные процедуры управления и распределения
    • Примерами систем класса A1 являются SCOMP от Honeywell , GEMSOS от Aesec и сервер SNS от Boeing. Два, которые не были оценены, - это производственная платформа LOCK и отмененное ядро ​​безопасности DEC VAX.
  • За пределами A1
    • Системная архитектура демонстрирует, что требования самозащиты и полноты для эталонных мониторов были реализованы в Trusted Computing Base (TCB).
    • Тестирование безопасности автоматически генерирует контрольный пример из формальной спецификации верхнего уровня или формальных спецификаций нижнего уровня.
    • Формальная спецификация и проверка - это когда TCB проверяется до уровня исходного кода с использованием формальных методов проверки, где это возможно.
    • Trusted Design Environment - это среда, в которой TCB разрабатывается на надежном объекте только с доверенным (аттестованным) персоналом.

Соответствие классов экологическим требованиям

Публикация, озаглавленная «Постановление армии 380-19», является примером руководства по определению того, какой класс системы следует использовать в данной ситуации.

Смотрите также

использованная литература

внешние ссылки