ГОСТ Р ИСО/МЭКТО 15446 — 2008
вать ОУД1, так как требования данного ОУД не предусматривают анализ уязвимостей, которые могут ис
пользоваться нарушителями с высоким потенциалом (в частности. ОУД1 несодержит требования семейств
AVA_VLA или AVA_SOF);
b
) не является избыточным по отношению к среде безопасности и сформулированным целям безо
пасности:
c) является достижимым, то есть для данного типа ОО сформулированные требования доверия к
безопасности являются технически выполнимыми (с точки зрения стоимости и затрат времени на оценку
безопасности ОО).
13.3.3 Демонстрация пригодности требований к стойкости функций безопасности
В разделе «Обоснование ПЗ» необходимо показать, что требования к минимальной стойкости функ
ций безопасности и требования кстойкости функций безопасности, заданные в явном виде, согласуются со
сформулированными целями безопасности.
Практически это означает, что необходимо представить соответствующее обоснование, принимаю
щее во внимание:
a) присутствующие в формулировках целей безопасности для ОО в явном и неявном видах требова
ния кстойкости функций безопасности,
b
) присутствующую в формулировках целей безопасности или в описании среды безопасности ин
формацию о технической компетенции, ресурсах и мотивации нарушителей.
Если данные аспекты уже были учтены при обосновании пригодности требований безопасности, то
учитывать их еще раз нет необходимости.
13.3.4 Демонстрация взаимной поддержки требований безопасности
13.3.4.1 Краткий обзор
Назначениеданной части раздела «Обоснование ПЗ» заключается в том, чтобы показать, что требо
вания безопасности ИТ (и, в частности. ФТБ) полны и внутренне непротиворечивы, что достигается демон
страцией их взаимной поддержки, а такжетого, что они представляют собой «интегрированное иэффектив
ное целое». В этих целях рекомендуется следующий подход:
a)демонстрация того, что там. где необходимо, зависимости компонентов функциональных требова
ний и требований доверия кбезопасности удовлетворены;
b
)демонстрация внутренней непротиворечивости (согласованности) между требованиями безопасно
сти ИТ;
c)демонстрация того, что там, где необходимо, включены поддерживающие ФТБ, предназначенные
для защиты механизмов безопасности, реализующих другие ФТБ. от таких нападений как «обход» и «не
санкционированное изменение».
Далее рассмотрим каждый из перечисленных аспектов взаимной поддержки.
13.3.4.2 Анализ зависимостей компонентов
Данный анализ наиболее эффективно может быть представлен в форме таблицы или древовидной
схемы. Если требования доверия к безопасности целиком базируется на ОУД либо на другом пакете дове
рия к безопасности, то анализ зависимостей сводится к анализу только зависимостей ФТБ (так как в паке тах
доверия зависимости компонентов удовлетворены изначально).
Анализ зависимостей компонентов должен включать в себя:
a)демонстрацию на уровне ФТБ удовлетворения зависимостейдля каждой итерации функционально
го компонента:
b
) идентификацию каждой неудовлетворенной зависимости иобоснование отсутствия необходимости
в ее удовлетворении.
Необходимость проведения анализа зависимостей на уровне ФТБ обусловлена тем, что. если компо
нент включают в ПЗ неоднократно путем выполнения операции итерации, то может возникнуть необходи
мость выполнения операции итерации над компонентами, от которых зависит рассматриваемый компо
нент. Например, компонент FMT_MSA.3 «Инициализация статических атрибутов» зависит от компонента
FMT_MSA.1 «Управление атрибутами безопасности». Если компонент FMT_MSA.3 включают в ПЗ
неоднократно в целях инициализации различных атрибутовбезопасности, то. вероятно, и FMT_MSA.1необ
ходимо включить в ПЗ то же число раз в целях управления каждым из рассматриваемых атрибутов. В
этом случае вывод о том. что зависимость компонента FMT_MSA.3 надлежащим образом
удовлетворена в силу того, что функциональный компонент FMT_MSA.1 включен в ПЗ, будет не полон, так
как ФТБ компо нента FMT MSA.1 могут не охватывать все атрибуты безопасности, упомянутые в
ФТБ компонента FMT MSA.3!
35