в базе 1 113 607 документа
Последнее обновление: 18.04.2024

Законодательная база Российской Федерации

Расширенный поиск Популярные запросы

8 (800) 350-23-61

Бесплатная горячая линия юридической помощи

Навигация
Федеральное законодательство
Содержание
  • Главная
  • "МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)
действует Редакция от 18.12.2008 Подробная информация
"МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)

14.4 Внутренняя структура ФБО (ADV_INT)

14.4.1 Цели

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

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

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

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

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

14.4.2 Ранжирование компонентов

Компоненты в таком семействе ранжированы на основе требуемых структурированности и минимизации.

14.4.3 Замечания по применению

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

Элементы ADV_INT.2.5C и ADV_INT.3.5C связаны с минимизацией взаимодействий между уровнями иерархии. Взаимодействие между уровнями допустимо, но при этом от разработчика требуется показать, что эти взаимодействия необходимы и их невозможно избежать.

ADV_INT.2.6C относится к концепции монитора обращений, требуя минимизации сложности тех частей ФБО, которые осуществляют политики управления доступом и/или управления информационными потоками, идентифицированные в ПБО. ADV_INT.3.6C развивает далее концепцию монитора обращений, требуя минимизации сложности всех ФБО.

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

14.4.4 ADV_INT.1 Модульность

Зависимости: ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

14.4.4.1 Элементы действий разработчика

14.4.4.1.1 ADV_INT.1.1D

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

14.4.4.1.2 ADV_INT.1.2D

Разработчик должен представить описание архитектуры.

14.4.4.2 Элементы содержания и представления свидетельств

14.4.4.2.1 ADV_INT.1.1С

Описание архитектуры должно идентифицировать модули ФБО,

14.4.4.2.2ADV_INT.1.2C

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

14.4.4.2.3ADV_INT.1.3C

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

14.4.4.3 Элементы действий оценщика

14.4.4.3.1 ADV_INT.1.1E

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

14.4.4.3.2 ADV_INT.1.2E

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

14.4.5 ADV_INT.2 Уменьшение сложности

Зависимости: ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

14.4.5.1 Замечания по применению

Данный компонент обращается к концепции монитора обращений, требуя минимизации сложности тех частей ФБО, которые осуществляют идентифицированные в ПБО политики управления доступом и/или информационными потоками.

14.4.5.2 Элементы действий разработчика

14.4.5.2.1 ADV_INT.2.1D

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

14.4.5.2.2 ADV_INT.2.2D

Разработчик должен представить описание архитектуры.

14.4.5.2.3 ADV_INT.2.3D

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

14.4.5.2.4 ADV_INT2.4D

Разработчик должен проектировать и структурировать ФБО способом, минимизирующим сложность тех частей ФБО, которые осуществляют какие-либо политики управления доступом и/или информационными потоками,

14.4.5.3 Элементы содержания и представления свидетельств

14.4.5.3.1 ADV_INT2.1C

Описание архитектуры должно идентифицировать модули ФБО и специфицировать, какие части ФБО осуществляют политики управления доступом и/или информационными потоками.

14.4.5.3.2 ADV_INT2.2C

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

14.4.5.3.3 ADV_INT.2.3C

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

14.4 5.3.4 ADV_INT.2.4С

Описание архитектуры должно показать ее разбиение на уровни.

14.4.5.3.5 ADV_INT.2.5C

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

14.4.5.3.6 ADV_INT.2.6C

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

14.4.5.4 Элементы действий оценщика

14.4.5.4.1 ADV_INT.2.1E

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

14.4.5.4.2 ADV_INT.2.2E

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

14.4.6 ADV_INT.3 Минимизация сложности

Зависимости: ADV_IMP.2 Реализация ФБО

ADV_LLD.1 Описательный проект нижнего уровня

14.4.6.1 Замечания пo применению

Данный компонент содержит требование, - чтобы свойство монитора обращений "достаточно простой для анализа" полностью обеспечивалось. Если этот компонент сочетается с функциональными требованиями FPT_RVM.1 и FPT_SEP.3, то концепция монитора обращений будет полностью реализована.

14.4.6.2 Элементы действий разработчика

14.4.6.2.1 ADV_INT.3.1D

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

14.4.6.2.2 ADV_INT.3.2D Разработчик должен представить описание архитектуры.

14.4.6.2.3 ADV_INT.3.3D

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

14.4.6.2.4 ADV_INT.3.4D

Разработчик должен проектировать и структурировать ФБО способом, минимизирующим сложность ФБО в целом.

14.4.6.2.5 ADV_INT.3.5D

Разработчик должен проектировать и структурировать части ФБО, осуществляющие какие-либо политики управления доступом и/или информационными потоками, так, чтобы они были достаточно простыми для анализа.

14.4.6.2.6 ADV_INT.3.6D

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

14.4.6.3 Элементы содержания и представления свидетельств

14.4.6.3.1 ADV_INT.3.1С

Описание архитектуры должно идентифицировать модули ФБО и специфицировать, какие части ФБО осуществляют политики управления доступом и/или управления информационными потоками.

14.4.6.3.2 ADV_INT.3.2C

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

14.4.6.3.3 ADV_INT.3.3C

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

14.4.6.3.4 ADV_INT.3.4C

Описание архитектуры должно показать ее разбиение на уровни.

14.4.6.3.5 ADV_INT.3.3C

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

14.4.6.3.6 ADV_INT.3.6C

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

14.4.6.3.7 ADV_INT.3.7C

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

14.4.6.4 Элементы действий оценщика

14.4.6.4.1 ADV_INT.3.1E

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

14.4.6.4.2 ADV_INT.3.2E

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

14.4.6.4.3 ADV_INT.3.3E

Оценщик должен подтвердить, что части ФБО, осуществляющие какие-либо политики управления доступом и/или, информационными потоками, достаточно просты для анализа,

  • Главная
  • "МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)