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

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

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

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

Содержание раздела