Информационная безопасность. Оранжевая книга сша


ISSP \ Домен 03. Архитектура и модель безопасности. Часть 8

В этой части рассмотрены следующие вопросы:
  • Методы оценки систем
  • Зачем проводить оценку продукта?
  • Оранжевая книга
  • Оранжевая книга и Радужная серия
  • Красная книга
  • ITSEC
  • Общие критерии

Обновлено: 03.05.2010

При оценке безопасности системы проверяются части системы, имеющие отношение к ее безопасности: ТСВ, механизмы управления доступом, монитор обращений, ядро и механизмы защиты. Взаимоотношения и взаимодействие между этими компонентами также подлежит оценке. Существуют различные методы оценки и присвоения уровней гарантии системам. Но почему недостаточно только одного метода? Это связано с тем, что методы и идеология со временем развиваются, а различные страны смотрят на компьютерную безопасность по-разному и по-разному оценивают некоторые аспекты безопасности. Далее будет описан каждый из методов, и все методы будут сравнены между собой. Оценка продукта на соответствие Оранжевой книге, ITSEC или Общим критериям – это далеко не прогулка в парке для производителя. В действительности, это длительный и сложный процесс. Прежде чем перейти к этим критериям, давайте посмотрим, зачем вообще нужно проходить через этот процесс.

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

В США Национальный центр компьютерной безопасности (NCSC – National Computer Security Center), входящий в Агентства национальной безопасности (NSA – National Security Agency), является организацией, которая отвечает за оценку компьютерных систем и продуктов. NCSC использует Программу оценки доверия к продукту (TPEP – Trusted Product Evaluation Program) при проведении тестирования коммерческих продуктов на соответствие определенному набору критериев для присвоения им рейтинга.

Таким образом, производители создают продукт и передают его на оценку, которая является проверкой соответствия требованиям TPEP. Оценивающая организация имеет группу тестировщиков, которые следуют набору критериев (многие годы этими критериями была Оранжевая книга, но сейчас для этих целей используются Общие критерии) для тестирования продукта, предоставленного производителем на оценку. После прохождения оценки, продукту присваивается рейтинг уровня гарантий. Успешно оцененные продукты размещаются в Списке оцененных продуктов (EPL – Evaluated Products List) с указанием присвоенного им рейтинга. Поэтому, вместо того, чтобы просто доверять маркетологам производителя, вы, как покупатель, можете поверить словам независимой третьей стороны, полностью протестировавшей продукт. Для этого вы можете воспользоваться EPL.

Процесс оценки является очень трудоемким и дорогостоящим для производителя. Не каждый производитель проводит свои продукты через это, поскольку это дорого и, к тому же, отодвигает дату выпуска продукта на рынок. Обычно, производитель проводит свои продукты через этот процесс, только если основная часть его потенциальных покупателей ориентируется на рейтинг гарантий при выборе продукта. В США Министерство обороны является самым крупным покупателем, поэтому многие производители проводят свои основные продукты через процесс оценки, в надежде, что их купит Министерство обороны (или кто-то другой).

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

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

TCSEC предоставляет систему классификации, иерархически разделенную на следующие уровни гарантий:

  • А – Проверенная защита (verified protection)
  • B – Мандатная защита (mandatory protection)
  • C – Дискреционная защита (discretionary protection)
  • D – Минимальная безопасность (minimal security)
Уровень классификации «А» представляет собой максимальный уровень гарантий, «D» – минимальный.

Каждый уровень может иметь один или несколько пронумерованных классов с соответствующими наборами требований, которые должны выполняться системой для достижения этого конкретного рейтинга. Классы с более высокими номерами предоставляют более высокую степень доверия и гарантий. Так, например, класс «B2» более доверенный, чем класс «B1».

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

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

Каждый уровень и класс включает в себя требования предыдущего уровня или класса. Это означает, что «C2» должен соответствовать требованиям своих критериев, а также всем требованиям критериев «C1», а «B3» помимо своих требований должен удовлетворять требованиям «C1», «C2», «B1» и «B2». Каждый уровень или класс вносит свой вклад в требования безопасности и ожидает выполнения всех требований всех предыдущих классов и разделов.

Разве Оранжевая книга еще актуальна? Мы перешли от Оранжевой книги к Общим критериям, поэтому возникает резонный вопрос – зачем изучать Оранжевую книгу? Сам по себе факт перехода не сделал Оранжевую книгу неважной. Это была первая эволюция критериев, и она использовалась 20 лет. Многие основные термины и концепции произошли из Оранжевой книги. И у нас все еще есть много продуктов с рейтингами Оранжевой книги, которые, в конечном счете, пройдут оценку по Общим критериям.Экзамен CISSP неуклонно переходит от Оранжевой книги к Общим критериям, но этот переход еще не завершен.

Уровень D: Минимальная защита

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

Уровень С: Дискреционная защита

Уровень «C» содержит два отдельных класса рейтинга гарантий, которые описаны далее. Более высокий номер рейтинга гарантий означает более высокий уровень защиты.

C1: Дискреционное обеспечение безопасности (Discretionary Security Protection). Дискреционное управление доступом основано на отдельных людях и/или группах. Оно требует разделения пользователей и информации, проведения идентификации и аутентификации отдельных сущностей. Управление доступом необходимо, чтобы пользователи могли быть уверены, что их данные не могут быть получены или повреждены неуполномоченными лицами. Архитектура системы должна обеспечивать защищенный домен выполнения, обеспечивающий невозможность негативного воздействия на привилегированные системные процессы со стороны менее привилегированных процессов. Должны существовать определенные способы проверки функциональной целостности системы. Требования к документации включают обязательное наличие конструкторской документации, показывающей, как защитные механизмы встроены в систему, документации по тестированию (планы и результаты тестирования), описания возможностей системы, позволяющие покупателю понять, как правильно установить и настроить систему, а также учебную документацию для пользователей.

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

C2: Управляемая защита доступа (Controlled Access Protection). Пользователи должны быть индивидуально идентифицированы для обеспечения более точного управления доступом и функций аудита. Механизмы логического управления доступом используются для выполнения аутентификации и однозначной идентификации каждого пользователя. Существенные с точки зрения безопасности события журналируются, записи о них защищены от несанкционированной модификации. Архитектура должна обеспечивать изоляцию ресурсов (или объектов), предоставляя надежную защиту, а также надлежащим образом журналировать любые производимые с ними действия. Должна применяться концепция обеспечения безопасности при повторном использовании объектов, предусматривающая, что в любом хранилище данных не должно оставаться остаточной информации после его освобождения для возможности использования другим субъектом. Например, если субъект использует сегмент памяти, то после окончания его использования, этот сегмент не должен содержать никакой информации. Это справедливо для носителей информации, используемых объектов, создаваемых временных файлов – все данные должны эффективно затираться, когда субъект перестает использовать это хранилище.

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

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

Уровень B: Мандатная защита

Мандатное управление доступом реализуется посредством использования меток безопасности. Архитектура основана на модели безопасности Bell-LaPadula, должны быть доступны доказательства реализации монитора обращений.

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

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

ПРИМЕЧАНИЕ. Метки безопасности не требуются при рейтинге безопасности ниже «В». Поэтому например, «С2» не требует меток безопасности, а «В1» – требует.B2: Структурированная защита (Structured Protection). Политика безопасности явно определена и документирована, структура системы и ее реализация подвергнуты исчерпывающему анализу и детальным тестовым процедурам. Этот класс требует наличия более строгих механизмов аутентификации и строго определенных интерфейсов между уровнями. Субъекты и устройства требуют наличия меток, а система не должна допускать наличия скрытых каналов. Должен существовать доверенный способ (trusted path) входа в систему и прохождения аутентификации, который обеспечивает прямое взаимодействие субъектов с приложениями или операционной системой, а также отсутствием недокументированных способов доступа (backdoor, trapdoor). Отсутствуют способы обхода или компрометации этого доверенного коммуникационного канала. Существует разделение функций администратора и оператора в рамках системы для обеспечения более доверенного и защищенного функционирования. Должно быть обеспечено отдельное адресное пространство для изоляции процессов и проведен анализ скрытых каналов. Этот класс увеличивает гарантии, расширяя требования к структуре системы.

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

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

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

Уровень A: Проверенная защита

Формальные методы используются для обеспечения того, что все субъекты и объекты управляются средствами дискреционного и мандатного управления доступом. Проектирование, разработка, внедрение и документация рассматриваются формально и детально. Механизмы безопасности систем «В3» и «А1» отличаются несильно, но в «А1» применяются гораздо более структурированные и строгие процедуры оценки способов проектирования и разработки системы.

A1: Проверенная структура (Verified Design). Архитектура и возможности защиты не сильно отличаются от систем с рейтингом «В3», но гарантии систем «А1» выше, чем систем «В3», из-за более формального подхода к проектированию системы «А1», разработки ее технических требований и более детальной техники проведения проверки. Для проверки эквивалентности между техническими требованиями ТСВ и моделью политики безопасности используются формальные техники. При разработке систем «А1» реализуется более строгое изменение конфигурации, может быть проверена структура в целом. Часто даже способ доставки системы заказчику внимательно исследуется, чтобы убедиться в отсутствии компрометации системы до ее внедрения в работу.

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

ПРИМЕЧАНИЕ. TCSEC учитывает конфиденциальность, но не целостность. Функциональность механизмов безопасности и гарантии этих механизмов не оцениваются раздельно, они комбинируются и оцениваются как одно целое.Ссылки по теме: Оранжевая книга в основном учитывает правительственные и военные требования и ожидания для их компьютерных систем. Многие люди видят определенные недостатки в Оранжевой книге в части безопасности, особенно когда применяют эти требования в коммерческой области, а не военной организации. Ниже перечислены основные проблемы, возникающие у практиков при использовании Оранжевой книги:
  • Она применима к операционным системам, но не другим системам, таким как сети, базы данных и т.д.
  • Она фокусируется в основном на одном атрибуте безопасности – конфиденциальности, но не учитывает целостность и доступность.
  • Она работает с правительственной классификацией, а не с классификацией, применяемой в коммерческих компаниях.
  • Она имеет относительно небольшое количество рейтингов, в связи с чем множество различных аспектов безопасности не оцениваются независимо.
Оранжевая книга концентрируется на контроле того, как пользователи получают доступ к информации, но игнорирует контроль того, что они делают с ней после авторизации, хотя авторизованный пользователь имеет возможность нанести (и обычно наносит) больше вреда, чем внешний атакующий. Коммерческие компании больше заботятся о целостности и доступности своих данных, а военные организации ставят во главу угла конфиденциальность. В связи с этим различием целей Оранжевая книга идеально подходит только для оценки средств для правительственных и военных систем.

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

Для пояснения каждой книги и ее использования, пожалуйста, ознакомьтесь со следующими ссылками.

Ссылки по теме:

Оранжевая книга учитывает односистемную безопасность, но сети являются комбинацией систем, и каждая сеть нуждается в обеспечении безопасности, не требуя при этом полного доверия от всех и каждой подключенных к ней систем. Трактовка доверенных сетей (TNI – Trusted Network Interpretation), также называемая Красной книгой, учитывает аспекты оценки безопасности для сети и сетевых компонентов. Она учитывает изолированные локальные (LAN) сети и глобальные сети (WAN).

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

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

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

Ниже приведен перечень вопросов безопасности, учтенных в Красной книге:

• Целостность коммуникаций

  • Аутентификация. Защищает от атак маскарадинга и повторного воспроизведения (playback attack). Механизмы включают цифровую подпись, шифрование, штампы времени и пароли.
  • Целостность сообщений. Защищает заголовок протокола, информацию маршрутизации и содержимое пакета от модификации. Механизмы включают аутентификацию и шифрование сообщений.
  • Невозможность отказа от авторства. Гарантирует, что отправитель не может отказаться от факта отправки сообщения. Механизмы включают шифрование, цифровую подпись и подтверждение подлинности (notarization).
• Предотвращение отказа в обслуживании
  • Непрерывность деятельности. Обеспечивает доступность сети даже в случае атаки. Механизмы включают применение отказоустойчивых и избыточных систем, а также средства перенастройки сетевых параметров в случае аварийной ситуации.
  • Управление сетью. Мониторинг производительности сети, выявление атак и сбоев. Механизмы включают компоненты, позволяющие сетевому администратору отслеживать и ограничивать доступ к ресурсам.
• Защита от компрометации
  • Конфиденциальность данных. Защищает данные от неавторизованного доступа в процессе передачи. Механизмы включают управление доступом, шифрование и физическую защиту кабелей.
  • Конфиденциальность потока трафика. Предотвращает неавторизованный доступ к информации о маршрутизации или частоте выполнения коммуникаций посредством анализа трафика. Механизмы включают «разбавление» (padding) сообщений, отправку «шума» и «ложных» сообщений.
  • Избирательная маршрутизация. Маршрутизирует сообщения способом, исключающим некоторые специфические угрозы. Механизмы включают конфигурацию сети и таблицы маршрутизации.
Оценка гарантий производится путем сравнения реальной работы продукта с теоретической – как он должен работать, а также путем тестирования конфигураций во множестве различных сценариев, оценки практик создания системы, проверки заявлений безопасности и их обоснованности.

TCSEC введен в 1985 году и отменен в декабре 2000 года. Это был первый методический и логичный набор стандартов разработки безопасных компьютерных систем. Он оказал большое влияние на многие страны, которые разработали свои стандарты оценки на основе рекомендаций TCSEC. В конечном итоге TCSEC был заменен Общими критериями.

ITSEC (Information Technology Security Evaluation Criteria) – это первая попытка создания единого стандарта для оценки атрибутов безопасности компьютерных систем и продуктов рядом европейских стран. США использовали Оранжевую книгу и Радужную серию, а Европа применяла ITSEC для оценки и установки рейтингов компьютерных систем. (Сегодня все мигрировали на Общие критерии, описанные в следующем разделе).

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

Возможно существование двух защитных механизмов систем, предоставляющих одинаковый тип функциональности, но имеющих существенно различающийся уровень гарантий. Это связано с тем, что предоставляющие функциональность механизмы были разработаны, спроектированы и внедрены по-разному. Например, системы А и В могут иметь защитные механизмы, предоставляющие одинаковую функциональность аутентификации, и в этих условиях оба продукта имеют одинаковый рейтинг по функциональности. Но разработчики системы А были неряшливы и беззаботны при разработке механизма аутентификации и поэтому их продукт получил меньший рейтинг по уровню гарантий. ITSEC разделяет эти два атрибута (функциональность и гарантии) и присваивает им рейтинг по-отдельности, тогда как TCSEC рассматривает их совместно и присваивает им один рейтинг (от «D» до «A1»).

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

  • Требования к функционалу безопасности
  • Идентификация и аутентификация
  • Аудит
  • Использование ресурсов
  • Доверенные пути/каналы
  • Защита пользовательских данных
  • Управление безопасностью
  • Доступ к продукту
  • Коммуникации
  • Защита персональных данных
  • Защита функций безопасности продукта
  • Поддержка криптографии
  • Требования к гарантиям безопасности
  • Инструкции и руководства
  • Управление конфигурациями
  • Оценка уязвимостей
  • Доставка и функционирование
  • Поддержка жизненного цикла
  • Обеспечение гарантий
  • Разработка
  • Тестирование
Рассмотрим снова наш пример, когда две системы предоставляют одинаковую функциональность (в отношении механизмов защиты), но имеют различный уровень гарантий. Используя подход TCSEC, различия в уровне гарантий сложно увидеть, т.к. функциональность и гарантии рассматриваются совместно. В подходе ITSEC рейтинг функциональности присваивается отдельно от гарантий, делая отличия в уровне гарантий более заметными. В критериях ITSEC классы рейтинга «F1» – «F10» относятся к функциональности механизмов безопасности, а «Е0» – «Е6» – к гарантиям этих механизмов.

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

Таблица 3-2 показывает взаимосвязь между двумя схемами оценки.

Таблица 3-2. Связь между ITSEC и TCSEC

Как вы могли заметить, большинство рейтингов ITSEC связаны с рейтингами TCSEC, но в ITSEC добавлены рейтинги «F6» – «F10» для специфических нужд потребителей, которые TCSEC не учитывает.

ITSEC – это критерии для операционных систем и других продуктов, которые рассматриваются как отдельные объекты оценки (TOE – Target of Evaluation). Поэтому, если вы читаете литературу, обсуждающую ITSEC-рейтинги продуктов, и в ней заявлено, что ТОЕ имеет рейтинг «F1» и «Е5», вы знаете, что ТОЕ – это продукт, который был оценен и что он указывает на низкий рейтинг функциональности и высокий рейтинг гарантий.

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

Ссылки по теме:

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

В 1990 году Международная организация по стандартизации (ISO – International Organization for Standardization) выявила наличие потребности в международном стандарте критериев оценки, который мог бы использоваться в глобальных масштабах. Проект по созданию Общих критериев стартовал в 1993 году, когда несколько организаций собрались для объединения и согласования существующих и разрабатываемых критериев оценки (TCSEC, ITSEC, CTCPEC и Федеральных критериев). В результате сотрудничества между национальными организациями по стандартизации США, Канады, Франции, Германии, Великобритании и Нидерландов были разработаны Общие критерии.

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

Оранжевая книга оценивает все системы на соответствие модели Bell-LaPadula. Общие критерии предоставляют значительно большую гибкость, оценивая продукты на соответствие профилям защиты, которые структурированы для учета потребностей безопасности в реальном мире. Так, если Оранжевая книга говорит: "Все марш в этом направлении, в этой форме и по этому пути!", Общие критерии спрашивают: "Так, какие угрозы сегодня стоят перед нами и каков лучший вариант борьбы с ними?".

В модели Общих критериев выполняется оценка продукта, после чего ему присваивается Оценочный уровень гарантий (EAL – Evaluation Assurance Level). Исчерпывающее и строгое тестирование, основанное на ориентированных на детали задачах, повышает уровень гарантий. Общие критерии имеют семь уровней гарантий в диапазоне от «EAL1», где проводится тестирование функциональности, до «EAL7», где выполняется исчерпывающее тестирование и проверяется структура системы. Различные пакеты EAL приведены в списке:

  • EAL 1. Функционально протестировано
  • EAL 2. Структурно протестировано
  • EAL 3. Методически протестировано и сверено
  • EAL 4. Методически проработано, протестировано и проанализировано
  • EAL 5. Полуформально проработано и протестировано
  • EAL 6. Полуформально проработано и протестировано с подтверждением
  • EAL 7. Формально проработано и протестировано с подтверждением
ПРИМЕЧАНИЕ. Если система является «формально проработанной», это означает, что она основана на модели, которая может быть математически доказана.Общие критерии используют профили защиты в процессе оценки. Это механизм, который используется для описания потребностей реального мира в отношении продуктов, которые сейчас отсутствуют на рынке. Профиль защиты содержит набор требований по безопасности, их смысл и обоснования, а также соответствующий рейтинг EAL, который требуется для продукта. Профиль защиты описывает предположения о среде, цели, ожидаемый уровень функциональности и гарантий. Каждая существенная угроза указывается с пояснениями, как она должна контролироваться посредством конкретных задач. Профиль защиты также обосновывает уровень гарантий и требования к стойкости каждого защитного механизма.

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

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

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

Профиль защиты содержит следующие пять разделов:

  • Описательные элементы. Указывает название профиля и описание проблемы безопасности, которая должна быть решена.
  • Логическое обоснование. Обосновывает профиль и дает более детальное описание реальной проблемы, которая должна быть решена. Предполагаемые среда и порядок использования, а также угрозы, показываются вместе с описанием политик безопасности, которые должен поддерживать продукт или система, чтобы соответствовать данному профилю.
  • Функциональные требования. Устанавливают границы защиты, означающие, что угрозы или компрометации в рамках этих границ должны быть предотвращены. Продукт или система должны реализовать границы, установленные в этом разделе.
  • Требования к гарантиям разработки. Идентифицирует конкретные требования, которым продукт или система должны удовлетворять на этапе разработки – от момента начала проектирования до момента внедрения.
  • Требования к оценке гарантий. Устанавливают тип и интенсивность оценки.
Процесс оценки – это только один этап определения функциональности и гарантий продукта. Если продукт достиг некоторого рейтинга, это применимо только для этой конкретной версии и только для определенной конфигурации продукта. Таким образом, если компания покупает межсетевой экран, предоставляющий высокий рейтинг гарантий, она не имеет гарантий, что следующая версия его программного обеспечения будет иметь такой же рейтинг. Следующая версия должна будет пройти через процесс пересмотра оценки. С другой стороны, если компания купила межсетевой экран и установила его с конфигурацией, которая не была рекомендована, уровень безопасности, которого хотела достичь компания, может снизиться. Таким образом, все эти рейтинги являются формализованным методом обзора систем в процессе их оценки в лаборатории. Когда продукт внедрен в реальную среду, все факторы, отличающиеся от использовавшихся при установке рейтинга, должны быть учтены и оценены для обеспечения надлежащей защиты ресурсов и окружения.ПРИМЕЧАНИЕ. Когда продукту присвоен рейтинг гарантий, это означает, что потенциально он может обеспечить этот уровень защиты. Покупатель должен правильно настроить продукт, чтобы реально получить этот уровень защиты. Производитель должен предоставить необходимую документацию по настройке и объяснить покупателю, как правильно настроить продукт и сохранить правильную настройку в течение всего времени его эксплуатации.Различные компоненты Общих критериев перечислены и описаны ниже:
  • Профиль защиты. Описание необходимого решения безопасности.
  • Объект оценки. Продукт, который предлагается в качестве необходимого решения безопасности.
  • Цель безопасности. Написанное разработчиком пояснение функциональности и гарантий безопасности, реализованных необходимым решением безопасности; другими словами: «это то, что наш продукт делает и как он это делает».
  • Пакеты EAL. Требования в отношении гарантий и функциональности, объединенные в пакет для повторного использования. Этот компонент описывает, что должно быть учтено для достижения продуктом определенного рейтинга EAL.
Ссылки по теме:

dorlov.blogspot.com

IRONZONE Статьи

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

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

Надежность систем оценивается по двум основным критериям:

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

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

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

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

От монитора обращений требуется выполнение трех свойств:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Критерии оценки безопасности компьютерных систем" Министерства обороны США открыли путь к ранжированию информационных систем по степени надежности. В "Оранжевой книге" определяется четыре уровня надежности (безопасности) - D, C, B и A. Уровень D предназначен для систем, признанных неудовлетворительными. В настоящее время он пуст, и ситуация едва ли когда-нибудь изменится. По мере перехода от уровня C к A к надежности систем предъявляются все более жесткие требования. Уровни C и B подразделяются на классы (C1, C2, B1, B2, B3) с постепенным возрастанием надежности. Таким образом, всего имеется шесть классов безопасности - C1, C2, B1, B2, B3, A1. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять приводимым ниже требованиям. Поскольку при переходе к каждому следующему классу требования только добавляются, будем говорить лишь о том новом, что присуще данному классу, группируя требования в согласии с предшествующим изложением.

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

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

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

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

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

Класс C2 - в дополнение к C1, права доступа должны гранулироваться с точностью до пользователя. Механизм управления должен ограничивать распространение прав доступа - только авторизованный пользователь, например владелец объекта, может предоставлять права доступа другим пользователям. Все объекты должны подвергаться контролю доступа.

Класс B3 - в дополнение к C2, обязательно должны использоваться списки управления доступом с указанием разрешенных режимов. Должна быть возможность явного указания пользователей или их групп, доступ которых к объекту запрещен.

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

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

Класс C2 - при выделении хранимого объекта из пула ресурсов вычислительной базы необходимо ликвидировать все следы предыдущих использований.

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

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

Класс B2 - в дополнение к B1, помечаться должны все ресурсы системы, например ПЗУ, прямо или косвенно доступные субъектам.

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

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

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

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

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

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

Класс B2 - в дополнение к B1, все ресурсы системы (в том числе ПЗУ, устройства ввода/вывода) должны иметь метки безопасности и служить объектами принудительного управления доступом.

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

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

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

Класс C2 - в дополнение к C1, каждый пользователь системы должен уникальным образом идентифицироваться. Каждое регистрируемое действие должно связываться с конкретным пользователем.

Класс B1 - в дополнение к C2, вычислительная база должна поддерживать метки безопасности пользователей.

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

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

Класс B3 - в дополнение к B2, коммуникационный путь может формироваться по запросу, исходящему как от пользователя, так и от самой базы. Надежный путь может использоваться для начальной идентификации и аутентификации, для изменения текущей метки безопасности пользователя и т.п. Общение по надежному пути должно быть логически отделено и изолировано от других информационных потоков.

Аудит:

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

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

Каждая регистрационная запись должна включать следующие поля:

  • дата и время события;
  • идентификатор пользователя;
  • тип события;
  • результат действия (успех или неудача).

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

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

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

Класс B2 - в дополнение к B1, должна быть возможность регистрировать события, связанные с организацией тайных каналов с памятью.

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

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

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

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

Класс C2 - в дополнение к C1, вычислительная база должна изолировать защищаемые ресурсы в той мере, как это диктуется требованиями контроля доступа и подотчетности.

Класс B1 - в дополнение к C2, вычислительная база должна обеспечивать взаимную изоляцию процессов путем разделения их адресных пространств.

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

Класс B3 - в дополнение к B2, вычислительная база должна быть спроектирована и структурирована таким образом, чтобы использовать полный и концептуально простой защитный механизм. Этот механизм должен играть центральную роль во внутренней структуризации вычислительной базы и всей системы. База должна активно использовать разделение данных по уровням. Значительные инженерные усилия должны быть направлены на уменьшение сложности вычислительной базы и на вынесение из нее модулей, не являющихся критически важными с точки зрения защиты.

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

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

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

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

Класс B3 - в дополнение к B2, аналогичная процедура должна быть проделана для временных каналов.

Класс A1 - в дополнение к B3, для анализа должны использоваться формальные методы.

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

Класс B2 - система должна поддерживать разделение функций оператора и администратора.

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

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

Класс B3 - должны существовать процедуры и/или механизмы, позволяющие произвести восстановление после сбоя или иного нарушения работы без ослабления защиты.

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

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

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

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

Класс B2 - в дополнение к B1, должна быть продемонстрирована относительная устойчивость вычислительной базы к попыткам проникновения.

Класс B3 - в дополнение к B2, должна быть продемонстрирована устойчивость вычислительной базы к попыткам проникновения.

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

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

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

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

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

Класс B3 - в дополнение к B2, должны быть приведены убедительные аргументы соответствия между спецификациями и моделью.

Класс A1 - в дополнение к B3, помимо описательных должны быть представлены формальные спецификации верхнего уровня, относящиеся к аппаратным и/или микропрограммным элементам, составляющим интерфейс вычислительной базы. Комбинация формальных и неформальных методов должна подтвердить соответствие между спецификациями и моделью. Должны использоваться современные методы формальной спецификации и верификации систем, доступные Национальному центру компьютерной безопасности США.

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

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

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

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

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

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

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

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

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

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

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

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

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

Класс B3 - в дополнение к B2, должна быть описана процедура, обеспечивающая безопасность начального запуска системы и возобновления ее работы после сбоя.

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

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

Класс B2 - в дополнение к C1, тесты должны подтверждать действенность мер по уменьшению пропускной способности тайных каналов передачи информации.

Класс A1 - в дополнение к B2, должно быть описано соответствие между формальными спецификациями верхнего уровня и исходными текстами.

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

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

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

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

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

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

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

ironzone.ucoz.net

13.2. Критерии безопасности компьютерных систем министерства обороны сша ("Оранжевая книга")

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

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

13.2.1. Таксономия требований и критериев "Оранжевой книги"

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

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

Требование 2. Метки. С объектами должны быть ассоциированы метки безопасности, используемые в качестве атрибутов контроля доступа. Для реализации нормативного управления доступом система должна обеспечивать возможность присваивать каждому объекту метку или набор атрибутов, определяющих степень конфиденциальности (гриф секретности) объекта и/или режимы доступа к этому объекту.

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

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

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

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

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

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

studfiles.net

Радужная серия — Википедия

Материал из Википедии — свободной энциклопедии

Радужная серия (Радужные книги) — серия стандартов информационной безопасности, разработанная и опубликованная в США в период с 1980 по 1990 гг. Изначально книги были опубликованы Министерством обороны США, а затем в Центре национальной компьютерной безопасности США.

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

В книге под названием «Прикладная криптография» эксперт по информационной безопасности Брюс Шнайер, автор NCSC-TG-021, писал, что он «не может даже начать описывать цвет обложки», и что некоторые из книг этой серии имеют «ужасно цветные обложки». Затем он переходит к описанию, как получить их копию, говоря: «Не говорите никому, что это я прислал»[1].

NIST Радужная серия Документ
Название Дата Цвет
5200.28-STD Критерии определения безопасности компьютерных систем 15 августа 1983 Оранжевая книга     
CSC-STD-002-85 Руководящие принципы использования паролей 12 апреля 1985 Зелёная книга     
CSC-STS-003-85 Руководство по применению критериев определения безопасности компьютерных систем в конкретных условиях 25 июня 1985 Светло-жёлтая книга

ru.wikipedia.org

"Оранжевая книга" США — контрольная работа

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

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

Класс C2 - в дополнение к C1, права доступа должны гранулироваться  с точностью до пользователя. Механизм управления должен ограничивать распространение  прав доступа - только авторизованный пользователь, например владелец объекта, может предоставлять права доступа  другим пользователям. Все объекты  должны подвергаться контролю доступа.

Класс B3 - в дополнение к C2, обязательно должны использоваться списки управления доступом с указанием  разрешенных режимов. Должна быть возможность  явного указания пользователей или  их групп, доступ которых к объекту  запрещен.

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

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

Класс C2 - при выделении  хранимого объекта из пула ресурсов вычислительной базы необходимо ликвидировать  все следы предыдущих использований.

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

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

Класс B2 - в дополнение к B1, помечаться должны все ресурсы  системы, например ПЗУ, прямо или  косвенно доступные субъектам.

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

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

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

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

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

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

Класс B2 - в дополнение к B1, все ресурсы системы (в том  числе ПЗУ, устройства ввода/вывода) должны иметь метки безопасности и служить объектами принудительного  управления доступом.

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

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

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

Класс C2 - в дополнение к C1, каждый пользователь системы должен уникальным образом идентифицироваться. Каждое регистрируемое действие должно связываться с конкретным пользователем.

Класс B1 - в дополнение к C2, вычислительная база должна поддерживать метки безопасности пользователей.

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

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

Класс B3 - в дополнение к B2, коммуникационный путь может формироваться  по запросу, исходящему как от пользователя, так и от самой базы. Надежный путь может использоваться для начальной  идентификации и аутентификации, для изменения текущей метки безопасности пользователя и т.п. Общение по надежному пути должно быть логически отделено и изолировано от других информационных потоков.   

Аудит:

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

использование механизма  идентификации и аутентификации;

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

удаление объектов;

действия системных  операторов, системных администраторов, администраторов безопасности;

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

Каждая регистрационная  запись должна включать следующие поля:

дата и время  события;

идентификатор пользователя;

тип события;

результат действия (успех или неудача).

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

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

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

Класс B2 - в дополнение к B1, должна быть возможность регистрировать события, связанные с организацией тайных каналов с памятью.

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

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

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

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

Класс C2 - в дополнение к C1, вычислительная база должна изолировать  защищаемые ресурсы в той мере, как это диктуется требованиями контроля доступа и подотчетности.

Класс B1 - в дополнение к C2, вычислительная база должна обеспечивать взаимную изоляцию процессов путем  разделения их адресных пространств.

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

Класс B3 - в дополнение к B2, вычислительная база должна быть спроектирована и структурирована таким образом, чтобы использовать полный и концептуально  простой защитный механизм. Этот механизм должен играть центральную роль во внутренней структуризации вычислительной базы и всей системы. База должна активно  использовать разделение данных по уровням. Значительные инженерные усилия должны быть направлены на уменьшение сложности  вычислительной базы и на вынесение  из нее модулей, не являющихся критически важными с точки зрения защиты.

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

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

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

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

Класс B3 - в дополнение к B2, аналогичная процедура должна быть проделана для временных каналов.

Класс A1 - в дополнение к B3, для анализа должны использоваться формальные методы.

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

Класс B2 - система  должна поддерживать разделение функций  оператора и администратора.

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

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

Класс B3 - должны существовать процедуры и/или механизмы, позволяющие  произвести восстановление после сбоя или иного нарушения работы без  ослабления защиты.

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

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

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

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

Класс B2 - в дополнение к B1, должна быть продемонстрирована относительная  устойчивость вычислительной базы к попыткам проникновения.

Класс B3 - в дополнение к B2, должна быть продемонстрирована устойчивость вычислительной базы к попыткам проникновения.

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

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

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

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

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

Класс B3 - в дополнение к B2, должны быть приведены убедительные аргументы соответствия между спецификациями и моделью.

Класс A1 - в дополнение к B3, помимо описательных должны быть представлены формальные спецификации верхнего уровня, относящиеся к аппаратным и/или микропрограммным элементам, составляющим интерфейс вычислительной базы. Комбинация формальных и неформальных методов должна подтвердить соответствие между спецификациями и моделью. Должны использоваться современные методы формальной спецификации и верификации систем, доступные Национальному центру компьютерной безопасности США.

freepapers.ru

Лабораторная работа № 2

“Критерии безопасности компьютерных систем министерства обороны США ("Оранжевая книга")"

Цель работы:

Изучить стандарт информационной безопасности “Критерии безопасности компьютерных систем министерства обороны США ("Оранжевая книга")”.

1. Теоретическое введение

1.1. Цель разработки

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

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

1.2. Таксономия требований и критериев "Оранжевой книги"

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

1.2.1 Политика безопасности

Требование 1. Политика безопасности. Система должна поддер­живать точно определенную политику безопасности. Возможность осуще­ствления субъектами доступа к объектам должна определяться на основа­нии их идентификации и набора правил управления доступом. Там, где необходимо, должна использоваться политика нормативного управления доступом, позволяющая эффективно реализовать разграничение доступа к категорированной информации (информации, отмеченной грифом секрет­ности — типа "секретно", "сов. секретно" и т.д.).

Требование 2. Метки. С объектами должны быть ассоциированы метки безопасности, используемые в качестве атрибутов контроля досту­па. Для реализации нормативного управления доступом система должна обеспечивать возможность присваивать каждому объекту метку или набор атрибутов, определяющих степень конфиденциальности (гриф секретно­сти) объекта и/или режимы доступа к этому объекту.

1.2.2 Аудит

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

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

1.2.3 Корректность

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

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

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

1.2.4. Таксономия критериев безопасности

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

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

studfiles.net

Информационная безопасность | Открытые системы. СУБД

Управление нотаризацией (распространение информации о нотариальных службах, администрирование этих служб).

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

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

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

Интерпретация

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

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

Чтобы понять суть положений, вошедших в первую часть, рассмотрим интерпретацию требований к классу безопасности С2. Первое требование - это поддержка добровольного управления доступом. "Интерпретация" предусматривает различные варианты распределения сетевой надежной вычислительной базы по компонентам и, соответственно, различные варианты распределения механизмов управления доступом. В частности, некоторые компоненты, закрытые от прямого доступа пользователей (например, коммутаторы пакетов, оперирующие на третьем уровне семиуровневой модели OSI), могут вообще не содержать подобных механизмов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новые сервисы безопасности и защитные механизмы

Рассматриваемый документ создавался примерно в то же время, что и Рекомендации Х.800. Естественно, что две рабочие группы обменивались информацией, поэтому во многих отношениях их подходы схожи. Имеются, однако, и важные различия. "Интерпретация" не замыкается на эталонной семиуровневой модели, ее цель - оценка безопасности всей распределенной конфигурации, а не только чисто сетевых аспектов. Рекомендации Х.800 в основном имеют дело с функциональностью (с сервисами безопасности) и в меньшей степени - с защитными механизмами. В части 2 "Интерпретации" анализируется еще одна важнейшая характеристика - гарантированность.

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

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

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

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

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

протоколирование и аудит.

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

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

Истинность этого утверждения непосредственно следует из определения монитора обращений.

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

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

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

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

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

www.osp.ru