Общая модель безопасности по ГОСТ Р ИСО/МЭК 15408

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

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

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

2.3 Эксплуатация  ОО

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 Понятия безопасности 

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 Описательные  возможности ОК 

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

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

Рисунок 6 - Организация и структура требований

Организация требований безопасности в ОК в виде иерархии класс - семейство - компонент призвана помочь потребителям в поиске конкретных требований безопасности.

Функциональные требования и требования доверия представлены в ОК в едином стиле с использованием одной и той же структуры и  терминологии.

1) Класс

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

Составляющие класса называются семействами.

2) Семейство

Семейство - это группа наборов  требований безопасности, имеющих общие  цели безопасности, но различающихся  акцентами или строгостью.

Составляющие семейства  называются компонентами.

3) Компонент

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