セキュリティ機能要件や保証要件の仕様を定めようとする場合、ISO/IEC 15408 の Part2 や Part3 で規定されて いる既存のコンポーネントを詳細化する自在性が与えられていても、PP や ST の作成者がそれらの要件の適切な 仕様を作成できないことがある。こういった場合には、拡張コンポーネントを定義することができる。本章では、拡張 コンポーネントの仕様に関するガイダンスを提供する。
ガイダンスを提供する前に、1 つだけ一般的なアドバイスをする：それは、拡張コンポーネントを定義することは、でき る限り避けるべきである、という点である。なぜならば、拡張コンポーネントを用いることによって、その製品を満足さ せるセキュリティ機能と保証要件をベースにした別の製品との比較が困難になるためである。その替わりに、まず、
ISO/IEC 15408 で規定されている既存のコンポーネントを利用することを試すべきである。こういった手段を取ること ができない場合に限り、拡張コンポーネントを利用すべきである。
ISO/IEC 15408 のコンポーネントに PP、または ST に記述したいと思う具体的な要件に対応するものがないと思わ れる場合には、コンポーネントを詳細化することで問題を解決できることが多い。例えば、利用者認証の要件が利 用者のタイプによって異なる場合には、特定の要件が適用される利用者タイプを特徴付けるために FIA クラスのコ ンポーネントを詳細化し、さらに複数のコンポーネントを具現化することによって異なった消費者タイプすべてに対応 するように表現することもできる。同様に、異なるタイプの利用者、サブジェクト、オブジェクト、またはセキュリティ属 性を管理するための異なった要件も詳細化を用いて表現することができる場合が多い。
ISO/IEC 15408-1 では、詳細化に関する例と共に、それらを利用して詳細化をより正確に表現する方法を提供し ている。
ISO/IEC 15408-1 には、拡張コンポーネントを定義する方法に関するガイダンスも若干提供されている。以下の各 項では、このガイダンスを補足している。
拡張コンポーネントを定義する前に、評価が既に完了し、公開されている ST、または PP の中に、セキュリティ機能、
または保証要件に具体的に追加したいと思う拡張コンポーネントが既に定義されているかについて詳しく調査すべ きである。評価済みの ST や PP で既に定義されている拡張されたコンポーネントを利用することによって、そのコンポ ーネントが既に ISO/IEC 15408 で要求されている ST、または PP の評価の一部として、その整合性や適合性が確 認されていることを容易に判断することができる。
拡張要件を定義する場合、ISO/IEC 15408-1 では、ISO/IEC 15408 の既存コンポーネントと同様の方法で定義
されていることが必要である。拡張コンポーネントに名前を付ける場合にも、ISO/IEC 15408 の既存のコンポーネン トと同様の詳述さのレベルが適用される。したがって、拡張コンポーネントについても、ISO/IEC 15408 と同様の構 造を用いて記述するよう勧める。拡張コンポーネントに名前を付ける場合には、ISO/IEC 15408 のクラス、またはフ ァミリの中で既に定義されているコンポーネントに対応していることを確認し、クラスの名前と（基本的には）ファミリの 名前に、このコンポーネントが拡張コンポーネントであることを示す識別子を追加するだけで名前が作成されるよう にすべきである。拡張コンポーネントは、割付、及び/または選択などの操作ができるよう、可能な限り、一般的な 方法で定義すべきである。これによって ST、または PP の別な作成者が拡張コンポーネントを抽出し、それらを自ら の要件に適合するような方法で容易にインスタンス化することができる。
ISO/IEC 15408-2 の機能コンポーネントを用いて、拡張 SFR コンポーネントをモデルとして表現する場合の仕様に は、次のような条件が含まれる：
a) 拡張 SFR が、ISO/IEC 15408-2 のコンポーネントと同様の詳述さのレベルで定義されていること。
b) ISO/IEC 15408-2 のコンポーネントと同様の書式と表現方法が用いられていること。
c) コンポーネントには ISO/IEC 15408-2 としてのトポロジと用語が用いられていること。
新たな SFR が、クラス、またはファミリに含まれている既存の SFR と同じ特徴があることが判れば、新たな SFR だけ でまとめることが容易になり、クラス、またはファミリ全体が対象としている共通の内容を具体的に表現することにも 役立つ。
ISO/IEC 15408-2 の機能コンポーネントとして表現される書式には次のような特徴がある：
a) 機能要件の大半は、TSF は～しなければならない」、または「TSF は～ができなければならない という言い回し を用い、「可能にする」、「検知する」、「実行する」、「保証する」、「制限する」、「監視する」、「認める」、「回 避する」、「保護する」、「提供する」、または「限定する」といった動詞が用いられる。
b) セキュリティ属性や認証された利用者といった標準的な用語の利用。
c) 個々のエレメントそれ自体で意味を持ち、1 つ前のエレメントを参照しなくても理解することができる。
d) セキュリティ要件が TOE に適合しているかどうかを判断することができるなど、それぞれのセキュリティ要件が評価 可能でなければならない。
拡張コンポーネントを作成する場合は、SFR に関し、次のような条件を考慮すべきである：
a) ST、または PP の作成者によって割付、または選択などの操作ができるように構成されている。
b) PP、または ST に含まれていなければならない、他の SFR に依存性を持っている。
c) 監査対象のイベントが説明されており、イベントについてどのような情報が記録されるべきかに関する内容が含 まれている。
d) 管理すべきセキュリティ属性に対応するなど、セキュリティ管理に関する内容が含まれている。
ISO/IEC 15408-2 には含まれておらず、またこれとは全く異なる SFR を適切に構築し、その内容が著しく向上され ていると確信できるならば、国際的な標準である ISO/IEC 15408 の既存の機能コンポーネントの次期バージョンに その SFR を提出することを進言する。
SFR が ST のみで用いられる場合、つまり、SFR が他の PP、ST または機能パッケージのコンポーネントとして再利 用されない場合は、SFR の割付や選択方法を ISO/IEC 15408 の操作として規定する必要はないことがある点に 注意すべきである。
ISO/IEC 15408-2 に含まれていない拡張 SFR に名前を付ける場合は、標準と同様の書式となるように、ISO/IEC 15408-2 で規定されているトポロジと命名規則に従うべきである。拡張 SFR には、機能要件を示す「F」を用い、
続けてクラスやファミリに指定された適切なコンポーネント番号を用いるべきである。次に、既存のクラスをベースに拡 張されたコンポーネントを所定の場所に挿入する。既存のクラスとは関連性のない拡張コンポーネントの場合は、
例えば、コンポーネント「EX」のクラスを作成する、あるいはコンポーネントの名前の後に EX を追加するといった方法
で、拡張されたセキュリティ要件が新たに作成されたものであることがはっきりと判るようにすることも可能である。拡 張コンポーネントをどのように表示すべきかについては、PP、または ST の適用時の注意事項で説明すべきである。
用いられた命名規則については、ISO/IEC 15408-2 で規定されているものとの矛盾が生じないように注意すべきで ある。
付録 A では、拡張コンポーネントを ISO/IEC 15408-2 で定義しているのと同様の方法で説明している。これによっ て評価者は、拡張コンポーネントを定義する ST や PP の評価時に、拡張コンポーネントを ISO/IEC 15408-2 で 規定されているものと同様に扱うことが可能になる。
付録 A で説明している拡張 SFR の例と同様に、拡張セキュリティ保証要件も定義することができる。これは、ST や PP に製品に共通のセキュリティに関する保証アクティビティが説明されており、この保証アクティビティが ISO/IEC 15408-3 で規定されている既存のコンポーネントに含まれていない場合に納得の行く話である。また、ISO/IEC 15408-3 で規定されている既存のコンポーネントに利用されているものと同様の書式でセキュリティ保証コンポーネ ントが定義されている場合、拡張されたセキュリティ保証要件には、評価者が、製品が拡張セキュリティ保証要件 に適合していることを検証する活動を裏付ける評価方法を明らかにする必要がある。こういったアクティビティは、
ISO/IEC 15408-3 で定義している保証コンポーネントを、ISO/IEC 18045 で定義している程度の内容の詳述さで 定義しなければならない。
拡張された保証コンポーネントでは、次のような要素（詳しくは、ISO/IEC 15408-1 の附属書 C.5 を参照）について 定義すべきである：
a) 開発者のアクション。
b) 開発者が規定しなければならない証拠の内容・提示に対する要件。
c) 評価者のアクション。
ISO/IEC 15408-3 を詳しく見てみると、保証コンポーネントに関する要素は、次のような特徴を持っていることが判 る：
a) 開発者のアクションに関する要素には、開発者が実行しなければならないアクション、一般的には評価証拠の 提供を示すことを目的としている。
b) 内容や表示法に関する要素には、要求されている内容と共に、開発者が提供しなければならない評価証拠 をさまざまな角度から質的に特徴づけることを目的としている。
c) 評価者のアクションに関する要素には、次のような 2 通りの様式がある：
－ 評価者の最初のアクションは、一般的に次のような様式である：
評価者は、提供された情報が、証拠の内容・提示に対するすべての要件を満たしていることを確認しなけ ればならない。
－ その他の評価者アクション要素については、一般的に独立したステートメントの様式を取るが、これは評価 の一貫として判断される。
したがって、証拠の内容・提示に対するすべての要件は、はっきりと曖昧な表現にならないようにするだけではなく、
（できる限り）評価者の評価者アクションの一部として主観的な判断が必要とならないような表現にすべきである。
むしろ、拡張 SAR に関しては、評価者が判断し易いように対象とする基準をはっきりと定義すべきである。セキュリ ティ対策方針を判断する際、それに対応する拡張 SAR を明らかにする必要がある場合は、適用時の注意事項の 追加を検討すべきである。
拡張 SAR が ISO/IEC 15408 で規定するコンポーネントと同様の様式で確実に定められるように、分離可能な要 件が独立した要件の要素として記述されるようにすべきである。また、拡張 SAR に適切な表現を選択する方法は、
ISO/IEC 15408-3 で詳しく説明しているが、ISO/IEC 15408-1 の第 3 章で説明している一般的な用語の定義の しかたを参考にすべきである。
ISO/IEC 15408-3 には含まれておらず、またこれとは全く異なる SAR を適切に構築し、その内容が著しく向上され ていると確信できるならば、国際的な標準である ISO/IEC 15408 の既存の保証コンポーネントの次期バージョンに