А). Особенности, связанные с межкатегорийным представлением <З`>
А-1. Прежде всего, коль скоро межкатегорийная плоскость <З`> отражает совокупности механизмов защиты, сконцентрированных в «клетках» модели OSE/RМ, следует пояснить, что представляет собой понятие «механизм защиты» [4].
Под механизмом защиты (Мх)будем понимать способ обеспечения требований безопасности без указания конкретной реализации, который может быть представлен теми или иными методами. В качестве Мх рассматриваются: механизмы управления доступом, контроля целостности, идентификации и аутентификации и др.
Метод защиты (М) также может быть реализован несколькими способами (например, идентификацию субъекта можно осуществить разными методами: паролем, методом биометрических характеристик, электронной карточкой). Реализация метода может быть выполнена одним или несколькими различными алгоритмами (А).
Таким образом, понятие Мх представляется иерархией референсности Мх(М(А)) (рис. 3), т.е. каждый Мх может быть реализован тем или иным методом, а каждый метод – тем или иным алгоритмом. Например, управление доступом, т.е. авторизованный доступ к объектам ИС на требуемом уровне и в соответствующем режиме, можно осуществлять мандатным или дискреционным методом, или иным. Нижний уровень – алгоритмический, тот же дискреционный метод может быть реализован атрибутными схемами, списками полномочий и т.п.
Выбор конкретной цепочки Мх(М(А)) зависит от:
а). Требуемого уровня безопасности, задаваемого вектором значений 
или 
для соответствующей «клетки» плоскости.
б). Требований нормативных регуляторов для государственных систем (например, согласно методическому документу «Меры защиты информации в государственных информационных системах», утвержденному федеральной службой по техническому и экспортному контролю (ФСТЭК) 11 февраля 2014 г., следует применять меры защиты, основанные на Мх идентификации и аутентификации субъектов и объектов доступа к СУБД государственного назначения).
в). Дополнительно для алгоритмов выбор определяется параметрами эффективности (затратами памяти, временем на выборку значений, удобством ведения данных о субъектах и объектах доступа, удобством отслеживания ограничений и зависимостей по наследованию полномочий и др.), а для криптоалгоритмов – оценками стойкости. При этом для получения более достоверных оценок стойкости необходимо использовать алгоритмы, основанные на государственных или международных стандартах, например, ГОСТ 34.10-2012, описывающий криптопреобразование усиленной электронной подписи, а также параметры эллиптических кривых для генерации ключа электронной подписи. А с учетом сертификационных требований российским предприятиям целесообразно использовать российские ГОСТы и нормативно-рекомендательные документы при построении профилей систем безопасности корпоративных ИС.
Поэтому в профиль целесообразно включать: а). ГОСТы или иные нормативные документы, описывающие выбранный алгоритм, т.к., особенно для криптоалгоритмов, именно стандарт позволяет реализовать алгоритм с более достоверной оценкой стойкости, что позволит обеспечить защитные свойства механизмов в соответствии с уровнем критериев 
или требованиями регуляторов; б). спецификации, отражающие те критерии и требования, на основе которых происходил выбор метода или механизма.
Таким образом, межкатегорийный профиль должен на уровне ГОСТов, нормативных документов и спецификаций фиксировать проектное решение цепочки «механизм-метод-алгоритм» Мх(М(А)) для каждой «клетки» <ИС> и <А> в соответствии с критериями а). - в).
А-2. Следующая особенность связана с семантической неоднородностью механизмов защиты, что позволило структурировать Мх на три категории, и их взаимосвязью.
Группа 1. Основные или целевые Мх(Ц): обеспечивающие свойства безопасности , реализаций «клеток» всех трех плоскостей: <ИС>, <A>, <З>.
Группа 2. Обеспечивающие Мх(О), те, которые осуществляют дополнительные действия, необходимые для функционирования целевых Мх на том или ином уровне безопасности. Например, идентификация и аутентификация (в некоторых случаях по требованию заказчика этот Мх может входить в группу основных механизмов); организация сеанса с ИС; организация доверенного канала/маршрута (туннели-рование); защита (уничтожение) остаточных данных; защита периметра от внешних воздействий с помощью межсетевых экранов и т.д.
Целью обеспечивающих Мх является удовлетворение потребностей целевых, т.е. эти Мх осуществляют дополнительные действия, необходимые для: а). организации функционирования целевых Мх, б). осуществления целевым Мх своего назначения на том или ином уровне.
Например, если к объекту БД («клетка» <ИС>.7 рис.1), для которого установлены те или иные права доступа (определен критерий конфиденциальности K), обращается некий субъект, то необходимо использовать механизм управления доступом (соответствующую цепочку Мх(М(А))) и описать в профиле, помимо цепочки Мх(М(А)), следующие механизмы из группы обеспечивающих:
1. механизм организации сеанса с ИС, чтобы предоставить возможность пользователю обратиться к СУБД;
2. механизм аутентификации субъекта (пользователя), который хочет обратиться к объекту СУБД, чтобы понять, что данный субъект является тем, кем он идентифицировался;
3. механизм идентификации и аутентификации объекта СУДБ;
4. механизм управления доступом (цепочка Мх(М(А))), который сопоставит права пользователя (субъекта) и файла (объекта), чтобы убедиться, что субъект обладает соответствующим правом.
5. чтобы обеспечить конфиденциальность файла на определенном уровне, надо использовать алгоритмы шифрования соответствующей стойкости механизма криптоподдержки.
Таким образом, каждый Мх из группы 1 требует поддержки обеспечивающих Мх(Ц)®(Мх(О1),Мх(О2),…,Мх(Оn)). Поэтому на самом деле межкатегорийная плоскость включает не только Мх, обеспечивающие , т.е. целевые, но к каждому целевому выстраивается и набор обеспечивающих Мх(Ц)®(Мх(О1),Мх(О2),…,Мх(Оn)), которые также подлежат профилированию по методике пункта А-1.
Группа 3. Управляющие механизмы Мх(У), те, которые обеспечивают согласованное функционирование Мх 1-й и 2-й групп. Это – мониторинг и аудит событий, происходящих в системе; анализ защищенности, т.е. выявление и анализ уязвимостей прикладной и платформенной компонент OSE/RM; оценка рисков, сопровождающих функционирование системы; администрирование системы безопасности.
Б). Особенности, связанные с проектным представлением <З``>
При профилировании проектного представления <З``> возникают две задачи.
а). Собственно формирование проектного представления <З``>, т.е. понять, в виде какой компоненты модели OSE/RM необходимо реализовывать Мх межкатегорийного представления. Понятно, что, например, управляющие механизмы реализуются как отдельные приложения. Решение этого вопроса для целевых и обеспечивающих Мх зависит от:
- влияния расположения механизма в системе на вклад в защиту «клеток» одного уровня и расположенных выше «клетки» локализации (чем ниже встроен Мх, тем большему количеству «клеток», расположенных выше по модели он обеспечит защиту);
- влияния локализации Мх на производительность других компонент системы.
б). Профилирование компонент сформированного проектного представления <З``>, а также межкомпонентных интерфейсов в соответствии со стандартами и спецификациями, связанными с системо-технической структурой КСЗ как информационной системы.
Имеется в виду, что комплект документов на проектирование КСЗ должен содержать а). профили приложений, реализующих защитные механизмы межкатегорийной плос-кости. Объектами стандартизации профиля приложений являются компоненты приложений в структу-ризации USIC (см. рис.1), а также программные интерфейсы между компонентами и приложениями; б). профили среды, которые определяют сервисы, предоставляемые приложе-ниям со стороны платформенной компоненты (промежуточный слой); услуги операционных систем, а также требования и интерфейсы к устройствам аппаратного слоя (рис. 4).