CMMC の旅を軌道に乗せる方法

最新の Cybersecurity Maturity Model Certification（CMMC）がようやく施行され、セキュリティ担当者がその要件を満たすために、どのように最新状況にキャッチアップすべきかについては、議論すべきことがたくさんあります。

このブログは誰向けですか？

国防総省（DoD）向けに、プライム（主契約）またはサブコントラクター（下請）として活動している組織に勤めていますか？貴社は Defense Industrial Base（DIB）のメンバーですか？貴社は Controlled Unclassified Information（CUI）および／または Federal Contract Information（FCI）を管理していますか？貴社の組織を CMMC 準拠にするよう割り当てられましたか？

上記のどれかの質問に「はい」と答えた場合は、このこの記事があなたのためのものです。

これは何についてですか？

このブログでは、CMMC 準拠プロジェクトを最初の日から最適に進める方法を理解できるようにすることを目的としています。CMMC についてさらに詳しく知りたい場合は、この DOD article。

バージョン 1 から大きく変わりました

現在は CMMC バージョン 3 です。元のものからの最大の違いは、準拠する組織に求められるセキュリティ要件のレベルをどのように分類しているかにあります。全体としてレベルは 3 つで、扱っているデータの重大度（深刻度）に応じて、より高いレベルへの準拠が必要になる可能性が高くなります。

レベル 1: 基本的なセキュリティ衛生（security hygiene）技術 15 個で構成され、FCIに重点を置きつつ、CUIのセキュリティには重点を置きません。

レベル 2: NIST SP 800-171 からそのまま引用されたNIST SP 800-171 の 110 の要件で、CUI の保護に重点を置いています。

レベル 3: NIST SP 800-172 からの 134 の要件で、再び CUI に焦点を当てていますが、最大の違いは、導入するすべてのツール、ポリシー（policies）、手順（procedures）は DoD の承認が必要だという点です。

いいですね。じゃあ次は何をすればいいでしょう？

つまり、各レベルが何なのかは分かりましたが、貴社にとってどれが該当するのかを判断するには、それを整理して理解する必要があります。そのために、まず管理しているデータの種類を評価しましょう。

参考のために、連邦契約情報 FCI および 管理対象の非機密情報 CUI の公式な政府定義を以下に示します。

要するに、FCIとは、公開向けに提供することを意図していない、DoD 契約に基づいて米国政府のために提供または作成される情報のことです。契約の仕様、技術提案、社内のプロジェクト報告書、または DoD 機関との連絡などが該当します。

一方で、CUI とは、連邦法、規則、方針に基づいて保護が必要な、機密指定はされていないものの機微な情報のことです。技術図面、図解（スキーマティック）、工学データの輸出規制対象情報（ITAR、EAR など）、人事記録や PII（例：軍の人員情報）、調達書類（RFP、契約書、DoD の報告書）など、あらゆるものが該当します。

自分はどのレベルに該当しますか？

CMMC 準拠プロジェクトを開始する最初の段階で行うべき最善のことは、組織が管理している情報の種類を決めることです。それは FCI ですか、CUI ですか、それとも両方でしょうか？情報が FCI のみであれば、シンプルにレベル 1 の CMMC に準拠すれば足ります。もし CUI であれば、その次は重大度（深刻度）によって決まります。保有している情報が、いかなる形であっても米国の国家安全保障を脅かす可能性があるのであれば、おそらくレベル 3 を目指す必要があります。そうでなければ、レベル 2 が最適な選択肢です。

どうやって判断すればいいですか？

最初に最適なのは、data classification を全体のインフラに対して実施することです。保有しているすべてのデータ、どこに存在しているか、そして誰がそれにアクセスできるかを特定します。そうすることで、まずすべてを正確にラベリングできます（例：PIIなのか、FCIなのか、CUIなのか）。次に、それに対して機密性レベルを割り当てます。つまり、そのデータがビジネス上または国家にとってどれほど重要かを示します。さらに、自社環境の中でデータが現在どこに置かれているかを確認できます。公開アクセスにさらされているでしょうか？最後に、誰がどの程度までアクセスできるのかを定義します。適切な分類には、昔ながらの権利（権限）ベースの redaction（マスキング/編集）が必ず伴うべきです。

避けたいのは、最終的にあなたのデータの一部が War Thunder のフォーラムに掲載されてしまうこと です。

まず1つクリア。あとは少なくとも109個残っています

データは何か、どこにあるのか、そして誰がアクセスできるのかを特定することは素晴らしい出発点ですが、面白いことはここからです。すでにCMMCを少なくとも5回読んだという経験から言うと、NIST 800-171と172の違いは思っているほど大きくありません。171にすでに存在する24の追加要件を、より厳格な形式で説明しただけだからです。

どのレベルを目標にするにせよ、最もおすすめなのはまず「レベル2」として扱うことです。もしそれより低くする必要があるなら、自分に関係する15の要件に絞って取り組めば十分です。とはいえ、800-171に沿って進める価値はあります。後でレベル2へ移行する際がずっと楽になるからです。一方で、最初にレベル2を満たすだけでなく、より高い目標を目指す必要があるなら、まずレベル2に到達し、その後残りを調整すればよいでしょう。どちらの場合も理由はシンプルさと、長期的に見たときの移行のしやすさです。

どうやってお手伝いしますか？

組織がコンプライアンスを満たすために、私たちがどのように支援できるのかを触れずに終わるのは、仕事としても不十分です。もしどこかの会社が「コンプライアンスに関するあらゆるニーズはすべて解決します」と言ってきたら、たいていの場合、それは嘘をついている可能性が高いでしょう。残念ながら、いわゆる“ワンボックス（1つの箱）”で完結するコンプライアンス・ソリューションは存在しません。

しかし、Netwrix のような企業は複数のソリューションを提供しており、それぞれが異なるセキュリティおよび規制分野をカバーしています。これらを組み合わせることで、800-171 または 172 ベースのいずれであっても、CMMC 要件のかなりの部分をカバーできます。

当社のポートフォリオが CMMC の要件をどのようにサポートしているかを、簡単にまとめました。さらに詳しく知りたい場合は、詳細なコンプライアンス・マッピング資料をご覧ください こちら。