2015-05-13
1991
Систематизированный каталог функциональных требований безопасности сосредоточен во второй части ОК [34]. Функциональные требования разбиты на 11 классов, 66 семейств и 135 компонентов.
Структура функционального класса приведена на рис. 3.4.5.1.
Рис. 3.4.5.1. Структура функционального класса
Имя класса содержит информацию, необходимую для идентификации функционального класса и отнесения его к определенной категории. Каждый функциональный класс имеет уникальное имя. Информация о категории предоставлена кратким именем, состоящим из трех букв латинского алфавита. Краткое имя класса используют при задании кратких имен семейств этого класса.
Представление класса содержит рисунок, показывающий все семейства этого класса и иерархию компонентов в каждом семействе.
Структура функционального семейства приведена на рис. 3.4.5.2.
 |
Рис. 3.4.5.2. Структура функционального семейства
Каждое функциональное семейство имеет уникальное имя. Первые три символа идентичны краткому имени класса, далее следуют символ подчеркивания и краткое имя семейства в виде XXX_YYY.
Характеристика семейства – это описание функционального семейства, в котором излагаются его цели безопасности и общее описание функциональных требований. Цели безопасности семейства характеризуют задачу безопасности, которая может быть решена с помощью ОО, включающего компонент из этого семейства. Описание функциональных требований обобщает все требования, которые включены в компоненты.
Цель ранжирования компонентов – предоставить пользователям информацию для выбора подходящего функционального компонента из семейства.
Связи между компонентами в пределах функционального семейства могут быть иерархическими и неиерархическими. Компонент иерархичен (т.е. расположен выше по иерархии) по отношению к другому компоненту, если предлагает большую безопасность.
Требования управления содержат информацию для разработчиков ПЗ/ЗБ, учитываемую при определении действий по управлению для данного компонента. Требования управления детализированы в компонентах класса «Управление безопасностью» (FMT).
Требования аудита содержат события,потенциально подвергаемые аудиту, для их отбора разработчиками ПЗ/ЗБ при условии включения в ПЗ или ЗБ требований из класса FAU «Аудит безопасности». Эти требования включают в себя события, относящиеся к безопасности, применительно к различным уровням детализации, поддерживаемым компонентами семейства FAU_GEN «Генерация данных аудита безопасности». Например, запись аудита какого-либо механизма безопасности может включать на разных уровнях детализации, которые раскрываются в следующих терминах:
- минимальный - успешное использование механизма безопасности;
- базовый - любое использование механизма безопасности, а также информация о текущих значениях атрибутов безопасности.
- детализированный - любые изменения конфигурации механизма безопасности, включая параметры конфигурации до и после изменения.
Структура функционального компонента приведена на рисунке 3.4.5.3.
Рис. 3.4.5.3. Структура функционального компонента
Идентификация компонента включает описательную информацию, необходимую для идентификации, категорирования, записи и реализации перекрестных ссылок компонента. Для каждого функционального компонента представляется следующая информация:
– уникальное имя, отражающее предназначение компонента;
– краткое имя, применяемое как основное имя ссылки для категорирования, записи и реализации перекрестных ссылок компонента и уникально отражающее класс и семейство, которым компонент принадлежит, а также номер компонента в семействе;
– список иерархических связей, содержащий имена других компонентов, для которых этот компонент иерархичен и вместо которых может использоваться при удовлетворении зависимостей от перечисленных компонентов.
Каждый компонент включает набор элементов. Каждый элемент определяется отдельно и является самодостаточным.
Функциональный элемент – это наименьшее функциональное требование безопасности, идентифицируемое и признаваемое в ОК. При формировании ПЗ или ЗБ не разрешается выбирать только часть элементов компонента – необходимо использовать всю их совокупность.
Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP_IFF.4.2 читается следующим образом: F – функциональное требование, DP – класс «Защита данных пользователя», IFF – семейство «Функции управления информационными потоками»,.4 – четвертый компонент «Частичное устранение неразрешенных информационных потоков», 2 – второй элемент компонента.
Зависимости среди функциональных компонентов возникают, когда компонент не самодостаточен и нуждается либо в функциональных возможностях другого компонента, либо во взаимодействии с ним для поддержки собственного выполнения. Список зависимостей идентифицирует минимум функциональных компонентов или компонентов доверия, необходимых для удовлетворения требований безопасности, ассоциированных с данным компонентом. Компоненты, которые иерархичны по отношению к компоненту из списка, также могут быть использованы для удовлетворения зависимости.
Зависимости между компонентами, указанные в части 2 ОК, являются обязательными, и их необходимо удовлетворить при разработке профиля защиты или задания по безопасности. В тех редких случаях, когда эти зависимости удовлетворить невозможно, соответствующее строгое обоснование должно быть приведено в ПЗ или ЗБ.
Классы и семейства представлены во второй части ОК в алфавитном порядке. В начале каждого класса имеется рисунок, показывающий таксономию этого класса, перечисляя семейства в этом классе и компоненты в каждом семействе. Рисунок также иллюстрирует иерархию компонентов внутри каждого семейства.
Пример представления таксономии класса и иерархии компонентов в его семействах приведен на рисунке 3.4.5.4.
Рис. 3.4.5.4. Пример представления класса
Семейство 1 на рис. 3.4.5.4 содержит три иерархических компонента, где компоненты 2 и 3 могут быть применены для выполнения зависимостей вместо компонента 1. Компонент 3 иерархичен к компоненту 2 и может применяться для выполнения зависимостей вместо компонента 2.
В семействе 2 имеются три компонента, не все из которых иерархически связаны. Компоненты 1 и 2 не иерархичны к другим компонентам. Компонент 3 иерархичен к компоненту 2 и может применяться для удовлетворения зависимостей вместо компонента 2, но не вместо компонента 1.
В семействе 3 компоненты 2 – 4 иерархичны к компоненту 1. Компоненты 2 и 3 иерархичны к компоненту 1, но несопоставимы по иерархии между собой. Компонент 4 иерархичен к компонентам 2 и 3.
При изложении функциональных требований безопасности ОО следует определять функциональные требования к ОО, где это возможно, как функциональные компоненты, выбираемые из части 2 ОК. В случае необходимости, требования формулируются в явном виде, однако при их изложении необходимо сохранять стилистику «Общих критериев».
При выборе компонентов функциональных требований из части 2 ОК, над ними могут быть осуществлены следующие операции:
- итерация, позволяющая неоднократно использовать компонент при различном выполнении в нем операций;
- назначение, позволяющее специфицировать параметр, устанавливаемый при использовании компонента;
- выбор, позволяющий специфицировать пункты, которые выбираются из перечня, приведенного в компоненте;
- уточнение, позволяющее осуществлять дополнительную детализацию при использовании компонента.
42. Парадигма доверия: значимость и причины возникновения уязвимостей, роль оценки. Представление требований доверия: структура класса, семейства, компонента, элемента. Примеры классов доверия. Парадигма поддержки доверия. Оценочные уровни доверия (ОУД1-ОУД7). Их примерное соответствие требованиям по классам безопасности Оранжевой книги, Европейских критериев и РД ГТК РФ.
1.2 Парадигма доверия
Цель данного подраздела состоит в изложении основных принципов и подходов к установлению доверия к безопасности. Данный подраздел позволит читателю понять логику построения требований доверия в ОК.
1.2.1 Основные принципы ОК
Основные принципы ОК состоят в том, что следует четко сформулировать угрозы безопасности и положения политики безопасности организации, а достаточность предло-женных мер безопасности должна быть продемонстрирована.
Более того, следует предпринять меры по уменьшению вероятности наличия уязви-мостей, возможности их проявления (т.е. преднамеренного использования или непредна-меренной активизации), а также степени ущерба, который может явиться следствием про-явления уязвимостей. Дополнительно следует предпринять меры для облегчения после-дующей идентификации уязвимостей, а также по их устранению, ослаблению и/или опо-вещению об их использовании или активизации.
1.2.2 Подход к доверию
Основная концепция ОК – обеспечение доверия, основанное на оценке (активном исследовании) продукта или системы ИТ, которым предполагается доверять. Оценка была традиционным способом обеспечения доверия и являлась основой предшествующих кри-териев оценки. Для согласования с существующими подходами в ОК принят тот же самый основной принцип. ОК предполагают, что проверку правильности документации и разра-ботанного продукта или системы ИТ будут проводить опытные оценщики, уделяя особое внимание области, глубине и строгости оценки.
ОК не отрицают и при этом не комментируют относительные достоинства других способов получения доверия. Продолжаются исследования альтернативных путей достиже-ния доверия. Если в результате этих исследований будут выявлены другие отработанные альтернативные подходы, то они могут в дальнейшем быть включены в ОК, которые струк-турно организованы так, что предусматривают такую возможность.
1.2.2.1 Значимость уязвимостей
Предполагается, что имеются нарушители, которые будут пытаться активно ис-пользовать возможности нарушения политики безопасности как для получения незаконной выгоды, так и для незлонамеренных, но, тем не менее, опасных действий. Нарушители мо-гут также случайно активизировать уязвимости безопасности, нанося вред организации. При необходимости обрабатывать чувствительную информацию и отсутствии в достаточ-ной степени доверенных продуктов или систем имеется значительный риск из-за отказов ИТ. Поэтому нарушения безопасности ИТ могут вызвать значительные потери.
Нарушения безопасности ИТ возникают вследствие преднамеренного использова-ния или случайной активизации уязвимостей при применении ИТ по назначению.
Следует предпринять ряд шагов для предотвращения уязвимостей, возникающих в продуктах и системах ИТ. По возможности уязвимости должны быть:
а) устранены, т.е. следует предпринять активные действия для выявления, а затем уда-ления или нейтрализации всех уязвимостей, которые могут проявиться;
б) минимизированы, т.е. следует предпринять активные действия для уменьшения до допустимого остаточного уровня возможного ущерба от любого проявления уязви-мостей;
в) отслежены, т.е. следует предпринять активные действия для обнаружения любой попытки использовать оставшиеся уязвимости с тем, чтобы ограничить ущерб.
1.2.2.2 Причины уязвимостей
Уязвимости могут возникать из-за недостатков:
а) требований, т.е. продукт или система ИТ могут обладать требуемыми от них функ-циями и свойствами, но все же содержать уязвимости, которые делают их непри-годными или неэффективными в части безопасности;
б) проектирования, т.е. продукт или система ИТ не отвечают спецификации, и/или уязвимости являются следствием некачественных стандартов проектирования или неправильных проектных решений;
в) эксплуатации, т.е. продукт или система ИТ разработаны в полном соответствии с корректными спецификациями, но уязвимости возникают как результат неадекват-ного управления при эксплуатации.
1.2.2.3 Доверие в ОК
Доверие – основа для уверенности в том, что продукт или система ИТ отвечают це-лям безопасности. Доверие могло бы быть получено путем обращения к таким источни-кам, как бездоказательное утверждение, предшествующий аналогичный опыт или специ-фический опыт. Однако ОК обеспечивают доверие с использованием активного исследо-вания. Активное исследование – это оценка продукта или системы ИТ для определения его свойств безопасности.
1.2.2.4 Доверие через оценку
Оценка является традиционным способом достижения доверия, и она положена в основу ОК. Методы оценки могут, в частности, включать в себя:
а) анализ и проверку процессов и процедур;
б) проверку, что процессы и процедуры действительно применяются;
в) анализ соответствия между представлениями проекта ОО;
г) анализ соответствия каждого представления проекта ОО требованиям;
д) верификацию доказательств;
е) анализ руководств;
ж) анализ разработанных функциональных тестов и полученных результатов;
и) независимое функциональное тестирование;
к) анализ уязвимостей, включающий предположения о недостатках;
л) тестирование проникновения.
1.2.3 Шкала оценки доверия в ОК
Основные принципы ОК содержат утверждение, что большее доверие является ре-зультатом приложения больших усилий при оценке, и что цель состоит в применении ми-нимальных усилий, требуемых для обеспечения необходимого уровня доверия. Повыше-ние уровня усилий может быть основано на:
а) области охвата, т.е. увеличении рассматриваемой части продукта или системы ИТ;
б) глубине, т.е. детализации рассматриваемых проектных материалов и реализации;
в) строгости, т.е. применении более структурированного и формального подхода.
2 Требования доверия к безопасности
2.1 Структуры
Следующие подразделы описывают конструкции, используемые в представлении классов, семейств и компонентов доверия, оценочных уровней доверия (ОУД), и их взаи-мосвязь.
На рисунке 2.1 показаны требования доверия, определенные в части 3 ОК. Наиболее общую совокупность требований доверия называют классом. Каждый класс содержит се-мейства доверия, которые разделены на компоненты доверия, содержащие, в свою очередь, элементы доверия. Классы и семейства используют для обеспечения таксономии класси-фицируемых требований доверия, в то время как компоненты применяют непосредственно для спецификации требований доверия в ПЗ/ЗБ.
2.1.1 Структура класса
Рисунок 2.1 иллюстрирует структуру класса доверия.
2.1.1.1 Имя класса
Каждому классу доверия присвоено уникальное имя. Имя указывает на тематиче-ские разделы, на которые распространяется данный класс доверия.
Представлена также уникальная краткая форма имени класса доверия. Она является основным средством для ссылки на класс доверия. Принятое условное обозначение вклю-чает в себя букву "A", за которой следуют еще две буквы латинского алфавита, относя-щиеся к имени класса.
2.1.1.2 Представление класса
Каждый класс доверия имеет вводный подраздел, в котором описаны состав и на-значение класса.
2.1.1.3 Семейства доверия
Каждый класс доверия содержит, по меньшей мере, одно семейство доверия. Структура семейств доверия описана в следующем пункте.
Рисунок 2.1 – Иерархическая структура представления требований доверия: класс-семейство-компонент-элемент
2.1.2 Структура семейства доверия
Рисунок 2.1 иллюстрирует структуру семейства доверия.
2.1.2.1 Имя семейства
Каждому семейству доверия присвоено уникальное имя. Имя содержит описатель-ную информацию по тематическим разделам, на которые распространяется данное семей-ство доверия. Каждое семейство доверия размещено в пределах класса доверия, который содержит другие семейства той же направленности.
Представлена также уникальная краткая форма имени семейства доверия. Она явля-ется основным средством для ссылки на семейство доверия. Принятое условное обозначе-ние включает в себя краткую форму имени класса и символ подчеркивания, за которым следуют три буквы латинского алфавита, относящиеся к имени семейства.
2.1.2.2 Цели
Подраздел целей семейства доверия представляет назначение семейства доверия.
В нем описаны цели, для достижения которых предназначено семейство, особенно связанные с парадигмой доверия ОК. Описание целей для семейства доверия представлено в общем виде. Любые конкретные подробности, требуемые для достижения целей, вклю-чены в конкретный компонент доверия.
2.1.2.3 Ранжирование компонентов
Каждое семейство доверия содержит один или несколько компонентов доверия. Этот подраздел семейства доверия содержит описание имеющихся компонентов и объяс-нение их разграничения. Его основная цель состоит в указании различий между компонен-тами при принятии решения о том, что семейство является необходимой или полезной ча-стью требований доверия для ПЗ/ЗБ.
В семействах доверия, содержащих более одного компонента, выполнено ранжиро-вание компонентов и приведено его обоснование. Это обоснование сформулировано в тер-минах области применения, глубины и/или строгости.
2.1.2.4 Замечания по применению
Необязательный подраздел замечаний по применению семейства доверия содержит дополнительную информацию о семействе. Эта информация предназначена непосредст-венно для пользователей семейства доверия (например, разработчиков ПЗ и ЗБ, проекти-ровщиков ОО, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого вни-мания.
2.1.2.5 Компоненты доверия
Каждое семейство содержит хотя бы один компонент доверия. Структура компо-нентов доверия представлена в следующем пункте.
2.1.3 Структура компонента доверия
Рисунок 2.2 иллюстрирует структуру компонента доверия.
Рисунок 2.2 – Структура компонента доверия
Связь между компонентами внутри семейства показана с использованием соглаше-ния о шрифтовом выделении. Для частей требований, которые являются новыми, расши-ренными или модифицированными по сравнению с требованиями предыдущего по иерар-хии компонента, применен полужирный шрифт. Такое же соглашение о шрифтовом выде-лении использовано и для зависимостей.
2.1.3.1 Идентификация компонента
Подраздел идентификации компонента содержит описательную информацию, не-обходимую для идентификации, категорирования, регистрации и ссылок на компонент.
Каждому компоненту доверия присвоено уникальное имя. Имя содержит информа-цию о тематических разделах, на которые распространяется компонент доверия. Каждый компонент входит в состав конкретного семейства доверия, с которым имеет общую цель безопасности.
Представлена также уникальная краткая форма имени компонента доверия как ос-новной способ ссылки на компонент. Принято, что за краткой формой имени семейства ставится точка, а затем цифра. Цифры для компонентов внутри каждого семейства назна-чены последовательно, начиная с единицы.
2.1.3.2 Цели
Необязательный подраздел целей компонента доверия содержит конкретные цели этого компонента. Для компонентов доверия, которые имеют этот подраздел, он включает в себя конкретное назначение данного компонента и подробное разъяснение целей.
2.1.3.3 Замечания по применению
Необязательный подраздел замечаний по применению компонента доверия содер-жит дополнительную информацию для облегчения использования компонента.
2.1.3.4 Зависимости
Зависимости среди компонентов доверия возникают, когда компонент не самодос-таточен, а предполагает присутствие другого компонента.
Для каждого компонента доверия приведен полный список зависимостей от других компонентов доверия. При отсутствии у компонента идентифицированных зависимостей вместо списка указано: "Зависимости отсутствуют". Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов.
Список зависимостей определяет минимальный набор компонентов доверия, на ко-торые следует полагаться. Компоненты, которые иерархичны по отношению к компоненту из списка зависимостей, также могут использоваться для удовлетворения зависимости.
В отдельных ситуациях обозначенные зависимости могут быть неприменимы. Раз-работчик ПЗ/ЗБ может отказаться от удовлетворения зависимости, представив обоснова-ние, почему данная зависимость неприменима.
2.1.3.5 Элементы доверия
Каждый компонент доверия содержит набор элементов доверия. Элемент доверия – требование безопасности, при дальнейшем разделении которого не изменяется значимый результат оценки. Он является наименьшим требованием безопасности, распознаваемым в ОК.
Каждый элемент доверия принадлежит к одному из трех типов.
а) Элементы действий разработчика, определяющие действия, которые должны вы-полняться разработчиком. Этот набор действий далее уточняется доказательным материалом, упоминаемым в следующем наборе элементов. Требования к действи-ям разработчика обозначены буквой "D" после номера элемента.
б) Элементы содержания и представления свидетельств, определяющие требуемые свидетельства и отражаемую в них информацию. Требования к содержанию и пред-ставлению свидетельств обозначены буквой "C" после номера элемента.
в) Элементы действий оценщика, определяющие действия, которые должны выпол-няться оценщиком. Этот набор действий непосредственно включает в себя под-тверждение того, что требования, предписанные элементами содержания и пред-ставления свидетельств, выполнены, а также конкретные действия и анализ, выпол-няемые в дополнение к уже проведенным разработчиком. Должны также выпол-няться не указанные явно действия оценщика, необходимые вследствие элементов действий разработчика, но не охваченные в требованиях к содержанию и представ-лению свидетельств. Требования к действиям оценщика обозначены буквой "E" по-сле номера элемента.
Действия разработчика, содержание и представление свидетельств определяют тре-бования, предъявляемые к разработчику по демонстрации доверия к ФБО. Выполняя эти требования, разработчик может повысить уверенность в том, что ОО удовлетворяет функ-циональным требованиям и требованиям доверия из ПЗ или ЗБ.
Действия оценщика определяют его ответственность по двум аспектам. Первый ас-пект – проверка правильности ПЗ/ЗБ в соответствии с требованиями классов APE/ASE из разделов 4 и 5. Второй аспект – верификация соответствия ОО его функциональным тре-бованиям и требованиям доверия. Демонстрируя, что ПЗ/ЗБ правильны, и их требования выполняются ОО, оценщик может предоставить основание для уверенности в том, что ОО будет отвечать поставленным целям безопасности.
Элементы действий разработчика, элементы содержания и представления свиде-тельств и элементы установленных действий оценщика определяют уровень его усилий, которые должны быть приложены при верификации утверждений о безопасности, сформу-лированных в ЗБ конкретного ОО.
2.1.4 Элементы доверия
Каждый элемент представляет собой требование для выполнения. Формулировки этих требований должны быть четкими, краткими и однозначными. Поэтому в требовани-ях отсутствуют составные предложения. Каждое требование изложено как отдельный эле-мент.
В тексте элементов использованы, как правило, термины, имеющие обычное сло-варное значение, которые не могут привести к неоднозначному толкованию требований.
В отличие от функциональных элементов из части 2 ОК к элементам доверия из части 3 ОК не применимы операции назначения и выбора; однако, при необходимости, до-пустимо применение операции уточнения.
2.1.5 Структура ОУД
Рисунок 2.3 иллюстрирует ОУД и их структуру, определенную в части 3 ОК. Ком-поненты доверия, содержание которых показано на рисунке, включены в ОУД посредст-вом ссылок на компоненты, приведенные в части 3 ОК.
2.1.5.1 Имя ОУД
Каждому ОУД присвоено уникальное имя. Имя представляет описательную инфор-мацию о предназначении ОУД.
Представлена также уникальная краткая форма имени ОУД. Она является основным средством ссылки на ОУД.
2.1.5.2 Цели
В подразделе целей ОУД приведено назначение ОУД.
2.1.5.3 Замечания по применению
Необязательный подраздел замечаний по применению ОУД содержит информацию, представляющую интерес для пользователей ОУД (например, для разработчиков ПЗ и ЗБ, проектировщиков ОО, планирующих использование этого ОУД, оценщиков). Представле-ние неформально и включает в себя, например, предупреждения об ограничениях исполь-зования или областях, требующих особого внимания.
Рисунок 2.3 – Структура ОУД
2.1.5.4 Компоненты доверия
Для каждого ОУД выбран набор компонентов доверия.
Более высокий уровень доверия, чем предоставляемый данным ОУД, может быть достигнут:
а) включением дополнительных компонентов доверия из других семейств доверия;
б) заменой компонента доверия иерархичным компонентом из этого же семейства до-верия.
2.1.6 Связь между требованиями и уровнями доверия
Рисунок 2.4 иллюстрирует связь между требованиями и уровнями доверия, опреде-ленными в части 3 ОК. Компоненты доверия состоят из элементов, но последние не могут по отдельности быть включены в уровни доверия. Стрелка на рисунке отображает ссылку в ОУД на компонент доверия внутри класса, где он определен.
Рисунок 2.4 – Связь требований и уровня доверия
2.2 Классификация компонентов
Часть 3 ОК содержит классы семейств и компонентов, которые сгруппированы на основе, связанной с доверием. В начале каждого класса представлена диаграмма, которая указывает семейства в классе и компоненты в каждом семействе.
На рисунке 2.5 показан класс, содержащий одно семейство. Семейство содержит три компонента, которые являются линейно иерархичными (т.е. компонент 2 содержит бо-лее высокие требования, чем компонент 1, к конкретным действиям, приводимым свиде-тельствам или строгости действий и/или свидетельств). Все семейства доверия в части 3 ОК – линейно иерархичные, хотя линейность не обязательна для семейств доверия, кото-рые могут быть добавлены в дальнейшем.
Рисунок 2.5 – Образец декомпозиции класса
2.3 Структура класса критериев оценки профиля защиты и зада-ния по безопасности
Требования для оценки профиля защиты и задания по безопасности трактуют как классы доверия, структура которых подобна структуре других классов доверия, описанных ниже. Отличие заключается в отсутствии подраздела ранжирования компонентов в описа-ниях семейств и вызвано тем, что каждое семейство имеет только один компонент.
В таблицах 3.1–3.4 приведены названия каждого из классов APE и ASE, состав-ляющих их семейств и их краткие имена. Содержание разделов ПЗ, рассматриваемых в се-мействах класса APE, представлено в части 1 ОК, приложение Б, подразделы Б.2.2–Б.2.6, а разделов ЗБ, рассматриваемых в семействах класса ASE, – в части 1 ОК, приложение В, подразделы В.2.2–В.2.8.
2.4 Использование терминов в части 3 ОК
В части 3 ОК определенным образом используются термины, список которых при-веден ниже. Они не включены в глоссарий ОК (раздел 2 части 1 ОК), потому что являются общеупотребительными терминами, и их использование, хотя и ограничено приведенными разъяснениями, согласуется со словарными определениями. Однако именно такое толко-вание терминов применялось при разработке части 3 ОК, и поэтому оно полезно для пони-мания. В скобках приведены эквиваленты терминов на английском языке.
верифицировать(verify): Аналогичен термину "подтверждать" ("confirm"), но име-ет более глубокий смысл. При использовании в контексте действий оценщика указывает, что требуются независимые усилия оценщика.
взаимно поддерживающие (mutually supportive): Описывает взаимосвязь в груп-пе сущностей, указывая, что последние обладают некоторыми свойствами, которые не на-ходятся в противоречии со свойствами других сущностей и могут способствовать выпол-нению другими сущностями их задач. Нет необходимости определять, что каждая из рас-сматриваемых отдельных сущностей непосредственно поддерживает другие сущности в этой группе; достаточно, если сделано обобщенное заключение.
внутренне непротиворечивый (internally consistent): Отсутствуют очевидные противоречия между любыми аспектами сущности. Применительно к документации это означает, что в ней не может быть изложено что-либо, что может быть воспринято как противоречащее чему-то другому.
делать (независимое) заключение (determine): Требуется независимый анализ для достижения конкретного заключения. Термин отличается от "подтверждать"("confirm") или "верифицировать"("verify"), так как последние подразумевают, что требует проверки анализ, проведенный ранее, в то время как "делать (независимое) заключение" подразуме-вает совершенно независимый анализ, обычно при отсутствии любого предшествующего анализа.
демонстрировать (demonstrate): Относится к анализу, который приводит к заклю-чению, но является менее строгим, чем "доказательство" ("proof").
доказывать (prove): Относится к формальному анализу в математическом смысле, полностью строгий во всех отношениях. Обычно используется, когда желательно показать соответствие между двумя представлениями ФБО на высоком уровне строгости.
исчерпывающий (exhaustive): Используется применительно к проведению анализа или другой деятельности. Аналогичен термину "систематический" ("systematic"), но более точен, так как указывает не только на то, что в соответствии с некоторым конкретным пла-ном проведения анализа или другой деятельности был применен методический подход, но также и на то, что этот план достаточен для обеспечения проведения исследования по всем возможным направлениям.
логически упорядоченный (coherent): Сущность логически упорядочена и имеет очевидный смысл. Применительно к документации этот термин относится как к тексту, так и к структуре, указывая, что они понятны потенциальной аудитории.
непротиворечивый (consistent): Описывает связь между двумя или более сущно-стями, указывая, что между ними нет никаких явных противоречий.
обеспечивать (ensure): Подразумевает сильную причинно-следственную связь ме-жду некоторым действием и его последствиями. Часто ему предшествует термин "способ-ствует" ("helps"), указывающий, что одно данное действие не полностью определяет по-следствия.
объяснять (explain): Отличается от терминов "описывать" ("describe") и "демонст-рировать" ("demonstrate"). Предназначен для ответа на вопрос "Почему?" без попытки ар-гументировать, что ход предпринимаемых действий обязательно оптимален.
описывать (describe): Требует, чтобы некоторые конкретные подробности сущно-сти были представлены.
подтверждать (confirm): Используется для указания необходимости подробного рассмотрения чего-либо; при этом требуется независимое заключение о его достаточности. Требуемый уровень строгости зависит от характера предмета. Применим только к дейст-виям оценщика.
полный (complete): Представлены все необходимые составляющие сущности. Применительно к документации это означает, что приведена вся необходимая информа-ция, причем настолько детально, что на данном уровне абстракции дальнейшие пояснения не требуются.
проверять (check): Аналогичен, но менее строг, чем "подтверждать"("confirm") или "верифицировать"("verify"). Требует, чтобы оценщиком было сделано оперативное заклю-чение, возможно лишь с поверхностным анализом или вообще без него.
прослеживать или сопоставлять (trace): Используется для указания, что между двумя сущностями требуется только минимальный уровень строгости неформального со-ответствия.
противостоять (counter): Используется в том смысле, что некоторая цель безопас-ности заключается в противостоянии конкретной угрозе, но не обязательно указывает в итоге на полную ее ликвидацию.
специфицировать или определять (specify): Используется в том же контексте, что и "описывать" ("describe"), но является более строгим и точным. Аналогичен термину "оп-ределять" ("define").
строгое обоснование (justification): Относится к анализу, ведущему к заключению, но является более строгим, чем термин "демонстрация" ("demonstration"), в смысле точных и подробных объяснений каждого шага логических суждений.
2.5 Классификация доверия
Классы и семейства доверия, а также их краткие имена приведены в таблице 2.1.
43. Сервисы безопасности: идентификация и аутентификация, разграничение доступа, протоколирование и аудит, экранирование, туннелирование, шифрование, контроль целостности, контроль защищенности, обнаружение отказов и оперативное восстановление, управление.
Мы приступаем к описанию сервисов безопасности, совокупность которых, на наш взгляд, достаточна для построения защиты, соответствующей современным требованиям.
