-150-

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

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

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

5.4.4. Функциональные требования к продукту информационных технологий

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

Функциональные требования, приведенные в “Федеральных критериях”, определяют состав и функциональные возможности доверенной вычислительной базы (Trusted Computer Base, TCB) или в принятой терминологии, ядра защиты (ЯЗ). Ядро защиты объединяет все компоненты ПИТ (аппаратные, программные и специальные средства), реализующие функции защиты. Таким образом, функциональные требования, направленные на обеспечение безопасности, относятся либо к внутренним элементам ЯЗ, либо к ее внешним функциям, доступным через специальные интерфейсы.

Для того, чтобы расширить спектр потенциального применения Профиля защиты в “Федеральных критериях”, при описании функциональных требований предполагается, что ЯЗ является единственной частью ПИТ, которая нуждается в защите и обладает такой характеристикой, как уровень защищенности. По этой причине предполагается достаточным установить множество требований, касающихся только безопасности ЯЗ.

-151-

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

Структура функциональных требований Функциональные требования “Федеральных критериев” разделены на

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

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

Требования к реализации политики безопасности описывают функции

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

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

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

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

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

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

-152-

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

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

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

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

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

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

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

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

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

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

-компоновка, установка, конфигурация и поддержка ßÇ;

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

-администрирование политики управления доступом;

-управление потреблением ресурсов системы;

-аудит действий пользователей.

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

-153-

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

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

Физическая защита ЯЗ. Требования этой группы задают ограничения на физический доступ к компонентам ЯЗ, а также допустимые физические параметры среды функционирования КС.

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

Инициализация и восстановление ЯЗ. Требования данной группы устанавливают возможности ßÇ по контролю за процессом собственной инициализации и способности к самовосстановлению после сбоев. Процесс восстановления после сбоя должен происходить без нарушений функционирования, даже временного, средств защиты. Восстановленное состояние ЯЗ должно соответствовать требованиям политики безопасности, мониторинга взаимодействий и самоконтроля целостности.

Ограничение привилегий при работе с ЯЗ. Требования этой группы устанавливают порядок назначения полномочий для работы с ßÇ. Основным принципом назначения таких полномочий является принцип минимальной достаточности. Это обеспечивается посредством постоянного контроля и, при необходимости, автоматического понижения привилегий пользователей при обращении к компонентам или сервису ЯЗ. Соблюдение этого принципа позволяет минимизировать нарушения целостности в случае возникновения сбоев или нарушений безопасности.

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

-154-

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

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

Ранжирование функциональных требований Состав и содержание включенных в Профиль защиты функциональных

требований определяются средой эксплуатации ПИТ. Чтобы обосновать выбор тех или иных требований и не вступать в противоречие с существующими стандартами в области безопасности ПИТ, функциональные требования, приведенные в “Федеральных критериях”, ранжируются по уровням с помощью следующих четырех критериев: широта сферы применения, степень детализации, функциональный состав средств защиты, обеспечиваемый уровень безопасности.

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

-пользователи системы, субъекты и объекты доступа;

-функции ЯЗ и интерфейс взаимодействия с ßÇ;

-аппаратные, программные и специальные компоненты ЯЗ;

-множество параметров конфигурации ЯЗ.

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

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

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