共通基準

情報技術セキュリティ評価のための共通基準（コモンクライテリアまたはCCと呼ばれる）は、コンピュータセキュリティ認証のための国際標準（ISO / IEC 15408）です。現在はバージョン3.1リビジョン5です。^[1]

コモン クライテリアは、コンピュータ システムのユーザーがセキュリティ機能要件と保証要件 (それぞれ SFR と SAR) をセキュリティ ターゲット(ST) に指定できるフレームワークであり、保護プロファイル(PP) から取得できます。ベンダーは、製品のセキュリティ属性を実装または主張することができ、テスト ラボは製品を評価して、実際に主張を満たしているかどうかを判断できます。言い換えると、コモン クライテリアは、コンピュータ セキュリティ製品の仕様、実装、評価のプロセスが、使用対象の環境に見合ったレベルで、厳格で標準的かつ反復可能な方法で実施されたことを保証します。^[2]コモン クライテリアは、オペレーティング システム、アクセス制御システム、データベース、キー管理システムなどの認定製品のリストを維持しています。^[3]

Common Criteria 評価は、コンピューター セキュリティ製品およびシステムに対して実行されます。

• 評価対象 (TOE) – 評価の対象となる製品またはシステム。評価は、対象に関する主張を検証するために使用されます。評価を実際に使用するには、対象のセキュリティ機能を検証する必要があります。これは、次の方法で行われます。
  • 保護プロファイル(PP) – 通常はユーザーまたはユーザー コミュニティによって作成される文書で、特定の目的のためにそのユーザーに関連するセキュリティ デバイス (デジタル署名を提供するために使用されるスマート カードやネットワークファイアウォールなど) のクラスのセキュリティ要件を示します。製品ベンダーは、1 つ以上の PP に準拠する製品を実装し、それらの PP に対して製品を評価することができます。このような場合、PP は製品の ST (以下に定義されるセキュリティ ターゲット) のテンプレートとして機能するか、ST の作成者は少なくとも関連する PP のすべての要件がターゲットの ST 文書にも表示されるようにします。特定の種類の製品を探している顧客は、要件を満たす PP に対して認定された製品に集中できます。
  • セキュリティ ターゲット(ST) – 評価対象のセキュリティプロパティを識別するドキュメント。ST は、1 つ以上の PP への準拠を主張できます。TOE は、ST で確立された SFR (セキュリティ機能要件。以下を参照) に対して評価されます。それ以上でもそれ以下でもありません。これにより、ベンダーは、製品の意図された機能に正確に一致するように評価を調整できます。つまり、ネットワーク ファイアウォールは、データベース管理システムと同じ機能要件を満たす必要はなく、実際には、異なるファイアウォールがまったく異なる要件リストに対して評価される場合があります。ST は通常、潜在的な顧客が評価によって認定された特定のセキュリティ機能を判断できるように公開されます。
  • セキュリティ機能要件 (SFR) –製品によって提供される個々のセキュリティ機能を指定します。Common Criteria は、このような機能の標準カタログを提示します。たとえば、SFR は、特定のロールを実行するユーザーを認証する方法を規定する場合があります。2 つのターゲットが同じタイプの製品であっても、SFR のリストは評価ごとに異なる場合があります。Common Criteria は、ST に含める SFR を規定していませんが、1 つの機能 (ロールに従ってアクセスを制限する機能など) の正しい操作が別の機能 (個々のロールを識別する機能など) に依存する依存関係を特定します。

評価プロセスでは、品質保証プロセスを通じて、製品のセキュリティ機能に対する信頼のレベルを確立しようとします。

• セキュリティ保証要件 (SAR) – 主張されているセキュリティ機能への準拠を保証するために、製品の開発および評価中に講じられる措置の説明。たとえば、評価では、すべてのソース コードを変更管理システムに保持することや、完全な機能テストを実行することが必要になる場合があります。Common Criteria ではこれらのカタログが提供されており、要件は評価ごとに異なる場合があります。特定のターゲットまたは製品タイプに対する要件は、それぞれ ST および PP に文書化されています。
• 評価保証レベル(EAL) – 評価の深さと厳しさを表す数値評価。各 EAL は、製品の開発全体を一定の厳しさレベルでカバーするセキュリティ保証要件 (SAR、上記参照) のパッケージに対応します。Common Criteria には 7 つのレベルがリストされており、EAL 1 は最も基本的なレベル (したがって実装と評価のコストが最も安い) で、EAL 7 は最も厳密なレベル (最もコストが高い) です。通常、ST または PP の作成者は保証要件を個別に選択するのではなく、これらのパッケージの 1 つを選択し、いくつかの領域の要件をより高いレベルの要件で「補強」する可能性があります。EAL が高いほど必ずしも「セキュリティが優れている」わけではなく、TOE のセキュリティ保証がより広範囲に検証されていることを意味するだけです。

これまでのところ、ほとんどの PP と評価された ST/認定製品のほとんどは、IT コンポーネント (ファイアウォール、オペレーティング システム、スマート カードなど) 向けでした。

共通基準認証は、IT 調達に指定されることがあります。その他の標準には、相互運用性、システム管理、ユーザー トレーニング、補足 CC、その他の製品標準が含まれます。例としては、ISO/IEC 27002やドイツのIT ベースライン保護などがあります。

TOE 内の暗号化実装の詳細は、CC の範囲外です。代わりに、FIPS 140-2などの国家標準が暗号化モジュールの仕様を示し、さまざまな標準が使用される暗号化アルゴリズムを指定します。

最近では、PP 作成者は、通常は FIPS 140-2 評価でカバーされる CC 評価の暗号化要件を含めており、スキーム固有の解釈を通じて CC の範囲を広げています。

一部の国の評価制度では、EAL ベースの評価を段階的に廃止し、承認された PP に厳密に準拠していると主張する製品のみを評価対象として受け入れています。米国では現在、PP ベースの評価のみが許可されています。

CC は次の 3 つの標準から生まれました。

• ITSEC – 1990 年代初頭にフランス、ドイツ、オランダ、英国によって開発された欧州標準。これもまた、英国の 2 つのアプローチ (防衛/情報市場を対象としたCESG UK 評価スキームと商用利用を対象としたDTIグリーン ブック) などの以前の取り組みを統合したもので、オーストラリアなど他のいくつかの国でも採用されました。
• CTCPEC – カナダの標準は米国国防総省の標準を踏襲したものですが、いくつかの問題を回避し、米国とカナダの両方の評価者が共同で使用しました。CTCPEC 標準は 1993 年 5 月に初めて公開されました。
• TCSEC –米国国防総省のDoD 5200.28 標準規格。オレンジブックおよびレインボーシリーズの一部と呼ばれます。オレンジブックは、 1970 年代後半から 1980 年代前半にかけて国家安全保障局と国立標準局 (NBS は最終的にNISTになりました) によって行われたアンダーソンレポートを含むコンピュータセキュリティの研究から生まれました。オレンジブックの中心的な論点は、一連の保護メカニズムについて Dave Bell と Len LaPadula が行った研究に基づいています。

CC は、既存の標準を統合して作成されました。主な目的は、政府市場 (主に防衛または諜報用) 向けにコンピュータ製品を販売する企業が、1 つの標準セットに対して評価するだけで済むようにすることです。CC は、カナダ、フランス、ドイツ、オランダ、英国、米国の政府によって開発されました。

すべての試験機関はISO/IEC 17025に準拠する必要があり、認証機関は通常 ISO/IEC 17065 に基づいて承認されます。

ISO/IEC 17025への準拠は、通常、国家承認機関に対して実証されます。

• カナダでは、カナダ規格協会（SCC）の試験所認定プログラム（PALCAN）が、共通基準評価施設（CCEF）を認定しています。
• フランスでは、Comité français d'accréditation  [fr] (COFRAC) が、一般に Center d'évaluation de la sécurité des technology de l'information  [fr] (CESTI) と呼ばれる共通基準評価機関を認定しています。評価は、国家情報安全保障局(ANSSI)によって指定された規範および基準に従って行われます。
• イタリアでは、OCSI (Organismo di Certificazione della Sicurezza Informatica) が Common Criteria 評価機関を認定しています。
• インドでは、電子情報技術省のSTQC局がIT製品をEAL 1からEAL 4の保証レベルで評価し、認証しています。^[4]
• 英国では、英国認定サービス（UKAS）が商業評価施設（CLEF）を認定していました。2015年10月28日にWayback Machineでアーカイブされました。英国は2019年以降、CCエコシステムの消費者にすぎません。
• 米国では、国立標準技術研究所（NIST）の国家自主試験所認定プログラム（NVLAP）がコモンクライテリア試験所（CCTL）を認定しています。
• ドイツでは、Bundesamt für Sicherheit in der Informationstechnik (BSI)
• スペインでは、国立暗号センター (CCN) がスペインの制度に従って運営されている Common Criteria Testing Laboratories を認定しています。
• オランダでは、IT セキュリティ分野の認定に関するオランダ制度 (NSCIB) が IT セキュリティ評価施設 (ITSEF) を認定しています。
• スウェーデンでは、スウェーデン IT セキュリティ認証機関 (CSEC) が IT セキュリティ評価施設 (ITSEF) にライセンスを付与します。

これらの組織の特徴は ICCC 10 で調査され、発表されました。

コモンクライテリア規格の他に、条約レベルのコモンクライテリアMRA（相互承認協定）もあり、各締約国は他の締約国によるコモンクライテリア規格に対する評価を承認する。1998年にカナダ、フランス、ドイツ、英国、米国が最初に署名し、1999年にオーストラリアとニュージーランドが加わり、2000年にはフィンランド、ギリシャ、イスラエル、イタリア、オランダ、ノルウェー、スペインが続いた。この協定はその後、コモンクライテリア承認協定（CCRA）に改名され、加盟国は拡大し続けている。^[5] CCRA内では、EAL 2までの評価のみが相互に承認されている（欠陥修正による増強を含む）。SOGIS-MRA内の欧州諸国は通常、より高いEALも承認している。EAL5以上の評価には、ホスト国の政府のセキュリティ要件が含まれる傾向がある。

2012 年 9 月、CCRA の会員の大多数がビジョン ステートメントを作成しました。このビジョン ステートメントでは、CC 評価済み製品の相互承認が EAL 2 (欠陥修正による拡張を含む) に引き下げられます。さらに、このビジョンは保証レベルから完全に離れ、評価は保証レベルが指定されていない保護プロファイルへの適合に限定されることを示しています。これは、世界規模の PP を開発する技術ワーキング グループを通じて達成されますが、移行期間はまだ完全には決定されていません。

^{2014年7月2日、2012年のビジョンステートメント[7} ]に概説された目標に従って、新しいCCRAが批准されました^[6] 。この取り決めの主な変更点は次のとおりです。

• コラボレーション保護プロファイル (cPP) または評価保証レベル 1 ～ 2 および ALC_FLR のみに対する評価の認識。
• cPP の作成を担当する技術専門家のグループである国際技術コミュニティ (iTC) の出現。
• 以前のバージョンの協定に基づいて発行された証明書の承認を含む、以前の CCRA からの移行計画。

Common Criteria は非常に汎用的であり、特定の製品 (クラス) の製品セキュリティ要件または機能のリストを直接提供しません。これはITSECが採用したアプローチに従っていますが、 TCSECやFIPS 140 -2などの他の以前の標準のより規範的なアプローチに慣れている人々にとっては議論の種となっています。

Common Criteria 認証ではセキュリティを保証することはできませんが、評価対象製品のセキュリティ属性に関する主張が独立して検証されたことを確認できます。つまり、Common Criteria 標準に照らして評価された製品は、仕様、実装、評価のプロセスが厳格かつ標準的な方法で実行されたことを示す明確な証拠チェーンを示します。

Windows Server 2003やWindows XPを含むさまざまなMicrosoft Windowsバージョンが認定されていますが^[8]、これらのWindowsシステム向けにセキュリティの脆弱性に対処するセキュリティパッチがMicrosoftから引き続き公開されています。これが可能なのは、Common Criteria認定を取得するプロセスにより、ベンダーが分析を特定のセキュリティ機能に限定し、動作環境とその環境で製品が直面する脅威の強さについて特定の仮定を立てることができるためです。さらに、CCは、費用対効果が高く有用なセキュリティ認定を提供するために、評価対象製品が保証レベルまたはPPで指定された詳細レベルまで検査されるように、評価範囲を制限する必要があることを認識しています。したがって、評価活動は、特定の深さ、時間、およびリソースの使用でのみ実行され、対象環境に対して合理的な保証を提供します。

Microsoft の場合、仮定には A.PEER が含まれます。

「TOE が通信する他のシステムは、同じ管理制御下にあり、同じセキュリティ ポリシー制約の下で動作するものと想定されます。TOE は、ネットワーク全体が同じ制約の下で動作し、単一の管理ドメイン内に存在する場合にのみ、ネットワーク環境または分散環境に適用できます。外部システムまたはそのようなシステムへの通信リンクを信頼する必要性に対応するセキュリティ要件はありません。」

この前提は、製品が準拠している制御アクセス保護プロファイル(CAPP)に含まれています。この前提と、汎用オペレーティング システムの一般的な使用には現実的ではない可能性のあるその他の前提に基づいて、Windows 製品のセキュリティ機能が評価されます。したがって、想定される特定の状況 (評価された構成とも呼ばれます) でのみ、セキュリティが確保されていると見なす必要があります。

Microsoft Windows を正確に評価された構成で実行するかどうかにかかわらず、Windows の脆弱性が引き続き出現した場合は、Microsoft のセキュリティ パッチを適用する必要があります。これらのセキュリティ脆弱性のいずれかが製品の評価された構成で悪用可能な場合、ベンダーは製品の Common Criteria 認定を自主的に取り消す必要があります。または、ベンダーは、評価された構成内のセキュリティ脆弱性を修正するパッチの適用を含めて製品を再評価する必要があります。ベンダーがこれらの手順のいずれかを実行しないと、製品が評価された国の認証機関によって製品の認定が強制的に取り消されることになります。

認定された Microsoft Windows バージョンは、評価された構成に Microsoft セキュリティ脆弱性パッチを適用しなくても、 EAL4+のままです。これは、評価された構成の制限と強度の両方を示しています。

2007 年 8 月、Government Computing News (GCN) のコラムニストである William Jackson 氏は、Common Criteria の方法論と、Common Criteria Evaluation and Validation Scheme (CCEVS) による米国での実装を批判的に検証しました。^[9]このコラムでは、セキュリティ業界の幹部、研究者、および National Information Assurance Partnership (NIAP) の代表者がインタビューを受けました。記事で概説されている反論には、次のようなものがあります。

• 評価はコストのかかるプロセスであり (数十万ドルに及ぶこともよくあります)、ベンダーがその投資から得る利益は必ずしもより安全な製品であるとは限りません。
• 評価は、実際のセキュリティ、技術的な正確性、または製品自体のメリットではなく、主に評価ドキュメントの評価に重点を置いています。米国の評価では、EAL5 以上でのみ国家安全保障局の専門家が分析に参加し、EAL7 でのみ完全なソース コード分析が必要になります。
• 評価証拠やその他の評価関連文書を準備するために必要な労力と時間は非常に煩雑であるため、作業が完了する頃には、評価対象の製品が古くなっているのが一般的です。
• Common Criteria Vendor's Forum などの組織からのインプットを含む業界からのインプットは、一般的にプロセス全体にほとんど影響を与えません。

2006 年の研究論文で、コンピュータ専門家の David A. Wheeler は、Common Criteria プロセスはフリーおよびオープンソース ソフトウェア(FOSS) 中心の組織および開発モデルを差別していると示唆しました。^{[10] Common Criteria の保証要件は、従来の}ウォーターフォールソフトウェア開発方法論に触発される傾向があります。対照的に、多くの FOSS ソフトウェアは、最新のアジャイルパラダイムを使用して作成されています。両方のパラダイムはうまく整合していないと主張する人もいますが、^[11]両方のパラダイムを調和させようとする人もいます。^[12]政治学者の Jan Kallberg は、認証された製品の実際の製造に対する制御の欠如、コンプライアンスを監視する常勤の組織体の不在、および Common Criteria IT セキュリティ認証への信頼が地政学的境界を越えて維持されるという考えについて懸念を表明しました。^[13]

2017年、コモンクライテリア認定スマートカード製品のリストにROCA脆弱性が見つかりました。この脆弱性により、コモンクライテリア認定スキームのいくつかの欠点が浮き彫りになりました。 ^[14]

• この脆弱性は、暗号解析コミュニティによって公開および分析されていない、自社製の RSA キー生成アルゴリズムに存在していました。しかし、ドイツの試験機関TÜV Informationstechnik GmbH (TÜViT) は、その使用を承認し、ドイツの認証機関BSI は、脆弱性のある製品に対して Common Criteria 証明書を発行しました。評価された製品のセキュリティ ターゲットでは、RSA キーは標準アルゴリズムに従って生成されると主張されていました。この脆弱性への対応として、BSI は現在、認証レポートで、実装された独自の暗号化が推奨標準に厳密に準拠していないかどうかを少なくとも明記することを義務付け、透明性の向上を計画しています。BSIは、独自のアルゴリズムを何らかの形で公開することを義務付ける予定はありません。
• 認証機関は、 Common Criteria 証明書で指定されたセキュリティ クレームがもはや有効ではないことを認識していますが、ANSSIもBSIも該当する証明書を取り消していません。BSI によると、証明書は誤解に基づいて発行された場合、つまり間違った証拠が提出されたことが判明した場合のみ取り消すことができます。証明書が発行された後は、改良された新しい攻撃が発見されることにより、証明書の有効性は時間の経過とともに低下すると想定する必要があります。認証機関はメンテナンス レポートを発行し、製品の再認証を実行することもできます。ただし、これらのアクティビティはベンダーが開始して後援する必要があります。
• いくつかの Common Criteria 認定製品が ROCA 欠陥の影響を受けていますが、認定に関するベンダーの対応は異なります。一部の製品については、長さが 3072 ビットと 3584 ビットの RSA キーのみが少なくとも 100 ビットのセキュリティ レベルを持つと記載されたメンテナンス レポートが発行されています。一方、一部の製品については、メンテナンス レポートで TOE の変更が認定された暗号化セキュリティ機能に影響を与えるとは記載されておらず、変更はガイダンス ドキュメントのレベルであり、保証には影響がないと結論付けられています。
• BSIによれば、認定された最終製品のユーザーはベンダーからROCA の脆弱性について知らされているはずだった。しかし、この情報は、75 万枚を超えるエストニアの身分証明書に脆弱な製品を導入していたエストニア当局にタイムリーに届かなかった。

CCは、その存続期間を通じて、作成国によっても普遍的に採用されたわけではなく、特に暗号の承認は、カナダ/米国のFIPS-140の実装や英国のCESG支援製品スキーム（CAPS）^[15]などによって個別に処理されていました。

英国は、相互承認にかかる時間、コスト、諸経費が市場の運営を妨げていることが判明した際に、いくつかの代替制度も策定した。

• CESGシステム評価（SYSn）とファストトラックアプローチ（FTA）スキームは、一般的な製品やサービスではなく政府システムの保証を目的としており、現在はCESGテーラード保証サービス（CTAS）に統合されている^[16]
• CESG Claims Tested Mark (CCT Mark) は、製品およびサービスに対するそれほど網羅的ではない保証要件を、コストと時間を効率的に処理することを目的としています。

2011年初頭、NSA/CSSはクリス・ソルターによる論文を発表し、評価に向けて保護プロファイル指向のアプローチを提案した。このアプローチでは、技術の種類を中心に関心のあるコミュニティが形成され、その技術の種類の評価方法を定義する保護プロファイルが開発される。 ^[17]目的はより堅牢な評価を行うことである。これが相互承認に悪影響を及ぼす可能性があるという懸念もある。^[18]

2012年9月、コモンクライテリアは、前年のクリス・ソルターの考えをほぼ実現した ビジョンステートメント^{[19]を発表しました。ビジョンの主要な要素は次のとおりです。}

• 技術コミュニティは、合理的で比較可能、再現可能で費用対効果の高い評価結果という目標をサポートする保護プロファイル（PP）の作成に重点を置く。
• 可能であれば、これらの PP に対して評価を行う必要があります。そうでない場合、セキュリティ ターゲット評価の相互承認は EAL2 に限定されます。

• ベル・ラパドゥーラモデル
• 中国強制証明書
• 評価保証レベル
• 140-2 の認証
• 情報保証
• 9241 規格
• 国際標準化機構（ISO）27001
• ユーザビリティテスト
• 検証と検証

• コモンクライテリアプロジェクトの公式ウェブサイト
• コモンクライテリア標準文書
• Common Criteria 評価済み製品リスト
• 認可を受けたコモンクライテリア試験所のリスト
• アジャイルセキュリティ保証に向けて
• 重要な共通基準の頭字語
• コモンクライテリアユーザーフォーラム
• Google Knol の追加の共通基準情報
• OpenCC プロジェクト – 無料の Apache ライセンス CC ドキュメント、テンプレート、ツール
• 共通基準クイックリファレンスカード
• 共通基準プロセスのチートシート
• 共通基準プロセスのタイムライン