機能仕様の評価（ADV_FSP.1）

6.6.2.1 目的

690 このサブアクティビティの目的は、開発者が TOE のセキュリティ機能の適切な記 述を提供しているかどうか及び TOE が提供するセキュリティ機能が ST のセキュ リティ機能要件を十分に満たしているかどうかを決定することである。

6.6.2.2 入力

691 このサブアクティビティ用の評価証拠は、次のとおりである。

a) ST b) 機能仕様

c) 利用者ガイダンス d) 管理者ガイダンス

6.6.2.3 評価者アクション

692 このサブアクティビティは、次の2つのCCパート3評価者アクションエレメント からなる。

a) ADV_FSP.1.1E b) ADV_FSP.1.2E 6.6.2.3.1 アクションADV_FSP.1.1E

ADV_FSP.1.1C

2:ADV_FSP.1-1 評価者は、機能仕様がすべての必要な非形式的説明文を含んでいることを決定する ために、その仕様を検査しなければならない。検査しなければならない。検査しなければならない。検査しなければならない。

693 機能仕様全体が非形式的である場合、このワークユニットは、適用されないために、

満たされているものとみなされる。

694 補助的な叙述的記述は、準非形式的または形式的記述だけでは理解するのが困難な 機能仕様の部分に必要となる（例えば、形式的表記の意味を明確にするため）。

ADV_FSP.1.2C

2:ADV_FSP.1-2 評価者は、機能仕様が内部的に一貫していることを決定するために、その仕様を検検検検 査しなければならない。

査しなければならない。

査しなければならない。

査しなければならない。

695 評価者は、TSFI を構成するインタフェースの記述が TSF の機能の記述と一貫して いることを保証することにより、機能仕様の正当性を確認する。

EAL2:ADV_FSP.1

696 一貫性の分析のガイダンスについては、附属書B.3を参照。

ADV_FSP.1.3C

2:ADV_FSP.1-3 評価者は、機能仕様が外部 TOE セキュリティ機能インタフェースのすべてを識別 していることを決定するために、その仕様を検査しなければならない。検査しなければならない。検査しなければならない。検査しなければならない。

697 用語「外部」（external）は、利用者に見えることを意味する。TOE への外部イン タフェースは、TSFへの直接インタフェースであるかまたはTOEのTSF以外の部 分へのインタフェースのいずれかである。ただし、これらの TSF 以外のインタ フェースは、最終的に TSF にアクセスすることがある。TSF に直接または間接的 にアクセスするこれらの外部インタフェースは、一体となって TOE セキュリティ 機能インタフェース（TSFI）を構成する。図6.1は、TSF（陰影の付いた）部分と TSF以外（空白）の部分を持つTOEを示している。このTOEには、3つの外部イ ンタフェースがある。ここで、インタフェースcは、TSF への直接インタフェース である。インタフェースbは、TSFへの間接インタフェースである。インタフェー ス a は、TOE の TSF 以外の部分へのインタフェースである。そこで、インタ フェースbとcがTSFIを構成する。

698 CC パート 2（またはそれの拡張コンポーネント）の機能要件に反映されているす

べてのセキュリティ機能は、ある種の外部から見える表示を持つことに注意される べきである。これらすべてが必ずしもセキュリティ機能をテストすることができる インタフェースとは限らないが、それらは、すべて、ある程度まで外部から見える ものであり、したがって機能仕様に含まれる必要がある。

699 TOEの境界を決定するガイダンスについては、附属書B.6を参照。

図図

図図6.1     TSFインタフェースインタフェースインタフェースインタフェース

2:ADV_FSP.1-4 評価者は、機能仕様が外部 TOE セキュリティ機能インタフェースのすべてを記述 していることを決定するために、その仕様を検査しなければな検査しなければならない。検査しなければな検査しなければならない。らない。らない。

(a) (ｂ) (ｃ)

TOE

(a) (ｂ) (ｃ)

TOE

700 悪意のある利用者からの脅威のないTOE（すなわち、FPT_PHP、FPT_RVM 及び FPT_SEPがSTから正当に除外されている）では、機能仕様（そして他のTSF表 現記述に展開される）に記述されている唯一のインタフェースは、TSF との間のイ ンタフェースである。FPT_PHP、FPT_RVM、及び FPT_SEP が存在しないこと で、セキュリティ機能がバイパスされる心配がないことが想定されるので、他のイ ンタフェースがTSFに与える影響についての心配がない。

701 他方、悪意のある利用者またはバイパスの脅威がある TOE（すなわち、FPT_PHP、

FPT_RVM、及び FPT_SEP が ST に含まれている）では、すべての外部インタ フェースが機能仕様に記述されているが、それは、それぞれの影響が明らかになる 程度に限られている。セキュリティ機能へのインタフェース（すなわち、図 6.1 の インタフェース b と c）は、完全に記述されているが、他のインタフェースは、そ のインタフェースを介して TSF へアクセスできない（すなわち、インタフェース は、図6.1 のタイプb ではなく、タイプa）ことを明確にする範囲でのみ記述され ている。FPT_PHP、FPT_RVM、及び FPT_SEP が含まれていることは、すべて のインタフェースが TSF に影響するおそれがあることを暗示している。各外部イ ンタフェースは、潜在的な TSF インタフェースなので、機能仕様には、インタ フェースがセキュリティに適切であるかどうかを評価者が決定できるように十分詳 細な各インタフェースの記述を含める必要がある。

702 いくつかのアーキテクチャは、外部インタフェースのグループに対して十分詳細にこ のインタフェース記述を、容易に提示している。例えば、カーネルアーキテクチャで は、オペレーティングシステムへのすべてのコールがカーネルプログラムで取り扱わ れる。TSP を侵害するかもしれないコールは、そのようにする権限を持つプログラ ムによってコールされなければならない。権限とともに実行されるすべてのプログラ ムは、機能仕様に含める必要がある。権限なしに実行されるカーネルの外部のあらゆ るプログラムは、TSP に影響を与えることはできず（すなわち、そのようなプログ ラムは、図6.1のタイプb ではなく、タイプa のインタフェースである）、そこで、

機能仕様から除外することができる。カーネルアーキテクチャが存在する場合、評価 者のインタフェース記述の理解は促進されるが、そのようなアーキテクチャは必ずし も必要ない。

2:ADV_FSP.1-5 評価者は、TSFI の提示が、効果、例外及び誤りメッセージを記述している各外部 インタフェースにおいて、TOE のふるまいを適切に及び正しく記述していること を決定するために、その提示を検査しなければならない。検査しなければならない。検査しなければならない。検査しなければならない。

703 インタフェースの提示が適切であり、正しいことを評価するために、評価者は、機 能仕様、STのTOE 要約仕様、及び利用者と管理者ガイダンスを使用して、次の要 因を評定する。

a) すべてのセキュリティに関係する利用者入力パラメタ（またはそれらのパラメ タの特性化）は識別されるべきである。完全であるために、直接利用者が制御 しないパラメタも、それらを管理者が使用できる場合、識別されるべきである。

b) レビュー済みガイダンスに記述されているすべてのセキュリティに関係するふ るまいは、機能仕様の中で意味(semantics)の記述に反映させられるべきである。

これには、事象及び各事象の影響としてのふるまいの識別を含めるべきである。

例えば、ファイルが要求時に開かれない各理由（例えば、アクセス拒否、ファ イルが存在しない、他の利用者がファイルを使用している、利用者は午後 5 時

EAL2:ADV_FSP.1

以降ファイルを開くことが許されていない）に異なる誤りコードを提供するよ うな、機能の豊富なファイルシステムインタフェースをオペレーティングシス テムが提供する場合、機能仕様は、要求に対してファイルが開かれたか、また は誤りコードが戻されたかを説明するべきである。（機能仕様は、誤りに対す るこれらの異なる理由のすべてを列挙することができるが、そのような詳細を 提供する必要はない。）意味の記述には、セキュリティ要件がインタフェース に適用される方法（例えば、インタフェースの使用が監査可能な事象であるか どうか、そして可能な場合は記録可能な情報かどうか）を含めるべきである。

c) すべてのインタフェースは、操作のすべての可能なモードに対して記述される。

TSF が権限の概念を提供する場合、インタフェースの記述は、権限がある場合 とない場合のインタフェースのふるまいを説明するべきである。

d) セキュリティに関係するパラメタの記述、及びインタフェースのシンタクス

(syntax)に含まれる情報は、すべての証拠資料にわたって一貫しているべきで

ある。

704 上記の検証は、機能仕様と ST の TOE 要約仕様及び開発者が提供する利用者及び 管理者ガイダンスをレビューすることによって行われる。例えば、TOE がオペ レーティングシステムとその下層のハードウェアである場合、評価者は、評価され る TOE に適切であるとして、利用者アクセス可能プログラムの説明、プログラム のアクティビティを制御するために使用されるプロトコルの記述、プログラムのア クティビティを制御するために使用される利用者アクセス可能データベースの記述、

及び利用者インタフェース（例えば、コマンド、アプリケーションプログラムイン タフェース）を探す。評価者は、プロセッサ命令セットが記述されていることも保 証する。

705 評価者が、設計、ソースコード、または他の証拠を検査し、機能仕様から抜けて落 ちているパラメタまたは誤りメッセージが含まれることを発見するまでは、機能仕 様が不完全であることを発見しないようなものであるため、このレビューは繰り返 えされる。

ADV_FSP.1.4C

2:ADV_FSP.1-6 評価者は、TSF が完全に表現されていることを決定するために、機能仕様を検査し検査し検査し検査し なければならない。

なければならない。

なければならない。

なければならない。

706 TSF 提示が完全であることを評定するために、評価者は、ST の TOE 要約仕様、

利用者ガイダンス、及び管理者ガイダンスを調べる。これらはいずれも、機能仕様 のTSF表現に含まれていないセキュリティ機能を記述するべきでない。

6.6.2.3.2 アクションADV_FSP.1.2E

2:ADV_FSP.1-7 評価者は、機能仕様が TOE セキュリティ機能要件の完全な具体化であることを決 定するために、その仕様を検査しなければならない。検査しなければならない。検査しなければならない。検査しなければならない。

707 すべての ST セキュリティ機能要件が機能仕様によって扱われていることを保証す るために、評価者は、TOE 要約仕様と機能仕様の間のマッピングを作成すること ができる。そのようなマッピングは、対応（ADV_RCR.*）要件を満たしているこ との証拠として開発者によってすでに提供されていることがある。その場合には、