LINEBURG


<< Пред. стр.

страница 4
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>

список конфигурации.
22
Список конфигурации идентифицирует элементы, находящиеся под управлением
138

конфигурацией.
ACM_CAP.2.4C
Оценщик должен исследовать список конфигурации, чтобы сделать заключение,
ACM_CAP.2-5
что он идентифицирует элементы конфигурации, входящие в состав ОО.
Минимальный состав элементов конфигурации, которые необходимо включить в список
139

конфигурации, задается требованиями семейства ACM_SCP. Если компоненты из
ACM_SCP не используются, список конфигурации охватывает тот ОО, который
поставляется потребителю. В общем случае в него следует включить документацию
пользователя и администратора, а также аппаратные средства, программно-аппаратные
средства и программное обеспечение ОО. Аппаратные, программно-аппаратные и
программные элементы конфигурации ОО следует контролировать либо на уровне
представления реализации, либо на уровне собственно ОО, например, объектного кода или
аппаратных средств. Степень детализации элементов конфигурации оставлена на
усмотрение разработчика.
ACM_CAP.2.5C
Оценщик должен исследовать способ идентификации элементов конфигурации,
ACM_CAP.2-6
чтобы сделать заключение, что он описывает, каким образом элементы
конфигурации идентифицируются уникально.
ACM_CAP.2.6C
Оценщик должен проверить, что список конфигурации уникально
ACM_CAP.2-7
идентифицирует каждый элемент конфигурации.
Список конфигурации содержит список элементов конфигурации, которые составляют ОО,
140

вместе с достаточной информацией для уникальной идентификации, какая версия каждого
элемента использовалась (обычно номер версии). Использование этого списка позволит
оценщику проверить, что во время оценки использовались соответствующие элементы
конфигурации и соответствующая версия каждого элемента.
3.4.3 Подвид деятельности ACM_CAP.3
3.4.3.1 Цели
Цель данного подвида деятельности – сделать заключение, четко ли разработчик
141

идентифицировал ОО и связанные с ним элементы конфигурации, а также контролируется
ли должным образом возможность изменения этих элементов.
3.4.3.2 Исходные данные
Свидетельства оценки для этого подвида деятельности:
142

а) ЗБ;
б) ОО, пригодный для тестирования;
в) документация управления конфигурацией.
3.4.3.3 Действия оценщика
Этот подвид деятельности включает один элемент действий оценщика из части 3 ОК:
143

а) ACM_CAP.3.1E.




23
3.4.3.3.1 Действие ACM_CAP.3.1E
ACM_CAP.3.1C
Оценщик должен проверить, что версия ОО, представленная для оценки,
ACM_CAP.3-1
уникально маркируется.
Оценщику следует использовать систему УК, применяемую разработчиком, для
144

подтверждения уникальности маркировки, проверяя список конфигурации с целью
удостовериться, что элементы конфигурации уникально идентифицированы. Свидетельство
уникальной маркировки версии ОО, представленной для оценки, может оказаться
неполным, если во время оценки исследовалась только одна версия; поэтому оценщику
рекомендуется выяснить систему маркирования, которая может поддерживать уникальную
маркировку (например, используя цифры, буквы или даты). Тем не менее, отсутствие
какой-либо маркировки обычно будет приводить к отрицательному заключению по этому
требованию, пока оценщик не станет уверен в возможности уникальной идентификации
ОО.
Оценщику следует стремиться исследовать несколько версий ОО (например, полученных в
145

ходе доработки после обнаружения уязвимости) для проверки, что любые две версии
маркированы по-разному.
ACM_CAP.3.2C
Оценщик должен проверить, что ОО, представленный для оценки, помечен его
ACM_CAP.3-2
маркировкой.
Оценщику следует удостовериться, что ОО содержит уникальную маркировку,
146

позволяющую отличать разные версии ОО. Этого можно достичь, используя помеченную
упаковку или носители, или же метку, отображаемую ОО при функционировании. Это
обеспечивает потребителю возможность идентификации ОО (например, в месте
приобретения или использования).
ОО может предоставить способ, посредством которого он может быть легко
147

идентифицирован. Например, программный ОО может отображать свое название и номер
версии при запуске программы или в ответ на запрос через командную строку. Аппаратный
или программно-аппаратный ОО может быть идентифицирован путем физического
нанесения на нем соответствующего номера.
Оценщик должен проверить непротиворечивость используемой маркировки ОО.
ACM_CAP.3-3
Если ОО помечен несколько раз, то необходима согласованность меток. Например, следует
148

предусмотреть возможность связать любое помеченное руководство, поставляемое в
составе ОО, с оцененным функционирующим ОО. Этим обеспечивается уверенность
потребителя в том, что он приобрел оцененную версию ОО, установил эту же версию и
располагает надлежащей версией руководства, необходимой для функционирования
данного ОО в соответствии с его ЗБ. Оценщик может использовать список конфигурации,
который является частью представленной документации УК, чтобы верифицировать
согласованное использование идентификаторов.
Оценщик также верифицирует, что маркировка ОО согласуется с ЗБ.
149

Руководство по анализу непротиворечивости см. в подразделе 10.3.
150

ACM_CAP.3.3C
Оценщик должен проверить, что представленная документация УК включает
ACM_CAP.3-4
список конфигурации.
24
Список конфигурации идентифицирует элементы, находящиеся под управлением
151

конфигурацией.
Оценщик должен проверить, что представленная документация УК содержит
ACM_CAP.3-5
план УК.
ACM_CAP.3.4C
Оценщик должен исследовать список конфигурации, чтобы сделать заключение,
ACM_CAP.3-6
что он идентифицирует элементы конфигурации, входящие в состав ОО.
Минимальный состав элементов конфигурации, которые необходимо включить в список
152

конфигурации, задается требованиями семейства ACM_SCP. Если компоненты из
ACM_SCP не используются, список конфигурации охватывает тот ОО, который
поставляется потребителю. В общем случае в него следует включить документацию
пользователя и администратора, а также аппаратные средства, программно-аппаратные
средства и программное обеспечение ОО. Аппаратные, программно-аппаратные и
программные элементы конфигурации ОО следует контролировать либо на уровне
представления реализации, либо на уровне собственно ОО, например, объектного кода или
аппаратных средств. Степень детализации элементов конфигурации оставлена на
усмотрение разработчика.
ACM_CAP.3.5C
Оценщик должен исследовать способ идентификации элементов конфигурации,
ACM_CAP.3-7
чтобы сделать заключение, что он описывает, каким образом элементы
конфигурации идентифицируются уникально.
ACM_CAP.3.6C
Оценщик должен проверить, что список конфигурации уникально
ACM_CAP.3-8
идентифицирует каждый элемент конфигурации.
Список конфигурации содержит список элементов конфигурации, которые составляют ОО,
153

вместе с достаточной информацией для уникальной идентификации, какая версия каждого
элемента использовалась (обычно номер версии). Использование этого списка позволит
оценщику проверить, что во время оценки использовались соответствующие элементы
конфигурации и соответствующая версия каждого элемента.
ACM_CAP.3.7C
Оценщик должен исследовать план УК, чтобы сделать заключение, что он
ACM_CAP.3-9
описывает, как система УК используется в целях сохранения целостности
элементов конфигурации ОО.
Описания, содержащиеся в плане УК, могут включать:
154

а) все операции, выполняемые в среде разработки ОО, которые подчинены процедурам
управления конфигурацией (например, создание, модификация или удаление элемента
конфигурации);
б) роли и обязанности лиц, требуемые для выполнения операций на отдельных элементах
конфигурации (для различных типов элементов конфигурации, например, для
документации и исходного кода, могут быть идентифицированы различные роли);
в) процедуры, которые используются для обеспечения того, чтобы только
уполномоченные лица могли изменять элементы конфигурации;
г) процедуры, которые используются для обеспечения отсутствия проблем параллелизма,
возникающих в результате одновременных изменений элементов конфигурации;

25
д) свидетельство, которое генерируется в результате применения процедур. Например,
при изменении элемента конфигурации система УК могла бы зафиксировать описание
изменения, ответственность за изменение, идентификацию всех затронутых элементов
конфигурации, статус изменения (например, "не завершено" или "завершено"), а также дату
и время внесения изменения. Эта информация могла бы заноситься в журнал аудита
произведенных изменений или в протокол контроля изменений;
е) подход к контролю версий и уникальной маркировке версий ОО (охватывающий,
например, выпуск исправлений («патчей») для операционных систем и последующее
обнаружение их применения).
ACM_CAP.3.8C
ACM_CAP.3-10 Оценщик должен проверить документацию УК, чтобы удостовериться, что она
включает записи системы УК, определенные планом УК.
Следует, чтобы выходные материалы системы УК обеспечили свидетельство, необходимое
155

оценщику для уверенности, что план УК применяется, а все элементы конфигурации
поддерживаются системой УК, как это требуется в ACM_CAP.3.9C. Пример выходных
материалов мог бы включать формы контроля изменений или формы разрешения доступа к
элементам конфигурации.
Оценщик должен исследовать свидетельство, чтобы сделать заключение, что
ACM_CAP.3-11
система УК используется в соответствии с планом УК.
Оценщику следует осуществить и исследовать выборку из свидетельства, охватывающую
156

каждый тип операций под УК, выполняемых на элементах конфигурации (например,
создание, модификация, удаление, возврат к более ранней версии), чтобы подтвердить, что
все операции системы УК выполнялись в соответствии с задокументированными
процедурами. Оценщик подтверждает, что свидетельство включает всю информацию,
идентифицированную для этой операции в плане УК. При исследовании свидетельства
может потребоваться доступ к используемым инструментальным средствам УК. Оценщику
разрешается остановиться на выборочной проверке свидетельства.
Руководство по выборке см. в подразделе 10.2.
157

Дополнительная уверенность в правильном функционировании системы УК и
158

эффективном сопровождении элементов конфигурации может быть получена посредством
проведения интервью с отобранными для этого участниками разработки. При проведении
подобных интервью оценщику следует стремиться получить более глубокое понимание
практического применения системы УК, а также убедиться, что процедуры УК
применяются в соответствии с документацией УК. Отметим, что такие интервью следует
проводить скорее в дополнение, а не вместо исследования документального свидетельства;
при этом они могут и не потребоваться, если документальное свидетельство само по себе
удовлетворяет требованиям. Тем не менее, учитывая широкую область применения плана
УК, возможно, что некоторые аспекты (например, роли и обязанности) могут быть
непонятны из одного только плана и протоколов УК. Это один из случаев, когда для
дополнительного разъяснения понадобится интервью.
Предполагается, что для поддержки этих действий оценщик посетит объект разработки.
159

Руководство по посещению объектов см. в подразделе 10.5.
160




26
ACM_CAP.3.9C
ACM_CAP.3-12 Оценщик должен проверить, что элементы конфигурации, идентифицированные
в списке конфигурации, сопровождаются системой УК.
Система УК, используемая разработчиком, предназначена для сохранения целостности ОО.
161

Оценщику следует проверить, чтобы для каждого типа элементов конфигурации
(например, проекта верхнего уровня или модулей исходного кода), содержащегося в списке
конфигурации, были примеры свидетельства, сгенерированного процедурами, описанными
в плане УК. В этом случае подход к выборке будет зависеть от степени детализации,
используемой в системе УК при управлении элементами конфигурации. Если, например, в
списке конфигурации идентифицированы 10000 модулей исходного кода, то следует
применить стратегию выборки, отличающуюся от применяемой в случае, когда их только
пять или всего один. Особое внимание в данном виде деятельности следует уделить тому,
чтобы убедиться в правильном функционировании УК, а не обнаружению какой-либо
незначительной ошибки.
Руководства по выборке см. в подразделе 10.2.
162

ACM_CAP.3.10C
ACM_CAP.3-13 Оценщик должен исследовать меры контроля доступа в УК, описанные в плане
УК, чтобы сделать заключение об их эффективности по предотвращению
несанкционированного доступа к элементам конфигурации.
Оценщику разрешается использовать несколько методов для заключения об эффективности
163

мер контроля доступа в УК. Например, оценщик может опробовать меры контроля доступа,
чтобы удостовериться, что процедуры нельзя обойти. Оценщику разрешается использовать
выходные материалы, сгенерированные процедурами системы УК и уже подвергавшиеся
исследованию на шаге оценивания ACM_CAP.3-12. Оценщику может быть также
продемонстрирована система УК, чтобы он убедился, что используемые меры контроля
доступа выполняются эффективно.
Если компонент семейства ACM_AUT включен в требования доверия, то пригодность
164

любых мер автоматизации управления доступом может быть верифицирована в
соответствующем этому компоненту подвиде деятельности.
3.4.4 Подвид деятельности ACM_CAP.4
3.4.4.1 Цели
Цель данного подвида деятельности – сделать заключение, четко ли разработчик
165

идентифицировал ОО и связанные с ним элементы конфигурации, а также контролируется
ли должным образом возможность изменения этих элементов.
3.4.4.2 Исходные данные
Свидетельства оценки для этого подвида деятельности:
166

а) ЗБ;
б) ОО, пригодный для тестирования;
в) документация управления конфигурацией.
3.4.4.3 Действия оценщика
Этот подвид деятельности включает один элемент действий оценщика из части 3 ОК:
167

а) ACM_CAP.4.1E.



27
3.4.4.3.1 Действие ACM_CAP.4.1E
ACM_CAP.4.1C
Оценщик должен проверить, что версия ОО, представленная для оценки,
ACM_CAP.4-1
уникально маркируется.
Оценщику следует использовать систему УК, применяемую разработчиком, для
168

подтверждения уникальности маркировки, проверяя список конфигурации с целью
удостовериться, что элементы конфигурации уникально идентифицированы. Свидетельство
уникальной маркировки версии ОО, представленной для оценки, может оказаться
неполным, если во время оценки исследовалась только одна версия; поэтому оценщику
рекомендуется выяснить систему маркирования, которая может поддерживать уникальную
маркировку (например, используя цифры, буквы или даты). Тем не менее, отсутствие
какой-либо маркировки обычно будет приводить к отрицательному заключению по этому
требованию, пока оценщик не станет уверен в возможности уникальной идентификации
ОО.
Оценщику следует стремиться исследовать несколько версий ОО (например, полученных в
169

ходе доработки после обнаружения уязвимости) для проверки, что любые две версии
маркированы по-разному.
ACM_CAP.4.2C
Оценщик должен проверить, что ОО, представленный для оценки, помечен его
ACM_CAP.4-2
маркировкой.
Оценщику следует удостовериться, что ОО содержит уникальную маркировку,
170

позволяющую отличать разные версии ОО. Этого можно достичь, используя помеченную
упаковку или носители, или же метку, отображаемую ОО при функционировании. Это
обеспечивает потребителю возможность идентификации ОО (например, в месте
приобретения или использования).
ОО может предоставить способ, посредством которого он может быть легко
171

идентифицирован. Например, программный ОО может отображать свое название и номер
версии при запуске программы или в ответ на запрос через командную строку. Аппаратный
или программно-аппаратный ОО может быть идентифицирован путем физического
нанесения на нем соответствующего номера.
Оценщик должен проверить непротиворечивость используемой маркировки ОО.
ACM_CAP.4-3
Если ОО помечен несколько раз, то необходима согласованность меток. Например, следует
172

предусмотреть возможность связать любое помеченное руководство, поставляемое в
составе ОО, с оцененным функционирующим ОО. Этим обеспечивается уверенность
потребителя в том, что он приобрел оцененную версию ОО, установил эту же версию и
располагает надлежащей версией руководства, необходимой для функционирования
данного ОО в соответствии с его ЗБ. Оценщик может использовать список конфигурации,
который является частью представленной документации УК, чтобы верифицировать
согласованное использование идентификаторов.
Оценщик также верифицирует, что маркировка ОО согласуется с ЗБ.
173

Руководство по анализу непротиворечивости см. в подразделе 10.3.
174

ACM_CAP.4.3C
Оценщик должен проверить, что представленная документация УК включает
ACM_CAP.4-4
список конфигурации.
28
Список конфигурации идентифицирует элементы, находящиеся под управлением
175

конфигурацией.
Оценщик должен проверить, что представленная документация УК содержит
ACM_CAP.4-5
план УК.
Оценщик должен проверить, что представленная документация УК содержит
ACM_CAP.4-6
план приемки.
ACM_CAP.4.4C
Оценщик должен исследовать список конфигурации, чтобы сделать заключение,
ACM_CAP.4-7
что он идентифицирует элементы конфигурации, входящие в состав ОО.
Минимальный состав элементов конфигурации, которые необходимо включить в список
176

конфигурации, задается требованиями семейства ACM_SCP. Если компоненты из
ACM_SCP не используются, список конфигурации охватывает тот ОО, который
поставляется потребителю. В общем случае в него следует включить документацию
пользователя и администратора, а также аппаратные средства, программно-аппаратные
средства и программное обеспечение ОО. Аппаратные, программно-аппаратные и
программные элементы конфигурации ОО следует контролировать либо на уровне
представления реализации, либо на уровне собственно ОО, например, объектного кода или
аппаратных средств. Степень детализации элементов конфигурации оставлена на
усмотрение разработчика.
ACM_CAP.4.5C
Оценщик должен исследовать способ идентификации элементов конфигурации,
ACM_CAP.4-8
чтобы сделать заключение, что он описывает, каким образом элементы
конфигурации идентифицируются уникально.
ACM_CAP.4.6C
Оценщик должен проверить, что список конфигурации уникально
ACM_CAP.4-9

<< Пред. стр.

страница 4
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign