Стандартизация в области информационной безопасности в сетях передачи данных

ТЕМА_2_CиСРиСИЗ 1,2,3,4

Стандартизация в области информационной безопасности в сетях передачи данных

1. Роль стандартов и спецификаций. Наиболее важные стандарты и спецификации в области информационной безопасности

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

Формальная состоит в том, что необходимость следования некоторым стандартам (например, криптографическим и/или Руководящим документам Гостехкомиссии России) закреплена законодательно. Однако наиболее убедительны содержательные причины. Во-первых, стандарты и спецификации - одна из форм накопления знаний, прежде всего о процедурном и программно-техническом уровнях ИБ. В них зафиксированы апробированные, высококачественные решения и методологии, разработанные наиболее квалифицированными специалистами. Во-вторых, и те, и другие являются основным средством обеспечения взаимной совместимости аппаратно-программных систем и их компонентов, причем в Internet-сообществе это средство действительно работает, и весьма эффективно.

Отмеченная роль стандартов зафиксирована в основных понятиях закона РФ "О техническом регулировании" от 27 декабря 2002 года под номером 184-ФЗ (принят Государственной Думой 15 декабря 2002 года):

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

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

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

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

На верхнем уровне можно выделить две существенно отличающиеся друг от друга группы стандартов и спецификаций:

1. оценочные стандарты, предназначенные для оценки и классификации информационных систем и средств защиты по требованиям безопасности;

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

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

Из числа оценочных необходимо выделить стандарт Министерства обороны США "Критерии оценки доверенных компьютерных систем" и его интерпретацию для сетевых конфигураций, "Гармонизированные критерии Европейских стран", международный стандарт "Критерии оценки безопасности информационных технологий" и, конечно, Руководящие документы Гостехкомиссии России. К этой же группе относится и Федеральный стандарт США "Требования безопасности для криптографических модулей", регламентирующий конкретный, но очень важный и сложный аспект информационной безопасности.

Технические спецификации, применимые к современным распределенным ИС, создаются, главным образом, "Тематической группой по технологии Internet" (Internet Engineering Task Force, IETF) и ее подразделением - рабочей группой по безопасности. Ядром рассматриваемых технических спецификаций служат документы по безопасности на IP-уровне (IPsec). Кроме этого, анализируется защита на транспортном уровне (Transport Layer Security, TLS), а также на уровне приложений (спецификации GSS-API, Kerberos). Необходимо отметить, что Internet-сообщество уделяет должное внимание административному и процедурному уровням безопасности ("Руководство по информационной безопасности предприятия", "Как выбирать поставщика Интернет-услуг", "Как реагировать на нарушения информационной безопасности").

В вопросах сетевой безопасности невозможно разобраться без освоения спецификаций X.800 "Архитектура безопасности для взаимодействия открытых систем", X.500 "Служба директорий: обзор концепций, моделей и сервисов" и X.509 "Служба директорий: каркасы сертификатов открытых ключей и атрибутов".

Британский стандарт BS 7799 "Управление информационной безопасностью. Практические правила", полезный для руководителей организаций и лиц, отвечающих за информационную безопасность, без сколько-нибудь существенных изменений воспроизведен в международном стандарте ISO/IEC 17799.

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

Краткие сведения о стандартах и спецификациях, не являющихся предметом данного курса.

Упоминаемые в данном разделе стандарты и спецификации детально рассмотрены в курсе "Основы информационной безопасности" и в книге "Информационная безопасность - практический подход" [ИБПП]. Только по этой причине они не включены в настоящий курс в качестве предмета изучения.

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

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

После "Оранжевой книги" была выпущена целая "Радужная серия". С концептуальной точки зрения, наиболее значимый документ в ней - "Интерпретация "Оранжевой книги" для сетевых конфигураций" (Trusted Network Interpretation, [TNI]). Он состоит из двух частей. Первая содержит собственно интерпретацию, во второй описываются сервисы безопасности, специфичные или особенно важные для сетевых конфигураций.

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

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

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

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

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

Важно указание и на различие между функциями (сервисами) безопасности и реализующими их механизмами, а также выделение двух аспектов гарантированности - эффективности и корректности средств безопасности. Руководящие документы (РД) Гостехкомиссии России [GTKRD1-GTKRDn] начали появляться несколько позже, уже после опубликования "Гармонизированных критериев", и, по аналогии с последними, подтверждают разницу между автоматизированными системами (АС) и продуктами (средствами вычислительной техники, СВТ), но в общем и целом они долгое время следовали в фарватере "Оранжевой книги".

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

В 2002 году Гостехкомиссия России приняла в качестве РД русский перевод [GTKRDCC] международного стандарта ISO/IEC 15408:1999 "Критерии оценки безопасности информационных технологий" [ECITS1-ECITS3], что послужило толчком для кардинальной и весьма своевременной со всех точек зрения переориентации (вспомним приведенный выше принцип стандартизации из закона "О техническом регулировании"). Конечно, переход на рельсы "Общих критериев" будет непростым, но главное, что он начался.

Среди технических спецификаций на первое место, безусловно, следует поставить документ X.800 "Архитектура безопасности для взаимодействия открытых систем" [X800]. Здесь выделены важнейшие сетевые сервисы безопасности: аутентификация, управление доступом, обеспечение конфиденциальности и/или целостности данных, а также невозможность отказаться от совершенных действий. Для реализации сервисов предусмотрены следующие сетевые механизмы безопасности и их комбинации: шифрование, электронная цифровая подпись (ЭЦП), управление доступом, контроль целостности данных, аутентификация, дополнение трафика, управление маршрутизацией, нотаризация. Выбраны уровни эталонной семиуровневой модели, на которых могут быть реализованы сервисы и механизмы безопасности. Наконец, детально рассмотрены вопросы администрирования средств безопасности для распределенных конфигураций.

Спецификация Internet-сообщества RFC 1510 "Сетевой сервис аутентификации Kerberos (V5)" [Kerb] относится к более частной, но весьма важной и актуальной проблеме - аутентификации в разнородной распределенной среде с поддержкой концепции единого входа в сеть. Сервер аутентификации Kerberos представляет собой доверенную третью сторону, владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности. О весомости данной спецификации свидетельствует тот факт, что клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем. Далее предполагается, что читатель свободно разбирается в особенностях охарактеризованных выше стандартов и спецификаций.

Краткие аннотации подробно рассматриваемых в курсе стандартов и спецификаций

"Гармонизированные критерии Европейских стран" стали весьма передовым документом для своего времени, они подготовили появление международного стандарта ISO/IEC 15408:1999 "Критерии оценки безопасности информационных технологий" (Evaluation criteria for IT security) [ECITS1-ECITS3], в русскоязычной литературе обычно (но не совсем верно) именуемого "Общими критериями" (ОК).

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

ОК содержат два основных вида требований безопасности:

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

1. требования доверия, соответствующие пассивному аспекту; они предъявляются к технологии и процессу разработки и эксплуатации.

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

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

"Общие критерии" способствуют формированию двух базовых видов используемых на практике нормативных документов - это профиль защиты и задание по безопасности.

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

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

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

Криптография - область специфическая, но общее представление о ее месте в архитектуре безопасности и о требованиях к криптографическим компонентам иметь необходимо. Для этого целесообразно ознакомиться с Федеральным стандартом США FIPS 140-2 "Требования безопасности для криптографических модулей" (Security Requirements for Cryptographic Modules) [FIPS140]. Он выполняет организующую функцию, описывая внешний интерфейс криптографического модуля, общие требования к подобным модулям и их окружению. Наличие такого стандарта упрощает разработку сервисов безопасности и профилей защиты для них.

Криптография как средство реализации сервисов безопасности имеет две стороны: алгоритмическую и интерфейсную. Нас будет интересовать исключительно интерфейсный аспект, поэтому, наряду со стандартом FIPS 140-2, мы рассмотрим предложенную в рамках Internet-сообщества техническую спецификацию "Обобщенный прикладной программный интерфейс службы безопасности" (Generic Security Service Application Program Interface, GSS-API) [GSS-API].

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

Технические спецификации IPsec [IPsec] имеют, без преувеличения, фундаментальное значение, описывая полный набор средств обеспечения конфиденциальности и целостности на сетевом уровне. Для доминирующего в настоящее время протокола IP версии 4 они носят факультативный характер; в перспективной версии IPv6 их реализация обязательна. На основе IPsec строятся защитные механизмы протоколов более высокого уровня, вплоть до прикладного, а также законченные средства безопасности, в том числе виртуальные частные сети. Разумеется, IPsec существенным образом опирается на криптографические механизмы и ключевую инфраструктуру.

Точно так же характеризуются и средства безопасности транспортного уровня (Transport Layer Security, TLS) [TLS]. Спецификация TLS развивает и уточняет популярный протокол Secure Socket Layer (SSL), используемый в большом числе программных продуктов самого разного назначения.

В упомянутом выше инфраструктурном плане очень важны рекомендации X.500 "Служба директорий: обзор концепций, моделей и сервисов" (The Directory: Overview of concepts, models and services) [X500] и X.509 "Служба директорий: каркасы сертификатов открытых ключей и атрибутов" (The Directory: Public-key and attribute certificate frameworks) [X509]. В рекомендациях X.509 описан формат сертификатов открытых ключей и атрибутов - базовых элементов инфраструктур открытых ключей и управления привилегиями.

Как известно, обеспечение информационной безопасности - проблема комплексная, требующая согласованного принятия мер на законодательном, административном, процедурном и программно-техническом уровнях. При разработке и реализации базового документа административного уровня - политики безопасности организации - отличным подспорьем может стать рекомендация Internet-сообщества "Руководство по информационной безопасности предприятия" (Site Security Handbook, см. [SSH1], [SSH2]). В нем освещаются практические аспекты формирования политики и процедур безопасности, поясняются основные понятия административного и процедурного уровней, содержится мотивировка рекомендуемых действий, затрагиваются темы анализа рисков, реакции на нарушения ИБ и действий после ликвидации нарушения. Более подробно последние вопросы рассмотрены в рекомендации "Как реагировать на нарушения информационной безопасности" (Expectations for Computer Security Incident Response) [KRN]. В этом документе можно найти и ссылки на полезные информационные ресурсы, и практические советы процедурного уровня.

При развитии и реорганизации корпоративных информационных систем, несомненно, окажется полезной рекомендация "Как выбирать поставщика Internet-услуг" (Site Security Handbook Addendum for ISPs) [SSHA]. В первую очередь ее положений необходимо придерживаться в ходе формирования организационной и архитектурной безопасности, на которой базируются прочие меры процедурного и программно-технического уровней.

Для практического создания и поддержания режима информационной безопасности с помощью регуляторов административного и процедурного уровней пригодится знакомство с британским стандартом BS 7799 "Управление информационной безопасностью. Практические правила" (Code of practice for information security management) [BS7799] и его второй частью BS 7799-2:2002 "Системы управления информационной безопасностью - спецификация с руководством по использованию" (Information security management systems - Specification with guidance for use) [BS7799-2]. В нем разъясняются такие понятия и процедуры, как политика безопасности, общие принципы организации защиты, классификация ресурсов и управление ими, безопасность персонала, физическая безопасность, принципы администрирования систем и сетей, управление доступом, разработка и сопровождение ИС, планирование бесперебойной работы организации. Можно видеть, что отобранные для курса стандарты и спецификации затрагивают все уровни информационной безопасности, кроме законодательного. Далее мы приступим к их детальному рассмотрению.

2. «Общие критерии», часть 1. Основные идеи

Рассматривается история создания "Общих критериев", описывается их текущий статус, анализируются основные идеи История создания и текущий статус "Общих критериев" В 1990 году Рабочая группа 3 Подкомитета 27 Первого совместного технического комитета (JTC1/SC27/WG3) Международной организации по стандартизации (ISO) приступила к разработке "Критериев оценки безопасности информационных технологий" (Evaluation Criteria for IT Security, ECITS). Несколько позже, в 1993 году, правительственные организации шести североамериканских и европейских стран - Канады, США, Великобритании, Германии, Нидерландов и Франции - занялись составлением так называемых "Общих критериев оценки безопасности информационных технологий" (Common Criteria for IT Security Evaluation). За этим документом исторически закрепилось более короткое название - "Общие критерии", или ОК (Common Criteria, CC). Рабочая группа ISO, возглавляемая представителем Швеции, функционировала на общественных началах и действовала весьма неторопливо, пытаясь собрать и увязать между собой мнения экспертов примерно из двух десятков стран, в то время как коллектив "Проекта ОК", финансируемый своими правительствами, несмотря на первоначальное трехлетнее отставание, весьма быстро начал выдавать реальные результаты. Объяснить это нетрудно: в "Проекте ОК" требовалось объединить и развить всего три весьма продвинутых и близких по духу документа - "Гармонизированные критерии Европейских стран", а также "Канадские критерии оценки доверенных компьютерных продуктов" и "Федеральные критерии безопасности информационных технологий" (США). (Сами разработчики "Общих критериев" относят к числу первоисточников еще и "Оранжевую книгу".) Как правило, круг людей, заседающих в комитетах и комиссиях по информационной безопасности, довольно узок, поэтому нет ничего удивительного в том, что одни и те же представители стран (в частности, США и Великобритании) входили в обе группы разработчиков. Естественно, в таких условиях между коллективом "Проекта ОК" и Рабочей группой 3 установилось тесное взаимодействие. Практически это означало, что группа WG3 стала бесплатным приложением к "Проекту ОК", а сами "Общие критерии" автоматически должны были получить статус не межгосударственного, а международного стандарта. В ОС Unix есть утилита tee, создающая ответвления каналов путем копирования стандартного вывода в файлы и довольно точно моделирующая взаимоотношения между коллективом "Проекта ОК" и группой WG3. С 1994 года ранние версии ОК становятся рабочими проектами WG3. В 1996 году появилась версия 1.0 "Общих критериев", которая, помимо публикации в Internet для всеобщего свободного доступа, была одобрена ISO и обнародована в качестве Проекта Комитета. Широкое открытое обсуждение документа и "опытная эксплуатация" привели к его существенной переработке и выходу версии 2.0 ОК в мае 1998 года. Разумеется, эксперты WG3 не могли ее не отредактировать. Их замечания были учтены в версии 2.1 ОК [CC211-CC213], принятой в августе 1999 года. Соответствующий международный стандарт ISO/IEC 15408-1999 [ECITS1-ECITS3] введен в действие с 1 декабря 1999 года. Таким образом, фактически стандарт ISO/IEC 15408-1999 и версия 2.1 ОК совпадают, а если пренебречь описываемыми ниже нюансами, их названия могут считаться взаимозаменяемыми. Однако, строго говоря, "Критерии оценки безопасности информационных технологий" и "Общие критерии оценки безопасности информационных технологий" - разные документы, поскольку выпущены под эгидой разных организаций, руководствующихся разными правилами распространения и обновления. ISO не предоставляет свободный доступ к своим стандартам, они относительно статичны, поскольку их обновляют или подтверждают один раз в пять лет (какие-либо изменения в стандарте ISO/IEC 15408 можно ожидать в 2004 году). Напротив, портал "Проекта ОК" (http://www.commoncriteria.org) открыт для всех желающих, а разработчики "Общих критериев" постоянно предлагают и принимают изменения, уточнения, интерпретации отдельных положений и готовят третью версию своего документа. Поэтому, с формальной точки зрения, международный стандарт ISO/IEC 15408-1999 по-русски правильнее сокращенно именовать КОБИТ, а не ОК. (Правда, велика вероятность, что рабочая группа ISO любезно согласится и дальше пользоваться плодами "Проекта ОК", естественно, внося в них свои редакторские правки...) Уточним, что далее, в рамках этой темы, мы будем иметь в виду именно "Общие критерии", а не стандарт ISO. С целью унификации процедуры сертификации по "Общим критериям" в августе 1999 года была опубликована "Общая методология оценки безопасности информационных технологий" (Common Methodology for Information Technology Security Evaluation) [CEM], описывающая минимальный набор действий при проведении оценки. "Проект ОК" с самого начала носил не только технический, но и экономико-политический характер. Его цель состояла, в частности, в том, чтобы упростить, удешевить и ускорить выход сертифицированных изделий информационных технологий (ИТ) на мировой рынок. Для этого в мае 2000 года уполномоченные правительственные организации шести стран-основателей "Проекта ОК", а также Австралии и Новой Зеландии, Греции, Италии, Испании, Норвегии, Финляндии и Швеции подписали соглашение "О признании сертификатов по Общим критериям в области безопасности информационных технологий" (позднее к нему присоединились Австрия и Израиль). Участие в соглашении предполагает соблюдение двух независимых условий: признание сертификатов, выданных соответствующими органами других стран-участниц, а также возможность осуществления подобной сертификации. Очевидно, от взаимного признания сертификатов выигрывают не только производители, но и потребители изделий ИТ. Что же касается их выдачи, то соглашение предусматривает жесткий контроль при получении и подтверждении этого права (например, предусмотрено проведение так называемых теневых сертификационных испытаний под контролем независимых экспертов). Таким образом, для полноценного участия в соглашении, помимо желания, государство должно располагать органами сертификации с достаточными ресурсами и штатом специалистов, квалификация которых получила официальное международное признание. По данным на конец 2002 года, правом выдачи сертификатов, признаваемых участниками соглашения, обладали Австралия и Новая Зеландия, Великобритания, Германия, Канада, США и Франция. К началу 2003 года сертификаты по "Общим критериям" получили около семидесяти разнообразных изделий ИТ ведущих производителей: операционные системы, системы управления базами данных, межсетевые экраны, коммуникационные средства, интеллектуальные карты и т.п.; еще почти сорок находились в процессе сертификации. Определяя статус "Общих критериев" в России, следует отметить, что отечественные специалисты с самого начала внимательно следили за этим проектом, публиковали аналитические обзоры и переводы (см., например, [JI981K]). В 1999 году была организована работа по подготовке российского стандарта и Руководящего документа (РД) Гостехкомиссии России на основе аутентичного перевода ОК. Она велась в тесном контакте с зарубежными коллегами и успешно завершена в 2002 году. Именно тогда был официально издан ГОСТ Р ИСО/МЭК 15408-2002 "Критерии оценки безопасности информационных технологий" [GOST1-GOST3] с датой введения в действие 1 января 2004 года. А пока положение регулируется РД Гостехкомиссии России [GTKRDCC], который, как и "Общие критерии", по замыслу разработчиков, должен быть динамичнее стандарта, модифицируясь вместе с ОК. Российские специалисты - активные участники "Проекта ОК", они вносят предложения по доработке "Общих критериев", выступают с докладами на конференциях, ведут научно-исследовательские работы, внедряют ОК в практику различных организаций. Следующим логичным шагом стало бы присоединение России к соглашению "О признании сертификатов". Основные понятия и идеи "Общих критериев" Основным свойством, которым должны обладать действительно общие критерии оценки безопасности информационных технологий, является универсальность. Следовательно, они не должны содержать априорных предположений об объекте оценки. В ОК данное условие выполнено: под объектом оценки (ОО) понимается аппаратно-программный продукт или информационная система с соответствующей документацией. Система - это специфическое воплощение информационных технологий с конкретным назначением и условиями эксплуатации. Продукт, согласно ОК, есть совокупность средств ИТ, предоставляющая определенные функциональные возможности и предназначенная для непосредственного использования или включения в различные системы. В качестве собирательного термина для систем и продуктов применяют словосочетание "изделие ИТ". Оно может быть как уже существующим, так и проектируемым. В первом случае - доработано по результатам оценки, во втором - сама перспектива подобного контроля способна дисциплинировать разработчиков; так или иначе проведение оценки должно оказать положительное влияние на безопасность ОО. Объект оценки рассматривается в определенном контексте - среде безопасности, в которую включаются все, что имеет отношение к его безопасности, а именно: ·1 законодательная среда - законы и нормативные акты, затрагивающие ОО; ·2 административная среда - положения политик и программ безопасности, учитывающие особенности ОО; ·3 процедурная среда - физическая среда ОО и меры физической защиты, персонал и его свойства (знания, опыт и т.п.), принятые эксплуатационные и иные процедуры; ·4 программно-техническая среда - предназначение объекта оценки и предполагаемые области его применения, активы (ресурсы), которые требуют защиты средствами ОО. Дальнейший этап технологического цикла подготовки к оценке, согласно "Общим критериям", - описание следующих аспектов среды ОО: ·1 предположения безопасности. Они выделяют объект оценки из общего контекста, задают границы рассмотрения. Истинность этих предположений принимается без доказательства, а из множества возможных отбирается только то, что заведомо необходимо для обеспечения безопасности ОО; ·2 угрозы безопасности ОО, наличие которых в рассматриваемой среде установлено или предполагается. Они характеризуются несколькими параметрами: источник, метод воздействия, опасные с точки зрения злонамеренного использования уязвимости, ресурсы (активы), потенциально подверженные повреждению. При анализе рисков принимаются во внимание вероятность активизации угрозы и ее успешного осуществления, а также размер возможного ущерба. По результатам анализа из множества допустимых угроз отбираются только те, ущерб от которых нуждается в уменьшении; ·3 положения политики безопасности, предназначенные для применения к объекту оценки. Для системы ИТ такие положения могут быть описаны точно, для продукта - в общих чертах. На основании предположений, при учете угроз и положений политики безопасности формулируются цели безопасности для объекта оценки, направленные на обеспечение противостояния угрозам и выполнение политики безопасности. В зависимости от непосредственного отношения к ОО или к среде они подразделяются на две группы. Часть целей для среды может достигаться нетехническими (процедурными) мерами. Все остальные (для объекта и среды) носят программно-технический характер. Для их достижения к объекту и среде предъявляются требования безопасности. "Общие критерии" в главной своей части как раз и являются каталогом (библиотекой) требований безопасности. Спектр стандартизованных требований чрезвычайно широк - это необходимое условие универсальности ОК. Высокий уровень детализации делает их конкретными, допускающими однозначную проверку, что важно для обеспечения повторяемости результатов оценки. Наличие параметров обусловливает гибкость требований, а дополнительную возможность ее достижения (через расширяемость) привносит использование нестандартных (не входящих в каталог ОК) требований. Для структуризации пространства требований в "Общих критериях" введена иерархия класс-семейство-компонент-элемент. Классы определяют наиболее общую (как правило, предметную) группировку требований. Семейства в пределах класса различаются по строгости и другим характеристикам требований. Компонент - минимальный набор требований, фигурирующий как целое. Элемент - неделимое требование. Между компонентами могут существовать зависимости. Они возникают, когда компонент сам по себе недостаточен для достижения цели безопасности. Соответственно, при включении такого компонента необходимо добавить всю "гроздь" его зависимостей. "Общие критерии" содержат два основных вида требований безопасности: ·1 функциональные, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности ОО и реализующим их механизмам; ·2 требования доверия, которые соответствуют пассивному аспекту, предъявляются к технологии и процессу разработки и эксплуатации ОО. Библиотека функциональных требований составляет вторую часть "Общих критериев", а каталог требований доверия - третью (первая часть содержит изложение основных концепций ОК). Сформулировав функциональные требования, требования доверия и требования к среде, можно приступать к оценке безопасности готового изделия ИТ. Для типовых изделий "Общие критерии" предусматривают разработку типовых совокупностей требований безопасности, называемых профилями защиты (ПЗ). Для проектируемого изделия за выработкой требований следует разработка краткой спецификации, входящей в задание по безопасности (ЗБ). (Как вспомогательный элемент, упрощающий создание профилей защиты и заданий по безопасности, могут применяться функциональные пакеты (ФП) - неоднократно используемые совокупности компонентов, объединенных для достижения установленных целей безопасности.) Краткая спецификация определяет отображение требований на функции безопасности (ФБ). "Общие критерии" не предписывают конкретной методологии или дисциплины разработки изделий ИТ, но предусматривают наличие нескольких уровней представления проекта с его декомпозицией и детализацией. За требованиями безопасности следует функциональная спецификация, затем проект верхнего уровня, необходимое число промежуточных уровней, проект нижнего уровня, после этого, в зависимости от типа изделия, исходный код или схемы аппаратуры и, наконец, реализация в виде исполняемых файлов, аппаратных продуктов и т.п. Между уровнями представления должно демонстрироваться соответствие, то есть все сущности более высоких уровней обязаны фигурировать и "ниже", а "внизу" нет места лишним сущностям, не обусловленным потребностями более высоких уровней. При проведении оценки изделия ИТ главными являются следующие вопросы: ·1 отвечают ли функции безопасности ОО функциональным требованиям? ·2 корректна ли реализация функций безопасности? Если оба ответа положительны, можно говорить о достижении целей безопасности. Основные понятия и идеи "Общей методологии оценки безопасности информационных технологий" "Общая методология оценки безопасности информационных технологий" - второй по важности документ (после "Общих критериев"), подготовленный в рамках "Проекта ОК". Основная цель "Общей методологии" - добиться объективности, повторяемости и воспроизводимости результатов оценки. Следуя принципам структурной декомпозиции, разработчики выделили в процессе оценки три задачи (этапа): ·1 входная задача; ·2 задача оценки; ·3 выходная задача. Входная задача имеет дело с представленными для оценки свидетельствами (далее для краткости мы будем именовать их свидетельствами оценки). Ее назначение - убедиться, что версии свидетельств корректны и должным образом защищены. Обычно для оценки представляются стабильные, официально выпущенные версии свидетельств, однако в ситуациях, когда оценка ведется параллельно разработке или доработке ОО, возможно предъявление рабочих версий. Оценщику вместе со спонсором этого процесса необходимо составить каталог и в дальнейшем производить конфигурационный контроль версий. Он обязан обеспечить защиту свидетельств от изменения и утери, а по окончании процесса оценки возвратить их, поместить в архив или уничтожить. На всех этапах оценки должна обеспечиваться конфиденциальность. Задача оценки в общем случае разбивается на следующие подзадачи: ·1 оценка задания по безопасности; ·2 оценка управления конфигурацией ОО; ·3 оценка документации по передаче ОО потребителю и эксплуатационной документации; ·4 оценка документации разработчиков; ·5 оценка руководств; ·6 оценка поддержки жизненного цикла ОО; ·7 оценка тестов; ·8 тестирование; ·9 оценка анализа уязвимостей. Нередко проводятся выборочные проверки, когда вместо всего (относительно однородного) множества свидетельств анализируется представительное подмножество, что позволяет сэкономить ресурсы при сохранении необходимого уровня доверия безопасности. Размер выборки должен быть обоснован математически и экономически, но при анализе реализации объекта оценки он должен составлять не менее 20%. Ошибки, обнаруженные при выборочной проверке, подразделяются на систематические и случайные. После исправления систематической ошибки необходимо произвести новую выборку; после случайной этого не требуется. Допускается выборочная проверка доказательств, тестов, результатов анализа скрытых каналов, выполнения требований к содержанию и представлению свидетельств, выборочное тестирование. В остальных ситуациях такой способ можно применять только в исключительных случаях, когда полная проверка требует слишком много ресурсов по сравнению с другими действиями в процессе оценки или когда она не существенно увеличивает доверие безопасности. При этом необходимо обосновать допустимость и целесообразность выборочного подхода. В "Общей методологии" специально подчеркивается, что сами по себе большие размеры и высокая сложность объекта оценки не оправдывают замены полных проверок выборочными, поскольку для оценки безопасности подобных объектов заведомо требуется много сил и средств. Необходимый элемент оценки - проверка внутренней согласованности каждого из представленных свидетельств, а также внешней взаимной согласованности различных свидетельств. Внутренняя согласованность проверяется в первую очередь для сущностей, имеющих несколько представлений: для спецификаций и проектов всех уровней, а также для руководств. Проверка внешней согласованности производится для описаний функций, параметров безопасности, процедур и событий, связанных с безопасностью, поскольку эти описания могут содержаться в разных документах. Внутренняя несогласованность высокоуровневых сущностей может иметь глобальные последствия для процесса оценки. Например, выявление противоречий в целях заставляет заново проанализировать требования и функции безопасности. Разные подзадачи в процессе оценки могут выполняться в произвольном порядке или параллельно, однако существуют зависимости, накладывающие некоторые ограничения на очередность выполнения. Наиболее очевидное из них состоит в том, что анализ задания по безопасности должен выполняться до каких бы то ни было проверок объекта оценки. Задание по безопасности среди других характеристик объекта оценки определяет его границы и спектр рассматриваемых угроз. Следовательно, процесс и результат оценки одного и того же продукта в сочетании с разными заданиями могут быть разными. Например, если в нем содержатся средства межсетевого экранирования и поддержки виртуальных частных сетей (ВЧС), но в задании по безопасности предусмотрена исключительно защита внутренней сети от внешних угроз, то свойства ВЧС-функций важны лишь в контексте возможности обхода средств экранирования. Даже если ВЧС-функции не обеспечивают конфиденциальности сетевых потоков данных, продукт с таким заданием получит положительную оценку. (Заметим, что набор проверяемых требований необходим при сертификации не только по "Общим критериям". Нередко производитель в рекламных целях ограничивается кратким "продукт сертифицирован", что, по сути, бессодержательно и может ввести в заблуждение потребителя, так как зачастую означает соответствие каким-либо условиям общего характера, вроде отсутствия недекларированных возможностей.) Важным моментом, обычно вызывающим много вопросов, является анализ уязвимостей и стойкости функций безопасности. Цель обоих видов проверки заключается в выявлении степени устойчивости объекта оценки по отношению к атакам, выполняемым нарушителем с определенным (низким, умеренным или высоким) потенциалом нападения. Анализ уязвимостей применяется ко всем функциям безопасности; при этом не делается каких-либо предположений относительно корректности их реализации, сохранения целостности, возможности обхода и т.п. Анализу стойкости подвергаются только функции безопасности, реализованные с помощью вероятностных или перестановочных механизмов, у которых и проверяется стойкость - базовая, средняя или высокая (базовая означает защищенность от нарушителя с низким потенциалом нападения). В принципе, все вероятностные функции можно считать уязвимыми, а подобный анализ классифицировать как анализ уязвимостей специального вида. Для успешного нападения необходимо сначала идентифицировать, а затем использовать некоторую уязвимость. Оба действия оцениваются с точки зрения временных затрат, необходимой квалификации, уровня знаний об ОО, характера и продолжительности доступа к ОО, необходимых аппаратно-программных и иных ресурсов. Перечисленные составляющие не являются независимыми. Высокая квалификация может сэкономить время, а специальное оборудование - упростить и ускорить доступ к ОО. Следовательно, если оценивать каждый параметр количественно, то результирующую функцию, характеризующую серьезность уязвимости, естественно сделать аддитивной. В таблицах 2.1 - 2.5 содержатся условные баллы, присваиваемые параметрам уязвимости в зависимости от того, в какой диапазон или на какой уровень они попадают. Для получения общего рейтинга нужно выбрать по одному значению из обоих числовых столбцов всех таблиц и сложить эти десять чисел. При оценке стойкости функций безопасности фаза идентификации не рассматривается (предполагается, что уязвимость известна), поэтому достаточно выбрать и сложить пять чисел из последних столбцов. Табл. 2.1. Условные баллы, присваиваемые уязвимости в зависимости от времени, которое понадобится для ее идентификации и использования. Диапазон Идентификация уязвимости Использование уязвимости < 0.5 часа 0 0 < суток 2 3 < месяца 3 5 > месяца 5 8 Табл. 2.2. Условные баллы, присваиваемые уязвимости в зависимости от уровня квалификации, необходимого для ее идентификации и использования. Уровень Идентификация уязвимости Использование уязвимости Любитель 0 0 Специалист 2 2 Эксперт 5 4 Табл. 2.3. Условные баллы, присваиваемые уязвимости в зависимости от уровня знаний об объекте оценки, необходимого для ее идентификации и использования. Уровень Идентификация уязвимости Использование уязвимости Отсутствие знаний 0 0 Общедоступные знания 2 2 Конфиденциальные сведения 5 4 Табл. 2.4. Условные баллы, присваиваемые уязвимости в зависимости от времени доступа к объекту оценки, требуемого для ее идентификации и использования. Диапазон Идентификация уязвимости Использование уязвимости < 0.5 часа или доступ незаметен 0 0 < суток 2 4 < месяца 3 6 > месяца 4 9 Табл. 2.5. Условные баллы, присваиваемые уязвимости в зависимости от аппаратно-программных и иных ресурсов (оборудования), необходимых для ее идентификации и использования. Уровень Идентификация уязвимости Использование уязвимости Отсутствие оборудования 0 0 Стандартное оборудование 1 2 Специальное оборудование 3 4 Заказное оборудование 5 6 Если уязвимость можно идентифицировать и/или использовать несколькими способами, для каждого из них вычисляется рейтинг и из полученных значений выбирается минимальное, то есть уязвимость характеризуется самым простым методом успешного нападения. В табл. 2.6 приведены диапазоны рейтинга, которые характеризуют стойкость функции безопасности. Табл. 2.6. Диапазоны рейтинга, характеризующие стойкость функции безопасности. Диапазон Стойкость функции безопасности 10 - 17 Базовая 18 - 24 Средняя > 24 Высокая Согласно "Общей методологии", потенциал нападения оценивается в общем и целом по той же схеме, что и степень риска от наличия уязвимостей, с некоторыми очевидными отличиями (например, из нескольких сценариев нападения выбирается худший, с наибольшим потенциалом). Считается, что он является функцией уровня мотивации злоумышленника, его квалификации и имеющихся ресурсов. Мотивация влияет на выделяемое на атаки время и, возможно, на привлекаемые ресурсы и подбор нападающих. В табл. 2.7 приведены диапазоны рейтинга, иллюстрирующие определенный потенциал нападения. Табл. 2.7. Диапазоны рейтинга, характеризующие потенциал нападения. Диапазон Потенциал нападения < 10 Низкий 10 - 17 Умеренный 18 - 24 Высокий > 24 Нереально высокий Нападение может быть успешным, только если его потенциал не меньше рейтинга уязвимости. Отсюда следует, в частности, что уязвимости с рейтингом выше 24 устойчивы к нападению с высоким потенциалом, поэтому их практическое использование злоумышленниками представляется нереальным. Отметим, что потенциал предполагаемых нападений на ОО выявляется дважды: при анализе задания по безопасности для выбора надлежащих мер противодействия и при анализе уязвимостей для определения достаточности выбранных мер и качества их реализации. Рассмотрим пример анализа стойкости функции безопасности. Пусть доступ к информационной системе осуществляется посредством территориально разнесенных терминалов, работа за которыми не контролируется. Авторизованные пользователи проходят аутентификацию путем введения паролей, состоящих из четырех различных цифр. Если пароль введен неверно, терминал блокируется на одну минуту. Требуется оценить стойкость такой парольной защиты для заданного пользователя с известным нападающему входным именем. Для нападения выбран один терминал, временем ввода можно пренебречь. Очевидно, число возможных парольных последовательностей составляет 10*9*8*7 = 5040 Для успешного подбора пароля методом полного перебора требуется примерно 2520 попыток, которые можно произвести за 42 часа, что больше суток, но меньше месяца. Никакой квалификации, знаний и/или оборудования для этого не нужно. Следовательно, чтобы определить стойкость функции, достаточно сложить два числа: 5 из табл. 2.1 и 6 из табл. 2.4. Сумма 11 позволяет сделать вывод, что данная функция безопасности обладает базовой стойкостью и является устойчивой к нападению с низким потенциалом. Возвращаясь к трем основным задачам процесса оценки, рассмотрим последнюю, выходную задачу. Ее цель - сформулировать замечания и получить технический отчет оценки. Текст с замечаниями не является обязательным. Он нужен, если в процессе оценки выявились какие-либо неясности или проблемы. Технический отчет оценки - это главный выходной документ, от качества которого во многом зависит повторяемость и воспроизводимость результатов оценки, т. е. возможность их многократного использования. "Общая методология" предписывает следующую структуру подобных отчетов: ·1 введение; ·2 архитектурное (высокоуровневое) описание объекта оценки с рассмотрением основных компонентов; ·3 описание процесса оценки, примененных методов, методологий, инструментальных средств и стандартов; ·4 представление результатов оценки; ·5 выводы и рекомендации; ·6 список представленных свидетельств; ·7 список сокращений, словарь терминов; ·8 список замечаний. Изучение "Общей методологии" полезно не только оценщикам, но и разработчикам, так как дает представление о вопросах, которые могут возникать в процессе оценки. К сожалению, более детальное рассмотрение этого документа выходит за рамки настоящего курса.

3. «Общие критерии», часть 2. Функциональные требования безопасности

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

Классификация функциональных требований безопасности

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

Аналогия между библиотекой функциональных требований безопасности и библиотекой программных модулей является в данном случае довольно полной. Функциональные компоненты могут быть не до конца конкретизированы, поэтому фактические параметры подставляются не в самих "Общих критериях", а в определенных профилях защиты, заданиях по безопасности и функциональных пакетах. (Правда, в ГОСТ Р ИСО/МЭК 15408-2002 параметризация не очень удачно названа "назначением".) В качестве параметров могут выступать весьма сложные сущности, такие, например, как политика безопасности (ПБ).

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

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

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

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

К первой группе относятся следующие классы:

1. FAU - аудит безопасности (описывает требования к сервису протоколирования/аудита);

1. FIA - идентификация/аутентификация;

1. FRU - использование ресурсов (прежде всего - обеспечение отказоустойчивости).

Классы второй группы:

1. FCO - связь (обслуживает неотказуемость отправителя/получателя);

1. FPR - приватность;

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

1. FDP - защита данных пользователя;

1. FPT - защита функций безопасности объекта оценки.

Наиболее многочисленны классы, играющие инфраструктурную роль:

1. FCS - криптографическая поддержка (обслуживает управление криптографическими ключами и криптографические операции);

1. FMT - управление безопасностью;

1. FTA - доступ к объекту оценки (управление сеансами работы пользователей);

1. FTP - доверенный маршрут/канал.

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

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

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

Далее мы кратко рассмотрим все 11 классов функциональных требований безопасности "Общих критериев".

Классы функциональных требований, описывающие элементарные сервисы безопасности

В этом разделе рассматриваются три класса функциональных требований безопасности:

1. FAU - аудит безопасности;

1. FIA - идентификация/аутентификация;

1. FRU - использование ресурсов.

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

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

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

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

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

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

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

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

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

Семейство FIA_UID (идентификация пользователя) включает два компонента и определяет набор действий (например, получение справочной информации), которые разрешается выполнять до идентификации. Обычно применяют более сильный компонент FIA_UID.2 - идентификация до любых действий, выполняемых пользователем при посредничестве функций безопасности.

Семейство FIA_UAU (аутентификация пользователя) устроено сложнее. Оно специфицирует типы механизмов аутентификации и используемые при этом атрибуты. Два первых компонента, FIA_UAU.1 (выбор момента аутентификации) и FIA_UAU.2 (аутентификация до любых действий пользователя), играют (применительно к аутентификации) ту же роль, что и компоненты семейства FIA_UID. На реализацию надежной аутентификации, устойчивой к сетевым угрозам, направлены компоненты FIA_UAU.3 (аутентификация, защищенная от подделок), FIA_UAU.4 (механизмы одноразовой аутентификации) и FIA_UAU.5 (сочетание механизмов аутентификации). После периода неактивности пользователя и в ряде других ситуаций уместно применение компонента FIA_UAU.6 (повторная аутентификация). Наконец, FIA_UAU.7 (аутентификация с защищенной обратной связью) указывает, как отображать пароль при вводе.

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

Обычно после успешной идентификации и аутентификации от имени пользователя начинает действовать некий процесс (субъект). Семейство FIA_USB (связывание пользователь-субъект) содержит требования по ассоциированию атрибутов безопасности пользователя с этим субъектом.

Выявлением и реагированием на неудачи аутентификации ведает семейство FIA_AFL (отказы аутентификации). Разумеется, и число допустимых неудачных попыток, и действия, выполняемые при превышении порога неудач, - все это параметры единственного компонента семейства.

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

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

Класс FRU (использование ресурсов) включает три семейства, призванные разными способами поддерживать высокую доступность.

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

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

Семейство FRU_RSA (распределение ресурсов) для достижения высокой доступности ресурсов привлекает механизм квот.

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

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

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

Отметим также, что включение в класс FRU конкретных механизмов еще резче обозначает излишнюю обобщенность требований класса FIA.

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

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

1. FCO - связь;

1. FPR - приватность.

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

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

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

Семейство FPR_PSE (псевдонимность) обеспечивает условия, когда пользователь может использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то же время подотчетным за свои действия. Базовый компонент семейства, FPR_PSE.1, предписывает выборочную анонимность, а также наличие средств генерации заданного числа псевдонимов и определения или принятия псевдонима от пользователя с верификацией соответствия некоторой метрике псевдонимов. Эти требования дополняются в компоненте FPR_PSE.2 (обратимая псевдонимность) возможностью определения доверенными субъектами идентификатора пользователя по представленному псевдониму, а в компоненте FPR_PSE.3 (альтернативная псевдонимность) - возможностью оперативного перехода на новый псевдоним, связь которого со старым проявляется лишь в заранее оговоренных ситуациях.

Семейство FPR_UNL (невозможность ассоциации) содержит единственный компонент, предусматривающий неоднократное применение пользователем информационных сервисов, не позволяя заданным субъектам ассоциировать их между собой и приписывать одному лицу. Невозможность ассоциации защищает от построения профилей поведения пользователей (см. выше компонент FAU_SAA.2).

Самым сложным в классе FPR является семейство FPR_UNO (скрытность). Его требования направлены на то, чтобы пользователь мог незаметно для кого бы то ни было работать с определенными информационными сервисами. Наиболее интересны два из четырех имеющихся компонентов семейства. FPR_UNO.2 (распределение информации, влияющее на скрытность) предписывает рассредоточить соответствующие данные по различным частям объекта оценки. Это одно из немногих архитектурных требований "Общих критериев" (правда, выраженное в очень общей форме). В некотором смысле противоположную роль играет компонент FPR_UNO.4 (открытость для уполномоченного пользователя), согласно которому уполномоченные пользователи должны иметь возможность наблюдать за тем, как употребляются заданные ресурсы и/или услуги. (Как сказал один пессимист: "Я так и знал, что этим все кончится!")

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

Защита данных пользователя

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

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

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

1. политики защиты данных пользователя;

1. виды защиты данных пользователя;

1. импорт и экспорт данных пользователя;

1. защита данных пользователя при передаче между доверенными изделиями ИТ.

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

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

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

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

Отметим, что компонент FDP_DAU.2 ведает неотказуемостью авторства, а рассмотренный выше класс FCO - неотказуемостью отправки и получения данных, что можно считать разновидностью динамической целостности.

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

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

Семейство FDP_ROL (откат) предусматривает возможность отмены последней операции и возврат к предшествующему состоянию с сохранением целостности данных пользователя.

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

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

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

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

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

Обратим внимание на различие требований к защите данных пользователя при передаче по внутреннему (семейство FDP_ITT) и внешнему (семейства FDP_UCT и FDP_UIT) каналам, что можно считать проявлением гибкости "Общих критериев". Для внешних каналов требования заданы более детально (особенно это касается целостности), однако не предусматривается обеспечение высокой доступности данных.

Отметим также, что за различные аспекты целостности данных пользователя отвечают пять семейств: FDP_DAU, FDP_ITT (точнее, компонент FDP_ITT.3), FDP_ROL, FDP_SDI и FDP_UIT. Первое контролирует аутентичность избранных наборов данных, компонент FDP_ITT.3 и семейство FDP_UIT отвечают за (динамическую) целостность передаваемых данных, FDP_ROL - за восстановление целостности после сбоев или ошибок, а FDP_SDI предусматривает тотальный мониторинг статической целостности.

На практике эти варианты целостности контролируются и восстанавливаются разными методами (например, для выполнения требований FDP_DAU естественно воспользоваться криптографическими хэш-функциями или цифровой подписью, для FDP_SDI - обычными контрольными суммами), поэтому разнесение требований, относящихся к одному аспекту ИБ, представляется в данном случае оправданным, хотя, на наш взгляд, предпочтительнее было бы ограничиться уровнем компонентов, а не семейств. Примером могут служить рассмотренные выше компоненты FAU_SAA.2 и FAU_SAA.4, обслуживающие различные методы выявления подозрительной активности.

Защита функций безопасности объекта оценки

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

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

1. архитектурная безопасность;

1. защита реализации функций безопасности;

1. защита данных функций безопасности;

1. инфраструктурные требования.

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

Еще один фундаментальный принцип архитектурной безопасности поддерживается семейством FPT_SEP (разделение доменов). Минимально необходимо отделение домена функций безопасности (компонент FPT_SEP.1), то есть функции безопасности должны поддерживать домен безопасности, который защищает их от вмешательства не облеченных доверием субъектов и искажений с их стороны (кроме того, должно быть реализовано разделение доменов безопасности субъектов). Максимальный уровень потребует реализации полного монитора обращений (компонент FPT_SEP.3), то есть предоставление отдельного домена той части функций безопасности, которая проводит в жизнь политики управления доступом и/или информационными потоками.

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

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

1. при сбоях заданных типов возврат к безопасному состоянию обеспечивается автоматическими процедурами;

1. безопасное состояние восстанавливается без превышения заранее определенной меры потери данных;

1. функции безопасности помогают выяснить, какие объекты могут быть восстановлены, а какие нет.

Семействo FPT_PHP (физическая защита) требует наличия средств выявления и реагирования на несанкционированный физический доступ к частям ОО, участвующим в реализации функций безопасности. Компонент FPT_PHP.1 (пассивное обнаружение физического нападения) можно отнести к средствам контроля целостности, так как он требует однозначного обнаружения физического воздействия, которое может угрожать выполнению функций безопасности; информация о наличии или отсутствии подобного воздействия предоставляется по запросу. Усиливающий компонент FPT_PHP.2 (оповещение о физическом нападении) предусматривает постоянный контроль за определенными элементами и оповещение назначенного пользователя о подобных происшествиях. Наконец, компонент FPT_PHP.3 (противодействие физическому нападению) требует автоматической реакции, предотвращающей нарушение политики безопасности.

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

Объединение в одном компоненте двух существенно разных видов требований представляется странным (тестирование имеет мало общего с контролем целостности кода и, тем более, изменяемых данных), но позволяет плавно перейти к третьей группе семейств класса FPT (защита данных функций безопасности). В эту группу входят шесть семейств, три из которых, FPT_ITA, FPT_ITC и FPT_ITI, отвечают, соответственно, за доступность, конфиденциальность и целостность экспортируемых данных функций безопасности. Отметим, что доступность должна быть обеспечена с заданной вероятностью, а контроль целостности в общем случае предусматривает возможность восстановления поврежденных данных удаленным доверенным изделием ИТ.

Семейство FPT_TDC содержит требование согласованной интерпретации данных, совместно используемых функциями безопасности ОО и другим доверенным изделием ИТ. Явных требований к контролю импортируемых данных в классе FPT (в отличие от FDP) нет, хотя из соображений симметрии они, безусловно, должны присутствовать (см. выше семейства FDP_ETC и FDP_ITC).

Пятое семейство группы, FPT_ITT (передача данных функций безопасности в пределах объекта оценки), аналогично рассмотренному ранее семейству из класса защиты данных пользователя FDP_ITT (передача в пределах ОО), но не предусматривает обеспечения доступности и разделения по атрибутам при контроле целостности. Справедливости ради укажем, однако, что в компоненте FPT_ITT.3 более детально специфицированы обнаруживаемые виды нарушений целостности: модификация, подмена, перестановка, удаление данных.

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

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

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

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

Наконец, семейство FPT_STM (метки времени) требует предоставления надежных меток времени в пределах объекта оценки. Подобные метки необходимы, например, функциям протоколирования и управления.

Классы функциональных требований, играющие инфраструктурную роль

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

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

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

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

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

FMT_REV (отмена) предусматривает возможность отмены (отзыва) атрибутов безопасности пользователей, субъектов и объектов.

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

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

Шесть семейств простой структуры содержит и класс FTA (доступ к объекту оценки), куда вошли требования управления сеансами работы пользователей (помимо идентификации и аутентификации).

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

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

Семейство FTA_SSL (блокирование сеанса) определяет возможность блокирования или завершения интерактивного сеанса как по инициативе пользователя, так и по инициативе функций безопасности (если пользователь неактивен заданное время). Действия, осуществляемые при блокировании, описаны весьма детально:

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

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

Еще три однокомпонентных семейства содержат некоторые подробности открытия сеанса.

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

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

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

Если сопоставить степень детализации требований к криптографической поддержке и к управлению сеансами, то различие представляется слишком большим. Впрочем, выдержать единый уровень в столь большом и сложном документе, как "Общие критерии", едва ли возможно. Привычные, традиционные требования предъявляет класс FTP (доверенный маршрут/канал), состоящий из двух семейств, содержащих по одному компоненту в каждом. Доверенный маршрут (семейство FTP_TRP) позволяет выполнять определенные действия в режиме прямого взаимодействия с функциями безопасности (например, при начальной аутентификации). Доверенные каналы (семейство FTP_ITC) предназначены для передачи критичных по безопасности данных между функциями безопасности с другими доверенными изделиями ИТ. Доверенный маршрут/канал должен быть логически отличим от других маршрутов (каналов), обеспечивать уверенную идентификацию взаимодействующих сторон, а также конфиденциальность и целостность передаваемых данных.

На этом мы завершаем рассмотрение функциональных требований безопасности.

4. «Общие критерии», часть 3. Требования доверия безопасности

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

Основные понятия и классификация требований доверия безопасности

Требования доверия безопасности составляют содержание третьей части "Общих критериев".

Доверие в трактовке "Общих критериев" - это основа для уверенности в том, что изделие ИТ отвечает целям безопасности. Доверие обеспечивается через активное исследование (оценку) изделия ИТ.

Требования доверия безопасности охватывают весь жизненный цикл изделий ИТ и предполагают выполнение следующих действий:

1. оцениваются задания по безопасности (ЗБ) и профили защиты (ПЗ), ставшие источниками требований безопасности;

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

1. проверяются процессы и процедуры безопасности, их применение;

1. анализируется документация;

1. верифицируются представленные доказательства;

1. анализируются тесты и их результаты;

1. анализируются уязвимости объекта оценки;

1. проводится независимое тестирование, в том числе тестовые "взломы" (называемые далее тестированием проникновения).

Каждое требование (элемент) доверия принадлежит одному из трех типов:

1. элементы действий разработчика (помечаются буквой "D" после номера элемента); эти действия должны подтверждаться доказательным материалом (свидетельствами);

1. элементы представления и содержания свидетельств (помечаются буквой "C");

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

Требования доверия разделены на 10 классов, 44 семейств и 93 компонента. Классы можно сгруппировать в зависимости от охватываемых этапов жизненного цикла изделий ИТ.

К первой группе, логически предшествующей разработке и оценке ОО, принадлежат классы APE (оценка профиля защиты) и ASE (оценка задания по безопасности).

Во вторую группу входят классы ADV (разработка), ALC (поддержка жизненного цикла) и ACM (управление конфигурацией).

К этапу получения, представления и анализа результатов разработки можно отнести классы AGD (руководства), ATE (тестирование) и AVA (оценка уязвимостей).

Требования к поставке и эксплуатации составляют содержание класса ADO.

Наконец, класс AMA (поддержка доверия) включает требования, применяемые после сертификации объекта оценки на соответствие "Общим критериям".

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

Одна из целей "Общих критериев" состоит в минимизации усилий разработчиков и оценщиков, направленных на обеспечение заданного уровня доверия. Этому способствует введение семи оценочных уровней доверия (ОУД), содержащих полезные для практического применения комбинации компонентов, упорядоченные по степени усиления. Повысить уровень доверия помогут дополнительные действия:

1. расширение границ объекта оценки;

1. увеличение уровня детализации рассматриваемых аспектов ОО;

1. повышение строгости рассмотрения, применение более формальных методов верификации.

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

Оценка профилей защиты и заданий по безопасности

Цель требований, вошедших в классы APE (оценка профиля защиты) и ASE (оценка задания по безопасности), - проверить полноту, непротиворечивость и реализуемость ПЗ или ЗБ.

Класс APE состоит из шести однокомпонентных семейств, соответствующих предписанной структуре профилей защиты.

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

Семейство APE_DES (описание ОО) специфицирует, что описание объекта оценки должно включать в себя, как минимум, тип продукта и его общую характеристику.

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

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

Основное содержание профиля защиты составляют требования безопасности. К этой части применимы семейства APE_REQ (требования безопасности ИТ) и APE_SRE (требования безопасности ИТ, сформулированные в явном виде). Первое относится к стандартным требованиям "Общих критериев", второе - к расширениям ОК, введенным разработчиком ПЗ. Логическое обоснование требований безопасности должно демонстрировать их решающую роль в достижении целей безопасности.

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

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

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

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

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

Требования доверия к этапу разработки

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

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

Неформальная спецификация пишется как обычный текст с определением необходимых терминов. Неформальная демонстрация соответствия требует установления "соответствия по сути".

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

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

Ранжирование компонентов в семействах класса ADV в основном соответствует стилю изложения спецификаций, ужесточаясь от неформального к формальному.

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

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

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

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

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

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

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

Требования семейства ADV_INT (внутренняя структура функций безопасности ОО) носят технологический характер и сходны по смыслу с требованиями структурированного программирования. Основная идея состоит в минимизации сложности процесса и результата разработки путем разбиения на модули и использования нескольких уровней абстракции. Здесь придется впервые сформулировать требования к действиям разработчика (до этого мы ограничивались требованиями к представлению и содержанию свидетельств).

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к этапу получения, представления и анализа результатов разработки

Мы переходим к рассмотрению трех следующих классов требований доверия безопасности: AGD (руководства), ATE (тестирование) и AVA (оценка уязвимостей).

Класс AGD состоит из двух однокомпонентных семейств, где сформулированы требования к руководствам администратора (AGD_ADM) и пользователя (AGD_USR).

Руководство администратора должно содержать:

1. описание особенностей управления ОО безопасным способом;

1. описание функций и интерфейсов администрирования;

1. предупреждения относительно функций и привилегий, подлежащие контролю;

1. описание всех предположений о поведении пользователя, которые связаны с безопасной эксплуатацией ОО;

1. описание всех параметров безопасности, контролируемых администратором, с указанием безопасных значений;

1. описание событий, относящихся к безопасности;

1. описание всех требований безопасности к среде ИТ, имеющих отношение к администратору.

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

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

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

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

1. изложение всех обязанностей пользователя по безопасной эксплуатации ОО.

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

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

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

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

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

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

Один из ключевых моментов оценки безопасности изделия ИТ - оценка уязвимостей (класс AVA), отправным пунктом которой является анализ уязвимостей (семейство AVA_VLA), выполняемый разработчиком и оценщиком. Четыре компонента этого семейства ранжированы по уровню строгости анализа и потенциалу предполагаемого нарушителя.

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

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

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

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

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

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

Анализ скрытых каналов, регламентируемый семейством AVA_CCA, крайне сложен и концептуально, и технически (см., например, статью [JI200211]). Здесь легко требовать, но трудно выполнять. Согласно "Общим критериям", разработчик проводит исчерпывающий поиск скрытых каналов для каждой политики управления информационными потоками и предоставляет документацию анализа, в которой идентифицированы скрытые каналы и оценена их пропускная способность, описаны наиболее опасные сценарии использования каждого идентифицированного скрытого канала.

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

Требования к поставке и эксплуатации, поддержка доверия

Класс ADO (поставка и эксплуатация) содержит требования к процедурам поставки, установки, генерации и запуска объекта оценки.

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

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

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

Действия по поддержке доверия носят циклический характер. Каждая итерация цикла состоит из двух фаз:

1. приемка объекта оценки для поддержки;

1. мониторинг ОО.

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

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

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

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

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

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

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

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

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

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

На этом мы завершаем рассмотрение семейств требований доверия безопасности.

Оценочные уровни доверия безопасности

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

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

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

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

Оценочный уровень доверия 2 (ОУД2) предусматривает структурное тестирование и доступ к части проектной документации и результатам тестирования разработчиком. ОУД2 применим, когда разработчикам или пользователям требуется независимо получаемый умеренный уровень доверия при отсутствии доступа к полной документации по разработке.

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

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

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

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

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

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

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

Оценочный уровень доверия 6 (ОУД6) характеризуется полуформальной верификацией проекта. Он позволяет получить высокое доверие путем применения специальных методов проектирования в строго контролируемой среде разработки при производстве высококачественных изделий ИТ и при защите ценных активов от значительных рисков.

Особенности ОУД6:

1. структурированное представление реализации;

1. полуформальное представление проекта нижнего уровня;

1. иерархическая структура проекта ОО;

1. устойчивость к попыткам проникновения нарушителей с высоким потенциалом нападения;

1. проверка правильности систематического анализа разработчиком скрытых каналов;

1. использование структурированного процесса разработки;

1. полная автоматизация управления конфигурацией ОО.

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

На седьмом уровне дополнительно требуются:

1. формальное представление функциональной спецификации и проекта верхнего уровня и формальная демонстрация соответствия между ними;

1. модульная, иерархическая и простая структура проекта ОО;

1. добавление представления реализации как основы акта об испытаниях;

1. полное независимое подтверждение результатов тестирования разработчиком.

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

Дополнительную информацию по "Общим критериям" можно найти в книге [OBIT].