Лекция 1: Обзор наиболее важных стандартов и спецификаций в области информационной безопасности
Защита функций безопасности объекта оценки
жүктеу/скачать 0.51 Mb.
|
| Защита функций безопасности объекта оценки
Мы продолжаем рассмотрение классов функциональных требований, направленных на достижение высокоуровневых целей безопасности. Класс FPT (защита функций безопасности объекта оценки) включает шестнадцать семейств (больше, чем какой-либо другой класс функциональных требований ), которые можно разбить на четыре группы: архитектурная безопасность ; защита реализации функций безопасности; защита данных функций безопасности; инфраструктурные требования. Важнейший принцип архитектурной безопасности - невозможность обхода защитных средств. Семейство FPT_RVM ( посредничество при обращениях ) предназначено для достижения этой цели. Входящий в него единственный компонент FPT_RVM.1 (невозможность обхода политики безопасности ОО) предписывает, чтобы функции, проводящие в жизнь политику безопасности, вызывались и успешно выполнялись прежде любого другого действия, предусмотренного ПБ. Еще один фундаментальный принцип архитектурной безопасности поддерживается семейством FPT_SEP ( разделение доменов ). Минимально необходимо отделение домена функций безопасности ( компонент FPT_SEP.1), то есть функции безопасности должны поддерживать домен безопасности, который защищает их от вмешательства не облеченных доверием субъектов и искажений с их стороны (кроме того, должно быть реализовано разделение доменов безопасности субъектов). Максимальный уровень потребует реализации полного монитора обращений ( компонент FPT_SEP.3), то есть предоставление отдельного домена той части функций безопасности, которая проводит в жизнь политики управления доступом и/или информационными потоками. Защитой реализации функций безопасности занимаются четыре семейства. Самое простое из них (по формулировке, но не по воплощению и/или проверке), FPT_FLS ( безопасность при сбое ), содержит требование, чтобы политика безопасности не нарушалась при сбоях заданных типов. Обеспечения высокой доступности и корректной работы функций безопасности вопреки возможным сбоям добивается и более сложное семейство FPT_RCV ( надежное восстановление ). FPT_RCV.4 (восстановление функции) предписывает, что функция безопасности либо нормально завершается, либо, для предусмотренных сценариев сбоев, восстанавливается ее устойчивое и безопасное состояние. Первые три его компонента отвечают за восстановление - ручное, автоматическое и автоматическое без недопустимой потери. Для ручного восстановления требуется, чтобы после сбоя функции безопасности перешли в режим аварийной поддержки, оставляющего возможность возврата ОО к безопасному состоянию. Автоматическое восстановление без недопустимой потери означает следующее: при сбоях заданных типов возврат к безопасному состоянию обеспечивается автоматическими процедурами; безопасное состояние восстанавливается без превышения заранее определенной меры потери данных; функции безопасности помогают выяснить, какие объекты могут быть восстановлены, а какие нет. Семействo FPT_PHP ( физическая защита ) требует наличия средств выявления и реагирования на несанкционированный физический доступ к частям ОО, участвующим в реализации функций безопасности. Компонент FPT_PHP.1 (пассивное обнаружение физического нападения) можно отнести к средствам контроля целостности, так как он требует однозначного обнаружения физического воздействия, которое может угрожать выполнению функций безопасности; информация о наличии или отсутствии подобного воздействия предоставляется по запросу. Усиливающий компонент FPT_PHP.2 (оповещение о физическом нападении) предусматривает постоянный контроль за определенными элементами и оповещение назначенного пользователя о подобных происшествиях. Наконец, компонент FPT_PHP.3 (противодействие физическому нападению) требует автоматической реакции, предотвращающей нарушение политики безопасности. Семейство FPT_TST ( самотестирование функций безопасности ) состоит из одного компонента, но служит сразу двум целям: выполняет собственно самотестирование (при запуске, периодически, по запросу уполномоченного пользователя и т.п.), а также осуществляет контроль целостности данных и выполняемого кода функций. Объединение в одном компоненте двух существенно разных видов требований представляется странным (тестирование имеет мало общего с контролем целостности кода и, тем более, изменяемых данных), но позволяет плавно перейти к третьей группе семейств класса FPT (защита данных функций безопасности). В эту группу входят шесть семейств, три из которых, FPT_ITA, FPT_ITC и FPT_ITI, отвечают, соответственно, за доступность, конфиденциальность и целостность экспортируемых данных функций безопасности. Отметим, что доступность должна быть обеспечена с заданной вероятностью, а контроль целостности в общем случае предусматривает возможность восстановления поврежденных данных удаленным доверенным изделием ИТ. Семейство FPT_TDC содержит требование согласованной интерпретации данных, совместно используемых функциями безопасности ОО и другим доверенным изделием ИТ. Явных требований к контролю импортируемых данных в классе FPT (в отличие от FDP) нет, хотя из соображений симметрии они, безусловно, должны присутствовать (см. выше семейства FDP_ETC и FDP_ITC). Пятое семейство группы, FPT_ITT (передача данных функций безопасности в пределах объекта оценки), аналогично рассмотренному ранее семейству из класса защиты данных пользователя FDP_ITT (передача в пределах ОО), но не предусматривает обеспечения доступности и разделения по атрибутам при контроле целостности. Справедливости ради укажем, однако, что в компоненте FPT_ITT.3 более детально специфицированы обнаруживаемые виды нарушений целостности: модификация, подмена, перестановка, удаление данных. Семейство FPT_TRC отвечает за согласованность данных функций безопасности при дублировании в пределах ОО. Здесь следует обратить внимание на требования элемента FPT_TRC.1.2: если части ОО, содержащие дублируемые данные, были разъединены, необходимо обеспечить согласованность таких данных после восстановления соединения перед обработкой запросов к заданным функциям безопасности. Отметим, что к взаимодействию с удаленным доверенным изделием ИТ требование согласованности данных не предъявляется. В целом же остается неясным смысл разнесения по разным классам требований защиты данных пользователя и функций безопасности. Последние, кроме того, трактуются как одноуровневые, для них не предусмотрено разделение по атрибутам, что для сложных систем может оказаться неприемлемым. Требования, которые мы назвали инфраструктурными, вошли в состав четырех семейств. Семейство FPT_AMT (тестирование базовой абстрактной машины ) определяет требования к тестированию, демонстрирующему правильность предположений, обеспечиваемых абстрактной машиной (аппаратно-программной платформой), лежащей в основе функций безопасности. Семейство FPT_RPL ( обнаружение повторного использования ) нацелено на выявление повторного использования сущностей различных типов (например, сообщений, запросов на обслуживание и ответов на запросы) и выполнение заданных ответных действий. Семейство FPT_SSP (протокол синхронизации состояний ) на самом деле содержит требования одностороннего или взаимного надежного подтверждения при обмене данными между функциями безопасности в распределенной среде. Наконец, семейство FPT_STM (метки времени) требует предоставления надежных меток времени в пределах объекта оценки. Подобные метки необходимы, например, функциям протоколирования и управления. жүктеу/скачать 0.51 Mb. Достарыңызбен бөлісу:
|