多層セキュリティ

マルチレベル セキュリティまたは複数レベルのセキュリティ( MLS ) は、互換性のない分類(つまり、異なるセキュリティ レベル) の情報の処理、異なるセキュリティ クリアランスと知る必要があるユーザーによるアクセスの許可、およびユーザーが権限のない情報にアクセスできないようにするためのコンピュータ システムのアプリケーションです。

マルチレベル セキュリティの使用には 2 つのコンテキストがあります。1 つは、破壊行為から自身を保護するのに十分なシステムであり、情報ドメインを分離する堅牢なメカニズムを備えている、つまり信頼できるシステムを指すコンテキストです。もう 1 つは、破壊行為から自身を保護するのに十分なコンピュータの強度と、情報ドメインを分離する適切なメカニズムを備えている、つまり信頼しなければならないシステムを必要とするコンピュータのアプリケーションを指すコンテキストです。信頼する必要があるシステムが必ずしも信頼できるとは限らないため、この区別は重要です。

MLSオペレーティング環境では、多くの場合、MLSオペレーティング システム(OS)上に構築された信頼性の高い情報処理システムが必要ですが、必ずしもそうとは限りません。ほとんどの MLS 機能は、信頼できないコンピューターだけで構成されたシステムでもサポートできますが、ハードウェア セキュリティに準拠したチャネルでリンクされた複数の独立したコンピューターが必要です (信頼できるネットワーク解釈、NCSC-TG-005 のセクション B.6.2 を参照)。ハードウェアで強制される MLS の例としては、非対称分離があります。^[1] 1 台のコンピューターが MLS モードで使用されている場合、そのコンピューターは信頼できるオペレーティング システムを使用する必要があります。MLS 環境内のすべての情報は OS によって物理的にアクセスできるため、情報へのアクセスが厳密に制御されるように、強力な論理制御が存在する必要があります。通常、これにはBell–LaPadula モデルなどのセキュリティ ラベルを使用する強制アクセス制御が含まれます。

信頼できるオペレーティングシステムを導入する顧客は、通常、製品が正式なコンピュータセキュリティ評価を完了することを要求します。評価は、システムが処理できる最低と最高の分類レベルである、より広いセキュリティ範囲に対してより厳格になります。信頼できるコンピュータシステム評価基準(TCSEC) は、コンピュータシステムの MLS を評価するために開発された最初の評価基準です。その基準では、セキュリティ要件と MLS セキュリティ範囲の広さの間に明確で統一されたマッピング^[2]がありました。歴史的に、機密扱いから最高機密までのセキュリティ範囲で MLS 処理が可能であると認定された実装はほとんどありませんでした。その中には、Honeywellの SCOMP、USAF SACDIN、NSAのBlacker、Boeingの MLS LAN があり、すべて TCSEC の下、1980 年代のIntel 80386ベースでした。現在、MLS 製品はCommon Criteriaの下で評価されています。 2008 年後半、最初のオペレーティング システム (詳細は後述) は、脅威の高い環境でのマルチレベル セキュリティを要求する米国政府プログラムの支援を受けて、評価保証レベル(EAL) - EAL 6+ / 高堅牢性という高い評価保証レベルに認定されました。この保証レベルは、古い Orange Book A1 と多くの類似点 (形式手法など) がありますが、機能要件は、Bell-La Padula などの高レベルのポリシーではなく、基本的な分離と情報フロー ポリシーに重点を置いています。Common Criteria では TCSEC の保証 (EAL) と機能 (保護プロファイル) の組み合わせが切り離されたため、CSC-STD-004-85 に文書化されたセキュリティ要件と MLS セキュリティ範囲機能の明確で統一されたマッピングは、Common Criteria が Rainbow Seriesに取って代わったときにほとんど失われました。

MLSをサポートする機能を備えた無料で利用できるオペレーティングシステムには、Security-Enhanced Linux機能が有効になっているLinuxやFreeBSDなどがあります。^[3]これらの無料のMLS実装では、次の3つの理由からセキュリティ評価が問題になると考えられていました。

1. MLS 信頼に必要な精度でカーネル自己保護戦略を実装することは常に非常に困難であり、これらの例は MLS 保護プロファイル用に設計または認定されていないため、MLS をサポートするために必要な自己保護を提供できない可能性があります。
2. EAL レベルとは別に、Common Criteria には、MLS モードでの動作に必要な堅牢性を指定する適切な高保証保護プロファイルのインベントリが欠けています。
3. たとえ（１）と（２）が満たされたとしても、評価プロセスは非常にコストがかかり、評価対象ソフトウェアの構成管理に特別な制限が課せられます。

このような仮定にもかかわらず、Red Hat Enterprise Linux 5は2007年6月にLSPP、RBACPP、CAPPに対してEAL4+の認定を受けました。^[4] Security-Enhanced Linuxを使用してMLSを実装し、Security-Enhanced LinuxでTOEのセキュリティ特性を強化した最初のCommon Criteria認定となりました。

ベンダーの認証戦略は、素人を誤解させる可能性があります。よくある戦略は、素人がEALレベルを過度に重視していることを利用して、過剰認証を行うことです。たとえば、EAL 3保護プロファイル（CAPPなど） ^[5]をEAL 4やEAL 5などの高いレベルに認証します。もう1つの戦略は、MLS対応保護プロファイルに評価されていないカーネルにMLSサポート機能（ロールベースアクセス制御保護プロファイル（RBACPP）やラベル付きセキュリティ保護プロファイル（LSPP）など）を追加して認証することです。これらのタイプの機能はカーネル上で実行されるサービスであり、破損や破壊から保護するためにカーネルに依存しています。カーネルがMLS対応保護プロファイルに評価されていない場合、デモがどれだけ印象的であってもMLS機能は信頼できません。特に注目すべきは、CAPPはMLSに不可欠な自己保護機能を明確に除外しているため、MLS対応プロファイルで はないということです。

General Dynamics は、信頼できる MLS オペレーティングシステムである PitBull を提供しています。PitBull は現在、Red Hat Enterprise Linuxの拡張バージョンとしてのみ提供されていますが、以前のバージョンは Sun Microsystems Solaris、IBM AIX、および SVR4 Unix 用に存在していました。PitBull は、Bell LaPadulaセキュリティメカニズム、Biba整合性メカニズム、スーパーユーザーの権限の置き換えなど、多くの機能を提供します。PitBull は、2009 年以来、General Dynamics の Trusted Network Environment (TNE) 製品のセキュリティ基盤となっています。TNE は、さまざまな機密レベルで運用されている国防総省および諜報コミュニティのユーザーによるマルチレベルの情報共有とアクセスを可能にします。また、マルチレベル連合共有環境である Battlefield Information Collection and Exploitation Systems Extended ^[6] (BICES-X) の基盤でもあります。

Sun Microsystems（現在はOracle Corporation ）は、商用 OS SolarisおよびOpenSolarisの統合機能としてSolaris Trusted Extensions を提供しています。制御されたアクセス保護プロファイル (CAPP) とロールベースのアクセス制御(RBAC) 保護プロファイルに加えて、Trusted Extensions はラベル付きセキュリティ保護プロファイル (LSPP) の EAL4 認定も受けています。^[7]セキュリティ ターゲットには、デスクトップ機能とネットワーク機能の両方が含まれます。LSPP では、カーネルとX Window System (X11 サーバー) によって強制されるラベル付けポリシーをユーザーがオーバーライドできないようにする必要があります。評価には隠れチャネル分析は含まれていません。これらの認証は CAPP に依存しているため、この製品が MLS に対して信頼できることを示す Common Criteria 認証はありません。

BAE Systems は、ベンダーが「高い保証」と称する MLS をサポートする商用システムであるXTS-400を提供しています。先行製品 (XTS-300 を含む) は、MLS 対応の TCSEC B3 レベルで評価されました。XTS-400 は、CAPP および LSPP 保護プロファイルに対して、Common Criteria の EAL5+ で評価されています。CAPP と LSPP はどちらも EAL3 保護プロファイルであり、本質的に MLS 対応ではありませんが、この製品の Common Criteria 評価のセキュリティ ターゲット^[8]には、MLS 機能を提供するセキュリティ機能の強化セットが含まれています。

サニタイズはMLS システムの問題領域です。Bell -LaPadula モデルで定義されているような MLS 制限を実装するシステムでは、明らかにセキュリティ制限に違反しない場合にのみ共有が許可されます。より低いクリアランスのユーザーは、より高いクリアランスを持つユーザーと作業内容を簡単に共有できますが、その逆はできません。Top Secret ユーザーが Top Secret ファイルを編集し、すべての Top Secret 情報を削除してから、それを Secret 以下のクリアランスを持つユーザーに配信できる、効率的で信頼性の高いメカニズムはありません。実際には、MLS システムは、信頼できるユーザーが MLS メカニズムをバイパスしてファイルのセキュリティ分類を変更できるようにする特権機能によってこの問題を回避します。ただし、この手法は信頼性がありません。

隠れチャネルは、 MLS システムにとって別の問題を引き起こします。MLS システムが秘密を完全に保持するには、極秘プロセスが秘密または下位のプロセスにいかなる種類の信号も送信できないようにする必要があります。これには、使用可能なメモリやディスク領域の変更、プロセス タイミングの変更などの副作用が含まれます。プロセスがこのような副作用を利用してデータを送信する場合、隠れチャネルを利用しています。実際のコンピューティング システムですべての隠れチャネルを閉じることは非常に困難であり、実際には不可能である可能性があります。すべての隠れチャネルを識別するプロセスは、それ自体が困難なものです。市販されている MLS システムのほとんどは、すべての隠れチャネルを閉じることを試みませんが、これにより、高セキュリティ アプリケーションで隠れチャネルを使用することは非現実的になります。

バイパスは、システム ハイ オブジェクトを MLS で信頼されているかのように扱う手段として導入された場合、問題となります。一般的な例としては、機密でない宛先に送信するために秘密のシステム ハイ オブジェクトからデータを抽出し、そのデータの一部のプロパティを、それが「実際に」機密でないことを示す信頼できる証拠として引用することが挙げられます (「厳密な」形式など)。システム ハイ システムは信頼できる証拠を保持するとは信頼できず、その結果、安全な仲介を行う論理的な方法がないまま、明白なデータ パスが開かれます。バイパスは、悪用が困難な狭帯域幅の秘密チャネルとは異なり、システム内で簡単に悪用できる大きな明白なリークを引き起こす可能性があるため、リスクを伴う場合があります。バイパスは、多くの場合、信頼できるオペレーティング環境を使用して、セキュリティ ドメインを起点まで連続的に分離していないために発生します。起点がシステム境界の外側にある場合、起点までの信頼できる分離を検証できない可能性があります。その場合、フローが本当に不可欠な場合は、バイパスのリスクは避けられません。

回避不可能なバイパスの一般的な例としては、信頼できないソースから秘密の IP パケットを受け入れ、秘密のユーザーデータを暗号化し、ヘッダーは暗号化せず、その結果を信頼できないネットワークに送る必要がある対象システムがあります。ソースは対象システムの影響範囲外にあります。ソースは信頼できない (システム高など) ですが、MLS であるかのように信頼されています。これは、ソースが、機密扱いされていないヘッダーと機密のプレーンテキスト ユーザーデータ (MLS データ構造) を含むパケットを提供するためです。ソースは信頼できないため、破損している可能性があり、機密扱いされていないパケット ヘッダーに秘密が挿入されます。破損したパケット ヘッダーは意味不明である可能性がありますが、対象システムがそれを妥当な信頼性で判断することは不可能です。パケット ユーザーデータは暗号的に十分に保護されていますが、パケット ヘッダーに読み取り可能な秘密が含まれている可能性があります。破損したパケットが対象システムによって信頼できないネットワークに渡された場合、ルーティングできない可能性がありますが、ネットワーク内の何らかの協力的な破損プロセスがパケットを取得して確認し、対象システムが漏洩を検出できない可能性があります。これは、検出が難しい大規模な明白な漏洩となる可能性があります。分類されていないヘッダーを持つ分類済みパケットを、実際の MLS 構造ではなく、システム上位構造として表示することは、非常に一般的ですが深刻な脅威となります。

バイパスのほとんどは回避可能です。回避可能なバイパスは、多くの場合、システム設計者がセキュリティを適切に考慮せずにシステムを設計し、その後でアドオン機能としてセキュリティを適用しようとした場合に発生します。そのような状況では、バイパスがシステムを機能させる唯一の (簡単な) 方法であるように見えます。バイパスされたデータの内容を調べて、バイパスされたデータに秘密が含まれていないことを立証しようとする無駄な試みである疑似セキュア スキームが提案 (および承認!) されています。これは、データの形式など、データに関する何かを信頼しなければ不可能であり、ソースがソース データの特性を保持することを信頼できないという仮定に反しています。確実な「セキュア バイパス」は神話であり、バイパスを透過的に実装するいわゆる高保証ガード(HAG) も同様です。これらがもたらすリスクは長い間認識されてきました。既存のソリューションは、最終的には技術的なものではなく、手順的なものです。バイパスの悪用によってシステムから機密情報がどれだけ持ち出されるかを確実に知る方法はありません。

素人の中には、セキュア コンピューティング システムを設計しながら、MLS は存在しないという結論を導き出している人もいます。その理由としては、COMPUSEC の専門家が減っていること^[9]と、MLS という用語が2 つの異なる意味や用途で多用されていることが考えられます。これらの 2 つの用途とは、処理環境としての MLS と機能としての MLS です。MLS が存在しないという考えは、MLS環境またはモードで動作するように認定された製品が存在せず、したがって機能としての MLS が存在しないという考えに基づいています。一方が他方を意味するわけではありません。多くのシステムは、セキュリティ レベルが異なるデータを含む環境で動作しており、したがってコンピュータ セキュリティ中間値定理 (CS-IVT) では MLS です^[10] 。 この混乱の結果はさらに深刻です。NSA 認定の MLS オペレーティング システム、データベース、およびネットワークは 1970 年代から運用モードで存在しており、MLS 製品は現在も構築、販売、展開されています。

素人は、システムが MLS 環境 (MLS の環境中心の意味) で動作していることを認めることは、MLS ソリューション (MLS の機能中心の意味) がないという問題を抱えているという認識に追い込まれることであると結論付けることがよくあります。MLS は一見複雑ですが、単純なソリューションが明らかでないからといって、それが存在しないという結論を正当化することはできません。このため、COMPUSEC に関する無知が深刻化し、「MLS について語ってはいけない」、「MLS など存在しない」というささやきとして表れることがあります。これらの MLS 否定スキームは急速に変化するため、対処できません。代わりに、MLS 環境と MLS 対応の違いを明確にすることが重要です。

• セキュリティ環境またはセキュリティ モードとしての MLS : ユーザのセキュリティ クリアランスが異なるコミュニティでは、MLS をデータ共有機能として認識する場合があります。つまり、ユーザは、その情報の受信を許可するクリアランスを持つ受信者と情報を共有できます。MLS システムに含まれるデータよりも低いセキュリティ レベルにクリアされた宛先への接続がある (または接続できる可能性がある) 場合、システムは MLS モードで動作しています。これは CS-IVT で形式化されています。システムのセキュリティ モードの決定は、システムのセキュリティ環境、つまりシステムに含まれるデータの分類、システムまたはその出力や信号に直接または間接的にアクセスできるユーザのクリアランス、およびシステムの他のシステムへの接続性とポートによって完全に決まります。セキュリティ モードは機能とは無関係ですが、信頼に値しないモードでシステムを動作させるべきではありません。
• 機能としての MLS : MLS データ共有を可能にすることを目的とした製品またはシステムの開発者は、Bell-LaPadula モデルを実施するメカニズムのように、データ共有制限またはセキュリティ ポリシーを実施する機能の観点から MLS を大まかに認識する傾向があります。セキュリティ ポリシーを堅牢に実装できることが証明できる場合、システムは MLS 対応です。

MLS という用語の本来の使用法は、セキュリティ環境またはモードに適用されていました。この混乱を解決する 1 つの方法は、MLS の本来の定義を保持し、そのコンテキストが使用されるときに MLS 対応であることを具体的に示すことです。

複数の独立したセキュリティ レベル(MILS) は、MLS のドメイン分離コンポーネントに対応するアーキテクチャです。UCDMO (クロス ドメインおよびマルチレベル システムの米国政府主導) は、 DoDおよびインテリジェンス コミュニティ認定システムのベースラインのカテゴリとしてクロス ドメイン アクセスという用語を作成しました。このカテゴリは、基本的に MILS に類似していると考えられます。

Biba モデル(整合性用) やBell-LaPadula モデル(機密性用)などのセキュリティ モデルは、分離されていると想定される特定のセキュリティ ドメイン間の一方向のフローを許可します。MILS は、上記のモデルで対処されるドメイン間の制御された相互作用に対処することなく、MLS の基礎となる分離に対処します。上記の信頼できるセキュリティ準拠のチャネルは、MILS ドメインをリンクして、より多くの MLS 機能をサポートできます。

MILS アプローチは、古い用語である MSL (複数単一レベル) で特徴付けられる戦略を追求し、各レベルの情報を独自の単一レベル環境 (システム高) 内に分離します。

MILS が提供する厳格なプロセス通信と分離は、MLS よりも超高信頼性ソフトウェア アプリケーションにとって有用である可能性があります。MILS は、セキュリティ レベルの概念によって具体化される階層構造に対応していない点が顕著です。このため、ドメイン間に特定のインポート/エクスポート アプリケーションを追加する必要がありますが、各アプリケーションは適切に認定される必要があります。そのため、MILS は、Multiple Independent Domains of Security (複数の独立したセキュリティ ドメイン) と呼ぶ方が適切かもしれません (MILS での MLS エミュレーションには、MLS アプリケーション用の同様の認定済みアプリケーション セットが必要です)。Bell-La Padula の階層関係と一致するレベル間のすぐに使用できる相互作用に対応しないことで、MILS は (ほとんど欺瞞的に) 最初は簡単に実装できますが、実用的な MLS アプリケーションに期待される機能の豊富さと柔軟性を実現するには、重要な追加のインポート/エクスポート アプリケーションが必要です。

MILS と MLS を比較する場合は、より単純な一連の輸出アプリケーションの認定が、1 つのより複雑な MLS カーネルの認定よりも達成可能かどうかを検討する必要があります。この質問は、利害関係者が要求する輸入/輸出のやり取りの範囲に一部依存します。MILS が有利なのは、すべての輸出アプリケーションに最大限の保証が必要とは限らない可能性があるからです。

このような問題を解決する別の方法として、複数の単一レベルと呼ばれるものがあります。各セキュリティ レベルは、信頼できない別のドメインに分離されます。ドメイン間の通信手段がないため、相互作用は不可能です。この分離のメカニズムは通常、別のコンピューターに物理的に分離することです。これは、Microsoft Windowsなど、MLS をサポートできないアプリケーションやオペレーティング システムをサポートするためによく使用されます。

信頼できるオペレーティングシステムなどのインフラストラクチャは、MLS システムの重要なコンポーネントですが、CNSSI 4009 による MLS の定義で要求される基準を満たすには (この記事の冒頭で言い換えました)、システムは、ユーザーが 1 つのシステムから複数の分類レベルのコンテンツにアクセスして処理できるユーザー インターフェイスを提供する必要があります。UCDMO は、2009 年のNSA情報保証シンポジウムで MLS に特化したトラックを実施し、認定された (運用中の) MLS システムと新興の MLS システムをいくつか紹介しました。SELinuxでの MLS の使用に注意してください。^[11]

MLS システムとして分類されるデータベースはいくつかあります。Oracleには、Oracle Label Security (OLS) という製品があり、これは通常、 Oracle データベース内の各テーブルに「ラベル」列を追加することによって、強制アクセス制御を実装します。OLS は、 JWICSおよびSIPRNetネットワークにまたがる「全ソース」インテリジェンス データベースの基盤として、米国陸軍INSCOMに導入されています。PostgreSQL のラベル付きバージョンを作成するプロジェクトがあり、Trusted Rubix などの古いラベル付きデータベース実装もあります。これらの MLS データベース システムは、複数のラベルにまたがるコンテンツに対して統合されたバックエンド システムを提供しますが、強制アクセス制御を実施しながら、ユーザーが 1 つのシステムで複数のセキュリティ レベルでコンテンツを処理できるようにするという課題は解決しません。

MLS エンドユーザー アプリケーションもいくつかあります。現在 UCDMO ベースラインにある他の MLS 機能は MLChat (2013-03-17 にWayback Machineでアーカイブ済み) と呼ばれ、XTS-400オペレーティング システムで実行されるチャット サーバーです。これは米国海軍研究所によって作成されました。異なるドメインのユーザーからのコンテンツが MLChat サーバーを通過するため、機密コンテンツを保護するためダーティ ワード スキャンが採用されています。これが本当に MLS システムなのか、それともクロスドメイン転送データ ガードの一形態なのかについては議論があります。強制アクセス制御は、XTS-400とアプリケーション固有のメカニズムの組み合わせによって維持されます。 ^[12]

Joint Cross Domain eXchange (JCDX) は、現在 UCDMO ^{[ permanent dead link ‍ ]}ベースラインにある MLS 機能のもう 1 つの例です。JCDX は、国防総省 (DoD) の国防情報局 (DIA) 認定の唯一のマルチレベル セキュリティ (MLS) コマンド、コントロール、通信、コンピューターおよびインテリジェンス (C4I) システムであり、戦域および前方展開戦術指揮官にほぼリアルタイムの情報と警告サポートを提供します。JCDX アーキテクチャは、高い保証の保護レベル 4 (PL4) の安全なオペレーティング システムと包括的に統合されており、データ ラベリングを使用して、世界中の海上および海域での部隊活動や潜在的なテロの脅威に関するほぼリアルタイムのデータ情報を配信します。米国および同盟国の場所にインストールされており、最高機密/SCI から機密公開レベルまで、すべて単一のプラットフォームでデータを提供できます。

現在 UCDMO ベースラインに含まれていない MLS アプリケーションには、BlueSpaceのアプリケーションがいくつか含まれています。BlueSpace には、MLS 電子メール クライアント、MLS 検索アプリケーション、MLS C2 システムなど、いくつかの MLS アプリケーションがあります。BlueSpace は、ミドルウェア戦略を使用して、アプリケーションをプラットフォームに依存しないようにし、複数のWindows OS インスタンス (仮想化またはリモート ターミナル セッション) にわたって 1 つのユーザー インターフェイスを調整します。米国海軍研究所は、Ruby on RailsフレームワークとSQLite3に基づくマルチレベル データベースを統合する MLWeb と呼ばれるマルチレベル Web アプリケーション フレームワークも実装しています。

おそらく、現在マルチレベル セキュリティの分野で起こっている最も大きな変化は、MLS と仮想化の融合です。信頼されるオペレーティング システムの多くは、ファイルやプロセスのラベル付けをやめ、UNIX コンテナーや仮想マシンへと移行しています。例としては、Solaris 10 TXのゾーン、Green Hill のIntegrityプラットフォームなどのシステムのパディングされたセルハイパーバイザー、Citrix の XenClient XT などがあります。General Dynamicsの Trusted Virtualization Environment (TVE)に実装されているNSAの High Assurance Platformも別の例です。このプラットフォームはSELinux をコアに使用し、複数のドメインにまたがる MLS アプリケーションをサポートできます。

• ベル・ラパドゥーラモデル
• ビバモデル、ビバ整合性モデル
• クラーク・ウィルソンモデル
• 任意アクセス制御(DAC)
• 評価保証レベル(EAL)
• グラハム・デニングモデル
• 強制アクセス制御(MAC)
• マルチカテゴリーセキュリティ（MCS）
• 多要素認証
• 非干渉（セキュリティ）モデル
• ロールベースのアクセス制御(RBAC)
• セキュリティ動作モード
• システムハイモード
• テイクグラントモデル

• Lampson, B. (1973). 「閉じ込め問題に関するメモ」Communications of the ACM . 16 (10): 613–615. CiteSeerX  10.1.1.129.1549 . doi :10.1145/362375.362389. S2CID  9355455.
• NCSC (1985)。「信頼できるコンピュータ システムの評価基準」。国立コンピュータ セキュリティ センター。 {{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ) (別名TCSECまたは「オレンジブック」) が必要です。
• NCSC (1986)。「信頼できるネットワークの解釈」。国立コンピュータ セキュリティ センター。 {{cite journal}}:ジャーナルの引用には|journal=（ヘルプ）が必要です（別名TNIまたは「レッドブック」）。[1]
• Smith, Richard (2005)。「第 205 章: マルチレベル セキュリティ」。Hossein Bidgoli (編) 著。情報セキュリティ ハンドブック、第 3 巻、脅威、脆弱性、予防、検出、管理。ニューヨーク: John Wiley。2006 年 5 月 6 日にオリジナルからアーカイブ。2006年5 月 21 日に取得。 原題：Isbn  : 0-471-64832-9。
• Patel, D.、Collins, R.、Vanfleet, WM、Calloni, BA、Wilding, MM、MacLearn, L.、および Luke, JA (2002 年 11 月)。「深く埋め込まれた高保証 (複数の独立したセキュリティ/安全性レベル) MILS アーキテクチャ」(PDF) 。経済開発および政策改革研究センター。2003年 4 月 28 日のオリジナル(PDF)からアーカイブ。2005 年 11 月 6 日に取得。 {{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要ですCS1 maint: multiple names: authors list (link)
• PA Loscocco、SD Smalley、PA Muckelbauer、RC Taylor、SJ Turner、JF Farrell。「障害の必然性：現代のコンピューティング環境におけるセキュリティの誤った想定」。第21回全国情報システムセキュリティ会議の議事録、303～314ページ、1998年10月。[2]

• MILSをサポートする最初のRTOS Integrity 178B認定
• INTEGRITY 178B 製品ページ
• PitBull 信頼できるオペレーティング システム