7. Лекция: Профили защиты, разработанные на основе "Общих критериев". Часть 3. Частные требования к комбинациям и приложениям сервисов безопасности Операционные системы
Операционные системы (ОС) - классический объект оценки по требованиям безопасности еще со времен "Оранжевой книги". Более того, до сих пор остается весьма распространенным мнение о том, что это важнейшее, едва ли не единственное защитное средство. С современных позиций ОС можно рассматривать как комбинацию сервисов идентификации и аутентификации, управления доступом и протоколирования/аудита. Кроме того, операционные системы обеспечивают базовые, инфраструктурные свойства безопасности, в том числе разделение доменов и посредничество при обращениях.
Для операционных систем разработан целый ряд профилей защиты (см. [72], [73], [83], [84], [3], [4]). К этой же группе документов можно отнести руководство по разработке профилей для перспективных коммерческих продуктов ИТ [82], поскольку оно, как и [73], [83], [84], [4]), ориентировано на класс безопасности C2 "Оранжевой книги".
Мы, однако, рассмотрим проект [3] (адаптированный вариант профиля [72]) , в целом соответствующий четвертому классу защищенности по классификации Гостехкомиссии России для средств вычислительной техники, поскольку он более представителен с точки зрения требований безопасности.
Операционные системы, удовлетворяющие проекту ПЗ, должны обеспечивать дискреционное и мандатное управление доступом, мандатное управление целостностью и предоставлять криптографические сервисы . Всем пользователям необходим ассоциированный уровень допуска, определяющий максимальный уровень чувствительности данных, к которым они могут обращаться (см. выше раздел "Требования к принудительному (мандатному) управлению доступом").
Вероятно, единственная специфическая угроза для рассматриваемого класса ОС заключается в неадекватной классификации данных на основе их меток, что способствует осуществлению несанкционированного доступа к (помеченным) данным. В качестве контрмеры провозглашается специфическая цель безопасности: "Операционная система должна предоставлять возможность расставлять точные метки чувствительности и целостности".
Еще одна очевидная цель состоит в том, что операционная система обязана поддерживать домен для своего собственного выполнения, это защитит ее и принадлежащие ей ресурсы от внешнего вмешательства, искажения или несанкционированного раскрытия.
Для борьбы с маскарадом сервера операционная система должна выделять средства, предотвращающие связь пользователя с некоторой сущностью, выдающей себя за операционную систему, но не являющейся таковой.
Из числа специфических функциональных требований наибольший интерес представляют криптографические компоненты. Остановимся на них подробнее:
генерация криптографических ключей (FCS_CKM.1). Симметричные криптографические ключи должны генерироваться в соответствии с согласованным с ФАПСИ алгоритмом, реализуемым аппаратным или программным генератором случайных чисел (см. далее компонент FCS_COP_EXP.2) и/или схемой генерации ключей, которая основана на криптографии с открытым ключом, использует программный и/или аппаратный генератор случайных чисел, определенный в FCS_COP_EXP.2, и хэш-функцию по ГОСТ Р 34.11-94. Асимметричные криптографические ключи должны генерироваться, согласуясь с параметрами криптографического преобразования, применяя генератор случайного числа и/или генератор простых чисел и удовлетворяя ГОСТ Р 34.10-2001 в части генерации простых чисел, ГОСТ Р 34.10-2001 для реализации процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма, ГОСТ 28147-89 для реализации процедур зашифрования и расшифрования данных, а также требованиям из этого проекта ПЗ: FPT_CTST_EXP, FCS_COP_EXP.2 и документации разработчика. Дополнительное требование упомянутого проекта ПЗ состоит в том, что к каждому сгенерированному симметричному ключу должна добавляться имитовставка алгоритма ГОСТ 28147-89 или контрольная сумма другого аттестованного алгоритма (FCS_CKM_EXP.1);
распределение криптографических ключей (FCS_CKM.2). Согласно проекту профиля [3], ключи должны распределяться (вручную или автоматически) в соответствии с требованиями ФАПСИ и действующих нормативных документов. Не предусматривается автоматическое распределение секретных ключей асимметричных криптосистем;
доступ к криптографическим ключам (FCS_CKM.3). Ключи должны храниться только в зашифрованном виде в соответствии с требованиями ФАПСИ и действующих нормативных документов (FCS_CKM.3.1). Дополнительное требование: информацию, позволяющую однозначно идентифицировать ключ (FCS_CKM_EXP.3.1), хранить нельзя;
уничтожение криптографических ключей (FCS_CKM.4). Криптографические ключи должны уничтожаться в соответствии с требованиями ФАПСИ и действующих нормативных документов. Удалять ключи и другие критичные параметры необходимо немедленно, полностью и таким образом, чтобы поверх ключа/критичной области памяти записывались три или более различных шаблонов (FCS_CKM.4.1);
криптографические операции (FCS_COP.1). Операции зашифрования/расшифрования данных должны выполняться в соответствии с алгоритмом криптографического преобразования по ГОСТ 28147-89 или другим аттестованным алгоритмом, а операции вычисления цифровой подписи - в соответствии с алгоритмом выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма по ГОСТ Р 34.10-2001 или другим аттестованным алгоритмом. Операции хэширования выполняются согласно определенному ГОСТ Р 34.11-94 или другому аттестованному алгоритму, операции обмена криптографическими ключами - в соответствии с требованиями ФАПСИ и действующих нормативных документов. (FCS_COP.1.1);
генерация случайных чисел (FCS_COP_EXP.2 - дополнительный компонент, предложенный в данном проекте ПЗ). Генерация случайных чисел должна выполняться множеством независимых аппаратных и/или программных датчиков, выходы которых объединяются с использованием хэш-функции по ГОСТ Р 34.11-94 или другого аттестованного алгоритма (FCS_COP_EXP.2.1). Датчики случайных/псевдослучайных чисел необходимо защитить от нарушения алгоритмов (режимов) их функционирования (FCS_COP_EXP.2.2);
защита остаточной информации криптографического ключа (FDP_RIP_EXP.2 - дополнительный компонент). Любой ресурс, содержащий критичные параметры безопасности, при освобождении этого ресурса должен быть очищен от всей информации путем перезаписи поверх его содержимого, как определено процедурой уничтожения ключа;
отделение домена функций безопасности (FPT_SEP_EXP.1 - дополнительный компонент). Поддерживается криптографический домен, отделенный от остальных функций безопасности, защищенный от вмешательства и искажения недоверенными субъектами (FPT_SEP_EXP.1.1);
тестирование криптографического модуля (FPT_CTST_EXP - дополнительное семейство). Для проверки правильности функционирования криптографического модуля необходимо реализовывать возможность его тестирования путем выполнения набора встроенных тестов при начальном запуске, по запросу администратора по криптографии и периодически (FPT_CTST_EXP.1.1). Тесты должны обеспечивать проверку и документирование статистических характеристик генераторов случайных/псевдослучайных чисел и отображение результатов тестирования (FPT_CTST_EXP.1.2). Предписывается выполнение тестов обнаружения ошибок в ключе при начальном запуске и по запросу администратора по криптографии (FPT_CTST_EXP.1.3), а также немедленное (сразу после генерации ключа) самотестирование каждого участвующего в генерации ключей компонента для верификации его функционирования в соответствии с FCS_CKM.1.1 и FCS_COP_EXP.2 (FPT_CTST_EXP.1.4). Сгенерированный ключ не должен использоваться, если самотестирование какого-либо компонента завершилось неудачей (FPT_CTST_EXP.1.5);
доверенный маршрут (FTP_TRP_EXP.1 - дополнительный компонент). Криптографический модуль должен обеспечивать маршрут связи между собой и локальными пользователями, который логически отличим от других маршрутов и предоставляет уверенную идентификацию самого себя (FTP_TRP_EXP.1.1).
Для обслуживания криптографических средств в рассматриваемом проекте ПЗ предусмотрен дополнительный компонент требований доверия безопасности:
анализ скрытых каналов криптографического модуля (AVA_CCA_EXP.1). Для криптографического модуля разработчику следует провести поиск скрытых каналов утечки критичных параметров безопасности (AVA_CCA_EXP.1.1D) и представить документацию анализа скрытых каналов (AVA_CCA_EXP.1.2D), которая идентифицирует скрытые каналы в криптографическом модуле и содержит оценку их пропускной способности (AVA_CCA_EXP.1.1C). Документация должна содержать описание процедур, используемых для заключения о существовании скрытых каналов в криптографическом модуле, и информацию, необходимую для проведения анализа скрытых каналов (AVA_CCA_EXP.1.2C). Кроме того, в ней описываются все предположения, сделанные в процессе анализа (AVA_CCA_EXP.1.3C), метод, применяемый для оценки пропускной способности канала в случае наиболее опасного сценария (AVA_CCA_EXP.1.4C), и сам наиболее опасный сценарий использования каждого идентифицированного скрытого канала (AVA_CCA_EXP.1.5C). Оценщик обязан подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств (AVA_CCA_EXP.1.1E), а результаты анализа скрытых каналов показывают, что криптографический модуль удовлетворяет функциональным требованиям (AVA_CCA_EXP.1.2E). Наконец, произведя тестирование, он выборочно подтверждает правильность результатов анализа скрытых каналов (AVA_CCA_EXP.1.3E).
Можно видеть, что в проекте профиля [3] вопросы криптографии изложены весьма пространно, однако смысл всех требований предельно прост: соответствие национальным стандартам (их три). Многократно упоминаемое соответствие требованиям ФАПСИ и действующих нормативных документов - условие туманное, допускающее неоднозначное толкование. (Заметим, что ссылка на требования определенного ведомства - вещь рискованная, так как последнее может прекратить свое существование.) Небесспорно и введение дополнительных, по сравнению с "Общими критериями", требований (функциональных и доверия).
Напомним, что в рассмотренном выше ПЗ для межсетевых экранов [43] криптография используется, помимо шифрования и контроля целостности, также и для аутентификации, однако ссылки на национальный стандарт и привлечения стандартных требований оказалось достаточно. Не ясно, почему следует особо оговаривать отделение криптографического домена или проведение анализа скрытых каналов криптографического модуля - другие функции безопасности не менее критичны и должны обладать не меньшей собственной защищенностью. Целесообразно выделить требования к криптографическим модулям в отдельный документ, как это сделано в федеральном стандарте США FIPS PUB 140-2 [44], а не перегружать ими профиль защиты ОС.
Далее, в рассматриваемом проекте ПЗ предусмотрена возможность удаленного администрирования, но отсутствует упоминание об аутентификации с использованием криптографических методов, а также о защите от подделки и/или воспроизведения аутентификационных данных (компоненты FIA_UAU.3 и FIA_UAU.4 "Общих критериев"). В результате остаются без противодействия стандартные сетевые угрозы.
Еще одна специфическая особенность ОС - возможность управления использованием ресурсов, их распределением между пользователями. Для этого уместно применить механизм квотирования.
максимальные квоты (FRU_RSA.1). Пользователям должны выделяться квоты долговременной и оперативной памяти, а также процессорного времени (FRU_RSA.1.1).
Рассмотренный проект профиля защиты для операционных систем показывает, как важно соблюдать определенный уровень формализации изложения, а также единый уровень детализации. Неоднородность ПЗ чревата несистематичностью, завышением или занижением требований. К сожалению, "Общие критерии" не регламентируют этот аспект разработки профилей защиты, заданий по безопасности и функциональных пакетов.
Отдельного рассмотрения заслуживают специфические функциональные требования, присутствующие в проекте [83]. Выше, в разделе "Системы активного аудита", мы отмечали важность требований к интерфейсам и их безопасности. В [83] предложен дополнительный элемент FAU_GEN.1-CSPP.3, предписывающий предоставление прикладного программного интерфейса для добавления собственных данных к общему регистрационному журналу и/или для ведения приложениями собственных журналов.
Для управления экспортом данных пользователя в соответствии с политикой безопасности введен элемент FDP_ETC.1-CSPP.3, предусматривающий выделение отдельного пула выходных каналов (например, путем резервирования номеров TCP-портов), недоступных обычным приложениям.
Поддержка распределенных конфигураций регламентируется целым рядом дополнительных требований, направленных на обеспечение конфиденциальности (FPT_ITC.1.1-CSPP), целостности (FPT_ITI.1.1-CSPP), согласованности (FPT_SYN-CSPP.1.1) критичных данных функций безопасности.
В заключение раздела следует отметить, что в Центре безопасности информации создан проект базового профиля защиты для ОС и разрабатывается профиль защиты ОС в средах, нуждающихся в высокой робастности (защищенности), с тем чтобы иметь завершенное семейство профилей защиты операционных систем.
Системы управления базами данных
Системы управления базами данных (СУБД), как и операционные системы, содержат комбинацию сервисов безопасности, однако, в отличие от ОС, не являются самодостаточными. СУБД используют механизмы и функции ОС. Такая двухуровневость ведет к появлению специфических угроз и требует привлечения соответствующих средств противодействия. Например, базы данных располагаются в файлах или на дисках, управляемых ОС; следовательно, к объектам БД можно обратиться как штатными средствами СУБД , так и с помощью механизмов ОС, получив доступ к файлу или устройству. Подобные возможности должны учитываться в профиле защиты для СУБД.
Дальнейшее изложение основано на проекте ПЗ [5] (его прототип [81] соответствует классу безопасности C2 "Оранжевой книги").
Здесь вводится понятие аутентификационного пакета, который предоставляет для СУБД механизм подтверждения подлинности заявляемого идентификатора пользователя. В рассматриваемом проекте профиля защиты для этого необходим хотя бы один из двух механизмов: внешний (аутентификация средствами ОС) или внутренний (аутентификация средствами СУБД).
Еще одно проявление упомянутой выше двухуровневости - предположение безопасности базовой конфигурации, состоящее в том, что базовая система (операционная система, и/или сетевые сервисы безопасности, и/или специальное программное обеспечение) установлены, сконфигурированы и управляются безопасным образом. Аналогичную направленность имеют цели безопасности для среды, предусматривающие, что базовая система должна обеспечить механизмы управления доступом, которые позволят защитить от несанкционированного доступа все связанные с СУБД файлы; кроме того, ОС предоставит средства для изоляции функций безопасности и защиты процессов СУБД.
Отметим, что в распределенной среде управление доступом и изоляция могут поддерживаться не только средствами базовой ОС, но и архитектурно, путем разнесения компонентов СУБД по узлам сети и использования межсетевых экранов. Эта возможность в проекте [5] не рассматривается.
Переходя к функциональным требованиям безопасности, укажем на важность требований согласованности данных между функциями безопасности (FPT_TDC), а также согласованности данных функций безопасности при дублировании в пределах распределенного объекта оценки (FPT_TRC). Согласованность достигается с помощью некоторой формы обработки распределенных транзакций или путем обновления дублируемых данных с применением какого-либо протокола синхронизации. К сожалению, требования этих семейств в проекте [5] не представлены, равно как и требования распределенности хранения и обработки для повышения устойчивости к отказам. Конечно, в "Оранжевой книге" ничего подобного не было, однако в наше время, как показывает профиль [48], следование определенным архитектурным принципам является обязательным.
Для защиты от атак на доступность в рассматриваемом проекте предусмотрены реализация квот, выделяемых пользователям (FRU_RSA.1), а также базовые ограничения на параллельные сеансы (FTA_MCS.1).
В целом, на наш взгляд, проект [5] нуждается в доработке. Необходимо учесть специфику современных СУБД, в частности, требования обеспечения динамической целостности данных, реализуемые механизмом транзакций. Требования безопасного восстановления носят слишком общий характер. Защита от стандартных угроз, существующих в сетевой среде, целиком переложена на базовую систему. Не учтены специфические для СУБД угрозы, описанные, например, в главе "Информационная безопасность систем управления базами данных" книги [86].
Виртуальные частные сети
Туннелирование и шифрование (наряду с необходимой криптографической инфраструктурой) на выделенных шлюзах в комбинации с экранированием на маршрутизаторах поставщиков сетевых услуг (для разделения пространств "своих" и "чужих" сетевых адресов в духе виртуальных локальных сетей) позволяют реализовать такое важное в нынешних условиях защитное средство, как виртуальные частные сети. Подобные сети, наложенные обычно поверх Internet, существенно дешевле и гораздо безопаснее, чем действительно собственные сети организации, построенные на выделенных каналах. Коммуникации на всем их протяжении физически защитить невозможно, поэтому лучше изначально исходить из предположения об уязвимости и соответствующим образом обеспечивать защиту. Современные протоколы, поддерживающие спецификации IPsec (см., например, [9]), позволяют сделать это.
На концах туннелей, реализующих виртуальные частные сети, целесообразно установить межсетевые экраны, обслуживающие подключение организаций к внешним сетям. В таком случае туннелирование и шифрование становятся дополнительными преобразованиями, выполняемыми в процессе фильтрации потоков данных наряду с трансляцией адресов. Помимо корпоративных межсетевых экранов, в роли конечных устройств могут выступать мобильные компьютеры сотрудников (точнее, их персональные МЭ). Далее соответствующие узлы сети мы будем называть опорными.
В качестве основы последующего изложения выбран проект профиля защиты [26], где объект оценки - совокупность опорных узлов. Требования к перспективным средствам аналогичного назначения представлены в документе [79].
Поскольку реализация виртуальных частных сетей в значительной степени основывается на криптографических механизмах, в число специфических угроз входят применение злоумышленником методов и средств криптографического анализа, а также компрометация криптографических ключей. Упомянем и угрозы доступности каналов связи.
Для нейтрализации угроз должны быть выполнены функциональные требования безопасности, относящиеся к криптографии. Необходимо осуществление контроля доступа к криптографическим ключам (FCS_CKM.3.1), шифрование (FCS_COP.1.1) и применение механизмов контроля целостности (FCS_COP.1.1) информации, передаваемой в рамках доверенного канала.
В виртуальной частной сети управление информационными потоками ограничивается (FDP_IFC.1.1). Вообще говоря, через опорные узлы проходят не только потоки данных, предназначенные для виртуальной частной сети, но и данные для внешних адресатов. Эти потоки должны различаться и обрабатываться по-разному (например, первые необходимо шифровать, а вторые - нет). По сути, должно быть реализовано межсетевое экранирование, только одна из сетей является виртуальной.
От виртуальных частных сетей требуется реализация некоторых аспектов приватности. Они не должны допустить, чтобы извне можно было определить подлинное имя пользователя, связанного с передаваемой в рамках доверенного канала информацией (FPR_ANO.1.1). В то же время, администратору необходимо предоставить возможность наблюдения за использованием ресурсов и функционированием процессов (FPR_UNO.4.1).
Опорные узлы должны обладать определенной отказоустойчивостью, обеспечивая возврат к безопасному состоянию, генерацию записи журнала аудита, сигнализацию администратору, когда происходит сбой в системе электропитания или нарушение безопасности (FRU_FLT.1.1).
Таковы специфические функциональные требования безопасности для виртуальных частных сетей. В "Общих критериях" в явном виде не представлены требования к туннелированию; нет их и в рассмотренном проекте. Возможно, туннелирование трактуется лишь как механизм обеспечения анонимности.
Виртуальные локальные сети
Под виртуальной локальной сетью в проекте профиля защиты [25] понимается такое логическое объединение узлов локальной сети, при котором обмен данными на канальном уровне эталонной семиуровневой модели возможен только между этими узлами.
Использование виртуальных локальных сетей позволяет:
повысить производительность (и доступность) сети за счет локализации потоков данных;
обеспечить защиту передаваемых данных посредством логического разделения среды передачи;
реализовать управление доступом пользователей к сетевым ресурсам.
Разграничение потоков данных обеспечивается путем фильтрации кадров данных. Таким образом, объект оценки оказывается межсетевым экраном канального уровня.
В проекте [25] рассматриваются два способа построения виртуальных локальных сетей:
группировка портов объекта оценки. В этом случае каждый порт поддерживает только одну виртуальную сеть;
использование специальной метрики для определения принадлежности к конкретной виртуальной локальной сети.
Впрочем, предлагаемые в проекте требования безопасности в равной степени применимы к обоим вариантам.
От рассмотренных ранее межсетевых экранов объект оценки отличается ограниченностью ресурсов и меньшей функциональностью. В частности, вся работа с регистрационной информацией (начиная с хранения) возлагается на среду, точнее, на так называемое средство анализа событий. Это освобождает объект оценки от ряда стандартных требований протоколирования и аудита, но ведет к необходимости организации доверенного канала.
Смарт-карты
Профиль защиты для смарт-карт [80] интересен необычностью объекта оценки. Он позволяет оценить гибкость и разнообразие требований "Общих критериев".
Эта необычность заключается в следующем:
минимум аппаратных ресурсов (интегральная схема, включающая процессор; оперативная и постоянная память относительно небольшого объема; порты ввода/вывода) в сочетании с программным обеспечением ограниченной функциональности (в профиле [80] рассматривается базовое ПО);
принадлежность неконтролируемой среде, когда карта может оказаться в руках злоумышленника, располагающего специальным оборудованием.
В защите (обеспечении конфиденциальности и целостности) нуждаются хранящиеся на карте пользовательские данные, программное обеспечение (прикладное и базовое), а также аппаратные компоненты.
Отметим, что приемное устройство, снабжающее смарт-карту электропитанием и связью с внешним миром, не входит в объект оценки.
Учитывая ограниченность ресурсов и потенциально враждебную среду, сервисы безопасности для смарт-карт должны быть отобраны и реализованы с особой тщательностью.
Сформулируем предположения безопасности для среды:
после установления доверенного канала с приемным устройством последнее предполагается достаточно безопасным, чтобы поддерживать доверенные коммуникации;
предполагается, что обеспечена конфиденциальность и целостность информации, хранящейся вне карты и существенной для ее безопасности. Имеются в виду как пользовательские данные, так и криптографические ключи, загружаемые приложения и т.п.
С большинством возможных угроз смарт-карта должна справляться самостоятельно, без помощи среды. Выделим специфические (а также специфически реализуемые и отражаемые) угрозы:
осуществление доступа к смарт-карте с помощью специального оборудования, когда преследуется цель выяснить определенные аппаратные и/или программные характеристики (применяемые криптографические механизмы, используемые ключи, хранимые данные и программы и т.п.). Не исключены попытки изменить аппаратно-программную конфигурацию и/или данные, а также перевести смарт-карту в небезопасное состояние, поместив ее в стрессовые условия (например, температурные или электромагнитные);
логические атаки: отслеживание зависимостей между входными данными операций, выполняемых смарт-картой, и результатами; попытки перевести карту в небезопасное состояние искусственно инициированным сбросом или загрузить вредоносные программы; использование некорректных входных данных; воспроизведение данных аутентификации; переборные атаки (на криптографические компоненты). К этой же категории угроз можно отнести попытки организовать нештатное взаимодействие прикладных функций и выполнить действия (например, отладочные), предусмотренные для особых этапов жизненного цикла смарт-карты. Одновременное проведение нескольких атак;
несанкционированный доступ: попытки злоупотребления полномочиями при доступе к пользовательским данным или данным функций безопасности, а также использования новой, не до конца оформленной смарт-карты;
попытки выявления и анализа утечек информации во время нормальной работы смарт-карты, совместный анализ результатов многих наблюдений.
попытки изготовления копий (клонирование) компонентов смарт-карты для детального изучения их поведения.
Специфической угрозой для среды является замена интегральной схемы, установленной в смарт-карте, с целью несанкционированного доступа к данным пользователя или функций безопасности.
Из специфических положений политики безопасности прежде всего отметим наличие уникальных идентификационных данных для каждого объекта оценки, а также (как ни странно) накопление регистрационной информации, которое необходимо производить, несмотря на ограниченность ресурсов. Аудит может выполняться во время сервисного обслуживания смарт-карты.
Цели безопасности формулируются таким образом, чтобы обеспечить нейтрализацию угроз и выполнить положения политики безопасности: интегральная схема должна работать в любых, в том числе стрессовых, условиях; осуществляется защита от многократного использования ресурсов при переборных атаках; изучение передаваемых данных не должно давать дополнительной информации по сравнению с анализом содержимого памяти; нормальное (безопасное) состояние устанавливается сразу после подачи питания или сброса; при замене интегральной схемы на карте обязательно должны оставаться следы и т.п.
Перейдем к рассмотрению специфических функциональных требований:
автоматическая реакция аудита безопасности (FAU_ARP) при обнаружении возможного нарушения безопасности. Предписываются минимальные необратимые последствия реакции. Подчеркнем, что в силу специфики объекта оценки оперативное информирование администратора безопасности в общем случае невозможно; с опасностью приходится бороться самостоятельно;
генерация списка регистрационных данных (FAU_LST - дополнительное семейство). На интегральной схеме, устанавливаемой в смарт-карте, нет часов; время указывает только приемное устройство, которое не считается доверенным. Следовательно, события можно лишь упорядочить по мере их появления, но с ними нельзя ассоциировать дату и время. В регистрационную информацию должны включаться идентификационные данные аппаратных и программных компонентов;
противодействие физическому нападению (FPT_PHP.3). Функции безопасности обязаны противодействовать попыткам эксплуатации в стрессовых условиях, отслеживанию информации, другим физическим атакам, автоматически реагируя таким образом, чтобы предотвратить нарушение политики безопасности (FPT_PHP.3.1);
надежное восстановление (FPT_RCV). Автоматическое восстановление без недопустимой потери (FPT_RCV.3), восстановление функции (FPT_RCV.4).
Для требований доверия безопасности в [80] используется усиленный оценочный уровень 4. Усиление обеспечивают компоненты AVA_VLA.3 (систематический поиск уязвимостей, обеспечение стойкости к нападениям, выполняемым нарушителем с умеренным потенциалом) и ADV_INT.1 (модульность).
Важным достоинством работы [80] является выделение двух функциональных пакетов: для интегральной схемы и базового ПО. Эти части могут разрабатываться независимыми производителями, поэтому целесообразно, чтобы они проводили такую же независимую сертификацию, а интегратор (производитель смарт-карт) выбирал поставщиков и осуществлял интегральную сертификацию. В части функциональных требований пакет для базового ПО аналогичен рассмотренному профилю; к аппаратуре предъявляется меньшее число требований. Например, в функциональном пакете для интегральной схемы отсутствуют компоненты FAU_SAA.1 (анализ потенциального нарушения) и FPT_RPL.1 (обнаружение повторного использования), что представляется вполне естественным.
Некоторые выводы
"Общие критерии" - исключительно мощное, гибкое средство разработки требований безопасности для изделий информационных технологий. В частности, могут быть выделены общие требования к сервисам безопасности, а также учтена специфика конкретных сервисов, фигурирующих по отдельности или в различных комбинациях.
В то же время, сама гибкость "Общих критериев" - источник сложных проблем, в первую очередь относящихся к методологии разработки профилей защиты. Можно провести аналогию с языками и технологией программирования, когда владение передовым языком программирования вовсе не означает умения проектировать и создавать большие программные комплексы.
Вопросы технологии "программирования" профилей защиты носят разнообразный характер и затрагивают все этапы жизненного цикла ПЗ. Какой подход выбрать при разработке ПЗ: "снизу вверх" или "сверху вниз"? Сами "Общие критерии", имеющие библиотечную (не объектную) структуру, подталкивают к применению подхода "снизу вверх", от отдельных требований к общей функциональности. Однако, как показывает опыт разработчиков профиля [48] (равно как и технология программирования), наиболее предпочтителен подход "сверху вниз", от требуемой функциональности объекта оценки к базовым механизмам безопасности.
Еще один технологический аспект - модульность ПЗ. Выделение функциональных пакетов для составных частей объекта оценки, реализованное в [80], дает больше свободы и разработчикам, и интеграторам, способствует раннему выявлению и устранению проблем, облегчает деятельность оценщиков.
Следующий вопрос касается технологии сопровождения множества профилей защиты. Как соотносить между собой отдельные ПЗ? Как группировать их, выстраивать иерархии и т.п.? Пока зарегистрированных профилей относительно немного (что само по себе является проблемой, но, можно надеяться, временной), и все-таки очевидно, что их число будет расти, они станут поступать из различных источников, из разных стран, так что поддержание международного статуса "Общих критериев", несомненно, потребует специальных усилий, которые целесообразно планировать заранее (см. соглашение "О признании сертификатов по Общим критериям в области безопасности информационных технологий").
Очень серьезная проблема - неполнота функциональных требований "Общих критериев". Как показывают рассмотренные профили, авторам ПЗ приходится добавлять собственные нестандартные классы, семейства, компоненты и элементы, что ведет к несопоставимости разрабатываемых профилей, к усложнению процедур сертификации и взаимного признания сертификатов.
Принципиальный недостаток - отсутствие в "Общих критериях" архитектурных и технологических требований. Такие свойства, как распределенность архитектуры, следование подходу менеджер/агент и т.п., необходимы для успешной реализации функций объекта оценки, они критичны для его безопасности.
Таким образом, проведенный анализ позволяет наметить следующие направления дальнейших исследований и разработок:
создание новых профилей защиты, охватывающих все сервисы безопасности;
разработка методологии и соответствующих инструментальных средств создания ПЗ;
разработка дисциплины и инструментальных средств для использования множества профилей защиты;
развитие "Общих критериев", разработка новых стандартных требований безопасности, как "точечных", так и концептуальных, архитектурных;
разработка дисциплины введения новых нестандартных требований с минимизацией проблем несопоставимости получающихся профилей защиты.
Для решения сформулированных проблем необходимо взаимодействие специалистов, независимо от их национальной и, тем более, ведомственной принадлежности.
|
