コモンクライテリア
コモンクライテリア（Common Criteria, 略称 CC）とは、コンピュータセキュリティのための国際規格であり、 ISO/IEC 15408 である。 IT 製品や情報システムに対して、情報セキュリティを評価し認証するための評価基準を定めている。
正式名称は "Common Criteria for Information Technology Security Evaluation"（情報技術セキュリティ評価のためのコモンクライテリア）である。 ISO/IEC 15408 の規格名は "Evaluation criteria for IT security", JIS X 5070 としての名称は「情報技術セキュリティの評価基準」である。 2019年3月時点においては「バージョン3.1 リリース5（2017年4月）」が最新版である。
日本ではコモンクライテリアまたは CC と呼ばれるほか、情報技術セキュリティ評価基準、ITセキュリティ評価基準、広く一般的にはセキュリティ評価基準などと呼ばれる。
現在では独立行政法人情報処理推進機構が、日本の「ITセキュリティ評価及び認証制度（JISEC：Japan Information Technology Security Evaluation and Certification Scheme）」[1]における認証機関を運営している。
概要
[編集]CC は 現在世界20 か国以上で政府調達基準とされており、日本においても、政府におけるIT製品・システムの調達に関して CC 評価・認証取得された製品の利用が推進されている。 [2][3]
また、CCRA加盟国のうちの一国において一度CC評価・認証を受ければ、他の国にも通用する。 情報システムや情報機器が、異なる国々で何度もセキュリティ認証を取得する必要をなくすために、欧州の ITSEC 標準や米国 TCSEC 標準の後継として、ISO の国際規格 (IS, International Standard) となることを目指して開発された。
CC は他のセキュリティ標準（米 FIPS 140 等）とは異なり、満たさなければならないセキュリティ要件のリストそのものを規定するのではなく、セキュリティ評価の枠組み（フレームワーク）を提供している。 この枠組みの中で、利用者はセキュリティ要件（要求仕様）を指定でき、開発者は製品のセキュリティ属性について主張でき、そして、評価者はそのセキュリティ主張を製品が本当に満たしているかどうかを検査できるようになっている。 すなわち CC は、コンピュータセキュリティ製品の要求仕様を示し、開発し、評価するというプロセスが厳密な方式で行なわれたという保証を提供するものである。
CC は以下の3冊で構成される。
- パート1: 概説と一般モデル (Introduction and general model)
- パート2: セキュリティ機能要件 (Security functional requirements)
- パート3: セキュリティ保証要件 (Security assurance requirements)
CC によるセキュリティ評価は、ITSEC （およびその前身であるドイツ BSI 標準の ITS）同様、対象システムのセキュリティ機能性と、信頼性（品質保証）の両面から実施される。 後者においては、使用されている手法の実効性や、実装の正確性が検証されねばならない。 必要な信頼性の度合い、すなわちセキュリティ評価の広さと深さは、通常、EAL （下記参照）として指定される。
CC に基づく評価は、一般にはとても高くつき、それなりに時間もかかる。 評価は認定を受けた評価機関によって実施され、評価結果に対する認証は、CCRA （後述）加盟各国の認証機関（日本の IPA運営のJISEC 等）だけから受けることができる。 評価機関は、厳格に定められた手続きに則って認定され、定期的に更新を受けなければならない。
最新の規格文書
[編集]- “セキュリティ評価基準”. CC/CEM バージョン3.1 リリース5. JISEC, 情報処理推進機構 (2017年7月20日). 2021年12月25日閲覧。
主要な概念
[編集]コモンクライテリアでは、以下のように主要な概念が数多く定義されている:
- プロテクションプロファイル (PP, Protection Profile)
- セキュリティ要件（要求仕様）を特定する文書。通常、利用者（または利用者の団体）が、自分の要求仕様を文書化したもの。実質的に、セキュリティデバイスの分類を規定している（例えば、デジタル署名用のスマートカード）。
- セキュリティターゲット (ST, Security Target)
- ある特定の製品のセキュリティ性能を特定する文書であり、製品を評価・認証するための基礎になる。通常、製品の開発者が作成する。ST は（一つ以上の） PP に適合していることを主張してもよく、評価の際は PP 適合主張が満たされているかどうかも検査される。
- 評価対象 (TOE, Target Of Evaluation)
- 簡単に言えば、ST にセキュリティ主張が記述された製品のことである。
- セキュリティ機能要件 (SFR, Security Functional Requirements)
- 製品が提供する個々のセキュリティ機能を規定する条文。セキュリティ機能の標準カタログとして CC は SFR のリストを規定しており、利用者が PP を書くときや、開発者が ST を書くときに、必要なものを選んで PP や ST に記載する。例として、特別な役割をもつ利用者（管理者など）を認証する方法を規定する SFR がある。 CC は ST に含まれるべき SFR を規定しないが、ある機能（例えば、役割に従ってアクセス制限する）が正常に動作するために不可欠な他の機能（例えば、各個人の役割を識別する）を、依存性として規定している。
- セキュリティ保証要件 (SAR, Security Assurance Requirements)
- セキュリティ機能性の主張に製品が準拠していることを保証するために、製品開発の間にとられる施策を規定する条文。例えば、全ソースコードが変更管理システムで保持されていることを要求する、十分な機能テストが行われる (perform) ことを要求する、など。上の SFR 同様、CC は SAR のカタログを規定し、必要なものを選んで PP や ST に記載する。
- 評価保証レベル (EAL, Evaluation Assurance Level)
- 製品の開発過程全般をカバーする保証要件のパッケージであり、7段階の厳格さに対応する。 EAL1 は最も基本的（したがって実施するのも評価を受けるのも安あがり）であり、EAL7 は最も厳しい（最も高価）。通常、ST や PP の著者は保証要件を一つ一つ選ぶことはせず、 EAL を一つ選び、必要であればより高レベルの保証要件をいくつか追加する。より高い EAL が必ずしも「より良いセキュリティ」を含意するとは限らず、主張している TOE セキュリティ保証がより広範に検証されたことを意味するに過ぎない。
今までのところ、PP の大部分、そして評価された ST/認証製品の大部分は、IT システムの構成要素（ファイアウォール、オペレーティングシステム、スマートカードなど）のためのものであった。 CC は IT 調達の要件として指定されることがある。 相互運用、システム管理、利用者教育等に関しては、他の標準規格が CC 等の製品標準を補う。 例えば ISO/IEC 27001 （旧 BS 7799-2）や ISO/IEC 27002 （旧 ISO/IEC 17799, BS 7799-1）またはドイツの IT-Grundschutzhandbuch である。
TOE 内の暗号系の実装に関する詳細は、CC の適用領域外である。 代わりに米政府標準 FIPS 140 などが暗号モジュールの仕様を規定し、使用する暗号アルゴリズムの仕様については様々な標準がある。
セキュリティ機能要件
[編集]CC の機能要件は、機能分野別に分類されており、セキュリティアーキテクチャの基本的な機能を表現したものとなっている。 前身となった TCSEC などと異なり、セキュリティ強度別の分類ではない。 主要な機能要件クラスは、FAU（セキュリティ監査）、FCO（通信）、FCS（暗号サポート）、FDP（利用者データ保護）、FIA（識別と認証）、FMT（セキュリティ管理）、FPR（プライバシー）、FPT（TOEセキュリティ機能の保護）、FRU（資源利用）、FTA（TOEアクセス）、および FTP（高信頼パス/チャネル）である。
ファイアウォールやICカード、無線LANなど、セキュリティ製品の種類によって、典型的なセキュリティ機能の範囲を定めた「プロテクションプロファイル」 (PP) が作られ、必要な一連の機能要件が記述される。
セキュリティ保証要件
[編集]CC は、評価結果の信頼性を担保するための数多くのセキュリティ保証要件を規定している。 保証要件は PP 評価用（APE クラス）、ST 評価用（ASE クラス）、TOE 評価用（それ以外の大部分）、および追加の枠組み用の四つに大別される。
3.0, 3.1 版の TOE 保証要件はADV (開発)、AGD (ガイダンス文書)、ALC (ライフサイクルサポート)、ATE (テスト) および AVA (脆弱性評定) の 5 クラスに大分類され、中分類では 20 ファミリーとなる。 2.x 版では分類方法が一部異なり、ACM (構成管理) および、ADO (配付と運用) を加えた 7 クラス 26 ファミリーである。
EAL
[編集]必要なセキュリティ保証要件を個別に指定するのは煩雑であるばかりでなく、その正当性を検証するのも大変である。 そこで、標準的なセキュリティ保証要件の組がいくつか定義されており、保証パッケージと呼ばれる。 中でも最も重要なのが7段階の EAL（Evaluation Assurance Level, 評価保証レベル）であり、CC において定義されている。
| CC EAL | ITSEC E | 意味 | TCSEC |
|---|---|---|---|
| EAL1 | E0-E1 | 機能テスト | D-C1 |
| EAL2 | E1 | 構造化テスト | C1 |
| EAL3 | E2 | 方式的テスト、及びチェック | C2 |
| EAL4 | E3 | 方式的設計、テスト、及びレビュー | B1 |
| EAL5 | E4 | 準形式的設計、及びテスト | B2 |
| EAL6 | E5 | 準形式的検証済み設計、及びテスト | B3 |
| EAL7 | E6 | 形式的検証済み設計、及びテスト | A |
統合 TOE
[編集]追加の枠組みを実現する保証要件クラスとしては、3.0, 3.1 版には ACO (統合) クラスがある。 これは統合 TOE (Composed TOE) すなわち TOE 評価が評価・認証済み他社製品に依存する場合の評価の枠組みのために導入された。
保証継続
[編集]評価・認証済み製品をバージョンアップする際、軽微な変更なら必ずしも再評価（差分評価）せずに、同等の保証が維持されていることを判定できれば効率がよい。
そのための枠組みを意図した保証要件として、CC 2.1 版には、AMA (保証維持) クラスがあった。 ところが、効果的な保証維持計画を、初版の認証取得前に TOE 開発者が策定するのは現実的でなく、評価方法も確立されていなかったので 2.2 版で廃止された。
代わりに、保証継続ガイドライン (ACG) と呼ばれる手続き方法（保証要件ではない）が CC および CEM とは別枠で導入され、相互承認を含めて実際に運用されている。
共通評価方法 (CEM)
[編集]共通評価基準であるコモンクライテリアに加え、スポンサー組織および委員会によって、評価結果が理解可能かつ比較可能にするための評価方法が開発された。 正式名称は Common Methodology for Information Technology Security Evaluation（情報セキュリティ評価のための共通方法）だが、共通評価方法 (Common Evaluation Methodology) の頭文字を採って CEM と呼ばれる。 これは、評価機関が CC 評価を行うための最低限のアクションを記述している。
CEM 2.3 版が ISO/IEC 18045 となっている。 2.3 版までの CEM は EAL1 から EAL4 までの評価に対応している。 3.0 および 3.1 版では ADV, ATE, AVA の各クラスは EAL5 まで、他のクラスは全コンポーネントの評価に対応している。
歴史
[編集]起源
[編集]CC は三つないし四つの標準を起源とする。 第1は米国防総省の TCSEC (Trusted Computer System Evaluation Criteria), 通称「オレンジブック」である。 1983年に制定され、1986年から NSA が国防関係のシステムを中心に評価・認証を行っている。
第2はヨーロッパの ITSEC (Information Technology Security Evaluation Criteria) である。 国内にセキュリティ評価・認証制度をもつフランス、ドイツおよびイギリスに、オランダを加えた4か国が開発し、1991年に欧州委員会から刊行され、他地域（オーストラリアなど）でも採用された。 TCSEC の概念を基にしながら、より柔軟な枠組みをもち、民生品から政府専用製品まで幅広く評価・認証が行われた。 国家間での相互承認、機能主張と保証要件の分離、そして評価基準 ITSEC に加え評価方法マニュアル ITSEM の標準化など、いくつかの点で CC の枠組みの基礎となっている。
第3はカナダの CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) であり、上記両標準を参考に、各々のアプローチを組み合わせ、1993年に公表された。
第4を挙げるならば、1993年に米国で起草された FC (Federal Criteria for Information Technology Security) だが、この取組みは早々に CC へと方向転換された。 FC は、元々軍需用の TCSEC を、民需にも使いやすいよう ITSEC の内容も取り入れた改訂版として構想された。 政府の高度機密向けセキュリティを担当し TCSEC を運用する NSA と、それ以外（政府の一般用と民間用）のセキュリティを担当する NIST が共に 1992年から FC 開発に取り組み、共に CC 開発に参画した。
統一
[編集]CC は、これら既存の標準規格を統一することによって誕生した。 これにより、防衛機関や情報機関向けにコンピュータ製品を販売する会社は、製品セキュリティ標準の適合性評価を、一つの標準についてだけ評価を受ければ済むようになった。 この統一と国際規格化への道のりには、実に 9年の歳月を要している。
ISO は1990年に、各国がセキュリティ評価結果を相互承認でき、国際 IT 市場に通用するような、汎用かつ国際標準のセキュリティ評価基準の開発を決定した。 この作業を同年 ISO/IEC JTC 1/SC 27/WG 3 が開始したが、作業量が膨大であることに加え、国際間の調整に難航し、遅々として捗らなかった。
1993年6月に、上記 TCSEC, ITSEC, CTCPEC および FC の開発に当たった6か国7組織は、共通の評価基準を共同開発し ISO 規格化することを合意した。 この活動は CC プロジェクトと名付けられ、各々の評価基準を統一し、成果を ISO に提供することを目的とした。
CC プロジェクトは各組織の代表者からなる編集委員会 (CC Editorial Board, CCEB) を結成して作業を開始し、上記 WG3 に対し規格案を提案した。 WG3 側では反発もあったが、運用実績のある既存の各標準とは別の標準を作ることの不安もあり、結局 WG3 側のエディターを CCEB に参画させることを条件に CC 採用を決めた。 これによって CCEB と WG3 の連携が確立し、CCEB から WG3 に原案を提供し始めた。 両者の調整を経て1996年1月に CC 1.0 版が完成し、4月には ISO が CD （委員会原案）として採用、配布を承認するに至った。
国際規格化
[編集]CC プロジェクトは 1.0 版でトライアルユース（試行評価）を何度も行い、評価基準文書のパブリックレビュー（公開審査）を広範囲に実施した。 試行評価、公開審査、および ISO からのフィードバックを基に CC の大規模な改訂が行われた。 改訂作業と並行して共通評価手法 (CEM) の開発、およびセキュリティ評価認証結果を各国で相互承認する枠組みの検討も進められた。
1997年10月に CC 2.0 “ベータ”版が WG3 に提出され、第2版 CD として承認された。 CC プロジェクトは WG3 のコメントと ISO 加盟各国の CD 投票コメントに基づき CC 2.0 版を仕上げ、1998年5月に FCD（最終草案）となった。 FCD 投票によって FDIS（最終規格案）化が決定した1998年10月、カナダ、フランス、ドイツ、イギリスおよび米国が相互承認協定 (MRA) に署名した。
FCD 投票コメントに基づき微修正された FDIS が国際投票を経て 1999年6月に IS （国際規格）として承認され ISO/IEC 15408:1999 となった。 CC プロジェクトはその微修正を取り入れ、使いやすく体裁を整えた評価基準文書 (CC) を発行し、併せて共通評価方法 (CEM) 初版を発行した。 この CC 文書が、IS と実質的に同一内容、同一効力をもつ 1999年8月の CC 2.1 版である。
2.1 版への指摘や問合せで明らかになった問題点は CC プロジェクト内に設けられた委員会 (CCIMB) で検討され、CC または CEM の修正を要する各々の指摘に対しては、問題の箇所と読み換え方を記した「解釈」 (Interpretation) と呼ぶ補足書面が発行された。 2004年1月に新規格案として、発行済み解釈を反映した CC と CEM の 2.2 版が発行された。 2005年8月にはその後の解釈を反映した新たな IS として CC 2.3 版 (ISO/IEC 15408:2005) および CEM 2.3 版 (ISO/IEC 18045:2005) が発行された。
CC バージョン 3 に至るまで
[編集]IS 化を成し遂げた CC バージョン 2.x 系（第2版系）はよく練られたセキュリティ評価基準だったが、解釈発行による微修正では済まないような根深い問題がいくつか指摘された。 用語や概念の定義に齟齬や循環がある、評価作業に無駄な重複がある、抽象度の大きく異なる機能要件が混在している、保証要件として内容を評価すべきセキュリティ側面が機能要件として形式しか評価されない、などである。 そのため、再び大規模な改訂の機運が高まり、バージョン 2 のメンテナンス（2.3 版の IS 化）と並行してバージョン 3 の開発が行われた。
バージョン 3（第3版）で計画された変更点のうち、まず PP と ST の改革を先行して試行評価することとなり、CC と CEM の 2.2 版に対して PP と ST の仕様・保証要件・評価方法の抜本改訂と、それらとの整合に必要最小限の変更（機能仕様や機能強度など）だけを施した 2.4 版が 2004年3月に発行された。 2.4 版は 2.3 版より早く発行され、パート 2 がない（2.2 版をそのまま使う）風変わりなテスト版であった。
CC と CEM の 3.0 版が 2005年6月に発行され、公開審査と試行評価が行われた。 その中で明らかになった問題点を修正した 3.1 版が 2006年9月に発行された。
3.0 版ではセキュリティ機能要件も保証要件も大幅に再編された。 ところが、特に機能要件は既存の PP の移植が困難な程の抜本改訂であったので、問題となった。 そのため 3.1 版の機能要件は 2.3 版に近いものに戻された。
CCRA: コモンクライテリア承認アレンジメント
[編集]コモンクライテリア承認アレンジメント (CCRA, Common Criteria Recognition Arrangement) は条約に準ずる国際協定である。[4] CCRA の各加盟国は、他の加盟国でなされた CC 規格評価を相互に承認することになっている。 最初は1998年に MRA（Mutual Recognition Arrangement, 相互承認アレンジメント）という名で、カナダ、フランス、ドイツ、英国および米国が署名し、オーストラリアおよびニュージーランドが1999年に、さらにフィンランド、ギリシア、イスラエル、イタリア、オランダ、ノルウェーおよびスペインが2000年に参加した。2003年からは日本も参加。 その後 MRA は CCRA に改名され、加盟国は増え続けている。
現在のところ、最高 EAL4 （障害修正 ALC_FLR の追加を含む）までの範囲で、 CCRA 内の国際的な相互認証が行われている。 より高い EAL については、非常に込み入っているので、国境を越えて承認する義務はなく、一部の国において国内限定で評価・認証が行われている。
参考文献
[編集]- 田渕治樹 (1999年). 国際セキュリティ標準 ISO 15408のすべて. 日経BP社. ISBN 4-8222-2254-3
- 内山政人 (2000年). ISO15408情報セキュリティ入門. 東京電機大学出版局. ISBN 4-501-53150-9
- 田渕治樹 (2001年). 国際セキュリティ標準ISO/IEC15408入門. オーム社. ISBN 4-274-94643-6
- 宇賀村直紀 (2006年). ISO15408セキュリティ実践解説 : 政府調達の統一基準. ソフトリサーチセンター. ISBN 4-88373-236-3
脚注
[編集]- ^ ITセキュリティ評価及び認証制度（JISEC） - IPA 独立行政法人情報処理推進機構
- ^ 政府機関の情報セキュリティ対策のための統一管理基準(1.5.1.1 情報システムのセキュリティ要件及び1.5.2.2 機器等の購入) - 2011年4月 内閣官房情報セキュリティセンター
- ^ IT セキュリティ評価及び認証制度等に基づく認証取得製品分野リスト - 2011年4月 経済産業省
- ^ 国際承認アレンジメント（CCRA） - IPA 独立行政法人情報処理推進機構
外部リンク
[編集]- コモンクライテリアプロジェクトの公式のウェブサイト
- 日本の「ITセキュリティ評価及び認証制度」（JISEC） - IPA 独立行政法人情報処理推進機構
- Japan Information Technology Security Evaluation and Certification Scheme (JISEC) - Information-technology Promotion Agency, Japan
- ISO/IEC 15408 無料ダウンロード
- 米国NISTによる一般的なCC情報
- 英国のCC等の評価制度
- ドイツBSIのCC情報
