История создания и текущий статус "Общих критериев"
В 1990 году Рабочая группа 3 Подкомитета 27 Первого совместного технического комитета (JTC1/SC27/WG3) Международной организации по стандартизации (ISO) приступила к разработке "Критериев оценки безопасности информационных технологий" (Evaluation Criteria for IT Security, ECITS). Несколько позже, в 1993 году, правительственные организации шести североамериканских и европейских стран - Канады, США, Великобритании, Германии, Нидерландов и Франции - занялись составлением так называемых "Общих критериев оценки безопасности информационных технологий" (Common Criteria for IT Security Evaluation). За этим документом исторически закрепилось более короткое название - "Общие критерии", или ОК (Common Criteria, CC).
Рабочая группа ISO, возглавляемая представителем Швеции, функционировала на общественных началах и действовала весьма неторопливо, пытаясь собрать и увязать между собой мнения экспертов примерно из двух десятков стран, в то время как коллектив "Проекта ОК", финансируемый своими правительствами, несмотря на первоначальное трехлетнее отставание, весьма быстро начал выдавать реальные результаты. Объяснить это нетрудно: в "Проекте ОК" требовалось объединить и развить всего три весьма продвинутых и близких по духу документа - "Гармонизированные критерии Европейских стран", а также "Канадские критерии оценки доверенных компьютерных продуктов" и "Федеральные критерии безопасности информационных технологий" (США). (Сами разработчики "Общих критериев" относят к числу первоисточников еще и "Оранжевую книгу".)
Как правило, круг людей, заседающих в комитетах и комиссиях по информационной безопасности, довольно узок, поэтому нет ничего удивительного в том, что одни и те же представители стран (в частности, США и Великобритании) входили в обе группы разработчиков. Естественно, в таких условиях между коллективом "Проекта ОК" и Рабочей группой 3 установилось тесное взаимодействие.
Практически это означало, что группа WG3 стала бесплатным приложением к "Проекту ОК", а сами "Общие критерии" автоматически должны были получить статус не межгосударственного, а международного стандарта.
В ОС Unix есть утилита tee, создающая ответвления каналов путем копирования стандартного вывода в файлы и довольно точно моделирующая взаимоотношения между коллективом "Проекта ОК" и группой WG3. С 1994 года ранние версии ОК становятся рабочими проектами WG3. В 1996 году появилась версия 1.0 "Общих критериев", которая, помимо публикации в Internet для всеобщего свободного доступа, была одобрена ISO и обнародована в качестве Проекта Комитета.
Широкое открытое обсуждение документа и "опытная эксплуатация" привели к его существенной переработке и выходу версии 2.0 ОК в мае 1998 года. Разумеется, эксперты WG3 не могли ее не отредактировать. Их замечания были учтены в версии 2.1 ОК 34-[36], принятой в августе 1999 года. Соответствующий международный стандарт ISO/IEC 15408-1999 53-[55] введен в действие с 1 декабря 1999 года. Таким образом, фактически стандарт ISO/IEC 15408-1999 и версия 2.1 ОК совпадают, а если пренебречь описываемыми ниже нюансами, их названия могут считаться взаимозаменяемыми. Однако, строго говоря, "Критерии оценки безопасности информационных технологий" и "Общие критерии оценки безопасности информационных технологий" - разные документы, поскольку выпущены под эгидой разных организаций, руководствующихся разными правилами распространения и обновления.
ISO не предоставляет свободный доступ к своим стандартам, они относительно статичны, поскольку их обновляют или подтверждают один раз в пять лет (какие-либо изменения в стандарте ISO/IEC 15408 можно ожидать в 2004 году). Напротив, портал "Проекта ОК" (http://www.commoncriteria.org) открыт для всех желающих, а разработчики "Общих критериев" постоянно предлагают и принимают изменения, уточнения, интерпретации отдельных положений и готовят третью версию своего документа.
Поэтому, с формальной точки зрения, международный стандарт ISO/IEC 15408-1999 по-русски правильнее сокращенно именовать КОБИТ, а не ОК. (Правда, велика вероятность, что рабочая группа ISO любезно согласится и дальше пользоваться плодами "Проекта ОК", естественно, внося в них свои редакторские правки...)
Уточним, что далее, в рамках этой темы, мы будем иметь в виду именно "Общие критерии", а не стандарт ISO.
С целью унификации процедуры сертификации по "Общим критериям" в августе 1999 года была опубликована "Общая методология оценки безопасности информационных технологий" (Common Methodology for Information Technology Security Evaluation) [37], описывающая минимальный набор действий при проведении оценки. "Проект ОК" с самого начала носил не только технический, но и экономико-политический характер. Его цель состояла, в частности, в том, чтобы упростить, удешевить и ускорить выход сертифицированных изделий информационных технологий (ИТ) на мировой рынок. Для этого в мае 2000 года уполномоченные правительственные организации шести стран-основателей "Проекта ОК", а также Австралии и Новой Зеландии, Греции, Италии, Испании, Норвегии, Финляндии и Швеции подписали соглашение "О признании сертификатов по Общим критериям в области безопасности информационных технологий" (позднее к нему присоединились Австрия и Израиль).
Участие в соглашении предполагает соблюдение двух независимых условий: признание сертификатов, выданных соответствующими органами других стран-участниц, а также возможность осуществления подобной сертификации. Очевидно, от взаимного признания сертификатов выигрывают не только производители, но и потребители изделий ИТ. Что же касается их выдачи, то соглашение предусматривает жесткий контроль при получении и подтверждении этого права (например, предусмотрено проведение так называемых теневых сертификационных испытаний под контролем независимых экспертов). Таким образом, для полноценного участия в соглашении, помимо желания, государство должно располагать органами сертификации с достаточными ресурсами и штатом специалистов, квалификация которых получила официальное международное признание.
По данным на конец 2002 года, правом выдачи сертификатов, признаваемых участниками соглашения, обладали Австралия и Новая Зеландия, Великобритания, Германия, Канада, США и Франция.
К началу 2003 года сертификаты по "Общим критериям" получили около семидесяти разнообразных изделий ИТ ведущих производителей: операционные системы, системы управления базами данных, межсетевые экраны, коммуникационные средства, интеллектуальные карты и т.п.; еще почти сорок находились в процессе сертификации.
Определяя статус "Общих критериев" в России, следует отметить, что отечественные специалисты с самого начала внимательно следили за этим проектом, публиковали аналитические обзоры и переводы (см., например, [JI981K]). В 1999 году была организована работа по подготовке российского стандарта и Руководящего документа (РД) Гостехкомиссии России на основе аутентичного перевода ОК. Она велась в тесном контакте с зарубежными коллегами и успешно завершена в 2002 году. Именно тогда был официально издан ГОСТ Р ИСО/МЭК 15408-2002 "Критерии оценки безопасности информационных технологий" 10-[12] с датой введения в действие 1 января 2004 года. А пока положение регулируется РД Гостехкомиссии России [19], который, как и "Общие критерии", по замыслу разработчиков, должен быть динамичнее стандарта, модифицируясь вместе с ОК.
Российские специалисты - активные участники "Проекта ОК", они вносят предложения по доработке "Общих критериев", выступают с докладами на конференциях, ведут научно-исследовательские работы, внедряют ОК в практику различных организаций. Следующим логичным шагом стало бы присоединение России к соглашению "О признании сертификатов".
Основные понятия и идеи "Общей методологии оценки безопасности информационных технологий"
"Общая методология оценки безопасности информационных технологий" - второй по важности документ (после "Общих критериев"), подготовленный в рамках "Проекта ОК". Основная цель "Общей методологии" - добиться объективности, повторяемости и воспроизводимости результатов оценки.
Следуя принципам структурной декомпозиции, разработчики выделили в процессе оценки три задачи (этапа):
входная задача;
задача оценки;
выходная задача.
Входная задача имеет дело с представленными для оценки свидетельствами (далее для краткости мы будем именовать их свидетельствами оценки). Ее назначение - убедиться, что версии свидетельств корректны и должным образом защищены.
Обычно для оценки представляются стабильные, официально выпущенные версии свидетельств, однако в ситуациях, когда оценка ведется параллельно разработке или доработке ОО, возможно предъявление рабочих версий. Оценщику вместе со спонсором этого процесса необходимо составить каталог и в дальнейшем производить конфигурационный контроль версий. Он обязан обеспечить защиту свидетельств от изменения и утери, а по окончании процесса оценки возвратить их, поместить в архив или уничтожить.
На всех этапах оценки должна обеспечиваться конфиденциальность.
Задача оценки в общем случае разбивается на следующие подзадачи:
оценка задания по безопасности; оценка управления конфигурацией ОО;оценка документации по передаче ОО потребителю и эксплуатационной документации; оценка документации разработчиков; оценка руководств;оценка поддержки жизненного цикла ОО; оценка тестов;тестирование;оценка анализа уязвимостей.
Нередко проводятся выборочные проверки, когда вместо всего (относительно однородного) множества свидетельств анализируется представительное подмножество, что позволяет сэкономить ресурсы при сохранении необходимого уровня доверия безопасности. Размер выборки должен быть обоснован математически и экономически, но при анализе реализации объекта оценки он должен составлять не менее 20%.
Ошибки, обнаруженные при выборочной проверке, подразделяются на систематические и случайные.
После исправления систематической ошибки необходимо произвести новую выборку; после случайной этого не требуется.
Допускается выборочная проверка доказательств, тестов, результатов анализа скрытых каналов, выполнения требований к содержанию и представлению свидетельств, выборочное тестирование.
В остальных ситуациях такой способ можно применять только в исключительных случаях, когда полная проверка требует слишком много ресурсов по сравнению с другими действиями в процессе оценки или когда она не существенно увеличивает доверие безопасности. При этом необходимо обосновать допустимость и целесообразность выборочного подхода.
В "Общей методологии" специально подчеркивается, что сами по себе большие размеры и высокая сложность объекта оценки не оправдывают замены полных проверок выборочными, поскольку для оценки безопасности подобных объектов заведомо требуется много сил и средств.
Необходимый элемент оценки - проверка внутренней согласованности каждого из представленных свидетельств, а также внешней взаимной согласованности различных свидетельств.
Внутренняя согласованность проверяется в первую очередь для сущностей, имеющих несколько представлений: для спецификаций и проектов всех уровней, а также для руководств.
Проверка внешней согласованности производится для описаний функций, параметров безопасности, процедур и событий, связанных с безопасностью, поскольку эти описания могут содержаться в разных документах.
Внутренняя несогласованность высокоуровневых сущностей может иметь глобальные последствия для процесса оценки. Например, выявление противоречий в целях заставляет заново проанализировать требования и функции безопасности.
Разные подзадачи в процессе оценки могут выполняться в произвольном порядке или параллельно, однако существуют зависимости, накладывающие некоторые ограничения на очередность выполнения. Наиболее очевидное из них состоит в том, что анализ задания по безопасности должен выполняться до каких бы то ни было проверок объекта оценки.
Задание по безопасности среди других характеристик объекта оценки определяет его границы и спектр рассматриваемых угроз.
Следовательно, процесс и результат оценки одного и того же продукта в сочетании с разными заданиями могут быть разными. Например, если в нем содержатся средства межсетевого экранирования и поддержки виртуальных частных сетей (ВЧС), но в задании по безопасности предусмотрена исключительно защита внутренней сети от внешних угроз, то свойства ВЧС-функций важны лишь в контексте возможности обхода средств экранирования. Даже если ВЧС-функции не обеспечивают конфиденциальности сетевых потоков данных, продукт с таким заданием получит положительную оценку.
(Заметим, что набор проверяемых требований необходим при сертификации не только по "Общим критериям". Нередко производитель в рекламных целях ограничивается кратким "продукт сертифицирован", что, по сути, бессодержательно и может ввести в заблуждение потребителя, так как зачастую означает соответствие каким-либо условиям общего характера, вроде отсутствия недекларированных возможностей.)
Важным моментом, обычно вызывающим много вопросов, является анализ уязвимостей и стойкости функций безопасности.
Цель обоих видов проверки заключается в выявлении степени устойчивости объекта оценки по отношению к атакам, выполняемым нарушителем с определенным (низким, умеренным или высоким) потенциалом нападения.
Анализ уязвимостей применяется ко всем функциям безопасности; при этом не делается каких-либо предположений относительно корректности их реализации, сохранения целостности, возможности обхода и т.п.
Анализу стойкости подвергаются только функции безопасности, реализованные с помощью вероятностных или перестановочных механизмов, у которых и проверяется стойкость - базовая, средняя или высокая (базовая означает защищенность от нарушителя с низким потенциалом нападения). В принципе, все вероятностные функции можно считать уязвимыми, а подобный анализ классифицировать как анализ уязвимостей специального вида.
Для успешного нападения необходимо сначала идентифицировать, а затем использовать некоторую уязвимость. Оба действия оцениваются с точки зрения временных затрат, необходимой квалификации, уровня знаний об ОО, характера и продолжительности доступа к ОО, необходимых аппаратно-программных и иных ресурсов.
Перечисленные составляющие не являются независимыми. Высокая квалификация может сэкономить время, а специальное оборудование - упростить и ускорить доступ к ОО. Следовательно, если оценивать каждый параметр количественно, то результирующую функцию, характеризующую серьезность уязвимости, естественно сделать аддитивной.
В таблицах 2.1 - 2.5 содержатся условные баллы, присваиваемые параметрам уязвимости в зависимости от того, в какой диапазон или на какой уровень они попадают. Для получения общего рейтинга нужно выбрать по одному значению из обоих числовых столбцов всех таблиц и сложить эти десять чисел. При оценке стойкости функций безопасности фаза идентификации не рассматривается (предполагается, что уязвимость известна), поэтому достаточно выбрать и сложить пять чисел из последних столбцов.
| < 0.5 часа | 0 | 0 |
| < суток | 2 | 3 |
| < месяца | 3 | 5 |
| > месяца | 5 | 8 |
| Любитель | 0 | 0 |
| Специалист | 2 | 2 |
| Эксперт | 5 | 4 |
| Отсутствие знаний | 0 | 0 |
| Общедоступные знания | 2 | 2 |
| Конфиденциальные сведения | 5 | 4 |
| < 0.5 часа или доступ незаметен | 0 | 0 |
| < суток | 2 | 4 |
| < месяца | 3 | 6 |
| > месяца | 4 | 9 |
| Отсутствие оборудования | 0 | 0 |
| Стандартное оборудование | 1 | 2 |
| Специальное оборудование | 3 | 4 |
| Заказное оборудование | 5 | 6 |
Если уязвимость можно идентифицировать и/ или использовать несколькими способами, для каждого из них вычисляется рейтинг и из полученных значений выбирается минимальное, то есть уязвимость характеризуется самым простым методом успешного нападения.
В табл. 2.6 приведены диапазоны рейтинга, которые характеризуют стойкость функции безопасности.
| 10 - 17 | Базовая |
| 18 - 24 | Средняя |
| > 24 | Высокая |
В табл. 2.7 приведены диапазоны рейтинга, иллюстрирующие определенный потенциал нападения.
| < 10 | Низкий |
| 10 - 17 | Умеренный |
| 18 - 24 | Высокий |
| > 24 | Нереально высокий |
Отметим, что потенциал предполагаемых нападений на ОО выявляется дважды: при анализе задания по безопасности для выбора надлежащих мер противодействия и при анализе уязвимостей для определения достаточности выбранных мер и качества их реализации.
Рассмотрим пример анализа стойкости функции безопасности. Пусть доступ к информационной системе осуществляется посредством территориально разнесенных терминалов, работа за которыми не контролируется. Авторизованные пользователи проходят аутентификацию путем введения паролей, состоящих из четырех различных цифр. Если пароль введен неверно, терминал блокируется на одну минуту. Требуется оценить стойкость такой парольной защиты для заданного пользователя с известным нападающему входным именем. Для нападения выбран один терминал, временем ввода можно пренебречь.
Очевидно, число возможных парольных последовательностей составляет
10*9*8*7 = 5040
Для успешного подбора пароля методом полного перебора требуется примерно 2520 попыток, которые можно произвести за 42 часа, что больше суток, но меньше месяца. Никакой квалификации, знаний и/или оборудования для этого не нужно. Следовательно, чтобы определить стойкость функции, достаточно сложить два числа: 5 из табл. 2.1 и 6 из табл. 2.4. Сумма 11 позволяет сделать вывод, что данная функция безопасности обладает базовой стойкостью и является устойчивой к нападению с низким потенциалом.
Возвращаясь к трем основным задачам процесса оценки, рассмотрим последнюю, выходную задачу. Ее цель - сформулировать замечания и получить технический отчет оценки.
Текст с замечаниями не является обязательным. Он нужен, если в процессе оценки выявились какие-либо неясности или проблемы.
Технический отчет оценки - это главный выходной документ, от качества которого во многом зависит повторяемость и воспроизводимость результатов оценки, т. е. возможность их многократного использования. "Общая методология" предписывает следующую структуру подобных отчетов:
введение; архитектурное (высокоуровневое) описание объекта оценки с рассмотрением основных компонентов;описание процесса оценки, примененных методов, методологий, инструментальных средств и стандартов; представление результатов оценки; выводы и рекомендации;список представленных свидетельств; список сокращений, словарь терминов;список замечаний.
Изучение "Общей методологии" полезно не только оценщикам, но и разработчикам, так как дает представление о вопросах, которые могут возникать в процессе оценки. К сожалению, более детальное рассмотрение этого документа выходит за рамки настоящего курса.
Основные понятия и идеи "Общих критериев"
Основным свойством, которым должны обладать действительно общие критерии оценки безопасности информационных технологий, является универсальность. Следовательно, они не должны содержать априорных предположений об объекте оценки. В ОК данное условие выполнено: под объектом оценки (ОО) понимается аппаратно-программный продукт или информационная система с соответствующей документацией.
Система - это специфическое воплощение информационных технологий с конкретным назначением и условиями эксплуатации.
Продукт, согласно ОК, есть совокупность средств ИТ, предоставляющая определенные функциональные возможности и предназначенная для непосредственного использования или включения в различные системы. В качестве собирательного термина для систем и продуктов применяют словосочетание "изделие ИТ". Оно может быть как уже существующим, так и проектируемым. В первом случае - доработано по результатам оценки, во втором - сама перспектива подобного контроля способна дисциплинировать разработчиков; так или иначе проведение оценки должно оказать положительное влияние на безопасность ОО.
Объект оценки рассматривается в определенном контексте - среде безопасности, в которую включаются все, что имеет отношение к его безопасности, а именно:
законодательная среда - законы и нормативные акты, затрагивающие ОО; административная среда - положения политик и программ безопасности, учитывающие особенности ОО;процедурная среда - физическая среда ОО и меры физической защиты, персонал и его свойства (знания, опыт и т.п.), принятые эксплуатационные и иные процедуры;программно-техническая среда - предназначение объекта оценки и предполагаемые области его применения, активы (ресурсы), которые требуют защиты средствами ОО.
Дальнейший этап технологического цикла подготовки к оценке, согласно "Общим критериям", - описание следующих аспектов среды ОО:
предположения безопасности. Они выделяют объект оценки из общего контекста, задают границы рассмотрения. Истинность этих предположений принимается без доказательства, а из множества возможных отбирается только то, что заведомо необходимо для обеспечения безопасности ОО;
Семейства в пределах класса различаются по строгости и другим характеристикам требований.
Компонент - минимальный набор требований, фигурирующий как целое.
Элемент - неделимое требование.
Между компонентами могут существовать зависимости. Они возникают, когда компонент сам по себе недостаточен для достижения цели безопасности. Соответственно, при включении такого компонента необходимо добавить всю "гроздь" его зависимостей.
"Общие критерии" содержат два основных вида требований безопасности:
функциональные, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности ОО и реализующим их механизмам;
требования доверия, которые соответствуют пассивному аспекту, предъявляются к технологии и процессу разработки и эксплуатации ОО.
Библиотека функциональных требований составляет вторую часть "Общих критериев", а каталог требований доверия - третью (первая часть содержит изложение основных концепций ОК).
Сформулировав функциональные требования, требования доверия и требования к среде, можно приступать к оценке безопасности готового изделия ИТ. Для типовых изделий "Общие критерии" предусматривают разработку типовых совокупностей требований безопасности, называемых профилями защиты (ПЗ).
Для проектируемого изделия за выработкой требований следует разработка краткой спецификации, входящей в задание по безопасности (ЗБ).
(Как вспомогательный элемент, упрощающий создание профилей защиты и заданий по безопасности, могут применяться функциональные пакеты (ФП) - неоднократно используемые совокупности компонентов, объединенных для достижения установленных целей безопасности.)
Краткая спецификация определяет отображение требований на функции безопасности (ФБ). "Общие критерии" не предписывают конкретной методологии или дисциплины разработки изделий ИТ, но предусматривают наличие нескольких уровней представления проекта с его декомпозицией и детализацией. За требованиями безопасности следует функциональная спецификация, затем проект верхнего уровня, необходимое число промежуточных уровней, проект нижнего уровня, после этого, в зависимости от типа изделия, исходный код или схемы аппаратуры и, наконец, реализация в виде исполняемых файлов, аппаратных продуктов и т.п.Между уровнями представления должно демонстрироваться соответствие, то есть все сущности более высоких уровней обязаны фигурировать и "ниже", а "внизу" нет места лишним сущностям, не обусловленным потребностями более высоких уровней.
При проведении оценки изделия ИТ главными являются следующие вопросы:
отвечают ли функции безопасности ОО функциональным требованиям? корректна ли реализация функций безопасности?
Если оба ответа положительны, можно говорить о достижении целей безопасности.
Классификация функциональных требований безопасности
Часть 2 "Общих критериев", представляющая собой весьма обширную библиотеку функциональных требований безопасности, описывает 11 классов, 66 семейств, 135 компонентов и содержит сведения о том, какие цели безопасности могут быть достигнуты при современном уровне информационных технологий и каким образом.
Аналогия между библиотекой функциональных требований безопасности и библиотекой программных модулей является в данном случае довольно полной. Функциональные компоненты могут быть не до конца конкретизированы, поэтому фактические параметры подставляются не в самих "Общих критериях", а в определенных профилях защиты, заданиях по безопасности и функциональных пакетах. (Правда, в ГОСТ Р ИСО/МЭК 15408-2002 параметризация не очень удачно названа "назначением".) В качестве параметров могут выступать весьма сложные сущности, такие, например, как политика безопасности (ПБ).
Некоторые функциональные компоненты "Общих критериев" задаются "с запасом", в них включается список возможностей, из которых затем с помощью соответствующей операции выбирается только то, что нужно в конкретной ситуации. Пример - обнаружение и/или предотвращение определенных нарушений политики безопасности. На программистском языке подобный отбор называется частичным применением.
Разумеется, любой функциональный компонент допускает многократное использование (например, чтобы охватить разные аспекты объекта оценки), называемое в ОК итерацией, а также уточнение и добавление дополнительных деталей (последнее можно считать еще одной формой частичного применения).
Между компонентами функциональных требований, как и между привычными библиотечными функциями, могут существовать зависимости. Они возникают, когда компонент не является самодостаточным и для своей реализации нуждается в привлечении других компонентов. Очевидно, размещая в ПЗ, ЗБ или ФП подобный компонент, нужно включить туда и всю гроздь зависимостей (это похоже на разрешение внешних ссылок при формировании выполняемого модуля).
Классы функциональных требований "Общих критериев" можно разделить в зависимости от того, описывают ли они элементарные сервисы безопасности или производные, реализуемые на основе элементарных, направлены ли они на достижение высокоуровневых целей безопасности или играют инфраструктурную роль.
К первой группе относятся следующие классы:
FAU - аудит безопасности (описывает требования к сервису протоколирования/аудита); FIA - идентификация/аутентификация; FRU - использование ресурсов (прежде всего - обеспечение отказоустойчивости).
Классы второй группы:
FCO - связь (обслуживает неотказуемость отправителя/получателя); FPR - приватность;
Достичь высокоуровневых целей безопасности помогают два класса:
FDP - защита данных пользователя; FPT - защита функций безопасности объекта оценки.
Наиболее многочисленны классы, играющие инфраструктурную роль:
FCS - криптографическая поддержка (обслуживает управление криптографическими ключами и криптографические операции); FMT - управление безопасностью; FTA - доступ к объекту оценки (управление сеансами работы пользователей); FTP - доверенный маршрут/канал.
Приведенная классификация содержит несколько примечательных моментов. Во-первых, функциональные требования ОК довольно разнородны. Трудно объяснить, например, почему протоколированию/аудиту соответствует собственный класс, а такой важнейший, без преувеличения, классический сервис безопасности, как управление доступом, "спрятан" среди других требований защиты данных пользователя.
Во-вторых, в ОК не выделены архитектурные требования. Правда, некоторые весьма важные архитектурные компоненты, в числе которых - посредничество при обращениях (частный случай невозможности обхода защитных средств) и разделение доменов, вошли в класс FPT (защита функций безопасности).
В-третьих, требования для защиты данных пользователя и функций безопасности объекта оценки разделены, хотя, очевидно, в обоих случаях необходимо применять сходные механизмы. Возможно, такой подход объясняется желанием выделить ядро безопасности и сохранить его компактность.
Далее мы кратко рассмотрим все 11 классов функциональных требований безопасности "Общих критериев".
Классы функциональных требований, играющие инфраструктурную роль
Криптографические механизмы - обязательный элемент защищенных систем. Класс FCS (криптографическая поддержка) состоит из 2 семейств, где в самом общем виде (точнее, в виде параметризованных шаблонов) рассматриваются генерация, распределение, доступ и уничтожение ключей, а также криптографические операции. Смысл требований состоит в том, что необходимо действовать в соответствии с некими алгоритмами, длинами ключей и стандартами; какие-либо содержательные спецификации отсутствуют.
Класс FMT (управление безопасностью), включающий шесть семейств, регламентирует управление функциями безопасности и их данными, атрибутами и ролями безопасности.
Семейство FMT_MOF (управление отдельными функциями) содержит единственное требование: только уполномоченные пользователи (точнее, уполномоченные идентифицированные роли) могут управлять режимами выполнения, подключением и отключением функций безопасности.
К управлению атрибутами безопасности (семейство FMT_MSA) предъявляется больше требований. Во-первых, оно должно быть доступно только определенным ролям. Во-вторых, необходимо контролировать безопасность присваиваемых значений. В-третьих, при создании объектов должна существовать возможность задания значений, отличных от подразумеваемых.
Аналогичным образом устроено семейство FMT_MTD (управление данными функций безопасности), только вместо переопределения подразумеваемых значений в компоненте FMT_MTD.2 специфицируются граничные значения и действия, предпринимаемые в случае выхода за допустимые границы.
FMT_REV (отмена) предусматривает возможность отмены (отзыва) атрибутов безопасности пользователей, субъектов и объектов.
FMT_SAE позволяет устанавливать сроки действия атрибутов безопасности. Для каждого атрибута могут задаваться действия, выполняемые по истечении срока.
Наконец, семейство FMT_SMR (роли управления безопасностью) предназначено для управления назначением различных ролей пользователям. Предусмотрено наличие правил, управляющих отношениями между ролями.
Шесть семейств простой структуры содержит и класс FTA (доступ к объекту оценки), куда вошли требования управления сеансами работы пользователей (помимо идентификации и аутентификации).
Семейство FTA_LSA определяет требования по ограничению атрибутов безопасности сеанса, которые может выбирать пользователь.
Семейство FTA_MCS ограничивает количество параллельных сеансов, предоставляемых пользователю. Оно может быть как общим, так и индивидуальным (с учетом атрибутов безопасности).
Семейство FTA_SSL (блокирование сеанса) определяет возможность блокирования или завершения интерактивного сеанса как по инициативе пользователя, так и по инициативе функций безопасности (если пользователь неактивен заданное время). Действия, осуществляемые при блокировании, описаны весьма детально:
очистка или перезапись устройств отображения, придание их текущему содержанию нечитаемого вида; блокирование любых действий по доступу к данным пользователя и устройствам отображения, кроме необходимых для разблокирования сеанса. Еще три однокомпонентных семейства содержат некоторые подробности открытия сеанса.
Семейство FTA_TAB (предупреждения перед предоставлением доступа к ОО) предписывает, чтобы перед открытием сеанса отображалось предупреждающее сообщение относительно несанкционированного использования объекта оценки. Это одно из весьма немногих функциональных требований без управляющих конструкций назначения или выбора.
Семейство FTA_TAH (история доступа к ОО) при успешном открытии сеанса определяет требования к отображению истории попыток получить доступ от имени пользователя, выполняющего вход в систему. Здесь проявлена просто-таки трогательная забота о пользователе: оговаривается, что справочная информация не должна исчезать с экрана до того, как пользователь успеет ее просмотреть.
Кроме того, функции безопасности могут отказать пользователю в открытии сеанса, основываясь на атрибутах безопасности, такая возможность с обманчивым названием "Открытие сеанса с ОО" предусмотрена семейством FTA_TSE.
Если сопоставить степень детализации требований к криптографической поддержке и к управлению сеансами, то различие представляется слишком большим. Впрочем, выдержать единый уровень в столь большом и сложном документе, как "Общие критерии", едва ли возможно.
Привычные, традиционные требования предъявляет класс FTP (доверенный маршрут/канал), состоящий из двух семейств, содержащих по одному компоненту в каждом. Доверенный маршрут (семейство FTP_TRP) позволяет выполнять определенные действия в режиме прямого взаимодействия с функциями безопасности (например, при начальной аутентификации). Доверенные каналы (семейство FTP_ITC) предназначены для передачи критичных по безопасности данных между функциями безопасности с другими доверенными изделиями ИТ. Доверенный маршрут/канал должен быть логически отличим от других маршрутов (каналов), обеспечивать уверенную идентификацию взаимодействующих сторон, а также конфиденциальность и целостность передаваемых данных.
На этом мы завершаем рассмотрение функциональных требований безопасности.
<
Классы функциональных требований, описывающие элементарные сервисы безопасности
В этом разделе рассматриваются три класса функциональных требований безопасности:
FAU - аудит безопасности; FIA - идентификация/аутентификация; FRU - использование ресурсов.
Класс FAU состоит из шести семейств, содержащих требования к отбору, протоколированию (регистрации), хранению и анализу данных о действиях и событиях, затрагивающих безопасность объекта оценки.
Семейство FAU_GEN (генерация данных аудита безопасности) включает два компонента. Первый, FAU_GEN.1 (генерация данных аудита), специфицирует потенциально подвергаемые протоколированию и аудиту события, вводит понятие уровня протоколирования (минимальный, базовый, детализированный, неопределенный), определяет минимум регистрационных данных о событии (дата, время, тип, результат события, а также идентификатор субъекта). Второй, FAU_GEN.2 (ассоциация идентификатора пользователя), предписывает ассоциировать каждое потенциально регистрируемое событие с идентификатором пользователя, его инициирующего.
Семейство FAU_SEL (выбор событий аудита безопасности) определяет требования к средствам отбора (включения или исключения) событий из числа потенциально регистрируемых, которые будут реально протоколироваться и подвергаться аудиту в процессе функционирования объекта оценки. Отбор может производиться на основе таких атрибутов, как идентификаторы объекта, пользователя, субъекта, узла сети или тип события. Предусматривается задание дополнительных атрибутов.
Семейство FAU_STG (хранение событий аудита безопасности) содержит две пары компонентов. Первая, FAU_STG.1 (защищенное хранение журнала аудита) и FAU_STG.2 (гарантии доступности данных аудита), специфицирует защиту регистрационного журнала от несанкционированного удаления, модификации, а также от повреждения регистрационных данных при его переполнении, сбое или атаке. Вторая пара, FAU_STG.3 (действия в случае возможной потери данных аудита) и FAU_STG.4 (предотвращение потери данных аудита), определяет последовательность действий, если объем информации в регистрационном журнале превышает заранее заданный порог.
Мы приступаем к рассмотрению двух следующих классов функциональных требований безопасности:
FCO - связь; FPR - приватность.
Класс FCO состоит из двух семейств, FCO_NRO и FCO_NRR, ведающих неотказуемостью (невозможностью отказаться от факта отправки или получения данных), которая достигается путем избирательной или принудительной генерации допускающих верификацию свидетельств, позволяющих ассоциировать атрибуты отправителя (получателя) с элементами передаваемых данных.
Класс FPR (приватность) содержит четыре семейства функциональных требований, обеспечивающих защиту пользователя от раскрытия и несанкционированного использования его идентификационных данных.
Семейство FPR_ANO (анонимность) дает возможность выполнения действий без идентификатора пользователя. Анонимность может быть полной или выборочной. В первом случае функции безопасности обязаны предоставить заданный набор услуг без запроса идентификатора пользователя. Во втором предусмотрено более слабое требование, в соответствии с которым идентификатор может запрашиваться, но должен скрываться от заранее указанных пользователей и/или субъектов.
Семейство FPR_PSE (псевдонимность) обеспечивает условия, когда пользователь может использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то же время подотчетным за свои действия. Базовый компонент семейства, FPR_PSE.1, предписывает выборочную анонимность, а также наличие средств генерации заданного числа псевдонимов и определения или принятия псевдонима от пользователя с верификацией соответствия некоторой метрике псевдонимов. Эти требования дополняются в компоненте FPR_PSE.2 (обратимая псевдонимность) возможностью определения доверенными субъектами идентификатора пользователя по представленному псевдониму, а в компоненте FPR_PSE.3 (альтернативная псевдонимность) - возможностью оперативного перехода на новый псевдоним, связь которого со старым проявляется лишь в заранее оговоренных ситуациях.
Семейство FPR_UNL (невозможность ассоциации) содержит единственный компонент, предусматривающий неоднократное применение пользователем информационных сервисов, не позволяя заданным субъектам ассоциировать их между собой и приписывать одному лицу.
В их число входят игнорирование и своевременное запрещение протоколируемых событий, запись поверх самых старых регистрационных данных и т.д.
Семейство FAU_SAR (просмотр аудита безопасности) предоставляет право на чтение (полное или выборочное, на основе критериев с логическими отношениями) регистрационного журнала уполномоченным пользователям и запрет на доступ к журналу для прочих пользователей.
Семейство FAU_SAA (анализ аудита безопасности) устанавливает требования к средствам автоматического анализа функционирования объекта оценки, позволяющим выявлять возможные нарушения безопасности. Базовым компонентом семейства является FAU_SAA.1 (анализ потенциального нарушения), регламентирующий применение набора правил, основанных на накоплении или объединении событий, сигнализирующих о вероятном нарушении безопасности. В рамках семейства этот компонент усилен по двум направлениям. В FAU_SAA.2 (выявление аномалий, опирающееся на профиль) вводится понятия профиля поведения, рейтинга подозрительной активности для каждого пользователя, чьи действия отражены в профиле, а также порога, превышение которого указывает на ожидаемое нарушение политики безопасности. FAU_SAA.3 (простая эвристика атаки) и FAU_SAA.4 (сложная эвристика атаки) содержит понятие сигнатуры атаки (разной степени сложности) и специфические функции выявления сигнатур в реальном масштабе времени.
Шестое семейство класса FAU - FAU_ARP (автоматическая реакция аудита безопасности) - определяет действия, которые необходимо предпринять при выявлении возможных нарушений безопасности. Действия эти характеризуются как "наименее разрушительные".
Можно сделать вывод, что в "Общих критериях" нашли отражение такие важные достижения относительно недавнего прошлого, как разработка и применение методов активного аудита.
Шесть семейств класса FIA (идентификация/аутентификация) содержат требования к функциям установления и проверки подлинности заявленного идентификатора пользователя, а также связывания атрибутов безопасности с уполномоченным пользователем.
Семейство FIA_UID ( идентификация пользователя) включает два компонента и определяет набор действий (например, получение справочной информации), которые разрешается выполнять до идентификации. Обычно применяют более сильный компонент FIA_UID.2 - идентификация до любых действий, выполняемых пользователем при посредничестве функций безопасности.
Семейство FIA_UAU (аутентификация пользователя) устроено сложнее. Оно специфицирует типы механизмов аутентификации и используемые при этом атрибуты. Два первых компонента, FIA_UAU.1 (выбор момента аутентификации) и FIA_UAU.2 (аутентификация до любых действий пользователя), играют (применительно к аутентификации) ту же роль, что и компоненты семейства FIA_UID. На реализацию надежной аутентификации, устойчивой к сетевым угрозам, направлены компоненты FIA_UAU.3 (аутентификация, защищенная от подделок), FIA_UAU.4 (механизмы одноразовой аутентификации) и FIA_UAU.5 (сочетание механизмов аутентификации). После периода неактивности пользователя и в ряде других ситуаций уместно применение компонента FIA_UAU.6 (повторная аутентификация). Наконец, FIA_UAU.7 (аутентификация с защищенной обратной связью) указывает, как отображать пароль при вводе.
Семейство FIA_ATD (определение атрибутов пользователя) предусматривает наличие у пользователей не только идентификаторов, но и других атрибутов безопасности, предписываемых политикой безопасности.
Обычно после успешной идентификации и аутентификации от имени пользователя начинает действовать некий процесс (субъект). Семейство FIA_USB (связывание пользователь-субъект) содержит требования по ассоциированию атрибутов безопасности пользователя с этим субъектом.
Выявлением и реагированием на неудачи аутентификации ведает семейство FIA_AFL (отказы аутентификации). Разумеется, и число допустимых неудачных попыток, и действия, выполняемые при превышении порога неудач, - все это параметры единственного компонента семейства.
Обычно пользователь доказывает свою подлинность, сообщая нечто, что знает только он ("секрет" в терминологии ОК).
Семейство FIA_SOS ( спецификация секретов) вводит понятие метрики качества секретов и содержит требования к средствам проверки качества и генерации секретов заданного качества. Примеры подобных средств - проверка выполнения технических ограничений на пользовательские пароли в ОС Unix и программные генераторы паролей.
В целом класс FIA, по сравнению с FAU, менее конкретен, его компоненты слишком параметризованы. Вероятно, это связано с тем, что криптография, без которой надежная и удобная для пользователя аутентификация невозможна, находится вне рамок "Общих критериев".
Класс FRU (использование ресурсов) включает три семейства, призванные разными способами поддерживать высокую доступность.
Выполнение требований семейства FRU_FLT (отказоустойчивость) должно обеспечить корректную работу всех или хотя бы некоторых функций объекта оценки даже в случае сбоев.
FRU_PRS (приоритет обслуживания) регламентирует действия по защите высокоприоритетных операций от препятствий или задержек со стороны операций с более низким приоритетом.
Семейство FRU_RSA (распределение ресурсов) для достижения высокой доступности ресурсов привлекает механизм квот.
Обращение к вопросу высокой доступности - несомненное достоинство "Общих критериев", которое, к сожалению, несколько проигрывает из-за отсутствия системного подхода. По неясным причинам в качестве сущностей одного уровня выделен один из трех высокоуровневых аспектов доступности и два механизма, способствующих ее поддержанию.
За пределами рассмотрения остались надежность и обслуживаемость, да и отказоустойчивость может достигаться очень разными способами - от использования многопроцессорных конфигураций до организации резервных вычислительных центров.
Помимо двух рассмотренных механизмов поддержания доступности существуют и другие, не менее важные, например, балансировка загрузки, проактивное управление и т.п. На наш взгляд, было бы целесообразным обобщить требования к доступности регистрационного журнала (см. выше семейство FAU_STG) на случай произвольных ресурсов.
Отметим также, что включение в класс FRU конкретных механизмов еще резче обозначает излишнюю обобщенность требований класса FIA.
Невозможность ассоциации защищает от построения профилей поведения пользователей (см. выше компонент FAU_SAA.2).
Самым сложным в классе FPR является семейство FPR_UNO (скрытность). Его требования направлены на то, чтобы пользователь мог незаметно для кого бы то ни было работать с определенными информационными сервисами. Наиболее интересны два из четырех имеющихся компонентов семейства. FPR_UNO.2 (распределение информации, влияющее на скрытность) предписывает рассредоточить соответствующие данные по различным частям объекта оценки. Это одно из немногих архитектурных требований "Общих критериев" (правда, выраженное в очень общей форме). В некотором смысле противоположную роль играет компонент FPR_UNO.4 (открытость для уполномоченного пользователя), согласно которому уполномоченные пользователи должны иметь возможность наблюдать за тем, как употребляются заданные ресурсы и/или услуги. (Как сказал один пессимист: "Я так и знал, что этим все кончится!")
Требования приватности ставят очень серьезную проблему многоаспектности информационной безопасности, заставляют искать баланс конфликтующих интересов субъектов информационных отношений. Разработчики заданий по безопасности должны учесть и конкретизировать эти требования с учетом действующего законодательства и специфики систем ИТ.
Защита данных пользователя
Мы переходим к рассмотрению классов функциональных требований, направленных на достижение высокоуровневых целей безопасности.
К высокоуровневым целям безопасности относятся защита данных пользователя и защита функций безопасности объекта оценки. Соответствующие классы функциональных требований характеризуются большим числом входящих в них семейств и разнородностью компонентов.
Класс FDP (защита данных пользователя) включает тринадцать семейств, которые можно разбить на четыре группы:
политики защиты данных пользователя; виды защиты данных пользователя;
импорт и экспорт данных пользователя; защита данных пользователя при передаче между доверенными изделиями ИТ.
В первую группу входят два семейства - FDP_ACC (политика управления доступом) и FDP_IFC (политика управления информационными потоками), - играющие, по сути, формальную роль именования политик, распространяющихся на определенные множества субъектов, объектов (потоков) и операций. Управление может быть ограниченным и полным. В последнем случае требуется, чтобы все операции всех субъектов на любом объекте (потоке) из области действия функций безопасности были охвачены некоторой политикой.
Вторая группа объединяет семь семейств. Содержательные аспекты управления доступом (информационными потоками) регламентируются семействами FDP_ACF (функции управления доступом) и FDP_IFF (функции управления информационными потоками). Первое устроено очень просто, состоит из одного компонента и требует наличия политик, основанных на атрибутах безопасности, а также дополнительных правил, явно разрешающих или запрещающих доступ.
Требования к функциям управления информационными потоками, представленные шестью компонентами, существенно сложнее и многообразнее. Компонент FDP_IFF.1 аналогичен FDP_ACF.1. Усиливающий его компонент FDP_IFF.2 требует поддержки многоуровневых политик, основанных на иерархических атрибутах (метках) безопасности. FDP_IFF.3, FDP_IFF.4 и FDP_IFF.5 направлены, соответственно, на ограничение пропускной способности, частичное или полное устранение скрытых каналов.
Наконец, FDP_IFF. 6 требует осуществления мониторинга скрытых каналов, пропускная способность которых превышает заданный порог.
Семейство FDP_DAU (аутентификация данных) обслуживает один из видов статической целостности данных. В соответствии с его требованиями функции безопасности должны предоставить возможность генерировать и верифицировать свидетельства правильности определенных объектов или типов информации (компонент FDP_DAU.1), а также (усиливающий компонент FDP_DAU.2) идентификатора пользователя, создавшего свидетельство.
Отметим, что компонент FDP_DAU.2 ведает неотказуемостью авторства, а рассмотренный выше класс FCO - неотказуемостью отправки и получения данных, что можно считать разновидностью динамической целостности.
Семейство FDP_ITT (передача в пределах ОО) содержит требования, связанные с защитой данных пользователя при их передаче по внутренним каналам объекта оценки. Предусматривается базовая защита внутренней передачи (FDP_ITT.1), направленная на предотвращение раскрытия, модификация ситуаций недоступности, а также мониторинг целостности данных (FDP_ITT.3). При обнаружении ошибок целостности должны выполняться заданные действия. Эти требования усиливаются, соответственно, компонентами FDP_ITT.2 и FDP_ITT.4 за счет раздельной передачи данных, обладающих разными атрибутами безопасности.
Согласно требованиям семейства FDP_RIP (защита остаточной информации), унаследованным от "Оранжевой книги", функции безопасности должны обеспечить уничтожение любого предыдущего содержания ресурсов при их выдаче и/или освобождении.
Семейство FDP_ROL (откат) предусматривает возможность отмены последней операции и возврат к предшествующему состоянию с сохранением целостности данных пользователя.
Последнее семейство второй группы, FDP_SDI (целостность хранимых данных), содержит требования мониторинга целостности всех контролируемых объектов и выполнения заданных действий при обнаружении ошибок целостности хранимых данных.
В третью группу семейств класса FDP, обслуживающую импорт и экспорт данных пользователя в/за пределы области действия функций безопасности объекта оценки, мы включили, как и следовало ожидать, два сходных по структуре двухкомпонентных семейства: FDP_ETC (экспорт) и FDP_ITC (импорт).
Они различаются по наличию или отсутствию (использованию или игнорированию) ассоциированных с данными атрибутов безопасности. Согласованная интерпретация атрибутов оговорена экспортером и импортером.
В последнюю, четвертую группу (защита данных пользователя при передаче между доверенными изделиями ИТ) входят два семейства, ведающих обеспечением конфиденциальности (FDP_UCT) и целостности (FDP_UIT). Имеется в виду, что одним из доверенных изделий является объект оценки, а для передачи используются внешние (по отношению к ОО) каналы.
FDP_UCT состоит из одного компонента, требующего защиты от несанкционированного раскрытия.
В семейство FDP_UIT включены более содержательные требования. Во-первых, предусматривается всеобъемлющая защита от модификации, удаления, вставки и повторения данных. Во-вторых, обнаруженная ошибка целостности может быть восстановлена как с помощью отправителя, доверенного изделия ИТ, так и силами самого объекта оценки.
Обратим внимание на различие требований к защите данных пользователя при передаче по внутреннему (семейство FDP_ITT) и внешнему (семейства FDP_UCT и FDP_UIT) каналам, что можно считать проявлением гибкости "Общих критериев". Для внешних каналов требования заданы более детально (особенно это касается целостности), однако не предусматривается обеспечение высокой доступности данных.
Отметим также, что за различные аспекты целостности данных пользователя отвечают пять семейств: FDP_DAU, FDP_ITT (точнее, компонент FDP_ITT.3), FDP_ROL, FDP_SDI и FDP_UIT. Первое контролирует аутентичность избранных наборов данных, компонент FDP_ITT.3 и семейство FDP_UIT отвечают за (динамическую) целостность передаваемых данных, FDP_ROL - за восстановление целостности после сбоев или ошибок, а FDP_SDI предусматривает тотальный мониторинг статической целостности.
На практике эти варианты целостности контролируются и восстанавливаются разными методами (например, для выполнения требований FDP_DAU естественно воспользоваться криптографическими хэш-функциями или цифровой подписью, для FDP_SDI - обычными контрольными суммами), поэтому разнесение требований, относящихся к одному аспекту ИБ, представляется в данном случае оправданным, хотя, на наш взгляд, предпочтительнее было бы ограничиться уровнем компонентов, а не семейств.Примером могут служить рассмотренные выше компоненты FAU_SAA.2 и FAU_SAA.4, обслуживающие различные методы выявления подозрительной активности.
Защита функций безопасности объекта оценки
Мы продолжаем рассмотрение классов функциональных требований, направленных на достижение высокоуровневых целей безопасности.
Класс FPT (защита функций безопасности объекта оценки) включает шестнадцать семейств (больше, чем какой-либо другой класс функциональных требований), которые можно разбить на четыре группы:
архитектурная безопасность; защита реализации функций безопасности; защита данных функций безопасности; инфраструктурные требования.
Важнейший принцип архитектурной безопасности - невозможность обхода защитных средств. Семейство FPT_RVM (посредничество при обращениях) предназначено для достижения этой цели. Входящий в него единственный компонент FPT_RVM.1 (невозможность обхода политики безопасности ОО) предписывает, чтобы функции, проводящие в жизнь политику безопасности, вызывались и успешно выполнялись прежде любого другого действия, предусмотренного ПБ.
Еще один фундаментальный принцип архитектурной безопасности поддерживается семейством FPT_SEP (разделение доменов). Минимально необходимо отделение домена функций безопасности (компонент FPT_SEP.1), то есть функции безопасности должны поддерживать домен безопасности, который защищает их от вмешательства не облеченных доверием субъектов и искажений с их стороны (кроме того, должно быть реализовано разделение доменов безопасности субъектов). Максимальный уровень потребует реализации полного монитора обращений (компонент FPT_SEP.3), то есть предоставление отдельного домена той части функций безопасности, которая проводит в жизнь политики управления доступом и/или информационными потоками.
Защитой реализации функций безопасности занимаются четыре семейства. Самое простое из них (по формулировке, но не по воплощению и/или проверке), FPT_FLS (безопасность при сбое), содержит требование, чтобы политика безопасности не нарушалась при сбоях заданных типов.
Обеспечения высокой доступности и корректной работы функций безопасности вопреки возможным сбоям добивается и более сложное семейство FPT_RCV (надежное восстановление).
Объединение в одном компоненте двух существенно разных видов требований представляется странным (тестирование имеет мало общего с контролем целостности кода и, тем более, изменяемых данных), но позволяет плавно перейти к третьей группе семейств класса 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 (метки времени) требует предоставления надежных меток времени в пределах объекта оценки. Подобные метки необходимы, например, функциям протоколирования и управления.
Оценка профилей защиты и заданий по безопасности
Цель требований, вошедших в классы APE (оценка профиля защиты) и ASE (оценка задания по безопасности), - проверить полноту, непротиворечивость и реализуемость ПЗ или ЗБ.
Класс APE состоит из шести однокомпонентных семейств, соответствующих предписанной структуре профилей защиты.
Семейство APE_INT (введение ПЗ) требует от разработчика представить введение как часть ПЗ, содержащую данные идентификации и аннотацию ПЗ. Оценщик должен подтвердить, что имеющаяся информация удовлетворяет всем требованиям к содержанию и представлению свидетельств, что введение является логически последовательным и внутренне непротиворечивым и согласуется с другими частями ПЗ. Перечисленные требования к действиям оценщика носят стандартный характер и далее упоминаться не будут.
Семейство APE_DES (описание ОО) специфицирует, что описание объекта оценки должно включать в себя, как минимум, тип продукта и его общую характеристику.
Требования семейства APE_ENV (среда безопасности) более содержательны. Необходимо идентифицировать и объяснить все допущения о предполагаемом применении ОО и среде использования, все угрозы, от которых нужна защита, и все политики безопасности, обязательные для исполнения.
Еще содержательнее требования семейства APE_OBJ (цели безопасности). Разработчик должен не только сформулировать цели безопасности для объекта оценки и его среды, но и представить их логическое обоснование, продемонстрировав противостояние всем идентифицированным угрозам, охват всех установленных положений политик безопасности и предположений безопасности.
Основное содержание профиля защиты составляют требования безопасности. К этой части применимы семейства APE_REQ (требования безопасности ИТ) и APE_SRE (требования безопасности ИТ, сформулированные в явном виде). Первое относится к стандартным требованиям "Общих критериев", второе - к расширениям ОК, введенным разработчиком ПЗ. Логическое обоснование требований безопасности должно демонстрировать их решающую роль в достижении целей безопасности.
Класс ASE устроен аналогично классу APE, некоторые отличия вызваны большей конкретностью задания по безопасности в сравнении с профилем защиты и наличием дополнительных разделов. Модифицированы требования шести рассмотренных выше семейств и добавлены два новых.
Семейство ASE_TSS (краткая спецификация ОО) определяет в самом общем виде функции безопасности и меры доверия, предназначенные, соответственно, для выполнения функциональных требований и требований доверия.
Функции безопасности и функциональные требования сопоставляют таким образом, чтобы можно было понять, какие из них обслуживают отдельно взятое требование и, наоборот, для выполнения каких требований предназначена каждая из функций. Логическое обоснование краткой спецификации ОО должно демонстрировать, что специфицированные функции пригодны для удовлетворения функциональных требований. Функции, реализованные вероятностными или перестановочными механизмами, нуждаются в определении требований к стойкости.
Если задание по безопасности является конкретизацией некоторых ПЗ, к нему применяются требования семейства ASE_PPC (утверждения о соответствии профилям защиты).
Подчеркнем важность тщательной разработки и оценки профилей защиты и заданий по безопасности. Просчеты на стадиях выработки требований и спецификаций изделий ИТ чреваты особо тяжелыми последствиями, исправлять которые сложно и дорого.
Оценочные уровни доверия безопасности
В "Общих критериях" определено семь упорядоченных по возрастанию оценочных уровней доверия (ОУД) безопасности, содержащих рассчитанные на многократное применение комбинации требований доверия (не более одного компонента из каждого семейства). Наличие такой шкалы дает возможность сбалансировать получаемый уровень доверия со сложностью, сроками, стоимостью и самой возможностью его достижения.
Предполагается, что в профилях защиты и заданиях по безопасности будут фигурировать или сами оценочные уровни, или их усиления, полученные путем расширения требований (за счет добавления к ОУД новых компонентов) либо увеличения строгости и/или глубины оценки (посредством замены компонентов более сильным вариантом из того же семейства). Таким образом, ОУД играют роль опорных точек в многомерном пространстве требований доверия.
Отметим, что в ОУД не включены требования классов APE (оценка профиля защиты), ASE (оценка задания по безопасности) и AMA (поддержка доверия), поскольку они находятся вне пределов основного цикла разработки изделий ИТ.
Оценочный уровень доверия 1 (ОУД1), предусматривающий функциональное тестирование, применим, когда требуется некоторая уверенность, что объект оценки работает безукоризненно, а угрозы безопасности не считаются серьезными. Его можно достичь без помощи разработчика и с минимальными затратами посредством анализа функциональной спецификации, спецификации интерфейсов, эксплуатационной документации в сочетании с независимым тестированием.
Оценочный уровень доверия 2 (ОУД2) предусматривает структурное тестирование и доступ к части проектной документации и результатам тестирования разработчиком. ОУД2 применим, когда разработчикам или пользователям требуется независимо получаемый умеренный уровень доверия при отсутствии доступа к полной документации по разработке.
В дополнение к ОУД1 предписывается анализ проекта верхнего уровня. Анализ должен быть поддержан независимым тестированием функций безопасности, актом разработчика об испытаниях, основанных на функциональной спецификации, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций и свидетельством поиска явных уязвимостей. Требуется наличие списка конфигурации ОО с уникальной идентификацией элементов конфигурации и свидетельства безопасных процедур поставки.
Оценочный уровень доверия 3 (ОУД3), предусматривающий систематическое тестирование и проверку, позволяет достичь максимально возможного доверия при использовании обычных методов разработки. Он применим в тех случаях, когда разработчикам или пользователям требуется умеренный уровень доверия на основе всестороннего исследования объекта оценки и процесса его разработки.
По сравнению с ОУД2 сюда добавлено требование, которое предписывает разработчику создавать акт об испытаниях с учетом особенностей не только функциональной спецификации, но и проекта верхнего уровня. Кроме того, требуется контроль среды разработки и управление конфигурацией объекта оценки.
Оценочный уровень доверия 4 (ОУД4) предусматривает систематическое проектирование, тестирование и просмотр. Он позволяет достичь доверия, максимально возможного при следовании общепринятой практике коммерческой разработки. Это самый высокий уровень, на который, вероятно, экономически целесообразно ориентироваться для существующих типов продуктов.
ОУД4 характеризуется анализом функциональной спецификации, полной спецификации интерфейсов, эксплуатационной документации, проектов верхнего и нижнего уровней, а также подмножества реализации, применением неформальной модели политики безопасности ОО. Среди других дополнительных требований - независимый анализ уязвимостей, демонстрирующий устойчивость к попыткам проникновения нарушителей с низким потенциалом нападения, и автоматизация управления конфигурацией.
Отличительные особенности оценочного уровня доверия 5 (ОУД5) - полуформальное проектирование и тестирование. С его помощью достигается доверие, максимально возможное при следовании строгой практике коммерческой разработки, поддержанной умеренным применением специализированных методов обеспечения безопасности. ОУД5 востребован, когда нужен высокий уровень доверия и строгий подход к разработке, не влекущий излишних затрат.
Для достижения ОУД5 требуется формальная модель политики безопасности ОО и полуформальное представление функциональной спецификации и проекта верхнего уровня, полуформальная демонстрация соответствия между ними, а также модульная структура проекта ОО. Акт об испытаниях должен быть основан еще и на проекте нижнего уровня. Необходима устойчивость к попыткам проникновения нарушителей с умеренным потенциалом нападения. Предусматривается проверка правильности анализа разработчиком скрытых каналов и всестороннее управление конфигурацией.
Оценочный уровень доверия 6 (ОУД6) характеризуется полуформальной верификацией проекта. Он позволяет получить высокое доверие путем применения специальных методов проектирования в строго контролируемой среде разработки при производстве высококачественных изделий ИТ и при защите ценных активов от значительных рисков.
Особенности ОУД6:
структурированное представление реализации;полуформальное представление проекта нижнего уровня;иерархическая структура проекта ОО;устойчивость к попыткам проникновения нарушителей с высоким потенциалом нападения;проверка правильности систематического анализа разработчиком скрытых каналов;использование структурированного процесса разработки;полная автоматизация управления конфигурацией ОО.
Оценочный уровень доверия 7 (ОУД7), предусматривающий формальную верификацию проекта, применим к разработке изделий ИТ для использования в ситуациях чрезвычайно высокого риска или там, где высокая ценность активов оправдывает повышенные затраты.
На седьмом уровне дополнительно требуются:
формальное представление функциональной спецификации и проекта верхнего уровня и формальная демонстрация соответствия между ними;модульная, иерархическая и простая структура проекта ОО;добавление представления реализации как основы акта об испытаниях;полное независимое подтверждение результатов тестирования разработчиком.
На наш взгляд, оценочные уровни доверия выбраны очень удачно; их усиление в профилях защиты и заданиях по безопасности в подавляющем большинстве случаев носит непринципиальный характер.
Дополнительную информацию по "Общим критериям" можно найти в книге [87].
<
Основные понятия и классификация требований доверия безопасности
Требования доверия безопасности составляют содержание третьей части "Общих критериев".
Доверие в трактовке "Общих критериев" - это основа для уверенности в том, что изделие ИТ отвечает целям безопасности. Доверие обеспечивается через активное исследование (оценку) изделия ИТ.
Требования доверия безопасности охватывают весь жизненный цикл изделий ИТ и предполагают выполнение следующих действий:
оцениваются задания по безопасности (ЗБ) и профили защиты (ПЗ), ставшие источниками требований безопасности;анализируются различные представления проекта объекта оценки и соответствие между ними, а также соответствие каждого из них требованиям безопасности;проверяются процессы и процедуры безопасности, их применение;анализируется документация;верифицируются представленные доказательства;анализируются тесты и их результаты;анализируются уязвимости объекта оценки;проводится независимое тестирование, в том числе тестовые "взломы" (называемые далее тестированием проникновения).
Каждое требование (элемент) доверия принадлежит одному из трех типов:
элементы действий разработчика (помечаются буквой "D" после номера элемента); эти действия должны подтверждаться доказательным материалом (свидетельствами);элементы представления и содержания свидетельств (помечаются буквой "C");элементы действий оценщика (помечаются буквой "E"); оценщики обязаны проверить представленные разработчиками свидетельства, а также выполнить необходимые дополнительные действия (например, провести независимое тестирование).
Требования доверия разделены на 10 классов, 44 семейства и 93 компонента. Классы можно сгруппировать в зависимости от охватываемых этапов жизненного цикла изделий ИТ.
К первой группе, логически предшествующей разработке и оценке ОО, принадлежат классы APE (оценка профиля защиты) и ASE (оценка задания по безопасности).
Во вторую группу входят классы ADV (разработка), ALC (поддержка жизненного цикла) и ACM (управление конфигурацией).
К этапу получения, представления и анализа результатов разработки можно отнести классы AGD (руководства), ATE (тестирование) и AVA (оценка уязвимостей).
Требования к поставке и эксплуатации составляют содержание класса ADO.
Наконец, класс AMA (поддержка доверия) включает требования, применяемые после сертификации объекта оценки на соответствие "Общим критериям".
По сравнению с функциональными, требования доверия устроены несколько проще. Во-первых, к их элементам не применяются операции назначения и выбора. Во-вторых, компоненты в пределах семейства линейно упорядочены, то есть компонент с большим номером всегда усиливает предыдущий.
Одна из целей "Общих критериев" состоит в минимизации усилий разработчиков и оценщиков, направленных на обеспечение заданного уровня доверия. Этому способствует введение семи оценочных уровней доверия (ОУД), содержащих полезные для практического применения комбинации компонентов, упорядоченные по степени усиления. Повысить уровень доверия помогут дополнительные действия:
расширение границ объекта оценки;увеличение уровня детализации рассматриваемых аспектов ОО;повышение строгости рассмотрения, применение более формальных методов верификации.
Далее мы кратко рассмотрим семейства требований и оценочные уровни доверия безопасности.
Требования доверия к этапу разработки
Функциональные требования, политика безопасности и краткая спецификация объекта оценки служат отправным пунктом процесса разработки функций безопасности ОО. Класс ADV (разработка) состоит из семи многокомпонентных семейств и содержит требования для постепенного повышения уровня детализации проекта вплоть до представления реализации с демонстрацией соответствия между уровнями.
В этом классе предусмотрены три стиля изложения спецификаций: неформальный, полуформальный и формальный - и три способа демонстрации соответствия.
Неформальная спецификация пишется как обычный текст с определением необходимых терминов. Неформальная демонстрация соответствия требует установления "соответствия по сути".
Полуформальная спецификация создается при помощи языка с ограниченным синтаксисом и, как правило, сопровождается пояснительным текстом. Полуформальная демонстрация соответствия невозможна без структурированного подхода.
В формальной спецификации используется математическая нотация, а методом демонстрации соответствия служит формальное доказательство.
Ранжирование компонентов в семействах класса ADV в основном соответствует стилю изложения спецификаций, ужесточаясь от неформального к формальному.
В классе ADV выделены четыре уровня детализации проекта: функциональная спецификация, проект верхнего уровня, проект нижнего уровня, представление реализации. Поскольку в конкретной разработке некоторые из них могут отсутствовать, предусмотрена независимая демонстрация соответствия каждого функциональным требованиям.
Требования к функциональной спецификации, сосредоточенные в семействе ADV_FSP, указывают на обязательность включения в функциональную спецификацию описания назначения и методов использования всех внешних интерфейсов функций безопасности объекта оценки с добавлением, где это необходимо, детализации результатов, нештатных ситуаций и сообщений об ошибках. Из описания должно быть понятно, как учтены функциональные требования и каким образом строить тесты соответствия.
Требования семейства ADV_SPM ( моделирование политики безопасности) охватывают еще один аспект функциональной спецификации - соответствие политике безопасности объекта оценки, возможности ее осуществления. Средством демонстрации соответствия служит модель политики безопасности: необходимо показать, что все функции безопасности в функциональной спецификации непротиворечивы и их полнота адекватна модели.
Семейство ADV_HLD содержит требования к проекту верхнего уровня, описывающего структуру функций безопасности ОО в терминах подсистем. Проект должен идентифицировать все необходимые базовые аппаратные, программно-аппаратные и/или программные средства с представлением функций, обеспечиваемых поддержкой реализуемых этими средствами механизмов защиты, а также все интерфейсы подсистем, выделяя те из них, которые предполагаются видимыми извне. Каждый интерфейс необходимо снабдить описанием назначения и методов использования (то же касается и функциональных спецификаций - это означает демонстрацию соответствия функциональным требованиям и позволяет организовать тестирование.) Следует выделить подсистемы, осуществляющие политику безопасности. Наконец, проект верхнего уровня должен содержать обоснование того, что выбранные механизмы достаточны для реализации функций безопасности.
Требования к проекту нижнего уровня образуют семейство ADV_LLD, в котором детализация доходит до уровня модуля. Специфицируются все интерфейсы модулей (с выделением видимых извне), реализующих функции безопасности. Обязательное условие - описание разделения на модули, выполняющие политику безопасности, и прочие, а также предоставление осуществляющих эту политику функций. Взаимосвязи между модулями следует определять в терминах имеющихся функциональных возможностей безопасности и зависимостей от других модулей. Проект нижнего уровня должен содержать описание назначения и методов использования всех интерфейсов модулей, а при необходимости - возможность создания детального отчета о результатах, нештатных ситуациях и отправки уведомлений об ошибках.
Очень важно, чтобы представление реализации (семейство ADV_IMP) однозначно определяло функции безопасности объекта оценки на высоком уровне детализации, тогда впоследствии их возможно создать без дальнейших проектных решений. Представление реализации должно быть структурировано в малые и понятные разделы, включать в себя описание связей между всеми частями реализации.
Семейство ADV_RCR ведает соответствием всех имеющихся смежных уровней представления функций безопасности. Надо доказать, что все функциональные возможности более абстрактного представления, относящиеся к безопасности, правильно и полностью уточнены на менее абстрактном уровне.
Требования семейства ADV_INT (внутренняя структура функций безопасности ОО) носят технологический характер и сходны по смыслу с требованиями структурированного программирования. Основная идея состоит в минимизации сложности процесса и результата разработки путем разбиения на модули и использования нескольких уровней абстракции. Здесь придется впервые сформулировать требования к действиям разработчика (до этого мы ограничивались требованиями к представлению и содержанию свидетельств).
Разработчик должен проектировать и структурировать функции безопасности объекта оценки в модульном, многоуровневом виде, облегчая связи между модулями, а также между уровнями проекта, уменьшая общую сложность, в особенности тех частей, которые отвечают за политику безопасности, чтобы они были простыми для анализа.
Разработчик обязан представить описание архитектуры с изложением назначения, интерфейсов, параметров и результатов применения каждого модуля и выделением частей, осуществляющих политику безопасности, с разбиением на уровни и демонстрацией того, что сложность минимизирована.
На наш взгляд, подобные архитектурные требования крайне важны, они заслуживают развития и вынесения в отдельный класс. Есть еще целый ряд других архитектурных принципов, специфичных для информационной безопасности (например, эшелонированность обороны, разнообразие защитных средств), которые, к сожалению, остались за рамками "Общих критериев".
Технологические требования процедурного характера составляют содержание класса ALC (поддержка жизненного цикла), состоящего из четырех семейств.
Прежде всего определяется модель жизненного цикла (семейство ALC_LCD), описывающая процессы разработки и сопровождения ОО, включая детализацию количественных параметров и/или метрик, используемых для оценки соответствия процесса разработки и принятой модели.
Затем следует обосновать выбор инструментальных средств и методов (семейство ALC_TAT). Это относится, в частности, к используемым языкам программирования, средствам подготовки документации, стандартам реализации и т.п.
Безопасность разработки организуется в соответствии с требованиями семейства ALC_DVS. Разработчик должен не только иметь описание и обоснование всех физических, относящихся к персоналу и иных мер безопасности, которые необходимы для обеспечения конфиденциальности и целостности проекта ОО и его реализации, но и соблюдать эти меры во время создания и сопровождения ОО, что проверяется оценщиками.
Важным элементом этапа сопровождения является устранение недостатков (семейство ALC_FLR). Процедуры отслеживания и устранения недостатков фиксируются разработчиком. Они должны содержать требование представления описания природы и проявлений каждого недостатка безопасности, а также статуса завершения исправления этого недостатка. Разработчик устанавливает процедуру приема и отработки сообщений о недостатках, запросов на их исправление с указанием контактных адресов и автоматическим распространением сообщений о недостатках и их исправлении зарегистрированным пользователям. Все ставшие известными недостатки безопасности должны быть исправлены (без создания новых), а исправления изданы.
Управление конфигурацией (УК, класс ACM) - необходимый инструмент коллектива разработчиков. В этот класс входят три семейства, самое содержательное из которых - ACM_CAP, специфицирующее возможности УК. Кроме выполнения очевидных требований уникальной идентификации (маркировки) объекта оценки, его версий и элементов (с выделением частей, относящихся к функциям безопасности), необходимо предусмотреть меры защиты от несанкционированных изменений и меры поддержки генерации ОО.
Любопытно применение принципа разделения обязанностей: требуется, чтобы лицо, ответственное за включение элемента в УК, не являлось его разработчиком.
Семейство ACM_SCP специфицирует область действия управления конфигурацией. Она включает представление реализации объекта оценки, проектную и тестовую документацию, документацию пользователя и администратора, документацию УК, информацию о недостатках безопасности и инструментальные средства разработки.
Для уменьшения числа возможных ошибок управление конфигурацией следует максимально автоматизировать - в этом смысл требований семейства ACM_AUT. Автоматизация должна распространяться на защиту от несанкционированных изменений, генерацию объекта оценки, выявление различий между версиями и на нахождение элементов, подвергающихся воздействию определенной модификации.
В целом требования доверия к этапу разработки сформулированы на высоком уровне, в соответствии с современной технологией создания и сопровождения сложных систем.
Требования к этапу получения, представления и анализа результатов разработки
Мы переходим к рассмотрению трех следующих классов требований доверия безопасности: AGD (руководства), ATE (тестирование) и AVA (оценка уязвимостей).
Класс AGD состоит из двух однокомпонентных семейств, где сформулированы требования к руководствам администратора (AGD_ADM) и пользователя (AGD_USR).
Руководство администратора должно содержать:
описание особенностей управления ОО безопасным способом;описание функций и интерфейсов администрирования;предупреждения относительно функций и привилегий, подлежащие контролю;описание всех предположений о поведении пользователя, которые связаны с безопасной эксплуатацией ОО;описание всех параметров безопасности, контролируемых администратором, с указанием безопасных значений;описание событий, относящихся к безопасности;описание всех требований безопасности к среде ИТ, имеющих отношение к администратору.
В руководство пользователя необходимо включить:
описание функций и интерфейсов объекта оценки, доступных пользователям;описание применения доступных пользователям функций безопасности;предупреждения относительно доступных пользователям функций и привилегий, которые следует контролировать;изложение всех обязанностей пользователя по безопасной эксплуатации ОО.
Класс ATE (тестирование) состоит из четырех семейств, содержащих требования к полноте, глубине, способам и результатам тестирования функций безопасности на предмет их соответствия спецификациям.
Разработчик выполняет функциональное тестирование (семейство ATE_FUN), обосновывает достаточность глубины (семейство ATE_DPT) и покрытия (ATE_COV) тестов.
При функциональном тестировании необходимо проверить все функции безопасности, не ограничиваясь подтверждением наличия требуемых функций безопасности, но проверяя также, отсутствуют ли нежелательные режимы функционирования.
Анализ глубины должен показать достаточность тестов для демонстрации того, что функции безопасности выполняются в соответствии с проектами верхнего и нижнего уровней и представлением реализации.
Важно, чтобы анализ покрытия демонстрировал полное соответствие между представленными тестами и описанием функций безопасности в функциональной спецификации.
Требуется полностью проверить все внешние интерфейсы функций безопасности.
Семейство ATE_IND (независимое тестирование) регламентирует действия оценщиков. Оценщику следует протестировать необходимое подмножество функций безопасности и подтвердить, что объект оценки функционирует в соответствии со спецификациями, а также выполнить некоторые или все тесты из тестовой документации, чтобы верифицировать результаты, полученные разработчиком.
Один из ключевых моментов оценки безопасности изделия ИТ - оценка уязвимостей (класс AVA), отправным пунктом которой является анализ уязвимостей (семейство AVA_VLA), выполняемый разработчиком и оценщиком. Четыре компонента этого семейства ранжированы по уровню строгости анализа и потенциалу предполагаемого нарушителя.
Анализ, проводимый разработчиком, направлен на поиск и идентификацию уязвимостей, обоснование невозможности их использования в предполагаемой среде и стойкости объекта оценки к явным нападениям.
Прежде всего оценщик обязан проверить, что ОО противостоит нападениям нарушителя, соответственно, с низким (AVA_VLA.2), умеренным (AVA_VLA.3) или высоким (AVA_VLA.4) потенциалом. Для достижения этой цели в общем случае проводится независимый анализ уязвимостей, а затем оцениваются возможности использования идентифицированных разработчиком и дополнительно выявленных уязвимостей, посредством проведения тестовых атак.
Анализ стойкости функций безопасности объекта оценки (семейство AVA_SOF) проводится на уровне реализующих механизмов. По своей направленности он аналогичен анализу уязвимостей. Выше, в разделе "Основные понятия и идеи "Общей методологии оценки безопасности информационных технологий", мы подробно рассматривали эту тему. Здесь же отметим, что требования единственного компонента семейства AVA_SOF носят формальный характер: для каждого механизма, имеющего утверждение относительно стойкости функции безопасности, анализ должен показать, что стойкость достигает или превышает уровень, определенный в профиле защиты или задании по безопасности.
Требования семейства AVA_MSU ( неправильное применение) направлены на то, чтобы исключить возможность такого конфигурирования и/или применения объекта оценки, которое администратор или пользователь считают безопасным, в то время как оно таковым не является. Необходимо обеспечить отсутствие в руководствах вводящих в заблуждение, необоснованных и противоречивых указаний и наличие безопасных процедур для всех режимов функционирования. Опасные состояния должны легко выявляться.
Задача решается следующим образом: в представленных разработчиком руководствах идентифицируются все возможные режимы эксплуатации объекта оценки, включая действия после сбоя или ошибки в работе, их последствия и значение для безопасности эксплуатации. Прилагается список всех предположений относительно среды эксплуатации и требований к внешним мерам безопасности.
Оценщик должен повторить все процедуры конфигурирования и установки, а также выборочно другие процедуры для подтверждения того факта, что объект оценки можно безопасно конфигурировать и использовать, применяя только представленные руководства. Кроме того, он обязан выполнить независимое тестирование и проверить, смогут ли администратор или пользователь выяснить, руководствуясь документацией, что ОО сконфигурирован или используется опасным образом.
Анализ скрытых каналов, регламентируемый семейством AVA_CCA, крайне сложен и концептуально, и технически (см., например, статью [8]). Здесь легко требовать, но трудно выполнять. Согласно "Общим критериям", разработчик проводит исчерпывающий поиск скрытых каналов для каждой политики управления информационными потоками и предоставляет документацию анализа, в которой идентифицированы скрытые каналы и оценена их пропускная способность, описаны наиболее опасные сценарии использования каждого идентифицированного скрытого канала.
Оценщик должен выборочно подтвердить правильность анализа скрытых каналов посредством тестирования.
Требования к поставке и эксплуатации, поддержка доверия
Класс ADO (поставка и эксплуатация) содержит требования к процедурам поставки, установки, генерации и запуска объекта оценки.
Требования к поставке сосредоточены в трехкомпонентном семействе ADO_DEL. Разработчик должен документировать и использовать процедуры поставки объекта оценки или его частей. Необходимо описать, каким образом различные процедуры и технические меры обеспечивают обнаружение (ADO_DEL.2) или предотвращение (ADO_DEL.3) модификаций либо иного расхождения между оригиналом разработчика и версией, полученной в месте применения, а также обнаружение попыток подмены от имени разработчика в тех случаях, когда последний ничего не поставлял.
Семейство ADO_IGS (установка, генерация и запуск) предназначено для безопасного перехода к этапу эксплуатации. Процедуры безопасной установки, генерации и запуска объекта оценки документируются разработчиком. Документация должна содержать описание процедур, обеспечивающих протоколирование применявшихся опций генерации, для точного ответа на вопрос, как и когда был сгенерирован ОО.
Класс AMA (поддержка доверия) включает четыре семейства и содержит требования, к которым обращаются после сертификации объекта оценки. Они помогают (по возможности экономно, без полной повторной оценки) сохранить уверенность в том, что ОО продолжает отвечать своему заданию по безопасности после изменений в нем или в его среде. Речь идет о выявлении новых угроз или уязвимостей, изменении в требованиях пользователя, а также об исправлении ошибок.
Действия по поддержке доверия носят циклический характер. Каждая итерация цикла состоит из двух фаз:
приемка объекта оценки для поддержки;
мониторинг ОО.
Фаза приемки включает разработку плана поддержки доверия и категорирование компонентов объекта оценки по их влиянию на безопасность. Элементы фазы мониторинга - представление описания текущей версии ОО и выполнение анализа влияния изменений на безопасность. Возможно, в конце итерации выяснится, что план или категорирование нуждаются в уточнении или изменении; тогда новая итерация начнется с повторной приемки ОО.
Цикл поддержки доверия не может выполняться бесконечно. В конце концов, либо накопится много мелких изменений, либо потребуются крупные, и тогда переоценка станет неизбежной.
Семейство AMA_AMP (план поддержки доверия) регламентирует вход в цикл поддержки доверия. Оно идентифицирует процедуры, которые выполняет разработчик при изменении объекта оценки или его среды. План поддержки доверия должен содержать краткое описание ОО, включающее предоставляемые им функциональные возможности безопасности, идентифицировать сертифицированную версию ОО и ссылаться на результаты оценки, определять предусматриваемые пределы изменения ОО, содержать описание жизненного цикла ОО, текущие планы новых выпусков ОО, аудита и следующей переоценки, а также включать в себя краткое описание любых запланированных изменений, которые, как ожидается, будут иметь заметное влияние на безопасность. План необходимо дополнить описанием процедур, которые предполагается применять для поддержки доверия и куда, как минимум, следует включить процедуры управления конфигурацией, поддержки свидетельства доверия, выполнения анализа влияния произведенных изменений на безопасность, устранения недостатков.
План поддержки доверия опирается на отчет о категорировании компонентов ОО для сертифицированной версии ОО, специфицируемый семейством AMA_CAT. Категорирование критически важно для анализа влияния на безопасность и переоценки ОО. Отчет должен распределить по категориям каждый компонент, который может быть идентифицирован в каждом представлении функций безопасности от наиболее до наименее абстрактного, согласно его отношению к безопасности. Как минимум, необходимо разделить компоненты ОО на осуществляющие и не осуществляющие политику безопасности. Следует описать примененную схему категорирования, чтобы сделать возможным распределение по категориям новых компонентов, а также перераспределение существующих вследствие изменений в ОО или в его задании по безопасности. Наконец, отчет должен идентифицировать средства разработки, модификация которых влияет на доверие.
Назначение семейства AMA_EVD (свидетельство поддержки доверия) состоит в том, чтобы в рамках фазы мониторинга убедиться в поддержке разработчиком доверия безопасности объекта оценки в соответствии с представленным планом. Семейство содержит требования к документации поддержки доверия для текущей версии ОО. Документация должна включать список текущей конфигурации ОО и список идентифицированных уязвимостей, подтверждать следование процедурам, описанным в плане поддержки доверия. Для каждой уязвимости в текущей версии требуется показать, что она не может быть использована в предполагаемой среде ОО.
Оценщик должен подтвердить, что все изменения, документированные при анализе влияния на безопасность для текущей версии ОО, находятся в пределах, установленных планом поддержки доверия, и что функциональное тестирование выполнялось на текущей версии ОО соразмерно поддерживаемому уровню доверия.
Анализ влияния на безопасность (семейство AMA_SIA), проведенный разработчиком, позволит оценить последствия изменений, воздействующих на сертифицированный объект оценки. По его результатам готовится документ, идентифицирующий сертифицированный ОО, откуда была получена текущая версия, а также все новые и модифицированные компоненты. Для каждого изменения, воздействующего на задание по безопасности или на представления функций безопасности, следует описать все последствия, к которым оно приводит на более низких уровнях представления, идентифицировать все функции безопасности и компоненты, категорированные как осуществляющие политику безопасности и подверженные влиянию со стороны данного изменения.
Если изменение приводит к модификации представления реализации, следует идентифицировать тесты, подтверждающие правильность функционирования новой версии.
Наконец, необходимо проанализировать влияние изменений на оценку уязвимости, управление конфигурацией, руководства, поставку и эксплуатацию, поддержку жизненного цикла объекта оценки.
Оценщик должен удостовериться, что при анализе влияния на безопасность все изменения документированы на приемлемом уровне детализации вместе с соответствующим строгим обоснованием поддержки доверия в текущей версии ОО.
На этом мы завершаем рассмотрение семейств требований доверия безопасности.
Общие функциональные требования
Для различных сервисов безопасности общими являются функциональные требования, связанные с идентификацией и аутентификацией, управлением доступом, протоколированием и аудитом, а также обеспечением высокой доступности. Далее эти требования разбиты в соответствии с иерархией, принятой в "Общих критериях".
Для сервисов безопасности предусмотрены общие требования по протоколированию и аудиту (класс FAU):
автоматическая реакция аудита безопасности (FAU_ARP.1.1), включая генерацию записи в регистрационном журнале, а также локальную или удаленную сигнализацию об обнаружении вероятного нарушения безопасности, адресованную администратору;генерация данных аудита безопасности (FAU_GEN.1). Обязательному протоколированию подлежат запуск и завершение регистрационных функций, а также все события для базового уровня аудита . В каждой регистрационной записи должны присутствовать дата и время события, тип события, идентификатор субъекта и результат (успех или неудача) события;анализ аудита безопасности (FAU_SAA.1.2). С целью выявления вероятных нарушений должны производиться по крайней мере накопление и/или объединение неуспешных результатов использования механизмов аутентификации, а также неуспешных результатов выполнения криптографических операций;просмотр аудита безопасности (FAU_SAR). Администратору предоставляется возможность читать всю регистрационную информацию. Прочим пользователям доступ к ней закрыт, за исключением явно специфицированных случаев;выбор событий аудита безопасности (FAU_SEL.1). Избирательность регистрации событий должна основываться хотя бы на минимально необходимом наборе атрибутов, состоящем из идентификатора объекта, идентификатора субъекта, адреса узла сети, типа события, даты и времени события;хранение данных аудита безопасности (FAU_STG.1.2). Регистрационную информацию следует защитить от несанкционированной модификации.
Многие сервисы безопасности прямо или косвенно нуждаются в криптографической поддержке, поэтому соответствующие требования класса FCS целесообразно трактовать как общие:
управление криптографическими ключами (FCS_CKM). Должны поддерживаться генерация криптографических ключей (FCS_CKM.1), распределение криптографических ключей (FCS_CKM.2), управление доступом к криптографическим ключам (FCS_CKM.3), уничтожение криптографических ключей (FCS_CKM.4);криптографические операции (FCS_COP.1). Всю информацию, передаваемую по доверенному каналу, необходимо шифровать и контролировать ее целостность согласно требованиям стандартов и других нормативных документов.
Любой сервис безопасности содержит данные пользователей (например, информацию для идентификации и аутентификации), поэтому общими являются и требования класса FDP (защита данных пользователя):
политика управления доступом (FDP_ACC.1.1). Должно осуществляться разграничение доступа для пользователей, прямо или косвенно выполняющих операции с сервисом безопасности;функции управления доступом (FDP_ACF.1.1). Применение функций разграничения доступа основывается на следующих атрибутах безопасности: идентификаторы субъектов доступа, идентификаторы объектов доступа, адреса субъектов доступа, адреса объектов доступа, права доступа субъектов; базовая защита внутренней передачи (FDP_ITT.1). Следует осуществлять заданную политику управления доступом и/или информационными потоками, чтобы предотвратить раскрытие, модификацию и/или недоступность данных пользователя при их передаче между физически разделенными частями сервиса безопасности (FDP_ITT.1.1);защита остаточной информации (FDP_RIP.2.1). Для всех объектов должна обеспечиваться полная защита остаточной информации, то есть недоступность предыдущего состояния при освобождении ресурса.
Необходимость идентификации и аутентификации пользователей сервисов безопасности (класс FIA) стала следствием общего требования подотчетности:
отказы аутентификации (FIA_AFL.1.2). При достижении определенного администратором числа неуспешных попыток аутентификации необходимо отказать субъекту в доступе, сгенерировать запись регистрационного журнала и сигнализировать администратору о вероятном нарушении безопасности;определение атрибутов пользователя (FIA_ATD.1.1).
Для каждого пользователя поддерживаются идентификатор, пароль и права доступа (роль). Кроме того, если используются криптографические операции, требуется поддержка открытых и секретных ключей;идентификация (FIA_UID) и аутентификация (FIA_UAU) пользователя. Каждый пользователь должен быть успешно идентифицирован (FIA_UID.2.1) и аутентифицирован (FIA_UAU.2.1) до разрешения любого действия, выполняемого сервисом безопасности от его имени. Необходимо предотвращать применение аутентификационных данных, которые были подделаны или скопированы у другого пользователя (FIA_UAU.3). Следует аутентифицировать любой представленный идентификатор пользователя (FIA_UAU.5.2) и повторно аутентифицировать пользователя по истечении определенного администратором интервала времени (FIA_UAU.6.1). Функции безопасности должны предоставлять пользователю только скрытую обратную связь во время выполнения аутентификации (FIA_UAU.7);связывание пользователь-субъект (FIA_USB.1.1). Соответствующие атрибуты безопасности пользователя нужно ассоциировать с субъектами, действующими от имени этого пользователя.
Управление - важнейший аспект информационной безопасности, а требования управления (класс FMT), несомненно, принадлежат к числу общих:
управление отдельными функциями безопасности (FMT_MOF.1.1). Только администратору позволяется определять режим функционирования, отключения, подключения, модифицировать режимы идентификации и аутентификации, управлять правами доступа, протоколирования и аудита;управление атрибутами безопасности (FMT_MSA). Только администратору предоставляется право изменения подразумеваемых значений, а также опроса, изменения, удаления, создания атрибутов безопасности и правил управления потоками информации (FMT_MSA.1.1). Следует обеспечить присваивание атрибутам безопасности исключительно безопасных значений (FMT_MSA.2.1);управление данными функций безопасности (FMT_MTD). Только администратор должен иметь возможность изменения подразумеваемых значений, опроса, изменения, удаления, очистки, определения типов регистрируемых событий, размеров регистрационных журналов, прав доступа субъектов, сроков действия учетных записей субъектов доступа, паролей, криптографических ключей (FMT_MTD.1.1).
Только он определяет ограничения размеров регистрационных журналов, сроков действия учетных записей субъектов доступа, паролей, криптографических ключей, числа неудачных попыток аутентификации, интервалов бездействия пользователей (FMT_MTD.2.1). При выходе за допустимые границы должны выполняться установленные действия: передача уведомления администратору, блокирование или удаление учетной записи, запрос на смену пароля или ключа и т.д. (FMT_MTD.2.2). Следует обеспечить присваивание данным функциям лишь безопасных значений (FMT_MTD.3.1); отмена (FMT_REV.1). Только уполномоченным администраторам разрешено выполнять отмену атрибутов безопасности, ассоциированных с пользователями. Важные для безопасности полномочия должны отменяться немедленно (FMT_REV.1.2);роли управления безопасностью (FMT_SMR). Поддерживаются следующие роли: уполномоченный пользователь, удаленный пользователь, администратор (FMT_SMR.1.1). Получение ролей удаленного пользователя и администратора может производиться только по явному запросу (FMT_SMR.3.1).
Приватность (класс FPR) - специфический аспект информационной безопасности, однако требование открытости для уполномоченного пользователя носит общий характер:
скрытность (FPR_UNO). Администратору необходимо иметь возможность наблюдать за использованием ресурсов сервиса безопасности (FPR_UNO.4.1).
Собственная защищенность (класс FPT) - важная характеристика любого сервиса безопасности. В число общих входят следующие требования:
тестирование абстрактной машины (FPT_AMT.1). Для демонстрации выполнения предположений безопасности, обеспечиваемых абстрактной машиной, положенной в основу сервиса безопасности, при запуске и/или по запросу администратора выполняется пакет тестовых программ (FPT_AMT.1.1);безопасность при сбое (FPT_FLS). Сервис должен сохранять безопасное состояние при аппаратных сбоях (вызванных, например, перебоями электропитания) (FPT_FLS.1.1);целостность экспортируемых данных (FPT_ITI). Сервис предоставляет возможность верифицировать целостность всех данных в момент их передачи между ним и удаленным доверенным изделием ИТ, выполняет повторную передачу информации, а также генерирует запись регистрационного журнала, если модификации обнаружены (FPT_ITI.1.2);надежное восстановление (FPT_RCV).
Когда автоматическое восстановление после сбоя или прерывания обслуживания невозможно, следует обеспечить переход сервиса в режим аварийной поддержки, позволяющий вернуться к безопасному состоянию (FPT_RCV.2.1). После аппаратных сбоев требуется возврат к безопасному состоянию с использованием автоматических процедур (FPT_RCV.2.2);обнаружение повторного использования (FPT_RPL). Сервис должен обнаруживать повторное использование аутентификационных данных (FPT_RPL.1.1), отказывать в доступе, генерировать запись регистрационного журнала и сигнализировать администратору о вероятном нарушении безопасности (FPT_RPL.1.2); посредничество при обращениях (FPT_RVM). Функции, осуществляющие политику безопасности сервиса, вызываются и успешно выполняются прежде, чем разрешается выполнение любой другой функции сервиса (FPT_RVM.1.1). Компонент FPT_RVM.1 направлен на обеспечение невозможности обхода защитных средств;разделение доменов (FPT_SEP). Функции безопасности должны поддерживать отдельный домен для собственного выполнения, который защищает их от вмешательства и искажения недоверенными субъектами (FPT_SEP.1.1);метки времени (FPT_STM). Функциям безопасности нужно предоставлять надежные метки времени (FPT_STM.1.1);согласованность данных между функциями безопасности (FPT_TDC). Необходима согласованная интерпретация регистрационной информации, а также параметров используемых криптографических операций (FPT_TDC.1.1);согласованность перечисленных функций безопасности при дублировании в пределах объекта оценки (FPT_TRC). Должна обеспечиваться согласованность функций безопасности при дублировании их в различных частях объекта оценки (FPT_TRC.1.1). Когда части, содержащие дублируемые данные, разъединены, она выполняется после восстановления соединения перед обработкой `любых запросов к заданным функциям безопасности (FPT_TRC.1.2);самотестирование функций безопасности (FPT_TST). Для демонстрации правильности работы функций безопасности в процессе нормального функционирования и/или по запросу администратора при запуске периодически должен выполняться пакет программ самотестирования (FPT_TST.1.1), а администратор верифицирует целостность данных (FPT_TST.1.2) и выполняемого кода функций безопасности (FPT_TST.1.3).
Требования класса FTA (доступ к объекту оценки) направлены на обеспечение защищенности от агрессивного потребления ресурсов:
ограничение на параллельные сеансы (FTA_MCS). Ограничение максимального числа параллельных сеансов, предоставляемых одному пользователю (FTA_MCS.1.1). У этой величины должно быть подразумеваемое значение, устанавливаемое администратором (FTA_MCS.1.2);блокирование сеанса (FTA_SSL). По истечении установленного администратором значения длительности бездействия пользователя сеанс работы принудительно завершается (FTA_SSL.3.1);открытие сеанса с объектом оценки (FTA_TSE). Сервис должен быть способен отказать в открытии сеанса, основываясь на идентификаторе субъекта, пароле субъекта, правах доступа субъекта (FTA_TSE.1.1).
Обеспечение защищенного взаимодействия сервисов безопасности в распределенной среде (класс FTP (доверенный маршрут/канал)) - одно из важнейших общих требований:
доверенный канал передачи между функциями безопасности (FTP_ITC). Для связи с удаленным доверенным изделием ИТ функции безопасности должны предоставлять канал, который логически отличим от других и обеспечивает надежную аутентификацию его сторон, а также защиту данных от модификации и раскрытия (FTP_ITC.1.1). Обеим сторонам необходимо иметь возможность инициирования связи через доверенный канал (FTP_ITC.1.2, FTP_ITC.1.3);доверенный маршрут (FTP_TRP). Для связи с удаленным пользователем функции безопасности предоставляют маршрут, который логически отличим от других и обеспечивает надежную аутентификацию его сторон, а также защиту данных от модификации и раскрытия (FTP_TRP.1.1). Пользователю позволяется инициировать связь через доверенный маршрут (FTP_TRP.1.2). Для начальной аутентификации удаленного пользователя и удаленного управления использование доверенного маршрута является обязательным (FTP_TRP.1.3).
Общие элементы политики и цели безопасности
Сформулируем общие положения политики безопасности организации, относящиеся к защитным сервисам:
идентификация и аутентификация всех субъектов доступа;
управление доступом к информационным ресурсам сервиса безопасности;
подотчетность пользователей сервиса безопасности;протоколирование и аудит функционирования сервиса безопасности;обеспечение доступности коммуникационных каналов;обеспечение конфиденциальности и целостности управляющей информации (в частности, при удаленном администрировании);обеспечение целостности аппаратно-программной и информационной частей сервиса безопасности;обеспечение невозможности обхода защитных средств.
Переходя к изложению целей безопасности для объекта оценки, отметим, что их достижение должно способствовать противостоянию угрозам безопасности и реализации предписаний политики безопасности. Для различных сервисов безопасности общими являются нижеперечисленные цели:
подотчетность субъектов и объектов, взаимодействующих с сервисом (необходимое условие достижения этой цели - идентификация и аутентификация взаимодействующих субъектов и объектов, а также протоколирование и аудит выполняемых действий);
автоматизация административных действий, наличие средств проверки корректности конфигурации, как локальной, так и распределенной, наглядный интерфейс администрирования;обеспечение (прежде всего средствами пользовательского интерфейса) корректного использования функций безопасности;предоставление пользователям средств для проверки аутентичности серверов и других партнеров по общению, а также открытых криптографических ключей; реальное осуществление подобных проверок;выявление попыток нарушения политики безопасности, задание реакции на подобные попытки;обеспечение отсутствия вредоносного кода в составе сервиса, в том числе после ликвидации нарушений информационной безопасности;проверка программного кода на наличие подписи доверенной стороны перед его загрузкой в систему;выполнение резервного копирования информации, необходимой для восстановления нормальной работы сервиса;обеспечение безопасного восстановления после сбоев и отказов;обеспечение конфиденциальности и целостности информации при удаленном администрировании сервиса;обеспечение устойчивости средств идентификации и аутентификации к попыткам воспроизведения информации и другим способам реализации маскарада; наличие средств разграничения доступа к компонентам и ресурсам сервиса безопасности;наличие средств контроля целостности компонентов и ресурсов сервиса;наличие средств контроля корректности функционирования сервиса;обеспечение безопасности многократного использования объектов.
Цели безопасности для среды дополняют цели безопасности объекта оценки и состоят в следующем:
обеспечение минимальной достаточности аппаратной и программной конфигурации вычислительной установки, на которой функционирует сервис безопасности;управление физическим доступом к компонентам и ресурсам сервиса;обеспечение невозможности обхода защитных средств;обеспечение достаточной подготовки уполномоченных пользователей сервиса безопасности;проведение в жизнь политики управления данными аутентификации: пользователи меняют эти данные должным образом и с требуемой регулярностью; ликвидация данных аутентификации и привилегий пользователей, лишенных доступа к сервису безопасности;разработка и реализация процедур и механизмов, предохраняющих от вторжения вредоносного программного обеспечения (ПО);разработка и реализация дисциплины доклада о нарушениях информационной безопасности;подготовка пользователей и обслуживающего персонала для противостояния методам морально-психологического воздействия;оперативная ликвидация выявленных уязвимостей.
Общие положения
Мы приступаем к анализу профилей защиты и их проектов, построенных на основе "Общих критериев" и описывающих сервисы безопасности, их комбинации и приложения. В первой части выделяются общие требования, которые могут войти в состав применимого ко всем сервисам функционального пакета, упрощающего разработку и понимание профилей для конкретных сервисов. Анализ профилей защиты позволяет оценить сильные и слабые стороны "Общих критериев", наметить возможные направления новых исследований.
"Общие критерии" в применении к оценке безопасности изделий информационных технологий (ИТ) являются, по сути, метасредствами, задающими систему понятий, в терминах которых должна производиться оценка, но не предоставляющих конкретных наборов требований и критериев, подлежащих обязательной проверке. Эти требования и критерии фигурируют в профилях защиты (ПЗ) и заданиях по безопасности (ЗБ) (см., например, [56], [20], [GTKRRPP]).
Профили защиты, в отличие от заданий по безопасности, носят универсальный характер: они характеризуют определенный класс изделий ИТ вне зависимости от специфики условий применения. Именно официально принятые профили защиты образуют построенную на основе "Общих критериев" (ОК) и используемую на практике нормативную базу в области информационной безопасности (ИБ).
В настоящее время такая база и в мире (см., например, [95], ), и в России только создается. В нашей стране эту работу курирует Государственная техническая комиссия при Президенте РФ (Гостехкомиссия России).
Профили защиты могут характеризовать отдельные сервисы безопасности, комбинации подобных сервисов, реализованные, например, в операционной системе, а также прикладные изделия ИТ, для которых обеспечение информационной безопасности критически важно (пример - смарт-карты).
Нас в первую очередь будут интересовать профили защиты сервисов безопасности, поскольку последние являются универсальными строительными блоками, позволяющими формировать защитные рубежи информационных систем (ИС) различного назначения, разной степени критичности.
В курсе [91] " Основы информационной безопасности" выделены следующие базовые сервисы безопасности:
идентификация и аутентификация;управление доступом;протоколирование и аудит;шифрование;контроль целостности;экранирование;анализ защищенности;обеспечение отказоустойчивости;обеспечение безопасного восстановления;туннелирование;управление.
В силу разных причин не для всех перечисленных сервисов профили защиты разработаны или разрабатываются. Так, традиционные протоколирование и аудит, отказоустойчивость и безопасное восстановление адекватно описываются соответствующими классами функциональных требований "Общих критериев", поэтому формировать на их основе привычные классы защищенности относительно несложно (однако сделать это, разумеется, все же необходимо).
Выделение сервисов туннелирования и управления еще не вошло в общепринятую практику, поэтому пока они обойдены вниманием разработчиков ПЗ.
Наконец, криптография во многих странах (да и в самих "Общих критериях") является "особой точкой" безопасности, поэтому создание профилей защиты для сервисов шифрования и контроля целостности, а также для других сервисов, реализация которых опирается на криптографические механизмы, затруднено по законодательным и/или организационным причинам. (Заметим, что, хотя сложившееся вокруг компьютерной криптографии положение можно объяснить, его никак нельзя признать нормальным.)
Если придерживаться объектно-ориентированного подхода (см., например, курс [91], а также книгу [90]), то целесообразно выделить по крайней мере два уровня в иерархии наследования требований к сервисам безопасности:
общие требования, применимые ко всем или многим сервисам;
частные требования, специфичные для конкретного сервиса.
С точки зрения технологии программирования, "Общие критерии" построены по дообъектной, "библиотечной" методологии. Они предоставляют параметризованные функциональные требования, но не содержат необходимые для практического применения комбинации таких требований или универсальные интерфейсы, допускающие конкретизацию в контексте различных сервисов.Тем не менее, мы попытаемся выделить из разных профилей общие требования к сервисам безопасности, поскольку это упростит охват и понимание всей системы имеющихся профилей защиты.
При изложении общих и частных требований к сервисам безопасности, их комбинациям и приложениям мы будем следовать стандартной структуре профилей защиты (см. выше описание класса требований доверия APE), обращая особое внимание на интересующие нас аспекты:
предположения безопасности;угрозы безопасности;политика безопасности;цели безопасности для объекта оценки;цели безопасности для среды;функциональные требования безопасности;требования доверия безопасности.
Общие предположения безопасности
Предположения безопасности - это часть описания среды, в которой функционирует объект оценки. Они выделяют объект оценки из общего контекста и задают границы рассмотрения. При проведении оценки истинность предположений принимается без доказательства.
Перечислим общие предположения:
использование сервиса безопасности предусматривает наличие уполномоченного пользователя, который выполняет обязанности администратора, обладает достаточной квалификацией, отвечает за нормальное функционирование системы, осуществляет сопровождение сервиса и действует в соответствии с положениями политики безопасности;предусматривается возможность удаленного администрирования сервиса;политика управления данными аутентификации проводится в жизнь, и пользователи меняют эти данные должным образом и с требуемой регулярностью;после лишения пользователя прав доступа к сервису (например, в связи со сменой работы) его данные аутентификации и привилегии ликвидируются;предусматривается резервное копирование информации, ассоциированной с сервисом (такой, например, как значения конфигурационных параметров);аппаратно-программная среда сервиса безопасности является минимально достаточной для нормального функционирования (в частности, обычно отсутствуют средства разработки, а другие возможности модификации среды сведены к минимуму);предполагается физическая защищенность вычислительной установки, поддерживающей сервис безопасности;не допускается возможность обхода узлов сети, на которых функционирует сервисы безопасности;предполагается, что вредоносный код не может иметь подпись доверенной стороны;предполагается, что пользователи должным образом сообщают о случаях нарушения информационной безопасности;предполагается, что пользователи и обслуживающий персонал способны противостоять методам морально-психологического воздействия.
Общие требования доверия безопасности
Требования доверия безопасности, по сравнению с функциональными, представляются более проработанными, поскольку для них определены оценочные уровни доверия (ОУД).
Для большинства областей применения достаточно третьего уровня доверия, но поскольку он достижим при разумных затратах на разработку, его можно считать типовым.
В число требований доверия третьего оценочного уровня входят:
анализ функциональной спецификации, спецификации интерфейсов, эксплуатационной документации;независимое тестирование;наличие проекта верхнего уровня;анализ стойкости функций безопасности;поиск разработчиком явных уязвимостей;контроль среды разработки;
управление конфигурацией.
В принципе реален и четвертый оценочный уровень, который можно рекомендовать для конфигураций повышенной защищенности. К числу дополнительных требований этого уровня относятся:
полная спецификация интерфейсов;наличие проекта нижнего уровня;анализ подмножества реализации;применение неформальной модели политики безопасности;независимый анализ уязвимостей;автоматизация управления конфигурацией.
Вероятно, это самый высокий уровень, который можно достичь при существующей технологии программирования и разумных затратах материальных и временных ресурсов.
Мы завершаем изложение общих требований к сервисам безопасности. На наш взгляд, знакомство с ними необходимо для усвоения и последующего практического использования "Общих критериев".
<
Общие угрозы безопасности
Современные сервисы безопасности функционируют в распределенной среде, поэтому необходимо учитывать наличие как локальных, так и сетевых угроз. В качестве общих можно выделить следующие угрозы:
обход злоумышленником защитных средств;осуществление злоумышленником физического доступа к вычислительной установке, на которой функционирует сервисы безопасности;
ошибки администрирования, в частности, неправильная установка, ошибки при конфигурировании и т.п.;
переход сервиса в небезопасное состояние в результате сбоя или отказа, при начальной загрузке, в процессе или после перезагрузки:
маскарад пользователя (попытка злоумышленника выдать себя за уполномоченного пользователя, например, за администратора; в распределенной среде возможны подмена исходного адреса или воспроизведение ранее перехваченных данных идентификации/аутентификации);маскарад сервера (попытка злоумышленника выдать свою систему за легальный сервер; следствием подобных действий может стать навязывание пользователю ложной информации или получение от него конфиденциальных сведений);использование злоумышленником чужого сетевого соединения или интерактивного сеанса (например, путем доступа к оставленному без присмотра терминалу);несанкционированное изменение злоумышленником конфигурации сервиса и/или конфигурационных данных;нарушение целостности программной конфигурации сервиса, в частности, внедрение троянских компонентов или получение контроля над сервисом;несанкционированный доступ к конфиденциальной (например, регистрационной) информации, в том числе несанкционированное расшифрование закодированных данных;несанкционированное изменение данных (например, регистрационных), включая такие, целостность которых защищена криптографическими методами;несанкционированный доступ к данным (на чтение и/или изменение) в процессе их передачи по сети;
анализ потоков данных с целью получения конфиденциальной информации;перенаправление потоков данных (в частности, на системы, контролируемые злоумышленником);блокирование потоков данных;повреждение или утрата регистрационной, конфигурационной или иной информации, влияющей на безопасность функционирования сервиса (например, из-за повреждения носителей или переполнения регистрационного журнала);
агрессивное потребление злоумышленником ресурсов, в частности, ресурсов протоколирования и аудита, а также полосы пропускания;
сохранение остаточной информации в многократно используемых объектах.
