Опубликован: 03.09.2003 | Доступ: свободный | Студентов: 8700 / 2419 | Оценка: 4.21 / 3.93 | Длительность: 20:03:00
ISBN: 978-5-9556-0053-6
Лекция 7:

Профили защиты, разработанные на основе "Общих критериев". Часть 3. Частные требования к комбинациям и приложениям сервисов безопасности

< Лекция 6 || Лекция 7: 123456 || Лекция 8 >
Аннотация: Описываются предположения и цели безопасности, функциональные требования и требования доверия, специфичные для конкретных комбинаций и приложений сервисов безопасности. Наиболее подробно рассматриваются частные функциональные требования.
Ключевые слова: операционная система, объект, ПО, оранжевая книга, разделение доменов, целый, профиль защиты, класс безопасности, C2, дискреционное управление доступом, мандатное управление доступом, мандатное управление целостностью, криптографический сервис, чувствительность данных, угроза, классификация данных, домен, маскарад, связь, алгоритм ГОСТ 28147, имитовставка, генерация случайных чисел, защита остаточной информации, уничтожение ключей, криптографический модуль, доверенный маршрут, компонент, анализ скрытых каналов, скрытый канал, ссылка, криптография, шифрование, функции безопасности, FIPS, сетевые угрозы, квота, уровень детализации, общие критерии, функциональный пакет, функциональные требования, CSPP, экспорт данных пользователя, поддержка, система управления базами данных (СУБД), комбинация сервисов безопасности, аутентификационный пакет, базовая конфигурация, согласованность данных функций безопасности, распределенные транзакции, дублирование данных, протокол синхронизации, устойчивость к отказам, динамическая целостность, безопасное восстановление, туннелирование, криптографическая инфраструктура,, шлюз, экранирование, виртуальные частные сети, Internet, каналы коммуникаций, опорный узел, требования безопасности, доверенный канал, управление информационными потоками, потоки данных, имя пользователя, отказоустойчивость, безопасное состояние, виртуальные локальные сети, эталонная семиуровневая модель, локализация потоков данных, логическое разделение среды передачи, смарт-карта, неконтролируемая среда, программное обеспечение, предположения безопасности, доверенные коммуникации, логическая атака, клонирование, аудит, цели безопасности, интегральная схема, список регистрационных данных, систематический, поиск, модульность, интегратор, анализ, обнаружение повторного использования, очередь, методология разработки, цикла, опыт, деятельность, сопровождение, множества

Операционные системы

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

Для операционных систем разработан целый ряд профилей защиты (см. [ 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) критичных данных функций безопасности.

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

< Лекция 6 || Лекция 7: 123456 || Лекция 8 >
Роман Попов
Роман Попов

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

Марина Марченкова
Марина Марченкова
Александр Воротников
Александр Воротников
Россия, Черногорск