コモンクライテリア – 日本の辞書

Common_Criteria

情報技術セキュリティ評価のためのコモンクライテリア（と呼ばれる共通の基準やCCが）である国際規格（ISO / IECのための15408）コンピュータセキュリティ認定。現在、バージョン3.1リビジョン5です。
Common Criteriaは、コンピューターシステムユーザーがセキュリティターゲット（ST）でセキュリティ機能と保証の要件（それぞれSFRとSAR）を指定できるフレームワークであり、保護プロファイル（PP）から取得できます。その後、ベンダーは自社製品のセキュリティ属性を実装または主張でき、テストラボは評価できます。それらが実際にクレームを満たしているかどうかを判断するための製品。言い換えれば、Common Criteriaは、コンピュータセキュリティ製品の仕様、実装、および評価のプロセスが、使用するターゲット環境に見合ったレベルで、厳密かつ標準的かつ反復可能な方法で実行されていることを保証します。 Common Criteriaは、オペレーティングシステム、アクセス制御システム、データベース、キー管理システムなど、認定された製品のリストを維持しています。

コンテンツ
1 重要な概念
2 歴史
3 テスト組織
4 相互認識の取り決め
5 問題
5.1 要件 5.2 認証の価値 5.3 批判
6 代替アプローチ
7 も参照してください
8 参考文献
9 外部リンク

重要な概念
コモンクライテリアの評価は、コンピュータセキュリティ製品およびシステムで実行されます。
評価対象（TOE） –評価の対象となる製品またはシステム。評価は、ターゲットに関して行われた主張を検証するのに役立ちます。実用化するには、評価でターゲットのセキュリティ機能を検証する必要がこれは、次の方法で実行されます。
保護プロファイル（PP） –通常はユーザーまたはユーザーコミュニティによって作成されるドキュメントで、そのユーザーに関連するセキュリティデバイスのクラス（たとえば、デジタル署名を提供するために使用されるスマートカードやネットワークファイアウォール）のセキュリティ要件を特定します。特定の目的。製品ベンダーは、1つ以上のPPに準拠する製品を実装し、それらのPPに対して製品を評価することを選択できます。このような場合、PPは製品のST（セキュリティターゲット、以下に定義）のテンプレートとして機能するか、STの作成者は、少なくとも関連するPPのすべての要件がターゲットのSTドキュメントにも表示されるようにします。特定の種類の製品をお探しのお客様は、要件を満たすPPに対して認定された製品に焦点を当てることができます。
セキュリティターゲット（ST） –評価対象のセキュリティプロパティを識別するドキュメント。STは、1つまたは複数のPPへの適合を主張する場合がTOEは、STで確立されたSFR（セキュリティ機能要件。以下を参照）に対して評価されます。これ以上でもそれ以下でもありません。これにより、ベンダーは、製品の意図された機能に正確に一致するように評価を調整できます。これは、ネットワークファイアウォールがデータベース管理システムと同じ機能要件を満たす必要がないことを意味し、実際には、異なるファイアウォールが完全に異なる要件のリストに対して評価される可能性がSTは通常、潜在的な顧客が評価によって認定された特定のセキュリティ機能を決定できるように公開されます。
セキュリティ機能要件（SFR） –製品によって提供される可能性のある個々のセキュリティ機能を指定します。コモンクライテリアは、そのような機能の標準カタログを提示します。たとえば、SFRは、特定の役割を実行するユーザーがどのように認証されるかを示す場合がSFRのリストは、2つのターゲットが同じタイプの製品であっても、評価ごとに異なる可能性がCommon Criteriaは、STに含まれるSFRを規定していませんが、ある機能の正しい操作（役割に応じてアクセスを制限する機能など）が別の機能に依存している依存関係（個々の役割を識別する機能など）を識別します。）。
評価プロセスでは、品質保証プロセスを通じて製品のセキュリティ機能に課せられる可能性のある信頼度を確立しようとします。
セキュリティ保証要件（SAR） –主張されているセキュリティ機能への準拠を保証するために、製品の開発および評価中に取られた措置の説明。たとえば、評価では、すべてのソースコードを変更管理システムに保持したり、完全な機能テストを実行したりする必要がある場合がコモンクライテリアはこれらのカタログを提供し、要件は評価ごとに異なる場合が特定のターゲットまたは製品のタイプの要件は、それぞれSTおよびPPに文書化されています。
評価保証レベル（EAL） –評価の深さと厳密さを表す数値評価。各EALは、セキュリティ保証要件（SAR、上記を参照）のパッケージに対応しており、特定のレベルの厳密さで製品の完全な開発をカバーしています。コモンクライテリアには7つのレベルがあり、EAL 1が最も基本的（したがって実装と評価が最も安価）であり、EAL 7が最も厳格（そして最も高価）です。通常、STまたはPPの作成者は、保証要件を個別に選択するのではなく、これらのパッケージの1つを選択します。場合によっては、いくつかの領域で要件をより高いレベルの要件で「拡張」します。より高いEALは、必ずしも「より良いセキュリティ」を意味するわけではなく、TOEの主張されたセキュリティ保証がより広範囲に検証されたことを意味するだけです。
これまでのところ、ほとんどのPPおよび最も評価されているST /認定製品は、ITコンポーネント（ファイアウォール、オペレーティングシステム、スマートカードなど）用です。IT調達では、コモンクライテリア認定が指定される場合が相互運用、システム管理、ユーザートレーニング、補足CC、その他の製品規格などを含むその他の規格。例としては、ISO / IEC27002やドイツのITベースライン保護などが
TOE内の暗号化実装の詳細は、CCの範囲外です。代わりに、FIPS 140-2などの国内規格では暗号化モジュールの仕様が規定されており、さまざまな規格で使用中の暗号化アルゴリズムが指定されています。
最近では、PPの作成者は、通常FIPS 140-2評価でカバーされるCC評価の暗号化要件を含め、スキーム固有の解釈を通じてCCの範囲を広げています。
一部の国の評価スキームでは、EALベースの評価が段階的に廃止され、承認されたPPに厳密に準拠していると主張する評価用の製品のみが受け入れられます。米国は現在、PPベースの評価のみを許可しています。カナダは、EALベースの評価を段階的に廃止する過程に

歴史
CCは、次の3つの標準に基づいています。
ITSEC – 1990年代初頭にフランス、ドイツ、オランダ、英国によって開発されたヨーロッパ規格。これも、2つの英国のアプローチ（防衛/インテリジェンス市場を対象としたCESG UK評価スキームと商業利用を目的としたDTIグリーンブック）などの以前の作業の統合であり、オーストラリアなどの他の国で採用されました。
CTCPEC –カナダの標準は米国のDoD標準に準拠していますが、いくつかの問題を回避し、米国とカナダの両方の評価者が共同で使用しました。CTCPEC標準は、1993年5月に最初に公開されました。
TCSEC –米国国防総省DoD 5200.28 Std、オレンジブックおよびレインボーシリーズの一部と呼ばれます。Orange Bookは、1970年代後半から1980年代初頭に、国家安全保障局と米国国立標準局（NBSは最終的にNISTになりました）によって行われたアンダーソンレポートを含むコンピュータセキュリティ作業に端を発しています。オレンジブックの中心的な論文は、一連の保護メカニズムのためにデイブベルとレンラパドゥラによって行われた作業に基づいています。
CCは、これらの既存の標準を統合することによって作成されました。主に、政府市場向け（主に防衛またはインテリジェンス用）にコンピューター製品を販売する企業は、1セットの標準に対して評価するだけで済みます。CCは、カナダ、フランス、ドイツ、オランダ、英国、および米国の政府によって開発されました。

テスト組織
すべての試験所はISO / IEC 17025に準拠している必要があり、認証機関は通常ISO / IEC17065に対して承認されます。
ISO / IEC 17025への準拠は、通常、各国の承認機関に示されます。
カナダでは、ラボ認定プログラム（PALCAN）の下にあるカナダ規格評議会（SCC）が、コモンクライテリア評価施設（CCEF）を認定しています。
フランスでは、Comitéフランス語D’認定（COFRAC）は、一般的に呼ばれるコモンクライテリアの評価施設、認定しセンターをD’評価・デ・ラ・sécuritéデ技術ドゥ情報（セスタス）。評価はで指定された規範や基準に従って行われアジャンス国立デラsécuritéデSystèmesのD’情報（ANSSI）。
イタリアでは、OCSI（Organismo di Certificazione della Sicurezza Informaticaがコモンクライテリア評価研究所を認定しています
英国では、英国認証機関（UKAS）が商業評価施設（CLEF）の認定に使用されていました。英国は2019年以来、CCエコシステムの唯一の消費者です
米国では、米国国立標準技術研究所（NIST）の国立自主試験所認定プログラム（NVLAP）が、コモンクライテリア試験所（CCTL）を認定しています。
ドイツでは、BundesamtfürSicherheitinder Informationstechnik（BSI）
スペインでは、国立暗号センター（CCN）は、コモンクライテリア認定する試験所のスペインスキームで動作します。
オランダでは、ITセキュリティ分野の認証のためのオランダのスキーム（NSCIB）がITセキュリティ評価施設（ITSEF）を認定しています。
スウェーデンでは、スウェーデンのITセキュリティ認証機関（CSEC）がITセキュリティ評価施設（ITSEF）のライセンスを取得しています。
これらの組織の特徴は、ICCC 10で調査され、発表されました。

相互認識の取り決め
コモンクライテリア基準に加えて、サブ条約レベルのコモンクライテリアMRA（相互承認協定）もあり、これにより、各当事者は、他の当事者によって行われたコモンクライテリア基準に対する評価を承認します。もともとは1998年にカナダ、フランス、ドイツ、イギリス、アメリカによって署名され、オーストラリアとニュージーランドが1999年に加わり、2000年にフィンランド、ギリシャ、イスラエル、イタリア、オランダ、ノルウェー、スペインが続きました。Common Criteria Recognition Arrangement（CCRA）に名前が変更され、メンバーシップは拡大し続けています。CCRA内では、EAL 2までの評価のみが相互に認識されます（欠陥修復による拡張を含む）。以前のITSEC契約に含まれるヨーロッパ諸国は、通常、より高いEALも認識しています。EAL5以上での評価には、ホスト国政府のセキュリティ要件が含まれる傾向が
2012年9月、CCRAのメンバーの過半数がビジョンステートメントを作成し、CCで評価された製品の相互認識がEAL 2に引き下げられます（欠陥修復による拡張を含む）。さらに、このビジョンは、保証レベルから完全に離れることを示しており、評価は、保証レベルが明記されていない保護プロファイルへの準拠に限定されます。これは、世界中のPPを開発する技術作業部会を通じて達成されますが、移行期間はまだ完全には決定され
2014年7月2日、2012年のビジョンステートメントで概説されている目標に従って、新しいCCRAが承認されました。アレンジメントの主な変更点は次のとおりです。
協調的保護プロファイル（cPP）または評価保証レベル1から2およびALC_FLRのみに対する評価の認識。
cPPの作成を担当する技術専門家のグループである国際技術コミュニティ（iTC）の出現。

以前のバージョンのアレンジメントの下で発行された証明書の認識を含む、以前のCCRAからの移行計画。

問題
要件
コモンクライテリアは非常に一般的です。それが直接製品（のクラス）特定の製品のセキュリティ要件や機能のリストを提供していません：これはによって取られたアプローチは以下のITSECを、しかし、のような他の以前の規格のより規範的なアプローチに使用されたものに議論の源となっていますTCSECとFIPS 140 -2。

認証の価値
コモンクライテリア認証はセキュリティを保証することはできませんが、評価された製品のセキュリティ属性に関する主張が独立して検証されたことを保証することはできます。言い換えれば、コモンクライテリア基準に照らして評価された製品は、仕様、実装、および評価のプロセスが厳密かつ標準的な方法で実施されたという明確な一連の証拠を示しています。
さまざまなマイクロソフトを含むWindowsのバージョン、Windows Server 2003のおよびWindows XPは、認定されているが、アドレスのセキュリティの脆弱性に対するセキュリティパッチはまだこれらのWindowsシステム用にMicrosoftから発行されてきています。これが可能なのは、Common Criteria認定を取得するプロセスにより、ベンダーが分析を特定のセキュリティ機能に制限し、動作環境とその環境で製品が直面する脅威の強さについて特定の仮定を立てることができるためです。さらに、CCは、評価された製品が保証レベルまたはPPで指定された詳細レベルで検査されるように、費用効果が高く有用なセキュリティ認証を提供するために評価の範囲を制限する必要があることを認識しています。したがって、評価活動は、特定の深さ、時間、およびリソースの使用に対してのみ実行され、意図された環境に対して合理的な保証を提供します。
Microsoftの場合、前提条件にはA.PEERが含まれます。
「TOEが通信する他のシステムはすべて、同じ管理制御下にあり、同じセキュリティポリシーの制約の下で動作すると想定されます。TOEは、ネットワーク全体が同じ制約の下で動作し、単一の管理ドメイン。外部システムまたはそのようなシステムへの通信リンクを信頼する必要性に対処するセキュリティ要件はありません。」
この仮定は、製品が準拠する制御アクセス保護プロファイル（CAPP）に含まれています。汎用オペレーティングシステムの一般的な使用には現実的ではない可能性があるこの仮定およびその他の仮定に基づいて、Windows製品の主張されているセキュリティ機能が評価されます。したがって、それらは、評価された構成としても知られている、想定された特定の状況でのみ安全であると見なされるべきです。
正確に評価された構成でMicrosoftWindowsを実行しているかどうかに関係なく、Windowsの脆弱性が引き続き表示されるため、Microsoftのセキュリティパッチを適用する必要がこれらのセキュリティの脆弱性のいずれかが製品の評価された構成で悪用される可能性がある場合、製品のCommonCriteria認定はベンダーによって自主的に取り消される必要がまたは、ベンダーは製品を再評価して、評価された構成内のセキュリティの脆弱性を修正するためのパッチの適用を含める必要がベンダーがこれらの手順のいずれかを実行しなかった場合、製品が評価された国の認証機関による製品の認証が不本意に取り消されることになります。
認定されたMicrosoftWindowsバージョンは、評価された構成にMicrosoftセキュリティ脆弱性パッチの適用を含めずにEAL4 +のままです。これは、評価された構成の制限と強度の両方を示しています。

批判
2007年8月、Government Computing News（GCN）のコラムニストであるWilliam Jacksonは、Common Criteriaの方法論と、Common Criteria Evaluation and Validation Scheme（CCEVS）による米国での実装を批判的に検討しました。コラムでは、セキュリティ業界の幹部、研究者、およびNational Information Assurance Partnership（NIAP）の代表者にインタビューを行いました。で概説されている反対意見は次のとおりです。
評価はコストのかかるプロセスであり（多くの場合、数十万米ドルで測定されます）、その投資に対するベンダーの見返りは、必ずしもより安全な製品ではありません。
評価は、製品自体の実際のセキュリティ、技術的な正確さ、またはメリットではなく、主に評価ドキュメントの評価に重点を置いています。米国の評価では、EAL5以上でのみ、国家安全保障局の専門家が分析に参加します。EAL7でのみ、完全なソースコード分析が必要です。
評価証拠やその他の評価関連文書を作成するために必要な労力と時間は非常に面倒であるため、作業が完了するまでに、評価対象の製品は一般に廃止されます。
Common Criteria Vendor’s Forumなどの組織からの入力を含む業界の入力は、通常、プロセス全体にほとんど影響を与えません。
2006年の研究論文で、コンピュータースペシャリストのDavid A. Wheelerは、コモンクライテリアプロセスがフリーでオープンソースのソフトウェア（FOSS）中心の組織や開発モデルを差別することを示唆しました。コモンクライテリアの保証要件は、従来のウォーターフォールソフトウェア開発方法論に触発される傾向が対照的に、多くのFOSSソフトウェアは、最新のアジャイルパラダイムを使用して作成されています。両方のパラダイムがうまく整合していないと主張する人もいますが、両方のパラダイムを調整しようとした人もいます。政治学者のヤン・カルバーグは、認証された後の製品の実際の生産に対する管理の欠如、コンプライアンスを監視する常勤の組織体の欠如、およびコモンクライテリアITへの信頼という考えについて懸念を表明しました。セキュリティ認証は、地政学的な境界を越えて維持されます。
2017年、ROCAの脆弱性は、CommonCriteria認定のスマートカード製品のリストで見つかりました。この脆弱性は、コモンクライテリア認証スキームのいくつかの欠点を浮き彫りにしました。
この脆弱性は、暗号解読コミュニティによって公開および分析されていない自社開発のRSAキー生成アルゴリズムに存在していました。しかし、テストlabaratoryドイツTÜVINFORMATIONSTECHNIK GmbH社（TÜViT）は、その使用を承認し、認証機関のBSIドイツでは、脆弱な製品のためのコモンクライテリア証明書を発行しました。評価された製品のセキュリティターゲットは、RSAキーが標準アルゴリズムに従って生成されると主張しました。この脆弱性に対応して、BSIは現在、実装された独自の暗号化が推奨される標準に正確に準拠していないかどうかを認証レポートに少なくとも指定することを要求することにより、透明性を向上させることを計画しています。BSIは、独自のアルゴリズムを公開することを要求する予定はありません。
認証機関は、コモンクライテリア証明書で指定されたセキュリティクレームがもはや保持されていないことを認識していますが、ANSSIもBSIも対応する証明書を取り消しBSIによると、証明書は、誤った証拠が提出されたことが判明した場合など、誤解の下で発行された場合にのみ取り消すことができます。証明書が発行された後、改善された新しい攻撃が発見されることにより、証明書の有効性は時間の経過とともに低下すると推定する必要が認証機関は、メンテナンスレポートを発行し、製品の再認証を実行することもできます。ただし、これらのアクティビティは、ベンダーが開始および後援する必要が
いくつかのコモンクライテリア認定製品はROCAの欠陥の影響を受けていますが、認定に関するベンダーの対応は異なります。一部の製品では、長さが3072ビットおよび3584ビットのRSAキーのみが少なくとも100ビットのセキュリティレベルを持っていることを示すメンテナンスレポートが発行されましたが、一部の製品では、TOEへの変更が影響することを記載していないメンテナンスレポートが認定された暗号化セキュリティ機能ですが、変更はガイダンスドキュメントのレベルであり、保証には影響しないと結論付けています。
BSIによると、認定された最終製品のユーザーは、ベンダーからROCAの脆弱性について知らされているはずです。ただし、この情報は、脆弱な製品を750，000枚を超えるエストニアIDカードに配備したエストニア当局にタイムリーに届きませんでした。

代替アプローチ
CCの存続期間を通じて、作成国でも広く採用されていませんでした。特に、カナダ/米国でのFIPS-140の実装や、CESG Assisted Products Scheme（CAPS ）などによって、暗号化の承認が個別に処理されていました。）英国で。
英国はまた、相互承認のタイムスケール、コスト、およびオーバーヘッドが市場の運営を妨げていることが判明した場合に、いくつかの代替スキームを作成しました。
CESGテーラードアシュアランスサービス（CTAS）に統合された一般的な製品やサービスではなく、政府システムを保証するためのCESGシステム評価（SYSn）およびファストトラックアプローチ（FTA）スキーム
マークテスト済みCESGクレームコストと時間効率的な方法で製品やサービスのためのあまり徹底的保証要件を取り扱うことを目的としている（CCTマーク）、
2011年の初めに、NSA / CSSはChrisSalterによる論文を発表しました。この論文は、評価に向けた保護プロファイル指向のアプローチを提案しました。このアプローチでは、関心のあるコミュニティがテクノロジータイプの周りに形成され、テクノロジータイプの評価方法を定義する保護プロファイルが作成されます。目的は、より堅牢な評価です。これが相互認識に悪影響を与える可能性があるという懸念が
2012年9月、コモンクライテリアは、前年からのクリスソルターの考えを大部分実施するビジョンステートメントを発表しました。ビジョンの主な要素は次のとおりです。
テクニカルコミュニティは、合理的で、比較可能で、再現性があり、費用効果の高い評価結果という目標をサポートする保護プロファイル（PP）の作成に重点を置きます。
可能であれば、これらのPPに対して評価を行う必要がそうでない場合、セキュリティターゲット評価の相互承認はEAL2に限定されます

も参照してください
ベルラパドゥラモデル
中国強制証明書
評価保証レベル
FIPS 140-2
情報保証 ISO 9241 ISO / IEC 27001
ユーザビリティテスト
検証と妥当性確認

参考文献
^ 「コモンクライテリア」。
^ 「コモンクライテリア-通信保安局」。
^ 「コモンクライテリア認定製品」。
^ 「世界中のコモンクライテリアスキーム」（PDF）。
^ アンダーアタック：コモンクライテリアには多くの批評家がいますが、されたGovernment ComputerNewsが大騒ぎしています。
^ Free-Libre /オープンソースソフトウェア（FLOSS）およびソフトウェアアシュアランス
^ Wäyrynen、J.、Bodén、M。、およびBoström、G。、セキュリティエンジニアリングとエクストリームプログラミング：不可能な結婚？
^ Beznosov、Konstantin; クルーシュテン、フィリップ。「アジャイルセキュリティ保証に向けて」。アーカイブされたオリジナルの2011年8月19日に。
^ コモンクライテリアはRealpolitikを満たしています–信頼、同盟、および潜在的な裏切り
^ Parsovs、Arnis。エストニアの電子IDカードとそのセキュリティの課題（PhD）。タルトゥ大学。pp。141–143。
^ 「CAPS：CESG支援製品スキーム」。2008年8月1日にオリジナルからアーカイブされました。
^ インフォセック保証と認証サービス（IACS）のアーカイブで2008年2月20日、ウェイバックマシン
^ 「コモンクライテリア改革：業界との協力の強化によるより良いセキュリティ製品」（PDF）。2012年4月17日にオリジナル（PDF）からアーカイブされました。
^ 「コモンクライテリアの「改革」—沈むか泳ぐか-業界はコモンクライテリアで革命醸造をどのように扱うべきか？」。2012-05-29にオリジナルからアーカイブされました。

外部リンク
コモンクライテリアプロジェクトの公式ウェブサイト
コモンクライテリア標準文書
コモンクライテリア評価製品のリスト
認可されたコモンクライテリア研究所のリスト
アジャイルセキュリティ保証に向けて
重要なコモンクライテリアの頭字語
コモンクライテリアユーザーフォーラム
GoogleKnolに関する追加のコモンクライテリア情報
OpenCCプロジェクト–無料のApacheライセンスCCドキュメント、テンプレート、ツール
コモンクライテリアクイックリファレンスカード
コモンクライテリアプロセスのチートシート
コモンクライテリアプロセスのタイムライン

「https://en.wikipedia.org/w/index.php?title=Common_Criteria&oldid=1060076446」
から取得”