ГОСТ Р ИСО/МЭК 15408-3-2013 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности
Рисунок 10 - Взаимосвязи между компонентами класса ADV и с другими семействами
Требования для всех других соответствий, показанных на рисунке 10, определены в классе ADV "Разработка". Семейство ADV_SPM "Моделирование политики безопасности" определяет требования к выбранным ФТБ формальной модели и предоставляет соответствие между функциональной спецификацией и формальной моделью. Каждое семейство, относящееся к конкретному представлению ФБО (т.е. ADV_FSP "Функциональная спецификация", ADV_TDS "Проект ОО" и ADV_IMP "Представление реализации"), определяет требования, относящиеся к соответствию между представлением ФБО и ФТБ. Каждый элемент декомпозиции должен точно отображать все прочие элементы (т.е. все элементы декомпозиции должны быть взаимоподдерживающими); разработчик обеспечивает прослеживание между представлениями ФБО и ФТБ в последних элементах компонентов под рубрикой "Элементы содержания и представления свидетельств" (обозначение - ".С"). Доверие относительно этого фактора достигается в процессе анализа каждого из уровней декомпозиции путем ссылки конкретного уровня на другие уровни декомпозиции (рекурсивным образом) в процессе анализа этого конкретного уровня декомпозиции; оценщик верифицирует их соответствие как часть выполнения второго элемента группы компонентов "Элементы действий оценщика" (обозначение - ".Е"). Полученная от этих уровней декомпозиции информация служит основой для усилий по функциональному тестированию и тестированию проникновения.
Семейство ADV_INT "Внутренняя структура ФБО" не представлено на рисунке 10, поскольку оно связано с внутренней структурой ФБО и имеет лишь косвенное отношение к процессу уточнения представлений ФБО. Также не представлено и семейство ADV_RCR "Архитектура безопасности", которое имеет большее отношение к целостности архитектуры, чем к представлению ФБО. Оба этих семейства, ADV_INT "Внутренняя структура" и ADV_RCR "Архитектура безопасности", относятся к анализу свойства ОО, которое заключается в невозможности искажения или обхода функциональных возможностей безопасности ОО.
Функциональные возможности безопасности ОО (ФБО) представляют собой совокупность всех функциональных возможностей различных частей ОО, на которых полагаются с целью осуществления ФТБ. ФБО включают в себя как функции, которые непосредственно осуществляют ФТБ, так и функции, которые, не осуществляя ФТБ непосредственно, косвенно содействуют осуществлению ФТБ. Сюда же включаются и функциональные возможности, при недостаточности или отсутствии которых возможны нарушения ФТБ. К таким функциональным возможностям относятся и те части ОО, которые на стадии запуска ОО должны привести ФБО в первоначальное безопасное состояние.
При разработке компонентов семейств класса ADV "Разработка" применялось несколько важных принципов. Эти принципы кратко рассматриваются в данном разделе, а более подробно объясняются в замечаниях по применению для семейств.
Самый важный принцип заключается в том, что при получении большего объема информации можно получить большее доверие тому, что функциональные возможности безопасности: 1) правильно реализованы, 2) не могут быть искажены, 3) не могут быть подвержены обходу. Это осуществляется путем верификации того, что документация составлена верно и не противоречит иной документации, а также посредством представления информации, которую можно использовать для подтверждения того, что проводимые тестовые испытания (как функциональное тестирование, так и тестирование проникновения) являются исчерпывающими. Это отражается в ранжировании компонентов семейств. В общем случае компоненты ранжированы в зависимости от того, какой объем информации должен быть представлен (и впоследствии проанализирован).
Хотя это справедливо не для всех ОО, но в большинстве случаев документ, описывающий функциональные возможности безопасности, является достаточно сложным, и некоторые его части требуют более тщательного изучения, чем другие. Выявление таких частей осуществляется, к сожалению, субъективным образом, поэтому терминология и компоненты доверия определяются так, что при увеличении уровня доверия ответственность за выявление тех частей ФБО, которые нужно проанализировать детально, переходит от разработчика к оценщику. Для описания данного принципа вводится специальная терминология, представленная далее. Следует отметить, что в семействах класса эта терминология используется для описания связанных с ФТБ частями ОО (т.е. для элементов и шагов оценивания семейств ADV_FSP "Функциональная спецификация", ADV_TDS "Проект ОО", ADV_IMP "Представление реализации"). Хотя общий принцип (о том, что некоторые части ОО являются более интересными для анализа) применим и к другим семействам, критерии излагаются по-разному для получения требуемого уровня доверия.
Все части ФБО являются значимыми для безопасности, что означает, что они должны обеспечивать безопасность ОО согласно ФТБ и требованиям разделения доменов и невозможности обхода ФБО. Один из аспектов важности ФБО для безопасности - в какой степени ФБО обеспечивают выполнение требований безопасности. Так как различные части ОО выполняют различные роли (или вовсе не играют никакой явной роли) в осуществлении требований безопасности, значимость этих функциональных возможностей для выполнения ФТБ можно представить в виде определенного ряда. В начале его находятся те части ОО, которые осуществляют выполнение ФТБ. Такие части непосредственно участвуют в реализации тех или иных ФТБ в ОО. Такие ФТБ относятся ко всем функциональным возможностям, которые представлены одним из ФТБ, содержащимся в ЗБ. Следует отметить, что значимость функциональных возможностей для обеспечения выполнения ФТБ невозможно выразить количественно. Например, в механизме реализации Дискреционного управления доступом (ДУД), в узком смысле к осуществлению выполнения ФТБ можно отнести несколько строк кода, которые обеспечивают проверку соответствия атрибутов безопасности субъекта атрибутам объекта. При более широком рассмотрении к этой же категории можно добавить объект программного обеспечения (например, функцию на языке программирования Си), содержащий несколько строк программного кода. При еще более широком рассмотрении туда же включаются операторы вызова функции языка программирования Си, так как именно они отвечают за обеспечение принятия решения о доступе после проверки атрибутов. Еще более широкое рассмотрение включает любой фрагмент кода в дереве вызовов (или программный эквивалент в зависимости от используемого языка программирования) данной функции языка программирования Си (например, функции сортировки, которая проводит сортировку списка контроля и управления доступом по алгоритму первого совпадения). Иногда компонент является не столько осуществляющим выполнение политики безопасности, сколько играющим роль поддержки; такие компоненты называются поддерживающими выполнение ФТБ.
Одна из характеристик функциональных возможностей, поддерживающих ФТБ, заключается в том, что они должны обеспечивать стабильную правильность реализации ФТБ посредством функционирования без ошибок. Такие функциональные возможности могут зависеть от функций, осуществляющих ФТБ, но в основном на функциональном уровне, например: управление памятью, управление буферизацией и т.д. Далее по ряду значимости для безопасности находятся функциональные возможности, называемые не влияющими на выполнение ФТБ. Они не участвуют в реализации ФТБ, а частью ФБО являются, скорее всего, из-за среды их функционирования. Это, например, любой программный код, запущенный в операционной системе в привилегированном аппаратном режиме. Его следует рассматривать как часть ФБО потому, что в случае искажения (или в случае замены вредоносным кодом) он может нарушить правильность выполнения ФТБ в силу того, что выполнялся в привилегированном режиме. Примером функциональных возможностей, не влияющих на выполнение ФТБ, может быть набор математических операций над числами с плавающей запятой, выполняемый для быстроты вычислений в режиме ядра ОС.
Семейство "Архитектура безопасности" (ADV_ARC) служит для описания требований и анализа ОО на основе свойств разделения доменов, собственной защиты ФБО и невозможности обхода ФБО. Эти свойства имеют значение для выполнения ФТБ, так как их отсутствие приведет, скорее всего, к сбою механизмов, осуществляющих реализацию ФТБ. Функциональные возможности этих свойств и проект, относящийся к ним, при этом рассматриваются не как часть описанного выше ряда значимости, а отдельно - в силу того, что они совершенно иные по сути и к их анализу предъявляются другие требования.
Разница в анализе реализации ФТБ (функциональных возможностей, осуществляющих и поддерживающих выполнение ФТБ) и реализации некоторых фундаментальных свойств безопасности ОО (к которым относится инициализация, собственная защита ФБО и невозможность обхода ФБО) заключается в том, что функциональные возможности, имеющие отношение к ФТБ, являются более или менее явными и относительно легко тестируемыми, а вышеупомянутые свойства требуют анализа гораздо более широкого набора функций на различных уровнях. Кроме того, глубина требуемого анализа данных свойств будет варьироваться в зависимости от проекта ОО. Семейства класса ADV "Разработка" обеспечивают выполнение этого отдельным семейством (ADV_ARC "Архитектура безопасности"), которое посвящено анализу требований инициализации, собственной защиты ФБО и невозможности обхода ФБО, в то время как другие семейства связаны с анализом функций, обеспечивающих поддержку выполнения ФТБ.
Даже в тех случаях, когда необходимы различные описания на разных уровнях детализации, совсем необязательно каждое представление ФБО оформлять в виде отдельного документа. Возможна ситуация, когда в одном документе выполняются требования по документированию нескольких представлений ФБО, а объединение в нем требуемой информации по каждому из этих представлений ФБО предпочтительнее, несмотря на усложнение структуры данного документа. В случае, когда несколько представлений ФБО объединены в одном документе, разработчику следует указать, какие части документа удовлетворяют определенным требованиям.
Этим классом узаконены три типа стиля изложения спецификаций: неформальный, полуформальный и формальный. Функциональная спецификация и документация по проекту ОО всегда излагаются с применением либо неформального, либо полуформального стиля изложения. Применение полуформального стиля изложения уменьшает неоднозначность в спецификациях по сравнению с неформальным стилем изложения. Кроме того, в дополнение к полуформальному представлению может потребоваться и предоставление формальной спецификации; преимущество такого требования в том, что описание ФБО несколькими способами увеличивает доверие к тому, что ФБО полно и точно определены.
Неформальную спецификацию излагают как повествовательный текст на естественном языке. Под естественным языком здесь подразумевается применение выразительных средств общения любого разговорного языка (например, английского, немецкого, русского, французского, испанского и т.д.). Неформальная спецификация не подчинена никаким нотационным или специальным ограничениям, отличным от общепринятых соглашений для этого языка (таких, как грамматика и синтаксис). Хотя не применяются никакие нотационные ограничения, в неформальной спецификации все же требуется привести определения значений терминов, использование которых в контексте отличается от общепринятого.
Разница между документами неформального и полуформального стиля изложения заключается только в форматировании и способе представления: в документах полуформального стиля приводится подробный глоссарий используемых терминов и определений, применяется стандартизованная структура документа и т.д. Документы полуформального стиля изложения составляются по стандартному шаблону. В случае, если документ составляется на естественном языке, в нем следует использовать соответствующие данному языку термины и определения. Кроме того, в представление могут включаться более структурированные языковые средства или схемы (например, диаграммы потока данных, диаграммы переходных состояний, диаграммы вида "объекты-отношения", схемы представления структур данных, процессов или программ). Независимо от того, основывается ли представление на диаграммах и схемах или на средствах естественного языка, при его составлении необходимо соблюдение определенных правил. Приводимый глоссарий должен содержать полные, подробные, точные и однозначные определения использованных в документе слов и словосочетаний; стандартизованная структура документа должна подразумевать, что при методологическом составлении документа особое внимание было уделено тому, чтобы он был максимально понятен. Следует отметить, что совершенно разные части ФБО могут описываться с использованием различных правил полуформального стиля изложения, касающихся оформления и систем обозначений (по крайней мере, пока количество различных полуформальных систем обозначений невелико), это не противоречит принципам полуформального изложения.
Формальную спецификацию излагают с использованием обозначений, основанных на известных математических понятиях, и обычно сопровождают вспомогательным пояснительным (неформальным) текстом. Эти математические понятия используются для определения синтаксиса и семантики системы обозначений и правил доказательства, поддерживающих логическое обоснование. Следует, чтобы в синтаксических и семантических правилах, регламентирующих формальную нотацию, определялось, как однозначно распознавать конструкции и определять их значение. Требуется свидетельство невозможности получения противоречивых выводов, а все правила, регламентирующие систему обозначений, необходимо определить или на них необходимо ссылаться.
На рисунке 11 показаны семейства данного класса и иерархия компонентов в семействах.