ГОСТ Р ИСО/МЭК 15408-3 — 2008
16.1.4.3.2 ALC_DVS.1.2E
Оценщикдолжен подтвердить применение мер безопасности.
16.1.5 ALC_DVS.2 Достаточность мор безопасности
Зависимости: нет зависимостей.
16.1.5.1 Элементы действий разработчика
16.1.5.1.1 ALC_DVS.2.1D
Разработчик должен разработать документациюпобезопасности разработки.
16.1.5.2 Элементы содержания и представления свидетельств
16.1.5.2.1 ALC_DVS.2.1C
Документация побезопасности разработки должна содержать описание всех физических, процедур
ных. относящихся к персоналуидругих мербезопасности, которые необходимыдля защиты конфиденци
альности и целостности проекта ОО и его реализации в среде разработки.
16.1.5.2.2 ALC_DVS.2.2C
Документация побезопасности разработки должна предоставить свидетельствотого, что необходи
мые меры безопасности соблюдаются во время разработки исопровождения ОО.
16.1.5.2.3 ALC_DVS.2.3C
Свидетельстводолжно содержать логическое обоснование того, что меры безопасности обес
печивают необходимый уровень защиты конфиденциальности и целостности ОО.
16.1.5.3 Элементы действий оценщика
16.1.5.3.1 ALC_DVS.2.1E
Оценщик должен подтвердить, чтопредставленная информация соответствует всем требованиям к
содержанию ипредставлению свидетельств.
16.1.5.3.2ALC_DVS.2.2E
Оценщикдолжен подтвердить применение мербезопасности.
16.2Устранение недостатков (ALC_FLR)
16.2.1 Цели
СемействоALC_FLR содержиттребование, чтобы обнаруженные недостатки безопасности были от
слежены и исправлены разработчиком. Хотя при оценке ОО не может быть сделано заключение о его
соответствии процедурам устранения недостатков в будущем, можно оценить политики ипроцедуры, кото
рые предусмотрены разработчиком для отслеживания и исправления недостатков, а также распростране
ния информациио недостатках и их исправлении.
16.2.2 Ранжирование компонентов
Компоненты в этом семействе ранжированы на основе расширения области применения процедур
устранения недостатков иповышения строгости политик устранения недостатков.
16.2.3 Замечания по применению
Данное семействообеспечиваетдоверие к сопровождению и поддержке ОО в будущем, требуя от
разработчикаОО отслеживатьи исправлять недостатки вОО. Кроме того, имеютсятребования по распро
странению сведений об исправлениях недостатков. Однако данное семейство не налагает требований,
выходящих за рамки текущей оценки.
Пользователь ОО считается основным лицом ворганизации, ответственным за получение ипримене
ние исправленийнедостатков безопасности.Таким лицомнеобязательно должен являться отдельный пользо
ватель. имможет быть представитель организации, ответственный заобработку недостатков безопасности.
Использование термина «пользователь ОО» предполагает, что в различных организациях имеются раз
личные процедуры обработки сообщений о недостатках, которые могупгвыполняться пользователями ин
дивидуально либо централизовано административным лицом.
Впроцедурах устранения недостатков следует описать методы реагирования на все типы встречаю
щихся недостатков. Некоторые недостатки не могут быть исправлены немедленно. Обэтих недостатках
могут сообщить разработчик ОО. пользователи ОО. другие стороны, знакомые с ОО. Не исключено, что
недостаток вообще не можетбыть исправлен, и необходимо применитьдругие (например, процедурные)
меры. Представленная документациядолжна охватывать процедуры пообеспечению исправлений в мес
тах эксплуатации, атакже предоставление информациио недостатках, для которых исправление отложено
(и чтоделать в этойситуации) или невозможно.
После того как оценка ОО завершена, он больше не является объектом оценки. Более того, любые
изменения, вносимые воцененный ОО. приводят ктому, что первоначальные результаты оценки не явля
ются большеприменимыми к измененной версии. Поэтому термин «релиз ОО». используемый в данном
семействе, относится к версии продукта или системы, являющейся релизом сертифицированного ОО. в
который были внесены изменения.
79