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

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

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

TCSEC, часто называемый Оранжевая книга, является центральным элементом МО Радуга серии публикации. Первоначально выпущен в 1983 г. Национальный центр компьютерной безопасности (NCSC), рука Национальное Агенство Безопасности, а затем обновленный в 1985 году, TCSEC был в конечном итоге заменен на Общие критерии международный стандарт, первоначально опубликованный в 2005 году.[нужна цитата ]

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

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

Политика

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

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

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

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

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

Уверенность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ Липнер, Стив (2015). «Рождение и смерть оранжевой книги». IEEE Annals of the History of Computing 37 нет. 2 (2015): 19-31. Извлекаются из https://dx.doi.org/10.1109/MAHC.2015.27.
  2. ^ «ИНСТРУКЦИЯ Министерства обороны - Кибербезопасность» (PDF). www.dtic.mil. Архивировано из оригинал (PDF) на 2014-04-29.
  3. ^ DOD 5200.28-STD «Критерии оценки доверенных компьютерных систем Министерства обороны», 1985, стр. 3
  4. ^ DOD 5200.28-STD «Критерии оценки доверенных компьютерных систем Министерства обороны», 1985, стр. 4
  5. ^ DOD 5200.28-STD «Критерии оценки доверенных компьютерных систем Министерства обороны», 1985, стр. 4
  6. ^ DOD 5200.28-STD "Критерии оценки доверенных компьютерных систем Министерства обороны", 1985 г.
  7. ^ DOD 5200.28-STD «Критерии оценки доверенных компьютерных систем Министерства обороны», 1985, стр. 5
  8. ^ DOD 5200.28-STD «Критерии оценки доверенных компьютерных систем Министерства обороны», 1985, стр. 9
  9. ^ DOD 5200.28-STD «Критерии оценки доверенных компьютерных систем Министерства обороны», 1985, стр. 12
  10. ^ DOD 5200.28-STD «Критерии оценки доверенных компьютерных систем Министерства обороны», 1985, стр. 20
  11. ^ DOD 5200.28-STD «Критерии оценки доверенных компьютерных систем Министерства обороны», 1985, стр. 44
  12. ^ Постановление армии 380-19. Извлекаются из https://fas.org/irp/doddir/army/r380_19.pdf.

внешняя ссылка