ГОСТ Р ИСО МЭК 15408-3 2007 (1027766), страница 21
Текст из файла (страница 21)
Если этот компонент сочетается с функциональными требованиями FPT_RVM.1 и FPT_SEP.3, то концепция монитора обращений будет полностью реализована.14.4.6.2 Элементы действий разработчика14.4.6.2.1ADV_INT.3.1DРазработчик должен проектировать и структурировать ФБО в модульном виде, избегая необязательных связей между модулями проекта.14.4.6.2.2ADV_INT.3.2DРазработчик должен представить описание архитектуры.14.4.6.2.3ADV_INT.3.3DРазработчик должен проектировать и структурировать ФБО по уровням с минимизацией взаимных связей между уровнями проекта.14.4.6.2.4ADV_INT.3.4DРазработчик должен проектировать и структурировать ФБО способом, минимизирующимсложность ФБО в целом.14.4.6.2.5ADV_INT.3.5DРазработчик должен проектировать и структурировать части ФБО, которые осуществляют какие-либо политики управления доступом и/или информационными потоками так,чтобы они были достаточно простыми для анализа.14.4.6.2.6ADV_INT.3.6DРазработчик должен обеспечить, чтобы функции, цели которых не имеют отношения кбезопасности, не включались в модули ФБО.14.4.6.3 Элементы содержания и представления свидетельств14.4.6.3.1ADV_INT.3.1CОписание архитектуры должно идентифицировать модули ФБО и специфицировать, какиечасти ФБО осуществляют политики управления доступом и/или управления информационными потоками.14.4.6.3.2ADV_INT.3.2CОписание архитектуры должно содержать изложение назначения, интерфейса, параметров ирезультатов применения каждого модуля ФБО.14.4.6.3.3ADV_INT.3.3C89ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)Описание архитектуры должно содержать изложение, каким образом проект ФБО обеспечивает большую независимость модулей, чтобы избежать ненужного взаимодействия.14.4.6.3.4ADV_INT.3.4CОписание архитектуры должно показать ее разбиение на уровни.14.4.6.3.5ADV_INT.3.5CОписание архитектуры должно показать, что взаимные связи были минимизированы, и содержать логическое обоснование оставшихся связей.14.4.6.3.6ADV_INT.3.6CОписание архитектуры должно содержать изложение, каким образом все ФБО структурированы для минимизации сложности.14.4.6.3.7ADV_INT.3.7CОписание архитектуры должно содержать логическое обоснование включения в ФБОкаждого модуля, не участвующего в осуществлении ПБО.14.4.6.4 Элементы действий оценщика14.4.6.4.1ADV_INT.3.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.14.4.6.4.2ADV_INT.3.2EОценщик должен сделать независимое заключение, что и проект нижнего уровня, и представление реализации согласуются с описанием архитектуры.14.4.6.4.3ADV_INT.3.3ЕОценщик должен подтвердить, что части ФБО, которые осуществляют какие-либо политики управления доступом и/или информационными потоками, достаточно просты дляанализа.14.5 Проект нижнего уровня (ADV_LLD)14.5.1ЦелиПроект нижнего уровня ОО содержит описание внутреннего содержания ФБО в терминахмодулей, их взаимосвязей и зависимостей.
Проект нижнего уровня обеспечивает доверие к тому,что подсистемы ФБО были правильно и эффективно уточнены.Для каждого модуля ФБО проект нижнего уровня описывает назначение, функции, интерфейсы, зависимости и реализацию всех функций, участвующих в осуществлении ПБО.14.5.2Ранжирование компонентовКомпоненты в этом семействе ранжированы на основе степени формализации, требуемойдля проекта нижнего уровня, и степени детализации, требуемой для спецификаций интерфейсов.14.5.3Замечания по применениюВыражение "модуль, осуществляющий ПБО" относится к любому модулю, на который необходимо полагаться для корректного осуществления ПБО.Выражение "функциональные возможности безопасности" используют, чтобы представитьсовокупность выполняемых модулем действий, которые участвуют в осуществлении функцийбезопасности, реализуемых ОО.
Это разграничение сделано потому, что модули не обязательнооднозначно отождествляются с конкретными функциями безопасности. В то время как данный модуль может прямо соответствовать как одной, так и нескольким функциям безопасности, возможно90ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)также, что несколько модулей необходимо объединить для реализации единственной функциибезопасности.Элементы ADV_LLD.*.6C содержат требование, чтобы проект нижнего уровня описал, какобеспечивается каждая из функций, осуществляющих ПБО. Смысл этого требования состоит втом, чтобы проект нижнего уровня содержал описание того, как планируется реализовать каждыймодуль, исходя из перспективы проекта.Элементы ADV_LLD.*.2E этого семейства определяют требование вынесения оценщикомнезависимого заключения, что проект нижнего уровня является точным и полным отображениемфункциональных требований безопасности ОО.
Этим обеспечивается прямое соответствие междуфункциональными требованиями безопасности ОО и проектом нижнего уровня в дополнение к попарным соответствиям, требуемым семейством ADV_RCR «Соответствие представлений». Ожидается, что оценщик использует свидетельство, включенное в ADV_RCR «Соответствие представлений», как основание для этого заключения, а требование полноты предполагает соотнесение суровнем абстракции проекта нижнего уровня.ADV_LLD.2.9C содержит требование полного представления интерфейсов модулей.
Этимбудет обеспечена необходимая детализация для поддержки как полного тестирования ОО (с использованием компонентов из семейства ATE_DPT «Глубина»), так и оценки уязвимостей.Применительно к уровню формализации проекта нижнего уровня неформальный, полуформальный и формальный проекты рассматривают как иерархичные по сути. Так, элементADV_LLD.1.1C может быть удовлетворен использованием полуформального или формальногопроекта нижнего уровня, а элемент ADV_LLD.2.1C – формального проекта нижнего уровня.14.5.4ADV_LLD.1Описательный проект нижнего уровняЗависимости: ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровняADV_RCR.1 Неформальная демонстрация соответствия14.5.4.1 Элементы действий разработчика14.5.4.1.1ADV_LLD.1.1DРазработчик должен представить проект нижнего уровня ФБО.14.5.4.2 Элементы содержания и представления свидетельств14.5.4.2.1ADV_LLD.1.1CПредставление проекта нижнего уровня должно быть неформальным.14.5.4.2.2ADV_LLD.1.2CПроект нижнего уровня должен быть внутренне непротиворечивым.14.5.4.2.3ADV_LLD.1.3CПроект нижнего уровня должен содержать описание ФБО в терминах модулей.14.5.4.2.4ADV_LLD.1.4CПроект нижнего уровня должен содержать описание назначения каждого модуля.14.5.4.2.5ADV_LLD.1.5CПроект нижнего уровня должен определить взаимосвязи между модулями в терминахпредоставляемых функциональных возможностей безопасности и зависимостей от другихмодулей.14.5.4.2.6ADV_LLD.1.6CПроект нижнего уровня должен содержать описание, как предоставляется каждая изфункций, осуществляющих ПБО.91ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)14.5.4.2.7ADV_LLD.1.7CПроект нижнего уровня должен идентифицировать все интерфейсы модулей ФБО.14.5.4.2.8ADV_LLD.1.8CПроект нижнего уровня должен идентифицировать, какие из интерфейсов модулейФБО являются видимыми извне.14.5.4.2.9ADV_LLD.1.9CПроект нижнего уровня должен содержать описание назначения и методов использования всех интерфейсов модулей ФБО, предоставляя, при необходимости, детализациюрезультатов, нештатных ситуаций и сообщений об ошибках.14.5.4.2.10ADV_LLD.1.10CПроект нижнего уровня должен содержать описание разделения ОО на модули, осуществляющие ПБО, и прочие.14.5.4.3 Элементы действий оценщика14.5.4.3.1ADV_LLD.1.1EОценщик должен подтвердить, что представленная информация удовлетворяет всемтребованиям к содержанию и представлению свидетельств.14.5.4.3.2ADV_LLD.1.2EОценщик должен сделать независимое заключение, что проект нижнего уровня – точное и полное отображение функциональных требований безопасности ОО.14.5.5ADV_LLD.2Полуформальный проект нижнего уровняЗависимости: ADV_HLD.3 Полуформальный проект верхнего уровняADV_RCR.2 Полуформальная демонстрация соответствия14.5.5.1 Элементы действий разработчика14.5.5.1.1ADV_LLD.2.1DРазработчик должен представить проект нижнего уровня ФБО.14.5.5.2 Элементы содержания и представления свидетельств14.5.5.2.1ADV_LLD.2.1CПредставление проекта нижнего уровня должно быть полуформальным.14.5.5.2.2ADV_LLD.2.2CПроект нижнего уровня должен быть внутренне непротиворечивым.14.5.5.2.3ADV_LLD.2.3CПроект нижнего уровня должен содержать описание ФБО в терминах модулей.14.5.5.2.4ADV_LLD.2.4CПроект нижнего уровня должен содержать описание назначения каждого модуля.14.5.5.2.5ADV_LLD.2.5CПроект нижнего уровня должен определить взаимосвязи между модулями в терминах предоставляемых функциональных возможностей безопасности и зависимостей от других модулей.14.5.5.2.6ADV_LLD.2.6CПроект нижнего уровня должен содержать описание, как предоставляется каждая из функций, осуществляющих ПБО.92ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)14.5.5.2.7ADV_LLD.2.7CПроект нижнего уровня должен идентифицировать все интерфейсы модулей ФБО.14.5.5.2.8ADV_LLD.2.8CПроект нижнего уровня должен идентифицировать, какие из интерфейсов модулей ФБО являются видимыми извне.14.5.5.2.9ADV_LLD.2.9CПроект нижнего уровня должен содержать описание назначения и методов использованиявсех интерфейсов модулей ФБО, предоставляя полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.14.5.5.2.10ADV_LLD.2.10CПроект нижнего уровня должен содержать описание разделения ОО на модули, осуществляющие ПБО, и прочие.14.5.5.3 Элементы действий оценщика14.5.5.3.1ADV_LLD.2.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.14.5.5.3.2ADV_LLD.2.2EОценщик должен сделать независимое заключение, что проект нижнего уровня – точное иполное отображение функциональных требований безопасности ОО.14.5.6ADV_LLD.3Формальный проект нижнего уровняЗависимости: ADV_HLD.5 Формальный проект верхнего уровняADV_RCR.3 Формальная демонстрация соответствия14.5.6.1 Элементы действий разработчика14.5.6.1.1ADV_LLD.3.1DРазработчик должен представить проект нижнего уровня ФБО.14.5.6.2 Элементы содержания и представления свидетельств14.5.6.2.1ADV_LLD.3.1CПредставление проекта нижнего уровня должно быть формальным.14.5.6.2.2ADV_LLD.3.2CПроект нижнего уровня должен быть внутренне непротиворечивым.14.5.6.2.3ADV_LLD.3.3CПроект нижнего уровня должен содержать описание ФБО в терминах модулей.14.5.6.2.4ADV_LLD.3.4CПроект нижнего уровня должен содержать описание назначения каждого модуля.14.5.6.2.5ADV_LLD.3.5CПроект нижнего уровня должен определить взаимосвязи между модулями в терминах предоставляемых функциональных возможностей безопасности и зависимостей от других модулей.14.5.6.2.6ADV_LLD.3.6CПроект нижнего уровня должен содержать описание, как предоставляется каждая из функций, осуществляющих ПБО.93ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)14.5.6.2.7ADV_LLD.3.7CПроект нижнего уровня должен идентифицировать все интерфейсы модулей ФБО.14.5.6.2.8ADV_LLD.3.8CПроект нижнего уровня должен идентифицировать, какие из интерфейсов модулей ФБО являются видимыми извне.14.5.6.2.9ADV_LLD.3.9CПроект нижнего уровня должен содержать описание назначения и методов использованиявсех интерфейсов модулей ФБО, предоставляя полную детализацию всех результатов, нештатныхситуаций и сообщений об ошибках.14.5.6.2.10ADV_LLD.3.10CПроект нижнего уровня должен содержать описание разделения ОО на модули, осуществляющие ПБО, и прочие.14.5.6.3 Элементы действий оценщика14.5.6.3.1ADV_LLD.3.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.14.5.6.3.2ADV_LLD.3.2EОценщик должен сделать независимое заключение, что проект нижнего уровня – точное иполное отображение функциональных требований безопасности ОО.14.6 Соответствие представлений (ADV_RCR)14.6.1ЦелиСоответствие между различными представлениями ФБО (т.е.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
