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

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

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

Это различие важно, поскольку системы, которым нужно доверять, не обязательно заслуживают доверия.

Доверенные операционные системы

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

Клиенты, развертывающие доверенные операционные системы, обычно требуют, чтобы продукт прошел официальную оценку компьютерной безопасности. Оценка более строгая для более широкого диапазона безопасности, который представляет собой самый низкий и самый высокий уровни классификации, которые может обрабатывать система. Критерии оценки доверенных компьютерных систем (TCSEC) были первыми критериями оценки, разработанными для оценки MLS в компьютерных системах. В соответствии с этими критериями существовало четкое единообразное отображение между требованиями безопасности и широтой диапазона безопасности MLS. Исторически лишь немногие реализации были сертифицированы для обработки MLS с диапазоном безопасности от «Несекретно» до «Совершенно секретно». Среди них были Honeywell SCOMP от ВВС США , SACDIN АНБ от , Blacker и MLS LAN от Boeing , все под управлением TCSEC, выпуска 1980-х годов и на базе Intel 80386 . В настоящее время продукты MLS оцениваются по Общим критериям . В конце 2008 года первая операционная система (подробнее ниже) была сертифицирована на высокий оцененный уровень надежности: Evaluation Assurance Level (EAL) — EAL 6+/High Robustness под эгидой программы правительства США, требующей многоуровневой безопасности при высокой угрозе. среда. Хотя этот уровень обеспечения безопасности во многом похож на уровень старой Оранжевой книги A1 (например, формальные методы), функциональные требования сосредоточены на фундаментальной изоляции и политиках потока информации, а не на политиках более высокого уровня, таких как Bell-La Padula. Поскольку Общие критерии отделили пару гарантий (EAL) и функциональности (Профиль защиты) TCSEC, четкое единообразное сопоставление между требованиями безопасности и возможностями диапазона безопасности MLS, задокументированное в CSC-STD-004-85, в значительной степени было потеряно, когда Общие критерии заменили Серия Радуга .

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

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

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

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

General Dynamics предлагает PitBull , надежную операционную систему MLS. PitBull в настоящее время предлагается только как расширенная версия Red Hat Enterprise Linux , но более ранние версии существовали для Sun Microsystems Solaris, IBM AIX и SVR4 Unix. PitBull предоставляет механизм безопасности Bell LaPadula , механизм целостности Biba , замену привилегий суперпользователя и многие другие функции. PitBull имеет базу безопасности для продукта Trusted Network Environment (TNE) General Dynamics с 2009 года. TNE обеспечивает многоуровневый обмен информацией и доступ к ней для пользователей в сообществах Министерства обороны и разведки, работающих с различными уровнями классификации. Это также основа для многоуровневой среды совместного использования коалиции, расширенной системы сбора и использования информации на поле боя. (БИСЕС-X).

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

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

Проблемные места

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

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

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

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

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

Дебаты: «MLS не существует»

Некоторые непрофессионалы разрабатывают безопасные вычислительные системы и приходят к выводу, что MLS не существует. Объяснение может заключаться в сокращении числа COMPUSEC . экспертов и термин MLS был перегружен двумя разными значениями/использованиями. Эти два варианта использования: MLS как среда обработки и MLS как возможность. Убеждение в том, что MLS не существует, основано на убеждении, что не существует продуктов, сертифицированных для работы в среде или режиме MLS, и, следовательно, MLS как возможность не существует. Одно не подразумевает другого. Многие системы работают в среде, содержащей данные, которые имеют неравные уровни безопасности и, следовательно, относятся к MLS по теореме о промежуточном значении компьютерной безопасности (CS-IVT). Последствия этой путаницы лежат глубже. Операционные системы, базы данных и сети 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) — это архитектура, которая учитывает компонент разделения доменов MLS. Обратите внимание, что UCDMO (руководитель правительства США по междоменным и многоуровневым системам) создал термин « Междоменный доступ» в качестве категории в своей базовой версии систем, аккредитованных Министерством обороны и разведывательным сообществом , и эту категорию можно рассматривать как по существу аналог MILS.

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

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

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

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

системы MSL

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

Приложения

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

Существует несколько баз данных, классифицируемых как системы MLS. У Oracle есть продукт под названием Oracle Label Security (OLS), который реализует обязательный контроль доступа — обычно путем добавления столбца «метка» к каждой таблице в базе данных Oracle . OLS развертывается в армии США INSCOM в качестве основы разведывательной базы данных из всех источников, охватывающей сети JWICS и SIPRNet . Существует проект по созданию размеченной версии PostgreSQL , а также есть более старые реализации размеченных баз данных, такие как Trusted Rubix . Эти системы баз данных MLS предоставляют унифицированную серверную систему для контента, охватывающего несколько меток, но они не решают проблему, связанную с тем, что пользователи обрабатывают контент на нескольких уровнях безопасности в одной системе, обеспечивая при этом обязательный контроль доступа.

Существует также несколько приложений MLS для конечных пользователей. Другая возможность MLS, которая в настоящее время используется в базовой версии UCDMO, называется MLChat. Архивировано 17 марта 2013 г. на Wayback Machine . Это чат-сервер, работающий на операционной системе XTS-400 — он был создан Исследовательской лабораторией ВМС США . Учитывая, что контент от пользователей в разных доменах проходит через сервер MLChat, для защиты секретного контента используется сканирование грязных слов, и были некоторые споры о том, действительно ли это система MLS или это скорее форма при междоменной передаче. защиты данных . Обязательный контроль доступа поддерживается за счет комбинации XTS-400 и механизмов, специфичных для приложения.

Совместный междоменный обмен (JCDX) является еще одним примером возможности MLS, которая в настоящее время используется в UCDMO. базовый уровень. JCDX - единственная система управления, контроля, связи, компьютеров и разведки (C4I), аккредитованная Министерством обороны (DoD) и Разведывательным управлением Министерства обороны (DIA), которая обеспечивает поддержку разведки и оповещения практически в реальном времени на театре военных действий и на передовых позициях. развернуты тактические командиры. Архитектура JCDX полностью интегрирована с безопасной операционной системой с высоким уровнем защиты четвертого уровня (PL4), использующей маркировку данных для распространения данных практически в реальном времени о действиях сил и потенциальных террористических угрозах в мировом океане и вокруг него. Он установлен в точках США и стран-партнеров НАТО, где он способен предоставлять данные от уровня «Совершенно секретно» / «SCI» до уровня «Секретно-разглашение», и все это на единой платформе.

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

Тенденции

Возможно, самое большое изменение, происходящее сегодня на арене многоуровневой безопасности, — это слияние MLS с виртуализацией. Все большее число доверенных операционных систем отказываются от маркировки файлов и процессов и вместо этого переходят на UNIX-контейнеры или виртуальные машины . Примеры включают зоны в Solaris 10 TX и гипервизор дополненных ячеек в таких системах, как от Green Hill платформа Integrity и XenClient XT от Citrix. SELinux и может поддерживать приложения охватывающие , MLS Еще одним примером является платформа High Assurance Platform от NSA, реализованная в Trusted Virtualization Environment (TVE) компании General Dynamics. В своей основе она использует несколько доменов.

См. также

• Модель Белла – ЛаПадулы
• Модель Биба , Модель целостности Биба
• Модель Кларка – Уилсона
• Дискреционный контроль доступа (DAC)
• Уровень гарантии оценки (EAL)
• Модель Грэма-Деннинга
• Обязательный контроль доступа (MAC)
• Многокатегорийная безопасность (MCS)
• Многофакторная аутентификация
• невмешательства (безопасности) Модель
• Управление доступом на основе ролей (RBAC)
• Режимы безопасности работы
• Высокий режим системы
• Модель «бери-грант»

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

• Лэмпсон, Б. (1973). «Заметка о проблеме заключения» . Коммуникации АКМ . 16 (10): 613–615. CiteSeerX   10.1.1.129.1549 . дои : 10.1145/362375.362389 . S2CID   9355455 .
• НЦСК (1985). «Критерии оценки доверенной компьютерной системы». Национальный центр компьютерной безопасности. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь ) (также известная как TCSEC или «Оранжевая книга»).
• НЦСК (1986). «Доверенная сетевая интерпретация». Национальный центр компьютерной безопасности. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь ) (она же ТНИ или «Красная книга»). [1]
• Смит, Ричард (2005). «Глава 205: Многоуровневая безопасность» . В Хоссейне Бидголи (ред.). Справочник по информационной безопасности, том 3, Угрозы, уязвимости, предотвращение, обнаружение и управление . Нью-Йорк: Джон Уайли. Архивировано из оригинала 6 мая 2006 г. Проверено 21 мая 2006 г. ISBN   0-471-64832-9 .
• Патель Д., Коллинз Р., Ванфлит В.М., Каллони Б.А., Уайлдинг М.М., МакЛирн Л. и Люк Дж.А. (ноябрь 2002 г.). «Глубоко встроенная архитектура MILS высокой надежности (несколько независимых уровней безопасности)» (PDF) . Центр исследований экономического развития и реформы политики. Архивировано из оригинала (PDF) 28 апреля 2003 г. Проверено 6 ноября 2005 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь ) CS1 maint: несколько имен: список авторов ( ссылка )
• П. А. Лоскокко, С. Д. Смолли, П. А. Макельбауэр, Р. К. Тейлор, С. Дж. Тернер и Дж. Ф. Фаррелл. Неизбежность неудачи: ошибочное предположение о безопасности в современных вычислительных средах . В материалах 21-й национальной конференции по безопасности информационных систем, стр. 303–314, октябрь 1998 г. [2] .

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

• Первая система RTOS Integrity 178B, сертифицированная для поддержки MILS
• Страница продукта INTEGRITY 178B
• Надежная операционная система PitBull