6.8 テストアクティビティ
6.8.4 独立テストの評価（ATE_IND.2）
6.8.4.1 目的
835 このアクティビティの目的は、TSF のサブセットを独立にテストすることにより TOE が特定されているとおりにふるまうかどうかを決定すること、また開発者の テストのサンプルを実行することにより開発者のテスト結果の確信を得ることであ る。
6.8.4.2 入力
836 このサブアクティビティ用の評価証拠は、次のとおりである。
a) ST b) 機能仕様
c) 利用者ガイダンス d) 管理者ガイダンス
e) セキュアな設置、生成、及び立上げの手順 f) テスト証拠資料
g) テストカバレージ分析 h) テストに適したTOE
6.8.4.3 評価者アクション
837 このサブアクティビティは、次の3つのCCパート3評価者アクションエレメント からなる。
a) ATE_IND.2.1E b) ATE_IND.2.2E c) ATE_IND.2.3E 6.8.4.3.1 アクションATE_IND.2.1E
ATE_IND.2.1C
2:ATE_IND.2-1 評価者は、テスト構成が ST に特定されたとおりに評価における構成と一貫してい ることを決定するために、TOEを検査しなければならない。検査しなければならない。検査しなければならない。検査しなければならない。
838 テストに使用される TOE は、ACM_CAP.2 サブアクティビティによって確証され たのと同じ一意のリファレンスと開発者が提供するテスト証拠資料を持つべきであ る。
839 ST は、評価のための複数の構成を特定することができる。TOE は、ST に従って テストする必要がある多数の個別のハードウェアとソフトウェア実装で構成するこ とができる。評価者は、ST に記述されている各評価済みの構成に一貫するテスト 構成が存在することを検証する。
840 評価者は、テスト環境に適用できる ST に記述されている TOE 環境のセキュリ ティの側面についての前提条件を考慮すること。ST にはテスト環境に適用されな い前提条件がいくつか存在することがある。例えば、利用者の取扱許可についての 前提条件は適用しないことがあるが、ネットワークへの 1 つのポイントでの接続に ついての前提条件は適用するだろう。
841 いずれかのテスト資源（例えば、メータ、アナライザ）が使用される場合、これら の資源が正しく調整されるようにするのは、評価者の責任である。
2:ATE_IND.2-2評価者は、TOE が適切に設置され、定義された状態にあることを決定するために、
そのTOEを検査しなければならない。検査しなければならない。検査しなければならない。検査しなければならない。
842 評 価 者 は 、 各 種 の 方 法 で TOE の 状 態 を 決 定 す る こ と が で き る 。 例 え ば 、 ADO_IGS.1 サブアクティビティがこれまでに成功裏に完了していることは、評価 者がテストに使用されている TOE が適切に設置され、定義された状態にあること を今もなお確信している場合、このワークユニットの条件を満たすことになる。そ うでない場合には、評価者は、提供されたガイダンスだけを使用して、TOE を設 置、生成し、立上げする開発者の手順に従うべきである。
843 TOE が未定義の状態であるために、評価者が設置手順を実行しなければならない
場 合 、 こ の ワ ー ク ユ ニ ッ ト は 、 成 功 裏 に 完 了 し た と き 、 ワ ー ク ユ ニ ッ ト 2:ADO_IGS.1-2の条件を満たすことができる。
ATE_IND.2.2C
2:ATE_IND.2-3 評価者は、開発者によって提供された一連の資源が、TSF を機能的にテストするた めに開発者によって使用された一連の資源と同等であることを決定するために、そ の一連の資源を検査しなければならない。検査しなければならない。検査しなければならない。検査しなければならない。
844 この資源の組み合わせには、研究所へのアクセス及び特別のテスト装置などを含め ることができる。開発者が使用したのと同じではない資源は、それらがテスト結果 に与える影響の観点から同等である必要がある。
6.8.4.3.2 アクションATE_IND.2.2E
2:ATE_IND.2-4 評価者は、テストサブセットを考え出さなければならない。考え出さなければならない。考え出さなければならない。考え出さなければならない。
845 評価者は、TOE に適したテストサブセットとテスト方策を選択する。1 つの極端な テスト方策は、テストサブセットに厳密にではなくテストでき得る多くのセキュリ ティ機能を含めることである。別のテスト方策は、気が付いた問題との関連に基づ いたいくつかのセキュリティ機能を含んだテストサブセットを持ち、これらの機能 を厳密にテストすることである。
846 一般的に、評価者のテスト手法は、これら 2 つの極端な方法の間に収まるべきであ る。評価者は、1 つ以上のテストを使用して、ST に識別されているほとんどのセ
EAL2:ATE_IND.2
キュリティ機能要件を実行するべきであるが、テストは、徹底的な仕様テストを実 証する必要はない。
847 評価者は、テストする TSF のサブセットを選択するとき、次の要因を考慮するべ きである。
a) 開発者テスト証拠。開発者テスト証拠は、カバレージ分析及びテスト証拠資料 からなる。開発者テスト証拠は、テスト中に開発者がセキュリティ機能をテス トした方法についての洞察を提供する。評価者は、TOEを独立にテストするた めの新しいテストを開発するとき、この情報を適用する。特に評価者は、次の ことを考慮するべきである。
1) 特定のセキュリティ機能に対する開発者テストの増加。評価者は、セキュ リティ機能をさらに厳密にテストするためにパラメタを変えて、さらに多 くの同じタイプのテストを行うことができる。
2) 特定のセキュリティ機能に対する開発者テスト方策の補足。評価者は、別 のテスト方策を使用してテストすることにより、特定のセキュリティ機能 のテスト手法を変更することができる。
b) テストサブセットに加えるセキュリティ機能の数。TOEに含まれているセキュ リティ機能の数が少ない場合には、セキュリティ機能のすべてを厳密にテスト することが現実的にできる。多数のセキュリティ機能を持つ TOE では、これ は費用効果が悪く、サンプリングが必要になる。
c) 評価アクティビティのバランスの維持。テストアクティビティに費やした評価 者の労力は、他の評価アクティビティに費やした労力と釣り合いを保つべきで ある。ATE_COV.1 の要件により開発者が提供するテストカバレージのレベル が大きく変動する場合、提供されるカバレージのレベルは、評価者によって費 やされる適切な労力を決定する重要な要因である。
848 評価者は、サブセットを構成するセキュリティ機能を選択する。この選択は、数多 くの要因に依存し、これらの要因の考慮は、テストサブセットサイズの選択にも影 響を与える。
a) セキュリティ機能の開発者テストの厳密さ。機能仕様に識別されているセキュ リティ機能のいくつかは、それらに関する開発者テスト証拠をほとんど持たな いかまたはまったく持たないことができる。追加のテストが必要であると評価 者が決定したセキュリティ機能は、テストサブセットに含められるべきである。
b) 開発者テスト結果。開発者のテスト結果からセキュリティ機能またはそれの様 相が特定どおりに動作することに評価者が疑いを持つ場合には、評価者は、テ ストサブセットにそのようなセキュリティ機能を含めるべきである。
c) TOE の種別に一般的に関係する知られている公知の弱点（例えば、オペレー
ティングシステム、ファイアウォール）。TOE の種別に関係する知られている 公知の弱点は、テストサブセットの選択プロセスに影響する。評価者は、その 種別の TOE に対して知られている公知の弱点に対処するそれらのセキュリ ティ機能をサブセットに含めるべきである（ここでの知られている公知の弱点 は、そのような脆弱性を意味せず、この個々の種別の TOE で経験された不十
分性または問題領域を意味する）。そのような弱点が知られていない場合には、
セキュリティ機能の広い範囲を選択する比較一般的な手法がさらに適している。
d) セキュリティ機能の重要性。TOEに対するセキュリティ対策方針の観点から他 のセキュリティ機能よりも重要なセキュリティ機能は、テストサブセットに含 められるべきである。
e) ST でなされている SOF 主張。特定の SOF 主張に対するすべてのセキュリ ティ機能は、テストサブセットに含められるべきである。
f) セキュリティ機能の複雑性。複雑なセキュリティ機能は、開発者または評価者 に、費用効果の高い評価とはならないめんどうな要求を課す複雑なテストを必 要とするかもしれない。逆に複雑なセキュリティ機能は、誤りが見つかりがち な領域であり、サブセットの有力な候補である。評価者は、これらの考慮事項 の間でバランスを計る必要がある。
g) 暗黙のテスト。あるセキュリティ機能のテストは、しばしば暗黙に他のセキュ リティ機能をテストすることがある。それらをサブセットに含めると、（暗黙 にではあるが）テストされるセキュリティ機能の数を最大限に増やすことがで きる。ある種のインタフェースは、一般的に各種のセキュリティ機能を提供す るために使用され、効率的なテスト手法の標的となる。
h) TOEへのインタフェースタイプ（例えば、プログラムに基づく、コマンド行、
プロトコル）。評価者は、TOE がサポートするすべての異なるタイプのインタ フェースのテストを含めることを考慮するべきである。
i) 革新的または一般的でない機能。販売広告用の印刷物で強調しているような革 新的または一般的でないセキュリティ機能が TOE に含まれている場合、これ らは、テストの有力な候補となるべきである。
849 このガイダンスは、適切なテストサブセットの選択プロセスで考慮する要因を明記 するが、これらは決してすべてではない。
850 サンプリングのガイダンスについては、附属書B.2を参照のこと。
2:ATE_IND.2-5 評価者は、テストを再現可能にできるように十分詳細に記述されたテストサブセッ トに対するテスト証拠資料を作成しなければならない作成しなければならない作成しなければならない作成しなければならない。
851 評価者は、ST 及び機能仕様からセキュリティ機能の期待されるふるまいを理解し て、機能をテストする最も適切な方法を決定する必要がある。特に、評価者は、次 のことを考慮する。
a) 使用する手法、例えば、セキュリティ機能を外部インタフェースでテストする か、テストハーネス(test harness)を使用して内部インタフェースでテストする か、または別のテスト手法（例えば、例外状況、コード検査）を採用するべき か。
b) セキュリティ機能を刺激し、応答を観察するために使用されるセキュリティ機 能インタフェース。