セキュリティ機能と保証レベル

CCの評価では、「適合する保証要件」や「評価保証レベル(EAL: Evaluation Assurance Level)」という言葉が使われています。セキュリティ評価では、セキュリティ対策に必要となる機能の要件のみならず、その機能が確実に動作するための要件についても明らかにしており、それらを保証要件と呼んでいます。ここでは、保証の要件と保証のレベルについて簡単に説明します。

セキュリティ評価の側面

セキュリティ評価でまず思い浮かべるのが、セキュリティ機能が仕様どおりに動作するかをテストして確認することだと思います。しかしCCでは、例えば以下のような様々な側面の評価が実施されます。

• セキュリティ基本仕様（セキュリティターゲット）において、TOEが対抗すると示された脅威に対し、その対策としてTOEが具備するセキュリティ要件が妥当であること。
• TOEの開発時に用いられた仕様書が、セキュリティ基本仕様で述べられたセキュリティ要件を過不足なく満たしていること。
• ガイダンスの曖昧な記述により、TOEの設置や運用でセキュアでない状況が作り出されないこと。
• エラーをはじめとする管理者・利用者へのメッセージが的確で、しかるべき対応が取られること。
• TOEの配付の過程で改ざんなどを考慮した手続がとられていること。

このように、セキュリティ機能が確実に動作することを確信するための「保証」は、単にセキュリティ機能をテストするだけではなく、いろいろな側面を確認することによって得られることになります。CCでは、このようなセキュリティの保証の指針となるあらゆる要件を集めて、「セキュリティ保証要件」として規格化しています。

セキュリティ保証要件

セキュリティ保証要件は、クラスと呼ばれる大きな分野があり、その分野ごとにファミリと呼ばれる分類がなされ、そのファミリをさらに具体化したコンポーネントから構成されています。CCでは、保証要件を下記のように大きく6つのクラスに分類しています。

保証クラス

それぞれの保証クラスは、さらに細かい保証ファミリで構成されます。たとえば、開発クラスでは、セキュリティ機能が仕様どおりに正確に実装されていること、そしてその実装が容易に阻害されることなく動作することに関連する要件を取扱い、以下の6つのファミリを含んでいます。

開発クラスの保証ファミリ

それぞれのファミリは、より完全性と正確性を増大させるような階層を持つコンポーネントで構成されています。この保証コンポーネントを、セキュリティ保証要件の単位として扱います。具体的には、開発クラスの機能仕様ファミリは、以下の6レベルの保証コンポーネントを含んでいます。

機能仕様ファミリのコンポーネント

この例では、保証コンポーネントは1から6へとより完全性と正確性を増大させる要件となっています。セキュリティ機能インタフェースが、セキュリティ基本仕様のセキュリティ要件を適切かつ正確に満たしていることを、1の基本機能仕様では、セキュリティ機能インタフェースの目的、使用方法の記述とパラメタの識別を入力とし検査していますが、2のセキュリティ実施機能仕様では、インタフェースの仕様とエラーメッセージの記述を要求し検査します。これは、エラーメッセージがたとえば資源へのアクセスなど、インタフェースには現れないセキュリティ機能の振る舞いの理解に役立つからです。さらに5の追加の誤り情報を伴う完全な準形式的機能仕様では、インタフェースの記述をBN記法などの曖昧さのない形で示すことにより機能仕様の不完全さなどを分析できるようになります。


このように、セキュリティ機能仕様の妥当性とセキュリティ機能実施の確実性に関する確信は、検査する証拠資料の範囲（完全性）と厳密さ（正確性）の拡大により高まります。この確信の根拠が保証であり、必要な根拠が保証要件となります。

ここでは、開発クラスの例をあげましたが、同様にすべての保証クラスは、保証ファミリを持ち、さらに保証ファミリは保証コンポーネントで構成されます。保証コンポーネントは、完全性と正確性を増すような階層的な構造をもっています。これらの保証要件の構造や各保証コンポーネントの詳細は
CCパート3に示されています。

保証パッケージと評価保証レベル

セキュリティ機能の妥当性と確実性についてのより高い確信は、より広い範囲のより厳密な証拠資料の検査によって得られます。しかし、すべての保証クラスの保証ファミリについて、より厳密な保証コンポーネント（前述の機能仕様の例では6の追加の形式仕様を伴う完全な準形式的機能仕様）の保証要件を満たしていることを評価するためには、それに応じた費用と期間が必要となります。
国家の安全保障に係るデータと個人のデータの保全について、必要とされる保証のレベルは異なるでしょう。また、同じデータの保全でも、非常に単純な構造と限定されたインタフェースを持つ製品について、その実装モジュールの凝集度の検証を試みることは、労力に比べて見合う利益が得られないことになります。改ざん検知が端点で可能な機能を具備した製品では、端点間のセキュアな配付手続についての厳密な保証を必要としないかもしれません。そこで、CCでは保証要件を保証コンポーネント単位で指定することができ、評価の対象となる製品や技術の分野、想定する使用方法、守るべき資産の価値などから、製品の調達者あるいはPP作成者が適切な保証コンポーネントのセットを指定します。 CCではまた、過去のセキュリティ評価の経験（米国のTCSECや欧州のITSECなど）から、標準的な保証コンポーネントをまとめた保証パッケージを用意しています。多くの場合、調達者やPP作成者は、自らが適切な保証コンポーネントを選択するという煩雑さを避け、この保証パッケージを指定しています。保証パッケージは、保証評価レベル（EAL: Evaluation Assurance Level）ごとに用意されており、評価保証のレベルが高くなるほど、より広範な保証ファミリからより厳密な保証コンポーネントが選択されます。現在EALは7段階（EAL1からEAL7まで）定義されています。
下表は、評価保証レベルごとに定義された保証コンポーネントのセットである保証パッケージを表しています。たとえば、EAL1を指定すると、開発クラスでは、保証コンポーネントADV_FSP.1が選択されます。ADV_FSPは開発クラスの機能仕様ファミリを表し、そのファミリのレベル1のコンポーネント（基本機能仕様）が要件として選ばれます。EAL2では、機能仕様ファミリはADV_FSP.2となりレベル2のコンポーネント（セキュリティ実施機能仕様）が選択されます。ソースコードや製造図面などが評価の対象となる実装表現ファミリ(ADV_IMP)は、EAL4までは要件として選択されません。このように、評価保証レベル(EAL)が高くなると、より広い保証ファミリの厳密な保証コンポーネントがそのEALの保証パッケージとして選択されることになります。

評価保証レベルと保証コンポーネント

では、どのような場合にどのような評価保証レベルが適切でしょうか。一般的な民需用途では、扱う情報の重要度や運用環境による攻撃機会に応じてEAL1からEAL4の保証レベル、EAL5以上は軍用などの特殊用途向けや攻撃対象機器を利用者（攻撃者）自身が保有できるICカード向けと言われています。認証を相互に承認する国際的アレンジメント(CCRA)でも、相互承認はEAL4まで（ただし、CCRAで承認されたPPに適合していない場合はEAL2まで）合意されています。

以下にEALごとのパッケージの特性について、CCパート3の記述を要約します。EALパッケージを構成する個々の保証コンポーネントの詳細は、CCパート3を参照願います。

EAL1（機能テスト）

セキュリティへの脅威が重大ではない場合に適用され、特定の機能の要件が対処されていることを確認する。仕様に対する評価者のテスト、ガイダンスの調査など開発者の支援を受けずに最小の費用で評価を実施できる。
EAL1は、評価されていないITに比べ、保証の増加を提供する。

EAL2（構造テスト）

古くから継承されたシステムの安全性を確保するなど完全な開発資料を提供できないような場合で、低レベルから中レベルの保証されたセキュリティを要する環境で適用できる。開発者からの設計情報と開発者テスト結果の提供レベルで評価を実施する。また、開発環境における構成管理や製品の配付の手続を評価する。
EAL2は、EAL1の保証に加え、開発者テスト、基本的攻撃能力を想定した脆弱性分析、さらに詳細なTOE仕様に基づく評価者のテストを要求する。

EAL3（方式テスト及びチェック）

中レベルの保証されたセキュリティを必要とし、既存の適切な開発方法を大幅に変更することなく、TOEとその開発の完全な調査を要する状況に適用される。
EAL3は、EAL2の保証に加え、テストの網羅性や開発時のTOE改ざんを防止するメカニズムや手続を要求する。

EAL4（方式設計、テスト及びレビュー）

既存の商用製品の開発に対し、セキュリティに係るエンジニアリングコストの追加を受け入れられ、中レベルから高レベルの保証されたセキュリティを必要とする場合に適用される。
EAL4は、EAL3の保証に加え、より多くの設計記述、ソースコードなどのセキュリティ機能のすべての実装表現、開発時のTOE改ざんを防止する向上されたメカニズムや手続を要求する。

EAL5（準形式的設計及びテスト）

EAL5レベルの保証をはじめから達成する意図を持って開発され、高レベルのセキュリティを必要とし、専門的なセキュリティエンジニアリング技法の適用する適切なコストを負担する場合に適用される。
EAL5は、EAL4の保証に加え、準形式的な設計記述、構造化され分析可能なアーキテクチャ、TOE改ざんを防止するさらに向上されたメカニズムや手続を要求する。

EAL6（準形式検証済み設計及びテスト）

保護する資産の価値が、高い保証のための追加的な開発コストを正当化するようなリスクの高い状況で使用する場合に適用される。
EAL6は、EAL5の保証に加え、さらに広範囲な分析、実装の構造化表現、さらなるアーキテクチャ構造、さらに広範囲な評価者の脆弱性評定、さらに向上された構成管理と開発環境の制御を要求する。

EAL7（形式的検証済み設計及びテスト）

リスクが非常に高いか、高い資産価値により、さらに高い開発コストが正当化される場合に適用される。
EAL7は、EAL6の保証に加え、数学的検証を伴う形式的表現と対応、広範囲のテストを使用する包括的分析を要求する。

製品の特性や調達者の関心によりEALパッケージに保証コンポーネントを追加したり、必要な保証コンポーネントのみを選択し独自の保証パッケージで評価することもできます。

調達者またはPP作成者は、評価における保証コンポーネントの内容を吟味し、有効と思われる保証コンポーネントが組み込まれていることを確認し、また不要あるいは労力に見合った利益が得られないと判断した保証コンポーネントを排除します。