コモンクライテリア（ISO/IEC 15408）の専門的理解と評価・認証プロセスの全貌
情報セキュリティが社会基盤の根幹を成す現代において、IT製品やシステムのセキュリティ品質を客観的に証明する枠組みとして「コモンクライテリア（Common Criteria、以下CC）」の重要性はかつてないほど高まっています。CCは単なる規格ではなく、国際的な相互承認協定（CCRA）に基づき、世界各国で認められる「信頼の証」として機能しています。本稿では、CCの技術的本質、評価保証レベル（EAL）の考え方、そして実務における適用上の要諦について詳細に解説します。
コモンクライテリアの技術的本質と構造
CCは「ISO/IEC 15408」として国際標準化されており、IT製品のセキュリティ機能が適切に設計・実装され、意図した通りに動作することを第三者機関が検証するためのフレームワークです。
CCの構造は大きく「セキュリティ機能要件（SFR）」と「セキュリティ保証要件（SAR）」の二本柱で構成されています。SFRは「何ができるか（暗号化、アクセス制御、監査機能など）」を規定し、SARは「どれだけ信頼できるか（開発プロセス、テスト、脆弱性分析など）」を規定します。
ここで重要なのは、CCが「絶対的なセキュリティの強さ」を定義するものではないという点です。CCは、定められたセキュリティターゲット（ST）に対して、その製品がどれだけ厳密に検証されたかという「保証の程度」を測定する尺度の役割を果たします。つまり、CC認証を取得した製品は、その製品のセキュリティ性能が、特定の評価レベルにおいて客観的に検証済みであることを意味します。
評価保証レベル（EAL）の段階的理解
CCにおいて最も注目されるのが、評価保証レベル（Evaluation Assurance Level: EAL）です。EALは1から7までの段階で構成されており、数字が大きいほど評価範囲が広く、深い分析が求められます。
EAL1（機能テスト）：最小限の検証。公開された機能が仕様通り動くかを確認。
EAL2（構造的テスト）：設計情報とテスト結果の整合性を確認。市販製品の標準的なレベル。
EAL3（系統的テスト・チェック）：開発プロセスの管理や構成管理が適切かを検証。
EAL4（系統的設計・テスト・レビュー）：商用製品における最高峰のレベル。設計の完全性が厳格に求められる。
EAL5-7：高度な設計、形式手法を用いた検証、実装レベルの分析が含まれる。主に軍事・政府機関向けや高信頼性インフラで使用される。
実務においては、EAL4が事実上の「商用最高レベル」として認識されています。これ以上のレベルは開発コストと期間が指数関数的に増大するため、製品の市場投入サイクルとのバランスを考慮した戦略的な選択が求められます。
セキュリティターゲット（ST）の策定と評価の実際
CC認証を取得するための最初の、そして最も重要なステップが「セキュリティターゲット（ST）」の作成です。STは、評価対象（TOE）がどのような脅威に対して、どのようなセキュリティ機能を持ち、どのような保証レベルを目指すのかを記述したドキュメントです。
プロフェッショナルとして留意すべきは、STの曖昧さがプロジェクトの失敗を招くという点です。STは後続の評価作業における「契約書」のような役割を果たします。
// セキュリティターゲット記述例（概念モデル）
SecurityTarget {
TOE_Identification: "SecureRouter v2.0",
Security_Problem_Definition {
Threats: ["Unauthorized access to management interface", "Data interception"],
Assumptions: ["Network administrator is trusted"],
Security_Objectives: ["Implement AES-256 encryption", "Strict RBAC enforcement"]
},
Security_Requirements {
SFRs: ["FDP_ACC.1", "FIA_UID.2", "FCS_CKM.1"],
SARs: ["EAL4_Augmented"]
}
}
このコード例に示すように、SFR（Security Functional Requirements）を適切に選定し、それがSTの脅威定義と論理的に整合していることを証明する必要があります。特に「Augmented（拡張）」という概念は重要で、EAL4の基本要件に特定のセキュリティ要件（例：脆弱性分析の強化）を上乗せすることで、特定の脅威に対する強固な保証を得る手法として一般的です。
実務アドバイス：CCプロフェッショナルとしての立ち回り
CC認証取得プロジェクトを成功させるには、技術力だけでなく、プロジェクトマネジメントと評価機関（認証機関）との密な連携が不可欠です。
1. 早期の評価機関参画：認証取得を決定した直後に、認定された評価機関（日本であればJISECなど）と相談を開始してください。開発の途中で方針転換を行うのは、膨大なドキュメント修正を伴うため致命的です。
2. 開発プロセスの「証拠」を蓄積する：CCは「言ったこと」ではなく「やったこと」を証明します。設計書、コードレビューログ、テスト実施記録、構成管理台帳などは、開発の各フェーズで適切にアーカイブしておく必要があります。後から遡って証拠を作ることは極めて困難です。
3. 脅威モデルの具体化：抽象的な脅威ではなく、実装レベルで想定される攻撃ベクトル（サイドチャネル攻撃、バッファオーバーフローなど）を具体的に列挙し、それに対してどのような防御策が講じられているかをSTに反映させてください。
4. 運用と保守の計画：認証取得後の維持管理も考慮に入れるべきです。パッチ適用や機能改修を行うたびに、認証の有効性を維持するための再評価（再認証）が必要となる場合があるため、ライフサイクル管理を計画に組み込んでください。
コモンクライテリアにおける形式手法の活用
EAL5以上の高度な評価が求められる環境では、自然言語による設計記述だけでは不十分です。ここでは「形式手法（Formal Methods）」の導入が鍵となります。Z言語やBメソッドといった数学的な記述言語を用いて、システムの仕様を記述し、その妥当性を数学的に証明することで、論理的な欠陥を排除します。
これは、従来の「テストによる検証（動的検証）」を補完する「静的検証」として強力な武器となります。バグの混入を未然に防ぐだけでなく、設計上の論理的不整合を早期に発見できるため、高信頼性が求められるシステム開発においては必須のスキルセットと言えます。
まとめと今後の展望
コモンクライテリアは、単なる認証取得のための手続きではありません。それは、製品開発においてセキュリティを「設計の最初から組み込む（Security by Design）」ための強力な規律です。CCのプロセスを遵守することで、開発チームは自社の製品に対する深い洞察を得ることができ、結果として市場における競争優位性と顧客からの信頼を獲得することができます。
今後、IoTデバイスの普及やサプライチェーン攻撃の増加に伴い、CCの重要性はさらに増していくでしょう。特に、ハードウェアの信頼性やファームウェアの完全性に対する要求は厳格化しています。CCプロフェッショナルには、単なる規格の知識だけでなく、最新の攻撃手法を理解し、それを防御するための設計思想を製品に落とし込む高度なエンジニアリング能力が求められています。
CC認証取得は、技術者にとっても組織にとっても困難な道のりですが、その過程で得られる「セキュリティ品質への厳格なこだわり」こそが、真のプロフェッショナルを育てる土壌となるのです。本稿が、貴殿のセキュリティエンジニアリングにおける指針となり、より堅牢なシステム構築の一助となれば幸いです。
コメント