信頼できるコンピュータシステムの評価基準

信頼できるコンピュータシステム評価基準（TCSEC）は、コンピュータシステムに組み込まれたコンピュータセキュリティ制御の有効性を評価するための基本要件を定めた米国 国防総省（DoD） の標準です。TCSECは、機密情報や機密扱いの情報の処理、保管、検索に考慮されるコンピュータシステムを評価、分類、選択するために使用されました。^[1]

TCSEC は、オレンジブックとも呼ばれ、国防総省レインボーシリーズ出版物の目玉です。TCSEC は、1983 年に国家安全保障局の一部門である国立コンピュータセキュリティセンター(NCSC) によって最初に発行され、1985 年に更新されましたが、最終的には2005 年に最初に発行されたCommon Criteria国際標準に置き換えられました。^{[引用が必要]}

1960 年代後半までに、政府機関は他のコンピュータ ユーザーと同様に、バッチ処理からマルチユーザーおよびタイムシェアリング システムへの移行をかなり進めていました。米国国防総省(DoD) 高等研究計画局 (ARPA)、現在のDARPA は、タイムシェアリング研究の主な資金提供者でした。^{[1] 1970 年までに、DoD は、軍の指揮命令の運用をサポートするために、}ワールドワイド軍事指揮統制システム(WWMCCS)と呼ばれるメインフレーム コンピューターの大規模な調達を計画していました。より高度な課題に対処したいという要望は早くからありました。たとえば、空軍の軍事航空輸送司令部(MAC) は、ほとんど機密扱いではない航空貨物および旅客サービスを軍に提供していましたが、軍事的緊急事態や特別作戦の場合など、同じ航空機と乗組員を使用する一部のミッションを機密扱いにする必要がまれにありました。 1970年までに、MACは、間もなく導入されるWWMCCSメインフレームで機密情報を処理する一方で、セキュリティクリアランスのないユーザー（クリアランスのないユーザー）がメインフレームにアクセスして機密情報にアクセスできるようにするという要件を明確にしました。^[2]

国家安全保障コミュニティは、2 つの方法でこの課題に対応しました。国防長官室は、コンピュータ システムのセキュリティ保護に関連するポリシーと技術の問題の調査を委託し、ARPA は機密情報を処理および保護できるプロトタイプの安全なオペレーティング システムの開発に資金を提供しました。

この研究活動は故ウィリス・ウェア氏の議長の下、国防科学委員会（DSB）のコンピュータセキュリティタスクフォースとして組織された。メンバーには政府や防衛関連企業の技術者、国防総省や諜報機関のセキュリティ担当者が含まれていた。タスクフォースは1967年から1969年にかけて会合を開き、機密報告書を作成し、1970年から適切なセキュリティ許可を持つ組織に提供した。^[3] DSBタスクフォースの報告書はウェア報告書と呼ばれるようになり、機密情報の処理に使用されるマルチユーザーコンピュータシステムの開発と運用に関するガイドラインを提供した。

1970 年代初頭、米国空軍の新しいコンピュータ システム機能の開発要件が、マサチューセッツ州ハンスコム空軍基地の空軍電子システム部門 (ESD) (後に電子システム センターとして知られる) に提出されました。ESD は、国の連邦政府出資研究開発センター(FFRDC)の 1 つであるMitre Corporationから技術的なアドバイスとサポートを受けました。初期の MITRE レポート^{[2]では、新しいマルチレベルの安全なオペレーティング システムを開発せずに MAC 要件を満たす代替アプローチが提案され、これらのアプローチによって}Ware レポートで解決不可能とされた問題が回避されるのではないかと期待されていました。

グレース・ハモンド・ニバルディは、ミター・コーポレーションに勤務していたときに、市販のオペレーティングシステムの評価に関する初期計画をまとめたレポートを発表しました。 ^[4]ニバルディの論文は、強制的なセキュリティの重要性を非常に強調しています。その後のオレンジブックと同様に、評価される製品のレベルを 7 つ定義し、最もセキュリティの低い最低レベル (0) を「未評価」としています。ニバルディのスキームでは、レベル 1 (実際に評価される最低レベル) を除くすべての製品に、広範な強制的なセキュリティ機能が含まれている必要があります。

オレンジブックの作業は1979年に始まりました。オレンジブックの作成は、ニバルディの1979年の報告書^[4]からオレンジブックの公式リリースである1983年まで続く一大プロジェクトでした。評価基準の最初の公開草案は、1982年5月にリリースされたブルーブックでした。^{[1]オレンジブックは1983年8月に発行されました。シーラ・ブランドが主な著者であり、他の数名がその開発に中心的な貢献者でした。その中には、}ミトレ社のグレース・ハモンド・ニバルディとピーター・タスカー、全米コンピュータセキュリティ会議のダン・エドワーズ、ロジャー・シェル、マービン・シェーファー、ユニバックのテッド・リーが含まれています。ジム・アンダーソン、スティーブ・ウォーカー、クラーク・ワイスマン、スティーブ・リップナーなど、政府、政府請負業者、ベンダーの多くの人々が、最終製品の内容に影響を与えたレビュー担当者として挙げられています。^[1]

1999年にオレンジブックは情報技術セキュリティ評価のための国際共通基準に置き換えられました。^[1]

2002年10月24日、オレンジブック（別名DoDD 5200.28-STD）はDoDD 8500.1によってキャンセルされ、その後2014年3月14日にDoDI 8500.02として再発行されました。^[5]

セキュリティポリシーは、コンピュータシステムによって明示的に定義され、強制されなければならない。3つの基本的なセキュリティポリシーが指定されている：^[6]

• 強制セキュリティ ポリシー–個人の許可、情報に対する承認、および要求されている情報の機密レベルに基づいて、アクセス制御ルールを直接適用します。その他の間接的な要因としては、物理的要因と環境的要因があります。このポリシーは、ルールの元となる法律、一般ポリシー、およびその他の関連ガイダンスも正確に反映する必要があります。
• マーキング– 必須のセキュリティ ポリシーを実施するように設計されたシステムは、アクセス制御ラベルの整合性を保存および保持し、オブジェクトがエクスポートされた場合にラベルを保持する必要があります。
• 裁量セキュリティ ポリシー- 情報を知る必要があると判断された特定の個人に基づいて、アクセスを制御および制限するための一貫した一連のルールを適用します。

政策に関係なく、個人の説明責任は強制されなければならない。権限のある有能な代理人がアクセスできるように安全な手段が存在し、その代理人が合理的な時間内に過度の困難なしに説明責任情報を評価できる必要がある。説明責任の目的には3つの要件が含まれる：^[6]

• 識別– 個々のユーザーを認識するために使用されるプロセス。
• 認証– 特定のカテゴリの情報に対する個々のユーザーの権限の検証。
• 監査–セキュリティに影響を与えるアクションを認証された個人まで追跡できるように、監査情報を選択的に保存および保護する必要があります。

コンピュータシステムには、システムが上記の要件を強制するという十分な保証を提供するために、独立して評価できるハードウェア/ソフトウェアメカニズムが含まれている必要があります。さらに、保証には、システムの信頼できる部分が意図したとおりにのみ機能するという保証も含まれている必要があります。これらの目的を達成するには、それぞれの要素を備えた2種類の保証が必要です。^[6]

• 保証メカニズム
• 運用保証:システム アーキテクチャ、システム整合性、秘密チャネル分析、信頼できる施設管理、信頼できる回復
• ライフサイクル保証:セキュリティテスト、設計仕様と検証、構成管理、信頼できるシステム配布
• 継続的な保護の保証– これらの基本要件を実施する信頼できるメカニズムは、改ざんや不正な変更から継続的に保護される必要があります。

各クラスには、システムの機能ではなく、開発、展開、管理に関する追加のドキュメント セットがあります。このドキュメントには次のものが含まれます。^{[引用が必要]}

• セキュリティ機能ユーザーズガイド、信頼できる施設マニュアル、テストドキュメント、設計ドキュメント

TCSEC は、D、C、B、A の 4 つの区分を定義しており、区分 A のセキュリティが最も高い。各区分は、個人または組織が評価対象システムに置くことができる信頼の大きな違いを表しています。さらに、区分 C、B、A は、クラス C1、C2、B1、B2、B3、A1 と呼ばれる一連の階層的な区分に分かれています。^[7]

各部門およびクラスは、直前の部門またはクラスの要件に従って拡張または修正されます。^[7]

• 評価は済んでいるが、上位の部門の要件を満たしていないシステムのために予約されています。^[8]

• C1 – 裁量的セキュリティ保護^[9]
  • 識別と認証
  • ユーザーとデータの分離
  • 個別にアクセス制限を適用できる任意アクセス制御（DAC）
  • 必要なシステムドキュメントとユーザーマニュアル
• C2 – 制御されたアクセス保護
  • よりきめ細かなDAC
  • ログイン手順による個人の説明責任
  • 監査証跡
  • オブジェクトの再利用
  • リソースの分離
  • このようなシステムの例としてはHP-UXがある。

• B1 – ラベル付きセキュリティ保護^[10]
  • セキュリティポリシーモデルの非公式な説明
  • データ機密ラベル
  • 選択されたサブジェクトとオブジェクトに対する強制アクセス制御 (MAC)
  • ラベルエクスポート機能
  • 発見された欠陥の一部は除去するか軽減する必要がある
  • 設計仕様と検証
• B2 – 構造化保護
  • セキュリティポリシーモデルが明確に定義され、正式に文書化されている
  • DACとMACの適用がすべての主体と対象に拡張されました
  • 隠れたストレージチャネルの発生と帯域幅を分析する
  • 保護に不可欠な要素と保護に不可欠でない要素に慎重に構造化
  • 設計と実装により、より包括的なテストとレビューが可能になります
  • 認証メカニズムが強化される
  • 管理者とオペレーターの分離により、信頼できる施設管理が実現します。
  • 厳格な構成管理制御が課せられる
  • オペレーターと管理者の役割は分離されています。
  • そのようなシステムの例としてはMulticsがある。
• B3 – セキュリティドメイン
  • リファレンスモニターの要件を満たす
  • セキュリティポリシーの施行に必須でないコードを除外するように構造化されている
  • 複雑さを最小限に抑えることを目指した重要なシステムエンジニアリング
  • セキュリティ管理者の役割が定義されました
  • セキュリティ関連イベントを監査する
  • 差し迫った侵入の自動検知、通知、対応
  • ユーザー認証機能のための TCB への信頼できるパス
  • 信頼できるシステム復旧手順
  • 隠れたタイミングチャネルの発生と帯域幅が分析されます
  • このようなシステムの例としては、XTS-400の前身であるXTS-300がある。

• A1 – 検証済み設計^[11]
  • 機能的にはB3と同一
  • 正式なトップレベル仕様を含む正式な設計と検証の手法
  • 正式な管理および配布手順
  • A1 クラス システムの例としては、Honeywell の SCOMP、Aesec の GEMSOS、Boeing の SNS Server などがあります。評価されなかった 2 つは、量産された LOCK プラットフォームとキャンセルされた DEC VAX セキュリティ カーネルです。
• A1を超える
  • システム アーキテクチャは、リファレンス モニターの自己保護と完全性の要件がTrusted Computing Base (TCB) に実装されていることを示しています。
  • セキュリティ テストでは、正式な最上位レベルの仕様または正式な下位レベルの仕様からテスト ケースが自動的に生成されます。
  • 形式仕様と検証では、実行可能な場合は形式検証方法を使用して、TCB がソース コード レベルまで検証されます。
  • 信頼できる設計環境とは、信頼できる（承認された）担当者のみが参加する信頼できる施設で TCB が設計される環境です。

「陸軍規則380-19」と題された出版物は、特定の状況でどのシステムクラスを使用すべきかを決定するためのガイドの例です。^[12]

• AR 380-19 は AR 25-2 に置き換えられました
• カナダの信頼できるコンピュータ製品評価基準
• 共通基準
• ITSEC
• レインボーシリーズ
• トラステッド プラットフォーム モジュール

• 国家安全保障研究所 - 5200.28-STD 信頼できるコンピュータ システムの評価基準
• FAS IRP DOD 信頼できるコンピュータ システム評価基準 DOD 5200.28
• 信頼できるコンピュータシステムの技術評価基準の提案