ГОСТ Р ИСО/МЭК 15408-3-2013
В случаях, когда 0 0 зависит от других ИТ-сущностей, участвующих в обеспечении собственной
защиты, распределение ролей должно быть четким. Например. ОО. являющийся исключительно
прикладным программным обеспечением, полагается на базовую операционную систему для
правильного функционирования и чтобы не допускать превышения полномочий; приложение при этом
не может защитить себя от вредоносного влияния операционной системы в случае, если она
подрывает функционирование приложения (например, путем перезаписи кода исполняемого файла
или данных ФБО).
«Описание архитектуры безопасности» также охватывает то, как вводимые пользователем
данные обрабатываются ФБО таким образом, чтобы ФБО не могли быть повреждены вводимыми
пользователем данными. Например, ФБО могут реализовать понятие привилегий и защитить себя
путем включения привилегированного режима для обработки пользовательских данных. ФБО могут
использовать основанный на процессах механизм разделения (например, по уровню или рангу
привилегий), чтобы отделить код и данные ФБО от кода и данных пользователя. ФБО может
реализовать структуры программной защиты или стандарты кодирования, которые способствуют
реализации разделения программного обеспечения, к примеру, путем отделения адресного
пространства пользователя от адресного пространства системы.
Для ОО. которые запускаются в режиме минимума функциональных возможностей (например,
однопользовательский режим, доступный только для установщиков или администраторов), а затем
переводятся в оцененную безопасную конфигурацию (режим, в котором недоверенные пользователи
имеют возможность входа в систему с использованием логина и использования сервисов и ресурсов
ОО), «Описание архитектуры безопасности» также включает в себя объяснение того, как ФБО
защищена от кода инициализации, который не запускается в оцененной конфигурации. Для таких ОО
в «Описании архитектуры безопасности» объясняется, что именно позволяет предотвратить в
оцененной конфигурации доступ к сервисам, к которым следует предоставлять доступ только во
время инициализации (например, прямой доступ к ресурсам). В нём же объясняется, что позволяет
предотвратить запуск кода инициализации, когда ОО находится в оцененной конфигурации.
Там также должно быть объяснение того, как доверенный код инициализации будет
поддерживать целостность ФБО (и процессов их инициализации). Например, процесс инициализации
может выявить какие-либо изменения, которые приведут к тому, что ФБО будут обманным образом
выданы за функционирующие в первоначальном безопасном состоянии.
Действия по анализу уязвимостей и тестированию (см. AVA_VAN) скорее всего будут включать
в себя попытки нарушить описанную собственную защиту ФБО путем вмешательства, прямой атаки
или мониторинга ФБО.
А.1.2.3 Невозможность обхода ФБО
Свойство невозможности обхода касается интерфейсов, которые позволяют обойтимеханизмы,
осуществляющие безопасность. В большинстве случаев это является последствием реализации,
когда если программист пишет интерфейс, который осуществляет доступ к объекту или воздействует
на объект, то он несет ответственность за то. что будет использовать интерфейсы, являющиеся
частью осуществляющего выполнение ФТБ механизма, а не пытаться обойти их. Таким образом,
описанием, относящимся к невозможности обхода, следует охватить две широких области.
226