Цель вида деятельности «Управление конфигурацией» состоит в том, чтобы помочь потребителю в идентификации оцененного ОО и удостовериться в том, что элементы конфигурации уникально идентифицированы, а также удостовериться в адекватности процедур, используемых разработчиком для управления и отслеживания изменений, вносимых в ОО. При этом детально должно быть рассмотрено, какие изменения отслеживают, каким образом вносят потенциальные изменения, а также степень использования автоматизации для уменьшения возможности ошибок.
13.4.1 Оценка автоматизации УК (ACM_AUT.1)
13.4.1.1 Цели
Цель данного подвида деятельности - сделать заключение, контролируется ли при поддержке автоматизированных инструментальных средств внесение изменений в представление реализации в целях достижения меньшей восприимчивости системы УК к человеческой ошибке или небрежности.
13.4.1.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является документация управления конфигурацией.
13.4.1.3 Действие ACM_AUT.1.1E
13.4.1.3.1 Шаг оценивания 4:ACM_AUT.1-1
ИСО/МЭК 15408-3 ACM_AUT.1.1C: Система УК должна предоставить автоматизированные средства, с использованием которых в представлении реализации ОО проводятся только санкционированные изменения.
Оценщик должен проверить план УК в части описания автоматизированных средств контроля доступа к представлению реализации ОО.
13.4.1.3.2 Шаг оценивания 4:ACM_AUT.1-2
Оценщик должен исследовать автоматизированные средства контроля доступа, чтобы сделать заключение об их эффективности для предотвращения несанкционированной модификации представления реализации ОО.
Оценщик изучает документацию УК, чтобы идентифицировать тех лиц или те роли, которые уполномочены изменять представление реализации ОО. Например, если представление реализации находится под управлением конфигурацией, то доступ к его элементу может быть разрешен только лицу, исполняющему роль интегратора программного обеспечения.
Оценщику следует опробовать автоматизированные средства контроля доступа, чтобы сделать заключение, может ли неуполномоченный пользователь или роль их обойти. Для заключения потребуется лишь несколько базовых тестов.
13.4.1.3.3 Шаг оценивания 4:ACM_AUT.1-3
ИСО/МЭК 15408-3 ACM_AUT.1.2C: Система УК должна предоставить автоматизированные средства для поддержки генерации ОО.
Оценщик должен проверить документацию УК в части автоматизированных средств поддержки генерации ОО из его представления реализации.
На этом шаге оценивания термин «генерация» применяют к процессам, принятым разработчиком для преобразования ОО из его реализации в состояние готовности к поставке конечному потребителю.
Оценщику следует верифицировать наличие автоматизированных процедур поддержки генерации в документации УК.
13.4.1.3.4 Шаг оценивания 4:ACM_AUT.1-4
Оценщик должен исследовать автоматизированные процедуры генерации, чтобы сделать заключение, могут ли они быть использованы для поддержки генерации ОО.
Оценщик делает заключение, что при следовании процедурам генерации будет сгенерирован ОО, отражающий
его представление реализации. Потребитель тогда может быть уверен, что версия ОО, поставленная для установки, реализует ПБО в соответствии с описанием в ЗБ. Например, в случае программного ОО это может предусматривать проверку того, что автоматизированные процедуры генерации помогают обеспечить включение в откомпилированный объектный код всех исходных файлов и связанных библиотек, направленных на осуществление ПБО.
Следует отметить, что это требование является только требованием предоставления поддержки. Например, подход, при котором исполняемые файлы Unix помещаются под управление конфигурацией, следует считать достаточным для достижения данной цели, учитывая, что такой подход к автоматизации существенно содействовал бы точной генерации ОО. Автоматизированные процедуры могут способствовать определению надлежащих элементов конфигурации, которые необходимо использовать при генерации ОО.
13.4.1.3.5 Шаг оценивания 4:ACM_AUT.1-5
ИСО/МЭК 15408-3 ACM_AUT.1.3C: План УК должен содержать описание автоматизированных инструментальных средств, используемых в системе УК.
Оценщик должен проверить, что план УК содержит информацию относительно автоматизированных инструментальных средств, используемых в системе УК.
13.4.1.3.6 Шаг оценивания 4:ACM_AUT.1-6
ИСО/МЭК 15408-3 ACM_AUT.1.4C: План УК должен содержать описание, как автоматизированные инструментальные средства используются в системе УК.
Оценщик должен исследовать информацию, относящуюся к автоматизированным инструментальным средствам, представленным в плане УК, чтобы сделать заключение, что в нем описано, как эти средства используются.
Информация, представленная в плане УК, обеспечивает необходимую детализацию для пользователя системы УК, чтобы дать возможность правильно использовать автоматизированные инструментальные средства для сохранения целостности ОО. Например, представленная информация может содержать описание:
a) функциональности, обеспечиваемой инструментальными средствами;
b) использования этой функциональности разработчиком для управления изменениями в представлении реализации;
c) использования этой функциональности разработчиком для поддержки генерации ОО.
13.4.1.4 Подразумеваемое действие оценщика
13.4.1.4.1 Шаг оценивания 4:ACM_AUT.1-7
ИСО/МЭК 15408-3 ACM_AUT.1.1D: Разработчик должен использовать систему УК.
Оценщик должен исследовать систему УК, чтобы сделать заключение, что использованы те автоматизированные инструментальные средства и процедуры, которые описаны в плане УК.
Этот шаг оценивания может быть рассмотрен как процесс, дополнительный по отношению к параллельно выполняемому оценщиком исследованию применения системы УК, требуемому АСМ_САР «Возможности УК». Оценщик старается получить свидетельство применения инструментальных средств и процедур. Для этого рекомендуется посетить объект разработки, чтобы лично убедиться в функционировании инструментальных средств и процедур, а также провести исследование свидетельств, получаемых при их применении.
Руководство по посещению объектов см. в А.5 «Посещение объектов» (приложение А).
Разработчик должен предусмотреть автоматизированные меры управления доступом как часть системы УК, а их пригодность может быть подтверждена в соответствии с компонентом
ACM_AUT.1 «Частичная автоматизация УК».
13.4.2.3.16 Шаг оценивания 4:ACM_CAP.4-16
ИСО/МЭК 15408-3 ACM_CAP.4.12C: Система УК должна поддерживать генерацию ОО.
Оценщик должен проверить документацию УК в части процедур поддержки генерации ОО.
На этом шаге оценивания термин «генерация» применяют к процессам, принятым разработчиком для преобразования ОО из его реализации в состояние готовности к поставке конечному потребителю.
Оценщик должен убедиться в существовании процедур поддержки генерации в документации УК. Процедуры поддержки генерации, предоставленные разработчиком, могут быть автоматизированы, и в таком случае их существование может быть подтверждено в соответствии с шагом оценивания 4:ACM_AUT.1-3.
13.4.2.3.17 Шаг оценивания 4:ACM_CAP.4-17
Оценщик должен исследовать процедуры генерации ОО, чтобы сделать заключение об их эффективности в обеспечении использования надлежащих элементов конфигурации при генерации ОО.
Оценщик делает заключение, что при следовании процедурам поддержки генерации версия ОО, ожидаемая потребителем (т.е. отвечающая описанию в ЗБ этого ОО и состоящая из надлежащих элементов конфигурации), была бы сгенерирована и поставлена для установки по месту расположения потребителя. Например, для программного ОО это может включать в себя проверку, что процедуры обеспечивают применение всех исходных файлов и связанных библиотек при создании откомпилированного объектного кода.
Оценщику следует иметь в виду, что система УК не обязательно обладает способностью генерировать ОО, но она должна оказывать поддержку процессу, который будет способствовать уменьшению вероятности субъективной ошибки.
13.4.2.3.18 Шаг оценивания 4:ACM_CAP.4-18
ИСО/МЭК 15408-3 ACM_CAP.4.13C: План приемки должен содержать описание процедур, используемых для приемки модифицированных или вновь созданных элементов конфигурации как части ОО.
Оценщик должен исследовать процедуры приемки, чтобы сделать заключение, что в них описаны критерии приемки, которые необходимо применять к вновь созданным или модифицированным элементам конфигурации.
План приемки описывает процедуры, которые необходимо использовать для обеспечения соответствующего качества составляющих частей ОО до их встраивания в ОО.
В плане приемки определяют применяемые процедуры приемки:
a) на каждой стадии «сборки» ОО (например, для модулей, их интеграции, системы в цепом);
b) для программных, программно-аппаратных и аппаратных компонентов;
c) для ранее оцененных компонентов.
Описание критериев приемки может содержать идентификацию:
a) ролей разработчиков или отдельных лиц, ответственных за приемку таких элементов конфигурации;
b) любых критериев приемки, применяемых до принятия элементов конфигурации (например, успешный просмотр документа или успешное тестирование в случае программного обеспечения, программируемого оборудования или аппаратных средств).
13.4.3 Оценка области УК (ACM_SCP.2)
13.4.3.1 Цели
Цель данного подвида деятельности - сделать
заключение, выполняет ли разработчик
управление конфигурацией для
представления реализации ОО, проекта,
тестов, руководств администратора и
пользователя, документации УК и
недостатков безопасности.
13.4.3.2 Исходные данные
Свидетельством оценки для этого подвида
деятельности является список элементов
конфигурации.
13.4.3.3 Действие ACM_SCP.2.1E
13.4.3.3.1 Шаг оценивания 4:ACM_SCP.2-1
ИСО/МЭК 15408-3 ACM_SCP.2.1C: Список элементов
конфигурации должен включать в себя следующее:
представление реализации, недостатки
безопасности и
свидетельства оценки, требуемые
компонентами доверия из ЗБ.
Оценщик должен проверить, что список
элементов конфигурации содержал
совокупность элементов, требуемую ИСО/МЭК
15408.
Как минимум, список должен содержать
следующее:
a) представление реализации ОО (т.е.
компоненты или подсистемы, которые
составляют ОО). Для полностью
программного ОО представление
реализации может состоять только из
исходного кода; для ОО, который включает
в себя аппаратную платформу,
представление реализации может
ссыпаться на комбинацию программных и
программно-аппаратных средств и
описание аппаратных средств;
b) свидетельства оценки, требуемые
компонентами доверия в ЗБ;
c) документацию, используемую для фиксации подробностей сообщенных недостатков безопасности, связанных с реализацией (например, сообщения о состоянии проблем, полученные из ведущейся разработчиком базы данных сообщений о проблемах).