Сканирование и редактирование книги

Бородулин А.В. ТРТУ гр. А-95

каждое вносимое в ПО изменение должно со­провождаться тщательной проверкой

всей системы так, как если бы это было испытанием абсолютно но­вой системы.

3.3.2.3. Возникновение ИЗ в процессе функционирования системы

Возникновение ошибок и сбоев, утечка информации и другие подобные явления в

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

при­чине воздействия на нее специально написанных про­грамм (РПС).

Хорошо известные случаи вирусных атак являются наиболее ярким обоснованием

необходимости постоян­ного контроля и анализа состояния системы и

исполняе­мых файлов [19]. Основной задачей такого анализа в процессе

функционирования системы является выявле­ние несанкционированной модификации

каких-либо фрагментов исполняемого кода. Очевидно,. что целью РПС является не

просто модификация кода, а нарушение функционирования системы и, возможно,

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

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

3.3.3. Классификация ИЗ по размещению в системе

ИЗ можно классифицировав по их размещению в ВС в зависимости от того, в каких

компонентах системы они находятся. Большинство ошибок, приводящих к

возникновению ИЗ и нарушению требовании защиты, присутствует в программном

обеспечении, хотя они мо­гут встречаться и в аппаратуре В данной работе

основ­ное внимание уделено исследованию таксономии ИЗ в программном

обеспечении вообще и в операционных системах в частности, однако

функционирование про­грамм всецело зависит от аппаратной платформы

Сле­довательно, ИЗ может использовать ошибки аппарату­ры. Это определяет

необходимость внесения в классифи­кацию соответствующих категорий, ошибки в

про­граммном обеспечении и ошибки аппаратных платформ (таблица 3.3).

Компоненты программного обеспечения, вне зави­симости от их конкретного

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

разде­ление программ по категориям носит достаточно услов­ный характер.

Среди всего комплекса программного обеспечения в отдельную категорию в первую

очередь выделим опера­ционную систему. В ней определена и реализована

архи­тектура всей вычислительной системы, и наличие в ней ошибок, связанных с

обеспечением безопасности, автоматически повлечет за собой серьезные

последствия для всей ВС в целом.

Непосредственно с ОС связано сервисное программ­ное обеспечение,

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

того, суще­ствует прикладное программное обеспечение, с которым

непосредственно работают пользователи

Таблица 3.3 Классификация ИЗ по размещению в вычислительной системе

				Кол-во при­меров	Индексы в Приложении IV
Размещение вВС	Программное обеспечение	Операционная система	Инициализация (загрузка)	8	U5, U13, PC2, PC4, MA1, MA2, AT1, CA1
			Управление выделением памяти	2	MT3, MU5
			Управление процессами	10	I6, I9, MT1, MT2, MU2, MU3, MU4, MU6, U7, UNl
			Управление устройствами	3	I2, I3, I4
			Управление файловой системой	6	I1, I5, MU8, U2, U3, U9
			Средства идентификации и аутентификации	5	MU1, DT1, U6. U11, D1
			Другие	1	MT4
		Сервисные про­граммы и утилиты	Привилегированные утилиты	10	I7, B1, U4, U7, U8, U10, U12, U14, PC1, PC3
			Непривилегированные утилиты	1	Ul
		Прикладные программы		1	I8
	Аппаратное обеспечение			3	MU9, D2, IN1

3.3.3.1. Системное программное обеспечение

Операционные системы обычно включают в себя функции управления процессами,

устройствами, распре­делением памяти, файловой системой и т.д. Кроме того,

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

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

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

системе, в данной классификации выделен только механизм

идентификации/аутентификации как один из важнейших и присущий всем системам

без ис­ключения.

Итак, положение ИЗ в операционной системе будем разделять по следующим

категориям:

· инициализация (загрузка) системы;

· управление распределением памяти;

· управление устройствами;

· управление процессами;

· управление файловой системой;

· идентификация и аутентификация.

Для ошибок, не попадающих ни в одну из данных категорий, введем

дополнительную категорию «другие».

Процесс инициализации системы имеет четко опре­деленные функции, но все же

достаточно сложен и весь­ма различен в разных системах. Ошибки на этапе

ини­циализации могут возникнуть в результате неправильно­го взаимодействия с

аппаратурой (например, если про­изошли изменения в составе аппаратных

средств) или при задании неверных параметров конфигурации. Ошибки такого рода

приводят, как правило, к непра­вильному назначению полномочий доступа к

ресурсам системы.

Управление процессами и управление распределени­ем памяти — основные задачи

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

злоумышленником контроля над всей системой и свободному доступу к любой

информации.

Управление устройствами подразумевает наличие комплекса программ

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

независимо от центрального процессора. Ошибки в таких програм­мах, например

ошибки приема/передачи управляющих параметров и команд устройствам, приводят

либо к от­казам и сбоям в работе устройств, либо позволяют зло­умышленнику

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

Файловая система использует значительное число функций операционной системы —

управление процес­сами, устройствами, распределением памяти и т.д.

Соот­ветственно, ошибки в этих компонентах автоматически распространяются и

на файловую систему. Кроме того, файловая система может содержать и

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

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

механизмов контроля. Таким образом, средства обеспечения безо­пасности,

принадлежащие операционной системе, ока­зываются непосредственно связанными с

механизмами управления файловой системой. Наличие ошибок в ме­ханизмах

управления файловой системой способна при­вести к нарушению функционирования

и безопасности всей ВС в целом.

Идентификация и аутентификация являются отправ­ными точками в

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

содержит специальные файлы, в которых хранятся имена и паро­ли, на основании

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

только корректную реализацию процедур идентификации и ау­тентификации, но и

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

иначе злоумышленник легко сможет выдать себя за легального пользователя и

получить соответствующие полномочия.

3.3.3.2. Сервисное программное обеспечение

Термин «сервисное программное обеспечение» включает в себя компиляторы,

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

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

специальные привиле­гии, превышающие привилегии работающего с ними

пользователя. Поэтому о сервисном программном обес­печении можно говорить как

о множестве привилегиро­ванных утилит.

Привилегированные утилиты, как правило, являются сложными программами и часто

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

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

принятые в ней ог­раничения и требования безопасности даже при наличии

собственной защиты. Это означает, что привилегиро­ванные утилиты являются

потенциально опасными с точки зрения защиты ВС в целом.

Наличие ошибок в реализации защиты привилегиро­ванных утилит или каналов

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

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

утилиты, с которой он рабо­тает. Наиболее известным примером подобного родя

яв­ляются многочисленные ошибки в системных утилитах ОС UNIX с установленным

битом SUID (U5 в Приложе­нии IV).

3.3.3.3. Прикладное программное обеспечение

Нарушения в функционировании вычислительных систем, вызванные неумышленными

ошибками в при­кладном программном обеспечении, обычно ограничи­ваются только

содержащим эту ошибку процессом, ко­торый либо некорректно функционирует либо

останав­ливается или зацикливается. Однако это не означает, что все ошибки в

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

внесенные программные закладки, вирусы, «троянские кони» и «логи­ческие

бомбы» находятся именно на уровне прикладного программного обеспечения.

Объектами их атак .потен­циально могут стать любые компоненты вычислитель­ной

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

вплоть до выведения опера­ционной системы из строя. В этом случае успех атаки

за­висит от того, насколько защищена конкретная ОС от разрушительных действий

прикладных программ. Мно­гопользовательские многозадачные ОС (такие, как

Unix) сравнительно легко справляются с подобной проблемой, а широко

распространенные DOS и Windows в этой ситуации оказываются практически

бессильными.

3.3.4. Результаты исследования таксономии ИЗ и их практическое применение

Рассмотренная таксономия ИЗ, основанная на ре­зультатах исследования [I],

дает достаточно полное представление о классификации ИЗ с точки зрения

источника их появления, этапа возникновения и размеще­ния в ВС. Эти

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

ценность для пассивного исследования и классификации ИЗ. С точки зрения

поиска путей и способов противостояния угрозам безопасности этого

недостаточно, так как отсутствует классификация причин нарушений

безопасности. По­этому представляется необходимым развить эти иссле­дования и

провести анализ случаев нарушения безопас­ности с точки зрения таксономии

причин появления ИЗ, чтобы получить представление о первоисточниках дан­ного

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

новых технологий и средств защиты, устраняющих причины существования ИЗ, и,

следовательно, обеспечивающих максимальную безопасность.

3.4. Исследование причин возникновения ИЗ

По мнений авторов, сложившаяся практика исследо­вания случаев нарушения

безопасности, уделяющая ос­новное внимание методам и средствам преодоления

за­щиты обладает существенным недостатком — отталки­ваясь от действий

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

преодоления средств защиты и не позволяет выявить недостатки средств

обеспечения безопасности. Кроме того, подоб­ный подход сразу разделяет все

случаи нарушения безо­пасности на умышленные, классифицируемые но спосо­бам

преодоления защиты, и неумышленные, обуслов­ленные ошибкам программирования.

Авторы придер­живаются норматической точки зрения на этот вопрос — важен сам

факт нарушения безопасности и те меры, которые необходимо предпринять для

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

этой точки зрения залог успешных действий злоумышленника, как и предпосылки

случайных нару­шений, предопределен свойствами самой ВС — ее архи­тектурой,

реализацией и администрированием. Это оз­начает что в основе каждого факта

нарушения безопас­ности ВС лежит соответствующий изъян средств защи­ты

обусловивший успешное осуществление атаки. Ана­лиз случаев нарушения

безопасности должен основы­ваться не столько на исследовании методов,

используе­мых нарушителем сколько на выявлении свойств систе­мы позволивших

ему осуществить свои действия.

Поэтому для решения задачи данной главы — опре­деления обстоятельств, приводящих

к успешной реали­зации угроз безопасности, их систематизации и выявле­ния

первопричин их появления предлагается разрабо­танная авторами таксономия причин

нарушений безо­пасности ВС, или причин возникновения ИЗ,

которая связывает случаи нарушения безопасности с принципами организации защиты

ВС, обусловившими их осуществимость. Таксономия причин возникновения ИЗ

должна дать ответ на имеющий ключевое значение с практиче­ской точки зрения

вопрос: что явилось причиной успеш­ною осуществления нарушения безопасности в

том или ином случае ? Для ответа на него необходимо выявить те свойства и

особенности архитектуры ВС, которые при­вели к возможности успешного

осуществления соответ­ствующих атак. Только знание природы этих причин

по­зволит оценить способность системы противостоять ата­кам, а также понять

природу недостатков, присущих су­ществующим средствам обеспечения безопасности,

и по­строить защищенную систему, лишенную этих недостат­ков.

3.4.1. Таксономия причин возникновения ИЗ

Рассмотрим с этой точки зрения известные случаи нарушения безопасности ВС,

используя в качестве при­меров статистику из Приложения IV. Анализ показыва­ет,

что все случаи произошли по одной из следующих причин (рис. 3.1):

1. Выбор модели безопасности, не соответствующей назначению или

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

реализации рассмотрены в главе 4 II тома) должна соответствовать как

требованиям безопасности, предъявляемым к ВС, так и принятой в ней

концепции обработки информации, в основном определяемой архитектурой ОС. В

настоя­щий момент наблюдается определенное несоответствие между моделями

безопасности и архитектурой ОС. Фактически формальные модели безопасности

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

интерпретации, чтобы приспособить к конкретной ОС. При этом приходится идти на

опреде­ленные компромиссы, и может оказаться, что модель безопасности в ходе

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

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

противном случае, несмотря на все достоинства модели, гарантированного ею

уровня безопасное ги дос­тичь не удастся.

2. Неправильное внедрение модели безопасности. Несмотря на правильный

выбор модели безопасности, ее реализация и применение к архитектуре

конкретной ОС в силу свойств самой модели или ОС было проведено не­удачно.

Это означает, что в ходе реализации были поте­ряны теоретические достижения,

полученные при фор­мальном доказательстве безопасности модели. Это наи­более

распространенная причина нарушения безопасно­сти ВС. Обычно неправильное

внедрение модели безопасности в систему выражается в недостаточном

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

объектам, а также во введении раз­личных исключений из предусмотренных

моделью пра­вил разграничения доступа типа привилегированных процессов,

утилит и т. д. В качестве примеров можно привести случаи I1, I4, I6, I7, MU3,

Bl. UN1, U4, U5, U14 из Приложения IV.

3. Отсутствие идентификации и/или аутентификации субъектов и объектов.

Во многих современных ОС (различные версии Unix, Novell NetWare, Windows)

иден­тификация и аутентификация субъектов и объектов взаимодействия находятся

на весьма примитивном уров­не — субъект может сравнительно легко выдать себя

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

Кроме того, можно внедрить в систему «ложный» объект, который будет при

взаимодействии выдавать себя за другой объект. Часто иденти­фикация и

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

уровни взаимо­действия; так, например, в ОС Novell NetWare преду­смотрена

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

сервера. В стандарт­ной версии ОС Unix аутентификация пользователей

на­ходится на очень примитивном уровне: программы под­бора пароля легко

справляются со своей задачей при на­личии у злоумышленника идентификатора

пользователя и зашифрованного пароля. Ряд служб ОС Unix (в первую очередь

сетевые службы, использующие стек протоколов TCP/IP) и всемирная

информационная сеть Internet в силу сложившихся обстоятельств и необходимости

соблюсти требования по совместимости в глобальном масштабе вообще не

предусматривают аутентификации при сете­вых взаимодействиях [21] (пример MU1

из Приложения IV).

4. Отсутствие контроля целостности средств обеспе­чения безопасности.

Во многих ОС контролю целостно­сти самих механизмов, реализующих функции

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

распространения РПС контроль целостности приобретает решающее значение.

Многие системы до­пускают прозрачную для служб безопасности подмену

компонентов. Например, ОС Unix традиционно по­строена таким образом, что для

обеспечения ее функ­ционирования многие процессы должны выполняться с уровнем

полномочий, превышающим обычный пользо­вательский уровень (с помощью

механизма замены прав пользователя на права владельца программы). Такие

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

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

целост­ности в ходе эксплуатации. С точки зрения безопасно­сти, такая

ситуация является недопустимой, так как не соблюдается принцип минимальной

достаточности при распределении полномочий процессов и пользователей. Список

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

должен быть максимально ограничен. Этого можно достичь путем

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

безопасности и целостности в рам­ках ядра ОС (пример U1 Приложения IV).

5. Ошибки, допущенные в ходе программной реали­зации средств

обеспечения безопасности. Эта группа причин нарушения безопасности будет

существовать до тех пор, пока не появятся технологии программирова­ния,

гарантирующие производство безошибочных про­грамм. По-видимому, такие

технологии не появятся и ошибки такого рода будут возникать всегда.

Исчерпы­вающее тестирование и верификация программных про­дуктов (особенно

реализующих функции защиты) позво­ляют сократить вероятность появления

подобных ошибок (примеры МТ1, MU2, DT1, Dl, U2, U3, U7, |U11, U 12 Приложения

IV).

6. Наличие средств отладки и тестирования в конеч­ных продуктах.

Многие разработчики оставляют в ком­мерческих продуктах т. н. «люки», «дыры»,

отладочные возможности и т.д. Наиболее известные примеры — от­ладочная опция

в программе sendmail и встроенный от­ладчик ОС Novell NetWare. Причины, по

которым это происходит, вполне понятны — программные продукты становятся все

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

Следователь­но, для определения причин сбоев и ошибок уже в .про­цессе

эксплуатации разработчикам приходится остав­лять в своих продуктах

возможности для отладки и ди­агностики в ходе эксплуатации. Очевидно, что для

тех ситуаций, где безопасность имеет решающее значение, применение подобной

практики недопустимо (пример U 10 Приложения IV).

7. Ошибки администрирования. Наличие самых со­временных и совершенных

средств защиты не гаранти­рует от возможных нарушений безопасности, так как в

безопасности любой системы присутствует человеческий фактор — администратор,

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

все усилия разработчиков будут сведены на нет. Ошибки администрирования

являются достаточно распростра­ненной причиной нарушений безопасности, но

часто списываются на ошибки разработчиков средств защиты.

Предложенный подход к классификации причин нару­шения безопасности в отличие

от существующих подходов позволяет определить полное множество независимых

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

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

безопасности системы.

Рис. 3.1 Таксономия прпичин нарушения безопасности ВС

3.4.2. Взаимосвязь таксономии причин нарушения безопасности и классификации ИЗ

Рассмотрим взаимосвязь между рассмотренной таксономией причин возникновения

ИЗ и предложенной в работе [1] классификацией источников появления и этапов

внедрения ИЗ.

Сопоставление предложенной таксономии причин нарушения безопасности и

классификации источников появления ИЗ [I] показано на рис. 3.2.

Рисунок 3.2 демонстрирует, что источником появле­ния наибольшего количества

категорий ИЗ является не­правильное внедрение модели безопасности и ошибки в

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

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

На рис. 3.3 показано соответствие между причинами нарушений безопасности и

классификацией ИЗ по этапу внесения [I].

Из рис 3.3 видно, что появление основных причин нарушения безопасности

закладывается на этапе разра­ботки, причем в основном на стадии задания

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

составления спецификаций является одним из са­мых трудоемких, а последствия

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

распространяются на все взаимосвязанные компоненты системы.

Рис. 3.2 Сопоставление таксономии причин нарушения безопасности и

классификации источников появления ИЗ.

Рис. 3.3 Сопоставление таксономии причин нарушения безопасности и

классификации ИЗ по этапу внесения.

Поскольку большинство причин нарушения безопасности определяет появление ИЗ

практически в любом компоненте ВС, сопоставление причин нарушения i

безо­пасности с классификацией ИЗ по размещению в системе проводить

нецелесообразно.

Перекрестный анализ таксономии причин наруше­ний безопасности и классификаций

ИЗ по источнику по­явления и этапу внесения показывает, что наиболее

зна­чимые причины (неправильное внедрение модели безо­пасности и ошибки

программной реализации) действуют в ходе процесса разработки и реализации.

Следователь­но, именно на этих этапах должны быть сосредоточены основные

усилия при создании защищенных систем.

Приведенное сопоставление показывает, что пред­ложенные причины нарушения

безопасности полностью охватывают как все аспекты появления, так и этапы

вне­сения ИЗ. Таким образом, предложенная таксономия причин нарушения

безопасности полностью подтвер­ждается существующими исследованиями ИЗ,

однако носит более принципиальный характер и, следовательно, обладает более

высокой степенью общности.

3.5 Заключение

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

значимость каждой из причин и выявить этапы разработки ВС, на которых они

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

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

со­ставляющие безопасности ВС, которые закладываются на ранних стадиях

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

защиты. Все эти действия можно объединить в один этап — выбор технологии

защиты ВС.

Кроме того, данная таксономия имеет и самостоя­тельное значение — ее можно

использовать как основу для анализа и экспериментального тестирования систем

защиты, так как она позволяет выбрать направления и способы проведения

тестовых атак на наиболее уязви­мые компоненты систем защиты. На основании

данного подхода в Центре защиты информации Санкт-Петер­бургского Технического

Университета были проведены исследования безопасности распространенных ОС и

компьютерных сетей, основные результаты которых приведены в работах [20, 21].

Эти результаты на практи­ке подтверждают правильность предложенной

таксоно­мии и доказывают адекватность рассмотренных причин нарушения

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

Разработанная авторами таксономия причин нару­шения безопасности является

первым и необходимым этапом для решения задач построения защищенных сис­тем

обработки информации, поставленных в первой гла­ве, и может служить отправной

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

второй главе, и корректного воплощения моделей безопасности (этому вопросу

будет посвящена четвертая глава II тома). Это позволяет говорить о создании

каче­ственно новой, научно обоснованной и подтвержденной существующей

практикой нарушения безопасности ВС технологии построения защищенных систем,

которая будет подробно рассмотрена в пятой главе II тома данной книги.

Литература к главе 3

1. Carl E. Landwehr, Alan R. Bull, John P. McDermott, and William S.Choi.

Information Technology Division, Code 5542, Naval Re­search Laboratory,

Washington, D.C. 20375-5337// A Taxonomy of Computer Security Flaws, with

Examples.

2. Abbott R. P. Chin J. S., Donnelley J. E„ Konigsford \V. L„ Tokubo S.

and Webb D. A. 1976 Security analysis and enhancements of computer

operating system. NBS1R 76-1041. National Bureau of Standards, ICST. April

1976.

3. Andersen J. P. 1972. Computer security technology planning study.

ESD-TR-73-51. Vols I and II, NTIS AD 758206,' Hanscom Field. Bedford, MA

(October 1972).

4. Bisbey II. R. and Hollingwoith, D. 1978. Protection analysis

project report. ISI/RR-78-13, DT[C AD A056816. USC/Information

Sci­ences Institute (May 1978).

5. Brehmer С. L. and Carl J. R. Hollingworth, 1993 Incorporating IEEE

Standard 1044 into your anomaly tracking process. CrossTalk, J. Defense

Software Engineering, 6 (Jan. 1993), 9-16.

6. Chillarege R., Bhandari I. S., Chaar J. K.. Halliday M. J., Moebus D.

S., Ray B. K.. and Wong, M-Y. 1992. Orthogonal defect classification-a

concept for in-process measurements. IEEE Trans. on Soft­ware Engineering,

18,11, (Nov. 1992), 943-956.

7. Cohen, F. 1984. Computer viruses: theory and experiments, 7th

DoD/NBS Computer Security Conference, Gaithersburg. MD (Sept. 1984). 240-263.

8. Federal Criteria for Information Technology Security. USA Na­tional

Institute of Standards and Technology & USA National Se­curity Agency.

9. Florae W. A. 1992. Software Quality Measurement: A Framework for

Counting Problems and Defects. CMU/SEI-92-TR-22, Software Engineering

Institute, Pittsburgh, PA. (Sept.).

10. Lampson, B. W. 1973. A note on the confinement problem, Comm.

ACM 16.10 (October), 613-615.

11. Leveson N. and Turner С. S. 1992. An investigation of the Therac-25

accidents. UCI TR92-108, Inf. and Comp. Sci. Dept, ofCal.-lrvinc. Irvinc,

CA.

12. Linde R. R. 1975. Operating system penetration. AFIPS national

computer Conference, 361—368.

13. McDermott J.P. 1988. A technique for removing fin important class of

Trojan horses from high order languages, Proc.11th National Com­puter

Security Conference NBS/NCSC, Gaithersburg, MD (October.). 114-117.

14. Pfleeger С. Р. 1989. Security in Computing. Prentice Hall,

Engle-wood Cliffs, NJ.

15. Schoch J. F. and Hupp J. A. 1982. The "worm" programs-early

ex­perience with a distributed computation. Comm. ACM.25.3 (March) 172-180.

16. Sullivan M.R. and Chillarege R. 1992. A comparison of software

de­fects in database management systems and operating systems. Proc.22nd

Int. Sump. on Fault-Tolerant Computer Systems (FTCS-22), Boston, MA IEEE CS

Press.

17. Weiss D. M. and Basili V. R. 1985. Evaluating software development

by analysis of changes: some data from the Software Engineering Laboratory.

IEEE Trans. Software Engineering SE-11,2 (February), 157-168.'

18. Use of A Taxonomy of Security Faults. COAST Laboratory, Purdue

University, Technical Report TR-96-051.

19. Д. Зегжда, А. Мешков. П. Семьяпов. Д. Шведов. Как

противо­стоять вирусной атаке. BHV — СПб, 1995. 318с.

20. Теория и практика обеспечения информационной безопасности /Под ред.

П. Д. Зегжда. M.: изд-во Агентства «Яхтсмен», 1996.

21. Атака через Internet /Под ред. П. Д. Зегжда.. С-Пб. Мир и семья. 1997.

Приложение I

«Федеральных критериев безопасности информационных технологий»

Данное приложение представляет собой ранжиро­ванный перечень функциональных

требований, содер­жащийся в соответствующем разделе «Федеральных критериев»,

отражает только принципиальную суть тре­бований и не претендует на перевод

стандарта как; руко­водящего документа.

Описание требований следует приведенным в разделе 2.8 требованиям в порядке

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

требова­ний начинается с его краткого описания и обзора Преду­смотренных

уровней ранжирования; идентификаторы уровней сохранены в том виде, в каком

они присутствуют в первоисточнике. Описание требований на каждом уровне

приводится в виде дополнений и изменений по сравнению с предыдущим уровнем.

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

Идентификация и аутентификация принадлежат к основным компонентам политики

безопасности. Отсут­ствие или низкая надежность процедур идентификации и/или

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

путем предотвраще­ния их регистрации в системе и отказа в получении доступа к

ее ресурсам. Надежность механизма идет идентификации/аутентификации напрямую

влияет на уровень безопасности всей системы в целом. При необходимости эти

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

идентификации и аутентификации.

Требования идентификации и аутентификации ран­жируются на основании уровня

предоставляемых воз­можностей. Уровень IA-1 включает только

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

контроля доступа в помещения. В которых кроме идентификации и аутентификации

реали­зована только функция pегистрации входа. На уровне IA-2

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

конкретного субъекта и позволяющих выполнить его авторизацию (предоставить ему

соответствующие права для работы в системе). Этот уровень наиболее широко

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

определяющие степень привилегированности субъектов и уровень конфиденциальности

объектов. Данные воз­можности расширяются на уровне IA-3 путем

регламен­тации принципов обработки результатов аутентификации, а также

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

идентификации и аутентификации пользователей. Этот уровень исполь­зуется в

системах с четко определенной политикой управления доступом. На уровне IA-4

происходит дальнейшее расширение требований, заключающееся в пре­доставлении

возможностей установки специальных ме­ханизмов идентификации и аутентификации и

их назначения для индивидуальною пользователя и/или группы пользователей. На

уровне IA-5 требуется реализация Не­скольких независимых механизмов

аутентификации пользователей.

• Уровень IA-1. Минимальная идентификация и аутентификация

1. ТСВ должно обеспечивать возможность иденти­фикации каждого

пользователя до начала выполнения им любых действий. ТСВ должно устанавливать

инди­видуальные полномочия пользователя в соответствии с его уникальным

идентификатором. ТСВ должно обеспе­чивать возможность установления

соответствия каждого регистрируемого в системе события с идентификатором

инициировавшего его пользователя.

2. ТСВ должно использовать механизм аутентифика­ции но паролю для

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

3. ТСВ должно обеспечивать защиту данных, исполь­зуемых для

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

неуполномоченных пользователей.

• Уровень IA-2. Идентификация, аутентификация и авторизация

1. Без изменений.

2. Изменение. Используемые для аутентификации данные должны включать

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

пароль), так и для реализации политики безопасности (атрибуты пользователей,

имена групп и ролей, уровни привилегированности субъектов и

конфиденциальности объектов, временные интервалы и т. д.). Эти данные должны

использоваться ТСВ для контроля действий пользователя в соответствии с

действующей в системе политикой безопасности.

3. Без изменений.

• Уровень IA-3. Идентификация и аутентификация с контролем исключительных

ситуаций

1. Без изменений.

2. Без изменений.

3. Дополнение. ТСВ должно обеспечивать выполне­ние процедуры

аутентификации вне зависимое от ре­зультата проведения процедуры идентификации

(на­пример, требовать пароль даже в случае ввода несущест­вующего имени

пользователя). ТСВ должно прекращать выполнение процедуры входа в

систему в случае последовательного неудачного проведения идентификации и/или

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

ТСВ должно оповестить администратора, зафик­сировать данное событие в

системном журнале и приос­тановить дальнейшее выполнение процедуры входа в

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

доступе вообще.

4. ТСВ должно обеспечивать хранение, защиту и

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

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

сис­теме.

• Уровень IA-4. Назначение процедур идентифика­ции и аутентификации

1. Дополнение. ТСВ должно обеспечивать возмож­ность идентификации

каждого привилегированного субъекта.

2. Дополнение. ТСВ должно обеспечивать возмож­ность внедрения новых

механизмов аутентификации (например, на основе электронных карт или

биометриче­ских характеристик), дополняющих уже существующие. ТСВ должно

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

каждому поль­зователю в зависимости от его атрибутов.

3. Без изменений.

4. Без изменений.

• Уровень IA-5. Комбинированное применение неза­висимых механизмов

идентификации и аутентифика­ции

1. Без изменений.

2. Дополнение. К каждому пользователю должны применяться два или более

независимых механизма ау­тентификации. Аутентификация считается успешной,

ес­ли все назначенные пользователю механизмы аутенти­фикации подтвердили

подлинность его идентификатора. ТСВ должно обеспечивать возможность

назначения пользователю механизмов аутентификации в соответст­вии с

атрибутами политики безопасности.

3. Без изменений.

4. Без изменений.

2. Регистрация пользователя в системе

Управление регистрацией пользователя в системе по­зволяет соблюсти требования

политики аудита с помо­щью учета места, времени, способа и режима

подключе­ния пользователя к системе. Кроме того, управление ре­гистрацией

обеспечивает гарантию того, что зарегист­рированный пользователь будет нести

ответственность за выполняемые действия.

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

контролироваться ТСВ. Должны рыть четко определены условия, при которых

возможно соз­дание субъекта или субъектов, представляющих данного

пользователя. Эти условия должны определяться на ос­новании значений

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

возможные роли, степень полномочий, период разрешенного для работы времени,

доступный ему сервис и ресурсы систе­мы.

Требования к процедуре регистрации в системе ранжируются на основании

обеспечиваемых возможно­стей защиты. Требования уровня SE-1 включают в себя

только простейшие возможности по управлению реги­страцией в системе в

соответствии с принадлежностью пользователя к определенной группе или

выполнения им конкретной роли, а также степени его привилегиро­ванности. Этот

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

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

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

иден­тификации и аутентификации (по сути, идентификация и аутентификация могут

считаться начальными проце­дурами управления регистрацией пользователя в

систе­ме). Уровень SE-2 дополнен возможностями учета вре­мени и места

регистрации пользователя в системе. На уровне SE-3 у пользователя

появляются возможности блокировать (приостанавливать) и возобновлять сеанс

работы с системой.

• Уровень SE-1. Базовый механизм управления реги­страцией пользователя в системе

1. Перед началом выполнения процедуры регистра­ции пользователя в системе

(процедуры login) TCB должно соответствующим сообщением предупреждать

пользователя о недопустимости попытки неавторизо­ванного проникновения в

систему и о возможных по­следствиях подобных действий.

2. Перед началом сеанса работы (до разрешения ре­гистрации) TCB должно

выполнить процедуры иденти­фикации и аутентификации пользователя. Если в TCB

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

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

количе­ства одновременных подключений, запрещающий пре­вышение некоторого

определенного числа.

3. TCB должно осуществлять регистрацию только соответствии с

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

предоставления дос­тупа к системе определяются на основании атрибутов

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

явным образом, использу­ются условия, принятые по умолчанию (например,

ус­пешная аутентификация пользователя).

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

которых уполномоченный пользо­ватель (администратор) может управлять

атрибутами пользователей, используемыми при их регистрации в системе. Должны

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

озна­комиться с собственными атрибутами, но не изменить их.

5. После успешной регистрации пользователя в сис­теме TCB должно

предоставлять ему следующую ин­формацию (без возможности ее модификации):

· место, время, режим, терминал или порт послед­ней успешной

регистрации пользователя;

· количество неуспешных попыток регистрации с использованием ею

идентификатора, зафиксиро­ванное между последним и текущим сеансом рабо­ты.

6. TCB должно обеспечивать блокирование (приоста­новку) или прерывание

и завершение сеанса работы пользователя по истечению устанавливаемого

админи­стратором интервала отсутствия активности со стороны пользователя.

• Уровень SE-2. Управление регистрацией в системе с учетом времени и места

подключения

1. Без изменений.

2. Без изменений.

3. Дополнение. ТСВ должно реализовывать меха­низм

разрешения/запрещения регистрации в системе на основании контроля допустимого

периода времени реги­страции. Условия контроля периода времени должны быть

определены для времени суток, дней недели и от­дельных календарных дат. ТСВ

должно реализовывать механизм разреше­ния/запрещения регистрации в системе па

основании контроля местоположения пользователя (используемых терминалов или

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

подключе­ния пользователей по каналам связи.

4. Без изменений.

5. Без изменений.

6. Без изменений.

• Уровень SE-3. Блокировка и восстановление сеан­са работы пользователя

1. Без изменений.

2. Без изменений.

3. Без изменений.

4. Без изменений.

5. Без изменений.

6. Дополнение. ТСВ должно поддерживать механизм блокировки и

возобновления сеанса работы пользовате­ля по его команде или по истечению

заданного админи­стратором интервала отсутствия активности со стороны

пользователя. Этот механизм должен обеспечивать:

· очистку экрана терминала для предотвращения возможности считывания

с него информации и блокировку клавиатуры и других средств ввода информации;

· запрет па любые действия в системе с использова­нием

заблокированных средств ввода-вывода ин­формации на время приостановки сеанса

пользо­вателя;

· выполнение процедур идентификации и аутенти­фикации пользователя

перед возобновлением се­анса работы.

3. Обеспечение прямого взаимодействия с ТСВ

Функциональные требования, обеспечивающие пря­мое взаимодействие с ТСВ,

ранжируются в зависимости от допустимой сферы применения и обеспечиваемых

возможностей защиты. Минимальный уровень tp-i предполагает наличие

гарантированного канала взаи­модействия пользователя с ТСВ, используемого для

вы­полнения процедуры регистрации в системе. На уровне ТР-2

прямое взаимодействие с ТСВ обеспечивается не только для процесса регистрации,

но и для других про­цессов, требующих обеспечения гарантированно досто­верного

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

точки зрения безопасности (например, администрирование атрибутов безопасности),

и ТСВ. На уровне ТР-3 обеспечивается гарантирование достоверный канал

взаимодействия ме­жду пользователем и доверенными приложениями, по­зволяющими

ему работать с критичной информацией.

• Уровень ТР-1. Обеспечение прямого взаимодейст­вия с ТСВ для процедуры

регистрации в системе

ТСВ должно обеспечивать гарантированно досто­верный канал взаимодействия с

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

регистрации в системе. Инициация прямого взаимодей­ствия с ТСВ должна

осуществляться только со стороны пользователя.

• Уровень ТР-2. Обеспечение прямого взаимодейст­вия пользователя с ТСВ

Дополнение. ТСВ должно обеспечивать гарантиро­ванно достоверный канал для

всех видов взаимодейст­вий с пользователем (регистрация в системе, изменение

атрибутов защиты и т.д.). Данный канал должен преду­сматривать возможность

инициации как со стороны пользователя, так н ТСВ, и должен быть изолирован от

других аналогичных каналов и обладать уникальными характеристиками.

• Уровень ТР-3. Обеспечение прямого взаимодейст­вия пользователя с

доверенными приложениями

Дополнение. ТСВ должно обеспечивать гарантиро­ванно достоверный канал прямого

взаимодействия пользователя с доверенными приложениями (например, для ввода

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

4. Регистрация и учет событий в системе (аудит)

Требования к регистрации и учету событий ранжи­руются в зависимости от

предоставляемых возможно­стей отбора подлежащих регистрации событий,

мощно­сти средств анализа журнала событий и степени монито­ринга действий

пользователя. Требования к аудиту под­разделяются на четыре группы:

· защита и управление доступом к системному жур­налу событий;

· определение множества подлежащих регистрации событий:

· фиксация и хранение зарегистрированных Собы­тий в журнале;

· анализ журнала событий и формирование отчетов.

Уровень AD-1 включает минимальные требования к аудиту, которым должны

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

защиты. На уровне AD-2 эти требования усиливаются как за счет

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

новых функций по управлению процессом регистрации и учета. На уровне AD-3

появляются требования к наличию дове­ренных средств аудита, предоставляющих

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

взаимодействие с оператором за счет исполь­зования графического представления

данных и т.п. Уро­вень AD-4 характеризуется введением требования

выяв­ления критичных с точки зрения безопасности событий и объявления тревоги в

случае их обнаружения. На уровне AD-5 требуется обеспечить такой

же контроль в режиме реального времени (осуществлять в режиме реального времени

обнаружение попыток нарушений безопасно­сти).

• Уровень AD-1. Минимальный аудит

1. ТСВ должно обеспечивать возможность создания, хранения, ведения

журнала аудита, содержащего регист­рацию обращений к защищенным объектам. ТСВ

долж­но обеспечивать защиту журнала от несанкционирован­ного доступа,

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

уполномочен­ным пользователям.

2. ТСВ должно обеспечивать регистрацию в журнале аудита следующих

типов событий:

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

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

· доступ к объектам, помещение объектов в доступную пользователю

область, запуск программ;

· действия, предпринятые операторами и админист­раторами,

ответственными за безопасность.

Для поддержки в системе политики обеспечения ра­ботоспособности и контроля за

распределением ресурсов должны регистрироваться попытки несанкционирован­ных

запросов на выделение ресурсов и попытки получе­ния доступа к ресурсам,

предоставленным другим субъ­ектам.

При поддержке в системе нормативного управле­ния доступом ТСВ должно иметь

возможность осуще­ствлять регистрацию и учет изменений меток,

класси­фицирующих уровень информации. Если нормативное управление доступом

применяется для контроля пото­ков информации между субъектами, ТСВ должно

иметь возможность регистрировать в журнале аудита события, которые

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

информа­ции.

3. Для каждого регистрируемого события в журнал аудита заносятся:

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

· идентификатор пользователя, инициировавшего событие;

· результат выполнения действия, соответствующе­го событию (успешное

завершение или отказ).

При запросах на доступ к объектам или их удаление должны также

регистрироваться имя и атрибуты объек­та.

4. Администратор должен иметь возможность выбо­ра регистрируемых

событий и действий для каждого пользователя или объекта на основании

соответствую­щих атрибутов политики безопасности.

• Уровень AD-2. Базовые требования к аудиту

1. Без изменений.

2. Изменение. ТСВ должно иметь возможность реги­стрировать следующие

типы событий:

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

регистрации пользователя в системе;

· события, связанные с управлением доступом, от­носящиеся к

определенному пользователю, субъ­екту, объекту или их атрибутам политики

безо­пасности;

· создание, удаление субъектов и объектов, осуще­ствление доступа,

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

на­значение и отзыв привилегий;

· действия, выполняемые операторами и админист­раторами,

ответственными за безопасность, приви­легированные операции, такие, как

модификация элементов ТСВ, настройка ТСВ, изменение пара­метров ТСВ и

системных привилегий, изменение атрибутов пользователей, изменение состава и

ти­пов регистрируемых в журнале аудита событий.

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

и их параметров. ТСВ должно содержать средства защиты и управления

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

ним только администратору.

3. Без изменений.

4. Дополнение. В ТСВ должны присутствовать за­щищенные средства

запуска и остановки процесса ауди­та. Доступ к этим средствам, равно как и к

средствам просмотра журнала аудита, должен быть разрешен толь­ко

администратору.

ТСВ также должно включать средства управления аудитом, доступные только для

администратора которые позволяют осуществлять:

· создание и удаление журнала аудита, контроль и изменение его размеров:

· форматирование и упаковку записей журнала ау­дита:

· обеспечение целостности журнала аудита при сбо­ях и отказах системы.

• Уровень AD-3. Развитые средства аудита

1. Без изменений.

2. Без изменений.

3. Без изменений.

4. Дополнение. В ТСВ должны присутствовать спе­циально

разработанные средства контроля целостно­сти журнала аудита, а также средства

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

5. Средства просмотра журнала аудита должны пре­доставлять

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

проверки. Данные средства должны быть защищены от несанкционирован­ного

доступа.

ТСВ также должно иметь средства обработки жур­нала аудита, позволяющие

осуществлять выборочный анализ:

· действий одного или нескольких пользователей:

· действий над одним или несколькими объектами или ресурсами:

· всех или подмножества исключительных ситуа­ций:

· действий, ассоциированных с заданными атрибу­тами политики

безопасности субъектов и объек­тов.

Средства просмотра журнала аудита должны предусматривать возможность работы

параллельно со штат­ным функционированием системы.

• Уровень AD-4. Обнаружение попыток нарушения безопасности

1. Без изменений.

2. Дополнение. ТСВ должно содержать средства мо­ниторинга событий,

возникновение которых может оз­начать угрозу нарушения безопасности. Эти

средства должны незамедлительно оповещать администратора системы и

останавливать (прекращать) выполнение вы­звавшего это событие процесса или

всей системы.

3. Без изменений.

4. Без изменений.

5. Без изменений.

• Уровень AD-5. Выявление попыток нарушения безопасности в режиме реального

времени

1. Без изменений.

2. Без изменений.

3. Без изменений.

4. Без изменений.

5. Дополнение. ТСВ должно обеспечивать возмож­ность регистрации

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

и опо­вещать о них администратора. Эта возможность должна реализовываться

специальным механизмом мониторинга событий, критичных с точки зрения политики

безопасности.

5. Политика управления доступом (произвольное и нормативное управление доступом)

Требования к реализации политики произвольного управления доступом могут быть

ранжированы в зави­симости от области применения политики (ко всем субъ­ектам

и объектам системы, к выбранным подмножествам субъектов и объектов, в

зависимости от атрибутов безо­пасности субъектов и объектов) и

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

прав доступа, возможность организации кон­троля доступа к объектам

пользователей только с их разрешения). Кроме того, эти требования можно

ранжи­ровать в зависимости от уровня абстракции, на котором рассматриваются

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

в файле).

Для ранжирования требований нормативного управ­ления доступом могут

использоваться те же самые кри­терии, однако описание уровня рассмотрения

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

Поскольку нормативное управление доступом основано на контроле информационных

потоков, долж­ны контролироваться соответствующие атрибуты субъ­ектов

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

Требования к управлению доступом ранжированы по четырем уровням. На уровне

АС-1 устанавливаются ми­нимальные требования к реализации политики

управле­ния доступом и допускается осуществление управлением доступа только по

отношению к некоторому подмноже­ству субъектов и объектов, а также ограниченные

воз­можности управления атрибутами безопасности. На уровне АС-2

требования к политике безопасности рас­ширяются в сторону возможности

одновременного при­менения нескольких политик управления доступом и средств

управления экспортом и импортом объектом. На уровне АС-3 управление доступом

должно поддержи­ваться для всех субъектов и объектов. Если реализована политика

нормативного управления доступом, она должна использовать все атрибуты

безопасности объек­тов и субъектов. На данном уровне также требуется про­водить

назначение прав доступа к объектам на основа­нии их типа. На следующем уровне

АС-4 управление доступом расширяется путем добавления атрибутов вре­мени и

местоположения. Появляется возможность Зада­ния прав пользователей в

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

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

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

Предполагается, что этот уровень будет использоваться в системах, где требуется

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

• Уровень АС-1. Минимальное управление доступом

1. Задание множества атрибутов безопасности объек­тов и субъектов. ТСВ

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

Атрибуты субъекта должны включать индивидуальный и группо­вой идентификаторы

пользователя, представленного этим субъектом. Атрибуты объекта должны

включать набор возможных прав доступа к этому объекту (чтение, запись,

выполнение).

2. Управление атрибутами безопасности объектов и субъектов. ТСВ должно

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

объек­тов и обеспечивать их безусловное выполнение. Эти правила должны быть

основаны на следующих положе­ниях:

· субъект может разрешать доступ к объекту для другого субъекта

только в том случае, если он сам обладает этим правом доступа:

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

совместного использования объ­ектов и управлять им на основе индивидуальных и

групповых атрибутов субъектов:

· пользователи должны обладать средствами для контроля за процессом

передачи прав доступа и иметь возможность ограничивать его.

Если для разных подмножеств субъектов и объектов определены различные правила

управления атрибутами безопасности, то их реализация должна быть

согласо­ванной и не противоречить политике безопасности.

3. Управление доступом субъектов к объектам. ТСВ должно определять

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

объектам и обеспечивать их соблюдение. Эти правила должны быть основаны на

атрибутах субъектов и объектов и обеспе­чивать защиту объектов от

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

охваты­вать четко определенное подмножество субъектов и объ­ектов, а также

принадлежащих им атрибутов безопасно­сти. Должна быть обеспечена возможность

применения различных правил назначения полномочий для различ­ных групп

субъектов и объектов, в этом случае реализа­ция этих правил должна быть

согласованной и не проти­воречить политике безопасности.

4. Контроль за созданием и уничтожением объектов и субъектов. ТСВ

должно контролировав создание и уничтожение субъектов и объектов, а также

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

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

в распоря­жение системы. Вся содержащаяся в нем информация, в том числе и

зашифрованная, должна быть уничтожена.

5. Инкапсуляция объектов. Если в ТСВ поддерживается механизм

инкапсуляции объектов, он должен обеспечивать:

· авторизацию доступа к инкапсулированным объектам:

· возможность создания пользователем инкапсули­рованных объектов и

подсистем:

· средства доступа к инкапсулированным объектам.

• Уровень АС-2. Базовые механизмы управления доступом

1. Дополнение. Если одновременно поддерживается несколько политик

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

полити­ки должны быть определены отдельно. Атрибуты субъ­ектов и объектов

должны точно отражать уровень их конфиденциальности и целостности.

2. Дополнение. Правила управления атрибутами безопасности субъектов и

объектов должны регламенти­ровать назначение атрибутов в ходе импорта и

экспорта объектов, в том числе управлять импортом в системе

не­классифицированной информации, не имеющей атрибу­тов безопасности, и

экспортом из системы информации, обладающей атрибутами безопасности.

3. Дополнение. Если одновременно поддерживается несколько политик

управления доступом, правила на­значения полномочий доступа должны быть

определены отдельно для каждой политики. ТСВ должно обеспечи­вать

корректность совместного применения политик безопасности, в том числе

совместное применение пра­вил авторизации каждой политики.

4. Без изменений.

5. Без изменений.

• Уровень АС-3. Расширенное управления доступом

1. Дополнение. ТСВ должно незамедлительно сооб­щать пользователю о

любых изменениях атрибутов ас­социированных с ним субъектов, повлекших за

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

быть предоставлена возможность запросить у ТСВ текущие значения атрибутов

безопас­ности ассоциированных с ним субъектов. ТСВ должно поддерживать

назначение атрибутов безопасности всем подключенным к системе физическим

устройствам (например, максимальные и минимальные уровни конфиденциальности).

Эти атрибуты должны использоваться ТСВ для отражения особенностей

функ­ционирования данных устройств, обусловленных их фи­зическими

параметрами.

2. Без изменений.

3. Изменение. Правила назначения полномочий дос­тупа должны быть

определены для всех субъектов и объектов, которые прямо или косвенно доступны

субъектам. Если применяется нормативное управление досту­пом, то правила

назначения полномочий доступа долж­ны учитывать все атрибуты субъектов и

объектов.

4. Без изменений.

5. Без изменений.

• Уровень АС-4. Точно определенная политика управления доступом

1. Дополнение. В состав атрибутов безопасности субъектов должны

входить показатели времени и место­положения, позволяющие дополнительно

аутентифицировать ассоциированного с данным субъектом пользова­теля.

2. Дополнение. Правила управления атрибутами безопасности субъектов и

объектов должны обеспечи­вать задание для каждого объекта списка

индивидуаль­ных субъектов и групп субъектов с указанием их прав доступа к

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

субъектов и объектов должны обеспечивать задание для каждого объекта списка

индивидуальных субъектов и групп субъектов, не имеющих прав доступа к данному

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

атрибутами в зависимости от времени и места — предоставление или отзыв прав

доступа могут быть осуществлены в определенный момент времени и продлиться

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

3. Дополнение. Правила назначения полномочий доступа должны включать

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

4. Изменение. ТСВ должно определять и поддерживать правила контроля за

созданием и уничтожением субъектов и объектов, позволяющие указать для

каждого субъекта и объекта:

· полномочия, требуемые для их создания и унич­тожения;

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

· ресурсы, требуемые для их создания и размещения;

· устанавливаемые по умолчанию значения атрибу­тов созданных

субъектов и объектов и, если требу­ется, правила наследования атрибутов.

Правила создания и уничтожения субъектов и объек­тов должны определяться на

основании их типов. Если для различных типов субъектов и объектов определены

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

совокупность реализует политику безопасное ги, принятую в системе. Если

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

уничтожения субъектов и объектов должны быть определены для каждой политики.

5. Без изменений.

6. Контроль скрытых каналов

Для осуществления контроля за скрытыми каналами требуется присутствие в ТСВ

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

скрытые каналы и ограничивать возможности их ис­пользования путем их полной

ликвидации или миними­зации пропускной способности. Ранжирование данной

группы требований проводится на основе типов контро­лируемых скрытых каналов

и предоставляемых возмож­ностей контроля (аудит, минимизация пропускной

спо­собности, ликвидация).

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

подразделяются на два типа: с ис­пользованием памяти и с использованием

времени. В первом случае для кодирования передаваемой информа­ции

используется область памяти (например, установле­ние характерных признаков в

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

паке­та). Во втором случае информация кодируется опреде­ленной

последовательностью и длительностью событий, происходящих в системе

(например, с помощью модуля­ции интервалов обращения к устройствам, введения

за­держек между приемом и посылкой сетевых пакетов и т.д.).

Уровень ССН-1 затрагивает только скрытые каналы, использующие память, и

ограничивается контролем их использования. На уровне ССН-2 добавляются

требова­ния минимизации пропускной способности и исключения возможностей

использования скрытых каналов для штат­ного режима эксплуатации» системы.

Уровень ССН-3 тре­бует полного подавления всех типов скрытых каналов.

• Уровень ССН-1. Контроль скрытых каналов, ис­пользующих память

1. ТСВ и привилегированные приложения должны содержать функции

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

должны позволять идентифицировать источник и приемник скрытою обмена

информацией и способ использования скрытого канала.

2. Функции ТСВ и привилегированных приложений, осуществляющие контроль

скрытых каналов, должны быть определены для каждого скрытого канала и

присут­ствовать в типовой конфигурации системы. Если для не­которых скрытых

каналов функции контроля отсутству­ют, должно быть проведено доказательство

невозможно­сти их использования для нарушения безопасности.

• Уровень ССН-2. Контроль и ограничение пропускной способности скрытых

каналов, использующих память

1. Дополнение. Должно обеспечиваться ограничение пропускной

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

Пропускная спо­собность каждого скрытого канала должна контролиро­ваться

администратором.

2. Дополнение. Функции ТСВ и привилегированных положений,

обеспечивающие ограничение пропускной способности или полное подавление

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

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

полного подав­ления отсутствуют, должно быть проведено доказатель­ство

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

• Уровень ССН-3. Контроль и ограничение пропуск­ной способности скрытых

каналов, использующих время

1. Без изменений.

2. Дополнение. Функции контроля, ограничения пропускной способности и

подавления скрытых каналов должны в полной мере распространяться и на скрытые

каналы, использующие время.

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

Данные требования являются частью политики обес­печения работоспособности

системы и позволяют кон­тролировать использование ресурсов системы.

Ранжиро­вание проводится по отношению к множеству управляе­мых ресурсов (т.е.

подмножества ресурсов с ограничен­ным распределением) и функциональным

возможностям средств управления.

Уровень AR-1 определяет базовые требования к кон­тролю за

предоставлением ресурсов в терминах ограни­ченного подмножества системных

ресурсов, субъектов и объектов. Уровень AR-2 расширяет область

применения средств контроля за предоставлением ресурсов до множе­ства всех

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

захвата ресурсов и их доступностью для всех субъектов. На уровне AR-3 к

этим требованиям добавляется управление распределени­ем ресурсов на основании

приоритета субъекта и введение фиксированных квантов, которыми распределяются

ре­сурсы.

• Уровень AR-1. Ограничение при распределении ресурсов

ТСВ должно обеспечивать возможность ограничения множества субъектов и

объектов, доступных пользовате­лю одновременно. ТСВ должно контролировать

распре­деление определенного подмножества системных ресурсов таким образом,

чтобы ни один пользователь не мог на­рушить работу другого пользователя путем

захвата тако­го количества ресурсов системы, при котором другие пользователи

не могут осуществлять доступ к объектам и субъектам. Для всех субъектов,

объектов и ресурсов должны быть определены ограничения на время и коли­чество

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

• Уровень AR-2. Полный контроль за распределени­ем ресурсов

Дополнение. ТСВ должно контролировать распреде­ление системных ресурсов таким

образом, чтобы ни один пользователь не мог сделать любой системный ре­сурс

недоступным для других пользователей, или огра­ничить возможности ТСВ по

обслуживанию других пользователей путем захвата ресурсов или осуществле­ния

манипуляций с ТСВ.

• Уровень AR-3. Распределение ресурсов на основа­нии приоритетов

Дополнение. ТСВ должно обеспечивать возможность распределения ресурсов на

основании специально выде­ленных атрибутов, поставленных в соответствие

каждо­му субъекту. ТСВ должно осуществлять распределение ресурсов в первую

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

выде­ляться блоками определенного размера (квантами).

8. Политика управления безопасностью

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

множестве управляемых па­раметров и уровне предоставляемых возможностей.

Уровень SM-1 содержит минимальные требования по управлению

безопасностью. Уровень SM-2 является ба­зовым и предназначен для

применения в большинстве систем. На уровне SM-3 надежность механизма

управле­ния обеспечивается за счет разделения ролей админист­ратора и оператора

системы и применения более широ­кого набора средств управления безопасностью.

На уровне SM-4 требуется наличие доверенных средств управления безопасностью и

введение контроля за адми­нистрированием системы.

• Уровень SM-1. Минимальное управление безопас­ностью

1. ТСВ должно содержать доверенные средства уста­новки и настройки

собственных конфигурационных па­раметров и инициализации критических

внутренних структур данных перед заданием атрибутов безопасно­сти

пользователей и администраторов.

2. ТСВ должно поддерживать доверенные средства просмотра и

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

3. ТСВ должно включать доверенные средства про­смотра, редактирования

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

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

положение. Данные средст­ва должны позволять администратору приостанавливать

и возобновлять действие идентификаторов пользовате­лей и их бюджетов.

4. ТСВ должно содержать доверенные средства кон­троля функционирования

системы и состояния систем­ных ресурсов. Эти средства должны обеспечивать

под­ключение и отключение внешних устройств, съемных носителей информации,

резервное копирование и вос­становление объектов, эксплуатацию и тестирование

программных и аппаратных компонентов ТСВ, запуск и остановку системы.

5. Средства управления безопасностью должны быть доступны только для

администратора системы.

• Уровень SM-2. Базовые механизмы управления безопасностью

1. Дополнение. Средства управления безопасностью должны учитывать

различие между режимами штатного функционирования и технического обслуживания

систе­мы и поддерживать управление безопасностью и в том и в другом режиме.

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

восстановление после сбоев и запуск системы.

2. Дополнение. В состав параметров политики безо­пасности должны

входить параметры идентификации, аутентификации, регистрации в системе и

параметры управления доступом как для системы в целом, так и для каждого

отдельного пользователя. ТСВ должно позволять администратору определять

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

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

поли­тики безопасности должны позволять ограничивать:

· максимальный период отсутствия активности со стороны пользователя;

· максимальное время работы пользователя в сис­теме:

· максимальное число последовательно осуществ­ленных безуспешных

попыток регистрации в сис­теме.

Если в системе обеспечивается поддержка политики обеспечения

работоспособности, ТСВ должно поддер­живать механизм управления доступностью

системных ресурсов посредством введения квот и ограничений на объем

потребляемых ресурсов.

3. Дополнение. ТСВ должно содержать средства для однозначной

идентификации каждого параметра поли­тики безопасности. Кроме того, должна

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

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

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

ат­рибутами политики безопасности субъектов, включая привилегии, атрибуты

произвольного и нормативного управления доступом, а также централизованного

контроля, назначения и снятия атрибутов политики безо­пасности.

4. Без изменений.

5. Без изменений.

• Уровень SM-3. Управление безопасностью в соот­ветствии с политикой

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

1. Дополнение. Режим технического обслуживания системы должен включать

средства инициализации па­раметров идентификации, аутентификации, регистрации

в системе и назначения полномочий администратора системы.

2. Дополнение. В случае совместного использования нескольких методов

аутентификации ТСВ должно пре­доставлять администратору возможность

определять ме­тоды аутентификации пользователей в зависимости от

соответствующих атрибутов политики безопасности. Если ТСВ поддерживает

одновременно несколько сеансов для одного пользователя, администратор должен

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

пользователя в зависимости от его атрибутов безопасности. ТСВ должно

позволять администратору ограничи­вать регистрацию для пользователя с

определенным идентификатором или с определенного терминала после заданного

количества неуспешных попыток регистрации с помощью этого идентификатора или

терминала.

3. Дополнение. ТСВ должно автоматически приоста­навливать полномочия

пользователей в случае, если они не использовались в течение заданного

администрато­ром периода времени. ТСВ также должно обеспечивать

автоматическое возобновление приостановленных пол­номочий по истечении

указанного администратором времени.

4. Дополнение. ТСВ должно поддерживать разделе­ние функций оператора и

администратора. Функции оператора должны ограничиваться управлением внеш­ними

устройствами.

5. Без изменений.

• Уровень SM-4. Расширенное управление безопас­ностью

1. Без изменений.

2. Без изменений.

3. Дополнение. ТСВ должно содержать доверенные средства

администрирования системы, осуществляющие контроль:

· конфигурации системы и регистрации пользовате­лей;

· корректности и инсталляции системы;

· отсутствия в ТСВ посторонних программ и дан­ных.

ТСВ должно включать средства контроля безопасно­сти начального состояния ТСВ

после инициализации или восстановления.

ТСВ должно включать средства контроля соответст­вия между пользователями,

субъектами, представляю­щими их в системе, и назначенным им атрибутом

безо­пасности.

4. Дополнение. Средства контроля функционирова­ния системы должны

поддерживать разделение ролей администратора безопасности и аудитора,

контроли­рующего администрирование. ТСВ должно выполнять заданные

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

влияющие на безо­пасность системы действия администратора должны быть строго

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

5. Без изменений.

9. Мониторинг взаимодействий

Ранжирование требований к мониторингу взаимо­действий производится по отношению

к области приме­нения мониторинга и степени детализации взаимодейст­вий. На

уровне RM-1 мониторинг взаимодействий огра­ничивается только заданными

подмножествами субъек­тов и объектов, обращения к которым контролируются

политикой управления доступом. На уровне RM-2 мониторинг взаимодействий

должен применяться для всех субъектов и объектов. Уровень RM-3

увеличивает сте­пень легализации с помощью мониторинга атрибутов безопасности и

статуса объектов, субъектов и ресурсов Уровень RM-4, предназначенный

для использования в системах, где действуют привилегированные процессы,

предусматривает поддержку модели мониторинга взаи­модействий привилегированных

процессов.

• Уровень RM-1. Мониторинг взаимодействий для заданных подмножеств субъектов

и объектов

1. ТСВ должно осуществлять мониторинг всех взаи­модействий, в которых

участвуют субъекты, объект и ресурсы, включенные в спецификацию ТСВ

Монито­ринг должен обеспечивать контроль взаимодействий в соответствии с

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

2. Мониторинг взаимодействий должен осуществ­ляться для заданного

подмножества субъектов, объектов и ресурсов, находящихся под контролем

политики безо­пасности системы, а также для обращений к их атрибу­там

безопасности (правам доступа, уровням конфиден­циальности, ролям, квотам и

т.д. ).

3. Мониторинг взаимодействий привилегированных субъектов должен

осуществляться в соответствии с атри­бутами безопасности этих субъектов

• Уровень RM-2. Мониторинг взаимодействий для всех субъектов и объектов

1. Без изменений.

2. Дополнение. Мониторинг взаимодействий должен осуществляться для

всех объектов, субъектов и ресурсов и их атрибутов безопасности

3. Без изменений.

• Уровень RM-3. Мониторинг взаимодействий и контроль атрибутов безопасности

1. Без изменений.

1. Дополнение. Требования мониторинга взаимодей­ствий обращений к

атрибутам субъектов, объектов и ре­сурсов распространяются на полное

множество атрибутов (состояние, размер, режим использования).

2. Без изменений.

• Уровень RM-4 Мониторинг взаимодействий привилегированных субъектов

1. Без изменений.

2. Без изменении.

3. Дополнение. Мониторинг взаимодействий приви­легированных субъектов

должен осуществляться на ос­нове модели безопасности и мониторинга,

определенней для этих субъектов.

10. Логическая защита ТСВ

Ранжирование требований логической защиты ТСВ проводится на основе их

возможностей по обеспечению безопасности ТСВ. Уровень LP-1 содержит

основные требования к изоляции ТСВ. На уровне LP-2 эти требо­вания

расширяются за счет введения средств контроля целостности структур данных ТСВ и

исключения влия­ния на состояние ТСВ со стороны непривилегированных

пользователей. Эти требования призваны сделать невоз­можным применение

злоумышленником средств про­никновения в ТСВ. На уровне LP-3 вводится

требование синхронности контроля целостности ТСВ.

• Уровень LP-1. Базовые средства изоляции ТСВ

ТСВ должно функционировать внутри собственного домена, изолированного от;

остальных компонентов системы. Изоляция домена ТСВ должна обеспечивать

защи­ту от внешних воздействий, модификации программ или данных ТСВ.

1. Изоляция компонентов ТСВ должна включать:

· изоляцию адресного пространства ТСВ от адрес­ного пространства

непривилегированных субъектов таким образом, чтобы они не могли получить

доступ по чтению и записи к программам и дан­ным ТСВ:

· взаимодействие между доменом ТСВ и остальны­ми компонентами системы

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

с ТСВ был невозможен;

· параметры, передаваемые в ТСВ, должны контро­лироваться на

допустимость их значений или принадлежность к адресному пространству ТСВ.

2. Для обеспечения надежности изоляции ТСВ права доступа к объектам,

переданным в ТСВ в качестве пара­метров, должны проверяться на соответствие

тре6yeмым, а обращения к объектам ТСВ со стороны средств, обеспечивающих

изоляцию, контролироваться монито­ром пересылок.

• Уровень LP-2. Изоляция и контроль целостности ТСВ

1. Без изменений.

2. Дополнение. Средства защиты ТСВ также должны осуществляв контроль

целостности структур данных ТСВ и предотвращать влияние на них со стороны

непривилегированных пользователей.

3. Контроль целостности структур данных ТСВ с по­мощью вычисления

функции-инварианта, определенной на множестве переменных, объектов и функций,

должен осуществляться до и после любого обращения к ТСВ.

4. Для предотвращения влияния на ТСВ со стороны непривилегированных

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

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

• Уровень LP-3. Изоляция и синхронный контроль целостности ТСВ

1. Без изменений.

2. Без изменений.

3. Без изменений.

4. Дополнение. Защита ТСВ должна обеспечивать синхронность функций

контроля целостности.

5. Синхронность функций контроля целостности оз­начает, что действия,

основанные на результатах про­верки целостности, осуществляются

непосредственно по­сле завершения процесса проверки и между этими собы­тиями

состояние ТСВ измениться не может.

11. Физическая защита ТСВ

Ранжирование требований физической защиты ТСВ производится на основе

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

предотвращать атаки на систему на физическом уровне.

На уровне РР-1 от средств обеспечения физической защиты требуется

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

РР-2 вы­двигается требование к устройствам распознавать попытки физического

вмешательств в их работу. Уровень РР-3 требует наличия средств

противодействия атакам на конфиденциальность и целостность системы, а также

изменениям в среде функционирования.

• Уровень РР-1. Административные меры и кон­троль среды функционирования

1. Должны быть определены административные ме­ры и параметры

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

защиты ТСВ.

2. Должны иметься и надлежащим образом приме­няйся средства и

устройства, необходимые для осуществления физического контроля за

компонентами ТСВ.

• Уровень РР-2. Обнаружение атак на физическом уровне

1. Без изменений.

2. Дополнение. Средства и устройства, осуществ­ляющие физический

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

на ТСВ. Эти устройства должны быть надежны и устойчи­вы к

непосредственному физическому воздействию.

• Уровень РР-3. Противодействие атакам на физиче­ском уровне и

неблагоприятным изменениям в среде функционирования

1. Без изменений.

2. Дополнение. Должны иметься средства противо­действия атакам на

физическом уровне, их характери­стики должны соответствовать требованиям

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

должны противостоять попыткам кражи и исследования компонентов ТСВ с помощью

физического воздействия, подслушивания, перехвата и анализа излу­чений. Для

обеспечения целостности эти устройства должны противодействовать

несанкционированному изменению состава аппаратного обеспечения, наруше­нию ею

функционирования, а также воздействиям на хранящуюся в системе информацию

механическими или электромагнитными методами. Для обеспечения

работо­способности системы эти устройства должны противо­действовать

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

вода, огонь и другие формы физических воздействий).

12. Самоконтроль ТСВ

Требования самоконтроля ТСВ ранжируются на ос­нове перечня контролируемых

элементов (аппаратное, программное и специальное обеспечение) и возможно­стей

механизмов проверки (периодичность, длитель­ность, глубина проверки)

На уровне SC-1 представлены минимальные требо­вания к самоконтролю ТСВ,

предполагается, что их вы­полнения будет достаточно для большинства

коммерче­ских приложений. Уровень SC-2 содержит расширенные требования,

включающие в себя тестирование при вклю­чении питания, загрузке системы, а

также управляемые оператором средства тестирования, применяемые для

периодического контроля функционирования элементов ТСВ. На уровне SC-3

появляются требования к тестиро­ванию программных компонентов ТСВ. На уровне

SC-4 требуется, чтобы тестирование осуществлялось регуляр­но па протяжении всею

периода функционирования сис­темы.

• Уровень SC-1. Минимальный самоконтроль

ТСВ должно включать аппаратные и/или программ­ные средства периодического

контроля целостности и корректности функционирования собственных аппарат­ных

и специальных компонентов.

• Уровень SC-2. Базовые механизмы самоконтроля

Дополнение. В состав средств контроля должны вхо­дить: [тестирование при

включении питания, тестирование в ходе загрузки системы и средства

легирования, управляемые опера горем.

Тесты при включении питания должны осуществлять проверку всех аппаратных и

специальных компонентов ТСВ, включая оперативную память, шины,

соединения, разъемы, управляющие контроллеры, процессор, адап­теры дисковых

накопителей и других устройств, комму­никационные порты, консоль и клавиатуру.

Эти тесты также должны осуществлять проверку всех компонентов, используемых для

выполнения гестов при загрузке сис­темы, и тестов, управляемых оператором.

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

центрального процессора (арифметические и логические устройства,

математиче­ский сопроцессор, устройство декодирования инструк­ций, контроллер

прерываний, кэш, буфер трансляции адресов, внутренние и внешние шины), а

также систем­ной шины, контроллеров оперативной памяти и уст­ройств,

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

тестировании системы.

Выполняемые оператором тесты должны обеспечи­вать однократное или

многократное тестирование ком­понентов ТСВ и системы в целом, регистрацию

результатов тестирования и. в случае выявления неисправно­сти, выполнять

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

• Уровень SC-3. Тестирование программных средств

Дополнение. Должны иметься управляемые и конфи­гурируемые программные или

специальные средства тестирования целостности и корректности программных

компонентов ТСВ — программ, данных и носителей информации. Эти средства

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

• Уровень SC-4. Регулярное тестирование программ­ных средств

Дополнение. Тесты контроля целостности и кор­ректности функционирования

программных компонен­тов ТСВ должны выполняться при каждом изменении

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

произошедших из-за дейст­вий непривилегированных субъектов.

13. Инициализация и восстановление ТСВ

Требования инициализации и восстановления безо­пасного состояния ТСВ ранжируются

по отношению к уровню предоставляемых возможностей: ручное восста­новление

(уровни TR-1 и TR-2), автоматическое (уровень TR-3),

обнаружение потерь объектов пользователей (уровень TR-4), минимизация

потерь объектов (уровень TR-5).

• Уровень TR-1. Минимальные требования восста­новления и инициализации

1. ТСВ должно содержать механизмы, обеспечиваю­щие гарантированное

восстановление безопасного со­стояния ТСВ после сбоев без нарушения функций

защи­ты.

• Уровень TR-2. Базовые средства восстановления и инициализации ТСВ

1. Без изменений.

2. В случае невозможности автоматического восста­новления и

«реинициализации» безопасного состояния ТСВ должно переходить в особое

состояние, в котором доступ может осуществляться только с помощью

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

восстановление ТСВ вручную без нарушений функций защиты.

• Уровень TR-3. Автоматическое восстановление и инициализация ТСВ

1. Без изменений

2. Изменение. ТСВ должно включать средства авто­матического

восстановления безопасного состояния ТСВ после ошибок и сбоев. Эти средства

должны по возмож­ности исключать потерю системных и пользовательских

объектов. Должны быть определены требования, или правила, политики

безопасности, позволяющие подтвер­дить безопасность ТСВ после восстановления.

• Уровень TR-4. Обнаружение потерь объектов

1. Без изменений.

2. Дополнение. ТСВ должно включать специальную контрольную функцию

восстановления, способную об­наруживать повреждение или разрушение объектов в

ре­зультате сбоев, и предупреждать об этом пользователей.

• Уровень TR-5. Минимизация потерь объектов

1. Без изменений.

2. Дополнение. Все вызываемые извне функции и операции ТСВ должны быть

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

либо, при возникновении сбоев, сохранять исходное со­стояние используемых

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

минимизи­ровать искажения и потери объектов при сбоях системы.

14. Ограничение привилегий при работе с ТСВ

Требования ограничения привилегий при работе с ТСВ ранжируются на основе

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

груп­пами функций ТСВ (уровень РО-1), с отдельными компонентами

(модулями) ТСВ и административными ролями (РО-2), с отдельными

операциями (РО-3) и динамически изменяющимися в ходе выполнения

операций (РО-4).

• Уровень РО-1. Назначение привилегий для выпол­нения функций ТСВ

1. Должны быть определены привилегии, необходи­мые для выполнения

отдельных функций ТСВ или их групп. Также должны быть определены

привилегирован­ные функции и объекты ТСВ, такие, как файлы регистра­ции

пользователей, файлы паролей, файлы, содержащие уровни безопасности

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

2. Должен быть назначен минимальный уровень при­вилегий, необходимый и

достаточный для осуществления доступа к установленным привилегированным

функциям и объектам ТСВ.

• Уровень РО-2. Назначение привилегий доступа к компонентам ТСВ

1. Дополнение. Должна обеспечиваться возможность назначения

необходимых привилегий действиям, выпол­няемым в ТСВ привилегированными

пользователями (администраторами).

2. Изменение. Всем функциям и компонентам (мо­дулям) ТСВ должен быть

поставлен в соответствие ми­нимальный уровень привилегий, необходимый и

доста­точный для их доступа к ним.

3. Должна быть обеспечена поддержка реализации привилегий модулей ТСВ

с помощью низкоуровневых процедур и механизмов.

• Уровень РО-3. Назначение привилегий для выпол­нения отдельных операций

1. Без изменений.

2. Дополнение. Должны быть определены привиле­гии, необходимые для

выполнения отдельных операций ТСВ. Для каждой операции должен быть назначен

ми­нимальный уровень привилегий, необходимый и доста­точный для ее

выполнения.

3. Изменение. Должна быть обеспечена поддержка реализации привилегий

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

• Уровень РО-4. Динамическое назначение привиле­гий для выполнения отдельных

операций

1. Без изменений.

2. Дополнение. Установленное привилегии должны использоваться всеми

функциональными компонентами ТСВ для контроля и ограничения распространения

оши­бок в работе механизмов защиты и предоставления пол­номочий, которые

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

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

привилегии отдельных операций ТСВ (но не выше заданной границы) и

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

Эти меры должны ограничивать использова­ние высокопривилегированных операций

ТСВ, потен­циально предоставляющих пользователю возможности использования

этих привилегий для нарушения полити­ки безопасности.

3. Без изменений.

15. Простота использования ТСВ

Ранжирование требований данной группы отражает имеющиеся возможности управления

конфигурацией ТСВ. На уровне EU-1 сформулированы общие требования,

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

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

безопасности или содержимого файлов регист­рации пользователей. Требования к

функциональности средств администрирования расширяются на уровне EU-2

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

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

обеспечить собственную защиту и защиту своих объектов от несанкционированного

использова­ния. На уровнях EU-3 и EU-4 требования усиливаются и

расширяются за счет увеличения множества субъектов и объектов, на которые они

распространяются для стан­дартной и полной конфигурации системы.

• Уровень EU-1. Простота управления безопасно­стью

1. ТСВ должно обеспечивать поддержку функций администрирования. Должна

быть предусмотрена воз­можность задания значений параметров безопасности по

умолчанию для средств администрирования.

• Уровень EU-2. Простота разработки приложений

1. Дополнение. ТСВ должно обеспечивать автомати­ческую установку

атрибутов безопасности по умолча­нию для определенных субъектов и объектов и

возмож­ность модификации этих атрибутов.

2. ТСВ должно предусматривать четко определенный программный интерфейс

взаимодействия со всеми при­нятыми в системе политиками безопасности для

под­держки приложений, которые могут обеспечить под­держку этих политик

безопасности на прикладном уров­не. ТСВ должно предоставлять пользователю

возмож­ность понижения полномочий используемых приложе­ний.

• Уровень EU-З. Простота использования стандарт­ной конфигурации системы

1. Изменение. ТСВ должно обеспечивать автоматическую установку

атрибутов безопасности по умолча­нию для определенных субъектов, объектов и

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

модификации этих атрибутов.

2. Без изменений.

• Уровень EU-4. Простота использования полной конфигурации системы

1. Изменение. ТСВ должно обеспечивать автомати­ческую установку

атрибутов безопасности по умолча­нию для всех субъектов, объектов и служб

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

2. Без изменений.

Приложение II

критериев безопасности компьютерных систем»

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

требований к адекватности реализации «Канадских критериев безопасности

компью­терных систем». Данное изложение отражает только принципиальную суть

требований и не претендует на пе­ревод стандарта как руководящего документа.

Описание каждого раздела требований начинается с его краткого описания и

обзора предусмотренных уровней ранжирования. Идентификаторы уровней сохранены

в том виде, в каком они присутствуют в первоисточнике. Специ­альный нулевой

уровень зарезервирован для систем, реа­лизующих данные требования в степени

недостаточной для соответствия какому-либо уровню. Некоторые уровни

функциональных критериев зависят от Других, и для того, чтобы удовлетворить

требованиям этих уровней, необхо­димо соблюсти не только приведенные в них

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

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

уровней после текста тре­бований указываются идентификаторы уровней,

сопря­женных с ними.

1. Критерии конфиденциальности

Критерии конфиденциальное и регламентируют защиту ресурсов компьютерной

системы от несанкциониро­ванного доступа. В качестве средств обеспечения

конфи­денциальности рассматриваются контроль скрытых кана­лов, произвольное и

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

ресурсов.

1.1. Контроль скрытых каналов

Контроль скрытых каналов позволяет выявить присутствие в системе потоков

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

Ран­жирование требований производится по четырем уровням в зависимости от

степени анализа наличия скрытых кана­лов и возможностей по контролю и

подавлению.

•Уровень СС-0. Недостаточный контроль скрытых ка­налов

Данный уровень зарезервирован для систем с прими­тивными возможностями

контроля скрытых каналов, ко­торые не удовлетворяют требованиям более высоких

уровней.

•Уровень С01. Анализ скрытых каналов

Должно быть проведено исследование наличия в компьютерной системе скрытых

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

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

Максимальная пропускная способность каждого скрытого канала должна быть

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

использованы совместно, должна быть указана макси­мальная пропускная

способность их совокупности.

Сопряженные уровни: ТЗ.

• Уровень СС-2. Контроль скрытых каналов

Дополнение. ТСВ должно позволять осуществлять контроль за использованием

заданного множества скры­тых каналов.

Сопряженные уровни: ТЗ, WA-1.

•Уровень СС-3. Подавление скрытых каналов

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

Сопряженные уровни: ТЗ.

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

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

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

пользовате­лям. Ранжирование требований проводится на основании возможностей

механизма контроля и степени его детали­зации.

•Уровень CD-0. Недостаточное произвольное управле­ние доступом

Уровень зарезервирован для систем с наличием от­дельных элементов

произвольного управления доступом, но не удовлетворяющих требованиям более

высоких уров­ней.

•Уровень CD-1. Минимальные требования к произ­вольному управлению доступом

ТСВ должно обеспечивать реализацию политики произвольного управления доступом

по отношению к за­данному подмножеству объектов компьютерной системы.

Предоставление доступа к объекту должно произво­диться на основании значений

тегов объекта и процесса, опросившего доступ.

Управление параметрами доступа должно выполнятся средствами ТСВ на основании

тега пользователя.

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

Правила назначения тегов при экспорте-импорте объектов должны являться

составной частью политики произвольного управления доступом.

Сопряженные уровни. CR-1,WI-1

•Уровень CD-2. Базовая политика произвольного управления доступом

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

основании значении тегов объекта и пользователя, ассоциированного с процессом,

запросив­шим доступ.

Дополнение. Политика произвольного управления доступом должна

предусматривать наличие частично оп­ределенной матрицы доступа для тегов всех

пользователей и тегов защищенных объектов.

Сопряженные уровни: CR-1, WI-1.

•Уровень CD-3. Гибкая политика произвольного управления доступом

Изменение. Политика произвольного управления доступом должна

предусматривать наличие полностью определенной матрицы доступа для тегов всех

пользовате­лей и тегов защищенных объектов.

Сопряженные уровни: CR-1, WI-1.

•Уровень CD-4. Расширенная политика произвольного управления доступом

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

основании значений тегов объекта, процесса, запросившего доступ, и

пользователя, ассоции­рованного с этим процессом.

Изменение. Политика произвольного управления доступом должна

предусматривать наличие полностью определенной матрицы доступа для тегов всех

пользовате­лей и процессов и тегов защищенных объектов.

Сопряженные уровни: CR-1, WI-1.

1.3. Нормативное управление доступом

Нормативное управление доступом. так же как и произвольное управление

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

по­токами информации от объектов системы к пользовате­лям. Ранжирование

требований проводится на основании степени их детализации, множества

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

•Уровень СМ-0. Недостаточное нормативное управле­ние доступом

Уровень резервирован для систем с примитивными возможностями нормативного

управления доступом. Не удовлетворяющих требованиям более высоких уровней.

•Уровень СМ-1. Минимальные требования к нормативному управлению доступом

ТСВ должно обеспечивать реализацию политики нормативною управления доступом

по отношению к за­данному подмножеству объектов компьютерной системы.

Предоставление доступа к объекту должно произво­диться на основании значений

тегов объекта и процесса, запросившего доступ.

Управление параметрами доступа должно осуществ­ляться средствами ТСВ только

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

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

Правила назначения тегов при экспорте-импорте объектов должны являться

составной частью политики нормативного управления доступом.

Сопряженные уровни: CR-1, IS-1.

•Уровень СМ-2. Базовая политика нормативного управления доступом

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

основании значений тегов объекта и пользователя, ассоциированного с процессом,

запросив­шим доступ.

Сопряженные уровни: CR-1, IS-1, WI-1.

•Уровень СМ-3. Гибкая политика нормативного управления доступом.

Изменение. Политика нормативного управления дос­тупом должна применяться

ко всем объектам компьютер­ной системы.

Сопряженные уровни: CR-1, IS-1, WI-1.

•Уровень СМ-4. Расширенная политика нормативного управления доступом

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

основании значений тегов объекта, процесса, запросившего доступ, и

пользователя, ассоции­рованного с этим процессом.

Сопряженные уровни: CR-1, IS-1, WI-1.

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

Контроль за повторным использованием объектов позволяет обеспечить безопасное

использование разделяе­мых объектов, одновременно или последовательно

дос­тупных нескольким процессам. Контроль должен предот­вращать сохранение в

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

одним процессом и перед предоставлением доступа к ним друго­му процессу.

•Уровень CR-0. Недостаточное нормативное управле­ние доступом

Уровень зарезервирован для систем с примитивными возможностями контроля за

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

•Уровень CR-1. Безопасное повторное использование объектов

ТСВ должно обеспечивать политику безопасного по­вторного использования

объектов. Эта политика должна применяться ко всем объектам, допускающим

совместное использование.

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

предоставлением его в по­вторное использование.

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

перед предоставлением его в повторное использование.

2. Критерии целостности

Критерии целостности определяют возможности компьютерной системы по

обеспечению собственной це­лостности и целостности обрабатываемой и хранимой

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

целостности, произвольного и норма­тивного управления целостностью,

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

ком­пьютерной системы, а также средств отката и самотести­рования.

2.1. Домены целостности

Поддержка доменов целостности позволяет ТСВ осуществлять защиту собственных

компонентов и контролировать целостность и осуществлять управление

защи­щенными объектами.

•Уровень IB-0. Недостаточная поддержка доменов целостности

Зарезервирован для систем, осуществляющих под­держку доменов целостности в

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

• Уровень IB-1. Домены целостности ТСВ

ТСВ должно поддерживать политику обеспечения целостности доменов,

предусматривающую идентифика­цию доменов (как доменов ТСВ, так и остальных) и

сред­ства их изоляции.

ТСВ должно обеспечивать защиту co6cтвенных до­менов от внешних воздействий.

• Уровень IB-2. Полный контроль доступа

Дополнение. Архитектура ТСВ должна гарантиро­вать, что доступ к сервису

средств безопасности и к защи­щенным объектам возможен только посредством ТСВ.

2.2. Произвольное управление целостностью

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

пользователям управлять потоками информации от пользователей к

объ­ектам системы. Ранжирование требований проводится на основании возможностей

механизма контроля и степени его детализации.

• Уровень ID-0. Недостаточное произвольное управле­ние целостностью

Уровень зарезервирован для систем с наличием от­дельных элементов

произвольного управления целостно­стью, но не удовлетворяющих требованиям

более высоких уровней.

• Уровень ID-1. Минимальные требования к произ­вольному управлению целостностью

ТСВ должно обеспечивать реализацию политики произвольного управления

целостностью по отношению к заданному подмножеству объектов компьютерной

систе­мы.

Предоставление доступа к объекту должно произво­диться на основании значений

тегов объекта и пользова­теля.

Управление параметрами доступа должно выпол­няться средствами ТСВ на

основании тега пользователя.

Теги защищенных объектов должны назначаться при их создании или

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

являться составной частью политики произвольного управления целостностью.

Сопряженные уровни: CR-1, WI-1.

• Уровень ID-2. Базовая политика произвольного управления целостностью

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

основании значений тегов объекта и процесса, запросившего доступ.

Дополнение. Политика произвольного управления Це­лостностью должна

предусматривать наличие частично определенной матрицы доступа для тегов всех

процессов и тегов защищенных объектов.

Сопряженные уровни: CR-1, WI-1.

• Уровень ID-3. Гибкая политика произвольного управления целостностью

Изменение. Политика произвольного управления це­лостностью должна

предусматривать наличие полностью определенной матрицы доступа для тегов всех

процессов и тегов защищенных объектов.

Сопряженные уровни: CR-1, WI-1.

• Уровень ID-4. Расширенная политика произвольною управления целостностью

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

основании значении тегов объекта, процесса, запросившего доступ, и

пользователя, ассоции­рованною с этим процессом.

Изменение. Политика произвольного управления целостностью должна

предусматривать наличие полностью определенной матрицы доступа для тегов всех

пользователей и процессов и тегов защищенных объектов.

Сопряженные уровни: CR-1, WI-1.

2.3. Нормативное управление целостностью

Нормативное управление целостностью, так же как и произвольное управление

целостностью, позволят администраторам и уполномоченным пользователям

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

Ранжирование требований проводится на основании степени их детализации,

множества защищаемых объектов и предоставляемых возможностей по управлению

досту­пом.

• Уровень 1М-0. Недостаточное нормативное управле­ние целостностью

Уровень зарезервирован для систем с примитивными возможностями нормативного

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

уровней.

• Уровень IM-1. Минимальные требования по норма­тивному управлению целостностью

ТСВ должно обеспечивать реализацию политики нормативного управления

целостностью по отношению к заданному подмножеству объектов компьютерной

систе­мы.

Предоставление доступа к объекту должно произво­дится на основании значений

тегов объекта и пользователя.

Управление параметрами доступа должно осуществляться средствами ТСВ только

администратором и авто­ризованными пользователями.

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

Правила назначения тегов при экспорте-импорте объектов должны являться

составной частью политики нормативного управления целостностью.

Сопряженные уровни: CR-1, IS-1, WI-1.

• Уровень IM-2. Базовая политика нормативного управления целостностью

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

основании значений тегов объекта и процесса, запросившего доступ.

Сопряженные уровни: CR-1, IS-1.

• Уровень IM-3. Гибкая политика нормативного управления целостностью

Изменение. Политика нормативного управления целостностью должна

применяться ко всем объектам ком­пьютерной системы.

Сопряженные уровни: CR-1, IS-1

•Уровень IM-4. Расширенная политика нормативного управления целостностью

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

основании значений тегов объекта, процесса, запросившего доступ, и

пользователя, ассоции­рованного с этим процессом.

Сопряженные уровни: CR-1,1 S-1, WI-1.

2.4. Физическая целостность

Критерии физической целостности определяют пери­метр ТСВ, регламентируют

возможности средств физиче­ской защиты ТСВ. Задачей средств обеспечения

физиче­ской целостности является выявление, ограничение и пре­дотвращение

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

системы, предот­вращение несанкционированного использования, модифи­кации или

подмены ее физических компонентов. Требова­ния к средствам физической защиты

ранжируются в зави­симости от типа обеспечиваемой защиты и средств, кото­рые

необходимо потратить злоумышленнику на ее пре­одоление.

• Уровень IP-0. Недостаточная физическая целост­ность

Зарезервирован для систем с минимальными возмож­ностями обеспечения

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

уровней.

• Уровень IP-1. Базовые требования по обеспечению физической целостности

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

определяющую периметр физи­ческой защиты ТСВ и множество компонентов

компью­терной системы, к которым данная политика применяется.

Периметр физической защиты ТСВ должен быть за­щищен с помощью специальных

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

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

• Уровень IP-2. Регулярная физическая целостность

Дополнение. ТСВ должно включать средства обнару­жения или противодействия

попыткам проникновения че­рез все входы, расположенные па периметре физической

защиты ТСВ.

Дополнение. В случае преодоления заграждений периметра безопасности ТСВ

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

принятой и компьютерной системе.

• Уровень IP-3. Расширенная физическая целостность

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

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

системы или должны вызывать предусмотренную реакцию ТСВ, направленную на

предотвращение нарушения поли­тики безопасности системы.

• Уровень IP-4. Полная физическая целостность

Дополнение. Все компоненты компьютерной системы должны быть защищены

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

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

чтобы физическое вмешательство в их работу было невозможным или вызывало

предусмотрен­ную реакцию ТСВ, направленную на предотвращение на­рушений

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

2.5. Возможность осуществления отката

Откат обеспечивает возможность отмены последова­тельности осуществленных

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

Ранжирование критериев этого раздела, производится в зависимости от уровня

конкретизации объектов и множе­ства операций, которые могут быть отменены.

• Уровень IR-0. Недостаточные возможности осущест­вления отката

Зарезервирован для систем с примитивными возмож­ностями отката, не

удовлетворяющих требованиям более высоких уровней.

• Уровень IR-1. Ограниченные возможности осущест­вления отката

ТСВ должно поддерживать политику осуществления отката — возврата к

предыдущему состоянию для опреде­ленного множества объектов.

Политика осуществления отката должна обеспечи­ваться автоматическими

средствами, представляющими администратору и уполномоченным пользователям

воз­можность отмены действий заданного множества опера­ций над защищенными

объектами за определенный период времени и возврата этих объектов в

состояние, в котором они находились до выполнения этих операций.

Сопряженные уровни: WI-1.

• Уровень IR-2. Расширенные возможности осуществ­ления отката

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

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

Сопряженные уровни: WI-1.

2.6. Разделение ролей

Разделение ролей позволяет распределить ответст­венность за действия в

системе, ограничить возможный ущерб безопасности системы в случае

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

предел полномочий пользователей и админи­стратора. Требования ранжируются в

зависимости от степени детализации.

• Уровень IS-0. Недостаточное разделение ролей

Зарезервирован для систем с примитивными возмож­ностями разделения ролей, не

удовлетворяющих требова­ниям более высоких уровней.

• Уровень IS-1. Базовые требования по разделению ро­лей

ТСВ должно поддерживать политику разделения ро­лей, регламентирующую

административные и неадминистративные роли пользователей и соответствующие им

действия и функции.

ТСВ должно обеспечивать разделение администра­тивных и неадминистративных

функций.

Пользователи должны получать возможность вы­полнения административных

действий только находясь в роли администратора.

Сопряженные уровни: WI-1.

• Уровень IS-2. Административное разделение ролей.

Дополнение. Политика разделения ролей должна пре­дусматривать наличие как

минимум двух отдельных адми­нистративных ролей: администратор безопасности

систе­мы и администратор системы, не имеющий возможностей по управлению

безопасностью.

Дополнение. Действия, доступные для выполнения в конкретной роли, должны

быть минимизированы по сво­ему составу и включать только те, которые необходимы

для реализации функций, соответствующих данной роли.

Изменение. Пользователи должны иметь возмож­ность выполнения функций

любой роли (а не только ад­министративной) лишь находясь в этой роли.

Дополнение. ТСВ должно гарантировать, что пользо­вателю, находящемуся в

определенной роли, доступны те, и только те функции и действия, которые

предусмотрены этой ролью.

Сопряженные уровни: WI-1.

• Уровень IS-3. Разделение ролей на основе привилегии пользователей

Дополнение. Политика разделения ролей должна пре­дусматривать наличие

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

Сопряженные уровни: WI-1.

2.7. Самотестирование

Самотестирование ТСВ обеспечивает корректность выполнения операций и надежное

функционирование эле­ментов компьютерной системы. Требования ранжируются в

зависимости от возможностей механизмов самоконтроля своевременно обнаруживать

некорректное функциониро­вание компонентов компьютерной системы.

• Уровень IT-0. Недостаточное самотестирование

Зарезервирован для систем с примитивными возмож­ностями самотестирования, не

удовлетворяющих требова­ниям более высоких уровней.

• Уровень 1Т-1. Базовое самотестирование

ТСВ должно поддерживать политику самотестирова­ния, определяющую возможности

системы по периодиче­скому контролю корректности функционирования ТСВ.

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

руководстве но управлению безо­пасностью системы.

• Уровень IT-2. Самотестирование при загрузке или запуске.

Дополнение. ТСВ должно выполнять набор контро­лирующих тестов в

процессе запуска или загрузки системы для проверки правильности

функционирования критич­ных компонентов.

• Уровень IT-3. Самотестирование в процессе работы

Изменение. ТСВ должно обеспечивать выполнение кот роля правильности

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

пе­риодически в процессе функционирования компьютерной системы.

3. Критерии работоспособности

Критерии работоспособности регламентируют рабо­ту средств, обеспечивающих

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

пользователей. В качестве мер обеспечения работоспособности рассмат­риваются

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

к отказам и сбоям, обеспечение живучести и восстановления системы в усло­виях

выхода из строя ее компонентов.

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

Контроль за распределением ресурсов позволяет ТСВ управлять использованием

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

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

•Уровень АС-0. Недостаточный контроль за распреде­лением ресурсов

Зарезервирован для систем с примитивными возможностями контроля за

распределением ресурсов, не удовлетворяющих требованиям более высоких

уровней.

• Уровень АС-1. Нормированное распределение ресур­сов

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

компьютерной системы, позво­ляющую установить нормы (квоты) на предоставление

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

Изменение квот на выделение ресурсов может произ­водиться только

администраторами и уполномоченными пользователями посредством ТСВ.

Сопряженные уровни: IS-1.

• Уровень АС-2. Предотвращение отказов в обслужи­вании

Изменение. Полшика управления распределением ре­сурсов должна охватывать

все ресурсы компьютерной системы.

Дополнение. Нормы и квоты на потребление ресурсов должны быть заданы

таким образом, чтобы ни один пользователь не мог захватить все ресурсы системы

и сделать невозможным доступ остальных пользователей к сервису ТСВ и защищенным

объектам.

Сопряженные уровни: IS-1.

• Уровень АС-3. Разграничение ресурсов

Изменение. Политика управления распределением ре­сурсов должна позволять

устанавливать ограничения на потребление ресурсов как для отдельных

пользователей, так и для групп пользователей.

Изменение. Соответственно, нормы и квоты на потребление ресурсов должны

быть заданы таким образом, чтобы не только один пользователь, но и группа

пользо­вателей не могла захватить все ресурсы системы и сделать невозможным

доступ остальных пользователей к сервису ТСВ и защищенным объектам.

Сопряженные уровни: IS-/.

3.2. Устойчивость к отказам и сбоям

Устойчивость к ошибкам и сбоям позволяет обеспечивать работоспособность

системы и доступность ее ресур­сов при выходе из строя отдельных компонентов.

Требо­вания ранжируются в зависимости от обеспечиваемых возможностей замены

компонентов без нарушения функ­ционирования.

• Уровень AF-0. Недостаточная устойчивость к отка­зам и сбоям

Зарезервирован для систем с примитивными возмож­ностями обеспечения

устойчивости к отказам, не удовле­творяющих требованиям более высоких

уровней.

• Уровень AF-1. Замена отдельных компонентов в хо­де функционирования

ТСВ должно поддерживать политику обеспечения ус­тойчивости к сбоям и отказам

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

функционирования системы.

Администратор или уполномоченные пользователи должны иметь возможность

осуществления замены защи­щенных компонентов.

Сопряженные уровни: IS-1, AR-1.

• Уровень AF-2. Полная замена компонентов системы

Изменение. Политика обеспечения устойчивости к отказам и сбоям должна

охватывать все компоненты ком­пьютерной системы и обеспечивать их замену без

преры­вания функционирования.

Сопряженные уровни: IS-1, AR-1.

3.3. Живучесть

Живучесть (robustness) системы характеризует ее возможности сохранять

работоспособность и доступность ресурсов системы после отказа некоторых из ее

компонен­тов. Фактически свойство живучести определяет возмож­ность системы

выполнять свои функции при наличии не­исправных компонентов. Требования

ранжируются в зави­симости количества неисправностей, при наличии которых

сохраняется работоспособность системы, и от множества ресурсов, доступных в

условиях выхода из строя компо­нентов системы.

• Уровень AR-О. Недостаточная живучесть

Зарезервирован для систем с примитивными возможностями обеспечения живучести,

не удовлетворяющих требованиям более высоких уровней.

• Уровень AR-1. Надежность системы при выходе из строя ограниченного

множества компонентов

ТСВ должно поддерживав поли гику обеспечения живучести, определяющую набор

защищенных компонен­тов системы и множество неисправностей этих компонен­тов,

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

функционировать.

Выход из строя отдельного защищенного компонента не должен нарушать

доступность ресурсов системы, но в худшем случае может привести к деградации

ее функцио­нальных возможностей.

Должны быть четко определены неисправности, сбои и отказы, возникновение

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

отказам в обслуживании.

Система должна иметь средства оповещения админи­стратора о выходе из строя

защищенных компонентов.

Сопряженные уровни: IS-1.

• Уровень AR-2. Надежность системы при выходе из строя любых компонентов

системы с деградацией функциональных возможностей

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

компонентам системы, а не только к их заданному набору.

Сопряженные уровни: IS-1.

• Уровень AR-3. Надежность системы без нарушений ее функционирования

Изменение. Выход из строя отдельного защищенного компонента не должен

нарушать доступность ресурсов системы или приводить к деградации ее

функциональных возможностей.

Сопряженные уровни: IS-1.

3.4. Восстановление

Средства восстановления позволяют вернуть ТСВ в безопасное состояние после

отказов или сбоев. Требова­ния ранжируются в зависимости от степени

автоматизации процесса восстановления.

• Уровень AY-0. Недостаточное восстановление

Зарезервирован для систем с примитивными возможностями восстановления, не

удовлетворяющих требовани­ям более высоких уровней.

• Уровень AY-1. Ручное восстановление

ТСВ должно поддерживать политику восстановления безопасного состояния,

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

возникновения которых возможно восстановление состояния системы без нарушений

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

После нарушения функционирования системы ТСВ должна обеспечить переход

системы в специальное со­стояние временного останова, в котором только

администратор и соответствующим образом уполномоченные пользователи могут

выполнить действия по восстановле­нию нормального функционирования системы.

Должна быть регламентирована процедура ручного восстановления нормального

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

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

которых необходима полная переустановка системы.

Сопряженные уровни: IS-1.

• Уровень AY-2. Автоматическое восстановление

Дополнение После нарушения функционирования системы ТСВ должно

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

восстановления нормальною функционирования системы.

Дополнение. Если это возможно, ТСВ должно выпол­нить автоматические

процедуры и восстановить нормаль­ное функционирование системы.

Изменение Если автоматическое восстановление не­возможно, ТСВ должно

обеспечить переход системы в специальное состояние временного останова, в

котором только администратор и соответствующим образом упол­номоченные

пользователи могут выполнить действия по восстановлению нормального

функционирования систе­мы.

Сопряженные уровни IS-1

• Уровень AY-3. Селективное автоматическое восста­новление

Изменение В случае, когда после нарушения функ­ционирования системы не

требуется ее полная переуста­новка, ТСВ должно осуществить автоматическое

восста­новление без потери доступности системных ресурсов; в худшем случае

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

Сопряженные уровни IS-1

4. Критерии аудита

Критерии аудита регламентируют работу средств, позволяющих установить

ответственность пользователей за события в системе. Аудит обеспечивается

средствами регистрации и учета, идентификации и аутентификации, а также

прямого взаимодействия с ТСВ.

4.1. Регистрация и учет событий в системе

Регистрация и учет событий в системе позволяют вы­явить потенциально опасные

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

Ле­гализации, сложности процесса анализа событий и воз­можности выявлять

потенциальные угрозы безопасности.

• Уровень WA-0. Недостаточная регистрация и учет событий в системе

Зарезервирован для систем с примитивными возмож­ностями регистрации и учета,

не удовлетворяющих требо­ваниям более высоких уровней.

• Уровень WA-1. Регистрация и учет событий в систе­ме

ТСВ должно поддерживать политику регистрации и учета событий в системе,

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

ТСВ должно осуществлять минимальный контроль событий, влияющих на

безопасность системы, и предос­тавлять журнал аудита посредством специального

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

Журнал аудита должен содержать информацию о да­те, времени, месте, типе и

результате каждого регистри­руемого события.

Журнал аудита должен содержать информацию, по­зволяющую идентифицировать

пользователей, процессы и объекты, участвовавшие в зарегистрированных

событиях.

Сопряженные уровни. WI-1

• Уровень WA-2. Регистрация и учет событий в систе­ме и защита журнала аудита

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

на безопасность системы, поддерживать журнал аудита и обеспечивать его защиту

от несанкционированного доступа, модификации и уничтожения.

Дополнение. Средства просмотра журнала аудита должны быть доступны

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

проверки зарегистрированных событий.

Сопряженные уровни: IS-1, WI-1.

• Уровень WA-3. Регистрация и учет событии в систе­ме, защита журнала аудита

и оповещение администра­тора

Дополнение. ТСВ должно осуществлять мониторинг событий или их

совокупности, возникновение которых яв­ляется признаком возможного нарушения

политики безо­пасное in.

Дополнение. ТСВ должно обеспечить возможность незамедлительного

оповещения администратора в случае возникновения угроз безопасности, а при

постоянном их появлении прекратить выполнение операции, вызвавшей это событие,

с минимальными последствиями для функ­ционирования системы.

Сопряженные уровни: IS-1, WI-1.

• Уровень WA-4. Детальная регистрация и учет собы­тии в системе.

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

на безопасность системы, поддерживать журнал аудита и обеспечивать его защиту

от несанкционированною доступа, модификации и унич­тожения.

Изменение. Средства анализа журнала аудита долж­ны быть доступны

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

зарегистрированных событий.

Сопряженные уровни: IS-1, WI-1.

• Уровень WA-5. Выявление вторжений

Дополнение. ТСВ должно осуществлять контроль попыток нарушения

безопасности вторжения в систему в режиме реального времени в соответствии с

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

Сопряженные уровни: IS-1, WI-1.

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

Идентификация и аутентификация позволяют ТСВ проверить подлинность

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

Ранжирование тре­бований выполняется в зависимости от функциональности

возможное! си механизмов идентификации и аутентифика­ции.

• Уровень WI-0. Недостаточная идентификация и ау­тентификация

Зарезервирован для систем с примитивными возмож­ностями идентификации и

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

• Уровень WI-1. Внешняя идентификация и аутенти­фикация

ТСВ должно поддерживать политику идентификации и аутентификации, определяющую

набор атрибутов, ассо­циированных с пользователем, и соответствующие

меха­низмы контроля и управления этими атрибутами.

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

ТСВ должно содержать защищенный механизм, по­зволяющий получить идентификатор

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

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

• Уровень WI-2. Индивидуальная идентификация и

аутентификации

Изменение. ТСВ должно содержать защищенный ме­ханизм, позволяющий

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

собственных средств ТСВ перед предоставлением пользовате­лю возможности

выполнения любых действий в системе.

Дано тонне. ТСВ должно обеспечивать защиту ин­формации, применяемой для

аутентификации, от несанкционированною доступа, модификации и уничтожения.

• Уровень WI-3. Множественная идентификация и аутентификация

Изменение. ТСВ должно содержав два и более за­щищенных механизма,

позволяющих получить идентификатор пользователя и осуществить его

аутентификацию с помощью собственных средств ТСВ перед предоставлени­ем

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

4.3. Прямое взаимодействие с ТСВ

Прямое взаимодействие с ТСВ (Trusted Path) обеспе­чивает возможность

непосредственного конфиденциаль­ного взаимодействия между пользователем и

ТСВ. Требо­вания ранжируются в зависимости от гибкости механиз­мов,

обеспечивающих прямое взаимодействие с ТСВ, и возможное! и пользователя

инициирован:, взаимодействие с ТСВ.

• Уровень WT-0. Недостаточное прямое взаимодейст­вие с ТСВ.

Зарезервирован для систем с примитивными возмож­ностями прямого

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

• Уровень WT-1. Базовые механизмы прямого взаимо-деис1вия с ТСВ

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

предусматривающую наличие соответствующих средств создания защищенных

ка­налов взаимодействия пользователя с ТСВ.

Прямое взаимодействие с ТСВ должно использовать­ся для начальной

идентификации и аутентификации поль­зователя.

Взаимодействие с ТСВ может быть инициировано только со стороны пользователя.

Сопряженные уровни: WI-2.

• Уровень WT-2. Усовершенствованные средства пря­мою взаимодействия с ТСВ

Изменение Прямое взаимодействие с ТСВ должно» использоваться для

начальной идентификации и аутенти­фикации пользователя, а также всегда

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

пользователя к ТСВ или от ТСВ к пользователю.

Изменение. Прямое взаимодействие с ТСВ может быть инициировано как со

стороны пользователя, так и ТСВ. Инициация прямого взаимодействия с

пользователем со стороны ТСВ должна однозначно идентифицироваться пользователем

и требовать Подтверждения с его стороны.

Сопряженные уровни: WI-2.

• Уровень WT-3. Полное обеспечения прямого взаимодействия с ТСВ

Изменение. Прямое взаимодействие с ТСВ должно использоваться для

начальной идентификации и аутенти­фикации пользователя, а также всегда

инициироваться пользователем или ТСВ при необходимости передачи ин­формации от

пользователя к ТСВ или от ТСВ к пользова­телю.

Сопряженные уровни: WI-2

5. Критерии адекватности реализации

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

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

адекватность реализации политики безопасности и, в конечном счете отражают

степень доверия к системе. Критерии адекватности охватывают все стадии и

аспекты создания и экс­плуатации системы и включают разделы, относящиеся к

архитектуре системы, среде разработки (процесс разра­ботки и управление

конфигурацией), контролю процесса разработки (разработка спецификаций,

архитектуры, соз­дание рабочею проекта и реализация), поставке и

сопро­вождению, документации (руководство по безопасности для пользователя и

руководство администратора безопас­ности) и тестированию безопасности.

Предусмотрено во­семь уровней адекватности реализации (ТО-Т7). С ростом

номера уровня происходит конкретизация, дополнение и усиление требований без

изменения их структуры. Крите­рии адекватности реализации политики

безопасности представляют собой наиболее объемную и детально про­работанную

часть «Канадских критериев».

•Уровень Т-0. Недостаточная адекватность реализа­ции.

Зарезервирован для систем с недостаточным уровнем обеспечения адекватности,

не удовлетворяющих требова­ниям более высоких уровней.

• Уровень Т-1.

1. Архитектура

ТСВ должна обеспечивать поддержку принят он в компьютерной системе политики

безопасности.

2. Среда разработки

Процесс разработки.

Разработчик компьютерной системы должен приме­нять четко определенную

технологию разработки и строго придерживаться ее принципов.

Управление конфигурацией в процессе разработки

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

конфигурацией.

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

вносимые в ходе разработки в аппаратное и специальное обеспечение, в исходные

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

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

комплектом документации и текущей версией ТСВ.

3. Контроль процесса разработки

Разработка спецификаций.

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

системы в виде функциональных спецификаций.

Функциональные спецификации должны содержать неформальное описание

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

реализованных в ТСВ.

Разработка архитектуры

Разработчик обязан составить неформальное описание архитектуру компьютерной

системы.

Описание архитектуры компьютерной системы должно включать описание всех

компонентов ТСВ.

Описание архитектуры должно включать интерфейс взаимодействия ТСВ с

остальными компонентами компьютерной системы.

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

реализованных аппаратными, про­граммными и специальными компонентами ТСВ.

Разработчик должен обеспечить полное соответствие между архитектурой системы

и политикой безопасности.

Создание рабочего проекта.

Разработчик обязан составить неформальное описа­ние рабочего проекта ТСВ.

Рабочий проект должен содержать описание всех компонентов ТСВ и подробно

описывать механизмы функционирования всех функций, критичных с точки зре­ния

безопасности.

Должны быть описаны назначение и параметры интерфейсов компонентов ТСВ,

критичных с точки зрения безопасности.

Реализация.

Для данного уровня требования этою раздела не предъявляются.

4. Поставка и сопровождение

Разработчик в комплекте с системой должен предос­тавлять средства ее

инсталляции, генерации и запуска.

Разработчик должен определить и документировать все параметры компьютерной

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

и за­пуска.

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

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

Разработчик должен включить в состав документа­ции на компьютерную систему

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

общей документации либо отдельного руководства. Руководство по безопасности

для пользователя должно содержать опи­сание возможностей компьютерной системы

по обеспечению безопасности и принципов работы рядового пользо­вателя со

средствами защиты.

В руководстве пользователя также должно быть опи­сано взаимодействие между

отдельными подсистемами обеспечения безопасности.

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

Разработчик должен включить в состав документа­ции на компьютерную систему

руководство администра­тора безопасности в виде обзора или раздела в общей

до­кументации либо отдельного руководства. Руководство администратора

безопасности должно содержать описание возможное! ей администрирования

средств защиты.

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

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

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

инсталляции, генерации и запуска системы с точки зрения обеспечения

безопасности.

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

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

инсталляции, генерации и запуска, с точки зрения обеспечения безопас­ности.

6. Тестирование безопасности

Разработчик должен предоставить методику тестиро­вания безопасности системы,

сценарий проведения испы­таний и средства тестирования. Полно га набора

тестов безопасности системы должна быть обоснована.

Разработчик должен представить доказательства проведения тестирования

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

тестов в соответствии с методикой тестирования.

• Уровень Т-2.

1. Архитектура

Без изменений

2. Среда разработки

Процесс разработки. Без изменений.

Управление конфигурацией в процессе разработки. Без изменений.

3. Контроль процесса разработки

Разработка спецификации.

Дополнение. Функциональные спецификации должны включать неформальное

описание модели безопасности.

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

моделью безопасности и реализован­ной политикой безопасности и показать, что

модель безо­пасности полностью обеспечивает политику безопасности

Разработка архитектуры.

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

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

Создание рабочего проекта.

Изменение. Рабочий проект должен содержать описа­ние всех компонентов ТСВ

и подробно описывать меха­низмы функционирования всех функций ТСВ.

Изменение. Должны быть описаны назначение и параметры интерфейсов всех

компонентов ТСВ.

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

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

уровня требования этого раздела не предъявляются.

4. Поставка и сопровождение

Без изменений.

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

Руководство но безопасности для пользователя. Без изменений.

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

6. Тестирование безопасности

Дополнение. Разработчик должен исправить или ней­трализовать все

обнаруженные в ходе тестирования ошиб­ки, после чего провести повторное

тестирование ТСВ для подтверждения того, что обнаруженные ошибки ликвиди­рованы

и при этом не внесены новые.

•Уровень Т-3.

1. Архитектура

Дополнение. ТСВ должна быть структурирована в ви­де набора независимых

компонентов.

2. Среда разработки

Процесс разработки.

Дополнение. Разработчик должен указать использо­ванные в ходе разработки

стандарты программирования и показать, что исходные тексты программного

обеспечения соответствуют этим стандартам.

Дополнение. Разработчик должен указать использо­ванные в ходе разработки

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

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

Управление конфигурацией в процессе разработки.

Изменение. Средства управления конфигурацией должны контролирован» вес

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

ис­ходные тексты и объектный код программ, а также в до­кументацию и в

компиляторы, используемые для трансля­ции исходных текстов.

3. Контроль процесса разработки

Разработка спецификаций.

Изменение. Функциональные спецификации должны включать полуформальное

описание модели безопасности.

Разработка архитектуры.

Изменение. Разработчик обязан составить полуфор­мальное описание

архитектуры компьютерной системы.

Создание рабочего проекта. Без изменений.

Реализация.

Разработчик обязан предоставить исходные тексты заданного подмножества

компонентов ТСВ.

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

реализацией ТСВ.

4. Поставка и сопровождение

Дополнение. Должны быть использованы техниче­ские, физические и

организационные меры для контроля

адекватности поставляемой потребителю копии ТСВ дистрибутив.

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

Руководство но безопасности для пользователя. Без изменений.

Без изменений.

6. Тестирование безопасности

Без изменений.

•Уровень Т-4.

1. Архитектура

Дополнение. Компоненты ТСВ, критичные с точки зрения безопасности, должны

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

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

2. Среда разработки

Процесс разработки.

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

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

раз­работки.

Управление конфигурацией в процессе разработки.

Изменение. Должны использоваться автоматизиро­ванные средства управления

конфигурацией, контроли­рующие все изменения, вносимые в ходе разработки в

аппаратное и специальное обеспечение, в исходные тексты и объектный код

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

для трансляции исходных текстов.

Дополнение. Средства управления конфигурацией должны обеспечивать

трансляцию и сборку исходных текстов ТСВ и осуществлять сравнение версий ТСВ

для под­тверждения внесенных изменений.

Дополнение. Средства управления конфигурацией должны обнаруживать

несоответствия между версиями различных компонентов ТСВ и автоматически

разрешать эти проблемы.

3. Контроль процесса разработки

Разработка с нотификации

Изменение. Функциональные спецификации должны включать формальное

описание модели безопасности.

Изменение. Разработчик должен обеспечить и проде­монстрировать полное

соответствие между моделью безо­пасности и реализованной политикой безопасности

и про­демонстрировать, что модель безопасности полностью обеспечивает политику

безопасности.

Разработка архитектуры.

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

ТСВ с остальными компонен­тами компьютерной системы с указанием исключительных

ситуаций и сообщений об ошибках.

Создание рабочего проекта.

Изменение. Разработчик обязан составить полуфор­мальное описание рабочего

проекта ТСВ.

Реализация. Без изменений.

4. Поставка и сопровождение

Без изменений.

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

Руководство но безопасности для пользователя. Без изменений.

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

6. Тестирование безопасности.

Изменение. Разработчик должен исправить все обна­руженные в ходе

тестирования ошибки, после чего провер­ит повторное тестирование ТСВ для

подтверждения того, что обнаруженные ошибки ликвидированы и притом не внесены

новые.

Дополнение. Разработчик должен провести тестиро­вание в виде попыток

несанкционированного проникновения в систему и доказать, что система

относительно ус­пешно противостоит атакам.

•Уровень Т-5.

1. Архитектура

Дополнение. Разработчик должен, по возможности, исключить из ТСВ не

критичные с точки зрения безопасности компоненты и обосновать свой выбор.

Дополнение. При проектировании ТСВ разработчик должен применять

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

должен ле­жать законченный концептуально простой механизм за­щиты с четко

определенной семантикой. Этот механизм должен играть основную роль в

обеспечении внутренней структуры ТСВ и всей системы. Архитектура ТСВ должна

использовать принципы модульности, абстракции и ин­капсуляции внутренних

объектов. Каждый компонент должен быть спроектирован с использованием принципа

наименьших привилегий.

2. Среда разработки

Процесс разработки. Без изменений.

Управление конфигурацией в процессе разработки. Без изменений.

3. Контроль процесса разработки

Разработка спецификаций. Без изменений.

Разработка архитектуры.

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

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

Создание рабочего проекта. Без изменений.

Реализация.

Изменение. Разработчик обязан предоставить все ис­ходные тексты ТСВ.

4. Поставка и сопровождение

Без изменений.

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

Руководство по безопасности для пользователя. Без изменений.

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

6. Тестирование безопасности

Изменение. Разработчик должен провести тестиро­вание в виде попыток

несанкционированного проникно­вения в систему и доказать, что система успешно

противо­стоит атакам.

• Уровень Т-6.

1. Архитектура

Без изменений.

2. Среда разработки

Процесс разработки.

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

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

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

Управление конфигурацией в процессе разработки.

Изменение. Должны использоваться автоматизиро­ванные средства управления

конфигурацией, контроли­рующие все изменения, вносимые в ходе разработки в

ап­паратное и специальное обеспечение, в исходные тексты|и объектный код

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

для трансляции исходных текстов и инструментальных средств разработ­ки.

Дополнение. Должны быть использованы техниче­ские, физические и

организационные меры для защиты от несанкционированной модификации или

уничтожения ди­стрибутивной копии ТСВ или дистрибутивных копий всех материалов,

используемых для построения ТСВ.

3. Контроль процесса разработки

Разработки спецификаций. Без изменений.

Разработка архитектуры.

Изменение. Разработчик обязан составить формаль­ное описание архитектуры

компьютерной системы.

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

архитектурой системы и моделью безо­пасности.

Создание рабочего проекта.

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

между архитектурой системы и рабо­чим проектом.

Реализация. Без изменений.

4. Поставка и сопровождение

Дополнение. Процесс дистрибуции компонентов ком­пьютерной системы должен

быть защищен с помощью со­ответствующих средств, обеспечивающие адекватность

поставляемой потребителю копии ТСВ дистрибутив.

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

Руководство но безопасности для пользователя. Без изменений.

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

6. Тестирование безопасности

Без изменений.

• Уровень Т-7

1. Архитектура

Без изменений.

2. Среда разработки

Процесс разработки. Без изменений.

Управление конфигурацией в процессе разработка

Без изменений.

3. Контроль процесса разработки

Разработка спецификаций. Без изменений.

Разработка архитектуры. Без изменений.

Создание рабочего проекта.

Изменение. Разработчик обязан составить формаль­ное описание рабочего

проекта ТСВ.

Изменение. Разработчик должен доказать полное Со­ответствие между

архитектурой системы и рабочим проек­том.

Реализация.

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

между рабочим проектом и реализа­цией ТСВ.

4. Поставка и сопровождение

Без изменений.

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

Руководство по безопасности для пользователя. Без изменений.

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

6. Тестирование безопасности

Без изменений

Приложение III.

критериев безопасности информационных технологий»

Это приложение содержит ранжированный перечень функциональ­ных требований и

требований адекватности, содержащихся в «Единых критериях». Данное изложение

отражает только суть требований и не претендует на перевод стандарта как

нормативного документа.

Для того чтобы отобразить иерархическое ранжирование требова­ний, присущее

«Единым критериям», будем представлять их в виде таб­лиц, в которых сравнимые

требования образуют столбцы, а несравни­мые — строки.

Рассмотрим соответствие таблиц и иерархии требований на сле­дующем примере:

Графическое представление иерархии:

соответствует следующей таблице:

Требования
1			5
2	3	4	6

В этой таблице каждое из несопоставимых между собой требований 2, 3 и 4

обеспечивает больший уровень безопасности, чем требование 1. Ни одно из них

несопоставимо с требованиями 5 и 6, образующими па­раллельную шкалу.

Функциональные требования

1. Аудит

Автоматическое реагирование на вторжение в систему поднятия тревоги
1. поднятие тревоги	2. Автоматическое реагирование
	3. Конфигурируемое автоматическое реагирование

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

Управление аудитом
I. Управление протоколом аудита	2. Контроль заполнения протокола аудита
	3. Управление пределами заполнения протокола аудита
4. Управление заполнением протокола аудита в ходе работы

Выявление отклонении от штатного режима работы

1. Выявление отклонении от штатною режима работы

2. Динамическое управление параметрами контроля

Распознавание вторжении в систему
1. Распознавание на основе простых эвристик	3. Динамический контроль за параметрами распознавания в ходе функционирования
2. Распознавание на основе сложных эвристик

Предобработка протокола аудита
1. Преобразование в форму. доступную для человека	2. Преобразование в форму, удобную для автоматической обработки	3. Преобразование в фор­му, допускающую после­дующие преобразования

Зашита протокола аудита

1. Ограниченная зашита протокола аудита

2. Расширенная защита протокола аудита

Постобработка протокола аудита
1. Преобразование в форму доступную для человека	2. Преобразование в форму, удобную для автоматической обработки	3. Преобразование в форму, допускающую последующие преобразования

Анализ протокола аудита
1. Анализ надвигающихся угроз на основе статических правил	2. Анализ надвигающихся угроз на основе динамических правил

Контроль доступа к протоколу аудита
1. Ограниченный контроль доступа к протоколу аудита	3. Избирательный контроль доступа к протоколу аудита
2. Расширенный контроль доступа к протоколу аудита

Отбор событий для регистрации н учета
1. Избирательный аудит
2. Выбор событий аудита в процессе работы	3. Выбор событии аудита в процессе работы администратором
	4. Выбор событии аудита в процессе работы уполномоченными пользователями

Выделение ресурса под протокол аудита

1. Выделение постоянного ресурса под протокол аудита

2. Учет потерянных данных протокола аудита

3. Предотвращение потерь данных протокола аудита

4. Управление предотвращением потерь данных протокола аудита

2. Информационный обмен

Невозможность для источника отречься от факта передачи информации

1. Принудительное доказательство передачи информации

2. Избирательное доказательство передачи информации

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

1. Принудительное доказательство приема информации

2. Избирательное доказательство приема информации

3. Защита информации

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

I. Управление доступом для ограниченного множества объектов и субъектов

2. Управление доступом для полного множества объектов и субъектов

Средства управления доступом
1. Управление доступом с по­мощью единственного атрибута безопасности	3. Средства предостав­ления прав доступа	5. Фиксированное рас­пределение прав доступа
2. Управление доступом с по­мощью нескольких атрибутов безопасности	4. Средства предостав­ления и отмены прав доступа

Инициализация атрибутов безопасности объектов
1. Статическая инициализация атрибутов безопасности
2. Определяемая администратором инициализация атрибутов безопасности	4. Управление инициализацией атрибутов безопасности на основе специальных пра­вил
3. Определяемая пользователем инициа­лизация атрибутов безопасности	5. Управление инициализацией и модифи­кацией атрибутов безопасности на основе специальных правил

Экспорт информации

Экспорт информации без сохранения атрибутов безопасности

Экспорт информации с сохранением атрибутов безопасности

Политика управления информационными потоками

Частичное управление информационными потоками

Полное управление информационными потоками

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

Импорт информации

Импорт информации без атрибутов безопасности

Импорт информации с атрибутами безопасности

Защита информации в процессе передачи между компонентами по внутренним каналам
1. Базовые средства защиты передаваемой информации	3. Мониторинг целостности передаваемой информации
2. Разграничение каналов передачи информации на основании атрибутов безопасности	4. Мониторинг целостности передаваемой информации на основе атрибутов безопасности
Уничтожение остаточной информации
1. Уничтожение остаточной информации при создании определенного подмножества объектов
2 Уничтожение остаточной информации при удалении определенного подмножест­ва объектов	3. Уничтожение остаточной информации при создании любых объектов
4. Уничтожение остаточной информации при создании любых объектов
Откат
1. Ограниченные возможности осуществления отката		3. Управление возможностью осуществления отката
2. Расширенные возможности осуществления отката

Правила модификации атрибутов безопасности
I. Модификация атрибутов безопасности администратором	3. Безопасная модификация атрибутов
2. Модификация атрибутов безопасности уполномоченными пользователями

Доступ к атрибутам безопасности

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

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

Целостность информации в процессе хранения

1. Контроль целостности информации в процессе хранения.

2. Контроль целостности информации при хранении с учетом ее атрибутов безопасно­сти.

Защита информации при передаче по внешним каналам

Базовая защита информации при передаче по внешним каналам

Целостность информации при передаче по внешним каналам
1. Обнаружение нарушений целостности при передаче информации	2. Восстановление информации получате­лем
	3. Повторная передача информации

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

Управление параметрами аутентификации пользователей

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

2. Базовое управление параметрами аутентификации пользователей

3. Расширенное управление параметрами аутентификации пользователей

Защита параметров аутентификации пользователей
1. Базовая защита параметров аутентифи­кации пользователей	2. Расширенная защита параметров аутентификации пользователей

Реакция на неудачные попытки аутентификации

1. Базовая обработка неудачных попыток аутентификации

2. Управление реакцией на неудачные попытки аутентификации

Управление атрибутами безопасности пользователей
1. Инициализация атрибутов безопасно­сти пользователей	2. Базовое управление атрибутами безо­пасности пользователей
	3. Расширенное управление атрибутами безопасности пользователей

Набор атрибутов безопасности пользователей

Индивидуальные и групповые атрибуты безопасности пользователей

Уникальные индивидуальные атрибуты безопасности пользователей

Генерация и проверка ключей и паролей
1. Выбор и проверка ключей и паролей	2. Генерация и проверка ключей и паролей

Аутентификация пользователей аутенти­ работы
1. Базовые механизмы аутентифи­кации пользователей			5. Приме­нение различных механизмов в соответствии с политикой аутентификации ­	7. Аутен­тифика­ция по за­ просу	8. От­ложен­ная аутентификация	9. Возмож­ность изменения состава средств аутентификации в процессе работы
2.Одноразовые механизмы аутентифика­ции ключи	3. Аутенти­фикация с контролем целост­ности параметров аутент­ификации	4. Применение несколь­ких механиз­мов аутентификаций	6. Настраивае­мые меха­низмы аутенти­фикации

Идентификация пользователей
1. Базовые механизмы идентификации пользовате­лей	3. Отложенная идентификация пользователей
2. Обеспечение уникальности идентификаторов пользователей

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

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

5. Конфиденциальность доступа к системе

Анонимность сеансов работы с системой

Анонимность сеансов пользователей

2. Анонимность пользователей при взаимодействии со средствами защиты

Использование псевдонимов
1. Использование псевдонимов для учета действий анонимных пользователей
2. Поддержка возможностей для средств защиты восстановления по псевдониму личности пользова­теля	3. Использование определенных правил образования псевдонимов

Невыводимость характеристик пользователя

Невозможность, определения пользователя, предпринимающего те или иные действия

Ненаблюдаемосгь сеансов работы с системой

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

2. Возможность определения использования объекта или ресурса только авторизованным администратором

6. Безопасность защиты

Тестирование аппаратно-программной платформы
1. Наличие средств тестирования аппа­ратно-программной платформы	2. Проведение тестирования аппаратно-программной платформы во время загрузки
3. Тестирование аппаратно-программной платформы в процессе работы

Защита от сбоев

1. Сохранение безопасного состояния в случае возникновения сбоев

Обеспечение взаимодействия средств защиты

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

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

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

Обеспечение целостности при взаимодействии средств защиты

1. Обнаружение модификации передаваемой информации при взаимодействии средств

защиты

2 Обнаружение модификации передаваемой информации при взаимодействии средств

защиты и ее восстановление

Защита информационного обмена между средствами защиты
1 Базовые средства защиты информационного обмена между средствами защиты
2 Защита информационного обмена между средствами защиты на основании атрибутов передаваемой информации	3. Контроль целостности информации при взаимодействии средств защиты

Физическая защита

1. Пассивное обнаружение атак на физическом уровне

2. Уведомление администратора об атаках на физическом уровне

3. Противодействие атакам на физическом уровне

Безопасное восстановление после сбоев
1. Ручное восстановление после сбоев	4 Восстановление после сбоев с возможностью отката
2 Автоматическое восстановление после сбоев
3. Автоматическое восстановление после сбоев с минимизацией потерь информации

Отзыв атрибутов безопасности

1. Базовые средства отзыва атрибутов безопасности

2. Обеспечение немедленного отзыва атрибутов безопасности

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

1. Распознавание повторных передач информации и имитации событий

Мониторинг взаимодействии

1. Тотальный мониторинг взаимодействия

Старение атрибутов безопасности

1. Отмена полномочии по истечении определенного периода времени

Разделение доменов

1. Выделение отдельного домена для средств защиты

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

3 Выделение необходимого числа доменов в соответствии с политикой безопасности

Обеспечение синхронизации

1. Одностороннее подтверждение о приеме информации

2. Взаимное подтверждение обмена информацией

Отсчет времени

1. Точный отсчет времени

Модификация ПО средств защиты

1. Защита целостность и исполняемого кода средств защиты

Разделение информации

1. Корректность использования информации средствами защиты

Репликация информации

1. Согласованность копий

Управление безопасностью

1. Базовые средства управления безопасностью

2. Выделение роли администратора безопасности

3. Выделение нескольких ролен администраторов безопасности с определенным

кругом обязанностей

4. Точно определенные роли администраторов и их обязанности

Руководство Безопасностью

1. Механизмы руководства безопасностью

Самотестирование

1. Самотестирование по запросу

2 Самотестирование во время загрузки

3 Самотестирование в процессе функционирования

Защита средств управления безопасностью

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

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

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

3. Гибкие средств управления безопасностью позволяющие администратору

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

7. Контроль за использованием ресурсов

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

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

8. Контроль доступа к системе

Ограничения на использование пользователями атрибутов и субъектов

1. Ограничения на использование атрибутов и субъектов

Ограничение числа одновременных сеансов

1. Базовые средства ограничения числа одновременных сеансов

2 Ограничение числа одновременных сеансов в зависимости от атрибутов пользователя

Блокировка сеанса работы
1. Автоматическая блокировка сеанса работы	2. Блокирование сеанса пользователем.	3 Автоматическое завершение сеанса работы

Объявления, предупреждения, приглашения и подскажи

1. Объявления, предупреждения, приглашения и подсказки установленных по

умолча­нию

2. Модифицируемые объявления, предупреждения, приглашения и подсказки

Протокол сеансов работы пользователей

1. Протоколирование сеансов работы пользователей

Управление параметрами сеансов

1. Базовые средства управления параметрами сеансов

Ограничения на сеансы работы

1. Конфигурирование сеансов работы

9. Обеспечение прямого взаимодействия

Прямое взаимодействие между компонентами ИТ-продукта

1. Обеспечение прямого взаимодействия между компонентами ИТ-продукта

Прямое взаимодействие с пользователями

1 Обеспечение прямого взаимодействия с пользователями

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

1. Управление конфигурацией

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

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

2 Полная автоматизация управления конфигурацией

Возможности управления конфигурацией

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

2 Применение авторизации при управлении конфигурацией

3. Генерация версий и процедура их приемки

4. Расширенные возможности управления конфигурацией

Область управления конфигурацией

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

2. Отслеживание изъянов в средствах безопасности

3 Управление конфигурацией инструментальных средств разработки

2. Дистрибуция

Поставка

1. Регламентированная процедура поставки

2. Обнаружение искажений в процессе поставки

3. Защита от искажении в процессе поставки

Установка, настройка, запуск

1. Регламентированные процедуры установки, настройки, запуска

2. Поддержка протокола генерации

3. Адекватность реализации

Общие функциональные спецификации

Соответствие общих функциональных спецификации политике безопасности

2 Реализация общими функциональными спецификациями неформальные модели политики безопасности

3. Реализация общими функциональными спецификациями полуформальной модели политики безопасности

4. Реализация общими функциональными спецификациями формальной моле т поли­тики безопасности

5. Описание интерпретации модели безопасности общими функциональными спецификациями

6 Формальная верификация адекватности реализации модели безопасности общими функциональными спецификациями

Архитектура защиты

1. Описание архитектуры защиты

2. Соответствие архитектуре защиты политике безопасности

3. Полуформальное определение архитектуры защиты

4. Полуформальное разъяснение архитектуры защиты

5. Формальное определение архитектуры защиты

Форма реализации

1. Предоставление описании реализации ограниченного подмножества средств защиты

2. Представление описании реализации всех средств защиты

3. Структурированное представление описании реализации средств защиты

Внутренняя структура средств защиты

1. Модульность

2 Иерархичность

3. Минимизация сложности

Частые спецификации функции защиты

1. Неформальные частые спецификации функции защиты

2. Полуформальные частые спецификации функции защиты

3. Формальные частые спецификации функции защиты

Соответствие спецификации и архитектуры требованиям безопасности

1. Неформальное доказагельство соответствия

2. Полуформальное доказательство соответствия

3. Формальное доказательство соответствия

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

Руководство администратора

1. Руководство администратора

Руководства пользователя

1. Руководства пользователя

5. Процесс разработки

Безопасность среды разработки

1. Применение мер безопасности в ходе разработки

2. Подтверждение мер безопасности, применяемых в ходе разработка

Исправление ошибок и ликвидация изъянов

1. Базовые средства учета ошибок и изъянов

2. Процедуры и средства обнаружения ошибок и изъянов

3. Применение средств ус гранения ошибок и изъянов

4. Регулярное применение средств устранения ошибок и изъянов

Технология разработки

1 Определенная разработчиком технология разработки

2 Использование стандартизованной технологии разработки

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

Средства разработки

1. Использование заданного набора средств разработки

2 Соответствие ограниченного подмножества средств разработки определенному стандарту

3 Соответствие всех средств разработки определенному стандарту

Полнота тестирования

1 Неформально подтвержденная полнота тестирования

2. Строго подтвержденная полнота тестирования

3. Всеобъемлющее тестирование

Глубина тестирования

1. Тестирование функциональных спецификаций

2. Тестирование архитектуры

3. Тестирование спецификаций средств защиты

4 Тестирование реализации средств защиты

Методика тестирования

1. Функциональные тесты

Независимое тестирование

1. Подготовка продукта к независимому тестированию

2. Избирательное независимое тестирование

3. Полное независимое тестирование

7. Оценка уязвимости

Анализ скрытых каналов

1. Анализ скрытых каналов

2. Систематический анализ скрытых каналов

3. Исчерпывающий анализ скрытых каналов

Анализ возможностей неправильного использования средств защиты

1. Анализ очевидных возможностей неправильного использования средств зашиты

2. Независимый анализ возможностей неправильною использования средств защиты

Анализ возможностей преодоления средств защиты

1. Оценка стойкости средств защиты

Анализ продукта на наличие изъянов защиты

1. Проведение анализа продукта на наличие изъянов защиты разработчиком

2. Независимый анализ продукта на наличие изъянов защиты

3. Относительная сопротивляемость продукта внешним воздействиям

4. Высокая сопротивляемость продукта внешним воздействиям

Для представления результатов классификационного анализа «Еди­ные критерии»

содержат семь стандартизованных уровней адекватности (п. 2.10.4.2).

Распределение требований адекватности по уровням пред­ставлено в таблице, в

ячейках которой указаны номера категорий требований адекватности, которым

должен удовлетворять продукт для присвоения ему соответствующего уровня

адекватности.

Требования адекватности	Номера уровней адекватности
	1	2	3	4	5	6	7
1. Управление конфигурацией
Автоматизация управления конфигурацией				1	1	2	2
Возможности управления конфигурацией	1	1	2	3	3	4	4
Область применения управления конфигурацией			1	2	3	3	3
2. Дне грибу цня
Поставка
Установка. Настройка. запуск		1	1	1	1	1	1
3. Адекватность реализации
Общие функциональные спецификации	1	1	1	2	4	5	6
Архитектура защиты		1	2	2	3	4	5
Форма реализации				1	2	3	3
Внутренняя структура средств защиты					1	2	3
Частые спецификации средств защиты				1	1	2	2
Соответствие спецификаций и архитектуры требованиям безопасности	1	1	1	1	2	2	3
4. Документация
Руководства администратора	1	1	1	1	1	1	1
Руководства пользователя	1	1	1	1	1	1	1
5. Процесс разработки
Безопасность среды разработки			1	1	1	2	2
Исправление ошибок и ликвидация изъянов
Технология разработки				1	2	2	3
Средства разработки				1	2	3	3
6. Тестирование
Полнота тестирования		1	2	2	2	3	3
Глубина тестирования		1	2	2	3	3	4
Методика тестирования		1	1	1	1	1	1
Независимое тестирование	1	1	2	2	2	2	3
7. Оценка уязвимости
Анализ скрытых каналов					1	2	2
Анализ возможностей неправильного использования средств защиты			1	2	2	2	2
Анализ возможностей преодоления средств защиты		1	1	1	1	1	1
Анализ продукта на наличие изъянов защиты		1	1	2	3	4	4

Приложение IV

(заимствовано из Carl E. Landwehr, Alan R. Bull, John P. McDermott, and

William S. Choi.

A Taxonomy of Computer Security Flaws, with Examples)

Данная подборка материалов ни в коей мере не мо­жет претендовать на

исчерпывающее описание всех из­вестных нарушений безопасности ВС и приведена

здесь исключительно для иллюстрации таксономии причин возникновения ИЗ и ее

обеспечения практическими при­мерами. Приведенные данные охватывают широкий

спектр как различных типов вычислительных систем, так и различных видов

нарушений безопасности, что необ­ходимо для выявления основных

закономерностей воз­никновения и проявления ИЗ.

Все эти примеры отражают реально имевшие место нарушения безопасности и

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

тип вычислительной системы, в которой имело место на­рушение безопасности,

кратко описываются ее особенно­сти и слабые стороны, использованные для

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

расположены в хронологическом порядке. Группам примеров, относящихся к одной

вычислительной системе, предшествует краткое описание ее структуры и

принципов функционирования, позволяющее понять реализованную в ней концепцию

зашиты.

Индексы примеров соответствуют системе обозначе­ний, принятой в [1] (см.

литературу к главе 3). В начале обозначения присутствует префикс,

определяющий тип ВС, за которым следует порядковый номер примера для данной

системы. В приложение вошли не все приведен­ные в [1] случаи, а только

наиболее характерные пред­ставители различных классов, в связи с чем

некоторое номера пропущены. В главе 3 отражены результаты, по­лученные при

анализе всей доступной информации, в том числе и не включенной в данное

Приложение.

Система IBM 360/370

В архитектуре систем IBM 360/370 существуют два состояния процессора — режим

выполнения прикладной программы, в котором запрещено выполнение подмно­жества

привилегированных команд (загрузка PSW, ини­циализация ввода/вывода и т.п.),

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

выполнения прикладным процессом привилегированной команды вызывает

прерывание, вызов привилегирован­ных команд из прикладных

(непривилегированных) про­цессов осуществляются посредством специального

вызова — Supervisor Call (SVC).

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

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

памяти значение ключа доступа равно 8, в то время как значение ключей для

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

Процесс, выполняющийся в области памяти с ненулевым значени­ем ключа, имеет

неограниченный доступ к другим об­ластям памяти с тем же (ключом доступа.

Кроме того, процесс может читать области памяти с другими значе­ниями ключей,

если только они не помечены как защищенные. Попытка записи в область памяти с

другим значением ключа приводит к возникновению прерыва­ния. Процессы

операционной системы выполняются в областях памяти со значением ключа, равным

0. Такие процессы имеют неограниченный доступ ко всем облас­тям памяти вне

зависимости от их ключей и статуса за­щищенности.

Подсистема ввода/вывода состоит из т. н. каналов, которые по сути

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

осуществ­ляющие обмен данными между памятью и внешними устройствами. С

каналом ввода/вывода может быть свя­зана специальная программа, которая

выполняется про­цессором ввода/вывода и осуществляет управление об­меном

данными между оперативной памятью и внешним устройством. Такие программы

после их инициализации функционируют независимо от основного процессора и

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

процессом ввода/вывода и контроль доступа возлагается на программу,

управляю­щую каналом ввода/вывода.

В многозадачной системе MVS имеется опция разде­ления времени Time Sharing

Option (TSO), которая по­зволяет одновременно нескольким пользователям

вы­полнять команды с интерактивных терминалов. В MVS существует категория

привилегированных процессов, объединенных понятием авторизованные программы

(Authorized Program Facility — APF). Эти программы занимают области памяти с

ключом доступа, равным 7. Им предоставлены возможности, недоступные

осталь­ным прикладным процессам, в частности перевод про­цессора в режим

супервизора. Данные процессы рас­сматриваются как расширение операционной

системы и считаются гарантированно безопасными (trustworthy).

Система IBM 370 является развитием системы 360 и представляет собой монитор

виртуальных машин. На ее основе министерством обороны США разработана система

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

Университетом штата Мичиган разработана система MTS (Michigan Terminal

System), специально предназначенная для работы как в пакетном, так и в

интерактивном режиме.

Индекс: I1. Система: IBM 360

Источник информации: A. S. Tanenbaum. Operating System Design and

Implementation. Prentice-Hall, Engle-wood Cliffs, NJ, 1987.

В системе IBM 360 имеется возможность нарушения контроля доступа к файлам. В

этой системе для обраще­ния к некоторым файлам требуется ввести

соответствую­щий пароль, причем процедура проверки правильности пароля

организована следующим образом: в систему вводится имя файла и пароль, а

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

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

и открытием файла. Для этого можно использовать фоновый процесс, который

имеет возможность записи в системные области памяти, например процесс обмена

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

файлу, пароль которого ему известен. Система проверяет га-роль и разрешает

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

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

которого проверялся пароль, а к другому, не­смотря на то что пароля для него

пользователь не знает.

Индекс: 14. Система: IBM VM/370

Источник информации: С. R. Attanasio, P. W. Markstein, R. J. Phillips

«Penetrating at Operating System: a study of VM/370 integrity», IBM System

Journal, 1976, PP.102—116.

При программировании каналов ввода/вывода на этапе трансляции управляющая

программа подверга­ется статическому анализу на допустимость исполь­зуемых

инструкций и обращений к областям памяти, однако при этом предполагается, что

каждая команда имеет фиксированную длину и выровнена по границе слова.

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

обязательно вы­ровненные по границе слова, что при наличии коман­ды перехода

на произвольный адрес позволяет органи­зовать передачу управления «в

середину» команды. Этот трюк приводит к выполнению других команд, со­стоящих

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

Соответствующим образом со­ставив подобную программу, пользователь может

за­пустить параллельный основным вычислениям процесс (как было отмечено выше,

программы ввода/вывода имеют доступ к любым областям памяти) и осущест­вить

неконтролируемый доступ к информации.

Индекс: 16. Система: IBM MVS (TSO)

Источник информации: R. Paans, G. Bones. «Surreptitious security violation in

the MVS operating system», Security, IFIP/Sec, Holland, 1983, pp. 95—101.

Существует возможность использования TSO для за­пуска привилегированного

процесса. Для этого необхо­димо запустить из TSO фоновый процесс и вызвать

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

обнаружить факт начала вы­полнения APF-процесса по изменению значения ключа

общей области памяти (для привилегированных процес­сов оно меньше 8). С этого

момента пользовательский фоновый процесс является привилегированным, так

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

После этого он может остановись APF-процесс и получить все привилегии и

возможности управления системой.

Индекс: 17. Система: IBM MVS

Источник информации: R. Paans, G. Bones. «Surrep­titious security violation

in the MVS operating system», Security, IFIP/Sec , Holland, 1983, pp.

101—105.

Коммерческие приложения, такие, как СУБД, часто должны устанавливаться в

систему как APF и выпол­няться как привилегированные. Считается, что такие

приложения являются доверенными и не используют предоставленные привилегии

для нарушения защиты и игнорирования установленных требований безопасно­сти.

Однако в ряде случаев (в первоисточнике приведен ряд примеров) доверенные

приложения предоставляют пользователю возможность использования

предостав­ленных им привилегий, что дает ему возможность на­рушать

безопасность системы. Данный пример пере­кликается с имеющейся в ОС Unix

возможностью за­пустить процесс с правами супервизора (пример U9).

Индекс: 19 Система КVM/370

Источник информации: М. Schaefer, В. Gold, R. Linde, and J. Schield, «Program

Confinement in KVM/370. Proc. of ACM National Conf., Oct., 1977.

Система KVM/370 выделяет каждой виртуальной машине квант времени физического

процессора. Причем виртуальная машина может использовать весь отведенный ей

квант или освободить процессор раньше срока. С учетом того, что виртуальная

машина имеет доступ к часам реального времени, существует возможность

орга­низовать скрытый канал передачи информации от одной виртуальной машины к

другой путем кодирования ин­формации величиной временного интервала,

использо­ванного виртуальной машиной.

Индекс: МТ1. Система: MTS

Источник информации: В. Hebbard et al. «A penetra­tion analysis of the Michigan

Terminal System». ACM SIGOPS Operating Systems Review 14, Jan. 1980,

pp. 7 — 20.

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

системных вызовов заставить систему изменить ряд критичных параметров и тем

са­мым отключить механизмы управления безопасностью и получить полный

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

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

косвенной адресации. В каждой функции ядра перед осуществлением каких-либо

дейст­вий проверяется принадлежность полученного парамет­ра-адреса

пространству пользовательского процесса, в противном случае запрос

пользователя отвергается. Од­нако пользователь может обойти этот контроль

посред­ством задания параметра, который содержит адрес, при­надлежащий самой

области передачи параметров. При этом можно добиться того, что в результате

вызова па­раметры будут модифицированы и в них окажутся адре­са важных

переменных из системной области, что дает возможность пользователю изменить

их при помощи других системных вызовов.

Операционная система Multics

Операционная система Multics изначально применя­лась на специально разработанных

компьютерах GE-645 фирмы General Electric. Позднее под управлением Multics

функционировали компьютеры серии HIS 61,80. Аналогично системам IBM 360/370

аппаратное, обеспе­чение этих компьютеров поддерживало два режима ра­боты: т.

н. master режим, в котором являлись допусти­мыми все команды, и

slave режим, в котором определен­ные команды были запрещены. Система

обеспечения безопасности включала в себя 8 колец защиты, которые в компьютерах

GE-645 были реализованы программно, а на платформе HIS 6180 — аппаратно. Кольцо

0 являлось наиболее привилегированным, предполагалось, что в нем может

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

Индекс: MU1 Система: Multics

Источник информации: A.S. Tanenbaum. «Operating System Design and

Implementation». Prentice-Hall, Englewood Cliffs, NJ, 1987.

Система Multics в режиме пакетной обработки информации при считывании с

перфокарт не поддерживала идентификацию/аутентификацию пользователя. Это

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

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

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

троянскую программу.

Индекс: MU2. Система: Multics

Источник информации: Р. A. Karger, R. R. Schell. «Multics Security

Evaluation: Vulnerability Analysis», ESD-TR-74-193, Vol. II, June 1974.

В случае, когда программа, выполняющаяся в менее привилегированном кольце

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

кольце, последняя должна удостовериться, что вызвавшая ее программа имеет

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

разделение колен защиты в системах на базе компьютеров GE-645 было

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

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

адресации системы GE-645, и проверка прав доступа не всегда осу­ществлялась

корректно, что позволяло непривилегиро­ванным программам получить доступ к

данным, обраба­тываемым в привилегированных кольцах защиты.

Индекс: MU3. Система: Multics

Источник информации: Р. A. Karger, R. R. Schell. «Multics Security Evaluation:

Vulnerability Analysis», ESD-TR-74-193, Vol. II, June 1974.

В ранних версиях Multics регистр указателя стека (sp) мог быть

модифицирован только в режиме master. Когда Multics получила широкое

распространение, это было признано неудобным, и в систему были внесены

измене­ния, допускавшие изменение регистра sp во всех режи­мах. Однако

в системе остался не исправлен ряд фраг­ментов кода, предполагавших, что

модификация регист­ра sp возможна только в режиме master. Это

нарушило интерфейс между master и slave режимами и позволило

использовать эти фрагменты кода для осуществления не­санкционированного

доступа.

Индекс: MU9. Система: Multics

Источник информации: Р. A. Karger, R. R. Schell. «Multics Security Evaluation:

Vulnerability Analysis», ESD-TR-74-193, Vol. II, June 1974.

С помощью программы тестирования аппаратно реализуемых механизмов защиты

Multics (авторы назва­ли ее Subverter) была выявлена аппаратная ошибка в

системе GE-645. Ошибка заключалась в следующем: если исполняемая команда

вызывала команду, находящуюся в самом начале другого сегмента, которая

использовала индексный регистр, но не устанавливала базу для индек­сации, то

эта команда выполнялась без какого-либо кон­троля со стороны аппаратных

средств. Благодаря этой возможности пользователь мог легко получить контроль

над всей системой.

Операционная система Burroughs 6700

Механизмы защиты ОС Burroughs были основаны на| том, что пользователь не мог

создать собственную при­кладную программу, кроме как с использованием

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

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

Индекс: В1. Система: Burroughs 6700

Источник информации: A.L. Wilkinson et al. «A pene­tration analysis of a

Burroughs large system», ACM SIGOPS Operating Systems Review 15, Jan. 1981,

pp. 14—25.

В системах Burroughs 6700 аппаратный контроль доступа к памяти осуществлялся

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

задаваемым значениями регистров границ, которые программы самостоятельно

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

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

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

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

система содержала со­ответствующий механизм, состоявший в том, что могли

выполняться только программы, созданные доверенными компиляторами, которые

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

файлу в системе был поставлен в соответствие оп­ределенный тип. Системный

загрузчик проверял соот­ветствие программ типу файлов, создаваемых

доверен­ным компилятором. Устанавливать тип файла неприви­легированному

пользователю было запрещено.

Таким образом, пользователь принципиально мог создать файл, который содержал

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

за­биравший на себя управление системой, но до тех пор, пока этому файлу не

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

выполнен.

В системе присутствовала утилита копирования фай­лов с/на магнитную ленту, в

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

находящихся на ленте. Это означало, что пользователь мог создать файл,

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

скопировать его обратно, после чего запустить на выполнение и по­лучить

контроль над системой.

Система Univac 1108

Компьютеры Univac 1108, предоставлявшие собой вы­сокопроизводительные

мейнфреймы, в 70-х годах обеспе­чивали вычислительными ресурсами

исследовательские лаборатории и университеты. Их основная память была

поделена на два банка, каждый из которых состоял из со­вокупности 512-байтных

элементов. Адресное простран­ство программ также состояло из двух банков:

банк I (банк инструкций) содержал код программы, банк D (банк данных) —

данные. Аппаратные средства защиты были организованы таким образом, что

программы мог­ли либо использовать оба банка как для чтения, так и для

записи, либо установить запрет на запись в оба банка.

Индекс: UN1. Система: Univac 1108/Exec 8

Источник информации: D. Stryker. «Subversion os a «Secure» Operating System»,

NRL Memorandum Report 2821. June 1974.

Операционная система мейнфреймов Univac —Exec 8 поддерживала одновременное

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

компиляторы и СУБД) с помощью их реализации в виде процессов с повторным

вхождением (re-entrant process, или REPs). Эти процессы хранили данные

пользователей в принадлежащих им D-банках и совместно использовали одну копию

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

записи.

Кроме того, Exec 8 содержала схему обработки ошибок, которая позволяла любой

программе перехватывать прерывание, генерируемое при возникновении ошибки

(например, при делении на ноль или выходе за границы памяти). Когда

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

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

должны были устанавливать свои собственные процедуры обработки ошибок, однако

многие процессы типа REP этого не делали. Это позволяло злоумышленнику

установить собственную про­грамму обработки ошибок, создать ошибочную

ситуа­цию в REP-процессе (например, организовав для него D-банк слишком

маленького размера) и перехватить прерывание. Получившая управление

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

по чтению, так и по записи к банкам I и D процесса типа REP. Это означало,

что она могла моди­фицировать его код, который имел доступ к D-банкам многих

пользователей, — например, внедрить «троян­ского коня», копирующего чужие

данные. Несмотря на то что подобная «троянская» программа будет рабо­тать

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

временного получения злоумышленником информации от процесса типа REP является

чрезвычайно опасной, так как дает ему неог­раниченный доступ к данным всех

остальных пользова­телей этого процесса.

Системы DEC PDP-10 и VAX

Системы DEC PDP-10 были компьютерами средней производительности, ставшими

стандартным средством поддержки распределенной интерактивной обработки данных

в 70-х годах. Эти системы функционировали под управлением ОС TENEX,

разработанной фирмой BBN. Компьютеры DEC VAX могли функционировать под

управлением операционной системы VMS, Unix-подоб­ной системы Ultrix и под

управлением операционных систем, разработанных самой DEC. В системе VMS

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

привилегиях пользователей. Пользо­ватель, который получил доступ к этому

файлу, получал неограниченные возможности управления системой.

Индекс: DT1. Система: TENEX

Источники информации: A. S. Tanenabum. «Opera­ting System Design and

Implementation». Prentice-Hall, Englewood Cliffs, NJ, 1987., и R. P. Abbott

et al, «Security Analysis and Enhancements of Computer Operating Systems,

Final Report of RISOS Project». National Bureau of Standards NBSIR-76-1041,

Apr. 1976, pp. 49—50.

Как и многие другие ОС, TENEX использовала сис­тему паролей для контроля

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

реали­зована таким образом, что позволяла злоумышленнику подобрать пароль за

небольшое количество попыток. Проверка пароля осуществлялась символ за

символом, причем выборка символов осуществлялась из области памяти

пользовательского процесса, а как только обнаруживался неверный символ —

проверка прекращалась. Так как пользователь контролировал область памяти,

откуда считывались символы пароля, он мог использовать для радикального

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

этого вариант пароля помещался на границу виртуальной страницы таким образом,

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

от­сутствовала в физической оперативной памяти. После этого, если при проверке

пароля возникала ситуации полгрузки страницы, это означало, что символ подобран

верно (процедура проверки обращалась к следующему символу только в том случае,

если текущий был верен), и противном случае процесс подбора этого символа

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

и т. д. Таким образом, вместе того чтобы проверять для подбора пароля,

состоящего из N символов алфавита мощностью М, MN комбинаций,

злоумышленник мог проверить всего M*N комбинаций. Это полностью

дискредитировало всю парольную систему защиты данной ОС.

Индекс: D1. Система: DEC VMS

Источник информации: «VMS code patch eliminates security breach». Digital

Review, June 1, 1987, p. 3.

Данный случай представляет особый интерес, так как система DEC VMS была

тщательным образом ис­следована на предмет наличия изъянов в средствах

за­щиты. В новой версии системы был добавлен системный вызов, предоставлявший

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

Проверка прав инициировавшего запрос пользователя на модификацию этого файла

выполнялась на основе анализа содержимого этого же файла. Поэтому в ходе

обработки этого запроса ОС первым делом открывала файл авторизации и

считывала из него соответствую­щую информацию. Если пользователь не имел

соответ­ствующих прав, выполнение запроса прекращалось. Од­нако при задании

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

получал от­каз, файл авторизации оставался открытым и доступ­ным для

пользователя. Злоумышленник, знавший об этом, мог присвоить себе все права по

управлению сис­темой.

Операционная система Unix

Операционная система Unix разрабатывалась луч­шими специалистами в области

создания ОС с одной целью — обеспечить удобную интерактивную среду об­работки

данных на компьютерах малой производи­тельности. Поэтому на ранних стадиях

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

поддерживает иерархическую файло­вую систему с контролем доступа, основанным

на по­нятии «владельца» файла. С каждым файлом связаны идентификаторы

владельца и группы, а также атрибуты доступа. Эти идентификаторы можно

изменить с по­мощью команд chown, chgrp. Атрибуты файла опреде­ляют права

доступа к нему. Все пользователи подразде­ляются на три категории:

· владелец файла, его идентификатор совпадает с идентификатором

владельца файла;

· члены группы владельца, их идентификатор груп­пы совпадает с

идентификатором группы файла;

· прочие — все остальные.

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

доступ (чтение, за­пись, выполнение) для каждой категории пользователей.

Изменить права доступа может только владелец файла либо root.

Пользователь с идентификатором root являет­ся администратором системы и

имеет неограниченные полномочия. Его действия не ограничиваются механиз­мами

контроля доступа.

Все пользователи системы зарегистрированы в спе­циальном файле /etc/passwd,

В нем указаны имена поль­зователей, их идентификаторы и пароли в зашифрован­ном

виде. Всем пользователям, кроме root, разрешен доступ к этому файлу

только по чтению. Если злоумыш­ленник получил возможность записи в этот файл,

он мо­жет создать пользователя с полномочиями root и полу­чить полный

контроль над системой.

Когда пользователь запускает процесс, как правило, ему присваивается

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

имени данного пользователя и с его правами доступа. Этому механизму недостает

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

модифи­кацию файла /etc/passwd в пределах относящейся к ним записи, был

введен атрибут SUID. Наличие у программы этого атрибута означает, что

при ее запуске соответст­вующий процесс будет иметь идентификатор и права не

запустившего его пользователя, а пользователя, являю­щегося владельцем файла,

содержащего программу. Как правило, этот атрибут устанавливается у системных

ути­лит, владельцем которых является root, требующий для своей работы

его полномочий. Например, утилита setpass, позволяющая пользователю

изменять свои пароль, должна иметь возможность осуществлять запись в файл

/etc/passwd. При этом безопасность системы полностью зависит от корректности

реализации подобных! программ, поскольку они позволяют любому пользова­телю

выйти за рамки своих полномочий.

Индекс: U2. Система: Unix

Источник информации: A. S. Tanenbaum. Operating System Design and

Implementation. Prentice-Hall, Engle-wood Cliffs, NJ, 1987.

Присутствующая во многих версиях Unix утилита lpr помещает файл в

очередь печати, а при указании опции «r», еще и удаляет его. В ранних версиях

Unix при ис­пользовании указанной опции проверка наличия полно­мочий на

удаление заданного файла у пользователя, вы­звавшего утилиту lpr,

отсутствовала. Это позволяло пользователю удалить любой файл, в том числе и файл

/etc/passwd, после чего ни один пользователь не мог вой­ти в систему.

Индекс: U3. Система: Unix

Источник информации: А. S. Tanenbaum. Operating System Design and

Implementation. Prentice-Hall, Engle-wood Cliffs, NJ, 1987.

В ряде версий Unix программа создания каталогов mkdir имела атрибут

SUID, а ее владельцем был root. Создание каталога происходило в две

стадии. Сначала посредством специального системного вызова mknod для

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

root. После этого с помощью другого системного вызова chown

владельцем нового ка­талога назначался пользователь, вызвавший mkdir.

По­скольку эти два этапа не были реализованы как атомар­ные операции, у

пользователей имелась возможность стать владельцем любого каталога и файла в

системе, в том числе и файла /etc/passwd. Для этого было достаточ­но

запустить mkdir как фоновый процесс и после выпол­нения первой стадии —

создания каталога, приостано­вить его. После этого пользователь удалял

созданный каталог и под тем же именем создавал ссылку {link) на файл

паролей /etc/passwd. Затем пользователь инициировал возобновление

выполнения утилиты mkdir, которая делала пользователя владельцем

созданного каталога. Однако, так как каталог предварительно был подменен

ссылкой на файл /etc/passwd, пользователь становился его владельцем.

Далее, в соответствии со своими полно­мочиями владельца, он мог изменять этот

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

Индекс: U4. Система: Unix

Источник информации: А.V. Discolo, «4.2 BSD Unix security». Computer Science

Department, University of California, Santa-Barbara, Apr. 1985.

Во многих версиях Unix команда sendmail позволяли неавторизованному

пользователю прочитать любой файл в системе. Эта программа могла считывать свой

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

файла не соответствовал синтакси­су команд sendmail, выводила на экран

каждую строку, в которой встретилась ошибка.

Проверка полномочий пользователя на доступ к файлу параметров не осуществлялась,

так как sendmail имела атрибут SUID, а ее владельцем был

root, так что пользователь легко мог ознакомиться с содержанием любого

файла, просто указав его в качестве файла пара­метров программы sendmail

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

синтаксису, принятому в sendmail, крайне мала).

Индекс: U5. Система: Unix

Источник информации: М.Bishop. «Security problems with the UNIX operating

system». Computer Science Department, Purdue University, West Lafayette,

Indiana, March. 1982.

Неправильное использование ограничений доступа к каталогам электронной почты

приводит к возникновению возможности преодоления системы защиты. В ряде версий

Unix почтовая программа после добавления но­вого сообщения к файлу, в котором

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

на имя которого поступило сообщение. При этом не производится никаких проверок

его атри­бутов. В дополнение к этому многие системы настроены таким образом,

что каталоги, содержащие электронную почту пользователей, доступны по записи

для всех поль­зователей. Это означает, что любой пользователь может удалить

«почтовый ящик» пользователя root и заменить его копией командного

интерпретатора с установленным атрибутом SUID и доступным для

выполнения лю­бым пользователем. После этого пользователь может послать на имя

root любое сообщение. Программа, об­служивающая почту, добавит это сообщение

в конец файла - «почтового ящика» и назначит ему нового вла­дельца — root.

Таким образом, в системе появится командный интерпретатор, с установленным

атрибутом SUID, владельцем root, и доступный для выполнения

любому пользователю.

Индекс: U7. Система: Unix

Источник информации: М. Bishop. «Security problems with the UNIX operating

system». Computer Science Department, Purdue University, West Lafayette,

Indiana, March,1982.

В Unix имеется утилита uux, реализующая удаленное выполнение

ограниченного множества команд и про­грамм. Командная строка, содержащая имя и

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

mix на удаленную машину, где осуществля­ется ее анализ и проверка на

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

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

анализа командной строки содержалась ошибка, которая позволяла выполнять

программы, не входящие в множество допустимых.

Разбор командной строки был организован следую­щим образом: утилита uux

читала первое слово команд­ной строки (имя команды), проверяла его, а затем

про­пускала (как аргументы и опции команды) все после­дующие символы до первого

разделителя команд (признака конца команды). Затем производился разбор

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

передавалась командному интерпрета­тору для выполнения. Но множество

проверяемых разделителей команд было неполным, символы «|», «Λ», «;»

учитывались, а «&» и «'» — нет. Таким образом, коман­ды, следующие за

неизвестным программе них раздели­телем. выполнялись, но не проверялись

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

осуществить удаленный запуск любых про­грамм и выполнение любых команд в обход

контроля них.

Индекс: U10. Система: Unix

Источник информации: Е. Н. Spafford. «Crisis and Aftermath», Comm. of the ACM

32, June 1989, PP 678 — 687.,

Во многих версиях ОС Unix программа sendmail распространялась с

установленной по умолчанию отладоч­ной опцией, позволявшей неавторизованным

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

посылать сообщения, снабженные npoграммой-получателем, которая запускается на

удалена ной машине и осуществляет прием сообщения. Эта воз­можность

использовалась разработчиками для отладки программы и в коммерческой версии

была оставлена по ошибке. Злоумышленник мог указать в качестве

программы-приемника командный интерпретатор, а в текст сообщения включить

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

системы, несмотря на то что он не был в ней зарегистри­рован. Известный вирус

Р. Морриса использовал эту возможность для проникновения в удаленные системы.

Индекс: U11. Система: Unix

Источник информации: D. Gwyn. «UNIX-wizard digest», Vol. 6 No. 15, Nov. 1988.

Команда chfn системы Unix предоставляет пользова­телям возможность

изменить имя, под которым они за­регистрированы в системе. Поскольку имя

пользователя хранится в файле /etc/passwd, эта программа должна иметь

возможность записи в этот файл. Для этого она имеет атрибут SUID, а ее

владельцем является root. Само по себе изменение имени не несет никакой

угрозы, но команда chfn не осуществляла проверку длины заданной

пользователем строки символов. Пользователь, знаю­щий об этом, мог создать

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

поме­щается на место прежней записи, и в файл /etc/passwd бу­дет

записана пустая строка. Пустая строка в этом файле интерпретируется как наличие

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

полномо­чиями root. Таким образом злоумышленник мог создать для себя

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

Индекс: U12. Система: Unix (4.3 BSD on VAX)

Источник информации: J. A. Rochlis, M. W. Eichin, «With microscope and

tweezers: the worm from MITs perspective», Comm. ACM 32, June 1989, pp.

689—699.

Программа-демон fingerd имеющаяся в каждой Unix системе, предназначена

для передачи удаленным пользо­вателям информации о пользователях локальной

систе­мы. Ошибка в этой программе позволяла неавторизо­ванному пользователю

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

фрагмент кода примерно следующего вида:

{

char buffer[100] ;

.

gets(buffer);

}

Проверка переполнения буфера не осуществлялась. Так как буфер размещался в

стеке, то, создав в нем фрагмент кода и вызвав переполнение стека, можно

за­менить адрес возврата из процедуры таким образом, что управление будет

передаваться на этот код. Посредством формирования соответствующего кода

злоумышленник мог вынудить систему выполнить любую необходимую ему команду, в

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

отладочной опцией команды sendmail использовалась вирусом Р. Морриса.

Индекс: U14. Система: Unix (SunOS)

Источник информации: J. Purtilo, RISKS-FORUM Digest, Vol. 7 No. 2, June 1988.

Процесс-демон rpc.rexd обеспечивает в системе Unix поддержку удаленного

выполнения программ. В реали­зации данной программой механизма идентификации

присутствовала ошибка. Когда приходил запрос с уда­ленной системы на выполнение

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

запрос. Если это был пользователь root, запрос отвергался, так как

root удаленной системы не имеет полномочий на локальной. Если это был не

root, rpc.rexd проверял легальность для локальной системы

идентификатора пользователя удаленной системы и в случае наличия в

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

процесс.

Эго означало, что пользователь, имеющий полномочия root в одной системе,

мог создать пользователя с идентификатором, совпадающим с идентификатором

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

имени и с полномочиями этого пользователя. Таким образом, злоумышленник,

полу­чивший контроль над одной из систем, мог получить доступ и к другим

системам.

Персональные компьютеры

Распространенное системное программное обеспече­ние персональных компьютеров

(ПК) характеризуется отсутствием средств защиты. В первую очередь это

касается таких популярных систем, как DOS, Windows, Windows 95. Системы, при

разработке которых было уделено хотя бы некоторое внимание проблеме защиты

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

сервисных ОС, предостав­ляющих пользователям тот или иной сервис. В качестве

примера можно назвать Novel NetWare, Windows NT и многочисленные версии Unix

для ПК (SCO, Linux, Solaris, QNX). Наиболее широко распространена ин­формация

о вирусных атаках и механизмах функциони­рования вирусов, использующих

отсутствие в ОС, при­меняемых на ПК, даже минимальной зашиты. В качестве

примера можно упомянуть публикацию авторов, посвя­щенную этой теме [19]

(литература к главе 3). В силу дос­тупности информации по этому вопросу

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

базе ПК представляется нецелесообразным. Приведенные в таблицах третьей главы

индексы приме­ров, связанных с нарушениями информационной безо­пасности ПК

(IN1, РС1-РС4, МА1, МА2 СА1, \Т1), со­ответствуют индексам из [1] (литература

к главе 3).

Специализированный Центр Защиты Информации и Кафедра Информационной

предлагает:

· анализ безопасности прикладною и системного программного

обеспечения и подготовку материалов для сертификации;

· разработку безопасных информационных систем:

· разработку безопасных сетевых решений для корпоративных сетей, в т.

ч. подключение к Internet;

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

программных средств и современных сетевых решений;

· обучение по специальности 22.07 «Организация и технология защиты

информации» (квалификация: инженер, бакалавр, магистр);

· краткосрочные курсы повышения квалификации администраторов

безопасности;

· книги и учебные пособия по информационной безопасности.

оказывает услуги:

- восстановление работоспособности локальных сетей

Novell NetWare, UNIX и Windows NT в случае утери пароля:

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

сбоев;

- обнаружение и отражение удаленных атак в сетях Internet и Novell NetWare.

Наш адрес: 195251, Санкт-Петербург, Политехническая ул., д. 29, главное

здание, ауд. 166, Тел./факс (812) 552-64-89

E-mail: WWW: www.ssl.stu.neva.ru

Содержание

Введение.......................................................................2

Глава 1........................................................................3

Проблемы создания защищенных информационных систем.............................3

1.1. Актуальность защиты систем обработки информации...........................3

1.2. Предпосылки кризиса обеспечения безопасности компьютерных систем..........3

1.3. Задачи данной книги.......................................................4

1.4. Структура данной книги....................................................5

1.5. Заключение к главе 1......................................................5

Литература к главе 1...........................................................6

Глава 2........................................................................7

Обзор и сравнительный анализ стандартов информационной безопасности............7

2.1. Введение..................................................................7

2.2. Основные понятия и определения............................................7

2.3. Угрозы безопасности компьютерных систем...................................8

2.4. Роль стандартов информационной безопасности...............................8

2.5 Критерии безопасности компьютерных систем министерства обороны США

(«Оранжевая книга»). 9

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

2.5.2. Таксономия требовании и критериев «Оранжевой книги».....................9

2.5.2.1. Политика безопасности.................................................9

2.5.2.2. Аудит................................................................10

2.5.2.3. Корректность.........................................................10

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

2.5.3. Классы безопасности компьютерных систем................................10

2.5.4. Интерпретация и развитие «Оранжевой книги».............................12

2.5.5. Выводы.................................................................13

2.6. Европейские критерии безопасности информационных технологий..............13

2.6.1. Основные понятия.......................................................13

2.6.2. Функциональные критерии................................................13

2.6.3. Критерии адекватности..................................................14

2.6.4. Выводы.................................................................15

2.7. Руководящие документы Гостехкомиссии России..............................15

2.7.1. Основные положения.....................................................15

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

2.7.2.1. Показатели защищенности СВТ от НСД...................................16

2.7.2.2. Требования к защищенности aвтоматизированных систем..................17

2.7.3. Классы защищенности автоматизированных систем..........................17

2.7.4. Выводы.................................................................18

2.8. Федеральные критерии безопасности информационных технологий..............19

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

2.8.2. Основные положения.....................................................19

2.8.3. Профиль защиты.........................................................20

2.8.3.1. Назначение и структура профиля защиты................................20

2.8.3.2 Этапы разработки профиля защиты.......................................21

2.8.4. Функциональные требования к ИТ-продукту................................21

2.8.4.1. Таксономия функциональных требований.................................22

2.8.4.2. Ранжирование функциональных требований...............................24

2.8.5. Требования к технологии разработки ИТ-продукта.........................25

2.8.6. Требования к процессу квалификационною анализа ИТ-продукта.............26

2.8.7. Выводы.................................................................27

2.9. «Канадские критерии безопасности компьютерных систем»....................27

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

2.9.2. Базовые понятия «Канадских критериев»..................................27

2.9.2.1 Объекты и субъекты....................................................27

2.9.2.2. Теги.................................................................28

2.9.3. Основные положения и структура «Канадских критериев»...................28

2.9.4. Выводы.................................................................30

2.10. Единые критерии безопасности информационных технологий..................31

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

2.10.2. Основные положения....................................................32

2.10.2.1. Профиль защиты......................................................33

2.10.2.2. Проект защиты.......................................................35

2.10.3. Требования безопасности...............................................37

2.10.3.1 Функциональные требования............................................37

2.10.3.2. Требования адекватности.............................................42

2.10.4. Выводы................................................................43

2.11. Анализ стандартов информационной безопасности...........................43

2.11.1. Универсальность.......................................................44

2.11.2. Гибкость..............................................................44

2.11.3. Гарантированность.....................................................45

2.11.4. Реализуемость.........................................................45

2.11.5. Актуальность..........................................................45

2.12. Заключение..............................................................46

Литература к главе 2..........................................................46

Глава 3.......................................................................48

Исследование причин нарушений безопасности ВС.................................48

3.1. Нарушения безопасности ВС и изъяны защиты................................48

3.2. Исследования нарушений безопасности компьютерных систем..................48

3.3. Таксономия ИЗ............................................................49

3.3.1. Классификация ИЗ по источнику появления................................49

3.3.1.1. Преднамеренно внедренные ИЗ с наличием деструктивных функций.........50

3.3.1.2. Преднамеренно внедренные ИЗ без деструктивных функций................51

3.3.1.3. Непреднамеренные ошибки и ИЗ.........................................51

3.3.2. Классификация ИЗ по этапу возникновения................................52

3.3.2.1. Возникновение ИЗ в процессе разработки системы.......................52

3.3.2.1.1. Составление требований и спецификаций..............................52

3.3.2.1.2. Создание исходных текстов программ.................................53

3.3.2.1.3. Генерация исполняемого кода........................................53

3.3.2.2. Возникновение ИЗ в процессе сопровождения и развития системы.........53

3.3.2.3. Возникновение ИЗ в процессе функционирования системы.................53

3.3.3. Классификация ИЗ по размещению в системе...............................53

3.3.3.1. Системное программное обеспечение....................................54

3.3.3.2. Сервисное программное обеспечение....................................55

3.3.3.3. Прикладное программное обеспечение...................................55

3.3.4. Результаты исследования таксономии ИЗ и их практическое

применение...................................................................

........... 55

3.4. Исследование причин возникновения ИЗ.....................................55

3.4.1. Таксономия причин возникновения ИЗ.....................................56

3.4.2. Взаимосвязь таксономии причин нарушения безопасности и классификации

ИЗ................................................................... 57

3.5 Заключение................................................................59

Литература к главе 3..........................................................59

Приложение I..................................................................60

Ранжированные функциональные требования «Федеральных критериев безопасности

информационных

технологий»..................................................................

.............................................................................

.................. 60

1. Идентификация и аутентификация.............................................60

2. Регистрация пользователя в системе.........................................61

3. Обеспечение прямого взаимодействия с ТСВ...................................62

5. Политика управления доступом (произвольное и нормативное управление

доступом)........................ 64

6. Контроль скрытых каналов...................................................66

7. Контроль за распределением ресурсов........................................67

8. Политика управления безопасностью..........................................67

9. Мониторинг взаимодействий..................................................69

10. Логическая защита ТСВ.....................................................69

11. Физическая защита ТСВ.....................................................70

12. Самоконтроль ТСВ..........................................................71

14. Ограничение привилегий при работе с ТСВ...................................72

15. Простота использования ТСВ................................................73

Приложение II.................................................................74

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

систем»................ 74

1. Критерии конфиденциальности................................................74

1.1. Контроль скрытых каналов.................................................74

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

1.3. Нормативное управление доступом..........................................75

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

2. Критерии целостности.......................................................76

2.1. Домены целостности.......................................................76

2.2. Произвольное управление целостностью.....................................76

2.3. Нормативное управление целостностью......................................77

2.4. Физическая целостность...................................................77

2.5. Возможность осуществления отката.........................................78

2.6. Разделение ролей.........................................................78

2.7. Самотестирование.........................................................79

3. Критерии работоспособности.................................................79

3.1. Контроль за распределением ресурсов......................................79

3.2. Устойчивость к отказам и сбоям...........................................80

3.3. Живучесть................................................................80

3.4. Восстановление...........................................................81

4. Критерии аудита............................................................81

4.1. Регистрация и учет событий в системе.....................................81

4.2. Идентификация и аутентификация...........................................82

4.3. Прямое взаимодействие с ТСВ..............................................83

5. Критерии адекватности реализации...........................................83

Приложение III................................................................90

Ранжированные требования «Единых критериев безопасности информационных

технологий»...... 90

Приложение IV................................................................101

Статистика нарушений безопасности компьютерных систем........................101