>サイトトップへ >このカテゴリの一覧へ

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

(1)

目  次

ページ

序文 

1

1

  適用範囲

2

2

  引用規格

3

3

  用語及び定義 

3

3.1

  この規格類で共通の用語及び定義 

3

3.2

  ADV クラスに関連する用語及び定義

11

3.3

  AGD クラスに関連する用語及び定義 

16

3.4

  ALC クラスに関連する用語及び定義

16

3.5

  AVA クラスに関連する用語及び定義

20

3.6

  ACO クラスに関連する用語及び定義 

21

4

  略語

21

5

  概要

22

5.1

  一般

22

5.2

  TOE 

22

5.3

  この規格類の対象読者 

23

5.4

  この規格類の各部

24

5.5

  評価の枠組み 

25

6

  一般モデル 

25

6.1

  序説及び一般モデル

25

6.2

  資産及び対抗策

26

6.3

  評価

30

7

  セキュリティ要件の調整(tailoring

30

7.1

  操作(Operations) 

30

7.2

  コンポーネント間の依存性 

33

7.3

  拡張コンポーネント

33

8

  プロテクションプロファイル及びパッケージ

34

8.1

  序説

34

8.2

  パッケージ 

34

8.3

  プロテクションプロファイル

34

8.4

  PP 及びパッケージの使用 

37

8.5

  複数のプロテクションプロファイルの使用

37

9

  評価結果

37

9.1

  序説

37

9.2

  PP 評価の結果 

38

9.3

  ST 評価を含む TOE 評価の結果 

38


X 5070-1

:2011 (ISO/IEC 15408-1:2009)  目次

(2)

ページ

9.4

  適合主張 

38

9.5

  ST 評価を含む TOE 評価の結果の利用

39

附属書 A(参考)セキュリティターゲットの仕様

41

附属書 B(参考)プロテクションプロファイルの仕様

57

附属書 C(参考)操作の指針 

62

附属書 D(参考)PP 適合

65

附属書 JA(参考)ISO/IEC 15408-2  Part 2: Security functional components 第 部:セキュリティ機能コ

ンポーネント 

66

附属書 JB(参考)ISO/IEC 15408-3  Part 3: Security assurance components 第 部:セキュリティ保証コ

ンポーネント 

69

参考文献

71


X 5070-1

:2011 (ISO/IEC 15408-1:2009)

(3)

まえがき

この規格は,工業標準化法に基づき,日本工業標準調査会の審議を経て,経済産業大臣が改正した日本

工業規格である。

これによって,JIS X 5070-1:2000 は改正され,この規格に置き換えられ,JIS X 5070-2:2000 及び JIS X 

5070-3:2000

は廃止された。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意

を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許権,出願公開後の特許出願及び実

用新案権に関わる確認について,責任はもたない。


日本工業規格

JIS

 X

5070-1

:2011

(ISO/IEC 15408-1

:2009

)

セキュリティ技術−

情報技術セキュリティの評価基準−

第 1 部:総則及び一般モデル

Information technology-

Security techniques-Evaluation criteria for IT security-

Part 1: Introduction and general model

序文 

この規格は,2009 年に第 3 版として発行された ISO/IEC 15408-1 を基に,技術的内容を変更することな

く作成した日本工業規格である。ただし,

附属書 JA 及び附属書 JB は,対応国際規格にはない参考事項で

ある。

なお,この規格で点線の下線を施してある参考事項は,対応国際規格にはない事項である。

この規格を含む JIS X 5070 規格類

JIS X 5070-1:2011,

ISO/IEC 15408-2:2008

及び ISO/IEC 15408-3:2008)

は,評価機関の行った,異なるセキュリティ評価の結果を比較可能にする。この規格類は,セキュリティ

評価のときに IT 製品のセキュリティ機能及びその IT 製品に適応される保証手段に対する共通の要件群を

提供することによって,この比較を可能にする。IT 製品はハードウェア,ファームウェア,又はソフトウ

ェアのいずれで実装されてもよい。

注記 1  日本工業規格では部で構成する規格がある場合,この部編成の規格全体を総称して,“規格

群”という。この規格では,日本工業規格になっていない国際規格を含めて,規格群をいう

場合は,

“規格類”と呼ぶ。また,この規格では,日本工業規格になっていない国際規格を,

ISO/IEC 15408-2:2008

を第 2 部及び ISO/IEC 15408-3:2008 を第 3 部という。

注記 2  附属書 JA に,第 2 部の目次を示し,附属書 JB に,第 3 部の目次を示している。

評価過程は,IT 製品のセキュリティ機能と IT 製品に適用される保証手段とがこれらの要件を満たすと

いうレベルの信頼を確立する。評価結果は,その IT 製品が利用者のセキュリティ要求を満たすか否かを利

用者が判断する際の手助けになるであろう。

この規格類は,セキュリティ機能をもつ IT 製品の開発,評価,及び/又は購入のための指針として役立

つものである。

この規格類は,多種多様な IT 製品の様々なセキュリティ特性に対して,多様な評価方法を適用できるよ

うに,意図的に柔軟性をもたせてある。したがって,この柔軟性が誤用されないように,注意を払うのが

望ましい。例えば,この規格類を使用する場合,不適切な評価方法,不適切なセキュリティ特性,又は不

適切な IT 製品に対しては,無意味な評価結果を生じるかもしれない。

このため,IT 製品が評価を受けたという事実は,評価対象のセキュリティ特性と使用された評価方法と

の枠組みにおいてだけ意味をもつ。認証機関は,製品,特性及び方法を慎重に点検して,評価によって有


2

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

意な結果が提供されることを確認するのが望ましい。また,評価対象の製品の購入者は,評価対象の製品

が購入者の固有な状況及び要求にとって有用であり,適用可能であるかどうかを判断するために,この枠

組みを慎重に検討するのが望ましい。

この規格類は,漏えい(洩)

,改ざん,又はサービス停止から資産を守る方法に関するものである。この

3

種類のセキュリティ確保の失敗に関する保護の分類は,一般にそれぞれ,機密性,完全性及び可用性と

呼ばれている。

この規格類はこの 3 種類以外の IT セキュリティの観点にも適用してもよい。

この規格類は,

(悪意のある,又は悪意はない)人間の活動から生じるリスク及び人間以外の活動から生じるリスクに適

用可能である。IT セキュリティから離れて,この規格類は IT の他の領域に適用してもよいが,この領域

への適用性については何も主張していない。

幾つかの項目には,専門的な技法が必要であったり,IT セキュリティにとってあまり重要でなかったり

することから,この規格類の範囲外とみなされるものがある。これらの項目の一部を次に示す。

a)

この規格類は,IT セキュリティ機能に直接関係しない管理上のセキュリティ手段に関するセキュリテ

ィ評価基準を含まない。しかし,多くの場合,セキュリティのかなりの部分が組織管理,人事管理,

物理管理,手順管理などの管理手段によって実現可能なこと又は支援可能なことがある。

b)

電磁波放射制御など,IT セキュリティの技術的な物理的側面の評価は特に対象としていないが,この

規格類で扱われる概念の多くはその領域に適用することができる。

c)

この規格類は,基準を適用するときに使用すべき評価方法については扱わない。この方法は,ISO/IEC 

18045

による。

d)

この規格類は,

機関が基準を適用する上での管理上及び法律上の枠組みについては扱わない。

しかし,

こうした枠組みの状況の下で評価を行う場合にこの規格類を用いることができる。

e)

認定(accreditation)に評価結果を用いるための手続は,この規格類で扱わない。認定は,非 IT 部分

全てを含む,運用環境全体における IT 製品(又はその集合体)の運用を,機関が承諾するための管理

行為をいう。評価プロセスの結果は,認定プロセスへの入力となる。しかし,非 IT 関連の特性の評定,

及び IT セキュリティ部分と非 IT 関連との関係の評定のためには,他の手法の方がより適しているた

め,認定機関(accreditor)はこれらの側面に対して別の手法を利用するのがよい。

f)

暗号化アルゴリズム固有の品質評定のための基準は,この規格類の適用対象外とする。暗号の数学的

特性に対して別途評定が必要な場合,この規格類が適用される評価制度は,そのような評定について

規定しなければならない。

適用範囲 

この規格は,IT セキュリティ評価の一般的な概念及び原理を定め,IT 製品のセキュリティ特性を評価す

る基盤として用いることを意図した規格の様々な部分によって与えられる評価の一般モデルについて規定

する。

この規格は,この規格類の全ての規格の概観を示す。この規格はこの規格類の様々な規格を記述し,こ

の規格類の全ての規格で使用される用語及び略語を定義し,評価対象(TOE)の基本的な概念を定め,評

価の枠組みを定め,評価基準が対象とする利用者を規定する。この規格は IT 製品の評価に必要な基本的な

セキュリティの概念を紹介する。

この規格は,様々な操作を定義する。それらの操作によって,この規格類の第 2 部及び第 3 部に記述さ

れている機能コンポーネント及び保証コンポーネントを調整できる。

この規格は,プロテクションプロファイル(PP)の主要な概念,セキュリティ要件のパッケージ及び適


3

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

合の主題を規定しており,評価結果についても規定している。この規格はセキュリティターゲット(ST)

の書き方について規定し,モデルを通してコンポーネントの組立て方について規定している。評価方法に

関する一般的な情報及び評価方法の適用範囲は,別の規格である ISO/IEC 18045 で規定している。

注記  この規格の対応国際規格及びその対応の程度を表す記号を,次に示す。

ISO/IEC 15408-1:2009

,Information technology−Security techniques−Evaluation criteria for IT

security

−Part 1: Introduction and general model(IDT)

なお,対応の程度を表す記号“IDT”は,ISO/IEC Guide 21-1 に基づき,

“一致している”こ

とを示す。

引用規格 

次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成する。これらの

引用規格は,記載の年の版を適用し,その後の改正版(追補を含む。

)は適用しない。

ISO/IEC 15408-2:2008

,Information technology−Security techniques−Evaluation criteria for IT security−

Part 2: Security functional components

ISO/IEC 15408-3:2008

,Information technology−Security techniques−Evaluation criteria for IT security−

Part 3: Security assurance components

ISO/IEC 18045:2008

,Information technology−Security techniques−Methodology for IT security evaluation

用語及び定義 

この規格類で用いる主な用語及び定義は,次による。

注記  箇条 では,この規格類において特別な意味で用いられる用語だけを示す。この規格類に用い

られる用語の組合せのうち,箇条 に含まれていない用語は,誤解が生じないように出現する

文脈において説明する。

3.1 

この規格類で共通の用語及び定義 

3.1.1 

敵対的な動作(adverse actions)

脅威エージェントが資産に行う動作。

3.1.2 

資産(assets)

TOE

の所有者が一般に価値を認めるもの。

3.1.3 

割付け(assignment)

この規格におけるコンポーネント内又は要件内の識別されたパラメタを規定すること。

3.1.4 

保証(assurance)

TOE

が SFR を満たしていることへの信頼の基盤。

3.1.5 

攻撃能力(attack potential)

TOE

への攻撃に攻撃者が費やすことができる労力の尺度であって,攻撃者の技能,資源及び動機の観点

から表現されるもの。


4

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

3.1.6 

要件追加(augmentation) 

パッケージへの一つ以上の要件の追加。

3.1.7 

認証データ(authentication data)

利用者の認証に用いられる情報。

3.1.8 

正当な利用者(authorised user)

SFR

に従って,操作を実行することができる TOE 利用者。

3.1.9 

クラス(class)

共通の目的をもつファミリの集合。

3.1.10 

理路整然とした(coherent)

論理的順序で並べられ,識別できる意味をもつ(連体修飾)

注記  証拠資料の場合は,文書内容及び文書構造の両方が,対象読者にとって理解できるものである

ことを意味する。

3.1.11 

完全な(complete)

エンティティの全ての必要な部分が提供されている(連体修飾)

注記  証拠資料の場合は,抽象化のレベルにおいてこれ以上の説明が必要ない詳細レベルで,全ての

関連する情報が証拠資料において扱われていることを意味する。

3.1.12 

コンポーネント(component)

要件を構成する最小の選択可能なエレメントのセット。

3.1.13  

統合保証パッケージ(composed assurance package)

この規格類第 3 部(主に ACO クラス)から抽出された要件からなる,定義済み統合保証尺度での程度

を表す保証パッケージ。

3.1.14 

確認する(confirm)

詳細にレビューし,充足性を第三者として示す。

注記  必要とされる厳格性のレベルは,内容によって異なる。この用語は,評価者アクションだけに

適用される。

3.1.15 

接続性(connectivity)

TOE

と外部の IT エンティティとの対話を可能にする TOE の特性。

注記  接続性には,任意の環境又は構成において任意の距離を介して,有線手段又は無線手段によっ

て行われるデータ交換が含まれる。


5

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

3.1.16 

一貫した(consistent)

複数のエンティティ間に明らかな矛盾が存在しない(連体修飾)

3.1.17 

対抗する(counter)

特定の脅威の影響を緩和する。脅威の影響を完全になくす必要はない。

3.1.18 

例証適合(demonstrable conformance)  

PP

における一般的なセキュリティ課題の解決方法を ST が提供するという ST と PP との関係。

注記 PP 及び ST は,異なるエンティティについて全く異なる記述を含み,異なる概念などを使用す

ることができる。例証適合は,複数の同様の PP が既に存在する TOE の種別にも適している。

これによって,ST 作成者はこれらの PP に対する適合を同時に主張し,作業量を減らすことが

できる。

3.1.19 

例証する(demonstrate)

分析によって得られる結果を提供する。この結果は“証明(proof)

”ほど厳格ではない。

3.1.20 

依存性(dependency)

依存するコンポーネントに基づく要件が PP,ST 又はパッケージに含まれる場合,一般に,依存される

コンポーネントに基づく要件もその PP,ST 又はパッケージに含まれなければならない,というコンポー

ネント間の関係。

3.1.21 

記述する(describe)

エンティティの一定の詳細を提供する。

3.1.22 

決定する(determine)

独立に分析し,一定の結論に到達する。

注記  この用語は,通常,これまでの分析を考慮しない,真に独立した分析を意味する。レビューす

る必要のある分析が既に行われていることを意味する用語である“確認する(confirm)”又は

“検証する(verify)

”と対比される。

3.1.23 

開発環境(development environment)

TOE

が開発される環境。

3.1.24 

エレメント(element)

セキュリティ上必要な事項の,最小単位の記述。

3.1.25 

確実にする(ensure) 

アクション(開発者アクション及び評価者アクション)が結果をもたらすことを保証する。

注記  この用語が“助ける(help)”などとともに用いられる場合は,結果が,そのアクションだけで


6

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

は完全には確実でないことを示す。

3.1.26 

評価(evaluation) 

定義された基準に基づき,PP,ST 又は TOE を評定すること。

3.1.27  

評価保証レベル(evaluation assurance level) 

この規格類第 3 部から抽出された保証要件の集合で,定義済み保証尺度での程度を表し,保証パッケー

ジを構成するもの。

3.1.28  

評価機関(evaluation authority) 

特定のコミュニティにおいて,評価制度に基づきこの規格類を適用し,標準を定め,評価の品質を監視

する機関。

3.1.29  

評価制度(evaluation scheme)

評価機関が特定のコミュニティにおいて,この規格類を適用するときの管理及び規制の枠組み。

注記  我が国における評価制度の名称は,“IT セキュリティ評価及び認証制度”である。

3.1.30 

徹底的な(exhaustive)

曖昧さを排除した計画に従って分析又は他の活動を行う,方法論的に整備されたアプローチ

(連体修飾)

注記  この用語は,分析などの活動を実施するときに用い,“系統的な”よりもかなり強い意味で用い

る。明快な計画に従って分析又は他の活動を行うときに系統的なアプローチを選択したことだ

けでなく,活動に使われる計画そのものが全ての可能性を尽くすことを保証するのに十分であ

る。

3.1.31 

説明する(explain)

行った活動の理由を示す。

注記  問われた場合,“行った活動が必然的に最適であった”という議論を試みることをせずに,“な

ぜ?”という問いへの答えを意図している。この用語は,

“記述する(describe)

”及び“例証す

る(demonstrate)

”とは異なる。

3.1.32 

拡張(extension) 

この規格類第 2 部に含まれていない機能要件及び/又はこの規格類第 3 部に含まれていない保証要件を

ST

又は PP に追加すること。

3.1.33 

外部エンティティ(external entity)

TOE

境界の外から TOE と交信する可能性がある人エンティティ又は IT エンティティ。

3.1.34 

ファミリ(family)

類似する目標をもつが,着眼点又は厳密さが異なるコンポーネントの集合。


7

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

3.1.35 

形式的(な)(formal)

確立した数学上の概念に基づいて,意味が定義された制限付き構文言語で表現されている(連体修飾)

3.1.36 

ガイダンス文書(guidance documentation)

TOE

の配付,立上げ,操作,管理及び/又は使用法について記述した文書。

3.1.37 

識別情報(identity)

TOE

の文脈内のエンティティ(利用者,プロセス,ディスクなど)を一意に識別する表現。

注記  このような表現の例は文字列である。利用者が人間の場合,表現は利用者の氏名若しくは略称,

又は(一意に識別化の可能な)擬似名であってもよい。

3.1.38 

非形式的(な)(informal)

自然言語で表現されている(連体修飾)

3.1.39 

TSF

間転送(inter TSF transfers)

TOE

と他の信頼できる IT 製品のセキュリティ機能との間でデータを通信すること。

3.1.40 

内部通信チャネル(internal communication channel)

TOE

内部の別々の部分間のチャネル。

3.1.41 

TOE

内転送(internal TOE transfer)

TOE

内部の別々の部分間でデータを通信すること。

3.1.42 

内部的に一貫した(internally consistent)

エンティティのどの側面の間にも明らかな矛盾がない(連体修飾)

注記  証拠資料のどの 2 か所をつき合わせても矛盾していると解釈できる部分がないことを意味す

る。

3.1.43 

繰返し(iteration)

二つ以上の異なる要件を表現するのに同一コンポーネントを使用すること。

3.1.44 

正当化(justification)

決定を導く分析。

注記  正当な例証より厳密である。この語は注意深く徹底的に論理的に一つ一つ確認していくという

意味で格段の厳密性を要する。

3.1.45 

オブジェクト(object)

情報を保持したり受け取ったりする TOE 内の受動的なもので,サブジェクトが行う操作の対象となるエ

ンティティ。


8

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

3.1.46 

操作(JIS X 5070 のコンポーネントに対する)[operation (on a component of JIS X 5070)]

コンポーネントを修正したり繰り返したりすること。

注記  コンポーネントに許される操作は,割付け,繰返し,詳細化及び選択である。

3.1.47 

操作(オブジェクトに対する)[operation (on an object)]

オブジェクトに対してサブジェクトが行える,特定の種類のアクション。

3.1.48 

運用環境(operational environment)

TOE

を運用する環境。

3.1.49 

組織のセキュリティ方針(organizational security policy) 

組織のためのセキュリティ規則,手順又は指針の集まり。

注記  セキュリティ方針は,特定の運用環境だけに対応することもある。

3.1.50 

パッケージ(package) 

名前の付いた機能要件又は保証要件の集合。

注記  パッケージの例に“EAL 3”がある。

3.1.51 

PP

評価(PP evaluation)

定義済みの評価基準を用いて PP を評定すること。

3.1.52 

プロテクションプロファイル,セキュリティ要求仕様書(Protection Profile)

ある種別の TOE に対するセキュリティの要求を実装に依存しないように記述した文書。

3.1.53 

証明する(prove)

数学的な意味での形式的分析による対応関係を示す。

注記  この分析では,あらゆる面で完全な厳密性が要求される。通常,二つの TSF 表現の対応関係を

高いレベルの厳密性で示す必要がある場合に,

“証明する”を使用する。

3.1.54 

詳細化(refinement) 

コンポーネントに詳細な内容を追加すること。

3.1.55 

役割(role) 

利用者と TOE との間で許されている交信を規定する定義済みの規則の集まり。

3.1.56 

秘密(secret) 

特定の SFP を実施するために,正当な利用者及び/又は TSF にしか知らせてはならない情報。

3.1.57 

セキュアな状態,セキュリティの確保された状態(secure state)


9

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

TSF

データが一貫しており,TSF が SFR の正確な実施を継続している状態。

3.1.58 

セキュリティ属性(security attribute) 

サブジェクト,利用者(TOE 範囲外の IT 製品を含む。

,オブジェクト,情報,セッション及び/又は

資源の特性のうち,SFR を定義する場合に使用し,SFR を実施する場合にその値を使用するもの。

3.1.59 

セキュリティ機能方針(security function policy) 

TSF

によって実施され,SFR の集まりとして表現できる特定のセキュリティの振る舞いを記述する規則

の集まり。

3.1.60 

セキュリティ対策方針(security objective) 

識別された脅威へ対抗することを意図した記述,並びに/又は識別された組織のセキュリティ方針及び

/若しくは前提条件を満たすことを意図した記述。

3.1.61 

セキュリティ課題(security problem)

TOE

が対処するよう意図されたセキュリティの本質及び範囲を規定する,一定の形式に従った記述。

注記  この記述は次の組合せから構成される。

・TOE が対抗すべき脅威。

・TOE が実施すべき OSP。

・TOE とその運用環境とが満たすべき前提条件。

3.1.62 

セキュリティ要件(security requirement)

TOE

のセキュリティ対策方針の達成に寄与するように定められている,標準的な言い回しで記述された

要件。

3.1.63 

セキュリティターゲット,セキュリティ設計仕様書(Security Target, ST)

特定の識別された TOE に対するセキュリティの要求を,実装に依存するように記述した文書。

3.1.64 

選択(selection)

コンポーネント内のリストから一つ以上の項目を指定すること。

3.1.65 

準形式的(な)(semiformal)

意味が定義された制限付き構文言語で表現されている(連体修飾)

3.1.66 

規定する(specify)

あるエンティティの固有の詳細を,厳密かつ正確に提供する。

3.1.67 

正確適合(strict conformance)

PP

における全ての要件が ST にもまた存在する,ST と PP との階層的な関係。


10

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

注記  この関係は,“ST には,PP の全ての項目を含めなければならないか,それ以上の項目を加える

ことができる”

(包含関係)として大まかに定義することができる。正確適合は,指定された方

法に厳格に従う要件である。

3.1.68 

ST

評価(ST evaluation)

定義済みの評価基準に用いて ST を評定すること。

3.1.69 

サブジェクト(subject)

オブジェクトに対して操作を実行する TOE 内の能動的なエンティティ。

3.1.70 

評価対象  TOE(target of evaluation)

ガイダンス文書が添付されることもある,ひとまとまりのソフトウェア,ファームウェア及び/又はハ

ードウェア。

3.1.71 

脅威エージェント(threat agent)

資産に対して敵対的な動作を行うエンティティ。

3.1.72 

TOE

評価(TOE evaluation)

定義済みの評価基準を用いて TOE を評定すること。

3.1.73 

TOE

資源(TOE resource)

TOE

内で使用可能な又は消費可能なもの。

3.1.74 

TOE

セキュリティ機能(TOE security functionality)

SFR

を正確に実現するために必要な TOE のハードウェア機能,ソフトウェア機能及び/又はファームウ

ェア機能の組合せ。

3.1.75 

たどる,追跡する(trace) 

最小限の厳密性で,二つのエンティティ間の対応関係の非形式的分析を実施する。

注記  例えば,セキュリティ機能要件からその元となるセキュリティ対策方針まで遡って確認できる

こと。

3.1.76 

TOE

範囲外への転送(transfers outside of the TOE)

TSF

の制御下にないエンティティに対して,TSF が仲介して行われるデータ通信。

3.1.77 

変換(translation)

標準的な言い回しでセキュリティ要件を記述する処理。

注記  この意味で変換という用語を使用することはこの用語の文字どおりの意味ではなく,また,標

準的な言い回しで表現される全ての SFR をセキュリティ対策方針に逆変換できることを意味す

るものでもない。


11

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

3.1.78 

高信頼チャネル(trusted channel) 

TSF

と別の信頼できる IT 製品とが,必要な信頼をもって通信することができる手段。

3.1.79 

高信頼 IT 製品(trusted IT product) 

TOE

と運用上,整合されたセキュリティ機能要件をもち,そのセキュリティ機能要件を正しく実現する

とみなされる TOE 以外の IT 製品。

注記  高信頼 IT 製品の一例として,別個に評価されたものがある。

3.1.80 

高信頼パス(trusted path) 

利用者と TSF とが,必要な信頼をもって通信することができる手段。

3.1.81 

TSF

データ(TSF data)

SFR

の実施に影響する,TOE の動作に必要なデータ。

3.1.82 

TSF

インタフェース(TSF interface)

外部エンティティ(又は TSF 外にある TOE 内のサブジェクト)が,TSF へデータを提供し,TSF から

データを受信し,TSF からサービスを呼び出す手段。

3.1.83 

利用者データ(user data)

TSF

の動作に影響を与えない,利用者のためのデータ。

3.1.84 

検証する(verify) 

充足性について独自の判断ができる程度に厳密に,第三者として確かめる。

注記  “3.1.14 確認する(confirm)”も参照する。この“検証する(verify)”という用語は,“確認す

る(confirm)

”よりも厳格な意味合いをもつ。評価者に独自の調査・分析作業を要求する場合,

この用語は評価者アクションの中で使用される。

3.2 ADV

クラスに関連する用語及び定義 

注記 1  次の用語は,ソフトウェアの内部構造に対する要件で使用する。これらの用語の幾つかは,

“the IEEE Std 610.12-1990,Institute of Electrical and Electronics Engineers, Standard Glossary of

Software Engineering Terminology

”による。

注記 2  3.2 から 3.6 までに示す,ADV クラス,AGD クラス,ALC クラス,AVA クラス及び ACO ク

ラスは,この規格類第 3 部に定義されたクラスである。

3.2.1 

管理者(administrator)

TSF

が実装する全ての方針に関して,あるレベルの信頼を得ているエンティティ。

注記  全ての PP 又は ST が管理者に対して同一のレベルを仮定しているわけではない。一般的に管理

者は,TOE の ST 中の方針に従うものと仮定されている。これらの方針のうち幾つかは,TOE

の機能要件に関係し,その他のものは,運用環境に関係している。


12

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

3.2.2 

呼出し木,コールツリー(call tree) 

モジュールが相互に呼び出し合っている関係を表す図中で,システム内のモジュールを示す図の形態。

注記  IEEE Std 610.12-1990 による。

3.2.3 

凝集,凝集度,モジュール強度(cohesion) 

単一のソフトウェアモジュールによって実行されるタスクが,相互に関連付けられる方法及びその度合

い。

[IEEE Std 610.12-1990]

注記  凝集の種類には,偶発的凝集,通信的凝集,機能的凝集,論理的凝集,逐次的凝集及び時間的

凝集がある。これらの凝集の種類については,対応する用語の項に定義している。

3.2.4 

偶発的凝集(coincidental cohesion) 

モジュール関連が全くない,又はほとんどないアクティビティを実行するような特性をもつ凝集。

[IEEE Std 610.12-1990]

注記  “凝集”(3.2.3)も参照。

3.2.5 

通信的凝集(communicational cohesion) 

モジュール内の他の機能に対する出力を生成する機能,又はモジュール内の他の機能からの出力を使用

する機能をもつ凝集。

[IEEE Std 610.12-1990]

注記 1  “凝集”(3.2.3)も参照。

注記 2  通信的に凝集するモジュールの例には,強制アクセスの検査,任意アクセスの検査及びアク

セス権限の検査を含む,アクセスチェックモジュールがある。

3.2.6 

複雑性(complexity) 

ソフトウェアの理解(分析,試験及び保守)のしづらさ。

[IEEE Std 610.12-1990]

注記  複雑性の軽減は,モジュールの分解,階層化及び最小化を用いる際の最終目標である。結合度

及び凝集度の管理は,この目標に大きく寄与する。

ソフトウェア工学分野では,ソースコードの複雑性を測定するための尺度を開発するための

試みに,多大な労力が費やされてきた。これらの尺度の多くは,演算子及びオペランドの数,

制御フロー図の複雑性(循環的複雑性)

,ソースコードの行数,実行可能コードに対するコメン

トの比率,

その他類似する指標などの,

簡単に算定できるソースコードの特性を使用している。

より簡単に理解できるコードを生成する上で,コーディング標準は,有効な手段であることが

分かってきた。

この TSF 内部構造

(ADV_INT)

ファミリは,

全てのコンポーネントで複雑性分析を要求する。

開発者は,複雑性が十分に軽減されたことを主張するために,その裏付けを提供することが求

められる。この裏付けとしては,開発者が使用したプログラミング標準,及び全てのモジュー

ルが標準に適合していること(適合しない場合には,ソフトウェア工学の論証によって例外が


13

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

正当化されていること)の明示,ソースコードの特性の幾つかを測定するために使用したツー

ルの結果,開発者が適切とみなすその他の裏付けなどがある。

3.2.7 

結合(coupling) 

ソフトウェアモジュール間の相互依存の方法及びその度合い。

[IEEE Std 610.12-1990]

注記  結合の種類には,呼出し結合,共通結合及び内容結合がある。これらについては 3.2.8 から 3.2.13

までで定義する。

3.2.8 

呼出し結合(call coupling) 

設計資料に記載された関数呼出し手続に厳密に従って,通信する場合の二つのモジュール間の関係。

注記  呼出し結合の例には,データ結合,スタンプ結合及び制御結合がある。3.2.9 から 3.2.11 までで

定義する。

3.2.9 

データ形呼出し結合[call coupling (data)]

設計資料に記載された関数呼出し手続に厳密に従い,かつ,厳密に単一データ項目の呼出しパラメタを

使用して通信する場合の二つのモジュール間の関係。

注記  “呼出し結合”(3.2.8)も参照。

3.2.10 

スタンプ形呼出し結合[call coupling (stamp)] 

複数のフィールドからなる呼出しパラメタ,又は意味のある内部構造をもつ呼出しパラメタを使用して

通信する場合の,二つのモジュール間の関係。

注記  “呼出し結合”(3.2.8)も参照。

3.2.11 

制御形呼出し結合[call coupling (control)] 

その一方が他方の内部ロジックに影響するように意図された情報を渡す場合の,二つのモジュール間の

関係。

注記  “呼出し結合”(3.2.8)も参照。

3.2.12 

共通結合(common coupling) 

共通データ領域又は共通システム資源を共有する場合の,二つのモジュール間の関係。

注記  グローバル変数は,その変数を使用するモジュールが共通結合されていることを示す。グロー

バル変数による共通結合は,一般に許可されているが,その結合度は制限される。

例えば,グローバル領域に配置されているが,単一のモジュールだけが使用する変数は,グ

ローバル領域への配置が不適切であり,その領域から削除するのが望ましい。グローバル変数

の適切性を評定するときに検討する必要がある,その他の要因には,次のものがある。

1)

グローバル変数を変更するモジュールの数:  一般に,グローバル変数の内容の制御に関す

る責任は,一つのモジュールだけに割り当てるのが望ましいが,その責任を別のモジュー

ルと共有する状況が発生するかもしれない。このような場合には,十分な正当性を提示す

る必要がある。この責任を三つ以上のモジュールが共有することは容認できない(この評


14

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

定を行う場合において注意することは,変数の内容に関して実際に責任を負う一つのモジ

ュールを決定することである。例えば,変数を変更するために一つのルーチンが使用され

るとして,そのルーチンが単にその呼出し側から要求された変更を実行する場合,その責

任を負うのは呼出し側のモジュールであり,そのようなモジュールが複数存在する可能性

がある。

。さらに,複雑性の決定手続の一つとして,二つのモジュールがグローバル変数

の内容に関して責任を負う場合,その変更が,それらのモジュール間でどのように調整さ

れるかを明確に示すことが望ましい。

2)

グローバル変数を参照するモジュールの数:一般に,グローバル変数を参照するモジュー

ルの数に制限はないが,多数のモジュールが参照する場合には,有効性及び必要性を検査

するのが望ましい。

3.2.13 

内容結合(content coupling)

その一方が他方の内部を直接参照することができる場合の,二つのモジュール間の関係。

注記  例えば,他方のモジュールのコードを変更する場合,又は他方のモジュールの内部ラベルを参

照する場合を含む。内容結合の結果,一方のモジュールの内容の一部又は全部が,他方のモジ

ュールに実質的に包含される。内容結合は,公表されていないモジュールインタフェースを使

用しているとみなすことができる。これは,公表されているモジュールインタフェースだけを

使用する呼出し結合とは対照的である。

3.2.14 

ドメイン分離(domain separation)

TSF

が,各々の利用者とその TSF とに対して別々のセキュリティドメインを定義し,別の利用者のセキ

ュリティドメイン又は TSF の内容に影響を与えることができる利用者プロセスが存在しないことを保証す

るセキュリティアーキテクチャ特性。

3.2.15 

機能的凝集(functional cohesion)

単一の目的に関連するアクティビティを実行するようなモジュールの機能的特性。

[IEEE Std 610.12-1990]

注記  機能的に凝集するモジュールの例には,単一タイプの入力を単一タイプの出力に変換する,ス

タックマネージャ,キューマネージャなどがある。

“凝集”

3.2.3)も参照。

3.2.16 

交信(interaction)

エンティティ間の一般的な通信に基づくアクティビティ。

3.2.17 

インタフェース(interface)

コンポーネント又はモジュールと交信するための手段。

3.2.18 

階層化(layering)

ある層がサービスに関して階層内でそれより下の層だけに依存し,更に,そのサービスをそれより上の

層だけに提供するように,モジュールの独立したグループが,個々の責任をもつよう階層的に体系化され

たソフトウェアの設計技法。


15

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

注記  各層がその直下の層からだけサービスを受け,その直上の層にだけサービスを提供するように

制約を強化したものを,厳密な階層化と呼ぶ。

3.2.19 

論理的凝集,手続的凝集(logical cohesion, procedural cohesion)

類似するアクティビティを異なるデータ構造で実行するような特性をもつ凝集。

注記  モジュールの機能が,異なった入力に対して,異なっていても関連した操作を行う場合,論理

的凝集のモジュールである。

“凝集”

3.2.3)も参照。

3.2.20 

モジュール分解(modular decomposition)

設計,開発及び評価を容易にするためにシステムをコンポーネントに分割するプロセス。

[IEEE Std 610.12-1990]

3.2.21 

非バイパス性(TSF の)[non-bypassability (of the TSF)]

全ての SFR 関連アクションが TSF によって仲介される,セキュリティアーキテクチャ特性。

3.2.22 

セキュリティドメイン(security domain)

能動的なエンティティがアクセスすることができる資源の集まり。

3.2.23 

逐次的凝集(sequential cohesion)

各機能の出力がその次の機能の入力となる特性をもつモジュール。

[IEEE Std 610.12-1990]

注記  逐次的に凝集するモジュールの例には,監査レコードを書き出す機能及び特定タイプの監査違

反の累積数をカウントし続ける機能を含むモジュールがある。

3.2.24 

ソフトウェア工学(software engineering)

ソフトウェアの開発,運用及び保守に対する,系統的かつ規則的で定量化可能な手法の適用(すなわち,

ソフトウェアに工学技術を適用すること。

[IEEE Std 610.12-1990]

注記  一般的に工学技術を実践するのと同様に,工学技術の原則を適用するときに,ある程度の見識

をもたなければならない。数多くの要因が,モジュール分解,階層化,最小化,その他の手段

の選択に影響する。例えば,開発者は,当初は実装されないが将来使用するアプリケーション

を念頭に置いてシステムを設計することがある。この場合,開発者は,将来使用するアプリケ

ーションを処理するロジックを,それらのアプリケーションを完全に実装する前に組み込むこ

とを選択するかもしれない。さらに,まだ実装されていないモジュールに対するコールを幾つ

か組み込んで,コールスタブ(call stub)をそのまま残すかもしれない。適切に構造化されたプ

ログラムからのこのような逸脱に対して開発者の正当性は,優れたソフトウェア工学の規則を

適用するとともに見識をもって評定する必要がある。

3.2.25 

時間的凝集(temporal cohesion)

機能を同時に実行する必要がある特性をもつモジュール。


16

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

注記 1  [IEEE Std 610.12-1990]による。

注記 2  時間的に凝集するモジュールの例には,初期化,回復,シャットダウンなどのモジュールが

ある。

3.2.26 

TSF

自己保護(TSF self-protection) 

TSF

以外のコード又はエンティティによって,TSF が破損されることのないセキュリティアーキテクチ

ャ特性。

3.3 AGD

クラスに関連する用語及び定義 

3.3.1 

設置(installation) 

TOE

運用環境への組込み,運用状態にするために人間が行う手続。

注記  この作業は TOE を受領して受け入れた後に,通常は,1 回だけ実行される。TOE は,ST で許

されたように,構成されるように求められる。TOE をセキュアな設定にするために,開発者が

実行しなければならない同様のプロセスの場合,ライフサイクルサポート(ALC)全体を通じ

て,それらのプロセスを“生成”という。TOE に,定期的に繰り返す必要のない初期立上げが

必要である場合,このプロセスを設置と分類する。

3.3.2 

運用(operation) 

TOE

の配布,準備後の“通常使用”

,管理及び保守を含む TOE の使用フェーズ。

3.3.3 

準備(preparation)

配付された TOE の利用者による受入れと,起動,初期化,立上げ,運用可能な状態への TOE の遷移な

どを含む設置とで構成される,製品ライフサイクルの 1 フェーズにおけるアクティビティ。

3.4 ALC

クラスに関連する用語及び定義 

3.4.1 

受入れ基準(acceptance criteria)

受入れ手順(例えば,文書のレビュー,ソフトウェア,ファームウェア又はハードウェアの試験)を実

施する場合に用いる基準。

3.4.2 

受入れ手順(acceptance procedures)

作成又は修正した構成要素を,TOE の一部として受け入れるため,又はライフサイクルの次の段階へ移

行するために従う手順。

注記  この手順は,受入れ及び受入れの決定に用いる基準について責任をもつ役割又は個人を明確に

する。受入れ状況には次に示す複数の種類があり,その幾つかの状況は重複してもよい。

a)

構成要素を最初に構成管理(configuration management)システムへ受け入れる場合。

特に,

他の製造業者のソフトウェア,

ファームウェア及びハードウェアの構成要素を TOE

へ追加する場合(

“統合”

b) TOE

を構築する各工程(例えば,モジュール,サブシステム,完成した TOE の品質管理)

において,構成要素を次のライフサイクルのフェーズへ移行するために受け入れる場合。


17

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

c)

異なる開発サイト間で,構成要素(例えば,TOE 又は暫定製品の一部)を搬送後に受け入

れる場合。

d)

利用者への TOE の配付後に受け入れる場合。

3.4.3 

構成管理,CM(configuration management, CM)

技術的及び管理的な指示及び監視の適用であって,構成要素の機能的特性及び物理的特性を識別し文書

化すること,それらの特性の変更処理及び実装状態を記録し報告すること,並びに指定された要件へのコ

ンプライアンスについての検証を行うこと。

注記  [IEEE Std 610.12-1990]による。

3.4.4 

CM 

文書(CM documentation, documentation of the CM system) 

CM

出力,CM リスト(構成リスト)

,CM システム記録,CM 計画及び CM 使用法文書を含む,全ての

CM

文書。

3.4.5 

構成管理証拠(configuration management evidence)

CM

システムの正しい運用を確証するのに使われても差し支えのない全てのもの。

注記  例えば,CM 出力,開発者が提供する理論的根拠,サイト訪問中に評価者が行う観察,実験,

インタビュー。

3.4.6 

構成要素(configuration item)

TOE

開発中に,CM システムが管理するオブジェクト。

注記 CM 要素は,TOE の一部又は評価文書若しくは開発ツールのような TOE の開発関連のオブジェ

クトでもよい。CM 要素は,

(ファイルなどのように)直接,又は(ハードウェア部品などのよ

うに)バージョンを含む参照情報を CM システムに格納してもよい。

3.4.7 

構成リスト(configuration list)

特定の製品に関する全ての構成要素をリスト化した構成管理出力文書であって,完成した製品の特定の

バージョンと関連する,個々の構成管理要素の正確なバージョンを伴っているもの。

注記  構成管理リストによって,製品の評価バージョンに属している構成要素を,製品の他バージョ

ンに属している異なるバージョンの同一構成要素から,区別することができる。最終構成管理

リストは,特定の製品の特定のバージョンのための特定の文書である。構成管理リストは構成

管理ツール内の電子文書とすることができる。その場合には,システムからの印刷出力ではな

く,システム全体又はシステムの一部を指定した方法で見ることができる。しかし,実際の評

価では,構成リストは評価文書の一部として印刷して配付されるであろう。構成リストは,

ALC_CMC

の構成管理要件の下にある構成要素を特定する。

3.4.8 

構成管理出力(configuration management output)

構成管理システムが作成又は実施し,構成管理に関連する結果。


18

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

注記  構成管理関連の成果は,行為(構成管理の指示を実現するための手動による処置など)と同様

に,文書(記入された定型用紙,構成管理システムの記録,ログデータ,ハードコピー,電子

出力データなど)として生じる。このような管理構成出力の例には,構成リスト,構成管理計

画及び/又は製品のライフサイクル中の振る舞いがある。

3.4.9 

構成管理計画(configuration management plan)

TOE

に対して構成管理システムをどのように使用するかの記述。

注記  構成管理計画を発行する目的は,担当者が何をしなければならないのかを明確にすることであ

る。構成管理システム全体からは,

(構成管理システムを適用する過程で作られてもよいため)

構成管理計画は構成管理システムの出力文書の一つと見ることができる。プロジェクトチーム

の担当者が,プロジェクトで行わなければならない各作業を理解するために使うため,具体的

なプロジェクトからは,構成管理計画は使用法文書に見える。構成管理計画は,特定の製品に

対する構成管理システムの使用方法を規定する。同一の構成管理システムを,他の製品の異な

る範囲で使用してもよい。すなわち,構成管理計画は,TOE 開発の期間中使用する,組織の構

成管理システムが出力するものを規定し,記述する。

3.4.10 

構成管理システム(configuration management system)

開発者が,製品ライフサイクルの開発及び保守で使用する,手順及びツール(それらの説明文書を含む。

全体の総称。

注記  構成管理システムは,異なれば,厳密さ及び機能の程度も異なってくる。評価保証の高いレベ

ル(の EAL)では,構成管理システムの,欠陥修正,変更管理及び他の追跡機構を自動化する

かもしれない。

3.4.11 

構成管理システム記録(configuration management system records)

構成管理システムの運用中に生成される出力であって,重要な構成管理活動を文書化するもの。

注記  構成管理システム記録の例には,構成管理要素の変更管理記録,アクセス承認記録などがある。

3.4.12 

構成管理ツール(configuration management tools)

構成管理システムを実現又は支援するツール(TOE の部品のバージョン管理のためのツールなど)

。ツ

ールは,人手による運用でも自動化された運用でもよい。

3.4.13 

構成管理使用法文書(configuration management usage documentation)

ツール及び手順のハンドブック,規則,文書などを用いて,構成管理システムを規定し,適用するよう

に記述した,構成管理システムの一部。

3.4.14 

配付(delivery)

完成した TOE を,製造環境から利用者の手元まで送り届けること(電子的手段を含む。

注記  このライフサイクルフェーズには,開発サイトにおけるパッケージ化及び格納を含んでもよい

が,未完成の TOE 又は TOE の一部を,異なる開発者又は異なる開発サイトの間で搬送するこ

とは含まない。


19

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

3.4.15 

開発者(developer)

TOE

の開発に責任をもつ組織。

3.4.16 

開発(development)

TOE

の実装表現の生成に関連する製品ライフサイクルのフェーズ。

注記 ALC 要件全般では,開発及び関連用語(開発者,開発する)が,より一般的な意味で開発及び

製造を含むように意図されている。

3.4.17 

開発ツール(development tools)

TOE

の開発製造を支援するツール(該当する場合はテストソフトウェアも含む。

注記  ソフトウェア TOE の場合は,一般に,プログラム言語,コンパイラ,リンカ及び生成ツールが

開発ツールである。

3.4.18 

実装表現(implementation representation)

最も抽象度の低い TSF の表現。具体的には,それ以上の設計の詳細化をすることなく,それ自体で TSF

を作成するのに使用される表現。

注記  すぐにコンパイルされる状態にあるソースコード,又は実際のハードウェアの製造に用いられ

るハードウェア図面は,実装表現の一部の例である。

3.4.19 

ライフサイクル(life-cycle)

オブジェクト(例えば,製品,システムなど)が存在する期間における一連の段階。

3.4.20 

ライフサイクル定義(life-cycle definition)

ライフサイクルモデルの定義。

3.4.21 

ライフサイクルモデル(life-cycle model)

ある特定のオブジェクトのライフサイクルの管理で使用される各段階及びそれらの関係の記述であって,

各段階のつながり具合,各段階の上位レベル特性(概念的特性)などを記述するもの。

注記  図 参照。

3.4.22 

製造(production)

製造ライフサイクルのフェーズは,開発フェーズに続き,実装表現から TOE の実装への変換,つまり利

用者に配付できる状態への変換で構成される。

注記 1  このフェーズは,TOE の製作,統合,生成,内部転送,保管及びラベル付けで構成すること

ができる。

注記 2  図 参照。


20

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

図 1CM 及び製品ライフサイクルの用語 

3.5 AVA

クラスに関連する用語及び定義 

3.5.1 

隠れチャネル(covert channel)

利用者にマルチレベル分離方針及び TOE の観察不能性要件に秘密裏に違反させてしまう不正信号チャ

ネル。

3.5.2 

検出した潜在するぜい弱性(encountered potential vulnerabilities)

評価者が評価中に検出した,SFR の侵害に使用される可能性のある TOE に潜在するぜい弱性。

3.5.3 

悪用可能なぜい弱性(exploitable vulnerability)

TOE

の運用環境で SFR を侵害するために使用可能な TOE の弱点。

3.5.4 

監視攻撃(monitoring attacks)

ガイダンス文書に対応した方法で TOE を運用することによって,TOE の内部機密データの暴露を目的

とする受動的な解析技術を含む攻撃方法の包括的なカテゴリ。

3.5.5 

潜在するぜい弱性(potential vulnerability)

存在が懸念されるが確認されていない弱点。

注記  存在が懸念されるとは,SFR を侵害する攻撃経路が想定されることである。

3.5.6 

残存するぜい弱性(residual vulnerability)

TOE

の運用環境では悪用できないが,

TOE

の運用環境において想定を超える攻撃力をもつ攻撃者が,

SFR


21

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

を侵害するために使用可能な弱点。

3.5.7 

ぜい弱性(vulnerability)

ある環境の SFR を侵害するために使用可能な TOE の弱点。

3.6 ACO

クラスに関連する用語及び定義 

3.6.1 

基本コンポーネント(base component)

自身が評価の対象であり,従属コンポーネントにサービス及び資源を提供する,統合 TOE 内のエンティ

ティ。

3.6.2 

互換性のあるコンポーネント[compatible (components)]

同様の運用環境で,各コンポーネントの対応するインタフェースを通じて,他のコンポーネントが要求

するサービスを提供可能なコンポーネントの特性。

3.6.3 

コンポーネント TOE  (component TOE)

評価に合格した TOE であって,他の統合 TOE の部品となるもの。

3.6.4 

統合 TOE  (composed TOE)

評価に合格した二つ以上のコンポーネントだけで構成される TOE。

3.6.5 

従属コンポーネント(dependent component)

自身が評価の対象であり,基本コンポーネントからのサービスの提供を受ける,統合 TOE 内のエンティ

ティ。

3.6.6 

機能インタフェース(functional interface)

セキュリティ機能要件の実施に直接関連しない TOE 機能へのアクセスを利用者に提供する外部インタ

フェース。

注記  統合 TOE では,統合 TOE の運用を支援するために従属コンポーネントによって要求され,基

本コンポーネントによって提供されるインタフェースである。

略語 

次の略語は,この規格類の一つ以上の部で用いる。

API

アプリケーションプログラミングインタフェース(Application Programming Interface)

CAP

統合保証パッケージ(Composed Assurance Package)

CM

構成管理(Configuration Management)

DAC

任意アクセス制御(Discretionary Access Control)

EAL

評価保証レベル(Evaluation Assurance Level)

GHz

ギガヘルツ(Gigahertz)

GUI

グラフィカルユーザインタフェース(Graphical User Interface)

IC

集積回路(Integrated Circuit)


22

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

IOCTL

入出力制御(Input Output Control)

IP

インターネットプロトコル(Internet Protocol)

IT

情報技術(Information Technology)

MB

メガバイト(Mega Byte)

OS

オペレーティングシステム(Operating System)

OSP

組織のセキュリティ方針(Organizational Security Policy)

PC

パーソナルコンピュータ(Personal Computer)

PCI

周辺コンポーネント相互接続(Peripheral Component Interconnect)

PKI

公開鍵基盤(Public Key Infrastructure)

PP

プロテクションプロファイル,セキュリティ要求仕様書(Protection Profile)

RAM

ランダムアクセスメモリ(Random Access Memory)

RPC

リモートプロシージャコール(Remote Procedure Call)

SAR

セキュリティ保証要件(Security Assurance Requirement)

SFR

セキュリティ機能要件(Security Functional Requirement)

SFP

セキュリティ機能方針(Security Function Policy)

SPD

セキュリティ課題定義(Security Problem Definition)

ST

セキュリティターゲット,セキュリティ設計仕様書(Security Target)

TCP

伝送制御プロトコル(Transmission Control Protocol)

TOE

評価対象(Target of Evaluation)

TSF TOE

セキュリティ機能の実現主体(TOE Security Functionality)

TSFI TSF

インタフェース(TSF Interface)

VPN

仮想プライベートネットワーク(Virtual Private Network)

概要 

5.1 

一般 

箇条 では,この規格類の主な概念について示す。すなわち,

“TOE”の概念,この規格類の対象読者及

びこの規格類の他の部分での内容記述のためのアプローチを明らかにする。

5.2 TOE 

この規格類は,評価するものに関して柔軟に対応できるため,広く理解されている IT 製品の境界に拘束

されていない。したがって,評価の文脈において,この規格類では“TOE”

(Target of Evaluation,評価対

象)という用語を使用する。

TOE

は,ガイダンス文書を伴うことがある,ソフトウェア,ファームウェア及び/又はハードウェアの

集合として定義される。

TOE

は一つの IT 製品の場合もあるが,そうである必要はない。TOE は,一つの IT 製品,IT 製品の一部,

IT

製品の集合,製品にならない固有な技術又はこれらの組合せのいずれでもよい。

この規格類に関する限り,TOE と IT 製品との間の正確な関係は,一つの側面に限って重要となる。つ

まり,IT 製品の一部だけからなる TOE の評価を,IT 製品全体の評価と誤解させてはならない。

TOE

の例を次に示す。

・  ソフトウェアアプリケーション。

・  オペレーティングシステム。


23

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

・  オペレーティングシステムと組み合わせたソフトウェアアプリケーション。

・  オペレーティングシステム及びワークステーションと組み合わせたソフトウェアアプリケーション。

・  ワークステーションと組み合わせたオペレーティングシステム。

・  スマートカード向け集積回路。

・  スマートカード向け集積回路の暗号化コプロセッサ。

・  端末,サーバ,ネットワーク機器及びソフトウェアの全てを含むローカルエリアネットワーク。

・  データベースアプリケーション。ただし,これと関連付けられるリモートクライアントソフトウェア

は除く。

5.2.1 TOE

の様々な形態 

この規格類では,TOE は複数の形態を取ることがある。(ソフトウェア TOE の場合の)例を次に示す。

・  構成管理システムの一連のファイル。

・  コンパイルされたばかりの単一のコピー原本。

・  顧客に発送する準備の整った箱詰めされた CD-ROM 及びマニュアル。

・  インストール済みの運用可能なソフトウェア。

これらの全てが TOE とみなされる。この規格類の他の部分で“TOE”という用語が使用される場合,文

脈によって意図する形態が決定される。

5.2.2 TOE

の様々な構成 

一般に,IT 製品はいろいろな方法で構成される。すなわち,様々な方法でインストールされ,様々なオ

プションを有効又は無効にすることができる。この規格類の評価中に TOE が特定の要件を満たしているか

どうかを決定する場合,構成の柔軟性が,TOE の全ての可能な構成が要件を満たさなければならないとい

う問題をもたらすことがある。このため,TOE のガイダンス部分では,TOE で可能な構成を強く制限する

ことがある。つまり,TOE のガイダンスは,IT 製品の一般ガイダンスとは異なることがある。

この一例としては,オペレーティングシステムの IT 製品がある。この製品は,多くの使い方(利用者の

種別,利用者の数,許可又は禁止される外部接続の種別,任意機能の有効化又は無効化など)に応じて構

成できる。この IT 製品を TOE とし,妥当な機能要件の集合で評価する場合は,多くの任意機能(全ての

種別の外部接続の許可又はシステム管理者の認証の不要など)によって,TOE が要件を満たさなくなるこ

とがあるため,構成をなおさら厳格に制限した方がよい。このため,一般に(多くの構成を許容する)IT

製品のガイダンスと(唯一の構成又はセキュリティ関連の方法に関して異ならない構成だけを許容する)

TOE

のガイダンスとの間には相違がある。TOE のガイダンスが複数の構成を許容する場合には,これらの

構成を一括したものを“TOE”と呼び,各構成は TOE に課される要件を満たさなければならないことに注

意する。

5.3 

この規格類の対象読者 

TOE

のセキュリティ特性の評価に一般的に関心をもつのは,利用者,開発者及び評価者の三つのグルー

プである。

この規格で示す基準は,

これら三つのグループ全ての要求に対応できるように構成されている。

この三つのグループは,全て,この規格類の主な読者とみなされている。この三つのグループは,この後

に示すようにこの基準からの恩恵を受けることができる。

5.3.1 

利用者 

この規格類は,評価が利用者の要求を満たすことを保証するように記述しているが,それは,これが評

価プロセスの基本的な目的及び意義だからである。

利用者は,TOE が利用者のセキュリティに関する要求を満たしているかどうかを決定する一助として,


24

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

評価結果を用いることができる。通常,これらのセキュリティに関する要求は,リスク分析及び方針の双

方の結果として,決定されている。利用者はまた,異なる TOE を比較する場合に評価結果を用いることも

できる。

この規格類は,利用者,特に関心をもつ利用者のグループ及びコミュニティに対して,セキュリティ要

件を明確に表現するための,プロテクションプロファイル(PP)と呼ばれる実装に依存しない要件定義の

ひな(雛)形を提供する。

5.3.2 

開発者 

この規格類は,TOE の評価の準備及び支援並びに各 TOE が満たすべきセキュリティ要件の特定におい

て,開発者を支援することを目的としている。これらの要件は,セキュリティターゲット(ST)と呼ばれ

る実装に依存する要件定義書に含まれている。この ST は,一つ以上の PP に基づき,当該 PP の規定に従

って ST が利用者からのセキュリティ要件に適合していることを示してもよい。

この規格類は,これらの要件に対して TOE の評価を裏付けるのに必要な証拠を提供する責任及び行動を

決定するために用いることができる。また,その証拠の内容及び提示も規定している。

5.3.3 

評価者 

この規格類は,セキュリティ要件に対する TOE の適合について判断を下すときに,評価者が用いる基準

を含んでいる。この規格類は,評価者が実施しなければならない一般的な行動の集合を記述している。こ

の規格類は,それらの行動の実行に当たって従うべき手続を具体的に述べていないことに注意する。これ

らの手順の詳細については,5.5 に示されている。

5.3.4 

その他の対象読者 

この規格類は,TOE の IT セキュリティ特性の仕様及び評価を指向していると同時に,IT セキュリティ

に興味又は責任のある全ての関係者のための参考資料としても役に立つものである。この規格類に含まれ

ている情報から恩恵を受けることができる,その他の関心のあるグループの幾つかを次に示す。

a)

組織の IT セキュリティ方針及び要件を決定し実現する責任のある,システム管理者及びシステムセキ

ュリティ担当役員。

b)

(TOE から構成された又は TOE を含む)IT ソリューションのセキュリティの妥当性評定に責任のあ

る,内部及び外部の監査員。

c) IT

製品のセキュリティ特性の仕様に責任のあるセキュリティの設計者。

d)

特定の環境内における IT ソリューション使用の受入れに責任のある調達者。

e)

評価の依頼及び支援に責任のある評価のスポンサー。

f) IT

セキュリティ評価プログラムの管理及び監督に責任のある認証機関。

5.4 

この規格類の各部 

この規格類は,次に示すように,関連する三つの部として提供している。各部の記述に用いられている

用語については,箇条 で説明する。

a)

この規格は,この規格類の序説である。IT セキュリティ評価の一般的な概念及び原則を定義し,評価

の一般モデルを提示する。

b)

第 2 部の“セキュリティ機能コンポーネント”は,TOE の機能要件の基となる標準ひな(雛)形とし

て,機能コンポーネントの集合を規定している。この規格類第 2 部は,機能コンポーネントの集合を

カタログ化し,ファミリ及びクラスを編成している。

c)

第 3 部の“セキュリティ保証コンポーネント”は,TOE の保証要件の基となる標準ひな(雛)形とし

て,保証コンポーネントの集合を規定している。この規格類第 3 部は,保証コンポーネントの集合を


25

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

カタログ化し,ファミリ及びクラスを編成している。また,この規格類第 3 部は PP 及び ST の評価基

準も定義し,更に評価保証レベル(EAL)と呼ばれる七つの定義済み保証パッケージも示している。

この規格類の三つの部を支援するために,その他の文書が発行されている。例えば,ISO/IEC 18045 

この規格類に基づく IT セキュリティ評価の方法を示す文書である。技術的根拠に関する資料及びガイダン

ス文書を含め,その他の文書も発行されることが予想される。

表 に,三つの主な対象読者グループがこの規格類の各部をどのように利用すべきかを示す。

表 1−“IT セキュリティの評価基準”の役割別用途 

利用者

開発者

評価者

第 1 部

予備知識として使用する。
そして,参考資料として使

用する義務がある。PP の構
造の手引である。

予備知識及び参考資料として使用
する。そして,TOE のセキュリティ

仕様を開発するために使用する義
務がある。

PP

及び ST を評価するときの

予備知識及び参考資料として

使用する義務がある。

第 2 部

TOE

の要件に関する記述

を定式化するときの手引
及び参考資料として使用
する。

TOE

の機能要件に関する記述を解

釈するとき及び TOE の機能仕様を
定式化するときの参考資料として
使用する義務がある。

機能要件に関する記述を解釈

するときの参考資料として使
用する義務がある。

第 3 部

必要な保証レベルを決定
するときの手引として使

用する。

TOE

の保証要件に関する記述を解

釈するとき及び TOE の保証アプロ

ーチを決定するときの参考資料と
して使用する。

保証要件に関する記述を解釈
するときの参考資料として使

用する。

5.5 

評価の枠組み 

評価結果間の比較可能性を高めるために,標準を定め,評価の品質を監視し,評価設備及び評価者が遵

守しなければならない規則を管理する信頼すべき評価制度の枠組みの中で評価を実施することが望ましい。

この規格類は,規制上の枠組みに関する要件を記述していない。しかしながら,こうした評価結果に対

する相互承認の目標を達成するには,様々な認証機関の規制上の枠組み間の一貫性が必要になろう。

評価結果間で比較可能性を高める第二の方法は,評価結果を生成するために共通の方法を使用すること

である。この規格類については,この方法が ISO/IEC 18045 で説明されている。

共通評価方法を用いることは,

結果の再現性及び客観性に寄与するが,それだけでは十分とはいえない。

一貫性を達成するのがより困難であるために,評価基準の多くには,専門家の判断及び予備知識の適用が

必要である。評価結果の一貫性を高めるために,最終評価結果を認証プロセスにかけてもよい。

認証プロセスは,通常公開される最終的な認証書の発行に至る独立した評価結果の検査である。認証プ

ロセスは,IT セキュリティ基準の適用における一貫性を高める手段である。

評価制度及び認証プロセスは,この制度及びプロセスを実行する認証機関の責任であり,この規格類の

適用範囲外である。

一般モデル 

6.1 

序説及び一般モデル 

箇条 では,この規格類全体にわたって用いられる一般的概念を示す。これには,この規格類の概念が

用いられる背景及びこの概念を適用するアプローチを含む。

この規格の利用者が参考とすべき,この規格類の第 2 部及び第 3 部では,これらの概念の使用について


26

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

詳述しており,ここに示すアプローチを用いることを前提としている。さらに,評価のためにこの規格を

使用する者にとっては,ISO/IEC 18045 が適用可能である。箇条 は,IT セキュリティについて相応の知

識があることを前提としており,この分野に関する手引の役割を果たすことを意図していない。

この規格類は,セキュリティの概念及び用語を用いてセキュリティについて論じる。これらの概念及び

用語を理解することが,この規格類を効果的に用いるための必要条件である。ただし,概念自体は極めて

一般的なものであり,この規格類が適用される IT セキュリティの課題の種類を限定することを意図してい

ない。

6.2 

資産及び対抗策 

セキュリティは,資産の保護に関係する。資産とは,何者かが価値があると認めるものである。資産の

例を次に示す。

・  ファイル又はサーバの内容。

・  投票で投じられた票の真正性。

・  電子商取引の処理の可用性。

・  高価なプリンタの使用権。

・  制限区画への立入り。

ただし,価値とは非常に主観的であるため,ほとんど全てのものが資産になり得る。このような資産が

ある環境は,運用環境と呼ばれる。運用環境の(側面の)例を次に示す。

・  銀行のコンピュータルーム

・  インターネットに接続するコンピュータネットワーク

・ LAN

・  一般的なオフィス環境

資産の多くは,情報の所有者が規定した要件を満たす IT 製品によって保存されたり,処理されたり,伝

送されたりする情報の形をとる。情報の所有者は,このような情報の可用性,流出及び改変を厳格に管理

し,対抗策によって資産を脅威から保護する。

図 に,上位レベルの概念及び関係を示す。


27

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

注記  対応国際規格の図 は,矢印のとおりに単語を続けて読むと,次の例のように意味のある英語の文となる。こ

れを,日本語に訳すと,図の意図を必ずしも反映することはできないので,矢印部分は対応国際規格のとおり
とした。

例  左上の“所有者”から右下の“資産”に対して,矢印のとおりに単語を並べる。

Owners impose countermeasures to reduce risk to assets.

所有者は,資産に対するリスクを減少させる対抗策を講じる。

図 2−セキュリティの概念及び関係 

対象となる資産を保護することは,それらの資産の価値を認めている所有者の責任である。実在する又

は想定の脅威エージェントもまたその資産の価値を認め,所有者の利益に反する形で資産を悪用しようと

する可能性がある。脅威エージェントの例には,ハッカー,悪意のある利用者,悪意はないが誤りを犯す

ことがある利用者,コンピュータ処理及び事故がある。

資産の所有者は,そうした脅威を,所有者にとっての資産の価値が減少することになるような資産の侵

害の可能性ととらえる。一般に,セキュリティ固有の侵害には,資産の機密性の損失,資産の完全性の損

失,資産の可用性の損失などがあるが,これらだけではない。そのため,このような脅威が実現する可能

性と,その場合の資産への影響とに基づいて,脅威から資産に対するリスクが生じる。したがって,資産

へのリスクを減らすために,対抗策が講じられる。対抗策は,IT 対抗策(ファイアウォール,スマートカ

ードなど)及び IT 以外の対抗策(警備員,手続など)から構成されることがある。セキュリティ対抗策(管

理)

,その実装方法及び管理方法に関する,より一般的な議論については,JIS Q 27001 及び JIS Q 27002

も参照する。

資産の所有者は,それらの資産に対する責任を負う(負わされる)ことがあるため,資産を脅威にさら

すリスクを受け入れる判断の正しさを立証できることが望ましい。この判断の正しさを立証するために重

要な点は,次のことを示すことである(

図 参照)。

所有者

(Owners)

value

wish to minimize

対抗策

(Countermeasures)

impose

to reduce

リスク

(Risk)

脅威エージェント

(Threat agents)

that increase

to

give rise to

脅威

(Threats)

資産

(Assets)

to

wish to abuse and/or may damage


28

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

・  対抗策が集合として十分であること。つまり,それぞれの対抗策が主張する動作を実行すれば,資産

の脅威が対抗されること。

・  それぞれの対抗策が正確であること。つまり,対抗策が主張する動作を確実に実行すること。

資産の所有者の多くは,対抗策の十分性及び正確性を判断するのに必要な知識,技能又は資源を欠いて

いるが,対抗策の開発者の主張だけに頼ることを望まないこともある。したがって,資産の所有者は,こ

れらの対抗策の評価を依頼することによって,対抗策の一部又は全部の十分性及び正確性に対する信頼度

を向上させる選択を行ってもよい。

注記  図 の注記に同じ。 

例  Owners require confidence that countermeasures are correct and therefore minimize risk to assets.

所有者は,対抗策が正確であり,したがって資産に対するリスクを最小限にするという信頼性を要求す

る。

図 3−評価の概念及び関係 

6.2.1 

対抗策の十分性 

評価において,対抗策が十分であるかどうかは,セキュリティターゲットと呼ばれる要件定義書を通じ

て分析する。箇条 では,この要件定義書の概要を示す。より詳細で完全な記述を,

附属書 に示す。

セキュリティターゲットでは,初めに資産及び資産への脅威について記述する。次に,セキュリティタ

ーゲットは,

(セキュリティ対策方針の形式で)対抗策を記述し,その対抗策の集合が脅威に対抗するため

に十分であること,

つまりそれぞれの対抗策が主張する動作を実行すれば,

脅威が対抗されることを示す。

次に,セキュリティターゲットは,対抗策を次の二つに分ける。

a)  TOE

のセキュリティ対策方針:  評価の過程で,正確性を判断する対抗策を記述する。

評価

(Evaluation)

所有者

(Owners)

信頼性

(Confidence)

対抗策

(Countermeasures)

正確である

(Correct)

provides

require

that

are

and therefore

minimize

十分である

(Sufficient)

リスク

(Risk)

資産

(Assets)

to

and therefore

minimize

are


29

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

b)

運用環境のセキュリティ対策方針:  評価の過程で,正確性を判断しない対抗策を記述する。

このように分ける理由は,次のとおりである。

・  この規格類は,IT 対抗策の正確性の評定に適している。そのため,IT 以外の対抗策(警備員,手続な

ど)は,常に運用環境のセキュリティ対策方針とする。

・  対抗策の正確性の評定には時間及び資金がかかるため,全ての IT 対抗策の正確性の評定は不可能なこ

とがある。

・  一部の IT 対抗策の正確性は,別の評価で既に評定されていることがある。そのため,この正確性を再

評定することは,費用効率が悪い。

セキュリティターゲットには,TOE のセキュリティ対策方針(評価の過程で正確性が評定される TOE

の IT 対抗策)を,セキュリティ機能要件(SFR)でより詳細に記述する必要がある。SFR は,正確性を確

保し,比較を容易にするために,

(この規格類第 2 部で記述する)規格化された表現で規定する。

要するに,セキュリティターゲットでは次のことを示す。

・ SFR が TOE のセキュリティ対策方針を満たしている。

・ TOE のセキュリティ対策方針及び運用環境のセキュリティ対策方針が,脅威に対抗する。

・  したがって,SFR 及び運用環境のセキュリティ対策方針が脅威に対抗する。

つまり,

(SFR を満たす)正しい TOE と(運用環境のセキュリティ対策方針を満たす)正しい運用環境

との組合せによって,脅威に対抗する。次の 6.2.2 及び 6.2.3 では,TOE の正確性及び運用環境の正確性に

ついて規定する。

6.2.2 TOE

の正確性 

TOE

は正確に設計及び実装されるとは限らず,ぜい弱性の原因となる誤りが含まれることがある。この

ようなぜい弱性に付け込まれ,攻撃者によって資産に損害が与えられたり,悪用されたりする可能性があ

る。このようなぜい弱性は,開発中の不慮の誤り(不十分な設計,悪意あるコードの意図的な追加,不十

分な試験など)から生じることがある。TOE の正確性を判定するために,次のような様々なアクティビテ

ィを実施できる。

・ TOE の試験。

・ TOE の様々な設計資料の検査。

・ TOE の開発環境の物理的セキュリティの検査。

セキュリティターゲットでは,セキュリティ保証要件(SAR)の形式で,正確性を判定するために,こ

れらのアクティビティについて記述する。SAR は,正確性を確保し,比較を容易にするために,

(この規

格類第 3 部で記述する)規格化された表現で規定する。SAR が満たされている場合は,TOE の正確性が保

証されるため,攻撃者に悪用されるぜい弱性が TOE に含まれる可能性が低くなる。TOE の正確性に関す

る保証の程度は,SAR によって決定される。つまり,少数の“弱い”SAR では僅かな保証を,多数の“強

力な”SAR では多くの保証をもたらす。

6.2.3 

運用環境の正確性 

運用環境も正確に設計及び実装されるとは限らず,ぜい弱性の原因となる誤りが含まれることがある。

このようなぜい弱性に付け込まれ,攻撃者によって資産に損害が与えられたり,悪用されたりする可能性

がある。ただし,この規格類では,運用環境の正確性に関して保証は得られない。言い換えると,運用環

境は評価されない(6.3 参照)

評価に関する限り,運用環境は,運用環境のセキュリティ対策方針が 100 %正確に具体化されたものと

みなされる。


30

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

このことは,この規格類の評価対象外であるが,TOE の利用者は,次のような方法を使用して運用環境

の正確性を実現することを防げない。

・ TOE が OS であり,運用環境のセキュリティ対策方針に“運用環境では,

(インターネットなどの)信

頼できないネットワークからのエンティティは ftp だけによって TOE にアクセスできるようにしなけ

ればならない。

”と記述されている場合,利用者は評価済みのファイアウォールを選択し,TOE への

ftp

アクセスだけを許可するようにそのファイアウォールを設定することができる。

・  運用環境のセキュリティ対策方針に“運用環境では,全ての管理要員が悪意をもって行動しないよう

にしなければならない。

”と記述されている場合,利用者は,悪意ある行動に対する懲罰を含むように

管理要員との契約を見直すことができる。

6.3 

評価 

この規格類は,次に記述する ST 評価を含む TOE 評価と,この規格類第 3 部に定義される PP 評価との 2

種類の評価を対象とする。多くの場合,この規格類では,単なる“評価”という用語は,ST 評価を含む

TOE

評価を指す。この規格類は,ST 評価を含む TOE 評価を次の二つの手順で進める。

a) TOE

及び運用環境の十分性を判定する ST 評価。

b) TOE

の正確性を判定する TOE 評価。上記の TOE 評価では,運用環境の正確性は判定しない。

ST

評価を実施する場合には,

(この規格類第 3 部の ASE の箇条で定義される)セキュリティターゲット

評価基準(ASE 基準)をセキュリティターゲットに適用する。ASE 基準を適用するための詳細な方法は,

使用される評価方法によって決まる。

TOE

評価は,より複雑である。TOE 評価の入力となる基本的な証拠資料は TOE 及び ST であるが,通常,

設計文書,開発者による試験結果などの開発環境からの証拠資料もまた入力となる。TOE 評価は,証拠資

料に対して(セキュリティターゲットで記述した)各 SAR を適用することからなる。各 SAR を適用する

ための詳細な方法は,使用される評価方法によって決まる。SAR を適用した結果の文書化方法,作成が必

要な報告書及びその詳細度は,使用される評価方法と,実施する評価に適用される評価制度との両方によ

って決まる。TOE 評価プロセスの結果は,次のいずれかとなる。

・  満たされていない SAR があるため,ST に記述された SFR を TOE が満たすという保証のレベルに達

していないとする判定結果。

・  全ての SAR が満たされているため,ST に記述された SFR を TOE が満たすという保証のレベルに達

しているとする判定結果。

TOE

評価は,TOE 開発が完了した後に,又は TOE 開発と並行に実施してもよい。

ST

評価の結果及び TOE 評価の結果を記述する方法については,箇条 に規定する。この評価の結果で

は,TOE が適合を主張する PP 及びパッケージも特定する。PP 及びパッケージの構成については

,箇条 8

に規定する。

セキュリティ要件の調整(tailoring) 

7.1 

操作(Operations) 

機能及び保証コンポーネントは,

この規格類の第 2 部及び第 3 部で定義されたとおりに使用してよいが,

使用する前に許可された操作を行って修正してもよい。操作を行う場合,PP 又は ST の作成者は,この要

件に依存する他の要件への依存性の必要性が満たされていることにも注意する。許可された操作は,次の

ものに限られる。

・  繰返し:異なる操作を行って 2 回以上同一コンポーネントを使用する。


31

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

・  割付け:パラメタを指定する。

・  選択:リストから,一つ以上の項目を指定する。

・  詳細化:詳細を追加する。

割付け及び選択操作は,コンポーネントで明示された場所だけに許可される。繰返し及び詳細化は,全

てのコンポーネントに許可される。各操作について次に詳述する。

この規格類第 2 部の

附属書に有効な選択及び割付けに関する手引を記述する。この手引は,規定となる

操作の仕方を規定する。定められた規定から外れる場合,PP 又は ST の作成者は,その正当性を示さなけ

ればならない。

a)

明示的な選択肢として与えている場合を除き,

“なし”以外を書いてはならない。選択肢のリストは,

空欄であってはならない。

“なし”を選択した場合,他の選択肢を追記してはならない。

“なし”が選

択肢の中になく,

“から一つだけ選択”の指定もない場合,選択肢の複数項目を“及び”

“又は”によ

って組み合わせてもよい。選択操作は,必要に応じて繰返し操作と組み合わせてよい。この場合,個

別の繰返しで選んだ選択肢を別の繰返しの選択肢と一致させてはならない。選択肢はそもそも排他的

使用を意図しているからである。

b)

割付け操作については,

“なし”と記述できるかについては,この規格類第 2 部の

附属書を参照して判

断する。

7.1.1 

繰返し操作(The iteration operation) 

全てのコンポーネントに対して繰返し操作を行える。PP 又は ST の作成者は,同じコンポーネントを使

って,複数の要件を含めることで,繰返し操作を行う。コンポーネントのそれぞれの繰返しは,同一コン

ポーネントの他のどの繰返しとも異なっていなければならない。これは,異なる方法で割付け及び選択を

完了するか,異なる方法で詳細化を適用することで実現できる。異なる繰返しは,明確な根拠と,これら

の要件との間の追跡のために,一意に識別するのが望ましい。

繰返し操作は,繰返しと同時にある範囲の値のリストを割付け操作できる要件コンポーネントとともに

用いられることもあることに留意することが大切である。その場合,PP 又は ST の作成者は,それらの範

囲の値に対して一括した根拠を示すことが必要なのか,又はそれらの値のそれぞれに個別の根拠を示すこ

とが必要なのかを熟慮して,最もふさわしい選択をすることができる。PP 又は ST の作成者は,それらの

値に対する個々の根拠が必要かどうかについて念頭に置いておくことが望ましい。

7.1.2 

割付け操作(The assignment operation) 

割付け操作は,特定のコンポーネントに PP 又は ST の作成者によって設定されるパラメタ付きのエレメ

ントが含まれる場合に行う。パラメタは,制限のない変数又は変数を特定の範囲の値に狭める規則にする

ことがある。

PP

のエレメントに割付けが含まれる場合には常に,PP 作成者は次の四つのいずれかを行わなければな

らない。

a)

割付けを未完了のままにする。PP 作成者は,FIA_AFL.1.2[不成功の認証試行が定義した回数に達す

るか上回ったとき,TSF は,

(割付け:アクションのリスト)を実行しなければならない。

]を PP に

加えることができる。

b)

割付けを完了する。例えば,PP 作成者は,FIA_AFL.1.2(不成功の認証試行が定義した回数に達する

か上回ったとき,TSF は,今後サブジェクトに結合することを外部エンティティに禁じることを実行

しなければならない。

)を PP に加えることができる。


32

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

c)

許可する値の範囲を更に制限するために割付けの範囲を狭める。例えば,PP 作成者は,FIA_AFL.1.1

[TSF は,

(割付け:4 から 9 までの正の整数)回の不成功の認証試行が生じた時を検出しなければな

らない。

]を PP に加えることができる。

d)

割付けを選択に変えることによって,割付けの範囲を狭める。例えば,PP 作成者は,FIA_AFL.1.2[不

成功の認証試行が定義した回数に達するか上回ったとき,TSF は,

(選択:サブジェクトに結合するこ

とを利用者に禁止,管理者に通知)しなければならない。

]を PP に加えることができる。

ST

作成者は使用する機能要件のエレメントに割付けが含まれる場合には常に,上記の b)に示すように

割付けを完了しなければならない。任意項目 a)c)及び d)は ST では認められない。任意項目 b)c)及び

d)

で選定する値は,割付けで要求される指定された型に適合しなければならない。割付けが(サブジェク

トなどの)集合として完結される場合は,集合の要素を列挙してもよいし,集合の要素を導出できる次の

規則を記述してもよい。

・  全てのサブジェクト。

・  種別 X の全てのサブジェクト。

・  サブジェクト a)を除く全てのサブジェクト。

ただし,どのサブジェクトを指しているかが明確であることを条件とする。

7.1.3 

選択操作 

選択操作は,特定のコンポーネントに PP 又は ST の作成者が複数の項目から選択しなければならないエ

レメントが含まれる場合に行う。PP のエレメントに選択が含まれる場合には常に,PP 作成者は次の三つ

のいずれかを行うことができる。

a)

選択を未完了のままにする。

b)

一つ以上の項目を選んで,選択を完了する。

c)

幾つかの選択肢を削除し,二つ以上を残すことによって,選択を制限する。

ST

作成者は使用する機能要件のエレメントに選択が含まれる場合には常に,上記の b)に示すように選

択を完了しなければならない。任意項目 a)及び c)は ST では認められない。b)及び c)で選定する一つ以上

の項目は,選択で提供される項目から取得しなければならない。

7.1.4 

詳細化操作 

詳細化操作は,全ての要件で行うことができる。PP 又は ST の作成者は,要件を変更することによって

詳細化を行う。詳細化の最初の規則は,その PP 又は ST の文脈において,詳細化された要件を満たす TOE

が詳細化されていない要件も満たすということである(つまり,詳細化された要件は,元の要件に比べ“よ

り厳格”でなければならない。

。詳細化がこの規則を満たさない場合,その詳細化によって生じる要件は

拡張要件とみなされ,拡張要件として扱わなければならない。

この規則に対する唯一の例外として,PP 又は ST の作成者は,全部ではなく一部の,サブジェクト,オ

ブジェクト,操作,セキュリティ属性及び/又は外部エンティティに適用するために SFR を詳細化するこ

とができる。ただし,この例外は,適合を主張する PP から取得された SFR の詳細化には適用されない。

このような SFR は,PP 内の SFR よりも少ない,サブジェクト,オブジェクト,操作,セキュリティ属性

及び/又は外部エンティティに適用するように詳細化することはできない。

詳細化の 2 番目の規則は,詳細化は元のコンポーネントに関連付けなければならないことである。

詳細化の特殊なケースには編集上の詳細化がある。この場合,文法に合わせるために,又は読者にとっ

てより理解しやすくするために,文を書き換えるなど,要件に小さな変更が行われる。この変更によって

要件の意味を変更することはできない。


33

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

7.2 

コンポーネント間の依存性 

コンポーネント間には,依存性が存在する場合がある。あるコンポーネントがそれ自身では不十分であ

り,別のコンポーネントを伴って初めて,セキュリティ機能性又は保証を提供することができるとき,依

存性をもつという。

この規格類第 2 部の機能コンポーネントは,通常,他の機能コンポーネントに依存し,この規格類第 3

部の保証コンポーネントは,通常,他の保証コンポーネントに依存する。この規格類第 2 部の機能コンポ

ーネントは,同第 3 部の保証コンポーネントに依存するよう定義し得る。また,拡張機能コンポーネント

が保証コンポーネントに依存し,又はその反対の依存性が生じることがある。

コンポーネントの依存性の記述は,この規格類の第 2 部及び第 3 部のコンポーネント定義を参照して決

定する。TOE セキュリティ要件の完全性を保証するには,依存性のあるコンポーネントに基づく要件を PP

及び ST に組み込むときに依存性を満たさなければならない。依存性はパッケージを構成するときにも考

慮に入れなければならない。言い換えれば,コンポーネント A がコンポーネント B に依存する場合,PP

又は ST にコンポーネント A に基づくセキュリティ要件が含まれるときには常に,PP 又は ST は次のいず

れかを含まなければならない。

a)

コンポーネント B に基づくセキュリティ要件。

b)

コンポーネント B に対して上位階層関係にあるコンポーネントに基づくセキュリティ要件。

c) PP

又は ST にコンポーネント B に基づくセキュリティ要件が含まれない正当な理由。

a)

及び b)において,依存性のためにセキュリティ要件が含まれる場合,実際に依存性を満たすような特

定の方法で,セキュリティ要件に対する操作(割付け,繰返し,詳細化及び選択)を完了することが必要

になるときがある。

c)

において,セキュリティ要件を含まないことの正当化では,次のいずれかを示すのが望ましい。

・  依存性が必要又は有用ではない理由。

・  依存性が,TOE の運用環境によって対処される場合。この場合,運用環境のセキュリティ対策方針が

この依存性にどのように対処するかを正当化によって記述しなければならない。

・  依存性が,その他の SFR によって,その他の方法(拡張 SFR,SFR の組合せなど)で対処されること。

7.3 

拡張コンポーネント 

この規格類では,次の二つの例外を除いて,要件は,この規格類の第 2 部又は第 3 部のコンポーネント

に基づかなければならない。

a)

第 2 部の SFR に書き換えることができない TOE のセキュリティ対策方針が存在する,又は第 3 部の

SAR

に書き換えることができない第三者要件(暗号の評価に関する法律,標準など)が存在する。

b)

第 2 部及び/又は第 3 部のコンポーネントに基づいてセキュリティ対策方針を書き換えることができ

るが,著しい困難及び/又は複雑さを伴う。

いずれの場合にも,PP 又は ST の作成者は,独自のコンポーネントを定義する必要がある。これらの新

しく定義されるコンポーネントは,拡張コンポーネントと呼ばれる。拡張コンポーネントは,拡張 SFR 及

び SAR にその背景及び目的を提供するために正確に定義する必要がある。

新しいコンポーネントを正確に定義した後に,PP 又は ST の作成者はこれらの新しく定義した拡張コン

ポーネントに基づいて一つ以上の SFR 又は SAR を作成し,他の SFR 及び SAR と同じ方法で使用すること

ができる。以降,この規格類に基づく SAR 及び SFR と,拡張コンポーネントに基づく SAR 及び SFR とを

区別しない。拡張コンポーネントの詳細要件は,この規格類第 3 部の拡張コンポーネント定義 (APE_ECD)

及び拡張コンポーネント定義 (ASE_ECD)として記述されている。


34

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

プロテクションプロファイル及びパッケージ 

8.1 

序説 

関心をもつ利用者のグループ及びコミュニティがそれぞれのセキュリティの必要性を表現できるように

し,ST の作成を容易にするために,この規格ではパッケージ及びプロテクションプロファイル(PP)と

いう二つの特別な概念を規定している。8.2 及び 8.3 ではこれらの概念についてより詳細に説明する。8.4

ではこれらの概念の使用方法を説明する。

8.2 

パッケージ 

パッケージとは,セキュリティ要件の集合に名前を付けたものである。パッケージは,次のいずれかで

ある。

・ SFR だけを含む機能パッケージ。

・ SAR だけを含む保証パッケージ。

SFR

と SAR との両方を含む混合パッケージは認められない。

パッケージは,任意の組織(party)が定義することができ,再利用を意図している。この目的のために

は,パッケージには組み合わせることで有用であり,かつ,効果的である要件を含む方がよい。パッケー

ジは,より大きなパッケージ,PP 及び ST の中で使用できる。現在,パッケージの評価に対する基準がな

いため,SFR 又は SAR の任意の集合をパッケージにすることができる。

保証パッケージの例には,この規格類第 3 部で定義される評価保証レベル(EAL)がある。この規格の

作成時点では,この規格類に対応する機能パッケージは存在しない。

8.3 

プロテクションプロファイル 

ST

が常に特定の TOE(例えば,MinuteGap v18.5 Firewall)について記述するのに対して,PP は TOE 種

別(例えば,ファイアウォール)について記述することを意図している。したがって,異なる評価で使用

される様々な ST のひな形として,同一の PP を使用することができる。PP の詳細については,

附属書 B

に示す。

一般に,ST はある TOE の要件を記述するものであり,その TOE の開発者によって作成される。これに

対して,PP はある TOE 種別の一般要件を記述するものであり,このため,通常は次の者によって作成さ

れる。

・  所定の TOE 種別の要件について合意の形成を求めている利用者のコミュニティ。

・  ある TOE の開発者,又はその種の TOE に対する最低限の基準レベルの確立を求めている同種の TOE

の開発者団体。

・  調達プロセスの一部として要件を指定する政府又は大企業。

PP

は,ST において許可される適合の種別を決定する。すなわち,PP は,

[その PP の適合主張(B.5 

照)の中で]ST に許可されている適合の種別が何であるかを宣言する。

・  正確適合が必要であると PP が宣言している場合,

ST

は PP に対して正確に適合しなければならない。

・  例証適合が必要であると PP が宣言している場合,ST は PP に対して正確に又は例証可能な方法で適

合しなければならない。

このことを言い換えると,PP が例証適合を明示的に許可している場合だけ,ST は PP に対して例証可能

な方法で適合することができる。

ST

が複数の PP への適合を主張する場合,ST は各 PP に対して,

(上記のように)それぞれの PP が指示

する方法で適合しなければならない。このことは,ST が正確適合する PP があれば例証適合する PP もあ

ることを意味する。


35

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

ただし,ST は当該 PP に適合するかしないか,のいずれかであることに注意する。この規格類では“部

分的な”適合を認めていない。したがって,PP が過度な要求をして PP 又は ST の作成者が PP 適合を主張

することを妨げることがないようにするのは,PP 作成者の責任である。

ST

は,ある PP と同等又はそれ以上に制限的であるためには,次の全てを満たさなければならない。

・ ST を満たす全ての TOE が PP も満たす。

・ PP を満たす全ての運用環境が ST も満たす。

つまり,言い換えれば,ST は,TOE に対しては同等以上の制約を課し,TOE の運用環境に対しては同

等以下の制約を課さなければならない。

この全般的な記述は,ST の各項目において,より詳細化する。

セキュリティ課題定義: ST の適合根拠では,ST 内のセキュリティ課題定義が PP 内のセキュリティ課題

定義と同等(又はそれ以上に制限的)であることを例証しなければならない。すなわち,次の二つを例証

しなければならない。

・ ST 内のセキュリティ課題定義を満たす全ての TOE が PP 内のセキュリティ課題定義も満たす。

・ PP 内のセキュリティ課題定義を満たす全ての運用環境が ST 内のセキュリティ課題定義も満たす。

セキュリティ対策方針: ST の適合根拠では,ST 内のセキュリティ対策方針が PP 内のセキュリティ対策

方針と同等(又はそれ以上に制限的)であることを例証しなければならない。すなわち,次の二つを例証

しなければならない。

・ ST 内の TOE のセキュリティ対策方針を満たす全ての TOE が PP 内の TOE のセキュリティ対策方針も

満たす。

・ PP 内の運用環境のセキュリティ対策方針を満たす全ての運用環境が ST 内の運用環境のセキュリティ

対策方針も満たす。

プロテクションプロファイルに対する正確適合が指定されている場合,次の要件を適用する。

a)

セキュリティ課題定義  ST は PP 内のセキュリティ課題定義を含まなければならない。追加の脅威及

び OSP を指定してもよいが,追加の前提条件を指定してはならない。

b)

セキュリティ対策方針

・ ST は,PP 内の全ての TOE のセキュリティ対策方針を含まなければならないが,追加の TOE の

セキュリティ対策方針を指定してもよい。

・ ST は,

(次の項目の場合を除いて)PP 内の全ての運用環境のセキュリティ対策方針を含まなけれ

ばならないが,追加の運用環境のセキュリティ対策方針を指定してはならない。

・ ST は,PP 内のある運用環境の対策方針を TOE のセキュリティ対策方針となるように指定しても

よい。これをセキュリティ対策方針の再配置と呼ぶ。

セキュリティ対策方針が TOE に対して再配置されている場合,セキュリティ対策方針根拠では,

どの前提条件又はその前提条件のどの部分が不必要になっているのかを明確にしなければならない。

c)

セキュリティ要件  ST は PP 内の全ての SFR 及び全ての SAR を含まなければならないが,追加の SFR

及び SAR,又はより上位階層の SFR 及び SAR を主張してもよい。ST での操作の完了は PP での操作

の完了と一貫していなければならない。この場合,PP と同じ操作が ST の中で完了しているか,PP の

要件をより制限的にする(詳細化の規則を適用した)操作が完了することになる。

プロテクションプロファイルに対する例証適合が指定されている場合,次の要件を適用する。

・ ST には,その ST が PP と“同等又はそれ以上に制限的である”ように考慮されているとする根拠

を含まなければならない。


36

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

・  例証適合では,PP 作成者は解決すべき一般的なセキュリティ課題を記述して,その解決に必要な要

件に対する一般的な指針を,複数の解決方法に具体化できるような説明を添えて提供することが許

される。

PP

評価は任意選択である。評価はこの規格類第 3 部のリストに従って APE を適用することによって実

施される。この評価の目標は,PP が完全で,一貫性があり,技術的に信頼でき,別の PP 又は ST を作成

するためのひな形として使用するのに適していることを例証することである。

評価済みの PP に基づいて PP 又は ST を作成することは,次の二つの利点がある。

・ PP に誤り,曖昧さ又は不備が存在するリスクが大きく低下する。新しい ST の作成中又は評価中に,

[PP の評価によって捕捉されていたはずの]PP の問題が発見された場合には,その PP が訂正される

までに多くの時間がかかることがある。

・  新しい PP 又は ST の評価では,多くの場面で評価済み PP の評価結果を再利用でき,新しい PP 又は

ST

の評価作業をより少ない労力で終わらせることができる。

任意選択:

追加の脅威

及びOSP

任意選択:

追加又は

より厳しい

SAR及びSFR

セキュリティ

ターゲット

セキュリティ要件

SFR

SAR

セキュリティ課題定義

脅威,OSP,

対策方針

セキュリティ

対策方針

前提条件

プロテクションプロファイル

セキュリティ要件

SFR

SAR

セキュリティ課題定義

脅威,OSP,

対策方針

セキュリティ

対策方針

前提条件

Eの

運用環境

TOE

満たす

同等又はそれ以上に

制限的である

すべて

Eが満たす

正確適合

だけ

正確適合

だけ

図 4PPST 及び TOE のそれぞれの内容の関係 

セキュリティ

対策方針

前提条件

セキュリティ課題定義

脅威及び OSP

対策方針

任意選択:

追加又は

より厳しい

SAR

及び SFR

セキュリティ要件

SFR

SAR

セキュリティ

対策方針

前提条件

セキュリティ課題定義

脅威及び OSP

対策方針

セキュリティ要件

SFR

SAR

任意選択: 
追加の脅威

及び OSP

正確適合

だけ

TOE

が満たす

満たす

TOE

TOE

運用環境

正確適合

だけ


37

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

8.4 PP

及びパッケージの使用 

ST

が一つ以上のパッケージ及び/又はプロテクションプロファイルへの適合を主張する場合,その ST

の評価では,その ST が適合を主張しているパッケージ及び/又は PP に(その ST のその他の部分を含め

て)実際に適合していることが例証される。適合の判断の詳細については,

附属書 に示す。

これは,次のプロセスも許している。

a)

特定の種別の IT セキュリティ製品を調達しようとしている組織は,そのセキュリティの必要性を PP

に記述し,その評価を受け,公開する。

b)

開発者は PP を入手し,この PP への適合を主張する ST を作成し,この ST の評価を受ける。

c)

次に,開発者は TOE を開発し(又は開発済みの TOE を使用し)

,ST に基づいてこの TOE の評価を受

ける。

これによって,開発者は,自らの TOE がその組織のセキュリティの必要性に適合していることを証明で

きる。その結果,この組織はその TOE を調達することができる。パッケージにも同様の考え方を適用でき

る。

8.5 

複数のプロテクションプロファイルの使用 

この規格類では,PP を他の PP に適合させることもできる。これによって,各 PP がそれ以前からある

PP

に基づくような連鎖した PP を構成することができる。

例えば,集積回路用の PP とスマートカード OS 用の PP とを入手し,これらを使用して,両方の PP へ

の適合を主張するスマートカード PP(IC 及び OS)を構成することができる。

次に,スマートカード PP とアプレットの読込みに関する PP とに基づいて,公共交通機関用スマートカ

ードに関する PP を作成できる。最後に,開発者はこの公共交通機関用スマートカード PP に基づいて ST

を作成できる。

評価結果 

9.1 

序説 

箇条 では,ISO/IEC 18045 に従って実施される PP 及び ST を含む TOE の評価から期待される結果を次

に示す。

・  複数の PP 評価は,評価済み PP のカタログをもたらす。

・ ST 評価は,TOE の評価の枠組み内で用いられる中間結果をもたらす。

・  複数の ST 評価を含む TOE 評価は,評価済み TOE のカタログをもたらす。多くの場合,これらのカタ

ログには特定の TOE ではなく,その TOE の基となる IT 製品名が記載される。したがって,カタログ

に IT 製品名が記載されていても,IT 製品全体が評価を受けていると解釈しないほうがよい。ST 評価

を含む TOE 評価の実際の範囲は,ST によって定義される。このようなカタログ例については参考文

献を参照する。


38

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

図 5−評価結果 

ST

は,パッケージ,評価済み PP,又は評価を受けていない PP に基づいてよい。ただし,ST は何かに

基づいて作成する必要はないため,これは必須ではない。

評価は,セキュリティ評価の結果を表現する絶対的な客観的尺度がない場合でも,証拠として引用する

ことができる客観的で再現性のある結果を出す方がよい。評価基準のセットが存在することは,評価が意

味のある結果をもたらし,認証機関間での評価結果に対する相互承認の技術的基礎を提供するのに必要な

前提条件である。

評価結果は,TOE のセキュリティ特性についての特定の種類の調査所見を示す。このような評価結果は,

あらゆる適用環境での使用に適していることを自動的に保証するものではない。ある特定の適用環境での

TOE

の使用を承認するかどうかは,評価の所見を含む多くのセキュリティの観点での検討に基づいて判断

する。

9.2 PP

評価の結果 

この規格類第 3 部は,PP に不備がなく,一貫性があり,技術的に信頼でき,その結果,ST の作成にお

いて使用するのに適しているかどうか,を宣言するために参考にすることを,評価者に義務付ける評価基

準を含んでいる。評価の結果には,9.4 で定義する“適合主張”も含まれなければならない。

9.3 ST

評価を含む TOE 評価の結果 

この規格類第 3 部は,TOE が ST 内の SFR を満たしていることを示す十分な保証が存在するかどうか,

を評価者が決定するために参考にすることを,評価者に義務付ける評価基準を含んでいる。したがって,

TOE

を評価した結果として,ST に対する合否判定をしなければならない。ST 及び TOE の両方を評価した

結果,合格と判定された場合,その基になる製品には登録リストに登録される資格が与えられる。評価の

結果には,9.4 で定義する“適合主張”も含まれなければならない。

評価結果は,後に認証プロセスで使用されることがあるが,この認証プロセスは,この規格類の適用範

囲外である。

9.4 

適合主張 

適合主張は,評価に合格した PP 又は ST によって満たされる要件の集合の導出元を示す。この適合主張

は,次の記述で構成されるこの規格類への適合主張を含む。

TOE

の評価

 
 

TOE

の評価結果

PP

の評価

ST

の評価

評価済み PP

 
 

PP

の評価結果

 
 

ST

の評価結果

評価済み TOE

 
 
 
 
 
 
 
 
 
 
 

TOE

登録リスト

 
 
 
 
 
 
 
 
 
 
 

PP

登録リスト

評価済み ST


39

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

a) PP

又は ST が適合を主張するこの規格類の版を記述する。

b)

この規格類第 2 部の(セキュリティ機能要件)への適合を次のいずれかで記述する。

・  ISO/IEC 15408-2 適合−PP 又は ST は,その PP 又は ST の全ての SFR がこの規格類第 2 部の機能

コンポーネントだけに基づく場合,ISO/IEC 15408-2 適合となる。

・  ISO/IEC 15408-2 拡張−PP 又は ST は,その PP 又は ST の少なくとも一つの SFR がこの規格類第

2

部の機能コンポーネントに基づいていない場合,ISO/IEC 15408-2 拡張となる。

c)

この規格類第 3 部の(セキュリティ保証要件)への適合を次のいずれかで記述する。

・  ISO/IEC 15408-3 適合−PP 又は ST は,その PP 又は ST の全ての SAR がこの規格類第 3 部の保証

コンポーネントだけに基づく場合,ISO/IEC 15408-3 適合となる。

・  ISO/IEC 15408-3 拡張−PP 又は ST は,その PP 又は ST の少なくとも一つの SAR がこの規格類第

3

部の保証コンポーネントに基づいていない場合,ISO/IEC 15408-3 拡張となる。

さらに,適合主張には,パッケージに関してなされる宣言を含んでもよい。この場合には次のうちの一

つが選択される。

a)

パッケージ名適合−PP 又は ST が,次のいずれかの場合に,あらかじめ定義されたパッケージ(例え

ば,EAL)に適合しているとき。

・  その PP 又は ST 内の SFR が,パッケージ内の SFR と同じ。

・  その PP 又は ST 内の SAR が,パッケージ内の SAR と同じ。

b)

パッケージ名追加−PP 又は ST が,次のいずれかの場合に,あらかじめ定義されたパッケージへの追

加となるとき。

・ PP 又は ST 内の SFR にはパッケージ内の全ての SFR が含まれるが,追加の SFR 又はパッケージ

内の SFR よりも上位階層の SFR が少なくとも一つある。

・ PP 又は ST 内の SAR にはパッケージ内の全ての SAR が含まれるが,追加の SAR 又はパッケージ

内の SAR よりも上位階層の SAR が少なくとも一つある。

TOE

がある ST で評価に合格している場合,その ST の適合主張は,その TOE にも適用できることに注

意する。したがって,TOE は,例えば ISO/IEC 15408-2  適合でもあり得る。

最後に,適合主張には,プロテクションプロファイルに関する次の二つの宣言を含んでもよい。

a) PP

適合−PP 又は TOE が,適合結果の一部として記載されている特定の PP を満たしているとき。

b)

適合の表明(PP だけ)−この表明は,PP 又は ST がこの PP に適合しなければならない方法,つまり

正確又は例証を記述する。この適合の表明の詳細については,

附属書 に示す。

9.5 ST

評価を含む TOE 評価の結果の利用 

ST

及び TOE が評価されると,資産の所有者は,TOE がその運用環境とともに脅威に対抗することにつ

いて,

(ST に定義される)保証を得ることができる。資産を脅威にさらすリスクを受け入れるかどうかを

判断するときに,その資産の所有者は評価結果を利用することができる。

ただし,資産の所有者は次のことを慎重に確認する方がよい。

・ ST 内のセキュリティ課題定義が資産の所有者のセキュリティ課題と一致している。

・  資産の所有者の運用環境が,ST に記述された運用環境のセキュリティ対策方針に適合している(又は

適合させることができる。

上記のいずれかが当てはまらない場合,その TOE は資産の所有者の目的に適していないことがある。ま

た,評価済み TOE の運用が開始されると,これまで分からなかった TOE 内の誤り又はぜい弱性が表面化

することがある。この場合,開発者は(ぜい弱性を改修するために)TOE を修正するか,又は ST を変更


40

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

して評価の範囲からぜい弱性を除去してもよい。いずれの場合も,前の評価結果はもはや有効ではない。

信頼の回復が必要であると思われる場合は,再評価が必要である。この規格類はこのような再評価のた

めに使用してよいが,再評価を行うための詳細な手続はこの規格の適用範囲外である。


41

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

附属書 A

(参考)

セキュリティターゲットの仕様

A.1 

この附属書の目的及び構成 

この附属書の目的は,セキュリティターゲット(ST)の概念を説明することにある。この附属書では,

ASE

基準(セキュリティターゲットの評価基準)の定義は行わない。ASE 基準の定義は,この規格類第 3

部にある。詳述は ISO/IEC 15408-3 の E.1[3]の中に見つけることができる。

この附属書は,次の四つの主要な部分から構成されている。

a) ST

に記載しなければならない内容。これについては,A.2 で概要を述べ,A.4 から A.10 まででより詳

細に説明する。これらの箇条では,ST 必須記載内容及び各内容間の相互関係について説明し,例を示

す。

b)

望ましい ST の使用法。これについては,A.3 で概要を述べ,A.11 でより詳細に説明する。これらの

箇条では,ST がどのように使用される方がよいかについて及び幾つかの疑問について ST で回答可能

なことを説明する。

c)

低保証 ST。低保証 ST は,ST の記載内容を減らした ST である。これについては,A.12 で詳細に説明

する。

d)

標準への適合の主張。A.13 では,TOE が特定の標準を満たしていることを,ST 作成者が主張する方

法について説明する。

A.2 ST

必須記載内容 

図 A.1 は,この規格類第 3 部に規定する ST 必須記載内容を示す。図 A.1 は,ST の構成に関する概略図

として使用してもよいが,別の構成であってもよい。例えば,セキュリティ要件根拠が特に長くなる場合

は,セキュリティ要件の箇条の代わりに,ST の附属書にそれを記述することができる。ST の各箇条及び

それらの細分箇条の記載内容を,次に手短に述べ,A.4 から A.10 まででより詳細に説明する。通常,ST

には次の事項を記述する。

a) ST

概説。抽象レベルの異なる,TOE についての三つの叙述的記述を含む。

注記 TOE についての三つの叙述的記述とは,ST 参照・TOE 参照,TOE 概要及び TOE 記述である。

b)

適合主張。ST が,いずれかの PP 及び/又はパッケージへの適合を主張するかどうかを示し,適合す

る場合には,どの PP 及び/又はパッケージに適合しているかを示す。

c)

セキュリティ課題定義。脅威,組織のセキュリティ方針(OSP)及び前提条件を示す。

d)

セキュリティ対策方針。セキュリティ課題を TOE のセキュリティ対策方針及び TOE の運用環境のセ

キュリティ対策方針に分割した解決方法を示す。

e)

拡張コンポーネント定義。  (この規格類の第 2 部又は第 3 部に含まれていない)  新しいコンポーネ

ントを定義することができる。これらの新しいコンポーネントは,拡張機能要件及び拡張保証要件を

定義するために必要である。

f)

セキュリティ要件。TOE のセキュリティ対策方針から規格化された表現に書き換えたものを示す。SFR

及び SAR は規格化された言語で表現される。また,根拠では SFR からセキュリティ対策方針へ逆方

向に遡れること,SFR の正当性を記述する。


42

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

g) TOE

要約仕様。TOE で SFR を実装する方法を示す。

ST

の記載内容を減らした低保証 ST も存在する。これについては,A.12 で詳細に説明する。この附

属書の他の部分では,上記の全項目を含む ST を想定している。

図 A.1−セキュリティターゲットの内容 

A.3 ST

の使用 

A.3.1 

望ましい ST の使用法 

典型的な ST は,次の二つの役割を果たす。

・  評価前及び評価中の場合,ST は“評価の対象が何か”を規定する。この役割において,ST は,TOE

の正確なセキュリティ特性及び正確な評価範囲に関して,開発者と評価者との間で合意するための基

となるものを提供する。この役割では,技術的な正確さ及び完全さが主な課題である。この役割にお

いて ST をどのように使用すればよいかについて A.7 で説明する。

・  評価後の場合,ST は“評価済みの対象が何か”を規定する。この役割において,ST は,TOE の開発

者又は販売代理業者と TOE の潜在的な利用者との間で合意するための基となるものを提供する。ST

は,TOE の正確なセキュリティ特性を抽象的に記述するものであり,この ST を満たすことを TOE が

評価済みであることから,潜在的な利用者は,この ST の記述を信頼することができる。この役割で

 
 

セキュリティターゲット

ST

参照

TOE

参照

TOE

概要

TOE

記述

 
 

ST

概説

CC

適合主張

PP

主張,

パッケージ主張

適合根拠

 
 

適合主張

脅威 
組織のセキュリティ方針 
前提条件

 
 

セキュリティ課題定義

TOE

のセキュリティ対策方針

運用環境のセキュリティ対策方針 
セキュリティ対策方針根拠

 
 

セキュリティ対策方針

拡張コンポーネント定義

 
 

拡張コンポーネント定義

セキュリティ機能要件 
セキュリティ保証要件

セキュリティ要件根拠

 
 

セキュリティ要件

TOE

要約仕様

 
 

TOE

要約仕様


43

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

は,使いやすさ及び理解しやすさが主な課題である。この役割において ST をどのように使用すれば

よいかについて A.11 で説明する。

A.3.2 

望ましくない ST の使用法 

(ST の多くの役割の中から)ST が果たさない方がよい二つの役割を次に示す。

詳細な仕様:ST は,比較的抽象レベルの高いセキュリティ仕様を記述する。一般に,ST には詳細な

プロトコル仕様,アルゴリズム及び/又は機構の詳細な説明,詳細にわたる運用の長い説明などを含

まない方がよい。

完全な仕様:ST は,セキュリティ仕様を記述したものであって,全体の仕様ではない。セキュリティ

に関係する場合を除いて,相互運用性,物理的な寸法及び重さ,定格電圧などの特性は,ST の一部分

でない方がよい。これは一般に,ST は,それ自体が完全な仕様ではなく,完全な仕様の一部分であっ

ても差し支えないということを意味する。

A.4 ST

概説(ASE_INT) 

ST

概説では,次の三つの抽象レベルについて叙述的な方法で TOE を説明する。

a) ST

参照及び TOE 参照。ST 及び ST が参照する TOE の識別情報を提供する。

b) TOE

概要。TOE を簡潔に説明する。

c) TOE

記述。TOE をより詳細に説明する。

A.4.1 ST

参照及び TOE 参照 

ST

は,特定の ST を指し示す明確な ST 参照を含む。典型的な ST 参照は,名称,バージョン,作成者及

び発行日から構成する。

“MauveRAM Database ST,バージョン 1.3,MauveCorp Specification Team,2002

年 10 月 11 日”は,ST 参照の記述例である。

ST

は,ST への適合を主張する TOE を指し示す TOE 参照も含む。典型的な TOE 参照は,開発者名,TOE

の名称及び TOE のバージョン番号から構成する。

“MauveCorp MauveRAM Database v2.11”は,TOE 参照

の記述例である。単一の TOE が,例えば,TOE の様々な利用者によって,何度も評価を受け,その結果,

複数の ST が存在する場合には,ST 参照は一意である必要はない。

TOE

が一つ以上の既知の製品から構成される場合,その製品名を挙げて,このことを TOE 参照に記述

することができる。ただし,利用者に,次のような誤解を与えてはならない,すなわち,主要な部分又は

セキュリティ機能が,その評価において熟慮されていない状況であるにもかかわらず,このことを記述し

ていない TOE 参照は,認められない。

ST

参照及び TOE 参照は,ST 及び TOE に索引を付け,これらを参照すること及び評価済みの TOE 又は

製品のリストにこれらを掲載することを容易にする。

A.4.2 TOE

概要 

TOE

概要は,自らのセキュリティの必要性を満たし,自らが使用するハードウェア,ソフトウェア及び

ファームウェアで稼動する TOE を見つけるために評価済みの TOE 又は製品のリストを調べようとする,

TOE

の潜在的な利用者のためのものである。TOE 概要の一般的な長さは,数段落である。

このため,TOE 概要は,TOE の使用方法及びその主要なセキュリティの特徴について簡潔に説明し,TOE

の種別及び TOE が必要とする TOE 以外の主要なハードウェア,ソフトウェア及びファームウェアが何で

あるかを示す。


44

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

A.4.2.1 TOE

の使用方法及び主要なセキュリティの特徴 

TOE

の使用方法及び主要なセキュリティの特徴に関する記述は,セキュリティの点から TOE が潜在的

にもつ能力及びセキュリティに関連した TOE の用途についての,ごく一般的な知識を与えることを目的と

する。この記述は,

(潜在的な)TOE の利用者のために,業務運用の視点から,TOE の使用方法及び主要

なセキュリティの特徴について TOE の利用者が分かる表現を使用して記述するのがよい。この記述例を次

に示す。

例  MauveCorp MauveRAM Database v2.11 は,ネットワーク環境での使用を想定した複数利用者向け

のデータベースである。このデータベースは,1 024 人の利用者が同時利用できる。このデータベ

ースは,パスワード又はトークンによる認証及び生体認証が使用でき,偶発的なデータ破損を防

止し,10 000 トランザクションをロールバックすることができる。このデータベースの監査の特

徴は,一部の利用者及びトランザクションに対する詳細な監査が,それ以外の利用者及びトラン

ザクションのプライバシを保護しつつ,実施できるように,高度に設定ができることである。

A.4.2.2 TOE

種別 

TOE

概要には,ファイアウォール,VPN ファイアウォール,スマートカード,暗号化モデム,イントラ

ネット,ウェブサーバ,データベース,ウェブサーバ及びデータベース,LAN,ウェブサーバ及びデータ

ベースを伴う LAN などの,TOE の一般的な種別を示す。

TOE

が上記のように容易に種別が記載できない場合には,

“なし(none)

”を使用することができる。

TOE

種別は,幾つかの場合において,利用者に誤解を与えることがある。例を次に示す。

a) TOE

種別から,TOE に特定のセキュリティ機能が備わっているものと期待しているにもかかわらず,

TOE

がこのセキュリティ機能を備えていないことがある。例を次に示す。

・ ATM カード種別の TOE において,識別機能・認証機能がない。

・  ファイアウォール種別の TOE において,ほとんど一般的に使用されているプロトコルに対応して

いない。

・ PKI 種別の TOE において,証明書失効機能がない。

b) TOE

種別から,TOE が特定の運用環境で動作するものと期待しているにもかかわらず,TOE がその

運用環境で動作できないことがある。例を次に示す。

・ PC オペレーティングシステム種別の TOE において,ネットワーク接続,フロッピードライブの

使用及び CD/DVD プレーヤの使用を行うと,PC がセキュアに動作しない。

・  ファイアウォール種別の TOE において,そのファイアウォールを通じて接続可能な全ての使用者

が善良でない限り,セキュアに動作しない。

A.4.2.3 

必要とする TOE 以外のハードウェア,ソフトウェア及び/又はファームウェア 

他の IT に依存しない TOE もあるが,多くの TOE(特にソフトウェア TOE)は,TOE 以外の追加のハー

ドウェア,ソフトウェア及び/又はファームウェアに依存する。後者の場合,TOE 概要は,そのような

TOE

以外のハードウェア,ソフトウェア及び/又はファームウェアを識別する必要がある。追加のハード

ウェア,ソフトウェア及び/又はファームウェアに関する,全てについての,十分に詳細な識別は必要で

はないが,この識別は,潜在的な利用者に対して,TOE を使用するために必要とする,主要なハードウェ

ア,ソフトウェア及び/又はファームウェアを判断するために十分な程度,それらの全てについて詳細で

ある方がよい。ハードウェア,ソフトウェア及び/又はファームウェアの識別例を,次に示す。

・ Yaiza オペレーティングシステム(バージョン 3.0  アップデート 6b,6c  若しくは 7,又はバージョン

4.0

)上で実行し,1 GHz より高速のプロセッサ及び 512 MB 以上の RAM を搭載した標準 PC。


45

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

・ Yaiza オペレーティングシステム(バージョン 3.0  アップデート 6d)上で実行し,1.0 WM ドライバセ

ットを備えた WonderMagic 1.0 グラフィックスカード,1 GHz より高速のプロセッサ及び 512 MB 以上

の RAM を搭載した標準 PC。

・ Yaiza

OS

(バージョン 3.0 以上)を搭載した標準 PC。

・ CleverCard

SB2067

集積回路。

・ Quick

OS

スマートカードオペレーティングシステム

(バージョン 2.0)

上で実行する CleverCard SB2067

集積回路。

・ 20xx 年 xx 月に設置された省庁の LAN。

A.4.3 TOE

記述 

TOE

記述は,TOE についての叙述的記述であり,数ページにわたることがある。TOE 記述は,TOE 概

要よりも詳細に,TOE がもつセキュリティの能力についての一般的な見解を,評価者及び潜在的な利用者

に与えた方がよい。TOE 記述は,その TOE の想定用途よりも幅広い用途を記述するために使用してもよ

い。

TOE

記述には,TOE の物理的範囲(TOE を構成する全てのハードウェア,ファームウェア,ソフトウ

ェア及びガイダンスのリスト)を記述する。このリストは,TOE の物理的範囲についての一般的な見解を

読者に与えるのに十分な詳細レベルで記述した方がよい。

TOE

記述には,TOE の論理的範囲(一般的な見解を読者に与えるのに十分な詳細レベルで,TOE によ

って提供される論理的なセキュリティの特徴)も記述した方がよい。この記述は,TOE 概要に記述する主

要なセキュリティの特徴よりも詳細であることが求められる。

物理的範囲及び論理的範囲において重要なことは,特定の部品又は特徴が TOE の範囲内であるかどうか

についての,また,この部品又は特徴が TOE の範囲外であるかどうかについての疑いを残さない方法で,

TOE

を記述することである。これは,TOE が TOE 以外のエンティティと相互に関連し,簡単に分離でき

ない場合に,特に重要である。TOE が TOE 以外のエンティティと相互に関連している例を次に示す。

・ TOE が,スマートカード IC 全体ではなく,スマートカード IC の暗号化コプロセッサである場合。

・ TOE が,暗号化プロセッサを除くスマートカード IC である場合。

・ TOE が,MinuteGap Firewall v18.5 のネットワークアドレスの変換部分である場合。

A.5 

適合主張(ASE_CCL) 

ST

のこの細別箇条には,ST が次に挙げるものとどのように適合するかを記述する。

・  この規格類の第 2 部及び第 3 部。

・  プロテクションプロファイル(ただし,存在する場合に限る。

・  パッケージ(ただし,存在する場合に限る。

ST

がこの規格類とどのように適合するかの記述は,使用するこの規格類の版及び ST に拡張セキュリテ

ィ要件が含まれるかどうか(A.8 参照)の二つの項目から成り立つ。

プロテクションプロファイルに対する ST の適合性の記述は,適合性を主張するプロテクションプロフ

ァイルを,ST において列挙することをいう。この詳細を 9.4 に示す。

パッケージに対する ST の適合性の記述は,適合性を主張するパッケージを,ST において列挙すること

をいう。この詳細を 9.4 に示す。


46

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

A.6 

セキュリティ課題定義(ASE_SPD)

A.6.1 

概要 

セキュリティ課題定義では,対処する必要があるセキュリティ課題を定義する。この規格類に関する限

り,セキュリティ課題定義は自明のこととして扱われる。すなわち,セキュリティ課題定義を導くプロセ

スは,この規格類の適用範囲外である。しかし,評価結果の有用性は ST に大きく依存し,ST の有用性は

セキュリティ課題定義の質に大きく依存することに注意する方がよい。したがって,良好なセキュリティ

課題定義を導くために,多くの資源を費やし,明確に定義されたプロセス及び分析を使用することは多く

の場合価値がある。

この規格類第 3 部によれば,全ての箇条に内容を記述する必要がないことに注意する。例えば,ST に脅

威を記述すれば,OSP を記述しなくてもよい,また,逆に OSP を記述すれば脅威について記述しなくても

よい。同様に,いかなる ST も前提条件を省略することができる。

TOE

が物理的に分散している場合は,TOE 運用環境の個別領域ごとに関連する脅威,OSP 及び前提条件

を記述することが望ましいことにも注意する。

A.6.2 

脅威 

セキュリティ課題定義の A.6.2 では,TOE,その運用環境又はこれら二つの組合せによって対抗する必

要がある脅威を示す。

脅威は,資産に対する脅威エージェントの敵対的な動作から構成される。敵対的な動作は,資産価値を

生じる資産の一つ以上の特性に影響を与える。脅威エージェントは個々のエンティティとして記述するこ

とができるが,場合によってはエンティティの種別,エンティティのグループなどとして記述する方が適

切である。脅威エージェントの例には,ハッカー,利用者,コンピュータのプロセス,事故などがある。

脅威エージェントは,専門知識,資源,機会,動機などの側面によって,更に詳細に記述することができ

る。

注記  資源とは,人,もの,金,時間などを指す。

敵対的な動作とは,脅威エージェントが資産に対して行う動作である。これらの動作は,資産価値を生

じる資産の一つ以上の特性に影響を与える。脅威の例を次に示す。

・  企業のネットワークから機密ファイルを遠隔操作で複製するハッカー(優れた専門知識,標準的な機

器を所有し,この行為に対して報酬を受け取る)

・  広域ネットワーク(WAN)の性能を大幅に低下させるワーム。

・  利用者のプライバシを侵害するシステム管理者。

・  機密通信を傍受しているインターネット上の第三者。

A.6.3 

組織のセキュリティ方針(OSP)

セキュリティ課題定義の A.6.3 では,TOE,その運用環境又はこれら二つの組合せによって実施する必

要がある OSP を示す。

OSP

とは,実際又は仮想上の組織によって,その運用環境において現在及び/又は将来に課される(若

しくは課されると推定される)セキュリティの規則,手続又はガイドラインである。OSP は TOE の運用

環境を管理する組織によって規定される場合もあれば,立法機関又は規制機関によって規定される場合も

ある。OSP は,TOE 及び/又は TOE の運用環境に適用できる。OSP の例を次に示す。

・  政府によって使用される全ての製品は,パスワード生成及び暗号化に関して国の基準に適合しなけれ

ばならない。


47

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

・  システム管理者の権限と部門機密に対するアクセス許可とをもつ利用者だけが,部門ファイルサーバ

を管理できるようにしなければならない。

A.6.4 

前提条件 

セキュリティ課題定義の A.6.4 では,セキュリティ機能を提供できるようにするために,その運用環境

に対して設定する前提条件を示す。TOE がこれらの前提条件を満たさない運用環境に置かれる場合,その

TOE

はそのセキュリティ機能の全てを提供することができなくなる可能性がある。前提条件には,運用環

境の物理的条件,人的条件及び接続に関する条件がある。前提条件の例を次に示す。

a)

運用環境の物理的側面に関する前提条件。

・ TOE は電磁波の放射を最小限にするように設計された部屋に設置されることを前提とする。

・ TOE の管理者コンソールはアクセス制限された領域に設置されることを前提とする。

b)

運用環境の人的側面に関する前提条件。

・ TOE の利用者は TOE を運用するために十分に訓練を受けることを前提とする。

・  国家機密として分類される情報に対して,TOE の利用者は情報の取扱いについて承認を受けるこ

とを前提とする。

・ TOE の利用者はパスワードを書き留めないことを前提とする。

c)

運用環境の接続性の側面に関する前提条件。

・ TOE を実行するために,ディスク領域が最低 10 GB の PC ワークステーションを利用できること

を前提とする。

・ TOE は,このワークステーションで実行されている OS 以外の唯一のアプリケーションであるこ

とを前提とする。

・ TOE は,信頼できないネットワークに接続されないことを前提とする。

評価中に,これらの前提条件は満たされているとみなされることに注意する。つまり,前提条件は決し

て試験されることはない。このため,前提条件は運用環境だけに対して設定できる。評価は,TOE に関す

る主張を評価することからなり,TOE に関する主張が正しいことを前提条件とすることではないので,

TOE

の動作に関して前提条件を設定することはできない。

A.7 

セキュリティ対策方針(ASE_OBJ) 

セキュリティ対策方針は,セキュリティ課題定義によって定義される課題に対して意図している解決策

の簡潔かつ抽象的な宣言文である。セキュリティ対策方針には,次の三つの役割がある。

・  課題に対して,自然言語で記述された上位レベルの解決策を提供する。

・  異なるエンティティ(TOE 及び運用環境)のそれぞれが課題の一部に対処しなければならないことを

反映するように,この解決策を二つの分割式解決策に分ける。

・  これらの分割式解決策が課題に対する完全な解決策を形成することを示す。

A.7.1 

上位レベル解決策 

セキュリティ対策方針は,あまり詳細過ぎない簡潔かつ明確な宣言文の集まりから構成される。これら

の組合せによって,セキュリティ課題に対する上位レベルの解決策が形成される。セキュリティ対策方針

の抽象化のレベルは,TOE について知識のある潜在的な利用者にとって,明確かつ理解可能にすることを

目的としている。セキュリティ対策方針は,自然言語で記述する。

A.7.2 

分割式解決策 

ST

では,セキュリティ対策方針に示される上位レベルセキュリティ解決策は,二つの分割式解決策に分


48

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

けられる。このような分割式解決策は,TOE のセキュリティ対策方針及び運用環境のセキュリティ対策方

針と呼ばれる。これは,分割式解決策が,TOE 及び運用環境という二つの異なるエンティティによって提

供されることを反映している。

A.7.2.1 TOE

のセキュリティ対策方針 

TOE

は,セキュリティ課題定義によって定義される課題の特定の部分を解決するために,セキュリティ

機能を提供する。この分割式解決策は,TOE のセキュリティ対策方針と呼ばれ,課題の特定の部分を解決

するために TOE が達成すべき目標のセットから構成される。TOE のセキュリティ対策方針の例を,次に

示す。

・ TOE は,TOE とサーバとの間で転送される全てのファイルの内容の機密を保持しなければならな  い。

・ TOE は,TOE が提供する転送サービスへのアクセスを許可する前に,全ての利用者を識別し,認証し

なければならない。

・ TOE は,ST の

附属書 に示されるデータアクセス方針に従って,データに対する利用者のアクセス

を制限しなければならない。

TOE

が物理的に分散している場合は,TOE のセキュリティ対策方針を含む ST の箇条を,これを反映す

るために複数の細分箇条に分割することが望ましい場合がある。

A.7.2.2 

運用環境のセキュリティ対策方針 

TOE

の運用環境は,TOE が(TOE のセキュリティ対策方針によって定義される)セキュリティ機能を

正しく提供できるように TOE を支援する技術及び手続に関する手段を実装する。この分割式解決策は運用

環境のセキュリティ対策方針と呼ばれ,運用環境で達成すべき目標を記述する宣言文の集まりから構成さ

れる。

運用環境のセキュリティ対策方針の例を,次に示す。

・  運用環境では,TOE を実行するために OS Inux バージョン 3.01b が動作しているワークステーション

を提供しなければならない。

・  運用環境では,TOE の操作を許可する前に,全ての TOE 利用者が適切な訓練を受けるようにしなけ

ればならない。

・ TOE の運用環境では,管理者及び管理者に付き添われた保守員に TOE への物理的アクセスを制限し

なければならない。

・  運用環境では,中央監査サーバに送信する前に,TOE によって生成される監査ログの機密性を確保し

なければならない。

TOE

の運用環境が特性の異なる複数のサイトから構成されている場合は,これを反映するために,運用

環境のセキュリティ対策方針を含む ST の箇条を,これを反映するために複数の細分箇条に分割すること

が望ましい場合がある。

A.7.3 

セキュリティ対策方針とセキュリティ課題定義との関係 

ST

には,次の二つの箇条からなるセキュリティ対策方針根拠も含まれる。

・  どのセキュリティ対策方針が,どの脅威,OSP 及び前提条件に対処するかを示す追跡。

・  全ての脅威,OSP 及び前提条件がセキュリティ対策方針によって効果的に対処されることを示す正当

化のセット。

A.7.3.1 

セキュリティ対策方針とセキュリティ課題定義との間の追跡 

追跡は,セキュリティ対策方針が,セキュリティ課題定義で記述される脅威,OSP 及び前提条件までど

のように遡るかを示す。この追跡では,次の三つの規則に従わなければならない。


49

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

a)

見せかけの対策方針の禁止:各セキュリティ対策方針は,少なくとも一つの脅威,OSP 又は前提条件

まで遡る。

b)

セキュリティ課題定義に関する完全性:脅威,OSP 及び前提条件のそれぞれについて,そこまで遡る

少なくとも一つのセキュリティ対策方針がある。

c)

正確な追跡:前提条件は常に TOE の運用環境について設定されるため,TOE のセキュリティ対策方

針は前提条件に遡らない。この規格類第 3 部で認められる追跡を

図 A.2 に示す。

図 A.2−セキュリティ対策方針とセキュリティ課題定義との間の追跡 

複数のセキュリティ対策方針が遡った先が同じ脅威になることがあるが,その場合,これらのセキュリ

ティ対策方針の組合せがその脅威に対抗することを示す。OSP 及び前提条件にも同じことが当てはまる。

A.7.3.2 

追跡の正当化の提供 

セキュリティ対策方針根拠では,追跡が有効であることも示す。つまり,特定の脅威,OSP 及び前提条

件まで遡る全てのセキュリティ対策方針が達成された場合,その脅威は対抗され,OSP は実施され,前提

条件が確認されることを示す。

この追跡の正当化においては,関連するセキュリティ対策方針を達成することによる,脅威への対抗,

OSP

の実施及び前提条件の確認への効果を分析し,実際に対抗,実施及び確認されるという結論を導く。

セキュリティ課題定義が幾つかのセキュリティ対策方針と非常に似ているような状況では,追跡の正当

化が非常に簡単になることがある。例えば,脅威が“T17:  脅威エージェント X は,AB 間の転送時に機

密情報を読み取る。

”であり,TOE のセキュリティ対策方針が“OT12: TOE は,AB 間で送信される全て

の情報の機密が確実に保持されるようにしなければならない。

”である場合,

“T17 は,OT12 によって直接

対抗される。

”と示される。

A.7.3.3 

脅威への対抗について 

脅威への対抗とは,必ずしもその脅威を除去することを意味せず,脅威を十分に減らすこと又は脅威を

十分に緩和することを意味する場合もある。

脅威の除去の例は,次のとおりである。

・  脅威エージェントから悪意ある行為を実行する能力を除去する。

・  敵対的な動作を資産に対して行うことができなくなるように,資産を移動,変更又は保護する。

・  脅威エージェントを除去する(例えば,頻繁にネットワークに障害を起こす装置をネットワークから

取り外す。

脅威の軽減の例は,次のとおりである。

・  敵対的な動作を実行する脅威エージェントの能力を制限する。

 
 
 
 
 
 
 

脅威

 
 

組織の

セキュリティ方針

 
 
 
 
 
 

前提条件

TOE

セキュリティ

対策方針

運用環境の

セキュリティ

対策方針


50

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

・  脅威エージェントが敵対的な動作を実行する機会を制限する。

・  実行された敵対的な動作が成功する可能性を減少させる。

・  抑止によって脅威エージェントが敵対的な動作を実行する動機を減少させる。

・  脅威エージェントに,より多くの専門知識又は資源を課する。

脅威の影響の緩和の例は,次のとおりである。

・  資産のバックアップを頻繁に行う。

・  資産のスペアコピーを取る。

・  資産に保険をかける。

・  適切なアクションをとることができるように,成功した全ての敵対的な動作が適切な時期に必ず検出

されるようにする。

A.7.4 

セキュリティ対策方針:結論 

セキュリティ対策方針及びセキュリティ対策方針根拠に基づいて,

次のような結論を導くことができる。

・  全てのセキュリティ対策方針が達成された場合,ASE_SPD で定義されるセキュリティ課題は解決され

る。

・  全ての脅威が対抗され,全ての OSP が実施され,全ての前提条件が確認される。

A.8 

拡張コンポーネント定義(ASE_ECD) 

多くの場合,ST のセキュリティ要件(A.9 参照)は,この規格類の第 2 部又は第 3 部のコンポーネント

に基づく。ただし,場合によっては,この規格類の第 2 部又は第 3 部のコンポーネントに基づかない ST

の要件が存在することがある。この場合は,新しいコンポーネント(拡張コンポーネント)を定義しなけ

ればならない。この定義は拡張コンポーネント定義で行う。これについての詳細を,C.4 に示す。

A.8

では,拡張コンポーネントだけを扱い,拡張要件(拡張コンポーネントに基づく要件)については

扱わない。拡張要件はセキュリティ要件(A.9 参照)に含めることが望ましい,全ての目的のために,こ

の規格類の第 2 部又は第 3 部のコンポーネントに基づく要件と同じになる。

A.9 

セキュリティ要件(ASE_REQ) 

セキュリティ要件は 2 種類の要件からなる。

a)

セキュリティ機能要件(SFR)

:TOE のセキュリティ対策方針の規格化された表現への書換え。

b)

セキュリティ保証要件(SAR)

:TOE が SFR に対応していることについて,どのように保証されるか

についての記述。

A.9.1

及び A.9.2 でこれらの 2 種類の要件について示す。

A.9.1 

セキュリティ機能要件(SFR) 

SFR

は TOE のセキュリティ対策方針の書換えである。

SFR

は通常,

抽象化のより詳細なレベルにあるが,

完全な書換えでなければならない(完全な書換えとは,セキュリティ対策方針が完全に記述されることで

ある。

さらに,SFR は特定の技術的解法(実装)から独立していなければならない。この規格類は,次の理由

によって規格化された表現への書換えを必要とする。

・  評価される対象についての正確な記述を提供するため。TOE のセキュリティ対策方針は通常,自然言

語で表現されるが,規格化された表現への書換えには TOE の機能の,より正確な記述が求められる。

・  二つの ST 間での比較を可能とするため。異なる ST 作成者がセキュリティ対策方針について説明する


51

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

ときに異なる用語を使用するかもしれないが,規格化された表現では同じ用語及び概念を使用するこ

とが求められる。これによって比較が容易になる。

運用環境は評価されず,その評価を目的とした記述は必要ないので,運用環境のセキュリティ対策方針

のために,この規格類ではどのような書換えも必要ない。運用システムのセキュリティアセスメントに関

連する参考文献を参照する。

運用環境の一部が別の評価で評価されるかもしれないが,これは現行の評価の範囲外である。例えば,

TOE

が OS の場合は,ファイアウォールがその運用環境に存在することを必要とするかもしれない。別の

評価ではファイアウォールを評価するかもしれないが,この評価は TOE が OS の場合の評価と関係ない。

A.9.1.1 

この規格類がこの書換えを支援する方法 

この規格類は,次の三つの方法でこの書換えを支援する。

a)

評価される対象について正確に記述するように設計された,事前に定義された明確な“表現”を提供

することによる。この表現は,この規格類第 2 部で定義されるコンポーネントの集まりとして定義さ

れる。幾つかの例外はあるが(7.3 参照)

,TOE のセキュリティ対策方針から SFR への明確な書換えと

して,この表現の使用が必須である。

b)

操作を提供することによる。操作とは,ST 作成者が,SFR を変更して,TOE のセキュリティ対策方

針の,より正確な書換えを提供するようにする仕組みのことである。この規格類には,割付け,選択,

繰返し及び詳細化の四つの操作が規定されている。これらは C.2 で,より詳しく記述している。

c)

依存性を提供することによる。依存性とは,SFR への,より完全な書換えを支援する仕組みのことで

ある。この規格類第 2 部の表現では,一つの SFR は他の SFR への依存性をもつことができる。これ

は,ST がその SFR を使用する場合に,他の SFR を使用する必要性を意味する。したがって,必要な

SFR

を含めることで,ST 作成者が入れ忘れないようにし,ST の完全性を改善する。依存性は 7.2 で,

より詳しく示している。

A.9.1.2 SFR

とセキュリティ対策方針との関係 

ST

は,SFR についての二つの細分箇条からなる,セキュリティ要件の根拠を含んでいる。

・  どの SFR が TOE のどのセキュリティ対策方針に対応しているのかを示す追跡。

・  その TOE の全てのセキュリティ対策方針が,

それらの SFR によって有効に対応していることを示す,

正当化論拠の集まり。

A.9.1.2.1 SFR

と TOE のセキュリティ対策方針との間の追跡 

追跡は,SFR が TOE のセキュリティ対策方針までどのように遡るかを示す。この追跡では,次の二つの

規則に従わなければならない。

a)

見せかけの SFR の禁止:各 SFR は,少なくとも一つのセキュリティ対策方針まで遡る。

b)  TOE

のセキュリティ対策方針に関する完全性:TOE のセキュリティ対策方針のそれぞれについて,

そこまで遡る少なくとも一つの SFR がある。

複数の SFR が遡った先が同じ TOE のセキュリティ対策方針になることがあるが,その場合,これらの

セキュリティ要件の組合せがその TOE のセキュリティ対策方針に対応することを示す。

A.9.1.2.2 

追跡の正当化の提供 

セキュリティ要件の根拠では,追跡が有効であることを示す。つまり,特定の TOE のセキュリティ対策

方針まで遡る全ての SFR が達成された場合,

その TOE のセキュリティ対策方針は対応されることを示す。

この追跡の正当化においては,関連する SFR を達成することによる,TOE のセキュリティ対策方針への対

応を分析し,実際に対応されるという結論に導く。


52

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

SFR

が TOE のセキュリティ対策方針と非常に似ているような状況では追跡の正当化が非常に簡単にな

ることがある。

A.9.2 

セキュリティ保証要件(SAR)

SAR

は TOE がどのように評価されるかについての記述である。この記述は次の理由によって規格化さ

れた表現を使用する。

・ TOE がどのように評価されるかについての正確な記述を提供するため。規格化された表現を使用する

ことで,正確に記述するのを助け,曖昧さを避ける。

・  二つの ST 間での比較を可能とするため。異なる ST 作成者が,評価について説明するときに異なる用

語を使用するかもしれないが,

標準化された表現では同じ用語及び概念を使用することが求められる。

これによって比較が容易になる。

この規格化された表現は,この規格類第 3 部で定義されているコンポーネントの集まりとして定義され

る。幾つかの例外は存在するが,この表現の使用は必須である。この規格類は,この表現を次の二つの方

法で支援している。

a)

操作を提供することによる。操作とは,ST 作成者が,SAR を変更する仕組みのことである。この規

格類には,割付け,選択,繰返し及び詳細化の四つの操作がある。これらは 7.1 で,より詳しく記述

している。

b)

依存性を提供することによる。依存性とは,SAR への,より完全な書換えを支援する仕組みのことで

ある。この規格類第 3 部の表現では,一つの SAR は他の SAR への依存性をもつことができる。これ

は,ST がその SAR を使用する場合に,他の SAR を使用する必要性を意味する。したがって,必要な

SAR

を含めることで,ST 作成者が入れ忘れないようにし,ST の完全性を改善する。依存性は 7.2 で,

より詳しく記述している。

A.9.3 SAR

及びセキュリティ要件の根拠 

ST

は,この SAR の組合せがなぜ適切であると考えたかを説明する,セキュリティ要件の根拠も含んで

いる。この説明に関する特定の要件はない。この説明の目的は,ST の読者がこの特定の組合せが選ばれた

理由を理解できるようにすることである。

適切でない例としては,セキュリティ課題定義が非常に高い能力の脅威エージェントに言及している一

方で,SAR に含まれるセキュリティ保証要件の一つである AVA_VAN のレベルが低い(又は AVA_VAN が

ない)が挙げられる。

A.9.4 

セキュリティ要件:結論 

ST

のセキュリティ課題定義では,セキュリティ課題は脅威,OSP 及び前提条件から成り立つものと定義

される。ST のセキュリティ対策方針の箇条では,解決策は二つの分割式解決策の形式で提供される。

・ TOE のセキュリティ対策方針

・  運用環境のセキュリティ対策方針

さらに,全てのセキュリティ対策方針が達成された場合,セキュリティ課題が解決されることを示す,

セキュリティ対策方針の根拠が提供される。全ての脅威が対抗され,全ての OSP が実施され,全ての前提

条件が確認される。


53

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

図 A.3−セキュリティ課題定義,セキュリティ対策方針及びセキュリティ要件の間の関係 

ST

のセキュリティ要件の箇条では,TOE のセキュリティ対策方針は SFR に書き換えられ,全ての SFR

が満たされる場合,全ての TOE のセキュリティ対策方針が達成されることを示す,セキュリティ要件の根

拠が提供される。さらに,SAR の集まりは,これらの SAR を選択した理由とともに,TOE がどのように

評価されるのかを示すために提供される。上記の全ての内容から,次のことがいえる。

全ての SFR 及び SAR を満足し,運用環境のセキュリティ対策方針全てが達成される場合,ASE_SPD で

定義されるセキュリティ課題が解決されるという保証が得られる。すなわち,全ての脅威が対抗され,全

ての OSP が実施され,全ての前提条件が確認される。これを

図 A.3 に示す。

得られる保証の程度は SAR によって定義され,この保証の程度が十分であるかどうかは,これらの SAR

を選択した理由によって明らかにされる。

A.10 TOE

要約仕様(ASE_TSS)

TOE

要約仕様の目的は,TOE がどのように全ての SFR を満たすかに関する記述を TOE の潜在的な利用

者に対して提供することである。この目的のために TOE が使用する一般的な技術的なメカニズムを,TOE

要約仕様は提供する。潜在的な利用者が TOE の一般的な形態及び実装を理解できる程度に詳細に記述する。

例えば,TOE がインターネットに接続された PC であり,SFR が認証を指定するセキュリティ機能要件

の一つである FIA_UAU.1 を含んでいる場合,TOE 要約仕様は,パスワード,トークン,こう(虹)彩走

査など,この認証がどのように行われるかを記述する。SFR を満たすために TOE が使用する適用可能な標

準のような,詳しい情報を提供してもよいし,より詳細な記述を提供してもよい。

A.11 ST

を使用して回答できる質問 

評価の後,ST には“何が評価されたのか”が示される。この役割において,ST は,TOE の開発者又は

販売代理業者と TOE の潜在的な利用者との間の合意のために役立つ。したがって,ST は次の質問に回答

 
 
 
 
 
 
 
 

脅威

 
 
 
 
 

TOE

セキュリティ

対策方針

 
 
 
 
 
 
 

運用環境の

セキュリティ

対策方針

 
 
 
 
 
 
 

前提条件

 

組織の

セキュリティ方針

 
 
 
 
 

セキュリティ

機能要件

(SFR)

 
 
 
 

セキュリティ

保証要件

(SAR)


54

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

することができる。

a)

多くの既存の ST 及び TOE の中から,必要な ST 及び TOE を見つけるにはどうしたらよいか。この質

問は,数段落からなる TOE の簡潔な要約を提供する,TOE 概要によって回答できる。

b)

この TOE は,当方の既存の IT 基盤に適合するか。この質問は,TOE を動作させるために必要とする

主要な,ハードウェア要素・ファームウェア要素・ソフトウェア要素を識別する,TOE 概要によって

回答できる。

c)

この TOE は,当方の既存の運用環境に適合するか。この質問は,TOE が機能するために運用環境に

配置する全ての制約を識別する,運用環境のセキュリティ対策方針によって回答できる。

d)

(関心をもった読者にとって)TOE は何をするものか。この質問は,数段落からなる TOE の簡潔な

要約を提供する,TOE 概要によって回答できる。

e)

(潜在的な利用者にとって)TOE は何をするものか。この質問は,TOE の要約(数ページ)を提供す

る,TOE 記述によって回答できる。

f)

(技術的に)TOE は何をするものか。この質問は,TOE が使用するメカニズムの高レベルな(要求仕

様レベルの)記述を提供する,TOE 要約仕様によって回答できる。

g)

(専門家にとって)TOE は何をするものか。この質問は,抽象的であり高度に技術的な記述を提供す

る SFR と,追加の詳細を提供する TOE 要約仕様とによって回答できる。

h)

政府又は組織によって定義された課題を TOE は処理できるか。政府又は組織が,解決策を定義するた

めに,パッケージ及び/又は PP を定義している場合に,ST が適合する全てのパッケージ及び PP を

記載する ST の適合主張の箇条において,回答を見つけることができる。

i)

(専門家にとって)TOE は当方のセキュリティ課題を処理できるか。TOE が対抗する脅威は何である

か。どの組織のセキュリティ方針がそれを実施するのか。運用環境に関してどのような前提条件があ

るのか。これらの質問は,セキュリティ課題定義によって回答できる。

j) TOE

はどの程度,信頼できるか。この質問は,TOE を評価するのに使用された保証レベル,つまり

TOE

の正確性について評価が提供する信頼を記述した,セキュリティ要件の箇条にある SAR によっ

て回答できる。

A.12 

低保証のセキュリティターゲット 

ST

を書くことはさ(些)細な仕事ではなく,特に低保証評価では,評価全体で開発者と評価者とによっ

て費やされた総努力の大半かもしれない。このため,低保証の ST を書いてもよい。

この規格類は,EAL 1 評価のための低保証の ST の使用を許すが,EAL 2 以上では許さない。低保証の

ST

は,低保証の PP(

附属書 参照)にだけ適合主張できる。全項目を含む通常の非低保証 ST が,低保

証の PP への適合を主張してもよい。低保証の ST は,通常の非低保証 ST と比較して,次に示すように,

かなり内容が少ない。

・  セキュリティ課題定義を記述する必要はない。

・ TOE のセキュリティ対策方針を記述する必要はないが,運用環境のためのセキュリティ対策方針は記

述しなければならない。

・ ST にセキュリティ課題定義がないので,セキュリティ対策方針の根拠を記述する必要はない。

・ TOE のセキュリティ対策方針が ST にないので,セキュリティ要件の根拠は,満たしていない依存関

係を正当化するだけでよい。

したがって,低保証 ST で書かなければならないものは次のとおりである。


55

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

a) TOE

及び ST への参照。

b)

適合主張。

c)

次の叙述的記述。

1) TOE

概要

2) TOE

記述

3) TOE

要約仕様

d)

運用環境のセキュリティ対策方針。

e) SFR

,SAR(拡張したコンポーネント定義を含む。

)及びセキュリティ要件根拠(満たされない依存性

がある場合だけ。

低保証の ST における,簡略化された内容を

図 A.4 に示す。

図 A.4−低保証セキュリティターゲットの内容 

A.13 ST

内での他の規格の参照 

幾つかの場合,ST 作成者は,特定の暗号規格又はプロトコルのような外部規格の参照を迫られるときが

ある。この規格類はこれを行う三つの方法を提供している。

a)

組織のセキュリティ方針(又はその一部)として行う方法。

例えば,政府規格にパスワードをどのように選択するかについての規定が存在する場合,これを ST

の組織のセキュリティ方針に指定してもよい。

例えば,TOE の各利用者が各々のパスワードを選ぶ必要がある場合には,環境の対策方針に通じ,

TOE

がパスワードを生成する場合には,TOE のセキュリティ対策方針,及び適切な SFR(FIA クラス)

に通じる。いずれの場合も,TOE のセキュリティ対策方針及び SFR が(又は環境の対策方針が)OSP

セキュリティターゲット 
(低保証)

ST

参照

TOE

参照

TOE

概要

TOE

記述

ST

概説

CC

適合主張

PP

主張,パッケージ主張

適合根拠

適合主張

運用環境のセキュリティ方針

セキュリティ対策方針

拡張コンポーネント定義

拡張コンポーネント定義

TOE

要約仕様

TOE

要約仕様

セキュリティ要件

セキュリティ機能要件 
セキュリティ保証要件 
セキュリティ要件根拠


56

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

を満たすのに適切であることを,開発者の根拠が示す必要がある。OSP が SFR によって実装されてい

る場合,評価者は,次に示すように妥当性を検査しなければならない(そしてこのために規格を調査

する場合がある。

b) SFR

の詳細化に使用される技術的規格(例えば,暗号の規格)として行う方法。

この場合,規格への適合は TOE による SFR の実現の一部であり,規格の全文が SFR の一部である

かのように扱われる。したがって,この適合は SFR への他の適合と同様に決定される。すなわち,ADV

クラス及び ATE クラスによる評価中に,SFR が TOE において完全かつ十分に実装されているかどう

かが,設計分析とテストとで分析される。規格の一部分だけを参照する場合,SFR の詳細化によって,

誤解が生じないようにその部分を示す。

c) TOE

要約仕様で言及する技術的規格(例えば,暗号の規格)として行う方法。

TOE

要約仕様は SFR がどのように実現されているかの説明として考えられるだけであって,SFR 又

は ADV 証拠資料のようには厳密な実装要件としては使用されない。したがって,TSS が技術的規格

を参照しており,ADV 証拠資料に反映されていない場合,評価者は矛盾を検出することがあるが,規

格を満たしていることを試験するための評価アクティビティはない。


57

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

附属書 B

(参考)

プロテクションプロファイルの仕様

B.1 

この附属書の目的及び構造 

この附属書の目的は,プロテクションプロファイル(PP)の概念を説明することである。この附属書で

は,APE 基準の定義は行わない。APE 基準の定義は,この規格類第 3 部にある。詳述は ISO/IEC 15408-3

の E.1[3]の中に見つけることができる。

PP

と ST とは非常に重複しているため,この附属書では PP と ST との相違点に重点を置く。ST と PP と

の間で同一の事項については,

附属書 で説明する。この附属書は,次の四つの主要な部分から構成され

ている。

a) PP

に記載しなければならない内容。これについては,B.2 で概要を述べ,B.4 から B.9 まででより詳

細に説明する。これらの箇条では,PP 必須の記載内容及び各内容間の相互関係について説明し,例を

示す。

b) PP

の望ましい使用法。これについては,B.3 で概要を示す。

c)

低保証 PP。低保証 PP は,PP の記載内容を減らした PP である。これについては,B.11 で詳細に説明

する。

d)

標準への適合の主張。B.12 では,TOE が特定の標準を満たしていることを,PP 作成者が主張する方

法について説明する。

B.2 PP

の必須の内容 

図 B.1 は,この規格類第 3 部に規定する PP 必須記載内容を示す。図 B.1 は PP の構成に関する概略図と

して使用してもよいが,別の構成であってもよい。例えば,セキュリティ要件根拠が特に長くなる場合は,

セキュリティ要件の箇条の代わりに,PP の附属書にそれを記述することができる。PP の各箇条及びそれ

らの箇条における記載内容について,次に手短に述べ,B.4 から B.9 まででより詳細に説明する。PP には

次の事項を記述する。

a)  PP

概説  TOE 種別の叙述的記述を含む。

b)

適合主張  PP が,いずれかの PP 及び/又はパッケージへの適合を主張するかどうかを示し,適合す

る場合には,どの PP 及び/又はパッケージに適合しているかを示す。

c)

セキュリティ課題定義  脅威,組織のセキュリティ方針(OSP)及び前提条件を示す。

d)

セキュリティ対策方針  セキュリティ課題を,TOE のセキュリティ対策方針及び TOE の運用環境に

分割した解決方法を示す。

e)

拡張コンポーネント定義  (この規格類の第 2 部又は第 3 部に含まれていない)新しいコンポーネン

トを定義することができる。これらの新しいコンポーネントは,拡張機能要件及び拡張保証要件を定

義するために必要とされる。

f)

セキュリティ要件  TOE のセキュリティ対策方針から規格化された表現への書き換えたものを示す。

この規格化された表現は,SFR の形式をとる。また,B.2 では SAR を定義する。

PP

の記載内容を減らした低保証 PP も存在する。これについては,B.11 で詳細に説明する。この例外を

除いて,B.1 から B.12 までは,上記の全項目を含む PP を想定している。


58

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

図 B.1−プロテクションプロファイルの内容 

B.3 PP

の使用 

B.3.1 

望ましい PP の使用法 

一般に,PP は利用者コミュニティ,行政機関,又は開発者グループによって必要とされるセキュリティ

の共通セットを定義する文書である。PP は,このセットを参照する手段を利用者に提供し,このような必

要性を背景とする将来の評価を容易にする。したがって,PP は一般に次のものとして使用される。

a)

特定の利用者又は利用者グループに対する要件仕様の一部。この利用者又は利用者グループは,PP を

満たしている場合にだけ特定の種別の IT 製品の購入を検討する。

b)

特定の行政機関による規制の一部。この行政機関は,PP を満たしている場合にだけ特定の種別の IT

製品の使用を許可する。

c) IT

製品開発者のグループによって定義される基準レベル。この開発者グループは,生産するこの種別

の全ての IT 製品がこの基準レベルを満たすことに合意する。

上記の例はその他の用途を排除するものではない。

B.3.2 

望ましくない PP の使用法 

(PP の多くの役割の中から)PP が果たさない方がよい三つの役割を次に示す。

a)

詳細な仕様:PP は,比較的抽象レベルの高いセキュリティ仕様を記述する。一般に,PP には詳細な

プロトコル仕様,詳細なアルゴリズム及び/又は機構の詳細な説明,詳細にわたる運用についての長

い説明などを含まないほうがよい。

PP

参照

TOE

概要

 
 

PP

概説

 
 
 

プロテクションプロファイル

CC

適合主張

PP

主張,パッケージ主張

適合根拠 
適合記述

 
 

適合主張

脅威 
組織のセキュリティ方針 
前提条件

 
 

セキュリティ課題定義

TOE

のセキュリティ対策方針

運用環境のセキュリティ対策方針 
セキュリティ対策方針根拠

 
 

セキュリティ対策方針

拡張コンポーネント定義

 
 

拡張コンポーネント定義

セキュリティ機能要件

セキュリティ保証要件 
セキュリティ要件根拠

 
 

セキュリティ要件


59

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

b)

完全な仕様:PP は,セキュリティ仕様を記述したものであって,全体の仕様ではない。セキュリティ

に関係する場合を除いて,相互運用性,物理的な寸法及び重さ,定格電圧などの特性は,PP の一部分

でない方がよい。これは一般に,PP はそれ自体が完全な仕様ではなく,完全な仕様の一部分であって

も差し支えないということを意味する。

c)

単一製品の仕様:ST とは異なり,PP は単一の製品ではなく,IT 製品の特定の種別について記述する

ことを目的とする。単一の製品だけが目的の場合は,ST を使用することが望ましい。

B.4 PP

概説(APE_INT) 

PP

概説では,次の二つの抽象レベルについて叙述的な方法で TOE を説明する。

a) PP

参照。PP の識別情報を提供する。

b) TOE

概要。TOE を簡潔に説明する。

B.4.1 PP

参照 

PP

は,特定の PP を指し示す明確な PP 参照を含む。典型的な PP 参照は,名称,バージョン,作成者及

び発行日から構成される。

“Atlantean Navy CablePhone Encryptor PP,バージョン 2b,アトラス海軍調達局,

2003

年 4 月 7 日”は,PP 参照の記述例である。参照は,異なる PP 間及び同じ PP の異なるバージョン間

で区別できるように,一意にしなければならない。

PP

参照は,PP に索引を付け,これらを参照すること及び PP のリストにこれらを組み込むことを容易に

する。

B.4.2 TOE

概要 

TOE

概要は,セキュリティの必要性を満たし,自らが使用するハードウェア,ソフトウェア及びファー

ムウェアで稼動する TOE を見つけるために,評価済み製品のリストを調べようとする,TOE の潜在的な

利用者のためのものである。

TOE

概要は,TOE の設計又は既存製品の改造で PP を使用することがある開発者も対象としている。

TOE

概要の一般的な長さは,数段落である。このため,TOE 概要では,TOE の使用方法及びその主要

なセキュリティ機能の特徴について簡潔に説明し,TOE の種別及び TOE が必要とする TOE 以外の主要な

ハードウェア,ソフトウェア及びファームウェアが何であるかを示す。

B.4.2.1 TOE

の使用方法及び主要なセキュリティの特徴 

TOE

の使用方法及び主要なセキュリティの特徴に関する記述は,TOE が備えるべき機能及び TOE の用

途についてごく一般的な知識を与えることを目的とする。この箇条は,

(潜在的な)TOE 利用者のために,

業務運用の点から,TOE の使用方法及び主要なセキュリティの特徴について,TOE 利用者が分かる表現を

使用して記述するのが望ましい。この記述例を次に示す。

“Atlantean Navy CablePhone Encryptor”は,Atlantean Navy CablePhone システムを通じて船舶間で秘密情

報の通信を実現すべき暗号化デバイスである。このため,最低 32 人の利用者及び最低 100 Mb/s の暗号化

速度をサポートするのが望ましい。これは,船舶間の相互通信及びネットワーク全体のブロードキャスト

の両方を実現するのが望ましい。

B.4.2.2 TOE

種別 

TOE

概要では,ファイアウォール,VPN ファイアウォール,スマートカード,暗号化モデム,イントラ

ネット,ウェブサーバ,データベース,ウェブサーバ及びデータベース,LAN,ウェブサーバ及びデータ

ベースを伴う LAN などの,TOE の一般的な種別を示す。


60

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

B.4.2.3 

必要とする TOE 以外のハードウェア,ソフトウェア及び/又はファームウェア 

他の IT に依存しない TOE もあるが,多くの TOE(特にソフトウェア TOE)は,TOE 以外の追加のハー

ドウェア,ソフトウェア及び/又はファームウェアに依存する。後者の場合,TOE 概要は,TOE 以外のハ

ードウェア,ソフトウェア及び/又はファームウェアを識別する必要がある。

プロテクションプロファイルは特定の製品について記述されるものではないため,多くの場合,必要と

するハードウェア,ソフトウェア及び/又はファームウェアについて一般的な考え方だけを示すことがで

きる。一部の場合,例えば,プラットフォームが既に確認されている特定の顧客向けの要件仕様などの場

合,

(はるかに)多くの具体的な情報が提供されることがある。

ハードウェア,ソフトウェア及び/又はファームウェア識別の例を次に示す。

・  なし(完全なスタンドアロン TOE)

・  汎用 PC で動作している Yaiza 3.0 オペレーティングシステム。

・ CleverCard

SB2067

集積回路。

・ QuickOS スマートカードオペレーティングシステムのバージョン 2.0 を実行する CleverCard SB2067 回

路。

・ 20xx 年 xx 月に設置予定の省庁 LAN。

B.5 

適合主張(APE_CCL) 

B.5

では,PP が他の PP 及びパッケージとどのように適合するかを記述する。これは,適合記述だけを

除いて,ST の適合主張の A.5 と同じである。

PP

の適合記述では,ST 及び/又はその他の PP がその PP にどのように適合しなければならないかを示

す。PP 作成者は,

“正確”適合又は“例証”適合のいずれを要求するかを選択する。これに関するより詳

細については,

附属書 を参照。

B.6 

セキュリティ課題定義(APE_SPD) 

B.6

は,ST のセキュリティ課題定義の A.6 と同じである。

B.7 

セキュリティ対策方針(APE_OBJ) 

B.7

は,ST のセキュリティ対策方針の A.7 と同じである。

B.8 

拡張コンポーネント定義(APE_ECD) 

B.8

は,ST の拡張コンポーネントの A.8 と同じである。

B.9 

セキュリティ要件(APE_REQ) 

B.9

は, ST のセキュリティ要件の A.9 と同じである。ただし,PP において操作を完了する際の規則は,

ST

において操作を完了する際の規則とはやや異なっている点に注意する。これについては,7.1 でより詳

細に説明する。

B.10 TOE

要約仕様 

PP

には,TOE 要約仕様は含まれない。


61

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

B.11 

低保証プロテクションプロファイル 

通常の PP(すなわち,全ての内容を含む PP)に対する低保証 PP の関係は,通常の ST に対する低保証

ST

の関係と同じである。つまり,低保証 PP は,次の内容から構成される。

a) PP

概説。PP 参照及び TOE 概要から構成される。

b)

適合主張。

c)

運用環境のセキュリティ対策方針。

d) SFR

及び SAR(拡張コンポーネント定義を含む。

)及びセキュリティ要件根拠(依存性が満たされて

いない場合だけ。

低保証 PP は,低保証 PP への適合だけを主張することができる(B.5 を参照)

。非低保証 PP は,低保証

PP

への適合を主張することができる。低保証 PP の簡略化された内容を

図 B.2 に示す。

図 B.2−低保証プロテクションプロファイルの内容 

B.12 PP

での他の標準の参照 

B.12

は,ST の標準に関する A.13 と同じである。ただし,PP には TOE 要約仕様がないので,A.13 c)  

除く。

SFR

の中で規格を参照することが,

(その規格の規模及び複雑さと,要求される保証レベルによっては)

PP

を満たす TOE を開発している開発者に大きな負担をかける可能性があり,規格への適合を評価するた

めの代替的な(この規格類に関連しない)方法を採用することが適切な場合があることに,PP 作成者は留

意する。

PP

参照

TOE

概要

 
 

PP

概説

プロテクションプロファイル 
(低保証)

CC

適合主張

PP

主張,パッケージ主張

適合根拠 
適合記述

 
 

適合主張

拡張コンポーネント定義

 
 

拡張コンポーネント定義

セキュリティ機能要件

セキュリティ保証要件 
セキュリティ要件根拠

 
 

セキュリティ要件

運用環境のセキュリティ対策方針

 
 

セキュリティ対策方針


62

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

附属書 C 
(参考)

操作の指針

C.1 

はじめに 

この規格で示すようにプロテクションプロファイル及びセキュリティターゲットは定義済みセキュリテ

ィ要件を含むとともに,PP 作成者及び ST 作成者にある状況でコンポーネントを拡張する能力を与える。

C.2 

操作の例 

7.1

では 4 種類の操作について示した。これら操作の例を次に示す。

C.2.1 

繰返し操作 

7.1.1

で示したように,

繰返し操作は全てのコンポーネントに対して行える。

PP

作成者及び ST 作成者は,

同じコンポーネントに複数の要件を含めることで繰返し操作を実行できる。繰返しを行った各々のコンポ

ーネントは,繰返しを行った他のどのコンポーネントとも異なる。これは,異なる方法で割付けと選択と

を行ったり,異なる方法で詳細化を行っているからである。異なる繰返しは,これらのセキュリティ要件

への/からの理由付け及び遡りが容易になるように,

一意に特定できるのが望ましい。

この典型例として,

二つの異なる暗号アルゴリズムを実装するために 2 回繰返しを行った FCS_COP.1  の例を挙げることがで

きる。各々の繰返しを一意に特定できる例として,次のものがある。

・  暗号操作(RSA 及び DSA  署名)[FCS_COP.1(1)]

・  暗号操作[TLS/SSL:対称鍵操作][FCS_COP.1(2)]

C.2.2 

割付け操作 

7.1.2

で示したように,割付け操作は当該コンポーネントのパラメタ付きエレメントを PP 作成者及び ST

作成者がパラメタを決定する場合に行われる。そのパラメタは,制限のない変数であるか,又はその変数

を特定範囲の値に狭めたものであってもよい。

エレメントへの割付け操作例として,次のものがある。

FIA_AFL.1.2

“不成功の認証回数が既定値に達するかそれを超えた場合,TSF は[割付け:アクションの

リスト]をしなければならない。

C.2.3 

選択操作 

7.1.3

で示したように,選択操作は,当該コンポーネントが複数の選択肢を含み,PP 作成者及び ST 作成

者によって選択される場合に行われる。

選択の例として,次のものがある。

FPT_TST.1.1

“TSF は,正常動作を実証するために,

[選択:初期立上げ中,通常運用中に定期的に,権

限をもった利用者の要求時に,及び条件(割付け:自己テストが作動すべき条件)のときに]自己テスト

一式を実行しなければならない。

C.2.4 

詳細化操作 

7.1.4

で示したように,詳細化操作は,全ての要件で行われる。PP 作成者及び ST 作成者は当該要件を書

き換えることで詳細化を行う。

詳細化の例として,次のような書換えがある。

FIA_UAU.2.1

“TSF は,その利用者を代行する他の TSF 仲介アクションを許可する前に,各利用者に認


63

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

証が成功することを要求しなければならない。

”を次のようにする。

FIA_UAU.2.1

“TSF は,その利用者を代行する他の TSF 仲介アクションを許可する前に,各利用者にユ

ーザ名とパスワードとによる認証が成功することを要求しなければならない。

PP

作成者及び ST 作成者に許されるこの規則の唯一の例外は,

SFR

を全てではなく一部のサブジェクト,

オブジェクト,操作,セキュリティ属性,及び/又は外部エンティティに適用することである。このよう

な具体例としては,次のものがある。

FIA_UAU.2.1

“TSF は,その利用者を代行する他の TSF 仲介アクションを許可する前に,各利用者に認

証が成功することを要求しなければならない。

”を次のようにする。

FIA_UAU.2.1

“TSF は,その利用者を代行する他の TSF 仲介アクションを許可する前に,インターネッ

トからの各利用者に認証が成功することを要求しなければならない。

第 2 に実施される詳細化規則は,基となるコンポーネントの範囲に収まっていなければならないことで

ある。例えば,監査要件コンポーネントに漏えい(洩)電磁波防止のための特別な要素を追加して詳細化

することは許されない。

特殊な詳細化として編集上の詳細化があり,要件の小修整,すなわち言語の文法を順守するため,読者

により分かりやすくするため,行われることがある。この小修整で要件の意味を変更してはならない。編

集上の詳細化として次のようなものがある。

FPT_FLS.1.1

“TSF は,次の種別の障害が生じたときはセキュアな状態を保持しなければならない:CPU

故障。

”を次のようにする。

FPT_FLS.1.1

“TSF は,次の種別の障害が生じたときはセキュアな状態を保持しなければならない:1CPU

の故障。

,又は更に,次のようにする。

FPT_FLS.1.1

“TSF は,一つの CPU に障害が生じたときにセキュアな状態を保持しなければならない。

C.3 

コンポーネントの構成 

この規格類は,この規格類の第 2 部及び第 3 部にあるコンポーネントを次に示す階層構造としている。

・  クラス          これは次のものからなる。

・  ファミリ        これは次のものからなる。

・  コンポーネント  これは次のものからなる。

・  エレメント

この,クラス,ファミリ,コンポーネント,及びエレメントへの階層構造は,消費者,開発者及び評価

者が目当てのコンポーネントを見つける手助けとなる。この規格類は,機能コンポーネント及び保証コン

ポーネントに同じ階層構造形態を採用し,同じ構成と用語とを用いている。

C.3.1 

クラス 

クラスの例として FIA クラスがあるが,これは利用者の識別,利用者の認証,利用者及びサブジェクト

の結合に焦点を当てている。

C.3.2 

ファミリ 

ファミリの例として FIA クラスに属する利用者の認証(FIA_UAU)がある。このファミリは利用者の

認証を専門とする。

C.3.3 

コンポーネント 

コンポーネントの例として  偽造されない認証(FIA_UAU.3)があり,偽造されない利用者の認証を専

門とする。


64

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

C.3.4 

エレメント 

エレメントの例として FIA_UAU.3.2 があり,複写した認証データの阻止を専門とする。

C.4 

拡張コンポーネント 

C.4.1 

拡張コンポーネントの定義方法 

PP

作成者及び ST 作成者が拡張コンポーネントを定義するとき,同規格類の既存のコンポーネントと同

様に定義しなければならない。明瞭,曖昧でなく,評価可能(これは当該コンポーネントに立脚する要件

が TOE に対して体系的に例証可能であること)でなければならない。拡張コンポーネントは同規格類の既

存のコンポーネントと同様の命名法,表現法,及び詳細度でなければならない。

PP

作成者及び ST 作成者は拡張コンポーネントを定義するとき,適用する依存性を含めることを忘れて

はならない。

起こり得る依存性の例として,次に示す。

a)

拡張コンポーネントが監査を参照する場合,FAU クラスへの依存性を含めなければならない。

b)

拡張コンポーネントがデータにアクセスしたり,データを改変したりする場合,FDP_ACC ファミリ

への依存性を含まなければならない。

c)

拡張コンポーネントが特殊な設計記述を含む場合,それにふさわしい ADV ファミリ(例えば,機能

仕様)への依存性を含まなければならない。

拡張機能コンポーネントの場合,PP 作成者及び ST 作成者は,この規格類第 2 部の既存コンポーネント

と同様に,適用可能な監査と関連操作の情報とをそのコンポーネントの定義に含めなければならない。拡

張保証コンポーネントの場合,PP 作成者及び ST 作成者は,ISO/IEC 18045 で提供される手法と同様の当

該コンポーネントを評価する手法を提供しなければならない。

拡張コンポーネントを,既存のファミリに増設してもよいがその場合,PP 作成者及び ST 作成者は増設

に使われたファミリがどのように変更されたかを記述しなければならない。そのとき,それらのコンポー

ネントが既存のファミリになじまない場合,新規ファミリを作ってその中に収めなければならない。新規

ファミリはこの規格類の既存のファミリと同じように定義しなければならない。


65

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

附属書 D 
(参考)

PP

適合

D.1 

はじめに 

PP

は ST へのひな形として使うよう意図されている。つまり,PP は利用者の要求を記述し,その PP に

適合する ST は PP で記述される要求を満たす TOE を記述する。PP は他の PP へのひな形として使用する

ことも可能であることに注意されたい。これは,ST と PP との関係に酷似している。この附属書は ST/PP

関係だけを記述するが,PP/PP 関係に対しても適用可能である。

この規格類は,いかなる部分適合も許可しない。したがって,例えば PP 適合を主張する場合,PP 又は

ST

は,参照する単一の PP 又は複数の PP に完全に適合していなければならない。しかし,適合には 2 種

類(

“正確”適合及び“例証”適合)あり,許可される適合のタイプを PP に記述する。すなわち,PP は,

ST

への PP 適合の許可されるタイプについて記述する(PP の適合記述に示す。B.5 を参照。

。ST が PP 例

証適合を主張できるのは,PP 適合を明示的に記述している場合で,それに対し,ST は,どの PP に対して

も正確適合しているといってよい。ST が適合を主張する PP に対して,正確適合と例証適合とを区別して

適用できる。つまり,ST はある PP 群に正確適合し,他の PP 群に例証適合することがある。言い換える

と,PP が明示的に例証適合を許しているなら,ST はその場合に限り PP に例証適合しているといえる。

ある PP への適合は,適合を主張する PP 又は ST が(そして,もし ST が評価完了した製品のものであ

るならばその製品も)当該 PP の要件を全て満たすことを意味する。

公開される PP は,通常,例証適合を要求する。これは PP に適合を主張する ST は PP に記述される一般

的なセキュリティ課題に対する解を提供しなければならないことを意味するが,PP の記述と同等か又は制

限をかけたいかなる方法でもよい。この規格類での“同等か制限をかけた”という用語の定義は長くなる

が,原則論では,ST が PP と同等以上の制約を TOE に課し,TOE の運用環境には PP と同等以下の制約で

済ませることができるなら,たとえ PP 及び ST が全く異なるエンティティについて異なる記述を議論し,

異なる概念を使用していようと,容認されることである。

D.2 

正確適合 

正確適合は,PP の要件が満たされていること及び ST が PP の実装となっていることの証拠を求める PP

作成者のためのものである(ST は,PP の要件より広がる。

。要するに,ST には,PP と同等以上に TOE

が行うことを規定し,PP と同等以下に運用環境が行うことを規定する。

正確適合の典型的な使用法は,製品のセキュリティ要件が PP で既定されるとおりに正確に一致するも

のから調達を行うことである。

PP

に正確適合する ST の例証化では,PP に記載されている制約に更に制約を追加してもよい。

D.3 

例証適合 

例証適合は,ST が PP で記述される一般セキュリティ問題への適した解決となっていることの証拠を求

める PP 作成者に向けられたものである。正確適合では PP と ST との間には明確な包含関係があるが,例

証適合の場合,その関係はそれほどはっきりしない。一般的な表現をすれば,ST は PP と同等か,より限

定的となっていなければならない。


66

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

附属書 JA

(参考)

ISO/IEC 15408-2

  Part 2: Security functional components

第 2 部:セキュリティ機能コンポーネント

適用範囲 

この規格類第 2 部は,セキュリティ評価の実施に必要なセキュリティ機能コンポーネントを規定してい

る。そして,多くの IT 製品に共通なセキュリティ機能要件を満足する機能コンポーネントのカタログを記

述している。

引用規格   

ISO/IEC 15408-2:2008

の 2(Normative reference)による。

定義及び用語   

ISO/IEC 15408-2:2008

の 3(Terms and definitions,symbols and abbreviated terms)による。

概要   

ISO/IEC 15408-2:2008

の 4(Overview)による。

機能要件の枠組み   

ISO/IEC 15408-2:2008

の 5(Functional requirements paradigm)による。

セキュリティ機能コンポーネント   

ISO/IEC 15408-2:2008

の 6(Security functional components)による。

クラス FAU:セキュリティ監査   

ISO/IEC 15408-2:2008

の 7(Class FAU:Security audit)による。

クラス FCO:通信   

ISO/IEC 15408-2:2008

の 8(Class FCO:Communication)による。

クラス FCS:暗号支援   

ISO/IEC 15408-2:2008

の 9(Class FCS:Cryptographic support)による。

10 

クラス FDP:利用者データの保護   

ISO/IEC 15408-2:2008

の 10(Class FDP:User data protection)による。

11 

クラス FIA:識別及び認証   

ISO/IEC 15408-2:2008

の 11(Class FIA:Identification and authentication)による。


67

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

12 

クラス FMT:セキュリティ管理   

ISO/IEC 15408-2:2008

の 12(Class FMT:Security management)による。

13 

クラス FPR:プライバシ   

ISO/IEC 15408-2:2008

の 13(Class FPR:Privacy)による。

14 

クラス FPT:評価対象のセキュリティ機能保護   

ISO/IEC 15408-2:2008

の 14(Class FPT:Protection of the TSF)による。

15 

クラス FRU:資源利用   

ISO/IEC 15408-2:2008

の 15(Class FRU:Resource utilisation)による。

16 

クラス FTA:評価対象へのアクセス   

ISO/IEC 15408-2:2008

の 16(Class FTA:TOE access)による。

17 

クラス FTP:高信頼パス及びチャネル   

ISO/IEC 15408-2:2008

の 17(Class FTP:Trusted path/channels)による。

附属書 A(規定)セキュリティ機能要件アプリケーションに関する備考   

ISO/IEC 15408-2:2008

の Annex A (normative)  Security functional requirements application notes  による。

附属書 B(規定)機能クラス,ファミリ及びコンポーネント   

ISO/IEC 15408-2:2008

の Annex B (normative)  Functional classes, families, and components  による。

附属書 C(規定)クラス FAU:セキュリティ監査   

ISO/IEC 15408-2:2008

の Annex C (normative)  Class FAU: Security audit  による。

附属書 D(規定)クラス FCO:通信   

ISO/IEC 15408-2:2008

の Annex D (normative)  Class FCO: Communication  による。

附属書 E(規定)クラス FCS:暗号支援   

ISO/IEC 15408-2:2008

の Annex E (normative)  Class FCS: Cryptographic support  による。

附属書 F(規定)クラス FDP:利用者データの保護   

ISO/IEC 15408-2:2008

の Annex F (normative) Class FDP: User data protection  による。

附属書 G(規定)クラス FIA:識別及び認証   

ISO/IEC 15408-2:2008

の Annex G (normative)  Class FIA:Identification and authentication  による。


68

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

附属書 H(規定)クラス FMT:セキュリティ管理   

ISO/IEC 15408-2:2008

の Annex H (normative)  Class FMT: Security management  による。

附属書 I(規定)クラス FPR:プライバシ   

ISO/IEC 15408-2:2008

の Annex I (normative)  Class FPR:Privacy による。

附属書 J(規定)クラス FPT:評価対象のセキュリティ機能保護   

ISO/IEC 15408-2:2008

の Annex J (normative)  Class FPT: Protection of the TSF  による。

附属書 K(規定)クラス FRU:資源利用   

ISO/IEC 15408-2:2008

の Annex K (normative)  Class FRU:Resource utilisation  による。

附属書 L(規定)クラス FTA:評価対象へのアクセス   

ISO/IEC 15408-2:2008

の Annex L (normative)  Class FTA: TOE access  による。

附属書 M(規定)クラス FTP:高信頼パス及びチャネル   

ISO/IEC 15408-2:2008

の Annex M (normative)  Class FTP: Trusted path/channels  による。


69

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

附属書 JB

(参考)

ISO/IEC 15408-3

  Part 3: Security assurance components

第 3 部:セキュリティ保証コンポーネント

適用範囲     

この規格類第 3 部は,保証要件を規定している。それは,コンポーネント TOE の保証程度を判定するた

めの尺度を定義する評価保証レベル(EAL)を規定し,統合 TOE の保証程度を判定するための尺度を定義

する統合された保証パッケージ(CAP)を規定し,保証レベル及びパッケージから構成する個々の保証コ

ンポーネントを規定し,更に,PP 又は ST を評価する基準を規定している。

引用規格   

ISO/IEC 15408-3:2008

の 2(Normative reference)による。

定義及び用語   

ISO/IEC 15408-3:2008

の 3(Terms and definitions,symbols and abbreviated terms)による。

規格の概要   

ISO/IEC 15408-3:2008

の 4(Overview)による。

規格の枠組み   

ISO/IEC 15408-3:2008

の 5(Assurance paradigm)による。

セキュリティ保証コンポーネント 

ISO/IEC 15408-3:2008

の 6(Security assurance components)による。

評価保証レベル   

ISO/IEC 15408-3:2008

の 7(Evaluation assurance levels)による。

統合保証のパッケージ   

ISO/IEC 15408-3:2008

の 8(Composed assurance packages)による。

プロテクションプロファイルの評価 

ISO/IEC 15408-3:2008

の 9(Class APE: Protection Profile evaluation)による。

10 

セキュリティターゲットの評価 

ISO/IEC 15408-3:2008

の 10(Class ASE: Security Target evaluation)による。


70

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

11 

開発 

ISO/IEC 15408-3:2008

の 11(Class ADV: Development)による。

12 

ガイダンス 

ISO/IEC 15408-3:2008

の 12(Class AGD: Guidance documents)による。

13 

ライフサイクル  サポート 

ISO/IEC 15408-3:2008

の 13(Class ALC : Life-cycle support)による。

14 

テスト 

ISO/IEC 15408-3:2008

の 14(Class ATE: Tests)による。

15 

ぜい弱性評定 

ISO/IEC 15408-3:2008

の 15(Class AVA: Vulnerability assessment)による。

16 

統合 

ISO/IEC 15408-3:2008

の 16(Class ACO: Composition)による。

附属書 A(参考)開発(ADV 

ISO/IEC 15408-3:2008

の Annex A (informative)  Development (ADV)  による。

附属書 B(参考)統合(ACO 

ISO/IEC 15408-3:2008

の Annex B (informative)  Composition (ACO)  による。

附属書 C(参考)保証コンポーネントの依存の相互参照 

ISO/IEC 15408-3:2008

の Annex C (informative)  Cross reference of assurance components dependencies によ

る。

附属書 D(参考)PP と保証コンポーネントとの相互参照 

ISO/IEC 15408-3:2008

の Annex D (informative)  Cross reference of PPs and assurance components による。

附属書 E(参考)EAL と保証コンポーネントとの相互参照 

ISO/IEC 15408-3:2008

の Annex E (informative)  Cross reference of EALs and assurance components による。

附属書 F(参考)CAP と保証コンポーネントとの相互参照 

ISO/IEC 15408-3:2008

の Annex F (informative)  Cross reference of CAPs and assurance components による。


71

X 5070-1

:2011 (ISO/IEC 15408-1:2009)

参考文献

この規格類の利用者にとって有用と思われる規格・資料を集めたものである。出版年を示していない文

献については,最新の版を参照することが望ましい。

ISO/IEC

規格 

[1]  JIS Q 27001

  情報技術−セキュリティ技術−情報セキュリティマネジメントシステム−要求事項

注記  対 応国 際規格 : ISO/IEC 27001, Information technology− Security techniques− Information

security management systems

−Requirements(IDT)

[2]  JIS Q 27002

  情報技術−セキュリティ技術−情報セキュリティマネジメントの実践のための規範

注記  対応国際規格:ISO/IEC 27002,Information technology−Security techniques−Code of practice for

information security management

(IDT)

[3]  JIS X 19790

  セキュリティ技術−暗号モジュールのセキュリティ要求事項

注記  対 応 国 際 規 格 : ISO/IEC 19790 , Information technology − Security techniques − Security

requirements for cryptographic modules

(IDT)

[4]  ISO/IEC 15292

,Information technology−Security techniques−Protection Profile registration procedures

[5]  ISO/IEC TR 15443 (all parts)

,Information technology−Security techniques−A framework for IT security

assurance

[6]  ISO/IEC TR 15446

,Information technology−Security techniques−Guide for the production of Protection

Profiles and Security Targets

[7]  ISO/IEC TR 19791

,Information technology−Security techniques−Security assessment of operational

systems

その他の規格 

[8]  IEEE Std 610.12-1990

,Institute of Electrical and Electronics Engineers, Standard Glossary of Software

Engineering Terminology

[9]  CCRA, Common Criteria portal, February 2009

http://www.commoncriteriaportal.org