ГОСТ Р ИСО МЭК 15408-3 2007 (1027766), страница 17
Текст из файла (страница 17)
Кроме того, имеется семейство требований для моделиПБО и для отображения соответствия между ПБО, моделью ПБО и функциональной спецификацией. И, наконец, имеется семейство требований к внутренней структуре ФБО, которое распространяется на такие аспекты, как модульность, разбиение на уровни и минимизация сложности.Парадигма для семейств данного класса – это одно из следующего: функциональная спецификация ФБО, декомпозиция ФБО на подсистемы, декомпозиция подсистем на модули, показ реализации модулей и демонстрация соответствия между всеми декомпозициями, которые предоставляются как свидетельства.
Требования для различных представлений ФБО выделены в разныесемейства, чтобы позволить разработчику ПЗ/ЗБ определить, какое именно подмножество представлений ФБО требуется.Источник соотносится с цельюСредаИсточник детализируется в целиAPE/ASE_OBJЦели безопасностиAPE/ASE_REQФункциональныетребования/ПБОADV_SPMASE_TSSКраткаяспецификация ООМодель ПБОADV_RCRADV_FSPФункциональнаяспецификацияADV_SPMADV_RCRADV_HLDПроект верхнегоуровняADV_RCRADV_LLDПроект нижнегоуровняADV_RCRADV_IMPПредставлениереализацииРисунок 10 – Связи между представлениями ОО и требованиями70ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)На рисунке 10 показаны связи между различными представлениями ФБО, целями и требованиями, с которыми они связаны. Классы APE и ASE определяют требования соответствия междуфункциональными требованиями и целями безопасности, а также между целями безопасности иожидаемой средой ОО. Класс ASE также определяет требования к соответствию между целямибезопасности, функциональными требованиями и краткой спецификацией ОО.Требования для всех других соответствий, показанных на рисунке 10, определены в классеADV «Разработка».
Семейство ADV_SPM «Моделирование политики безопасности» определяеттребования соответствия между ПБО и моделью ПБО, а также между моделью ПБО и функциональной спецификацией. Семейство ADV_RCR «Соответствие представлений» определяет требования соответствия между всеми имеющимися представлениями ФБО — от краткой спецификацииОО до представления реализации. Наконец, каждое семейство доверия, относящееся к конкретному представлению ФБО (т.е. ADV_FSP «Функциональная спецификация», ADV_HLD «Проектверхнего уровня», ADV_LLD «Проект нижнего уровня» и ADV_IMP «Представление реализации»),определяет требования, устанавливающие связь между представлением ФБО и функциональными требованиями, сочетание которых помогает убедиться в том, что функциональные требованиябезопасности ОО были учтены. Анализ прослеживания будет выполняться всегда, начиная с самого высокого уровня представления ФБО, включая каждое из имеющихся представлений ФБО.ГОСТ Р ИСО/МЭК 15408 реализует это требование прослеживания, используя зависимости от семейства ADV_RCR «Соответствие представлений».
Семейство ADV_INT «Внутренняя структураФБО» не представлено на рисунке 10, поскольку оно связано с внутренней структурой ФБО и имеет лишь косвенное отношение к процессу уточнения представлений ФБО.Политика безопасности ОО (ПБО) — совокупность правил, регулирующих управление ресурсами, их защиту и распределение в пределах ОО и выражаемых посредством функциональныхтребований безопасности ОО.
От разработчика в явном виде не требуется представление ПБО,поскольку ПБО выражается посредством функциональных требований безопасности ОО, черезсочетание политик функций безопасности (ПФБ) и других отдельных элементов требований.Функции безопасности ОО (ФБО) — совокупность всех функциональных возможностей различных частей ОО, направленных на осуществление ПБО.
ФБО включают в себя как функции, которые непосредственно осуществляют ПБО, так и функции, которые, не реализуя ПБО непосредственно, косвенно содействуют осуществлению ПБО.Хотя требования семейства ASE_TSS «Краткая спецификация ОО» и некоторых других семейств класса ASE предусматривают несколько различных представлений ФБО, совсем необязателен отдельный документ для каждого представления ФБО. Действительно, возможен случай, когда один документ выполняет требования по документированию нескольких представлений ФБО, аобъединение в нем требуемой информации по каждому из этих представлений ФБО предпочтительнее, несмотря на усложнение структуры данного документа. В случае, когда несколько представлений ФБО объединены в одном документе, разработчику следует указать конкретно, в какихдокументах какие представления содержатся.Этим классом узаконены три типа стиля изложения спецификаций: неформальный, полуформальный и формальный.
Функциональная спецификация, проект верхнего уровня, проект нижнего уровня и модель ПБО будут изложены с применением одного или нескольких из этих стилейспецификации. Неоднозначность в этих спецификациях уменьшается с повышением уровня формализации стиля изложения.Неформальную спецификацию излагают как текст на естественном языке. Под естественным языком здесь подразумевается применение выразительных средств общения любого разговорного языка (например, английского, немецкого, русского, французского). Неформальная спецификация не подчинена никаким нотационным или специальным ограничениям, отличным от общепринятых соглашений для этого языка (таких, как грамматика и синтаксис). Хотя не применяются никакие нотационные ограничения, в неформальной спецификации все же требуется привестиопределения значений терминов, использование которых в контексте отличается от общепринятого.71ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)Полуформальную спецификацию излагают на языке с ограниченным синтаксисом и обычносопровождают вспомогательным пояснительным (неформальным) текстом.
Язык с ограниченнымсинтаксисом может быть естественным языком с ограниченной структурой предложения и ключевыми словами со специальными значениями или же он может быть языком схем (таких, как схемыпотоков данных, переходов, взаимосвязей сущностей, структур данных и процессов или структурпрограмм). В обоих случаях обязателен набор соглашений, позволяющих определить ограничения, накладываемые на синтаксис.Формальную спецификацию излагают с использованием нотации, основанной на известныхматематических понятиях, и обычно сопровождают вспомогательным пояснительным (неформальным) текстом.
Эти математические понятия используют, чтобы определить синтаксис и семантику нотации и правила доказательства, поддерживающие логическую аргументацию. Следует,чтобы синтаксические и семантические правила, регламентирующие формальную нотацию, определяли, как однозначно распознавать конструкции и определять их значение. Требуется свидетельство невозможности вывода противоречий, а все правила, регламентирующие нотацию, необходимо определить или сослаться на них.Существенное доверие может быть достигнуто через обеспечение прослеживания ФБО докаждого из его представлений и соответствия модели ПБО функциональной спецификации.
Семейство ADV_RCR «Соответствие представлений» содержит требования к отображению соответствия между различными представлениями ФБО, а семейство ADV_SPM «Моделирование политики безопасности» – между моделью ПБО и функциональной спецификацией. Соответствие можетпринять форму либо неформальной или полуформальной демонстрации, либо формального доказательства.Когда требуется неформальная демонстрация соответствия, это означает, что требуетсятолько соответствие по сути. Методы демонстрации включают, например, использование двумерной таблицы с входами, обозначающими соответствие, или использование подходящей для этогонотации схем проекта. Могут быть также использованы указатели и ссылки на другие документы.Полуформальная демонстрация соответствия требует структурного подхода при анализесоответствия.
Следует, чтобы при этом подходе уменьшалась неоднозначность, которая можетсуществовать при неформальном соответствии, ограничивая интерпретацию применяемых терминов. Могут быть также использованы указатели и ссылки на другие документы.Формальное доказательство соответствия требует, чтобы были использованы известныематематические понятия для определения синтаксиса и семантики формальной нотации и правилдоказательства, которые поддерживают логическую аргументацию. Необходимо, чтобы свойствабезопасности могли быть выражены на языке формальной спецификации, и было показано, чтоэти свойства удовлетворяются формальной спецификацией.
Могут быть также использованы указатели и ссылки на другие документы.Элементы ADV_RCR.*.1C содержат требование, чтобы разработчик представил свидетельство для каждой смежной пары представлений ФБО, что все относящиеся к безопасности функциональные возможности более абстрактного представления ФБО уточнены в менее абстрактномпредставлении ФБО. Каждый из элементов ADV_FSP.*.2E, ADV_HLD.*.2E, ADV_LLD.*.2E иADV_IMP.*.2E содержит требование, чтобы оценщик сделал заключение о том, что ФБО, представляемые этим семейством требований – точное и полное отображение функциональных требований безопасности ОО.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
