ГОСТ Р ИСО МЭК 15408 2002 МЭК 1

Рисунок 4. 3 – Модель разработки ОО

Рисунок 4.3 – Модель разработки ОО

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

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

OK не предписывают конкретную совокупность представлений проекта. В ОК требуется, чтобы имелось достаточное число представлений с достаточным уровнем детализации для демонстрации, если потребуется, того, что:

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

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

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

4.2.2 Оценка ОО

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

а) совокупность свидетельств, характеризующих ОО, включая прошедшее оценку ЗБ в качестве основы оценки ОО;

б) ОО, безопасность которого требуется оценить;

в) критерии, методология и система оценки.

Рисунок 4. 5 – Последовательное формирование требований и спецификаций

Рисунок 4.5 – Последовательное формирование требований и спецификаций

4.3.1 Среда безопасности

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

При установлении среды безопасности автор ПЗ или ЗБ должен принять во внимание:

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

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

в) предназначение ОО, включая тип продукта и предполагаемую сферу его применения.

На основании исследования политик безопасности, угроз и рисков следует сформировать материалы, относящиеся к безопасности ОО;

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

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

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

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

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

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

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

Требования безопасности ИТ проистекают только из целей безопасности ОО и целей безопасности его среды, относящихся к ИТ.

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

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

В ОК представлены две различные категории требований безопасности – функциональные требования и требования доверия.

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

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

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

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

а) уверенности в корректности реализации функций безопасности, т.е. оценки того, правильно ли они реализованы;

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

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

4.3.4 Краткая спецификация ОО

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

4.3.5 Реализация ОО

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

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

4.4.1 Представление требований безопасности

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

Рисунок 4. 2 – Понятия, используемые при оценке, и их взаимосвязь

Рисунок 4.2 – Понятия, используемые при оценке, и их взаимосвязь

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

4.1.2 Контекст безопасности информационных технологий

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

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

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

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

Уверенность в безопасности ИТ может быть достигнута в результате действий, которые могут быть предприняты в процессе разработки, оценки и эксплуатации ОО.

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

Спецификация заданий по безопасности

ЗБ содержит требования безопасности ИТ для конкретного ОО и специфицирует
функции безопасности и меры доверия, предлагаемые объектом оценки для
удовлетворения установленных требований.

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

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

Данное приложение содержит требования к ЗБ в описательной форме. В
классе доверия ASE, в разделе 5 ГОСТ Р ИСО/МЭК 15408-3 эти требования приведены в форме компонентов доверия, которые следует
использовать при оценке ЗБ.

В.2.1. Содержание и представление ЗБ

Содержание ЗБ представлено на рисунке В.1, который рекомендуется
использовать при создании структурной схемы ЗБ.

В.2.2. Введение ЗБ

Введение ЗБ должно содержать информацию для управления документооборотом
и обзорную информацию:

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

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

в) утверждение о
соответствии ОК должно изложить каждое поддающееся оценке утверждение о
соответствии ОО общим критериям, как указано в подразделе 5.4.

В.2.3. Описание ОО

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

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

В.2.4. Среда безопасности ОО

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

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

– информацию относительно
предполагаемого использования ОО, включая такие аспекты, как предполагаемая
область применения, потенциальная значимость активов и возможные ограничения на
использование;

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

Рисунок В. 1 – Содержание задания по безопасности

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

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

Если цели безопасности ОО следуют только из политики безопасности
организации и предположений, то описание угроз может быть опущено.

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

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

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

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

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

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

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

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

В.2.6. Требования
безопасности ИТ

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

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

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

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

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

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

2) При изложении требований доверия к безопасности ОО следует
определить их как один из ОУД, возможно, усиленный другими компонентами доверия
из части 3 ОК. Расширение ОУД в ЗБ может осуществляться за счет явного включения
дополнительных компонентов доверия, не содержащихся в этой части.

б) Необязательное изложение требований
безопасности для среды ИТ должно определять требования безопасности ИТ,
которым должна отвечать среда ИТ этого ОО. Если безопасность ОО не зависит от
среды ИТ, то эта часть ЗБ может быть опущена.

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

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

1) Когда это применимо, все требования безопасности ИТ следует вводить
ссылкой на компоненты требований безопасности из частей 2 и 3 ОК. Если при
формировании всех либо части требований не применимы компоненты из частей 2 или
3, то в ЗБ допускается необходимые требования безопасности сформулировать явным
образом, без ссылки на содержание ОК.

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

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

4) Следует удовлетворить все зависимости между требованиями безопасности
ИТ. Зависимости могут быть удовлетворены включением необходимых требований в состав
требований безопасности ОО или требований к среде.

В.2.7. Краткая спецификация ОО

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

Краткая спецификация ОО включает в себя следующее.

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

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

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

3) Если в состав требований доверия к ОО включен компонент AVA_SОF.1, то должны быть идентифицированы все функции безопасности ИТ,
реализованные с помощью вероятностного или перестановочного механизма
(например, пароля или хэш-функции). Возможность нарушения механизмов таких
функций посредством преднамеренного или случайного воздействия имеет
непосредственное отношение к безопасности ОО. Должен быть проведен анализ
стойкости всех этих функций. Стойкость каждой идентифицированной функции должна
быть определена и заявлена либо как базовая СФБ, средняя СФБ или высокая СФБ,
либо с применением дополнительно введенной метрики стойкости. Свидетельство,
приводимое в отношении стойкости функции безопасности, должно быть достаточным,
чтобы позволить оценщикам сделать свою независимую оценку и подтвердить, что
утверждения о стойкости адекватны и корректны.

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

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

В.2.8. Утверждения о соответствии ПЗ

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

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

а) Если утверждений о
соответствии ПЗ нет, то следует привести полное описание целей и требований
безопасности ОО, как определено в данном приложении. При этом данный раздел ЗБ
опускается.

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

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

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

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

Если сделано утверждение о соответствии какому-либо ПЗ, то изложение
утверждений о соответствии должно содержать следующий материал для каждого ПЗ.

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

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

и) Дополнение ПЗ, идентифицирующее цели и
требования безопасности ОО, которые дополняют цели и требования ПЗ.

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

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

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

1) сочетание отдельных компонентов функциональных требований и
требований доверия для ОО и его среды ИТ в совокупности отвечает изложенным
целям безопасности;

2) данный набор требований безопасности образует единое и внутренне
непротиворечивое целое;

3) выбор требований безопасности строго обоснован. При этом должны быть
строго обоснованы:

– выбор требований, не
содержащихся в частях 2 или 3 ОК,

– выбор требований доверия,
не включенных в какой-либо ОУД,

– случаи неудовлетворения
зависимостей;

4) выбранный для ЗБ уровень стойкости функций и заявленная в явном виде
стойкость функций согласуются с целями безопасности для ОО.

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

1) сочетание специфицированных для ОО функций безопасности ИТ при
совместном использовании удовлетворяет функциональным требованиям безопасности
ОО;

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

3) строго обосновано утверждение, что изложенные меры доверия
соответствуют требованиям доверия.

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

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

Этот потенциально объемный материал разрешается распространять отдельно,
поскольку он необходим или полезен не для всех пользователей ЗБ.

Спецификация профилей защиты

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

Данное приложение содержит требования к ПЗ в описательной форме. В
классе доверия АРЕ, в разделе 4 ГОСТ Р ИСО/МЭК 15408-3 эти требования приведены в форме компонентов доверия, которые следует
использовать при оценке ПЗ.

Б.2.1. Содержание и представление

Содержание ПЗ представлено на рисунке Б.1, который следует
использовать при создании структурной схемы разрабатываемого ПЗ.

Б.2.2. Введение ПЗ

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

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

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

Б.2.3. Описание ОО

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

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

Б.2.4. Среда безопасности ОО

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

Если цели безопасности ОО
следуют только из политики безопасности организации и предположений, то
описание угроз может быть опущено.

Рисунок Б.1 – Содержание профиля защиты

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

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

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

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

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

Б.2.6. Требования безопасности ИТ

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

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

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

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

2) При изложении требований доверия к безопасности ОО следует
определить их как один из ОУД, возможно, усиленный другими компонентами доверия
из части 3 ОК. Расширение ОУД в ПЗ может осуществляться за счет явного
включения дополнительных компонентов доверия, не содержащихся в этой части.

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

1) Когда это применимо, все требования безопасности ИТ следует вводить
ссылкой на компоненты требований безопасности из частей 2 и 3 ОК. Если при
формировании всех либо части требований не применимы компоненты из частей 2 или
3, то в ПЗ допускается сформулировать необходимые требования безопасности явным
образом, без ссылки на содержание ОК.

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

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

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

5) Следует удовлетворить все зависимости между требованиями безопасности
ИТ. Зависимости могут быть удовлетворены включением необходимых требований в
состав требований безопасности ОО или требований к среде.

Б.2.7. Замечания по применению

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

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

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

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

3) выбор требований безопасности строго обоснован. Каждое из
перечисленных ниже условий должно быть строго обосновано:

– выбор требований, не
содержащихся в частях 2 или 3 ОК;

– выбор требований доверия,
не включенных в какой-либо ОУД;

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

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

ПРИЛОЖЕНИЕ А (справочное)

Проект Общих критериев

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

ПРИЛОЖЕНИЕ Г (справочное)

Текст документа сверен по:

М.: ИПК Издательство стандартов, 2002