コモンクライテリア
評価・認証済み製品をバージョンアップする際、軽微な変更なら必ずしも再評価(差分評価)せずに、同等の保証が維持されていることを判定できれば効率がよい。
そのための枠組みを意図した保証要件として、CC 2.1 版には、AMA (保証維持) クラスがあった。 ところが、効果的な保証維持計画を、初版の認証取得前に TOE 開発者が策定するのは現実的でなく、評価方法も確立されていなかったので 2.2 版で廃止された。
代わりに、保証継続ガイドライン (ACG) と呼ばれる手続き方法(保証要件ではない)が CC および CEM とは別枠で導入され、相互承認を含めて実際に運用されている。
コモンクライテリア承認アレンジメント (CCRA, Common Criteria Recognition Arrangement) は条約に準ずる国際協定である。 CCRA の各加盟国は、他の加盟国でなされた CC 規格評価を相互に承認することになっている。 最初は1998年に MRA(Mutual Recognition Arrangement, 相互承認アレンジメント)という名で、カナダ、フランス、ドイツ、英国および米国が署名し、オーストラリアおよびニュージーランドが1999年に、さらにフィンランド、ギリシア、イスラエル、イタリア、オランダ、ノルウェーおよびスペインが2000年に参加した。2003年からは日本も参加。 その後 MRA は CCRA に改名され、加盟国は増え続けている。
現在のところ、最高 EAL4 (障害修正 ALC_FLR の追加を含む)までの範囲で、 CCRA 内の国際的な相互認証が行われている。 より高い EAL については、非常に込み入っているので、国境を越えて承認する義務はなく、一部の国において国内限定で評価・認証が行われている。
セキュリティ機能性の主張に製品が準拠していることを保証するために、製品開発の間にとられる施策を規定する条文。例えば、全ソースコードが変更管理システムで保持されていることを要求する、十分な機能テストが行われる (perform) ことを要求する、など。上の SFR 同様、CC は SAR のカタログを規定し、必要なものを選んで PP や ST に記載する。
CC は以下の3冊で構成される。
パート1: 概説と一般モデル (Introduction and general model)
パート2: セキュリティ機能要件 (Security functional requirements)
パート3: セキュリティ保証要件 (Security assurance requirements)
CC によるセキュリティ評価は、ITSEC (およびその前身であるドイツ BSI 標準の ITS)同様、対象システムのセキュリティ機能性と、信頼性(品質保証)の両面から実施される。 後者においては、使用されている手法の実効性や、実装の正確性が検証されねばならない。 必要な信頼性の度合い、すなわちセキュリティ評価の広さと深さは、通常、EAL (下記参照)として指定される。
CC に基づく評価は、一般にはとても高くつき、それなりに時間もかかる。 評価は認定を受けた評価機関によって実施され、評価結果に対する認証は、CCRA (後述)加盟各国の認証機関(日本の IPA運営のJISEC 等)だけから受けることができる。 評価機関は、厳格に定められた手続きに則って認定され、定期的に更新を受けなければならない。