Приложение D (рекомендуемое). Рабочий пример: профиль защиты и задание по безопасности для межсетевого экрана

Приложение D
(рекомендуемое)

Рабочий пример: профиль защиты и задание по безопасности для межсетевого экрана

D.1 Введение

В настоящем приложении проиллюстрировано применение руководства, содержащегося в разделах 7 - 13, посредством рабочего примера применительно к межсетевому экрану.

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

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

a) идентификация операционной системы, под управлением которой работает межсетевой экран, и аппаратной платформы;

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

D.3 Среда безопасности объекта оценки

D.3.1 Предположения безопасности

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

a) межсетевой экран должен быть универсальным посредником, так как существует возможность обойти его (межсетевой экран);

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

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

D.3.2 Угрозы

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

Ниже приведен пример угрозы, которой должен противостоять межсетевой экран:

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

Формулировка угрозы оперирует следующими понятиями:

a) источник угрозы - нарушитель из потенциально враждебной (внешней) сети;

b) активы ИТ, подверженные нападению, - это хосты (узлы) или другие сервисы частной сети;

c) форма нападения - использование недостатков реализации сервисов.

Хотя большинство угроз, с которыми сталкивается межсетевой экран, связано с нарушителями из враждебной сети, существуют угрозы, когда нарушитель может находиться как во враждебной, так и в частной сети:

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

Идентифицированные угрозы, которым ОО не противостоит, отражают практические ограничения в отношении межсетевого экрана. Например:

a) определенные способы атак, применяемые нарушителями из враждебной сети, которым ОО не противостоит, такие как перехват сеанса и поиск (сниффинг) данных;

b) частная сеть может стать уязвимой для атак в результате действий злоумышленников из частной сети;

c) уязвимость частной сети со стороны вирусов, которые могут содержаться во входящем трафике - это также угроза, для противостояния которой межсетевой экран не предназначен;

d) частная сеть может стать уязвимой для атак в результате действия или бездействия администратора межсетевого экрана;

e) частная сеть может стать уязвимой для атак в результате непосредственной физической атаки на межсетевой экран.

Ниже приведена возможная (заслуживающая особого внимания) угроза для межсетевого экрана, выполняющего роль шлюза прикладного уровня (далее - МЭ прикладного уровня):

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

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

D.3.3 Политика безопасности организации

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

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

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

D.4.1 Цели безопасности для объекта оценки

Цели безопасности для межсетевого экрана можно сформулировать следующим образом:

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

b) Цель О2 - к межсетевому экрану прикладного уровня может быть предъявлено требование организовать серверы полномочий (сервер полномочий перехватывает попытки соединений с серверами и затем сам посылает запросы на нужные серверы от имени пользователей; когда сервер возвращает информацию, сервер полномочий пересылает ее пользователю) в целях противостояния атакам, основанным на недостатках реализации прикладных сервисов.

c) Цель О3 - аналогично может существовать требование аутентификации полномочий приложений.

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

e) Цель О5 - требование к функциональным возможностям управления безопасностью в части функций, которые должны быть доступны администраторам, а также в части управления доступом к этим функциональным возможностям.

Пример цели безопасности для ОО:

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

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

D.4.2 Цели безопасности для среды

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

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

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

D.5 Требования безопасности информационных технологий

D.5.1 Функциональные требования безопасности

Для непосредственного удовлетворения целей безопасности для ОО, описанных в предыдущем разделе, могут быть выбраны следующие ФТБ:

a) цель безопасности О1 может быть удовлетворена соответствующим использованием FDP_ACF.1 (управление доступом, основанное на атрибутах безопасности) и FDP_ACC.2 (полное управление доступом) либо FTA_TSE.1 (открытие сеанса с ОО);

b) цель безопасности О2 может быть удовлетворена FIA_UAU.2 (аутентификация до любых действий пользователя) и FIA_UID.2 (идентификация до любых действий пользователя). Другие подходящие ФТБ: FIA_UAU.3 (аутентификация, защищенная от подделок), FIA_UAU.4 (механизмы одноразовой аутентификации) и FIA_UAU.5 (сочетание механизмов аутентификации), поскольку они учитывают спецификацию более сильных опознавательных механизмов;

c) цель безопасности О4 может быть удовлетворена FAU_GEN.1 (генерация данных аудита) и FAU_ARP.1 (сигналы нарушения безопасности) с тем, чтобы обеспечить анализ информации аудита в реальном масштабе времени;

d) цель безопасности 05 может быть удовлетворена FMT_SMR.1 (роли безопасности) вместе с FIA_UAU.2 и FIA_UID.2, использующими аутентификацию администратора межсетевого экрана.

После формирования начального набора остальные ФТБ выбирают главным образом, для того, чтобы удовлетворить зависимости. Дополнительные ФТБ могут быть включены, потому что они обеспечивают полезную (но не существенную) поддержку полномочий и, например, могут включать в себя FIA_AFL.1 (обработка отказов аутентификации), FPT_RVM.1 (невозможность обхода ПБО) и FPT_SEP.3 (полный монитор обращений).

Далее необходимо выбрать соответствующий уровень аудита (то есть "неопределенный", "минимальный", "базовый" или "детализированный"). Этот уровень должен соответствовать целям безопасности для ОО.

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

D.5.2 Требования доверия к безопасности объекта оценки

Выбор требований доверия должен быть относительно простым. Если авторы ПЗ и ЗБ не считают необходимым расширение или усиление требований доверия, то выбор последних сводится к выбору соответствующего оценочного уровня доверия к безопасности. Например, анализируя характер угроз (включая относительно сложные атаки) и ценность активов ИТ, можно выбрать ОУД4 как наиболее подходящий.

D.5.3 Требования безопасности для ИТ-среды

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

Выбор требований доверия в рассматриваемом случае соответствует выбору требований доверия для ИТ, например, ОУД4.

D.6 Краткая спецификация объекта оценки

D.6.1 Функции безопасности объекта оценки

При построении функций безопасности ИТ авторы ЗБ могут начинать с ФТБ и получать функции безопасности ИТ из них следующим образом:

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

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

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

- явного IP- адреса или имени хоста источника;

- явного номера порта источника;

- IP- адреса или имени хоста получателя;

- номера порта получателя.

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

- отображать и изменять параметры межсетевого экрана по управлению доступом;

- инициализировать и изменять данные аутентификации пользователей;

- отображать и изменять атрибуты пользователей;

- выбирать события, которые нужно контролировать;

- выделять подмножество контролируемых событий, предположительно отображающих возможное или предстоящее нарушение безопасности;

- сопоставлять отдельные механизмы аутентификации с определенными событиями аутентификации;

- проверять целостность межсетевого экрана.

Таким образом, можно интегрировать требования нескольких ФТБ в одной функции безопасности ИТ (ФТБ необходимо определить, используя FMT_MSA.1.1, FMT_MOF.1.1, FMT_MTD.1.1 и FPT_TST.1.3).

D.7 Утверждения о соответствии профиля защиты

В этом разделе ЗБ для межсетевого экрана следует идентифицировать в профили защиты для межсетевых экранов, на которых основано данное ЗБ, и продемонстрировать согласованность ЗБ с этими ПЗ.

D.8 Обоснование профиля защиты

D.8.1 Обоснование целей безопасности

Демонстрация пригодности целей безопасности для того, чтобы противостоять угрозам, может быть осуществлена:

a) с использованием таблицы, показывающей, какие цели безопасности каким угрозам соответствуют (например, O.ACCESS (O1), которая определяет потребность в политике управления доступом межсетевого экрана, может соответствовать угрозам, относящимся к нарушителям из враждебной сети, типа IP-спуфинга (подмена IP-адреса) или атаки на уязвимые сервисы), обеспечивая отображение каждой цели безопасности, по крайней мере, на одну угрозу;

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

Ниже приведен пример объяснения пригодности:

Угроза T.PROTOCOL. Нарушитель из враждебной сети может применить ненадлежащее использование протоколов сервисов (например, использование "известного" номера порта для протокола, отличного от протокола, определенного для использования этого порта).

Цель O.ACCESS ограничивает хосты и порты сервисов, к которым можно обращаться, соответственно, из враждебных (внешних) сетей и частной сети.

Цель O.AUDIT контролирует возможные атаки, предоставляя администратору межсетевого экрана средства их обнаружения и принятия соответствующих мер.

Цель O.ADMIN обеспечивает необходимую поддержку, обеспечивая безопасное административное управление межсетевым экраном, поддерживаемое O.INSTALL и O.TRAIN.

D.8.2 Обоснование функциональных требований безопасности

Демонстрацию пригодности ФТБ для удовлетворения целей безопасности для ОО можно представить следующим образом:

a) показ посредством таблицы, какие ФТБ и каким целям безопасности соответствуют (например, FDP_ACF.1 и FDP_ACC.2 соответствует цели безопасности O.ACCESS (O1)), гарантируя, что каждое ФТБ отображается по крайней мере на одну цель безопасности;

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

Ниже приведен пример обоснования пригодности:

цель O.ADDRESS. Межсетевой экран должен ограничить диапазон допустимых адресов частной и враждебной (внешней) сети (то есть внешний хост не может подменить внутренний хост).

FDP_ACF.1 вместе с FDP_ACC.2 обеспечивают возможность ограничения доступа, как это требует O.ADDRESS, a FPT_RVM.1 обеспечивает, чтобы эти функции вызывались всегда, когда требуется.

Демонстрация взаимной поддержки и внутренней согласованности может быть обеспечена, во-первых, посредством анализа зависимостей. Во-вторых, она может быть дополнена таблицей, демонстрирующей поддержку ФТБ со стороны других ФТБ для защиты от обхода, вмешательства и блокирования соответствующих ФБО. Демонстрация взаимной поддержки и внутренней согласованности может сопровождаться пояснением данных таблицы. Вместо рассмотрения каждого требования по порядку (что ведет к повторам) можно выделить общие вопросы, необходимые для понимания данных таблицы. Например, атаки вмешательства предотвращаются:

- FPT_SEP.3, который поддерживает разделение на домены и, в частности, предотвращает вмешательство нарушителя в функции безопасности;

- функциями безопасности, которые ограничивают возможности модификации атрибутов или данных настройки уполномоченным администратором (например, основанные на FMT_MSA.1);

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

D.8.3 Обоснование требований доверия к безопасности

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

D.9 Обоснование задания по безопасности

В ЗБ, разработанного в соответствии с ПЗ для межсетевого экрана в разделе "Обоснование ЗБ", могут широко использоваться материалы раздела ПЗ "Обоснование ПЗ", в частности:

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

b) если в ЗБ добавлено небольшое число ФТБ по отношению к ФТБ, определенных в ПЗ, в обосновании ЗБ может быть ссылка на соответствующую часть обоснования ПЗ, а также продемонстрировано:

- что дополнительные требования являются надлежащими для удовлетворения целей безопасности,

- что дополнительные требования не приводят к каким-либо конфликтам, а поддерживают другие требования,

- что дополнительные зависимости были удовлетворены или не должны были быть удовлетворены;

c) если идентичные ПЗ требования доверия к безопасности были определены в ЗБ, то в подразделе ЗБ "Обоснование требований безопасности" можно просто сослаться на соответствующую часть обоснования ПЗ.

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

a) логическое обоснование соответствия ПЗ; оно может быть выполнено посредством использования таблицы для демонстрации покрытия всех ФТБ из ПЗ, а также - таблицы, показывающей выполнение в ЗБ операций, предусмотренных в ПЗ;

b) обоснование функций безопасности ИТ; оно может быть выполнено посредством явного сопоставления специфицированных функций безопасности ИТ с ФТБ. Если никаких новых функциональных возможностей на этом уровне не вводится, то демонстрация взаимной поддержки может считаться представленной в обосновании требований безопасности.