• 検索結果がありません。

機能仕様の評価(ADV_FSP.1)

ドキュメント内 CEM パート2: 共通評価方法論 (ページ 182-188)

7.6 開発アクティビティ

7.6.2 機能仕様の評価(ADV_FSP.1)

7.6.2.1 目的

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

7.6.2.2 入力

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

a) ST b) 機能仕様

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

7.6.2.3 評価者アクション

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

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

ADV_FSP.1.1C

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

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

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

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

ADV_FSP.1.2C

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

査しなければならない。

査しなければならない。

査しなければならない。

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

EAL3:ADV_FSP.1

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

ADV_FSP.1.3C

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

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

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

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

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

図図

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

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

(a) (b) (c)

TOE

(a) (b) (c)

TOE

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

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

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

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

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

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

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

b) レビュー済みガイダンスに記述されているすべてのセキュリティに関係するふ るまいは、機能仕様の中で意味(semantics)の記述に反映されるべきである。こ れには、事象及び各事象の効果としてのふるまいの識別を含めるべきである。

例えば、オペレーティングシステムが、ファイルが要求時に開かれない各理由

(例えば、アクセス拒否、ファイルが存在しない、他の利用者がファイルを使

EAL3:ADV_FSP.1

用している、利用者は午後 5 時以降にファイルを開くことが許されていない)

に対して異なる誤りコードを提供するような、機能の豊富なファイルシステム インタフェースを提供する場合、機能仕様は、要求に対してファイルが開かれ たか、または誤りコードが戻されたかを説明するべきである。(機能仕様は、

誤りに対するこれらの異なる理由のすべてを列挙することができるが、そのよ うな詳細を提供する必要はない。)意味の記述には、セキュリティ要件がイン タフェースに適用される方法(例えば、インタフェースの使用が監査可能な事 象であるかどうか、そして可能な場合は記録可能な情報かどうか)を含めるべ きである。

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

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

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

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

ある。

1000 上記の検証は、機能仕様と ST の TOE 要約仕様及び開発者が提供する利用者及び

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

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

1001 評価者が、設計、ソースコード、または他の証拠を検査し、機能仕様から抜けて落

ちているパラメタまたは誤りメッセージが含まれることを発見するまでは、機能仕 様が不完全であることを発見しないようなものであるため、このレビューは繰り返 えされる。

ADV_FSP.1.4C

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

なければならない。

なければならない。

なければならない。

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

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

7.6.2.3.2 アクションADV_FSP.1.2E

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

1003 すべての ST セキュリティ機能要件が機能仕様によって扱われていることを保証す

るために、評価者は、TOE 要約仕様と機能仕様の間のマッピングを作成すること ができる。そのようなマッピングは、対応(ADV_RCR.*)要件を満たしているこ

ドキュメント内 CEM パート2: 共通評価方法論 (ページ 182-188)