筆者:土橋俊夫

 CMMC 2.0の概要が発表され早2ヶ月が過ぎました。12月3日付けでその内容の一部がホームページに公開され、引き続きアセスメントに関する詳細な内容も順次公表されています(12月10日にはレベル1の詳細、12月16日にはレベル2の詳細が発表されました)。

 発表されたCMMC 2.0の内容と注視すべき動向について以下に報告します。

 請負業者や下請け業者に要求されるCMMCのレベルは、募集要項やRFI(Requests for Information)で指定され、CMMC 2.0では、情報を保護するというプログラムの当初の目標を維持しながら、次のことを行うとされています。

  1.  CMMC基準を簡素化し、サイバーセキュリティの規制、ポリシー、および契約要件を明確にする。
  2.  最も優先度の高いプログラムに対応する企業に焦点を当て、最先端のCMMC基準と第三者の評価要件を明確にする。
  3.  企業がCMMC基準を実装するための説明責任を確保する。

 結果として、我々がCMMC 1.0に対して危惧していた「認証対象の数が多すぎて現実的ではない」という課題が大きく改善されたと思われます。しかしながら今回の発表後の様子を見ていると、認証に関して様々な意見が提示され、発表直後にホームページの差替えが行なわれるなど、関係部門間における検討・調整が不十分であったことが伺えます。一例を挙げれば、DoDの情報に基づいて公開された様々なWebサイトにおいて「第三者認証に関する実施間隔が誤って報じられた」事(One TERM参照)があります。

 現状でも細部にわたっての実施要領等不明な部分も多く、今後も運用開始まで揺り戻し等想定される状況といえますが、現時点においてCMMC 2.0とはどのようなものか整理するとともに、今後の動きを正確に把握するために注視すべき動向についてまとめました。

 上の図はCMMCのホームページに掲載されたものです。主な変更点は以下の通りですが、具体的な内容については、今後公開される模様です。

  1. レベルの区分が、5段階から3段階に整理。マチュリティモデルプロセスを排除
  2. CMMC 1.0のレベル3はCMMC 2.0のレベル2となり、要件はCMMC独自部分を排除した110項目に整理
  3. CMMC 2.0のレベル3はNIST SP 800-172ベースとなり、今後開発
  4. CMMC 2.0のレベル1とレベル2は自己評価。さらに、レベル2のうち重要な国家安全保障に関連する情報を扱うプロジェクトに関しては、3年毎に第三者評価。レベル3の評価は政府機関により実施
  5. POA&M(Plan of Action & Milestones)の利用を認める

 以上の変更により、新しいCMMC 2.0では従来のレベル2およびレベル4がなくなり、全体のレベルが5段階から3段階に整理されました。

 レベル1はFCI(Federal Contract Information)対応、レベル2はCUI(Controlled Unclassified Information)対応、レベル3はAPT(Advanced Persistent Threat)対応と、各レベルの性格がよりはっきりしたといえます。CMMC固有の要求やマチュリティモデルプロセスの排除を明確にしたことにより、NIST SP 800シリーズへの準拠性が明確になりました。

 また、CMMC 1.0レベル3で求められていた「NIST SP 800-171以外に付加されていた20要件」がCMMC 2.0レベル2では削除され、NIST SP 800-171の要件のみになりました。この変更は、従来からNIST SP 800-171対応を進めてきた事業者にとっては、新たな項目への対応を行うことなくCMMC 2.0レベル2に対応することが容易になったことを意味します。

 認証に関する要件は大幅に緩和(第三者機関による認証は、レベル2の一部に限定等)され、これにより多くの事業者にとって、CMMC 2.0への対応がさらに容易になったといえます。しかし、一方では「緩和しすぎだ」との意見も出ており、この点はCMMC 2.0の仕組みが確立するまで動向を注視する必要があります。

 また、CMMC 1.0では認められていなかったPOA&Mの利用が、範囲は限られるとはいえ認められることになりました。これは、DoD Assessment Methodologyで組み込まれたSPRS(Supplier Performance Risk System)の仕組みと整合性が取れた施策であり、100%の要件対応を求めたCMMC 1.0により現実的な修正を加え、事業者にとって受け入れやすいものにしたといえます。

 DoDは、定義されたタイムライン内で未達成の要件をPOA&Mで処理できるようにするために、契約締結前に達成する必要のある要件のベースライン数や、POA&Mに含めることができない要件の指定を予定しています。

 そして、SPRSへの登録等も当面、DoDの調達条件のDoD Assessment Methodologyで求められるものと同等であるならば、セキュリティに対する要求のCMMCへの移行がより容易になったと考えられます。言い方を変えれば、DoD Assessment Methodologyの仕組みを、ほぼそのままCMMC 2.0に取り込んだといえます。

 これらのルール作成への取り組みが進行していく今後9ヶ月から2年程度の間、DoDは現在のCMMCパイロットの取り組みを一時停止する予定であり、DoDの契約条件にCMMC要件が含まれることはないと思われます。しかしながら、情報セキュリティの脅威が日々増大している今、すでにNIST SP 800-171対応に着手している事業者は、CMMCの詳細部分の明確化を待つことなくその対応を進めることが、誤りなく情報セキュリティ対策を向上させる上で重要です。

 以上がCMMC 2.0の概要となります。続いて、今後注視すべき4つの項目について示します。

  1. 評価に関しては、CMMC 1.0に比べてCMMC 2.0では自己評価が大幅に取り入れられています。レベル1、2については全て自己評価、さらにレベル2においては、重要な国家安全保障情報に関連するプロジェクトに関して、3年毎に第三者評価を受査するという形になります。
     DoD担当者によれば、「受査する企業数は当初想定の22万社から4万社と1/5程度かそれ以下になる」とのことで、当初想定された膨大な受査数はCMMC 1.0実現の大きな課題でしたが、現実的な受査数になったといえます。
     しかし現在までのところ、12月1日のCMMC-AB(CMMC Accreditation Body)リモートミーティングでも、DoDが提示した認証のフレームワークは示されましたが、評価の具体的な実施要領等についての発表はなく、DoDの詳細発表待ちの感が強いです。またレベル2における自己評価と第三者評価の仕切りをどのようにするかも明確ではなく、事業者にどのような影響が出るかDoD、CMMC-ABの今後の発表を注視していく必要があります。
  2. CMMCの仕組みをDoDの調達に反映させるための法規類についても変更が出る可能性があり、特に現在のところ言及のない「2025年CMMC全面適用を目指したルール(DFARS252.204-7021)」等がどのように変わるのかについて注視する必要があります。
  3.  CMMC 2.0の要件をNIST標準に合わせた結果、基礎となるNIST SP 800-171およびNIST SP 800-172の要件に変更が加えられるとCMMC要件が変化することになるため、NIST標準の要件の変更を注視していく必要があります。特にNIST SP 800-171は、以前から「発表されたNIST SP 800-53の新バージョン(Revision5)に基づいてRevision3を開発する」と公表されており注意が必要で、さらに最近のDoD担当者の言によれば、「必要に応じて標準の変更を依頼することもある」とのことで、NIST標準の変更動向には注意が必要です。
  4.  CMMC 2.0のレベル3は開発中であり、今後発表される内容について、特にこれらの高いレベルを必要とする可能性のある事業者は注視する必要があります。

 以上、とりいそぎCMMC 2.0の現状と注視すべき状況についてまとめました。今後も、上記で記述した注視すべき状況に焦点を当て、継続してCMMCに関する情報の収集・調査の上、速やかに公表していく予定です。

 最後になりますが、12月16日までに発表されたアセスメントガイドについて、簡単に触れておきます。これらの項目についても、必要に応じて情報を公開します。

  1. 従来から公表されていた資料にありました通り、その管理策はNIST SP 800-171 を基本的に踏襲し、評価要領もNIST SP 800-171Aをそのまま引用しています。ただし管理策の「system」「information system」に変更されています。NIST SP 800-171の用語集によれば両者の意味は同じであると解説されていますが、NIST SP 800-171開発の流れの中で「information system」を「system」に置き換えてきた経緯からすると多少の違和感があり、その意図についても注視していく必要があります。
  2. 発表されたSCOPE文書によると、CMMCレベル2における管理すべき情報資産として「請負業者のリスク管理資産(CUIを扱う能力はあるが、扱わないように設定されている資産)」等が含まれており、これらもSSP(System Security Plan)に記載することが求められているため、その範囲は気になるところですが、詳細は現在明らかになっていません。

以上

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA