ГОСТ Р ИСО 7498-2-99 Информационная технология (ИТ). Взаимосвязь открытых систем. Базовая эталонная модель. Часть 2. Архитектура защиты информации
5.4 Общеархитектурные механизмы защиты
В данном подразделе описан ряд механизмов, которые не являются специфичными для любой конкретной услуги. Так, в разделе 7 эти механизмы описаны неявно, как принадлежащие любому отдельному уровню. Некоторые из этих общеархитектурных механизмов защиты могут рассматриваться как аспекты административного управления защитой (см. также раздел 8). Назначение этих механизмов в основном прямо зависит от запрашиваемой степени защиты.
5.4.1 Доверительная функциональность
5.4.1.1 Доверительная функциональность должна использоваться для расширения области применения или повышения эффективности других механизмов защиты. Любая функциональность, непосредственно обеспечивающая механизмы защиты или доступ к ним, должна быть заслуживающей доверия.
5.4.1.2 Процедуры, используемые для гарантии включения таких доверительных функциональностей в соответствующие аппаратные и программные средства, не входят в предмет рассмотрения настоящего стандарта и в любом случае зависят от уровня воспринимаемой угрозы и ценности защищаемой информации.
5.4.1.3 Как правило, такие процедуры дорогостоящи и сложны в реализации. Эти проблемы могут быть минимизированы путем выбора архитектуры, позволяющей реализовать функции защиты в модулях, которые могут быть выполнены отдельно от функций, не связанных с защитой, и защищены от них.
5.4.1.4 Любая защита ассоциаций, устанавливаемых выше того уровня, на котором предусматривается эта защита, должна обеспечиваться другими средствами, например, соответствующей доверительной функциональностью.
5.4.2 Метки защиты
Ресурсы, включающие элементы данных, могут иметь связанные с ними метки защиты, например, метки, предназначенные для указания уровня чувствительности. Часто с транзитными данными необходимо передавать соответствующие метки защиты. Метка защиты может представлять собой дополнительные данные, связанные с передаваемыми данными, или может быть неявной, например, она может предполагаться при использовании специального ключа для шифрования данных или контекста данных, включающего описание отправителя или маршрута. Неявные метки защиты должны быть точно идентифицированы для обеспечения их соответствующей проверки. Кроме того, они должны быть надежно связаны с соответствующими данными.
5.4.3 .Обнаружение события
5.4.3.1 Обнаружение события, относящегося к защите, состоит в выявлении видимых нарушений защиты и может также представлять собой обнаружение "нормальных" событий, таких как успешное получение права на доступ (или подключение к системе). События, относящиеся к защите, могут распознаваться логическими объектами в рамках ВОС, включающими механизмы защиты. Спецификация параметров, составляющих какое-либо событие, обеспечивается административным управлением обработкой событий (см. 8.3.1). Обнаружение различных событий, относящихся к защите, может вызвать, например, одно или несколько следующих действий:
a) выдача локального сообщения о событии;
b) выдача удаленного сообщения о событии;
c) регистрация события в системном журнале (см. 5.4.3);
d) действие процедуры восстановления (см. 5.4.4).
Примерами событий, относящихся к защите, могут служить следующие ситуации:
а) нарушение специальной защиты;
b) выбранное специфическое событие;
c) переполнение счетчика количества ситуаций.
5.4.3.2 Стандартизация поля обнаружения события должна учитывать передачу информации, связанной с выдачей сообщения о событии и его регистрацией, а также синтаксическое и семантическое определения, используемые для передачи сообщения о событии и его регистрации.
5.4.4 Данные отслеживания защиты
5.4.4.1 Данные отслеживания защиты обеспечивают надежный механизм защиты, поскольку они предоставляют потенциальную возможность обнаружения и исследования пробелов защиты путем выдачи последующего анализа процедур защиты. Анализ процедур защиты предусматривает независимый просмотр и анализ системных записей и активностей для проверки адекватности системным функциям управления, обеспечения соответствия с принятой стратегией защиты и операционными процедурами, оценки нарушения защиты и выдачи рекомендаций о любых задаваемых изменениях в функциях управления, стратегии и процедурах защиты. Анализ процедур защиты требует регистрации информации, относящейся к защите, в виде данных отслеживания защиты, а также анализа информации, извлекаемой из данных отслеживания защиты, и уведомления о его результатах. Документирование или регистрация в системном журнале рассматриваются в качестве механизма защиты и описаны в настоящем разделе. Анализ и генерацию сообщений рассматривают в качестве функции административного управления защитой (см. 8.3.2).
5.4.4.2 Сбор информации о данных отслеживания защиты может удовлетворять различным требованиям путем определения типов событий, относящихся к защите и подлежащих регистрации (например, видимые нарушения защиты или завершение успешных операций).
Сведения о наличии данных отслеживания защиты могут служить в качестве сдерживающего фактора для некоторых потенциальных источников нарушения защиты.
5.4.4.3 Организация данных отслеживания защиты ВОС должна рассматриваться с учетом того, какая информация должна дополнительно записываться в системный журнал, при каких обстоятельствах эта информация должна документироваться, а также какие синтаксические и семантические определения должны использоваться для обмена информацией о данных отслеживания защиты.
5.4.5 Процедура восстановления защиты
5.4.5.1 Процедура восстановления защиты связана с запросами от таких механизмов, как функции обработки событий и административного управления, и выполняет действия по восстановлению в соответствии с используемым набором правил. Эти действия по восстановлению могут относиться к одному из следующих трех типов:
a) немедленные;
b) временные;