ГОСТ Р ИСО/МЭК 15408-3-2002
15.3.2 О т ч е то к а т е г о р и р о в а н и ик о м п о н е н т о вО О
Назначение отчета о категорировании компонентов (К) состоит в том, чтобыдополнить план Г1Д
категорированием компонентов ОО (например, подсистем ФЬО) по их отношению к безопасности.
Это категорирование занимает центральное место как ванализе влияния на безопасность, проводимом
разработчиком, так и при последующей переоценке ОО.
Проверка отчета о категорировании компонентов ОО происходит вфазе приемки, причем оцен
щик проверяеттолько версию отчета для сертифицированной версии ОО. Хотя процедуры поддержки
доверия, идентифицированные в плане ПД, требуют от разработчика обновления отчета о
категориро вании компонентов ОО по мере внесения изменений в ОО. от оценщика не требуется
делать заново обзор документа; вто же время любые такие обновления, вероятно, будут
внимательно проверяться в фазе мониторинга.
Отчет о категорировании компонентов ОО распространяется на все представления ФБО на под
держиваемом уровне доверия. Отчет о категорировании компонентов ОО также идентифицирует:
а) любые аппаратные, программно-аппаратные и программные компоненты, которые яатяются
внешними по отношению кОО (например, аппаратные или программные платформы) и
удовлетворяют требованиям безопасности ИТ, определенным в ЗБ;
б) любые инструментальные средства разработки, модификация которых будет влиять на требу
емое доверие к тому, что ОО удовлетворяет своему ЗБ.
Отчет о категорировании компонентов ОО также содержит описание подхода, используемого для
категорирования компонентов ОО. Как минимум, компоненты ООтребуется разделить на осуществля
ющие и не осуществляющие Г1БО. Описание схемы категорирования предназначено, чтобы дать воз
можность аналитику безопасности от разработчика выбрать категорию, к которой следует отнести
каждый новый компонент ОО, а также, когда потребуется, изменить категорию существующего
компонента ОО после изменений в ОО или его ЗБ.
Начальное категорирование компонентов ОО будетосновано на свидетельстве, представленном
разработчиком для поддержки оценки ОО и независимо подтвержденном оценщиком. Хотя за поддер
жку документа отвечает аналитик безопасности от разработчика, начальное его содержание может быть
основано на результатах оценки ОО.
Представляется полезным включать в ЗБ компонент ЛМА САТ.1, где имеется требование под
держки доверия в последующих версиях (X). Оно применяется независимо от того, достигается ли
поддержка доверия использованием требований этого класса или же периодической переоценкой ОО.
15.3.3 С в и д е т е л ь с т в оп о д д е р ж к ид о в е р и я
Необходимо убедиться втом, что доверие к ОО поддерживается разработчиком в соответствии с
планом ПД. Этодостигается путем подготовки свидетельства, которое демонстрирует поддержку дове
рия к ОО и независимо проверяется оценщиком. Эта проверка, называемая «аудит поддержки дове
рия* (аудит ПД). будет, как правило, применяться периодически вфазе мониторинга цикла поддерж ки
доверия к ОО.
Аудит ПД проводят в соответствии с графиком, определенным в плане ПД. Действия разработчи
ка и оценщика, требуемые вAMA_EVD. 1.будут выполняться один или несколько раз вфазе монито-
ринга цикла поддержки доверия. Оценщику, возможно, необходимо непосредственно ознакомиться с
условиями разработки ОО. чтобы выполнить экспертизу требуемого свидетельства, но не
исключают ся и другие способы проверки.
От разработчика требуется представить свидетельство следования процедурам поддержки дове
рия. указанным в плане ПД. Оно будет включать в себя:
а) записи управления конфигурацией;
б) документацию, используемую при анализе влияния на безопасность, включая текущую вер
сию отчета о категорировании компонентов ОО и свидетельства для всех примененных требований
доверия, такие как улучшения проекта, тестовая документация, новые версии руководств и т. д.;
в) свидетельство отслеживания недостатков безопасности.
Проверка оценщиком анализа шшяния на безопасность, проведенного разработчиком, (требуе
мая AMA_S1A. 1, от которого зависит AMAEVD. 1) займет центратьиое место ваудите ПД. Аудит ПД
будет, всвою очередь, способствовать подтверждению анализа, проведенного разработчиком (и.
сле довательно, уверенности в качестве анализа), обеспечивая подтверждение правильности
утверждения разработчика, чтодоверие к ОО поддерживается для его текущей версии.
При аудите ПД требуется, чтобы оценщик подтвердил выполнение функциональноготестирова
ния текущей версии ОО. Это выделяют в отдельную проверку, потому что тестовая документация
9К