Нормативная документация
ГОСТ Р ИСО/МЭК 18045-2008 Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий

Содержание

Предисловие

Введение

1 Область применения

2 Нормативные ссылки

3 Термины и определения


4 Обозначения и сокращения

5 Краткий обзор


6 Принятые соглашения

7 Общие задачи оценки

7.1 Введение


7.2 Задача получения исходных данных для оценки

7.3 Задача оформления результатов оценки

8 Оценка профиля защиты

8.1 Введение


8.2 Организация оценки ПЗ

8.3 Вид деятельности «Оценка профиля защиты»

9 Оценка задания по безопасности

9.1 Введение


9.2 Организация оценки ЗБ

9.3 Вид деятельности «Оценка задания по безопасности»

10 Оценка по ОУД1

10.1 Введение


10.2 Цели

10.3 Организация оценки по ОУД1

10.4 Вид деятельности «Управление конфигурацией»

10.5 Вид деятельности «Поставка и эксплуатация»

10.6 Вид деятельности «Разработка»

10.7 Вид деятельности «Руководства»

10.8 Вид деятельности «Тестирование»

11 Оценка по ОУД2

11.1 Введение


11.2 Цели

11.3 Организация оценки по ОУД2

11.4 Вид деятельности «Управление конфигурацией»

11.5 Вид деятельности «Поставка и эксплуатация»

11.6 Вид деятельности «Разработка»

11.7 Вид деятельности «Руководства»

11.8 Вид деятельности «Тестирование»

11.9 Вид деятельности «Оценка уязвимостей»

12 Оценка по ОУД3

12.1 Введение


12.2 Цели

12.3 Организация оценки по ОУД3

12.4 Вид деятельности «Управление конфигурацией»

12.5 Вид деятельности «Поставка и эксплуатация»

12.6 Вид деятельности «Разработка»

12.7 Вид деятельности «Руководства»

12.8 Вид деятельности «Поддержка жизненного цикла»

12.9 Вид деятельности «Тестирование»

12.10 Вид деятельности «Оценка уязвимостей»

13 Оценка по ОУД4

13.1 Введение


13.2 Цели

13.3 Организация оценки по ОУД4

13.4 Вид деятельности «Управление конфигурацией»

13.5 Вид деятельности «Поставка и эксплуатация»

13.6 Вид деятельности «Разработка»

13.7 Вид деятельности «Руководства»

13.8 Вид деятельности «Поддержка жизненного цикла»

13.9 Вид деятельности «Тестирование»

13.10 Вид деятельности «Оценка уязвимостей»

14 Подвид деятельности «Устранение недостатков»

14.1 Оценка устранений недостатков (ALC_FLR.1)


14.2 Оценка устранений недостатков (ALC_FLR.2)

14.3 Оценка устранений недостатков (ALC_FLR.3)

Приложение А (обязательное) Общие указания по оценке

А.1 Цели


А.2 Выборка

А.3 Анализ непротиворечивости

А.4 Зависимости

А.5 Посещение объектов

А.6 Границы объекта оценки

А.7 Угрозы и требования класса FPT

А.8 Стойкость функций безопасности и анализ уязвимостей

А.9 Сфера ответственности системы оценки

Приложение В (справочное) Сведения о соответствии национальных стандартов Российской Федерации ссылочным международным стандартам













13.4 Вид деятельности «Управление конфигурацией»

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

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 «Посещение объектов» (приложение А).

13.4.2 Оценка возможностей УК (ACM_CAP.4)

13.4.2.1 Цели

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

13.4.2.2 Исходные данные

Свидетельства оценки для этого подвида деятельности:

a) ЗБ;

b) ОО, пригодный для тестирования;

c) документация управления конфигурацией.

13.4.2.3 Действие ACM_CAP.4.1E

13.4.2.3.1 Шаг оценивания 4:ACM_CAP.4-1

ИСО/МЭК 15408-3 ACM_CAP.4.1C: Маркировка ОО должна быть уникальна для каждой версии ОО.

Оценщик должен проверить, что версия ОО, представленная для оценки, уникально маркирована.

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

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

13.4.2.3.2 Шаг оценивания 4:ACM_CAP.4-2

ИСО/МЭК 15408-3 ACM_CAP.4.2C: ОО должен быть помечен маркировкой.

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

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

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

13.4.2.3.3 Шаг оценивания 4:ACM_CAP.4-3

Оценщик должен проверить непротиворечивость используемой маркировки ОО.

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

Оценщик также верифицирует, что маркировка ОО согласована с ЗБ.

Руководство по анализу непротиворечивости см. в A.3 «Анализ непротиворечивости» (приложение А).

13.4.2.3.4 Шаг оценивания 4:ACM_CAP.4-4

ИСО/МЭК 15408-3 ACM_CAP.4.3C: Документация УК должна включать в себя список конфигурации, план УК и план приемки под УК.

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

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

13.4.2.3.5 Шаг оценивания 4:ACM_CAP.4-5

Оценщик должен проверить, что представленная документация УК содержит план УК.

13.4.2.3.6 Шаг оценивания 4:ACM_CAP.4-6

Оценщик должен проверить, что представленная документация УК содержит план приемки.

13.4.2.3.7 Шаг оценивания 4:ACM_CAP.4-7

ИСО/МЭК 15408-3 ACM_CAP.4.4C: Список конфигурации должен уникально идентифицировать все элементы конфигурации, входящие в ОО.

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

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

13.4.2.3.8 Шаг оценивания 4:ACM_CAP.4-8

ИСО/МЭК 15408-3 ACM_CAP.4.5C: Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО.

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

Минимальный состав элементов конфигурации, которые необходимо включить в список конфигурации, задается требованиями семейства ACM_SCP «Область УК».

13.4.2.3.9 Шаг оценивания 4:ACM_CAP.4-9

ИСО/МЭК 15408-3 ACM_CAP.4.6C: Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации, входящих в ОО.

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

13.4.2.3.10 Шаг оценивания 4:ACM_CAP.4-10

ИСО/МЭК 15408-3 ACM_CAP.4.7C: Система УК должна уникально идентифицировать все элементы конфигурации, входящие в ОО.

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

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

13.4.2.3.11 Шаг оценивания 4:ACM_CAP.4-11

ИСО/МЭК 15408-3 ACM_CAP.4.8C: План УК должен содержать описание, как используется система УК.

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

Описания, содержащиеся в плане УК, могут включать в себя:

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

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

c) процедуры, используемые для обеспечения того, чтобы только уполномоченные лица могли изменять элементы конфигурации;

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

e) свидетельство, генерируемое в результате применения процедур. Например, при изменении элемента конфигурации система УК могла бы зафиксировать описание изменения, ответственность за изменение, идентификацию всех затронутых элементов конфигурации, статус изменения (например, «не завершено» или «завершено»), а также дату и время внесения изменения. Эта информация могла бы быть внесена в журнал аудита проведенных изменений или в протокол контроля изменений;

f) подход к контролю версий и уникальной маркировке версий ОО (охватывающий, например, выпуск исправлений («патчей») для операционных систем и последующее обнаружение их применения).

13.4.2.3.12 Шаг оценивания 4:ACM_CAP.4-12

ИСО/МЭК 15408-3 ACM_CAP.4.9C: Свидетельство должно демонстрировать, что система УК действует в соответствии с планом УК.

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

Выходные материалы системы УК должны обеспечивать свидетельство, позволяющее оценщику быть уверенным, что план УК применяется, а все элементы конфигурации поддерживаются системой УК, как это требуется в АСМ_САР.4.10С. Пример выходных материалов мог бы включать в себя формы контроля изменений или формы разрешения доступа к элементам конфигурации.

13.4.2.3.13 Шаг оценивания 4:ACM_CAP.З-13

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

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

Руководство по выборке см. в А.2 «Выборка» (приложение А).

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

Предполагается, что для поддержки этих действий оценщик посетит объект разработки.

Руководство по посещению объектов см. в А.5 «Посещение объектов» (приложение А).

13.4.2.3.14 Шаг оценивания 4:ACM_CAP.З-14

ИСО/МЭК 15408-3 ACM_CAP.4.10C: Документация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации.

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

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

Руководства по выборке см. в А.2 «Выборка» (приложение А).

13.4.2.3.15 Шаг оценивания 4:ACM_CAP.4-15

ИСО/МЭК 15408-3 ACM_CAP.4.11C: Система УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения.

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

Оценщик может использовать несколько методов для заключения об эффективности мер контроля доступа в УК. Например, оценщик может опробовать меры контроля доступа, чтобы удостовериться, что процедуры нельзя обойти. Оценщик может использовать выходные материалы, сгенерированные процедурами системы УК и уже подвергнутые исследованию на шаге оценивания АСМ_САР.4-13. Оценщику может быть также продемонстрирована система УК, чтобы он убедился, что используемые меры контроля доступа выполняются эффективно.

Разработчик должен предусмотреть автоматизированные меры управления доступом как часть системы УК, а их пригодность может быть подтверждена в соответствии с компонентом 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) документацию, используемую для фиксации подробностей сообщенных недостатков безопасности, связанных с реализацией (например, сообщения о состоянии проблем, полученные из ведущейся разработчиком базы данных сообщений о проблемах).




Далее >>>



|   Главная   |   Законы   |   ГОСТ   |   РД   |   Требования   |   Пособия   |   Рекомендации   |   Перечни   |


books on zlibrary