2.6.4Класс AGD. Руководства
Класс доверия AGD определяет требования, направленные на обеспечение понятности, достаточности и законченности эксплуатационной документации, представляемой разработчиком. Эта документация, которая содержит две категории информации (для пользователей и администраторов), является важным фактором безопасной эксплуатации ОО.
2.6.4.1Руководство администратора (AGD_ADM)
Требования к руководству администратора способствуют обеспечению, что ограничения среды будут поняты администраторами и операторами ОО. Руководство администратора – основное средство, имеющееся в распоряжении разработчика, для предоставления администраторам ОО детальной и точной информации о том, как осуществлять администрирование ОО безопасным способом и эффективно использовать привилегии ФБО и функции защиты.
2.6.4.2Руководство пользователя (AGD_USR)
Требования к руководству пользователя способствуют обеспечению, что пользователи могут эксплуатировать ОО безопасным способом (например, ограничения использования, предусмотренные ПЗ или ЗБ, необходимо четко объяснить и проиллюстрировать). Руководство – основное средство, имеющееся в распоряжении разработчика, для предоставления пользователям ОО необходимой общей и специфической информации о том, как правильно использовать функции защиты ОО. В руководстве необходимо осветить два аспекта. Во-первых, требуется объяснить, что делают доступные пользователю функции безопасности, и как они будут использоваться, чтобы пользователи имели возможность последовательно и действенно защищать свою информацию. Во-вторых, требуется разъяснить роль пользователя в поддержании безопасности ОО.
2.6.5Класс ALC. Поддержка жизненного цикла
Класс доверия ALC определяет требования доверия посредством принятия для всех этапов разработки ОО четко определенной модели жизненного цикла, включая политики и процедуры устранения недостатков, правильное использование инструментальных средств и методов, а также меры безопасности для защиты среды разработки.
2.6.5.1Безопасность разработки (ALC_DVS)
Семейство "Безопасность разработки" охватывает физические, процедурные, относящиеся к персоналу и другие меры безопасности, используемые применительно к среде разработки. Оно также содержит требования к физической безопасности местоположения разработки и к контролю за отбором и наймом персонала разработчиков.
2.6.5.2Устранение недостатков (ALC_FLR)
Семейство "Устранение недостатков" обеспечивает, чтобы недостатки, обнаруженные потребителями ОО, отслеживались и исправлялись, пока ОО сопровождается разработчиком. Несмотря на то, что при оценке ОО не может быть принято решение о потенциальном соответствии требованиям устранения недостатков, можно оценить политики и процедуры, которые разработчик предусмотрел для выявления и устранения недостатков и распространения исправлений потребителям.
2.6.5.3Определение жизненного цикла (ALC_LCD)
Семейство "Определение жизненного цикла" устанавливает, что технология разработки, используемая разработчиком для создания ОО, включает в себя положения и действия, указанные в требованиях к процессу разработки и поддержке эксплуатации. Уверенность в соответствии ОО требованиям больше, когда анализ безопасности и подготовка свидетельств осуществляются на регулярной основе как неотъемлемая часть процесса разработки и поддержки эксплуатации. В задачи этого семейства не входит предопределение какого-либо конкретного процесса разработки.
2.6.5.4Инструментальные средства и методы (ALC_TAT)
Семейство "Инструментальные средства и методы" связано с необходимостью определения инструментальных средств разработки, используемых для анализа и создания ОО. Сюда включены требования, относящиеся к инструментальным средствам разработки и опциям этих инструментальных средств, зависящим от реализации.
2.6.6Класс ATE. Тестирование
Класс доверия ATE устанавливает требования к тестированию, которое демонстрирует, что ФБО удовлетворяют функциональным требованиям безопасности ОО.
2.6.6.1Покрытие (ATE_COV)
Семейство "Покрытие" имеет дело с полнотой функциональных тестов, выполненных разработчиком для ОО. Оно связано со степенью тестирования функций безопасности ОО.
2.6.6.2Глубина (ATE_DPT)
Семейство "Глубина" имеет дело с уровнем детализации, на котором разработчик проверяет ОО. Тестирование функций безопасности основано на увеличивающейся глубине информации, получаемой из анализа представлений ФБО.
2.6.6.3Функциональное тестирование (ATE_FUN)
Семейство "Функциональное тестирование" устанавливает, что ФБО действительно демонстрируют свойства, необходимые для удовлетворения требований своего ЗБ. Функциональное тестирование обеспечивает доверие, что ФБО удовлетворяют, по меньшей мере, требованиям выбранных функциональных компонентов. Однако функциональные тесты не устанавливают, что ФБО не выполняют больше, чем от них ожидается. Это семейство сосредоточено на функциональном тестировании, выполняемом разработчиком.
2.6.6.4Независимое тестирование (ATE_IND)
Семейство "Независимое тестирование" определяет степень выполнения функционального тестирования ОО кем-либо, кроме разработчика (например, третьей стороной). Это семейство повышает ценность тестирования добавлением тестов, которые дополняют тесты разработчика.
2.6.7Класс AVA. Оценка уязвимостей
Класс доверия AVA определяет требования, направленные на идентификацию уязвимостей, которые могут быть активизированы. Особое внимание уделено уязвимостям, которые вносятся при проектировании, эксплуатации, неправильном применении или неверной конфигурации ОО.
2.6.7.1Анализ скрытых каналов (AVA_CCA)
Семейство "Анализ скрытых каналов" направлено на выявление и анализ непредусмотренных коммуникационных каналов, которые могут применяться для нарушения предписанной ПБО.
2.6.7.2Неправильное применение (AVA_MSU)
Семейство "Анализ неправильного применения" позволяет выяснить, способен ли администратор или пользователь, используя руководства, определить, что ОО конфигурирован или эксплуатируется небезопасным способом.
2.6.7.3Стойкость функций безопасности ОО (AVA_SOF)
Анализ стойкости направлен на функции безопасности ОО, которые реализованы с помощью вероятностного или перестановочного механизма (например, пароля или хэш-функции). Даже если такие функции нельзя обойти, отключить или исказить, не исключено, что их все же можно преодолеть прямой атакой. Может быть заявлен уровень или специальная метрика стойкости для каждой из этих функций. Анализ стойкости функций выполняют для принятия решения, отвечают ли такие функции сделанным заявлениям. Например, анализ стойкости механизма пароля может, показав достаточность области задания пароля, продемонстрировать, что функция, использующая этот механизм, отвечает заявленной стойкости.
2.6.7.4Анализ уязвимостей (AVA_VLA)
Анализ уязвимостей заключается в идентификации недостатков, которые могли быть внесены на различных этапах разработки. В результате определяются тесты проникновения, позволяющие получить всю совокупность необходимой информации относительно:
1) полноты ФБО (противостоят ли ФБО всем ожидаемым угрозам?);
зависимостей между всеми функциями безопасности.
Эти потенциальные уязвимости оценивают посредством тестирования проникновения, позволяющим сделать заключение, могут ли они в действительности быть использованы для нарушения безопасности ОО.
2.7Классификация поддержки
Требования по поддержке доверия, трактуемые как класс доверия, представлены с использованием структуры класса, определенной выше.
Семейства поддержки доверия и их краткие имена приведены в таблице 2.2.
Класс
|
Семейство доверия
|
Краткое имя
|
AMA –
Поддержка доверия
|
План поддержки доверия
|
AMA_AMP
|
Отчет о категорировании компонентов ОО
|
AMA_CAT
|
Свидетельство поддержки доверия
|
AMA_EVD
|
Анализ влияния на безопасность
|
AMA_SIA
|
Таблица 2.2 – Декомпозиция класса AMA "Поддержка доверия"
2.8Краткий обзор класса и семейств поддержки доверия
Ниже приведены краткие характеристики класса и семейств поддержки доверия из раздела 16.
2.8.1Класс AMA. Поддержка доверия
Класс AMA предназначен для поддержки уровня доверия, что ОО продолжит отвечать своему ЗБ при изменениях в ОО или его среде. Каждое из семейств этого класса определяет действия разработчика и оценщика, выполняемые после того, как ОО был успешно оценен, хотя некоторые требования применимы и при оценке.
2.8.1.1План поддержки доверия (AMA_AMP)
Семейство "План поддержки доверия" идентифицирует планы и процедуры, которые выполняет разработчик для обеспечения поддержки доверия, установленного к оцененному ОО, после изменений в ОО или его среде.
2.8.1.2Отчет о категорировании компонентов ОО (AMA_CAT)
Семейство "Отчет о категорировании компонентов ОО" представляет категорирование компонентов ОО (например, подсистем ФБО) по их отношению к безопасности. Это категорирование занимает центральное место в анализе разработчиком влияния на безопасность.
2.8.1.3Свидетельство поддержки доверия (AMA_EVD)
Семейство "Свидетельство поддержки доверия" направлено на то, чтобы убедиться в поддержке разработчиком доверия к ОО в соответствии с планом поддержки доверия.
2.8.1.4Анализ влияния на безопасность (AMA_SIA)
Семейство "Анализ влияния на безопасность" направлено на то, чтобы убедиться в поддержке доверия к ОО посредством проводимого разработчиком анализа влияния на безопасность ОО всех изменений после его оценки.
3Критерии оценки профиля защиты и задания по безопасности
3.1Краткий обзор
Настоящий раздел знакомит с критериями оценки для ПЗ и ЗБ, полностью представленными в классах APE "Оценка профиля защиты" и ASE "Оценка задания по безопасности" (разделы 4 и 5 соответственно).
Эти критерии – первые требования оценки, представленные в части 3 ОК, потому что, как правило, оценку ПЗ и ЗБ выполняют до оценки ОО. Они играют особую роль в оценке информации об ОО и оценке функциональных требований и требований доверия для выяснения, являются ли ПЗ и ЗБ содержательной основой для оценки ОО.
Хотя данные критерии оценки несколько отличаются от требований в разделах 8–14, они представлены аналогичным образом, потому что действия разработчика и оценщика при оценке сопоставимы для ПЗ, ЗБ и ОО.
Классы для ПЗ и ЗБ отличаются от классов для ОО тем, что при оценке ПЗ или ЗБ необходимо учесть все требования классов для ПЗ или ЗБ соответственно, в то время как далеко не все требования, представленные в классах для ОО, придется учитывать при оценке конкретного ОО.
Критерии оценки для ПЗ и ЗБ основаны на информации, приведенной в приложениях Б и В к части 1 ОК. Там можно найти полезную информацию о происхождении требований классов APE и ASE.
3.2Краткий обзор критериев профиля защиты
3.2.1Оценка профиля защиты
Цель оценки ПЗ – показать, что он является полным, непротиворечивым, технически правильным и поэтому пригоден для изложения требований к одному или нескольким оцениваемым ОО. Такой ПЗ может быть приемлем для включения в реестр ПЗ.
3.2.2Соотношение с критериями оценки задания по безопасности
Как показано в приложениях Б и В к части 1 ОК, имеется много совпадений в структуре и содержании ПЗ, ориентированного на определенный тип ОО, и ЗБ, разработанного для конкретного ОО. Поэтому многие критерии для оценки ПЗ содержат требования, которые подобны аналогичным для ЗБ и представлены таким же образом.
3.2.3Задачи оценщика
Оценщики ПЗ, который содержит требования только из ОК, должны применять требования класса APE, приведенные в таблице 3.1.
Таблица 3.1 – Семейства оценки профиля защиты, содержащего требования только из ОК
Класс
|
Семейство
|
Краткое имя
|
APE –
Оценка профиля защиты
|
Профиль защиты, описание ОО
|
APE_DES
|
Профиль защиты, среда безопасности
|
APE_ENV
|
Профиль защиты, введение ПЗ
|
APE_INT
|
Профиль защиты, цели безопасности
|
APE_OBJ
|
Профиль защиты, требования безопасности ИТ
|
APE_REQ
|
Оценщики ПЗ, который содержит требования не из ОК, должны применять требования класса APE, приведенные в таблице 3.2.
Таблица 3.2 – Семейства оценки профиля защиты с требованиями, расширяющими ОК
Класс
|
Семейство
|
Краткое имя
|
APE –
Оценка профиля защиты
|
Профиль защиты, описание ОО
|
APE_DES
|
Профиль защиты, среда безопасности
|
APE_ENV
|
Профиль защиты, введение ПЗ
|
APE_INT
|
Профиль защиты, цели безопасности
|
APE_OBJ
|
Профиль защиты, требования безопасности ИТ
|
APE_REQ
|
Профиль защиты, требования безопасности ИТ, сформулированные в явном виде
|
APE_SRE
|
3.3Краткий обзор критериев задания по безопасности
3.3.1Оценка задания по безопасности
Цель оценки ЗБ – показать, что оно является полным, непротиворечивым, технически правильным и поэтому пригодно для использования в качестве основы при оценке соответствующего ОО.
3.3.2Соотношение с другими критериями оценки из ОК
При оценке ОО различают две стадии: оценка ЗБ и непосредственно оценка ОО, к которому относится данное ЗБ. Требования для оценки ЗБ полностью представлены в разделе 5, а требования для оценки ОО содержатся в разделах 8–14.
Оценка ЗБ включает в себя оценку утверждений о соответствии ПЗ. Если в ЗБ не утверждается соответствие ПЗ, то в части ЗБ "Утверждения о соответствии ПЗ" должно быть указано, что соответствие какому-либо ПЗ для ОО не утверждается.
|
