Вопрос № 4. Функциональные требования к ИТ-продукту

Вопрос № 4. Многофункциональные требования к ИТ-продукту


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

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



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

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

4.1. Таксономия многофункциональных требований

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

Рис. 2. Таксономия многофункциональных требований "Федеральных критериев"

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

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

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

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

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


Загрузка...

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

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

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

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

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

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

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

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

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

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

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

- сборка, установка, конфигурация и поддержка ТСВ;

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

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

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

-аудит действий юзеров.

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

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

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

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

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

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

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

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

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

4.2. Ранжирование многофункциональных требований

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

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

- юзеры системы, субъекты и объекты доступа;

- функции ТСВ и интерфейс взаимодействия с ТСВ;

- аппаратные, программные и особые составляющие ТСВ;

- огромное количество характеристик конфигурации ТСВ.

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

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

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

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

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

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

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

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


Таблица 1. Ранжирование многофункциональных требований "Федеральных критериев"

Многофункциональные требования Широта сферы приме- нения Степень детали-зации Многофункциональный состав средств защиты Обеспе-чиваемый уровень безопас-ности
Реализация политики безопасности
Политика аудита
Идентификация и аутентификация * *
Регистрация в системе *
Обеспечение прямого взаимодействия с ТСВ * *
Регистрация и учет событий * *
Политика управления доступом * * *
Контроль укрытых каналов * *
Политика обеспечения работоспособности
Контроль за рассредотачиванием ресурсов * *
Отказоустойчивость - - - -
Управление безопасностью * *
Мониторинг взаимодействий * * *
Логическая защита ТСВ *
Физическая защита ТСВ * *
Самоконтроль ТСВ * *
Инициализация и восстановление ТСВ *
Ограничение льгот при работе с ТСВ *
Простота использования ТСВ * *




Возможно Вам будут интересны работы похожие на: Вопрос № 4. Функциональные требования к ИТ-продукту:


Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Похожый реферат

Cпециально для Вас подготовлен образовательный документ: Вопрос № 4. Функциональные требования к ИТ-продукту