Законодательная база Российской Федерации

"МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)

Ниже приведены краткие списания классов и семейств доверия из разделов 12 - 18, представленные в том же порядке, е котором они - изложены в этим разделах.

6.6.1 Класс АСМ: Управление конфигурации.

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

6.6.1.1 Автоматизация УК (ACM_AUT)

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

6.6.1.2 Возможности УК (АСМ_САР)

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

6.6.1.3 Область УК (ACM_SCP)

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

6.6.2 Класс ADO: Поставкам эксплуатация

Класс доверия ADO "Поставка и эксплуатация" определяет требования к мерам, процедурам и стандартам применяемым для безопасной поставки, установки и эксплуатации ОО, обеспечивая, чтобы безопасность ОО не нарушалась во время его распространения, установки и эксплуатации.

6.6.2.1 Поставка (ADO_DEL)

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

6.6.2.2 Установка, генерация и запуск (ADO_IGS)

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

6.6. 3 Класс ADV: Разработка

Класс доверия ADV "Разработка" определяет требования для пошагового уточнения ФБО. начиная с краткой спецификации ОО в ЗБ и до фактической реализации. Каждое из получаемых представлений ФБО содержит информацию, помогающую оценщику решить, были ли выполнены функциональные требования к ОО.

6.6.3.1 Функциональная спецификация (ADV_FSP)

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

6.6.3.2 Проект верхнего уровня (ADV_HLD)

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

6.6.3.3 Представление- реализаций (AOV_IMP)

Представление реализации - наименее абстрактное представление ФБО. Оно фиксирует детализированное внутреннее содержание ФБО на уровне исходного текста, аппаратных схем и т.п.

6.6.3.4 Внутренняя структура ФБО (ADV_INT)

Требования к внутренней структуре ФБО определяют необходимое внутреннее структурирование ФБО.

6.6.3.5 Проект нижнего уровня (ADV_LLD)

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

6.6.3.6 Соответствие представлений (ADV_RCR)

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

6.6.3.7 Моделирование политики безопасности (ADV_SPM)

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

6.6.4 Класс AGD: Руководства

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

6.6.4.1 Руководство администратора (AGD_ADM)

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

6.6.4.2.Руководство пользователя (AGD_USR)

6.6.5 Класс ALC: Поддержка жизненного цикла

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

6.6.5.1 Безопасность разработки (ALC_OVS)

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

6.6.5.2 Устранение недостатков (ALC_FLR)

6.6.5.3 Определение жизненного цикла (ALC_LCD)

6.6.5.4 Инструментальные средства и метода (АLС_ТАТ)

6.6.6 Класс АРЕ: Оценка профиля защиты

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

6.6.7 Класс ASE: Оценка задания по безопасности

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

6.6.8 Класс ATE: Тестирование

Класс доверия ATE устанавливает требования к тестированию, которое демонстрирует, что ФБО удовлетворяют функциональным требованиям безопасности ОО.

6.6.8.1 Покрытие (ATE_COV)

Семейство "Покрытие" устанавливает полноту функциональных тестов, выполненных разработчиком для ОО. Оно связано со степенью тестирования функций безопасности ОО.

6.6.8.2 Глубина (АТЕ_СРТ)

Семейство "Глубина" устанавливает уровень детализации, на котором разработчик проверяет ОО. Тестирование функций безопасности основано на увеличивающейся глубине информации, получаемой из анализа представлений ФЕО.

6.6.8.3 Функциональное тестирование (ATE_FUN)

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

6.6.8.4 Независимое тестирование (ATE_IND)

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

6.6.9 Класс AVA: Оценка уязвимостей

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

6.6.9.1 Анализ скрытых каналов (AVA_CCA)

Семейство "Анализ скрытых каналов" направлено на выявление и анализ непредусмотренных коммуникационных каналов, которые могут применяться для нарушения предписанной ПВО.

6.6.9.2 Неправильное применение (AVA_MSU)

Семейство "Анализ неправильного применения" позволяет выяснить, способен ли администратор или пользователь, используя руководства, определить, что ОО конфигурирован или эксплуатируется небезопасным способом.

6.6.9.3 Стоимость функций безопасности ОО (AVA_SOF)

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

6.6.9.4 Анализ уязвимостей (AVA_VLA)

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

1) полноты ФБО (противостоят ли ФБО всем ожидаемым угрозам)

2) зависимостей между всеми функциями безопасности.

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