LINEBURG


<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

компонентов. Если в ЗБ нет требования представления проекта верхнего уровня
(ADV_HLD), этот раздел не применим.
2.5.5.2.3 Оценка
Оценщик должен привести в отчете сведения о методах оценки, технологии,
87

инструментальных средствах и применяемых стандартах.
Оценщик может сослаться на критерии оценки, методологию и интерпретации,
88

использованные при оценке ОО, или на устройства, применяемые при испытаниях.
Оценщик должен привести в отчете сведения о любых ограничениях, принятых при
89

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

организации работ, конфиденциальности и т.д.
2.5.5.2.4 Результаты оценки
Для каждого вида деятельности по оценке ОО оценщик должен привести в отчете:
91

- название рассматриваемого вида деятельности;
- вердикт, сопровождаемый обоснованием, для каждого компонента доверия,
определяющего этот вид деятельности, как результат выполнения соответствующего
действия ОМО и составляющих его шагов оценивания.
Обоснование представляет объяснение для вынесения вердикта, сделанного на основе ОК,
92

ОМО, любых их интерпретаций и изученных свидетельств оценки, и показывает, насколько
свидетельства оценки удовлетворяют или не удовлетворяют каждому аспекту критериев.
Оно содержит описание выполненной работы, используемых методов и процедур
получения результатов. Обоснование может обеспечивать детализацию до уровня шагов
оценивания ОМО.
Оценщик должен привести в отчете всю информацию, специально запрошенную на
93

шагах оценивания.
Для видов деятельности AVA и ATE указываются шаги оценивания, которые определяют
94

информацию, включаемую в ТОО.
2.5.5.2.5 Выводы и рекомендации
Оценщик должен привести в отчете выводы по результатам оценки об удовлетворении
95

ОО требованиям своего ЗБ, в частности, общий вердикт в соответствии с разделом 5 части
1 ОК и процедурой вынесения вердикта, описанной в п.2.2.5 "Вердикты оценщика".
Оценщик дает рекомендации, которые могут быть полезны для органа по сертификации.
96

Эти рекомендации могут указывать на недостатки продукта ИТ, обнаруженные во время
оценки, или упоминать о его свойствах, которые особенно полезны.

16
2.5.5.2.6 Перечень свидетельств оценки
Оценщик должен привести в отчете следующую информацию о каждом свидетельстве
97

оценки:
– составитель (например, разработчик, заявитель);
– название;
– уникальная ссылка (например, дата составления и номер версии).
2.5.5.2.7 Перечень сокращений/глоссарий терминов
Оценщик должен привести в отчете перечень всех сокращений, используемых в ТОО.
98

В ТОО нет необходимости повторять определения глоссария, уже приведенные в ОК или
99

ОМО.
2.5.5.2.8 Сообщения о проблемах
Оценщик должен привести в отчете полный перечень, уникально идентифицирующий
100

все СП, подготовленные во время оценки, а также их статус (состояние).
Для каждого СП в перечне следует привести идентификатор СП, а также название или
101

аннотацию.




17
3 Вид деятельности ACM
3.1 Введение
Этот вид деятельности предназначен для определения того, что в процессе уточнения и
102

модификации ОО и связанной с ним информации поддерживаются установленный порядок
и управление, и для обеспечения доверия к тому, что ОО и документация, используемые
при оценке, именно те, которые подготовлены к распространению.
Вид деятельности ACM включает: "Автоматизацию УК", "Возможности УК" и "Область
103

УК". Подвид деятельности, соответствующий компоненту ACM_AUT.1, состоит из
подразумеваемого действия оценщика, основанного на ACM_AUT.1.1D. Отметим, что
руководство для ACM_SCP.2 изменено по сравнению с ACM_SCP.1, хотя шаги оценивания
не изменились.

3.2 Цели
Целью этого вида деятельности является определение того, что в процессе уточнения и
104

модификации ОО и связанной с ним информации поддерживается установленный порядок
и управление конфигурацией.

3.3 Оценка автоматизации УК
3.3.1 Подвид деятельности ACM_AUT.1
3.3.1.1 Цели
Цель данного подвида деятельности – сделать заключение, контролируется ли при
105

поддержке автоматизированных инструментальных средств внесение изменений в
представление реализации в целях достижения меньшей восприимчивости системы УК к
человеческой ошибке или небрежности.
3.3.1.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является документация УК.
106

3.3.1.3 Действия оценщика
Этот подвид деятельности включает два элемента действий оценщика из части 3 ОК:
107

а) ACM_AUT.1.1E;
б) Подразумеваемое действие оценщика, основанное на ACM_AUT.1.1D.
3.3.1.3.1 Действие ACM_AUT.1.1E
ACM_AUT.1.1C
Оценщик должен проверить план УК в части описания автоматизированных
ACM_AUT.1-1
средств контроля доступа к представлению реализации ОО.
Оценщик должен исследовать автоматизированные средства контроля доступа,
ACM_AUT.1-2
чтобы сделать заключение об их эффективности для предотвращения
несанкционированной модификации представления реализации ОО.
Оценщик просматривает документацию УК, чтобы идентифицировать тех лиц или те роли,
108

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



18
Оценщику следует опробовать автоматизированные средства контроля доступа, чтобы
109

сделать заключение, может ли неуполномоченный пользователь или роль их обойти. Для
заключения потребуется несколько базовых тестов.
ACM_AUT.1.2C
Оценщик должен проверить документацию УК в части автоматизированных
ACM_AUT.1-3
средств поддержки генерации ОО из его представления реализации.
На этом шаге оценивания термин генерация применяется к процессам, принятым
110

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

генерации в документации УК.
Оценщик должен исследовать автоматизированные процедуры генерации,
ACM_AUT.1-4
чтобы сделать заключение, могут ли они использоваться для поддержки
генерации ОО.
Оценщик делает заключение, что при следовании процедурам генерации будет
112

сгенерирован ОО, отражающий его представление реализации. Потребитель тогда может
быть уверен, что версия ОО, поставленная для установки, реализует ПБО, как описано в ЗБ.
Например, в случае программного ОО это может включать проверку, что
автоматизированные процедуры генерации помогают обеспечить включение в
откомпилированный объектный код всех исходных файлов и связанных библиотек,
направленных на осуществление ПБО.
Следует отметить, что это требование является только требованием предоставления
113

поддержки. Например, подход, при котором make-файлы Unix помещены под управление
конфигурацией, следует считать достаточным для достижения данной цели, учитывая, что
такой подход к автоматизации существенно содействовал бы точной генерации ОО.
Автоматизированные процедуры могут способствовать определению надлежащих
элементов конфигурации, которые необходимо использовать при генерации ОО.
ACM_AUT.1.3C
Оценщик должен проверить, что план УК содержит информацию относительно
ACM_AUT.1-5
автоматизированных инструментальных средств, используемых в системе УК.
ACM_AUT.1.4C
Оценщик должен исследовать информацию, относящуюся к
ACM_AUT.1-6
автоматизированным инструментальным средствам, представленным в плане УК,
чтобы сделать заключение, что в нем описано, как они используются.
Информация, представленная в плане УК, обеспечивает необходимую детализацию для
114

пользователя системы УК, чтобы дать возможность правильно использовать
автоматизированные инструментальные средства для сохранения целостности ОО.
Например, представленная информация может содержать описание:
а) функциональности, обеспечиваемой инструментальными средствами;
б) того, как эта функциональность используется разработчиком для управления
изменениями в представлении реализации;
в) того, как эта функциональность используется разработчиком для поддержки генерации
ОО.


19
3.3.1.3.2 Подразумеваемое действие оценщика
ACM_AUT.1.1D
Оценщик должен исследовать систему УК, чтобы сделать заключение, что
ACM_AUT.1-7
используются те автоматизированные инструментальные средства и процедуры,
которые описаны в плане УК.
Этот шаг оценивания может рассматриваться как процесс, дополнительный по отношению
115

к параллельно выполняемому оценщиком исследованию применения системы УК,
требуемому ACM_CAP. Оценщик старается получить свидетельство применения
инструментальных средств и процедур. Для этого рекомендуется посетить объект
разработки, чтобы лично убедиться в функционировании инструментальных средств и
процедур, а также провести исследование свидетельств, получаемых при их применении.
Руководство по посещению объектов см. в подразделе 10.5.
116


3.4 Оценка возможностей УК
3.4.1 Подвид деятельности ACM_CAP.1
3.4.1.1 Цели
Цель данного подвида деятельности – сделать заключение, четко ли разработчик
117

идентифицировал ОО.
3.4.1.2 Исходные данные
Свидетельства оценки для этого подвида деятельности:
118

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

а) ACM_CAP.1.1E.
3.4.1.3.1 Действие ACM_CAP.1.1E
ACM_CAP.1.1C
Оценщик должен проверить, что версия ОО, представленная для оценки,
ACM_CAP.1-1
уникально обозначается.
В этом компоненте доверия отсутствуют какие-либо другие требования к разработчику по
120

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




20
Оценщику следует стремиться исследовать несколько версий ОО (например, полученных в
121

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

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

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

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

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

3.4.2 Подвид деятельности ACM_CAP.2
3.4.2.1 Цели
Цель данного подвида деятельности – сделать заключение, четко ли разработчик
127

идентифицировал ОО и связанные с ним элементы конфигурации.
3.4.2.2 Замечания по применению
В этом компоненте вынесение заключения об использовании системы УК ограничено
128

проверкой идентификации ОО и исследованием списка конфигурации. В ACM_CAP.3
требования расширены сверх этих двух вопросов, и требуется более подробное
свидетельство использования системы УК.
3.4.2.3 Исходные данные
Свидетельства оценки для этого подвида деятельности:
129

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

а) ACM_CAP.2.1E.


21
3.4.2.4.1 Действие ACM_CAP.2.1E
ACM_CAP.2.1C
Оценщик должен проверить, что версия ОО, представленная для оценки,
ACM_CAP.2-1
уникально маркируется.
Оценщику следует использовать систему УК, применяемую разработчиком, для
131

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

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

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

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

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

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

ACM_CAP.2.3C
Оценщик должен проверить, что представленная документация УК включает
ACM_CAP.2-4

<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign