Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

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




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

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

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

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

· аппаратные, программные и специальные компо­нентыТСВ;

· множество параметров конфигурации ТСВ.

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

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

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

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

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

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

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

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

В Приложении I приведен полный ранжированный перечень функциональных требований «Федеральных критериев».

Требования к технологии разработки ИТ-продукта

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

Требования к технологии разработки ИТ-продуктов включают четыре раздела: требования к процессу разра­ботки, к среде разработки, к документированию и к со­провождению.

 

Таблица 2.3.Ранжирование функциональных требований «Федеральных критериев».

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

 

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

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

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

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

«Федеральные критерии» содержат ранжированный перечень типовых требований к технологии разработки ИТ-продуктов. Выполнение требований к технологии разработки является необходимым условием для прове­дения процедуры квалификационного анализа.

Рис. 2.6 Таксономия требований «Федеральных критериев» к технологии разработки ИТ-продукта.

2.8.6. Требования к процессу квалификационною анализа ИТ-продукта

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

 

Рис. 2.7 Таксномия требований «Федеральных критериев» к процессу квалификационнго анализа ИТ-продукта

Раздел требований к анализу ИТ-продукта содержит требования к проведению независимого анализа пред­ложенного решения и к его реализации в виде конкрет­ного средства.

Раздел требований к контролю регламентирует про­верку соответствия среды разработки ИТ-продукта и обеспечиваемого производителем сопровождения требо­ваниям к технологии разработки.

Требования к тестированию описывают процедуру проведения тестирования функций ТСВ как самим раз­работчиком ИТ-продукта, так и независимыми экспер­тами.

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

Выводы

«Федеральные критерии безопасности информаци­онных технологий» являются первым стандартом ин­формационной безопасности, в котором определяются три независимые группы требований: функциональные требования к средствам защиты, требования к техноло­гии разработки и к процессу квалификационного анали­за. Авторами этого стандарта впервые предложена кон­цепция профиля защиты — документа, содержащего описание всех требований безопасности как к самому ИТ-продукту, так и к процессу его проектирования, раз­работки, тестирования и квалификационного анализа.

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

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

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

Данный стандарт ознаменовал появление новою по­коления руководящих документов в области информаци­онной безопасности, а его основные положения послужи­ли базой для разработки «Канадских критериев безопас­ности компьютерных систем» (п. 2.9) и «Единых критериев безопасности информационных технологий» (п. 2 10).





Воспользуйтесь поиском по сайту:



©2015- 2022 megalektsii.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.