Loading article…
情報技術セキュリティ評価のための共通基準、または単に共通基準（CC）は、情報セキュリティ規格です。これはISO/IEC 15408:2022で採用されています。
Common Criteriaは、コンピュータシステムのユーザーがセキュリティ機能要件とセキュリティ保証要件（それぞれSFRとSAR）をセキュリティターゲット（ST）で指定できるフレームワークであり、保護プロファイル（PP）から取得できます。ベンダーは製品のセキュリティ属性を実装または主張することができ、テストラボは製品を評価して、実際にその主張を満たしているかどうかを判断できます。言い換えれば、Common Criteriaは、コンピュータセキュリティ製品の仕様、実装、評価のプロセスが、使用対象環境に見合ったレベルで、厳格かつ標準的で再現可能な方法で実施されたことを保証します。[ 1 ] Common Criteriaは、オペレーティングシステム、アクセス制御システム、データベース、キー管理システムなど、認証済み製品のリストを維持しています。[ 2 ]
共通基準評価は、コンピュータセキュリティ製品およびシステムに対して実施される。
これまでのところ、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つの規格から生まれた。
CCは、これらの既存の規格を統合することによって作成されました。主な目的は、政府市場（主に国防または情報機関向け）にコンピュータ製品を販売する企業が、単一の規格セットに基づいて製品を評価してもらうだけで済むようにすることでした。CCは、カナダ、フランス、ドイツ、オランダ、英国、および米国の政府によって開発されました。
すべての試験機関はISO/IEC 17025に準拠する必要があり、認証機関は通常、ISO/IEC 17065に基づいて承認されます。
ISO/IEC 17025への準拠は、通常、各国の認証機関に対して証明されます。
これらの組織の特徴は、ICCC 10で調査され、発表された。
共通基準規格に加えて、サブ条約レベルの共通基準相互承認協定（MRA）もあり、各締約国は他の締約国が行った共通基準規格に対する評価を承認します。当初は1998年にカナダ、フランス、ドイツ、英国、米国によって署名され、1999年にオーストラリアとニュージーランドが参加し、2000年にはフィンランド、ギリシャ、イスラエル、イタリア、オランダ、ノルウェー、スペインが続きました。この協定はその後、共通基準承認協定（CCRA）と改称され、加盟国は拡大し続けています。[ 4 ] CCRA内では、EAL 2までの評価のみが相互に承認されます（欠陥修正による拡張を含む）。SOGIS-MRA内の欧州諸国は通常、より高いEALも承認します。EAL5以上の評価は、ホスト国の政府のセキュリティ要件に関わる傾向があります。
2012年9月、CCRAの加盟団体の大多数は、CC評価製品の相互承認レベルをEAL 2（欠陥修正による強化を含む）に引き下げるというビジョン声明を発表しました。さらに、このビジョンは保証レベルそのものからの脱却を示しており、評価は保証レベルが明示されていない保護プロファイルへの適合性に限定されることになります。これは、世界規模の保護プロファイルを開発する技術ワーキンググループを通じて実現される予定ですが、移行期間はまだ完全には決定されていません。
2014年7月2日、2012年のビジョン声明[6]に概説された目標に基づき、新たなCCRAが批准された[ 5 ]。協定の主な変更点は以下のとおりである。
Common Criteriaは非常に汎用的な規格であり、特定の製品（または製品クラス）に対する製品セキュリティ要件や機能のリストを直接提供するものではありません。これはITSECのアプローチに倣ったものですが、 TCSECやFIPS 140-2などの以前の規格のより規定的なアプローチに慣れている人々にとっては議論の的となっています。
コモンクライテリア認証はセキュリティを保証するものではありませんが、評価対象製品のセキュリティ特性に関する主張が独立した機関によって検証されたことを保証するものです。言い換えれば、コモンクライテリア規格に基づいて評価された製品は、仕様策定、実装、評価のプロセスが厳格かつ標準的な方法で実施されたことを示す明確な証拠の連鎖を示しています。
Windows Server 2003やWindows XPを含むさまざまなMicrosoft Windows バージョンが認証されていますが[ 7 ]、これらの Windows システム向けにセキュリティ脆弱性に対処するためのセキュリティ パッチが Microsoft から引き続き公開されています。これは、共通基準認証を取得するプロセスにより、ベンダーが分析を特定のセキュリティ機能に限定し、動作環境と、その環境で製品が直面する脅威の強さについて一定の仮定を置くことができるためです。さらに、CC は、費用対効果が高く有用なセキュリティ認証を提供するために評価範囲を制限する必要性を認識しており、評価対象製品は保証レベルまたは PP で指定された詳細レベルまで調査されます。したがって、評価活動は一定の深さ、時間、リソースの使用に限って実行され、意図された環境に対して合理的な保証を提供します。
マイクロソフトの場合、前提条件にはA.PEERが含まれます。
TOEが通信する他のシステムはすべて、同じ管理下にあり、同じセキュリティポリシーの制約の下で運用されているものとみなされます。TOEは、ネットワーク全体が同じ制約の下で運用され、単一の管理ドメイン内に存在する場合に限り、ネットワーク環境または分散環境に適用可能です。外部システムや、そのようなシステムへの通信リンクを信頼する必要性に対応するセキュリティ要件はありません。
この前提は、各製品が準拠するアクセス制御保護プロファイル（CAPP）に含まれています。汎用オペレーティングシステムの一般的な使用状況では現実的ではない可能性のある、この前提およびその他の前提に基づいて、Windows製品のセキュリティ機能が評価されます。したがって、これらの製品は、想定された特定の状況（評価済み構成とも呼ばれる）においてのみ安全であると考えるべきです。
マイクロソフト Windows を評価対象の構成で実行するか否かにかかわらず、Windows の脆弱性が発見され次第、マイクロソフトが提供するセキュリティ パッチを適用する必要があります。製品の評価対象構成において、これらのセキュリティ脆弱性のいずれかが悪用可能な場合、ベンダーは製品の Common Criteria 認証を自主的に取り消す必要があります。あるいは、ベンダーは、評価対象構成におけるセキュリティ脆弱性を修正するためのパッチの適用を含めて、製品を再評価する必要があります。ベンダーがこれらのいずれの措置も講じない場合、製品が評価された国の認証機関によって、製品の認証が強制的に取り消されることになります。
認定済みのMicrosoft Windowsバージョンは、評価対象構成にMicrosoftのセキュリティ脆弱性パッチを適用していないにもかかわらず、EAL4+レベルに留まっています。これは、評価対象構成の限界と強みの両方を示しています。
2007年8月、Government Computing News（GCN）のコラムニストであるウィリアム・ジャクソンは、Common Criteriaの方法論と、Common Criteria Evaluation and Validation Scheme（CCEVS）による米国でのその実装について批判的に検証した。[ 8 ]このコラムでは、セキュリティ業界の幹部、研究者、およびNational Information Assurance Partnership（NIAP）の代表者にインタビューが行われた。記事で概説されている異議には、次のものがある。
2006年の研究論文で、コンピュータ専門家のDavid A. Wheelerは、Common Criteriaプロセスがフリーソフトウェアおよびオープンソースソフトウェア（FOSS）中心の組織や開発モデルを差別していると指摘した。[ 9 ] Common Criteriaの保証要件は、従来のウォーターフォール型ソフトウェア開発手法に影響を受けている傾向がある。対照的に、多くのFOSSソフトウェアは、現代のアジャイルパラダイムを使用して開発されている。両方のパラダイムはうまく整合しないと主張する人もいるが、[ 10 ]両方のパラダイムを調和させようとする人もいる。[ 11 ]政治学者のJan Kallbergは、認証された後の製品の実際の生産に対する管理の欠如、コンプライアンスを監視する常駐スタッフの組織機関の欠如、Common Criteria ITセキュリティ認証に対する信頼が地政学的境界を越えて維持されるという考えについて懸念を表明した。[ 12 ]
2017年に、ROCA脆弱性がCommon Criteria認証を受けたスマートカード製品のリストで発見されました。この脆弱性は、Common Criteria認証スキームのいくつかの欠点を浮き彫りにしました。[ 13 ]
CCの存続期間を通じて、作成国でさえも普遍的に採用されておらず、特に暗号化承認は、カナダ/米国のFIPS-140の実装や英国のCESG支援製品スキーム（CAPS）[ 14 ]のように、別々に処理されています。
英国はまた、相互承認にかかる時間、費用、および諸経費が市場の運営を阻害していることが判明した場合に、いくつかの代替案を策定してきた。
2011年初頭、NSA/CSSはクリス・ソルターによる論文を発表し、評価に対する保護プロファイル指向のアプローチを提案した。このアプローチでは、関心のあるコミュニティが技術タイプを中心に形成され、そのコミュニティが技術タイプの評価方法を定義する保護プロファイルを開発する。 [ 16 ]目的は、より堅牢な評価を実現することである。これが相互承認に悪影響を与える可能性があるという懸念もある。[ 17 ]
2012年9月、コモン・クライテリアはビジョン声明[ 18 ]を発表し、前年のクリス・ソルターの考えを大部分実現した。ビジョンの主な要素は以下のとおりである。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)