この規格ページの目次
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) P又は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部の拡張コンポーネント定義 (APEECD)
及び拡張コンポーネント定義 (ASEECD)として記述されている。
――――― [JIS X 5070-1 pdf 36] ―――――
34
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
8 プロテクションプロファイル及びパッケージ
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もあ
ることを意味する。
――――― [JIS X 5070-1 pdf 37] ―――――
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と“同等又はそれ以上に制限的である”ように考慮されているとする根拠
を含まなければならない。
――――― [JIS X 5070-1 pdf 38] ―――――
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の評価作業をより少ない労力で終わらせることができる。
プロテクションプロファイル
セキュリティ
セキュリティ
セキュリティ要件
セキュリティ要件
対策方針
SFR
セキュリティ課題定義 SFR
セキュリティ課題定義 SAR
脅威及びOSP SAR
脅威,OSP,
対策方針
対策方針
前提条件
前提条件
すべて
同等又はそれ以上に
制限的である
任意選択 :
任意選択 : 正確適合
正確適合 セキュリティ 任意選択 :
任意選択 :
追加の脅威
追加の脅威 追加又は
追加又は
及びOSP
だけ ターゲット より厳しい
より厳しい
SAR及びSFR
SAR及びSFR
セキュリティ課題定義
セキュリティ課題定義
セキュリティ要件
セキュリティ要件
脅威及びOSP
脅威,OSP, 正確適合
正確適合
対策方針
対策方針 SFR だけ
SFR だけ
TOEが満たす SAR
SAR
セキュリティ
セキュリティ
対策方針
前提条件
TOE
TOE 満たす
TOEの
TOEの
運用環境
運用環境
図4−PP,ST及びTOEのそれぞれの内容の関係
――――― [JIS X 5070-1 pdf 39] ―――――
37
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
8.4 PP及びパッケージの使用
STが一つ以上のパッケージ及び/又はプロテクションプロファイルへの適合を主張する場合,そのST
の評価では,そのSTが適合を主張しているパッケージ及び/又はPPに(そのSTのその他の部分を含め
て)実際に適合していることが例証される。適合の判断の詳細については,附属書Aに示す。
これは,次のプロセスも許している。
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 評価結果
9.1 序説
箇条9では,ISO/IEC 18045に従って実施されるPP及びSTを含むTOEの評価から期待される結果を次
に示す。
・ 複数のPP評価は,評価済みPPのカタログをもたらす。
・ ST評価は,TOEの評価の枠組み内で用いられる中間結果をもたらす。
・ 複数のST評価を含むTOE評価は,評価済みTOEのカタログをもたらす。多くの場合,これらのカタ
ログには特定のTOEではなく,そのTOEの基となるIT製品名が記載される。したがって,カタログ
にIT製品名が記載されていても,IT製品全体が評価を受けていると解釈しないほうがよい。ST評価
を含むTOE評価の実際の範囲は,STによって定義される。このようなカタログ例については参考文
献を参照する。
――――― [JIS X 5070-1 pdf 40] ―――――
次のページ PDF 41
JIS X 5070-1:2011の引用国際規格 ISO 一覧
- ISO/IEC 15408-1:2009(IDT)
JIS X 5070-1:2011の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.040 : 文字セット及び符号化