ГОСТРИСО/МЭК ТО 15446— 2008
модели политики безопасности, то должно использоваться семейство ADV_SPM (моделирование политики безо
пасности).
С.5.4 Проект и реализация объекта оценки
С.5.4.1 Общее доверие
С.5.4.1.1 Руководство
Необходимо уделить внимание тому, чтобы минимизировать и (где возможно) устранить ошибки проекти
рования и реализации. В ПЗ и ЗБ должно быть продемонстрировано, что. по крайней мере, высокоуровневая
архитектура ОО является надлежащей для реализации установленных функциональных требований.
Если требуется большая уверенность в проекте и его реализации, то может потребоваться демонстрация
того, что более низкие уровни проекта (потенциально до самого нижнего уровня) также отражают требуемые
функциональные возможности и были корректно уточнены по отношению к более высоким уровням проекта.
С.5.4.1.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408
Для обеспечения необходимой уверенности в правильности проекта и реализации ОО следует выбрать
соответствующие компоненты следующих семейств:
a) ADVJHLD (проект верхнего уровня):
b) ADV_LLD (проект нижнего уровня);
c) ADV_RCR (соответствие представлений);
d) ALC_TAT (инструментальные средства и методы).
Компоненты из семейства ADVJHLD должны использоваться для выражения требований к описанию ФБО
в терминах основных структурных частей (то есть подсистем) и связи этих частей с функциями, которые они выпол
няют. Компонент ADVJHLD.2 (детализация вопросов безопасности в проекте верхнего уровня) следует использо
вать. если есть требование по отделению криптографических границ ОО от границ ОО в целом.
Компоненты из семейства ADV_LLD следует использовать для выражения требований к описанию внутрен
него содержания ФБО в терминах модулей, их взаимосвязей и зависимостей.
Компоненты из семейства ADV_RCR следует использовать при наличии требований к демонстрации соот
ветствия между различными представлениями проекта.
Компонент ALC_TAT.2 следует использовать при наличии требования к выполнению разработки в соответ
ствии с конкретным стандартом реализации (например, стандарт кодирования).
С.5.4.2 Модульный проект
С.5.4.2.1 Руководство
Как уже отмечалось, разработчики криптографии обычно озабочены тем. что ошибка в одной части ОО
может повлиять на другие части ОО. и информация из одной части ОО может стать доступной для других частей
ОО, которым она не требуется. Эта озабоченность привела к следующим типам традиционных требований:
a) все входные данные, поступающие в ОО через интерфейс ввода данных, должны пройти только через
маршрут ввода данных;
b
) все выходные данные, выходящие из ОО через интерфейс вывода данных, должны пройти только через
маршрут вывода данных:
c) маршрут вывода данных должен быть логически отделен от системы и процессов генерации ключей,
ручного ввода ключей или обнуления ключей;
d) ОО должен поддерживать отдельные маршруты для открытых и закрытых данных.
Предназначение этих требований заключается в том. чтобы обеспечить техническое руководство, связан
ное с модульным проектированием, уменьшением сложности и минимизации негативных последствий ошибок в
какой-либо части системы.
С.5.4.2.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408
Для выражения требований к модульному проекту ОО в ПЗ и ЗБ следует выбрать компонент(ы) из следую
щих семейств:
a) ADV_FSP (функциональная спецификация):
b) ADV_HLD (проект верхнего уровня):
c) ADVJNT (внутренняя структура ФБО);
d) ADVJ.LD (проект нижнего уровня).
Например, проект нижнего уровня показывает все потоки данных и может быть использован для обеспече
ния уверенности в том. что входные, выходные данные, открытый и зашифрованный тексты доступны только
компонентам ОО. которым они необходимы. Требования модульности и иерархичности помогают обеспечить
уверенность в том. что ОО разрабатывается с использованием надлежащих принципов проектирования, и.
сле довательно. доступ к данным могут получить только те компоненты ОО. которым они необходимы.
В этом направлении существуют следующие элементы компонента ADVJNT.3 (минимизация сложности) из
семейства ADVJNT (внутренняя структура ФБО):
a) ADVJNT.3.3C — описание архитектуры должно содержать изложение, каким образом проект ФБО обес
печивает большую независимость модулей, чтобы избежать ненужного взаимодействия:
b) ADVJNT.3.5C — описание архитектуры должно показать, что взаимные связи были минимизированы, и
содержать строгое обоснование оставшихся связей:
76