Данное требование пятого класса включает в себя аналогичное требование шестого класса, а именно:

Дискреционный принцип контроля доступа КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.).

Требования управления доступом

FDP_ACC.1.1 - ФБ должна предписать политику дискреционного контроля доступа для:

а) пользователей;

б) субъектов, действующих от имени пользователей;

в) других именованных субъектов;

г) именованных объектов, содержащих данные пользователя;

д) [назначение: операции между субъектами и объектами, охваченными управлением доступа].

FDP_ACF.1.1 - ФБ должна предписать политику дискреционного контроля доступа к объектам, основанную на следующих признаках субъекта:

a) идентичность пользователя: идентичность пользователя по признакам пользователя;

б) список группы: нуль или большее количество тождеств из группы признаков пользователя;

в) [назначение: тип субъекта: характер(природа) субъекта].

a) список контроля доступа: список групп и пользователей со списком (для каждой группы или пользователя) специфических операций, разрешенных на объекте каждой группе или пользователю;

б) [назначение: тип объекта: характер управляемого объекта].

Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).

a) если идентичность субъекта пользователя или любой элемент списка группы субъектов упомянуты в списке контроля доступа к объекту, то субъекту будут предоставлены разрешения доступа, упомянутые в списке контроля доступа;

б) если ни идентичность субъекта пользователя, ни любой элемент списка группы субъектов не упомянуты в списке контроля доступа к объекту, то доступ будет предоставляться применением [назначение: правила доступа по умолчанию].

в) если ознакомление со списком контроля доступа дает неоднозначный результат, то эта неоднозначность должна быть разрешена применением [назначение: правила для консультации по списку контроля доступа].

Если различные правила относятся к различным субъектам и объектам, то должны быть представлены все эти правила.

FDP_ACI.1.1 - ФБ должна предписать политику стандартных (заданных по умолчанию) признаков, чтобы обеспечить разрешающие или стандартные значения для признаков безопасности объекта, которые используются, чтобы предписать ПФБ.

FDP_ACI.1.2 - ФБ должна предоставить возможность спецификации альтернативных начальных значений для отмены стандартных значений после создания объекта.

Права изменять ПРД должны предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).

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

a) Разрешение доступа к объекту пользователям, не обладающим таким разрешением, может быть назначено только уполномоченными пользователями.

б) [Назначение: дополнительные правила для изменения признаков объекта].

При первоначальном назначении или при перераспределении

внешней памяти КСЗ должен предотвращать доступ субъекту к остаточной информации.

Данное требование полностью совпадает с требованием для шестого класса, а именно:

КСЗ должен требовать от пользователей идентифицировать себя при запросах на доступ.

КСЗ должен подвергать проверке подлинность идентификации осуществлять аутентификацию.

КСЗ должен располагать необходимыми данными для идентификации и аутентификации.

КСЗ должен препятствовать доступу к защищаемым ресурсам неидентифицированных пользователей и пользователей, подлинность идентификации которых при аутентификации не подтвердилась.

FIA_UID.1.1 - ФБ должна идентифицировать каждого пользователя перед выполнением любых действий, требуемых пользователем.

FIA_UAU.1.1 - ФБ должна подтвердить подлинность требуемой идентичности любого пользователя до выполнения любых функций для пользователя.

FIA_ATD.1.1 - ФБ должна обеспечить для каждого пользователя набор признаков безопасности, необходимый, чтобы предписать ПФБ.

FIA_ATA.1.1 - ФБ должна обеспечить способность инициализации признаков пользователя с обеспеченными стандартными значениями.

FIA_ADP.2.1 - ФБ должна защитить от несанкционированного наблюдения, модификации и разрушения необработанную форму опознавательных данных всегда во время их хранения в ОО.

КСЗ должен быть в состоянии осуществлять регистрацию следующих событий:

использование идентификационного и аутентификационного механизма;

запрос на доступ к защищаемому ресурсу (открытие файла, запуск программы и т.д.);

создание и уничтожение объекта; действия по изменению ПРД.

FAU_GEN.1.1 - ФБ должна быть способна произвести запись

аудита следующих контролируемых событий:

a) Запуск и завершение контролируемых процессов;

б) Все контролируемые события для базового уровня аудита, определенные во всех функциональных компонентах, включенных в ПЗ-5, а именно:

[FIA_UID] - Все попытки использовать механизм идентификации пользователя, в том числе, при условии идентичности пользователя. Начало запроса должно быть включено в контрольную запись.

[FIA_UAU] - Любое использование опознавательного механизма. Начало запроса должно быть включено в контрольную запись.

[FIA_ATA] - Все запросы на использование функции администрирования признака пользователя, включая идентификацию признаков пользователя, которые были изменены.

[FIA_ADP] - Все запросы к данным аутентификации пользователя.

[FAU_PRO] - Любая попытка читать, модифицировать или уничтожить трассу контроля.

[FAU_MGT] - Любая попытка выполнять операции с трассой контроля.

[FAU_SEL] - Все модификации конфигурации аудита, которые происходят во время работы набора контрольных функций.

[FDP_ACF] - Все запросы для выполнения операции на объекте, охваченном ПФБ, включая введение объектов в адресное пространство пользователя и стирание объектов.

[FDP_ACI] - Любые изменения или отмена стандартных признаков объекта, включая идентификацию стандартных признаков объекта, которые были изменены или отменены.

[FDP_SAM] - Все попытки модифицировать признаки безопасности, включая идентификацию объекта попытки изменения и новые значения модифицированных признаков безопасности.

[FPT_AMT] - Выполнение тестирования основной машины и результаты проверок.

[FPT_TSA] - Использование относящейся к безопасности административной функции.

в) [назначение: другие контролируемые события]

дата и время; субъект, осуществляющий регистрируемое действие; тип события (если регистрируется запрос на доступ, то

следует отмечать объект и тип доступа);

успешно ли осуществилось событие (обслужен запрос на доступ или нет).

a) Дата и время события, тип события, идентичность субъекта и результат (успех, неудача) события.

б) Для каждого типа контролируемых событий [назначение: другая, относящаяся к аудиту, информация].

FAU_GEN.2.1 - ФБ должна быть способна связать любое контролируемое событие с идентичностью пользователя, который явился причиной события.

FAU_STG.1.1 - ФБ должна обеспечить хранение полученных записей аудита в постоянной трассе контроля.

FAU_PRO.1.1 - ФБ должна разрешать доступ к трассе контроля только уполномоченному администратору.

FAU_MGT.1.1 - ФБ должна обеспечивать уполномоченному администратору возможность создавать, удалять и освобождать трассу контроля.

FAU_SEL.1.1 - ФБ должна быть способна включать или исключать контролируемые события из набора ревизуемых событий на основе следующих признаков:

a) идентичность пользователя;

б) признаки объекта.

Требования администрирования

FPT_TSA.1.1 - ФБ должна отличать относящиеся к безопасности административные функции от других функций.

FPT_TSA.1.2 - Набор относящихся к безопасности административных функций ФБ должен включать все функции, необходимые чтобы инсталлировать, конфигурировать и управлять ФБ; как минимум, этот набор должен включать [назначение: список административных услуг, которые должны быть минимально обеспечены].

FPT_TSA.1.3 - ФБ должна ограничить возможность выполнять относящиеся к безопасности административные функции специально уполномоченными пользователями.

FPT_TSA.1.4 - ФБ должна быть способна выделить пользователей, уполномоченных для административных функций, из всех пользователей ОО.

FPT_TSU.1.1 - ФБ должна предписать проверки правильности входных значений относящихся к безопасности административных функций как описано в Руководстве администратора.

В СВТ данного класса защищенности должны быть предусмотрены средства периодического контроля за целостностью программной и информационной части КСЗ.

FPT_SEP.1.1 - ФБ должна для собственного выполнения поддерживать область безопасности , которая защищает ее от вмешательства и подделки недоверенными субъектами:

a) Передачи между областями ФБ и не-ФБ должны управляться так, чтобы произвольный вход в область ФБ или выход из области ФБ были невозможны.

б) Значения ссылок пользовательских или прикладных параметров, относящихся ФБ, должны быть согласованы с адресным пространством и значениями, ожидаемыми ФБ.

в) Разрешения ссылок к объектам (и/или к данным не-ФБ) в качестве параметров ФБ должны быть согласованы с разрешениями, требуемыми ФБ.

г) Ссылки на объекты ФБ, используемые функциями изоляции ФБ, должны быть установлены ФБ.

д) Область ФБ должна иметь все признаки пользователя и объекта.

FPT_SEP.1.2 - ФБ должна предписать разделение между областями безопасности субъектов в ОКФБ.

FPT_RVM.1.1 - ФБ должна гарантировать, что функции осуществления ПФБ вызываются и действуют прежде, чем произойдет любое, связанное с безопасностью, действие:

a) ФБ должна обеспечить все ссылки на субъекты, объекты, ресурсы и функции ФБ.

б) Посредничество должно гарантировать, что все подчиненные ссылки объекта направлены функциям политики дискреционного контроля доступа.

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

г) Ссылки, исходящие от привилегированных субъектов, должны быть установлены в соответствии с атрибутами, определенными для этих субъектов.

FPT.AMT.1.1 - ФБ должна обеспечить уполномоченному администратору возможность проверить правильность действия относящихся к безопасности функций, поддержанных аппаратными средствами и программируемым оборудованием, на котором функционирует ОО.

На начальном этапе проектирования СВТ должна быть построена модель защиты. Модель должна включать в себя ПРД к объектам и непротиворечивые правила изменения ПРД.

ОО должен выполнить требования уровня гарантии оценки УГО3, а именно:

ADV_FSP.1 (Объект оценки и политика безопасности)

ADV_FSP.1.1D - Разработчик должен обеспечить функциональную спецификацию.

ADV_FSP.1.2D - Разработчик должен обеспечить ПФБ.

ADV_FSP.1.1C - Функциональная спецификация должна описать ФБ с использованием неформального стиля.

ADV_FSP.1.2C - Функциональная спецификация должна включать неформальное представление синтаксиса и семантики всех внешних интерфейсов ФБ.

ADV_FSP.1.3C - Функциональная спецификация должна включать свидетельство, которое демонстрирует, что ФБ полностью представлена.

ADV_FSP.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельства.

ADV_FSP.1.2E - Оценщик должен решить, что функциональная спецификация согласуется с ПФБ.

ADV_FSP.1.3E - Оценщик должен определить, адресованы ли функциональные требования ЗБ представлениям ФБ.

Должна содержать описание принципов работы СВТ, общую схему КСЗ, описание интерфейсов КСЗ с пользователем и интерфейсов модулей КСЗ, модель защиты, описание механизмов контроля целостности КСЗ, очистки памяти, идентификации и аутентификации.

ADV_HLD.2.1D - Разработчик должен обеспечить проект высокого уровня ФБ.

ADV_HLD.2.1C - Представление проекта высокого уровня должно быть неформальным.

ADV_HLD.2.2C - Проект высокого уровня должен описать структуру ФБ в терминах подсистем.

ADV_HLD.2.3C - Проект высокого уровня должен описать функциональные возможности безопасности, обеспеченные каждой подсистемой ФБ.

ADV_HLD.2.4C - Проект высокого уровня должен идентифицировать интерфейсы подсистем ФБ.

ADV_HLD.2.5C - Проект высокого уровня должен идентифицировать любые основные аппаратные средства ЭВМ, программируемое оборудование и/или программное обеспечение, требуемое ФБ, с представлением функций, обеспеченных поддерживающими механизмами защиты, осуществленными в этих аппаратных средствах ЭВМ, программируемом оборудовании или программном обеспечении.

ADV_HLD.2.6C - Проект высокого уровня должен описать разделение ФБ на подсистемы, осуществляющие ПФБ, и другие подсистемы.

ADV_HLD.2.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ADV_HLD.2.2E - Оценщик должен определить, адресованы ли функциональные требования ЗБ представлениям ФБ.

ADV_RCR. 1 (Неформальная демонстрация соответствия)

ADV_RCR.1.1D - Разработчик должен обеспечить свидетельство, что наименее абстрактное представление ФБ есть точное, последовательное и полное преобразование функциональных требований, выраженных в ЦБ.

ADV_RCR.1.1C - Для каждой смежной пары представлений ФБ свидетельство должно демонстрировать, что все части более абстрактного представления преобразованы в менее абстрактные представления.

ADV_RCR.1.2C - Для каждой смежной пары представлений ФБ демонстрация соответствия между представлениями может быть неформальная.

ADV_RCR.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ADV_RCR.1.2E - Оценщик должен проанализировать соответствие между функциональными требованиями, выраженными в ЗБ, и наименее абстрактным представлением, чтобы гарантировать точность, последовательность и законченность.

ALC_DVS.1 (Идентификация мер безопасности)

ALC_DVS.1.1D - Разработчик должен предъявить документацию

безопасности разработки.

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

ALC_DVS.1.2C - Документация безопасности разработки должна обеспечить свидетельство того, что эти меры безопасности применяются в течение разработки и обслуживания ОО.

ALC_DVS.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ALC_DVS.1.2E - Оценщик должен проверить, применяются ли меры безопасности.

В данном классе защищенности должны тестироваться: реализация ПРД (перехват явных и скрытых запросов на доступ, правильное распознавание санкционированных и несанкционированных запросов, средства защиты механизма разграничения доступа, санкционированные изменения ПРД);

успешное осуществление идентификации и аутентификации, а также их средства защиты;

очистка памяти в соответствии с п. 2.3.2; регистрация событий в соответствии с п. 2.3.5, средства защиты регистрационной информации и возможность санкционированного ознакомления с ней;

работа механизма, осуществляющего контроль за целостностью КСЗ.

ATE_FUN.1.1D - Разработчик должен проверить ФБ и задокументировать результаты.

ATE_FUN.1.2D - Разработчик должен обеспечить тестовую документацию.

ATE_FUN.1.1C - Тестовая документация должна состоять из планов тестирования, описаний процедуры тестирования и проверки результатов.

ATE_FUN.1.2C - Планы тестирования должны идентифицировать функции безопасности, которые будут проверены, и описать цели тестирования, которые будут выполнены.

ATE_FUN.1.3C - Описания процедур тестирования должны идентифицировать испытания, которые будут выполнены, и описать сценарии для тестирования каждой функции безопасности.

Должно быть предоставлено описание тестов и испытаний, которым подвергалось СВТ в соответствии с требованиями п. 2.3.7, и результатов тестирования.

ATE_FUN.1.5C - Результаты тестирования, выполненного разработчиком, должны демонстрировать, что каждая функция безопасности работает как определено.

ATE_FUN.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ATE_IND.2 (Независимое тестирование по образцу)

ATE_IND.2.1D - Разработчик должен обеспечить ОО для испытания.

ATE_IND.2.1C - ОО должен быть подходящим для тестирования. ATE_IND.2.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ATE_IND.2.2E - Оценщик должен проверить ФБ, чтобы подтвердить, что ФБ работает как определено.

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

ATE_COV.2 (Полный охват - строгий)

ATE_COV.2.1D - Разработчик должен обеспечить анализ достаточности тестов.

ATE_COV.2.1C - Анализ достаточности тестов должен демонстрировать, что тестирования, идентифицированные в тестовой документации, охватывают ФБ.

ATE_COV.2.2C - Анализ достаточности тестов должен демонстрировать соответствие между функциями безопасности и результатами тестов, идентифицированными в тестовой документации.

ALC_COV.2.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ATE_DPT.2 (Тестирование на уровне проекта высокого уровня) ATE_DPT.2.1D - Разработчик должен обеспечить анализ глубины тестирования.

ATE_DPT.2.1C - Анализ глубины должен демонстрировать, что тестирование, идентифицированное в тестовой документации, достаточны, чтобы демонстрировать, что ОО работает в соответствии с функциональной спецификацией и проектом высокого уровня ФБ.

ATE_DPT.2.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

AVA_VLA.1 (Анализ уязвимости разработчиком)

AVA_VLA.1.1D - Разработчик должен тщательно выполнить и задокументировать анализ представляемого ОО по поиску очевидных путей, которыми пользователь может нарушить ПФБ.

AVA_VLA.1.2D - Разработчик должен задокументировать расположение идентифицированных уязвимостей.

AVA_VLA.1.1C - Свидетельство должно показать для каждой уязвимости, что уязвимость не может эксплуатироваться в предназначенной для ОО окружающей среде.

AVA_VLA.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования для содержания и представления свидетельств.

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

AVA_MSU.1 (Анализ неправильного применения - очевидные недостатки)

AVA_MSU.1.1D - Разработчик должен задокументировать результаты анализа документации руководств в части противоречивости и полноты.

AVA_MSU.1.2D - Разработчик должен гарантировать, что документация руководств не содержит никаких вводящих в заблуждение инструкций.

AVA_MSU.1.1C - Документация результатов анализа должна демонстрировать, что руководства не имеют противоречий и достаточно полны.

AVA_MSU.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

AVA_MSU.1.2E - Оценщик должен установить, что не имеется никаких вводящих в заблуждение указаний в руководящей документации.

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

AVA_SOF.1 (Оценка силы функции безопасности ОО)

AVA_SOF.1.1D - Разработчик должен идентифицировать все механизмы безопасности ОО, для которых анализ силы функции безопасности ОО является свойственным.

AVA_SOF.1.2D - Разработчик должен провести анализ силы функции безопасности для каждого идентифицированного механизма.

AVA_SOF.1.1C - Анализ силы функции безопасности ОО должен определить воздействие идентифицированных механизмов безопасности ОО на способности функций безопасности ОО противостоять угрозам.

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

AVA_SOF.1.3C - Каждое требование силы должно быть или базовое, или среднее, или высокое.

AVA_SOF.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

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

AVA_SOF.1.3E - Оценщик должен подтвердить, что требования силы правильны.

ADO_IGS.1 (Процедуры инсталляции, генерации и запуска)

ADO_IGS.1.1D - Разработчик должен задокументировать процедуры, которые нужно использовать для безопасной установки, генерации и запуска ОО.

ADO_IGS.1.1C - Документация должна описать шаги, необходимые для безопасной установки, генерации и запуска ОО.

ADO_IGS.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ACM_CAP.2 (Контроль полномочий)

ACM_CAP.2.1D - Разработчик должен использовать систему УК. ACM_CAP.2.2D - Разработчик должен обеспечить документацию УК.

ACM_CAP.2.1C - Документация УК должна включать список конфигурации и план УК.

ACM_CAP.2.2C - Список конфигурации должен описать изделия конфигурации, которые включает ОО.

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

ACM_CAP.2.4C - План УК должен описать, как используется система УК.

ACM_CAP.2.5C - Документация УК должна обеспечить свидетельство того, что система УК работает должным образом.

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

ACM_CAP.2.7C - Система УК должна гарантировать, что только санкционированные изменения сделаны в изделиях конфигурации ОО.

ACM_CAP.2.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ACM_SCP.1 (Минимальный охват УК)

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

ACM_SCP.1.2C - Документация УК должна описать, как изделия конфигурации прослеживаются системой УК.

ACM_SCP.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

Требование совпадает с аналогичным требованием шестого класса, а именно:

Документация на СВТ должна включать в себя краткое руководство для пользователя с описанием способов использования КСЗ и его интерфейса с пользователем.

AGD_USR.1.1D - Разработчик должен обеспечить руководство пользователя.

AGD_USR.1.1C - Руководство пользователя должно описать ФБ и интерфейсы, доступные пользователю.

AGD_USR.1.2C - Руководство пользователя должно содержать руководящие принципы использования функций безопасности, обеспеченных ОО.

AGD_USR.1.3C - Руководство пользователя должно содержать предупреждения относительно функций и привилегий, которые должны управляться в безопасной окружающей среде обработки.

AGD_USR.1.4C - Руководство пользователя должно описать взаимодействие между видимыми пользователем функциями безопасности.

AGD_USR.1.5C - Руководство пользователя должно быть согласовано со всей другой документацией, имеющейся для оценки.

AGD_USR.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

Данный документ адресован администратору защиты. Должен содержать описание контролируемых функций, руководство по генерации КСЗ, описания старта СВТ, процедур проверки правильности старта, процедур работы со средствами регистрации.

AGD_ADM.1.1D - Разработчик должен обеспечить руководство

администратора, адресованное административному персоналу системы.

AGD_ADM.1.1C - Руководство администратора должно описать, как управлять объектом оценки безопасным способом.

AGD_ADM.1.2C - Руководство администратора должно содержать предупреждения относительно функций и привилегий, которыми необходимо управлять для обеспечения безопасности окружающей среды обработки.

AGD_ADM.1.3C - Руководство администратора должно содержать руководящие принципы последовательного и эффективного использования функций безопасности в пределах ОКФБ.

AGD_ADM.1.4C - Руководство администратора должно описать различие между двумя типами функций: теми, которые позволяют администратору управлять параметрами безопасности, и теми, которые позволяют администратору только получать информацию.

AGD_ADM.1.5C - Руководство администратора должно описать все параметры безопасности, находящиеся под контролем администратора.

AGD_ADM.1. 6C - Руководство администратора должно описать каждый тип относящегося к безопасности события относительно административных функций, которые должны быть выполнены, включая изменение(замену) характеристик безопасности объектов, находящихся под контролем(управлением) ФБ.

AGD_ADM.1.7C - Руководство администратора должно содержать руководящие принципы относительно того, как функции безопасности взаимодействуют.

AGD_ADM.1.8C - Руководство администратора должно содержать инструкции относительно конфигурирования ОО.

AGD_ADM.1.9C - Руководство администратора должно описать все наборы конфигурации, которые могут использоваться в течение безопасной установки ОО.

AGD_ADM.1.10C - Руководство администратора должно описать детали, достаточные для использования процедур, относящихся к администрированию безопасности.

AGD_ADM.1.11C - Руководство администратора должно быть согласовано со всеми другими документами, имеющимися для оценки.

AGD_ADM.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

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