ГОСТ Р ИСО/МЭК 15408-3—2002
АМА_АМР.1.1ОС План ПД должен содержать строгое обоснование, что идентифицированный
аналитик безопасности от разработчика хорошо знает задание побезопасности,
функциональнуюспецификацию и (где это необходимо) проект верхнегоуровня
ОС), а также результаты оценки и все примененные требования доверия для
сертифицированной версии ОО.
АМА_АМР. 1.11С План ПДдолжен содержать описание или иметь ссылки на процедуры, которые
предполагается применять для поддержки доверия к ОО и которые, как мини
мум, должны включать в себя процедуры управления конфигурацией, поддерж
ки свидетельства доверия, выполнения анализа влияния на безопасность изме
нений, воздействующих на ОО, и устранения недостатков.
Элементы действий оценщика
АМА_АМР.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет
всем требованиям к содержанию и представлениюсвидетельств.
АМА_АМР. 1.2Е Оценщик должен подтвердить, что нредюженные графики аудита ПД и пере
оценки ОО приемлемы и согласуются с предполагаемыми изменениями ОО.
16.2 Отчет о категорировании компонентов ОО (АМА_САТ)
Цели
Назначение отчета о категорировании компонентов ОО состоит втом, чтобыдополнить план ПД
обеспечением категорирования компонентов ОО (например, подсистем ФБО) согласно ихотношению
к безопасности. Категорирование занимает центральное место в анализе влияния на безопасность,
проводимом разработчиком, а также в последующей переоценке ОО.
Ранжирование компонентов
Семейство ЛМЛ CAT содержит только один компонент.
Замечания по применению
Термин «наименее абстрактное из представлений ФБО» в АМА_СЛТ.1 относится к наименее
абстрактному представлению ФБО. которое предоставлено для поддерживаемого уровня доверия. На
пример. если для ОО поддерживается уровень доверия ОУДЗ, то наименее абстрактное из прелогаше
ний ФБО —проект верхнего уровня. Следовательно, в этом случае необходимо категорировать следу
ющие компоненты ОО:
а) все внешние интерфейсы ФБО. которые могут быть идентифицированы вфункциональной
спецификации;
б) все подсистемы ФБО. которые могут быть идентифицированы в проекте верхнего уровня.
Вто время какданноесемейство содержит требованиеразделения по меньшей мере на .две катего
рии. может быть приемлемо (в зависимости от типа ОО) подразделитьддлее категорию, осуществля-
юшую IIБО. чтобы облегчитьанализ влияния на безопасность, проводимый разработчиком. Напри
мер. компоненты, осуществляющие ИБО. могли бы быть категорированы на критичныедля безопас
ности и на поддерживающие безопасность, где:
а) критичные для безопасности компоненты ОО —это те. которые несут непосредственную
ответственность заосуществление хотя бы одной функции безопасности ИТ, определенной в
задании по безопасности;
б) поддерживающие безопасность компоненты (Ю - это те, которые не несут непосредственную
ответственность за осуществление какой-либо функции безопасности И Г (и поэтому некри
тичны дтя безопасности), но на которые тем не менее налагаются при поддержке функций
безопасности ИТ; эта категория может, всвою очередь, включать в себя компоненты ООдвух
различныхтипов;
- способствующие выполнению критичных для безопасности компонентов ОО (поэтому для них
обязательно правильное функционирование).
—не способствующие выполнению критичных для безопасности компонентов ОО. нотем не
менее требующие доверия к тому, что ихрежим функционирования не является опасным (т. е.
не ведет к активизации уязвимостей).
ЛМЛ_СЛТ. 1.ЗС содержиттребование идентификации любых инструментальныхсредств разра
ботки. модификация которых повлияет на доверие к тому, что ОО удовлетворяет своему заданию по
безопасности (например, компилятора, используемогодля получения объектного кола).
АМА_САТ. 1Отчет о категорировании компонентов (К)
Зависимости
101