Предопределенные профили защиты

Область применения

Разд. Предопределенные профили защиты ОК содержит три Профиля Защиты. Два из них были созданы на основе исходных критериев, а еще один разработан для изделия ИТ, которое является относительно новым для процесса оценки безопасности.

Профили, представленные в версии 1.0 ОК, были разработаны авторами ОК как часть процесса проверки достоверности реализации ОК и специальных требований безопасности, содержащихся в ОК. Пока такие оценки не завершены и профили не зарегистрированы для общего использования, они должны трактоваться как предварительные или временные, а их представление в ОК как образец.

Профили "Коммерческая Защита 1" (КЗ1) и "Коммерческая Защита 3" (КЗ3) представляют дальнейшее развитие профилей Федеральных критериев [15] , выполненное с использованием терминологии и конструкций ОК. Профиль КЗ1 ОК предназначен для замены профиля Федеральных критериев CS1 (и, следовательно, класса C2 TCSEC), но не идентичен этим наборам требований. Профиль КЗ3 ОК предназначен для выполнения тех же самых потребностей потребителя, что и профиль Федеральных критериев CS3.

Профиль ОК "Межсетевой Экран" (firewall) — первый член возможного семейства профилей, связанных с межсетевыми экранами (брандмауэрами), предназначен для испытаний изделий, которые интересны для проблематики безопасности ИТ, но не нашли отражения в предыдущих критериях оценки.

Подобное семейство профилей защищенности межсетевых экранов представлено в Руководящем документе Гостехкомиссии России [6] .

Краткий обзор профилей защиты

ПЗ — конструкция ОК, которая предоставляет пользователям возможность описания наборов требований безопасности для многократного использования. Все исходные критерии содержат некоторые наборы стандартизированных требований для функций и гарантий. ПЗ ОК также содержит эти два типа требований вместе с формулировкой задачи безопасности, которую нужно решить для оцениваемого изделия с учетом специфики его использования. Хотя понятие ПЗ было заимствовано из Федеральных Критериев, оно имеет концептуальное начало в TCSEC и структурное начало в ITSEC.

Каждый ПЗ состоит из следующих основных частей:

1. Безопасность окружающей среды — описание проблемы безопасности, которая должна быть решена ОО в соответствии с ПЗ. Окружающая среда описана в терминах ожидаемых угроз, политики безопасности, которая должна быть предписана, и условий использования ОО.
2. Цели безопасности — совокупность формулировок, подводящих итог решаемой задачи безопасности и являющихся базисом для определения требований.
3. Функциональные требования — компоненты из Части 2 ОК, конкретизированные, при необходимости, применением разрешенных действий.
4. Требования гарантии, состоящие из уровня гарантии оценки и усиленные, при необходимости, дополнением компонентов гарантии из Разд. Требования гарантии безопасности ОК.

Профиль защиты — коммерческая защита 1

Представление

Коммерческая защита 1 (КЗ1) — базовая управляемая защита доступа, основанная на дискреционном (избирательном) принципе контроля доступа.

КЗ1 определяет набор основополагающих функций безопасности и гарантий для изделий и систем ИТ.

КЗ1 обеспечивает уровень защиты, который соответствует невраждебному и хорошо управляемому сообществу пользователей, когда требуется защита от угроз безопасности системы из-за небрежности или случайности. КЗ1 не предназначен для применения в обстоятельствах, когда защита требуется против враждебных и изобретательных нарушителей.

Описание объекта оценки

КЗ1 содержит набор требований безопасности для автоматизированных рабочих мест, универсальных многопользовательских операционных систем, систем управления базами данных и других применений. Такие ОО включают один или большее количество процессоров, периферийных и запоминающих устройств, используемых многими пользователями для выполнения ряда функций, требующих управляемого распределенного доступа к данным, хранящимся в системе.

КЗ1 применим к ОО, которые обеспечивают средства для интерактивного взаимодействия с пользователями.

КЗ1 применим также к распределенным системам ИТ, но не предназначен для условий безопасности, которые возникают из потребности распределения ресурсов ИТ внутри сети. Здесь ОО рассматривается как элемент централизованно-управляемой системы, который выполняет обычный набор требований безопасности.

КЗ1 предполагает, что ответственность за сохранение данных, защищенных ОО, может быть делегирована пользователям ОО. Все данные находятся под управлением ОО. Данные сохранены в именованных объектах, и ОО может присоединять к каждому управляемому объекту описание прав доступа к этому объекту.

Всем индивидуальным пользователям назначен уникальный идентификатор, по которому ОО опознает пользователя перед разрешением на выполнение любых дальнейших действий.

ОО, соответствующий КЗ1, предписывает такие средства управления, что доступ к объектам данных может происходить только в соответствии с ограничениями доступа, определенными для этого объекта владельцем или другим уполномоченным пользователем.

Права доступа (например, чтение, запись, выполнение) могут быть назначены объектам данных относительно субъектов (например, пользователей). Если субъекту предоставлен доступ к объекту, то содержание этого объекта может быть свободно используемо, чтобы влиять на другие доступные объекты.

КЗ1 рассматривается как подходящий для защиты информации только одного уровня конфиденциальности (секретности).

Безопасность окружающей среды

Этот раздел идентифицирует аспекты безопасности, которые определяют выбор требований безопасности КЗ1. Это — идентификация угроз для безопасности данных, противостоять которым предназначены требования КЗ1, политика безопасности, которой должен соответствовать ОО, а также физические, персональные и другие аспекты окружения ОО.

Угрозы безопасности

Угрозы, адресованные объекту оценки:

УГРОЗА ДОСТУПА (T.ACCESS). Неуполномоченный человек может получить логический доступ к ОО.

Термин "неуполномоченный человек" определяет тех, кто имеет или может попытаться получить физический доступ к системе и ее терминалам, но не имеет полномочий, чтобы получить логический доступ к ее ресурсам.

Предполагается, что такие "неуполномоченные люди" могут обладать широким диапазоном навыков, способов и побуждений в пределах от любознательного дилетанта с ограниченными техническими знаниями до тех, кто понимает значение информации, хранимой в системе, подготовлен, чтобы сосредоточить значительные усилия для входа в систему и имеет некоторую техническую осведомленность о ее устройстве.

Предполагается, что значение охраняемых ресурсов не обязывает к применению строгих средств управления безопасностью ИТ, а средства физического контроля оповестят ответственных лиц системы о физическом присутствии нападающих внутри контролируемого пространства.

УГРОЗА АВТОРА (T.AUTHOR). Пользователь может получить доступ к ресурсам, право доступа к которым ему не предоставлено.

Термин "пользователь" определяет людей, которым предоставлена некоторая форма законного доступа к системе, но не обязательно ко всем объектам данных.

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

УГРОЗА ДЕФЕКТА (T.FLAW). Нарушения безопасности могут происходить из-за дефектов в ОО.

Пользователи или внешние агенты угрозы могут случайно или путем направленного поиска обнаруживать дефекты в конструкции или применении ОО, что может привести к использованию уязвимости.

УГРОЗА СЛЕДУ (T.TRACE). Относящиеся к безопасности события не могут быть зарегистрированы или не могут быть различимы пользователем.

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

Угрозы, адресованные операционной окружающей среде:

УГРОЗА ФУНКЦИОНИРОВАНИЯ (T.OPERATE). Нарушения безопасности могут происходить из-за некомпетентной администрации при применении ОО.

Пользователи или внешние агенты угрозы могут случайно или путем направленного поиска обнаруживать несоответствия в управлении безопасностью ОО, которые позволяют им получить логический доступ к ресурсам в нарушение любых разрешений, которые они могут иметь.

Потенциальные нарушители могут пытаться разрабатывать методы, при которых неправильно управляемые функции безопасности ОО могут быть обойдены.

УГРОЗА ФИЗИЧЕСКАЯ (T.PHYSICAL). Критические к безопасности части ОО могут быть подвергнуты физической атаке, которая может поставить под угрозу безопасность ОО.

Организационная политика безопасности

ПОЛИТИКА ИЗВЕСТНОГО (P.KNOWN). Законные пользователи ОО должны быть идентифицированы до того, как им предоставлен доступ к ОО.

ПОЛИТИКА ДОВЕРИЯ (P.TRUST). Законным пользователям системы с однажды предоставленным доступом к информации предоставляется возможность последующего контроля над этой информацией.

ПОЛИТИКА ДОСТУПА (P.ACCESS). Права доступа к специфическим объектам данных определены атрибутами, приписанными этому объекту, идентичностью пользователя и атрибутами, связанными с этим пользователем.

ПОЛИТИКА ОТЧЕТА (P.ACCOUNT). Пользователи должны быть ответственны в своих действиях, касающихся безопасности.

Условия безопасного использования

Предполагается, что ОО, соответствующий КЗ1, обеспечит эффективную безопасность только в случае, если он установлен, управляется и используется правильно. Операционная среда должна управляться согласно документации требований гарантий КЗ1 для поставки и действия, а также руководства администратора и пользователя.

Для окружающей среды приняты следующие специфические условия:

Физические условия

УСЛОВИЯ РАЗМЕЩЕНИЯ (A.LOCATE). Ресурсы изделия, включая терминалы, будут размещены в пределах управляемых средств доступа, которые предотвратят несанкционированный физический доступ.

УСЛОВИЯ ЗАЩИТЫ (A.PROTECT). Аппаратные средства и программное обеспечение ОО, критические к нарушению политики безопасности, будут физически защищены от несанкционированного изменения потенциально враждебными посторонними.

Условия для персонала

УСЛОВИЯ УПРАВЛЕНИЯ (A.MANAGE). Будут иметься одна или более компетентных личностей, которым предписано управлять ОО и безопасностью содержащейся в нем информации.

УСЛОВИЯ ДОСТУПА (A.ACCESS). Пользователи обладают необходимыми привилегиями, чтобы обратиться к информации, управляемой ОО.

УСЛОВИЯ СОТРУДНИЧЕСТВА (A.COOP). Пользователи должны выполнять некоторую задачу или группу задач, которые требуют безопасной окружающей среды ИТ.

Условия соединений

КЗ1 не содержит в явном виде требований для сетей или распределенных систем. Однако принимается, что существуют следующие условия соединений:

УСЛОВИЯ РАВЕНСТВА ПОЛОЖЕНИЯ (A.PEER). Любые другие системы, с которыми ОО связывается, находятся под тем же самым управлением и эксплуатируются с теми же самыми ограничениями политики безопасности.

КЗ1 применим к сетевым или распределенным окружающим средам, если только вся сеть функционирует при тех же ограничениях и находится в пределах единой области управления.

УСЛОВИЯ ПОДКЛЮЧЕНИЯ (A.CONNECT). Все связи с периферийными устройствами находятся в пределах действия средств управления доступом.

КЗ1 включает вопросы безопасности, касающиеся манипулирования ОО через законные интерфейсы. Внутренние линии связи для терминалов приняты адекватно защищенными.

Цели безопасности

а) Цели безопасности ИТ:

ЦЕЛЬ ЛОГИЧЕСКАЯ (O.LOGICAL). ОО должен предотвратить логический вход в ОО людям без полномочий доступа к ОО.

ЦЕЛЬ ДОСТУПА (O.ACCESS). ОО должен ограничить пользователям доступ к ресурсам ОО и допускать только к тем, к которым им предоставлен доступ.

ЦЕЛЬ ЗАПИСИ (O.RECORD). ОО должен фиксировать необходимые события, чтобы гарантировать, что существует информация для поддержания эффективного управления безопасности.

ЦЕЛЬ ОТЧЕТА (O.ACCOUNT). ОО должен гарантировать, что все пользователи ОО могут впоследствии быть подотчетными в своих действиях, связанных с безопасностью.

ЦЕЛЬ ПРЕДОТВРАЩЕНИЯ ОБХОДА (O.BYPASS). ОО должен предотвратить незаконное или неправильное функционирование программного обеспечения и пользователей в обход ограничений политики безопасности ОО.

ЦЕЛЬ ОТСУТСТВИЯ ДЕФЕКТОВ (O.FLAW). ОО не должен содержать очевидные дефекты в проекте, реализации или применении.

ЦЕЛЬ УПРАВЛЕНИЯ (O.CONTROL). ОО должен обеспечить все функции и средства, необходимые для поддержки ответственного за управление безопасностью ОО.

б) Цели безопасности не-ИТ:

Принято, что ОО, контролируемый КЗ1, должен быть полным и автономным, а также независимым от любых других изделий для правильного выполнения. Однако некоторые цели относительно общей операционной среды должны быть выполнены, чтобы поддержать возможности безопасности КЗ1.

ЦЕЛЬ УСТАНОВКИ (O.INSTALL). Ответственный за ОО должен гарантировать, что ОО поставлен, установлен, управляется и эксплуатируется способами, которые поддерживают безопасность ИТ.

ЦЕЛЬ ФИЗИЧЕСКАЯ (O.PHYSICAL). Ответственный за ОО должен гарантировать, что части ОО, критические к политике безопасности, защищены от физических воздействий, которые могли бы ставить под угрозу безопасность ИТ.

ЦЕЛЬ ДОВЕРИЯ (O.CREDEN). Ответственный за ОО должен гарантировать, что все мандаты доступа защищены пользователями способом, который поддерживает безопасность ИТ.

ЦЕЛЬ СОЕДИНЕНИЙ (O.CONNECT). Ответственный за ОО должен гарантировать, что никакие соединения с наружными системами или пользователями не могут ставить под угрозу цели безопасности ИТ.

Требования безопасности ОО ИТ

Этот раздел содержит функциональные требования и требования гарантии к ОО, включенные в КЗ1. Требования состоят из функциональных компонент Разд. Требования к функциям безопасности ОК и уровня гарантии оценки, содержащего компоненты гарантии из Разд. Требования гарантии безопасности ОК.

Функциональные требования

В Таб. 2 приведена сводка функциональных требований КЗ1, выраженных в компонентах Разд. Требования к функциям безопасности ОК.

Требования идентификации и аутентификации

FIA_UID.1.1 — ФБ должна идентифицировать каждого пользователя перед выполнением любых действий, требуемых пользователем.

FIA_UAU.1.1 — ФБ должна подтвердить подлинность требуемой идентичности любого пользователя до выполнения любых функций для пользователя.

FIA_ATD.1.1 — ФБ должна обеспечить для каждого пользователя набор признаков безопасности, необходимый, чтобы предписать ПФБ.

FIA_ATA.1.1 — ФБ должна обеспечить способность инициализации признаков пользователя с обеспеченными стандартными значениями.

FIA_ADP.2.1 — ФБ должна защитить от несанкционированного наблюдения, модификации и разрушения необработанную форму опознавательных данных всегда во время их хранения в ОО.

Требования аудита

FAU_GEN.1.1 — ФБ должна быть способна произвести запись аудита следующих контролируемых событий:

1. Запуск и завершение контролируемых процессов;
2. Все контролируемые события для базового уровня аудита, определенные во всех функциональных компонентах, включенных в КЗ1, а именно:
   • [FIA_UID] — Все попытки использовать механизм идентификации пользователя, в том числе, при условии идентичности пользователя. Начало запроса должно быть включено в контрольную запись.
   • [FIA_UAU] — Любое использование опознавательного механизма. Начало запроса должно быть включено в контрольную запись.
   • [FIA_ATA] — Все запросы на использование функции администрирования признака пользователя, включая идентификацию признаков пользователя, которые были изменены.
   • [FIA_ADP] — Все запросы к данным аутентификации пользователя.
   • [FAU_PRO] — Любая попытка читать, модифицировать или уничтожить трассу контроля.
   • [FAU_MGT] — Любая попытка выполнять операции с трассой контроля.
   • [FAU_SEL] — Все модификации конфигурации аудита, которые происходят во время работы набора контрольных функций.
   • [FDP_ACF] — Все запросы для выполнения операции на объекте, охваченном ПФБ, включая введение объектов в адресное пространство пользователя и стирание объектов.
   • [FDP_ACI] — Любые изменения или отмена стандартных признаков объекта, включая идентификацию стандартных признаков объекта, которые были изменены или отменены.
   • [FDP_SAM] — Все попытки модифицировать признаки безопасности, включая идентификацию объекта попытки изменения и новые значения модифицированных признаков безопасности.
   • [FPT_AMT] — Выполнение тестирования основной машины и результаты проверок.
   • [FPT_TSA] — Использование относящейся к безопасности административной функции.
3. [назначение: другие контролируемые события]

FAU_GEN.1.2 — ФБ должна в пределах каждой записи аудита фиксировать по крайней мере следующую информацию:

а) Дата и время события, тип события, идентичность субъекта и результат (успех, неудача) события.

б) Для каждого типа контролируемых событий [назначение: другая, относящаяся к аудиту, информация].

FAU_GEN.2.1 — ФБ должна быть способна связать любое контролируемое событие с идентичностью пользователя, который явился причиной события.

FAU_STG.1.1 — ФБ должна обеспечить хранение полученных записей аудита в постоянной трассе контроля.

FAU_PRO.1.1 — ФБ должна разрешать доступ к трассе контроля только уполномоченному администратору.

FAU_MGT.1.1 — ФБ должна обеспечивать уполномоченному администратору возможность создавать, удалять и освобождать трассу контроля.

FAU_SEL.1.1 — ФБ должна быть способна включать или исключать контролируемые события из набора ревизуемых событий на основе следующих признаков:

а) идентичность пользователя;

б) признаки объекта.

FAU_SEL.2.2 — ФБ должна обеспечить уполномоченному администратору возможность выбирать в любое время в течение действия ОО события, которые должны контролироваться.

Требования администрирования

FPT_TSA.1.1 — ФБ должна отличать относящиеся к безопасности административные функции от других функций.

FPT_TSA.1.2 — Набор относящихся к безопасности административных функций ФБ должен включать все функции, необходимые чтобы инсталлировать, конфигурировать и управлять ФБ; как минимум, этот набор должен включать [назначение: список административных услуг, которые должны быть минимально обеспечены].

FPT_TSA.1.3 — ФБ должна ограничить возможность выполнять относящиеся к безопасности административные функции специально уполномоченными пользователями.

FPT_TSA.1.4 — ФБ должна быть способна выделить пользователей, уполномоченных для административных функций, из всех пользователей ОО.

FPT_TSU.1.1 — ФБ должна предписать проверки правильности входных значений относящихся к безопасности административных функций как описано в Руководстве администратора.

Требования управления доступом

FDP_ACC.1.1 — ФБ должна предписать политику дискреционного контроля доступа для:

а) пользователей;

б) субъектов, действующих в защиту пользователей;

в) других именованных субъектов;

г) именованных объектов, содержащих данные пользователя;

д) [назначение: операции между субъектами и объектами, охваченными управлением доступа].

FDP_ACF.1.1 — ФБ должна предписать политику дискреционного контроля доступа к объектам, основанную на следующих признаках субъекта:

а) идентичность пользователя: идентичность пользователя по признакам пользователя;

б) список группы: нуль или большее количество тождеств из группы признаков пользователя;

в) [назначение: тип субъекта: характер (природа) субъекта].

ФБ должна предписать политику дискреционного контроля доступа к объектам, основанную на следующих признаках объекта:

а) список контроля доступа: список групп и пользователей со списком (для каждой группы или пользователя) специфических операций, разрешенных на объекте каждой группе или пользователю;

б) [назначение: тип объекта: характер управляемого объекта].

FDP_ACF.1.2 — ФБ должна предписать следующие правила, чтобы определить, разрешается ли действие между контролируемыми субъектами и объектами:

а) если идентичность субъекта пользователя или любой элемент списка группы субъектов упомянуты в списке контроля доступа к объекту, то субъекту будут предоставлены разрешения доступа, упомянутые в списке контроля доступа;

б) если ни идентичность субъекта пользователя, ни любой элемент списка группы субъектов не упомянуты в списке контроля доступа к объекту, то доступ будет предоставляться применением [назначение: правила доступа по умолчанию].

в) если ознакомление со списком контроля доступа дает неоднозначный результат, то эта неоднозначность должна быть разрешена применением [назначение: правила для консультации по списку контроля доступа].

Если различные правила относятся к различным субъектам и объектам, то должны быть представлены все эти правила.

FDP_ACI.1.1 — ФБ должна предписать политику стандартных (заданных по умолчанию) признаков, чтобы обеспечить разрешающие или стандартные значения для признаков безопасности объекта, которые используются, чтобы предписать ПФБ.

FDP_ACI.1.2 — ФБ должна предоставить возможность спецификации альтернативных начальных значений для отмены стандартных значений после создания объекта.

FDP_SAM.2.1 — ФБ должна предписать следующие правила доступа, чтобы обеспечить уполномоченным пользователям возможность модифицировать признаки объекта:

а) Разрешение доступа к объекту пользователям, не обладающим таким разрешением, может быть назначено только уполномоченными пользователями.

б) [Назначение: дополнительные правила для изменения признаков объекта].

FDP_RIP.1.1 — ФБ должна гарантировать, что после распределения ресурсов по объектам, которые содержат данные пользователей, любое предыдущее информационное содержание (включая зашифрованные представления) недоступно.

Защита ФБ и посредничество ссылок

FPT_SEP.1.1 — ФБ должна для собственного выполнения поддерживать область безопасности, которая защищает ее от вмешательства и подделки недоверенными субъектами:

а) Передачи между областями ФБ и не-ФБ должны управляться так, чтобы произвольный вход в область ФБ или выход из области ФБ были невозможны.

б) Значения ссылок пользовательских или прикладных параметров, относящихся ФБ, должны быть согласованы с адресным пространством и значениями, ожидаемыми ФБ.

в) Разрешения ссылок к объектам (и/или к данным не-ФБ) в качестве параметров ФБ должны быть согласованы с разрешениями, требуемыми ФБ.

г) Ссылки на объекты ФБ, используемые функциями изоляции ФБ, должны быть установлены ФБ.

д) Область ФБ должна иметь все признаки пользователя и объекта.

FPT_SEP.1.2 — ФБ должна предписать разделение между областями безопасности субъектов в ОКФБ.

FPT_RVM.1.1 — ФБ должна гарантировать, что функции осуществления ПФБ вызываются и действуют прежде, чем произойдет любое, связанное с безопасностью, действие:

а) ФБ должна обеспечить все ссылки на субъекты, объекты, ресурсы и функции ФБ.

б) Посредничество должно гарантировать, что все подчиненные ссылки объекта направлены функциям политики дискреционного контроля доступа.

в) Посредничество должно гарантировать, что все ссылки ресурсов обращаются к функциям защиты остаточной информации.

г) Ссылки, исходящие от привилегированных субъектов, должны быть установлены в соответствии с атрибутами, определенными для этих субъектов.

FPT.AMT.1.1 — ФБ должна обеспечить уполномоченному администратору возможность проверить правильность действия относящихся к безопасности функций, поддержанных аппаратными средствами и программируемым оборудованием, на котором функционирует ОО.

Требования гарантированности

ОО должен выполнить требования уровня гарантии оценки УГО3.

Прикладные замечания

Этот раздел используется, чтобы обеспечить дополнительную информацию, которая будет полезна автору ЗБ при интерпретации требований ОК, особенно в части действий, которые не были завершены на уровне ПЗ.

Профиль защиты — коммерческая защита

Версия 1.0 профиля защиты КЗ3 пока еще не завершена до конца, поэтому здесь подробно не рассматривается. Выбранные компоненты функциональных требований являются приемлемым набором для КЗ3 и согласуются с соответствующим профилем Федеральных критериев. Однако большое количество "операций" на выбранных функциональных требованиях остается незавершенным и, следовательно, не отражает все подробности требований, содержащихся в Федеральных критериях. Ожидается, что следующая версия этого ПЗ полностью выполнит поставленную цель.

Представление

Коммерческая защита 3 (КЗ3) — защита доступа, основанная на функциях(ролях), аналоге мандатного принципа доступа.

КЗ3 использует компоненты требований ОК для моделирования профиля КЗ3 из Федеральных критериев. КЗ3 определяет усиленный набор функций безопасности и гарантий для изделий ИТ, функционирующих в критических средах, где доступ к программам, протоколам и информации должен быть ограничен согласно назначенной организационной функции пользователей.

КЗ3 обеспечивает мощные механизмы аутентификации и средства администрирования.

Изделия, соответствующие КЗ3, как предполагается, будут использоваться в критических коммерческих и государственных окружающих средах, где отказ (сбой) системы не должен приводить к нарушению безопасности и требуется относительно высокая степень доверия

Изделия, соответствующие КЗ3, предназначены для обработки критической несекретной или одноуровневой секретной информации.

Описание объекта оценки

КЗ3 определяет набор требований безопасности для объектов оценки, которые включают универсальные многопользовательские операционные системы, системы управления базами данных и прикладные программы.

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

ОО КЗ3 являются стойкими к нехватке ресурса и отказу (сбою) системы, обеспечивая восстановление разнообразных свойств системы и распределения ресурсов.

Типичные представители для КЗ3 — вычислительные системы рабочей группы или предприятия с необходимостью высоких требований целостности данных с предоставлением санкционированного доступа к компьютерным системам как местным, так и удаленным пользователям.

КЗ3 применима к ОО, которые обеспечивают средства для интерактивного взаимодействия с пользователями. КЗ3 также применима к ОО, включающим сетевые функции, но не содержащим никаких специфических сетевых требований. Работа с сетями охвачена лишь в объеме, когда они могут рассматриваться как часть централизованно-управляемой системы, которая выполняет общий набор требований безопасности.

КЗ3 предполагает, что организация — владелец всех данных. Все данные централизованно управляются операционной системой. Данные сохраняются в именованных объектах, и операционная система может связаться с каждым объектом с точно деструктурированным описанием прав доступа к этому объекту.

Всем индивидуальным пользователям назначен уникальный идентификатор. Этот идентификатор пользователя поддерживает индивидуальную ответственность. ОО опознает требуемое тождество пользователя перед разрешением на выполнение любых дальнейших действий. КЗ3 поддерживает многократные опознавательные механизмы.

ОО, соответствующий КЗ3, предписывает такие средства управления, что доступ к объектам данных и разрешенным действиям относительно них может происходить только в соответствии с ограничениями доступа, основанными на функциях (ролях), определенных администратором системы. Администратор системы сопоставит каждого пользователя с одним или большим количеством функций, которые ОО использует, чтобы принимать решения доступа. Полномочие для принятия функции может предоставляться и отменяться администратором системы. Набор операций распределен каждой функции администратором системы. Каждая операция включает действие или процедуру преобразования и набор связанных элементов данных.

КЗ3 поддерживает политику разделения обязанностей, при которой функции не могут находиться в противоречии. Никакому отдельному индивидууму не разрешено выполнять все части транзакции, представляемой набором операций (действий) с наборами данных объектов. Эта возможность может быть предоставлена только администратору системы, чтобы предотвратить появление "привилегированного пользователя" или "суперпользователя" с наличием слишком широкого набора привилегий, когда необходим только поднабор.

ОО, соответствующий КЗ3, гарантирует обеспечение эффективных мер безопасности только при правильной установке, управлении и использовании. Операционная окружающая среда должна управляться способом, который поддерживает цели безопасности КЗ3. В частности, это позволяет определить, что оцененный ОО был получен без изменения, что безопасное состояние было обеспечено во время модификации и что безопасное состояние поддерживается в течение эксплуатации.

Безопасность окружающей среды

По сравнению с КЗ1 в КЗ3 специализированы вопросы организационной политики безопасности, расширен список потенциальных угроз. Дополнительно включены:

УГРОЗА НЕДОСТУПНОСТИ (T.DENY). Пользователям может быть заблокирована возможность доступа к ресурсам ОО.

Снижение доступности ресурса системы может происходить от ряда причин, связанных с умышленными и неумышленными происшествиями. Управление ресурсами системы, пользователи и внешние агенты угрозы могут быть причинами снижения производительности или недоступности ресурсов, особенно дискового пространства, памяти и центрального процессора.

УГРОЗА РАЗРУШЕНИЯ (T.CRASH). Безопасное состояние ОО может быть поставлено под угрозу в случае аварийного отказа системы.

Аварийный отказ системы может происходить при неадекватных механизмах восстановления при запуске системы. Объекты данных пользователя и контрольная информация могут при этом изменяться или теряться. Система и прикладное программное обеспечение могут быть повреждены.

УГРОЗА ВМЕШАТЕЛЬСТВА (T.TAMPER). Возможно вмешательство в механизмы защиты ОО.

Программное обеспечение ОО и данные, которые используются для обеспечения безопасности ОО, могут быть обойдены или скомпрометированы, нарушая целостность механизмов осуществления и исключая их способность управлять безопасностью ОО.

УГРОЗА НЕ ЗАМЕТИТЬ (T.OBSERVE). Могут происходить события в действии ОО, которые ставят под угрозу безопасность ИТ, но которые не могут быть легко отмечены.

Эта угроза связана с человеческим фактором в отношении способности администратора или пользователя обнаружить ситуацию, которая воздействует на состояние безопасности ОО. ОО может использоваться способом, который является опасным, но который администратор или пользователь приемлет и неправильно доверяет его безопасности.

УГРОЗА РАЗРАБОТКИ РОЛИ (T.ROLEDEV). Разработка и назначение функций (ролей) пользователя могут быть выполнены способом, который подрывает безопасность.

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

Цели безопасности

В целях безопасности, по сравнению с КЗ1, добавлены:

Требования безопасности ОО ИТ

Этот раздел содержит функциональные требования и требования гарантии, которым должны удовлетворять ОО, соответствующий КЗ3. Они состоят из функциональных компонентов Разд. Требования к функциям безопасности ОК и уровня гарантии оценки, содержащего компоненты гарантии из Разд. Требования гарантии безопасности .

Функциональные требования

В Таб. 3 приведена сводка функциональных требований КЗ3, выраженных в функциональных компонентах ОК. Детализация компонентов на уровне функциональных элементов и действий с ними в данном обзоре для краткости не приводится.

Как видно из Таб. 3 , функциональные требования КЗ3 по сравнению с КЗ1 значительно расширены и усилены.

Требования гарантированности

Требования гарантированности для КЗ3 включают уровень гарантии оценки УГО4 и дополнительные компоненты гарантии из Разд. Требования гарантии безопасности ОК, а именно: ALC_FLR.2 (Процедуры сообщения о дефекте) и ADO_DEL.2 (Обнаружение модификации).

Профиль защиты межсетевого экрана с фильтром пакета на сетевом/транспортном уровне

Представление

Назначением этого профиля защиты является определение функций и гарантий, применимых к наиболее коммерчески доступным МЭ.

Цель установки межсетевого экрана состоит в том, чтобы обеспечить защиту, управляемый и контролируемый доступ к услугам как изнутри, так и снаружи частной сети организации, разрешая и/или отвергая поток пакетов через МЭ.

Описание объекта оценки

Типичное расположение, включающее межсетевой экран, показано на Рис. 2 . МЭ установлен между двумя сетями так, чтобы трафик между ними был направлен через МЭ. МЭ может таким образом обеспечивать управление доступом к пакетам, пересылаемым между сетями. МЭ — вычислительное устройство (например, маршрутизатор или главный компьютер) который используется, чтобы физически отделить одну сетевую область от другой.

Маршрутизаторы могут управлять движением на сетевом/транспортном уровне, избирательно разрешая или отвергая движение, основанное на адресе источника/адресата или порта. Главные компьютеры могут управлять движением на прикладном уровне. Данный профиль защиты адресован понятию фильтрующего пакета на сетевом/транспортном уровне. Примером может быть МЭ, который выполняет функции безопасности, основанные на информации, имеющейся в IP и TCP заголовках (например, исходного адреса и порта).

Безопасность окружающей среды

МЭ, соответствующие данному профилю защиты, предназначены для использования в коммерческих окружающих средах, желающих иметь гибкую политику управления доступом, некоторую возможность аудита и минимальный уровень гарантии в функциях безопасности.

Угрозы безопасности

Этот профиль защиты достаточен для относительно благоприятных физических и эксплуатационных окружающих сред, где угроза злонамеренных нападений, нацеленных на обнаружение пригодных для использования уязвимостей, рассматривается как умеренная. Таким образом основные угрозы, которым надо противостоять — это ошибки или случайные попытки нарушить политику безопасности, предписанную ФБ.

а) Угрозы, адресованные ОО

б) Угрозы, адресованные операционной окружающей среде

Возможные угрозы, приведенные ниже, не адресованы МЭ.

Им нужно противостоять процедурным способом или принять как потенциальные риски системы.

Условия безопасного использования

а) Физические условия

б) Условия для персонала

в) Условия соединений

Цели безопасности

а) Цели безопасности ИТ

Решение предоставлять или отвергать возможность пакету пройти через МЭ основано на признаках субъекта, объекта, а также сгенерированной МЭ информации о состоянии и административно конфигурируемых правилах управления доступом.

Так как МЭ функционирует только на уровне пакета, не может быть никаких человеческих пользователей МЭ в общепринятом смысле слова "пользователь". Любая идентификационная и опознавательная информация была бы частью содержания пакета и, следовательно, вне ВКФБ. Персонал администрации непосредственно обращается(получает доступ) к МЭ через пульт и опознается через процедуры, которые предоставляют возможность разрешения физически обратиться (получить доступ) к МЭ.

Зато понятие механический пользователь применяется. Механический пользователь (идентифицированный как TCP/IP порт на другой машине) представляется в ФБ как субъект или объект. Субъекты и объекты идентифицированы информацией об источнике и адресате, которую содержит пакет. Исключая уполномоченных администраторов, каждая ссылка на пользователя относится к механическому пользователю на TCP/IP порте, как идентифицировано в пакете.

Эта цель ограничивает доступ к МЭ уполномоченным административным персоналом и дает только им способность конфигурировать МЭ посредством приложенного пульта. Эта цель близко связана и поддерживает ЦЕЛЬ АУДИТА.

МЭ должен предостеречь себя от атаки внешними объектами. Это включает защиту выполнимого кода так же, как и защиту пакетов, фактически обрабатываемых. Защита контролируемых данных также вписывается в этот перечень.

Трасса контроля необходима, чтобы определить, имеются ли продолжающиеся попытки обойти реализацию политики безопасности, или, если имеются, где они должны быть пресечены. Данные контроля должны быть не только собраны, но и обозримы, чтобы облегчить работу. Трасса контроля должна быть достаточно защищена и область потенциальных потерь известна так, чтобы административному персоналу могли обеспечиваться обоснованные решения безопасности.

Эта цель специально адресована части требований гарантированности данного ПЗ.

б) Цели безопасности не-ИТ

МЭ принят полным и автономным, то есть независимым от любых других изделий, чтобы функционировать правильно. Однако некоторые цели относительно среды должны быть выполнены, чтобы поддерживать возможности безопасности МЭ.

Необходимо убедиться, что поставленный МЭ — идентичная копия оцененного. В течение установки все службы безопасности, необходимые для действий поддержания безопасности, должны быть задействованы. Управление и операции должны также поддержать безопасность, например, обучением пользователя и мотивацией. Это близко связано с угрозой враждебного персонала администрации.

Требования безопасности ОО ИТ

Функциональные требования

В Таб. 4 приведена сводка функциональных требований ПЗ МЭ, выраженная в функциональных компонентах ОК.

Требования аудита

FAU_GEN.1.1 — ФБ должна быть способна произвести запись аудита следующих контролируемых событий:

а) запуск и завершение контролируемых процессов;

б) все контролируемые события для минимального уровня аудита, определенные во всех функциональных компонентах, включенных в ПЗ (см. Таб. 5 );

в) для всех функциональных компонентов, включенных в ПЗ/ЗБ [назначение: другое контролируемое событие, определенное разработчиком ЗБ].

FAU_GEN.1.2 — ФБ должна в пределах каждой записи аудита фиксировать по крайней мере следующую информацию:

а) Дата и время события, тип события, идентичность субъекта и результат (успех, неудача) события.

б) Для каждого типа контролируемых событий функциональных компонентов включенных в ПЗ, должны быть включены признаки, приведенные в скобках в Таб. 5 .

FAU_MGT.1.1 — ФБ должна обеспечить уполномоченному администратору возможность создавать, удалять и освобождать трассу контроля.

FAU_POP.1.1 — ФБ должна быть способна генерировать понятное человеку представление любых данных аудита, сохраняемых в постоянной трассе контроля.

FAU_PRO.1.1 — ФБ должна ограничить доступ к трассе контроля уполномоченным администратором.

FAU_SAR.1.1 — ФБ должна обеспечивать инструментальные средства обзора аудита, способные просмотреть данные контроля.

FAU_SAR.1.2 — ФБ должна ограничить использование инструментальных средств просмотра аудита уполномоченным администратором.

FAU_SAR.3.1 — ФБ должна обеспечить инструментальные средства просмотра аудита, способные выполнить поиск и сортировку данных контроля, основанные на [назначение: множество критериев с логическими связями, определенное разработчиком ЗБ].

FAU_STG.3.1 — ФБ должна хранить полученные записи аудита в постоянной трассе контроля.

FAU_STG.3.2 — ФБ должна ограничить число потерь контрольных записей и поэтому контролировать переполнение памяти, отказ и нападение.

В случае переполнения памяти аудита, ФБ должна быть способна к [выбор: игнорирование или предотвращение, как определит разработчик ЗБ] возникновения контролируемых действий, за исключением предпринимаемых уполномоченным администратором.

Требования идентификации и аутентификации

FIA_ADA.1.1 — ФБ должна обеспечить функции для инициализации данных аутентификации пользователя, связанных с паролями.

FIA_ADA.1.2 — ФБ должна ограничить использование этих функций уполномоченным администратором.

FIA_ADP.1.1 — ФБ должна защитить от несанкционированного наблюдения, модификации и разрушения данные аутентификации, которые хранятся в ОО.

FIA_ATA.1.1 — ФБ должна обеспечить способность инициализации признаков пользователя с обеспеченными стандартными значениями (по умолчанию).

FIA_ATD.1.1 — ФБ должна обеспечить каждому пользователя набор признаков безопасности, необходимых, чтобы предписать ПФБ.

FIA_UAU.1.1 — ФБ должна подтвердить подлинность требуемой идентичности любого пользователя до выполнения для него любых функций.

FIA_UID.1.1 — ФБ должна идентифицировать каждого пользователя перед выполнением любых действий, требуемых пользователем.

FIA_USB.1.1 — ФБ должна сопоставить соответствующие признаки безопасности пользователя с субъектами, действующими от имени этого пользователя.

Защита ФБ

FPT_RVM.1.1 — ФБ должна гарантировать, что функции осуществления ПФБ вызываются и воздействуют прежде, чем произойдет любое, связанное с безопасностью, действие.

FPT_SEP.1.1 — ФБ должна поддержать область безопасности для собственного выполнения, которая защищает ее от вмешательства и подделки недоверенными субъектами.

FPT_SEP.1.2 — ФБ должна предписать разделение между областями безопасности в области контроля ФБ.

Требования администрирования

FPT_TSA.1.1 — ФБ должна отличать относящиеся к безопасности административные функции от других функций.

FPT_TSA.1.2 — Набор относящихся к безопасности административных функций ФБ должен включать все функции, необходимые, чтобы инсталлировать, конфигурировать и управлять ФБ; как минимум, этот набор должен включать следующие услуги:

а) сопровождение признака безопасности администратором, включая заданную по умолчанию установку и отмену;

б) сопровождение функции аудита, включая запуск и завершение;

в) создание, стирание и освобождение трассы контроля;

г) контроль инструментальных средств обзора;

д) инициализация данных аутентификации пользователя;

е) изменение и отображение параметров управления потоком данных МЭ (параметров управления доступом);

ж) [назначение: другие услуги по определению разработчика ЗБ].

FPT_TSA.1.3 — ФБ должна ограничить возможность выполнять относящиеся к безопасности административные функции специально уполномоченными пользователями.

FPT_TSA.1.4 — ФБ должна быть способна выделить набор пользователей, уполномоченных для административных функций, из набора всех пользователей МЭ.

FPT_TSM.1.1 — ФБ должна обеспечить уполномоченным администраторам возможность устанавливать и модифицировать следующие параметры конфигурации ФБ:

а) параметры управления доступом;

б) заданные по умолчанию признаки пользователя;

в) правила аудита;

г) [назначение: другие, определенные разработчиком ЗБ].

FPT_TSM.1.2 — ФБ должна обеспечить уполномоченным администраторам возможность:

а) сопровождения признака безопасности, включая заданную по умолчанию установку и отмену;

б) управления функцией аудита, включая запуск, завершение;

в) создания, стирания и освобождения трассы контроля;

г) просмотра данных аудита;

д) инициализации данных аутентификации пользователя;

е) управления признаками пользователя, субъекта и объекта;

ж) изменения и отображения параметров управления потоком данных МЭ (параметров управления доступом);

з) управления интерфейсами;

и) [назначение: предоставление возможности подключения и отключения набора периферийных устройств, определенных разработчиком ЗБ].

Управление доступом

FDP_ACC.2.1 — ФБ должна предписать политику потока МЭ по субъектам и объектам и всем действиям среди субъектов и объектов, охваченных политикой потока МЭ (например, операция записи).

FDP_ACC.2.2 — ФБ должна гарантировать, что все действия между любым субъектом и любым объектом в пределах области контроля ФБ охвачены политикой потока МЭ.

FDP_ACF.2.1 — ФБ должна предписать политику потока МЭ к объектам, основанную на следующем:

а) сетевая идентификация субъекта и объекта;

б) идентичность субъекта;

в) идентичность объекта;

г) время.

FDP_ACF.2.2 — ФБ должна предписать следующие правила, чтобы определить, разрешается ли действие между управляемыми субъектами и управляемыми объектами:

а) если время находится между периодом, определенным уполномоченным администратором;

б) субъект или объект имеет внутреннюю сетевую идентификацию, а второй имеет внешнюю сетевую идентификацию;

в) субъект связан с внутренней сетью и порт, с которым субъект связан, находится во внутренней сети;

г) доступ субъекта к идентифицированному объекту разрешен;

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

FDP_ACF.4.1 — ФБ должна предписать политику потока МЭ, чтобы обеспечить способность явно предоставить доступ на основе значений признаков безопасности субъектов и объектов.

FDP_ACF.4.2 — ФБ должна предписать политику потока МЭ, чтобы обеспечить способность явно запретить доступ на основе значений признаков безопасности субъектов и объектов.

FDP_ACI.1.1 — ФБ должна предписать политику потока МЭ, обеспечивающую ограничительные стандартные значения для признаков безопасности объекта, которые используются, чтобы предписать политику потока МЭ.

FDP_ACI.1.2 — ФБ должна позволить спецификацию альтернативных начальных значений для стандартных значений после того, как объект создан.

FDP_ETC.1.1 — ФБ должна предписать политику потока МЭ для информации, выводимой из области контроля ФБ через функцию, которая не обеспечивает признаки безопасности при передаче информации.

FDP_ITC.1.1 — ФБ должна предписать политику потока МЭ для информации, вводимой из-за области контроля ФБ через функцию, которая не обеспечивает надежные признаки безопасности.

FDP_ITC.1.2 — ФБ должна позволить уполномоченному пользователю присваивать признаки безопасности полученной информации.

FDP_ITC.1.3 — ФБ должна обеспечить следующие правила, когда информация, управляемая политикой потока МЭ, вводится снаружи области контроля ФБ:

а) идентичность пользователя устанавливается по информации создателя в пакете;

б) идентичность объекта устанавливается по адресу, обозначенному в пакете;

в) сеть субъекта устанавливается по порту, на котором информация была получена;

г) сеть объекта устанавливается по порту, с которым адресат связан.

FDP_SAM.1.1 — ФБ должна предписать политику потока МЭ, чтобы обеспечить уполномоченных администраторов способностью изменить [назначение: параметры управления потоком данных МЭ, определяемые разработчиком ЗБ].

FDP_SAQ.1.1 — ФБ должна предписать политику потока МЭ, чтобы обеспечить уполномоченного администратора способностью запросить значения [назначение: параметры управления потоком данных МЭ, определяемые разработчиком ЗБ].

Требования гарантированности

Требования гарантированности включают уровень гарантии УГО1.

Профиль Защиты ОК по сути является аналогом классов безопасности "Оранжевой книги", классов защищенности РД ГТК РФ, но базируется на значительно более полной и систематизированной совокупности компонентов требований безопасности. Для сравнения: в ОК — 256 компонентов функциональных требований и требований гарантированности, в TCSEC — 59 компонентов, в РД ГТК для СВТ — 51 компонент, для АС — 67 компонентов.

Каждый компонент содержит новые или усиленные требования.

Для иллюстрации в таблице 3 Приложения приведена сравнительная характеристика требований пятого класса защищенности РД ГТК РФ для СВТ и соответствующего Профиля Защиты ОК (условно ПЗ-5).

Количество стандартизованных Профилей Защиты в ОК не ограничено. Но все они должны отвечать соответствующим требованиям и, прежде чем быть включенными в международный регистр, пройти процедуры регистрации, которые будут определены в ОК ( Разд. Заключение ).

Требования гарантии безопасности	Содержание	Заключение