Многоуровневая безопасность - Multilevel security

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

Надежные операционные системы

MLS рабочая среда часто требует высоконадежной системы обработки информации, часто построенной на операционной системе (ОС) MLS, но не обязательно. Большинство функциональных возможностей MLS может поддерживаться системой, полностью состоящей из ненадежных компьютеров, хотя для этого требуется несколько независимых компьютеров, соединенных аппаратными каналами, совместимыми с безопасностью (см. Раздел B.6.2 Интерпретации доверенных сетей, NCSC-TG-005 ). Примером MLS с аппаратным обеспечением является асимметричная изоляция.[1] Если один компьютер используется в режиме MLS, то этот компьютер должен использовать доверенную операционную систему (ОС). Поскольку вся информация в среде MLS физически доступна ОС, должны существовать строгие логические элементы управления, чтобы гарантировать, что доступ к информации строго контролируется. Обычно это включает принудительный контроль доступа который использует защитные метки, такие как Модель Белла – ЛаПадулы.

Заказчики, которые развертывают доверенные операционные системы, обычно требуют, чтобы продукт прошел формальную оценку компьютерной безопасности. Оценка более строгая для более широкого диапазона безопасности, который является самым низким и самым высоким уровнями классификации, которые может обработать система. В Критерии оценки доверенных компьютерных систем (TCSEC) был первым критерием оценки, разработанным для оценки MLS в компьютерных системах. По этим критериям было четкое единообразное отображение[2] между требованиями безопасности и широтой диапазона безопасности MLS. Исторически немногие реализации были сертифицированы для обработки MLS с диапазоном безопасности от Несекретного до Совершенно секретно. Среди них были Honeywell SCOMP, ВВС США САКДИН, АНБ с Чернее, и Боинг MLS LAN, все под TCSEC, винтаж 1980-х и Intel 80386 -на основании. В настоящее время продукция MLS проходит оценку Общие критерии. В конце 2008 года первая операционная система (подробнее см. Ниже) была сертифицирована на высокий уровень гарантии: Уровень гарантии оценки (EAL) - EAL 6+ / Высокая надежность, под эгидой правительственной программы США, требующей многоуровневой безопасности в среде с высоким уровнем угроз. Хотя этот уровень доверия имеет много общего с уровнем гарантии старой Orange Book A1 (например, формальные методы), функциональные требования сосредоточены на фундаментальных политиках изоляции и информационных потоков, а не на политиках более высокого уровня, таких как Bell-La Padula. Поскольку Common Criteria развязал соединение TCSEC обеспечения (EAL) и функциональности (Protection Profile), четкое единообразное соответствие между требованиями безопасности и возможностями диапазона безопасности MLS, задокументированное в CSC-STD-004-85, было в значительной степени потеряно, когда Common Criteria заменил собой Радуга серии.

Свободно доступные операционные системы с некоторыми функциями, поддерживающими MLS, включают Linux с Linux с повышенной безопасностью функция включена и FreeBSD.[3] Когда-то считалось, что оценка безопасности является проблемой для этих бесплатных реализаций MLS по трем причинам:

  1. Всегда очень сложно реализовать стратегию самозащиты ядра с точностью, необходимой для доверия MLS, и эти примеры не были разработаны или сертифицированы для профиля защиты MLS, поэтому они могут не обеспечивать самозащиту, необходимую для поддержки MLS.
  2. Помимо уровней EAL, в Common Criteria отсутствует перечень соответствующих профилей защиты с высоким уровнем гарантии, которые определяют надежность, необходимую для работы в режиме MLS.
  3. Даже если (1) и (2) были выполнены, процесс оценки очень дорог и накладывает особые ограничения на управление конфигурацией оцениваемого программного обеспечения.

Несмотря на такие предположения, Red Hat Enterprise Linux 5 был сертифицирован по LSPP, RBACPP и CAPP на EAL4 + в июне 2007 года.[4] Он использует Linux с улучшенной безопасностью для реализации MLS и был первым сертификатом Common Criteria для обеспечения свойств безопасности ОО с Linux с расширенной безопасностью.

Стратегии сертификации поставщиков могут ввести в заблуждение неспециалистов. Обычная стратегия использует чрезмерное внимание непрофессионала к уровню EAL с чрезмерной сертификацией, например, сертификация профиля защиты EAL 3 (например, CAPP).[5] до повышенных уровней, таких как EAL 4 или EAL 5. Другой способ - добавление и сертификация функций поддержки MLS (таких как управление доступом на основе ролей профиль защиты (RBACPP) и помеченный профиль защиты безопасности (LSPP)) для ядра, которое не оценивается как профиль защиты с поддержкой MLS. Эти типы функций представляют собой службы, запускаемые в ядре и зависящие от ядра для защиты их от повреждения и подрывной деятельности. Если ядро ​​не оценивается по профилю защиты с поддержкой MLS, функциям MLS нельзя доверять, независимо от того, насколько впечатляющей выглядит демонстрация. Особо следует отметить, что CAPP специально не профиль с поддержкой MLS, поскольку он специально исключает возможности самозащиты, критичные для MLS.

Общая динамика предложения Питбуль, надежная операционная система MLS. PitBull в настоящее время предлагается только как расширенная версия Red Hat Enterprise Linux, но более ранние версии существовали для Sun Microsystems Solaris, IBM AIX и SVR4 Unix. PitBull предоставляет Белл ЛаПадула механизм безопасности, Биба механизм целостности, замена привилегий для суперпользователь, и многие другие функции.PitBull имеет основу безопасности для доверенной сетевой среды General Dynamics. (TNE) продукт с 2009 года. TNE обеспечивает многоуровневый обмен информацией и доступ для пользователей в сообществах Министерства обороны и разведки, использующих различные уровни классификации. Это также основа для многоуровневой среды совместного использования коалиций, расширенных систем сбора и эксплуатации информации поля боя.[6] (BICES-X).

Sun Microsystems, сейчас же Корпорация Oracle, предложения Надежные расширения Solaris как интегрированная функция коммерческих ОС Солярис и OpenSolaris. В дополнение к профилю защиты контролируемого доступа (CAPP) и управление доступом на основе ролей (RBAC) профили защиты, доверенные расширения также были сертифицированы на EAL4 для маркированного профиля защиты безопасности (LSPP).[7] Цель безопасности включает как настольные, так и сетевые функции. LSPP требует, чтобы пользователи не имели права отменять политику маркировки, применяемую ядром, и X Window System (Сервер X11). Оценка не включает скрытый канал анализ. Поскольку эти сертификаты зависят от CAPP, сертификаты Common Criteria не предполагают, что этот продукт заслуживает доверия для MLS.

BAE Systems предложения XTS-400, коммерческая система, которая поддерживает MLS с «высокой степенью надежности», по заявлению поставщика. Продукты-предшественники (включая XTS-300) оценивались на уровне TCSEC B3, который поддерживает MLS. XTS-400 был оценен по общим критериям на уровне EAL5 + по профилям защиты CAPP и LSPP. CAPP и LSPP являются профилями защиты EAL3, которые изначально не поддерживают MLS, но являются целью безопасности.[8] для оценки Common Criteria этого продукта содержится расширенный набор функций безопасности, обеспечивающих возможность MLS.

Проблемные зоны

Дезинфекция является проблемной зоной для систем MLS. Системы, реализующие ограничения MLS, например, определенные Модель Белла – ЛаПадулы, разрешать совместное использование только в том случае, если это явно не нарушает ограничений безопасности. Пользователи с более низким уровнем допуска могут легко делиться своей работой с пользователями с более высоким уровнем допуска, но не наоборот. Не существует эффективного и надежного механизма, с помощью которого пользователь совершенно секретно может редактировать совершенно секретный файл, удалять всю совершенно секретную информацию и затем доставлять ее пользователям с секретным или более низким уровнем допуска. На практике системы MLS обходят эту проблему с помощью привилегированных функций, которые позволяют надежному пользователю обойти механизм MLS и изменить классификацию безопасности файла. Однако техника ненадежный.

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

Обход является проблематичным, когда вводится как средство обработки объекта высокого уровня системы, как если бы он был доверенным MLS. Типичным примером является извлечение данных из секретного системного объекта высокого уровня для отправки в неклассифицированное место назначения, указав какое-либо свойство данных в качестве надежного доказательства того, что они «действительно» неклассифицированы (например, «строгий» формат). Системе высокого уровня нельзя доверять сохранение каких-либо доверенных свидетельств, и в результате открывается открытый путь к данным без логического способа его безопасного посредничества. Обход может быть рискованным, потому что, в отличие от скрытых каналов с узкой полосой пропускания, которые трудно использовать, обход может привести к большой, легко используемой открытой утечке в системе. Обход часто возникает из-за невозможности использовать доверенные операционные среды для поддержания непрерывного разделения доменов безопасности на всем пути до их происхождения. Когда этот источник находится за пределами границы системы, может оказаться невозможным подтвердить доверенное разделение на источник. В этом случае риск обхода может быть неизбежен, если поток действительно необходим.

Типичным примером неизбежного обхода является субъектная система, которая должна принимать секретные IP-пакеты от ненадежного источника, шифровать секретные данные пользователя, а не заголовок, и передавать результат в ненадежную сеть. Источник находится вне сферы влияния субъектной системы. Хотя источник не является доверенным (например, высокий уровень системы), ему доверяют, как если бы это был MLS, поскольку он предоставляет пакеты с неклассифицированными заголовками и секретными пользовательскими данными в виде открытого текста, конструкцией данных MLS. Поскольку источник не является доверенным, он может быть поврежден и хранить секреты в неклассифицированном заголовке пакета. Поврежденные заголовки пакетов могут быть бессмысленными, но субъектная система не может определить это с какой-либо разумной надежностью. Данные пользователя пакета криптографически хорошо защищены, но заголовок пакета может содержать читаемые секреты. Если поврежденные пакеты передаются в ненадежную сеть субъектной системой, они могут быть не маршрутизируемыми, но какой-то взаимодействующий поврежденный процесс в сети может захватить пакеты и подтвердить их, а субъектная система может не обнаружить утечку. Это может быть большая явная утечка, которую трудно обнаружить. Просмотр классифицированных пакетов с неклассифицированными заголовками как системных структур вместо структур MLS, которыми они на самом деле являются, представляет собой очень распространенную, но серьезную угрозу.

В большинстве случаев обхода можно избежать. Избегаемый обход часто возникает, когда системные архитекторы проектируют систему до того, как правильно учли безопасность, а затем пытаются применить безопасность постфактум в качестве дополнительных функций. В этой ситуации обход оказывается единственным (простым) способом заставить систему работать. Предлагаются (и одобряются!) Некоторые псевдобезопасные схемы, которые проверяют содержимое обойденных данных в тщетной попытке установить, что обойденные данные не содержат секретов. Это невозможно без доверия к данным, например к их формату, что противоречит предположению о том, что источнику не доверяют сохранение каких-либо характеристик исходных данных. Гарантированный «безопасный обход» - это миф, так же как и так называемый Страж высокой уверенности (HAG), который прозрачно реализует обход. Риск, который они представляют, давно признан; существующие решения в конечном итоге носят процедурный, а не технический характер. Невозможно с уверенностью узнать, сколько секретной информации получено из наших систем с помощью обхода.

«Не бывает MLS»

Наблюдается снижение КОМПЬЮЗЕК эксперты [9] и срок MLS был перегружен. Непрофессионалы проектируют безопасные вычислительные системы и приходят к выводу, что MLS не существует. Эти два использования: MLS как среда обработки против MLS как возможность. Убеждение, что MLS не существует, основано на убеждении, что нет продуктов, сертифицированных для работы в MLS. Окружающая среда или режим, и поэтому MLS как способность не существует. Одно не подразумевает другого. Многие системы работают в среде, содержащей данные с неодинаковыми уровнями безопасности и, следовательно, являются MLS в соответствии с теоремой о промежуточном значении компьютерной безопасности (CS-IVT).[10] Последствия этой путаницы еще глубже. Сертифицированные NSA операционные системы, базы данных и сети MLS существуют в рабочем режиме с 1970-х годов, и продукты MLS продолжают создаваться, продаваться и развертываться.

Непрофессионалы часто приходят к выводу, что признание того, что система работает в среде MLS (ориентированное на среду значение MLS), должно быть подкреплено воспринимается угол наличия проблемы без решения MLS (значение MLS, ориентированное на возможности). MLS обманчиво сложна, и то, что простые решения не очевидны, не оправдывает вывода о том, что их не существует. Это может привести к ужасающему невежеству в отношении COMPUSEC, которое проявляется как шепот, что «нельзя говорить о MLS» и «Нет такой вещи, как MLS». Эти схемы отказа MLS меняются так быстро, что их невозможно устранить. Вместо этого важно прояснить различие между MLS-средой и MLS-совместимой.

  • MLS как среда безопасности или безопасный режим: Сообщество, пользователи которого имеют разные уровни допуска, может воспринимать MLS как обмен данными возможность: пользователи могут обмениваться информацией с получателями, допуск которых позволяет получать эту информацию. Система работает в режиме MLS, когда у нее есть (или может быть) возможность подключения к пункту назначения, который очищен до более низкого уровня безопасности, чем любые данные, содержащиеся в системе MLS. Это формализовано в CS-IVT. Определение режима безопасности системы полностью зависит от среды безопасности системы; классификация данных, которые он содержит, допуск тех, кто может получить прямой или косвенный доступ к системе или ее выходам или сигналам, а также возможности подключения системы и порты к другим системам. Режим безопасности не зависит от возможностей, хотя система не должна работать в режиме, в котором она не заслуживает доверия.
  • MLS как способность: Разработчики продуктов или систем, предназначенных для обеспечения совместного использования данных MLS, как правило, слабо воспринимают это с точки зрения возможности применять ограничения на совместное использование данных или политику безопасности, например механизмы, обеспечивающие соблюдение Модель Белла – ЛаПадулы. Система является совместимой с MLS, если можно показать, что она надежно реализует политику безопасности.

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

Архитектура MILS

Несколько независимых уровней безопасности (MILS) - это архитектура, которая обращается к компоненту разделения доменов MLS. Обратите внимание, что UCDMO (руководитель правительства США в области междоменных и многоуровневых систем) создал термин Междоменный доступ в качестве категории в исходном состоянии DoD и Разведывательное сообщество аккредитованные системы, и эту категорию можно рассматривать как аналог MILS.

Модели безопасности, такие как Биба модель (для целостности) и Модель Белла – ЛаПадулы (для конфиденциальности) разрешить односторонний поток между определенными доменами безопасности, которые в противном случае считаются изолированными. MILS направлен на изоляцию, лежащую в основе MLS, без обращения к контролируемому взаимодействию между доменами, на которое обращаются вышеуказанные модели. Упомянутые выше доверенные каналы, совместимые с безопасностью, могут связывать домены MILS для поддержки дополнительных функций MLS.

Подход MILS следует стратегии, характеризуемой более старым термином MSL (несколько одноуровневых), который изолирует каждый уровень информации в своей собственной одноуровневой среде (Система высокий ).

Жесткая коммуникация и изоляция процессов, предлагаемые MILS, могут быть более полезны для программных приложений сверхвысокой надежности, чем MLS. В частности, MILS не обращается к иерархической структуре, воплощенной в понятии уровней безопасности. Это требует добавления определенных приложений импорта / экспорта между доменами, каждый из которых требует соответствующей аккредитации. Таким образом, MILS можно было бы лучше назвать несколькими независимыми доменами безопасности (для эмуляции MLS на MILS потребуется аналогичный набор аккредитованных приложений для приложений MLS). Отказавшись от решения нестандартного взаимодействия между уровнями, согласующегося с иерархическими отношениями Bell-La Padula, MILS (почти обманчиво) прост в реализации на начальном этапе, но требует нетривиальных дополнительных приложений импорта / экспорта для достижения богатства и гибкости, ожидаемых практическое применение MLS.

При любом сравнении MILS / MLS следует учитывать, является ли аккредитация набора более простых экспортных приложений более достижимой, чем аккредитация одного, более сложного ядра MLS. Этот вопрос частично зависит от степени взаимодействия импорта / экспорта, которое требуется заинтересованным сторонам. В пользу MILS говорит вероятность того, что не для всех экспортных приложений потребуется максимальная гарантия.

Системы MSL

Есть еще один способ решения таких проблем, известный как несколько одноуровневых. Каждый уровень безопасности изолирован в отдельном ненадежном домене. Отсутствие средства связи между доменами гарантирует невозможность взаимодействия. Механизм этой изоляции обычно заключается в физическом разделении на отдельные компьютеры. Это часто используется для поддержки приложений или операционные системы которые не имеют возможности поддерживать MLS, такие как Майкрософт Виндоус.

Приложения

Инфраструктура, такая как доверенные операционные системы, является важным компонентом систем MLS, но для выполнения критериев, требуемых в соответствии с определением MLS, необходимо: CNSSI 4009 (перефразировано в начале этой статьи), система должна предоставлять пользовательский интерфейс, который позволяет пользователю получать доступ и обрабатывать контент на нескольких уровнях классификации из одной системы. UCDMO запустил трек, специально посвященный MLS на АНБ Симпозиум по обеспечению информации в 2009 году, на котором было выделено несколько аккредитованных (в производстве) и новых систем MLS. Обратите внимание на использование MLS в SELinux.[11]

Есть несколько баз данных, классифицируемых как системы MLS. Oracle есть продукт под названием Oracle Label Security (OLS), который реализует принудительный контроль доступа - обычно путем добавления столбца "метка" к каждой таблице в База данных Oracle. OLS развертывается в Армия Соединенных Штатов ИНСКОМ в качестве основы интеллектуальной базы данных «из всех источников», охватывающей JWICS и SIPRNet сети. Есть проект по созданию помеченной версии PostgreSQL, а также есть более старые реализации помеченных баз данных, такие как Надежный Rubix. Эти системы баз данных MLS обеспечивают единую внутреннюю систему для контента, охватывающего несколько ярлыков, но они не решают проблему, связанную с тем, что пользователи обрабатывают контент на нескольких уровнях безопасности в одной системе, обеспечивая при этом обязательный контроль доступа.

Есть также несколько приложений для конечных пользователей MLS. Другая возможность MLS, которая в настоящее время находится на базовом уровне UCDMO, называется MLChat, и это чат-сервер, работающий на XTS-400 операционная система - она ​​была создана США Лаборатория военно-морских исследований. Учитывая, что контент от пользователей из разных доменов проходит через сервер MLChat, сканирование грязных слов используется для защиты секретного контента, и были некоторые споры о том, действительно ли это система MLS или больше междоменный перенос защита данных. Обязательный контроль доступа поддерживаются комбинацией XTS-400 и механизмы для конкретных приложений.[12]

Совместная междоменная биржа (JCDX) - еще один пример возможности MLS, которая в настоящее время UCDMO[постоянная мертвая ссылка ] исходный уровень. JCDX - единственная аккредитованная Министерством обороны (DoD), Управлением военной разведки (DIA) многоуровневая система безопасности (MLS) для командования, управления, связи, компьютеров и разведки (C4I), которая обеспечивает поддержку разведки и предупреждения в режиме реального времени на театре военных действий и в будущем развернуты тактические командиры. Архитектура JCDX полностью интегрирована с защищенной операционной системой с высоким уровнем защиты 4 (PL4), использующей маркировку данных для распространения информации о силовых действиях и потенциальных террористических угрозах в Мировом океане и вокруг них в режиме, близком к реальному времени. Он установлен в местах в США и странах-партнерах, где он может предоставлять данные от Top Secret / SCI до уровней Secret-Releasable, и все это на единой платформе.

Приложения MLS, которые в настоящее время не входят в базовый план UCDMO, включают несколько приложений из BlueSpace. BlueSpace имеет несколько приложений MLS, включая почтовый клиент MLS, поисковое приложение MLS и систему MLS C2. BlueSpace использует стратегию промежуточного программного обеспечения, чтобы его приложения не зависели от платформы, организуя один пользовательский интерфейс для нескольких Windows Экземпляры ОС (виртуализированный или сеансы удаленного терминала ). Соединенные штаты Лаборатория военно-морских исследований также реализовал многоуровневую структуру веб-приложений под названием MLWeb который объединяет Рубин на рельсах фреймворк с многоуровневой базой данных на основе SQLite3.

Будущее

Возможно, самым большим изменением, происходящим сегодня на арене многоуровневой безопасности, является конвергенция MLS с виртуализацией. Все большее число доверенных операционных систем отказываются от маркировки файлов и процессов, а вместо этого переходят к Контейнеры UNIX или виртуальные машины. Примеры включают зоны в Solaris 10 TX, а заполненная ячейка гипервизор в таких системах, как Зеленые холмы Честность платформа и XenClient XT от Citrix. В Платформа высокой надежности от АНБ как реализовано в Общая динамика ' Надежная среда виртуализации (TVE) - другой пример - он использует SELinux по своей сути, и может поддерживать приложения MLS, которые охватывают несколько доменов.

Смотрите также

использованная литература

  1. ^ Дэвидсон, Дж. (1996-12-09). Асимметричная изоляция. Конференция по приложениям компьютерной безопасности. С. 44–54. Дои:10.1109 / CSAC.1996.569668. ISBN  978-0-8186-7606-2.
  2. ^ CSC-STD-004-85: Требования к компьютерной безопасности - Руководство по применению критериев оценки доверенных компьютерных систем Министерства обороны в определенных средах (25 июня 1985 г.)
  3. ^ Политика конфиденциальности многоуровневой безопасности во FreeBSD
  4. ^ «Утвержденный продукт - Red Hat Enterprise Linux версии 5, работающий на оборудовании IBM». Национальное партнерство по обеспечению информации, Схема оценки и проверки общих критериев, США. 7 июня 2007 г. Цитировать журнал требует | журнал = (Помогите)
  5. ^ Профиль защиты контролируемого доступа (CAPP)
  6. ^ Коррин, Эмбер (2017-08-08). «Как BICES-X способствует глобальному анализу». C4ISRNET. Получено 2018-12-10.
  7. ^ «Доверенные расширения Solaris 10, выпуск 11/06». Управление безопасности связи Канады. 2008-06-11. Архивировано из оригинал на 2011-06-17. Получено 2010-06-26. Цитировать журнал требует | журнал = (Помогите)
  8. ^ «Цель безопасности, версия 1.22 для XTS-400, версия 6.4.U4» (PDF). Национальное партнерство по обеспечению информации, Схема оценки и проверки общих критериев, США. 2008-06-01. Архивировано из оригинал (PDF) на 2011-07-23. Получено 2010-08-11. Цитировать журнал требует | журнал = (Помогите)
  9. ^ Дэвид Эллиотт Белл: Оглядываясь назад на модель Белла – ЛаПадулы - Приложение В архиве 2011-08-27 на Wayback Machine (20 декабря 2006 г.)
  10. ^ Дэвид Эллиотт Белл: Оглядываясь назад на модель Белла – ЛаПадулы (7 декабря 2005 г.)
  11. ^ Например: Петерсен, Ричард (2011). Fedora 14 Администрирование и безопасность. Серфинг Turtle Press. п. 298. ISBN  9781936280223. Получено 2012-09-13. Справочная политика SELinux [...] Многоуровневая безопасность (MLS) добавляет более совершенный метод безопасного доступа. MLS добавляет к ресурсам значение уровня безопасности.
  12. ^ http://www.sse.gr/NATO/EreunaKaiTexnologiaNATO/36.Coalition_C4ISR_architectures_and_information_exchange_capabilities/RTO-MP-IST-042/MP-IST-042-12.pdf[постоянная мертвая ссылка ]

дальнейшее чтение

внешние ссылки