はじめに
SSPは、CMMC対応で最も重要な文書の一つです。しかし、多くの企業はSSPを「監査用に作る文書」または「テンプレートを埋める作業」として扱います。
それは危険です。
SSPは、評価者に見せるためだけの文書ではありません。CUIを扱うシステムが、どこまでを境界とし、どの要求をどの仕組みで満たし、誰が何に責任を持つのかを説明する設計文書です。
結論
SSPとは、System Security Planの略で、対象システムの境界、運用環境、処理・保存・送信される情報、セキュリティ要求の実装方法、他システムとの接続、役割と責任を説明する文書です。NIST SP 800-171 Rev.3では、System Security Planは、システム構成要素、情報タイプ、運用環境、接続、セキュリティ要求、保護策、役割と責任などを含むものとして扱われています。参考: NIST SP 800-171 Rev. 3 HTML – System Security Plan and POA&M sections
CMMCでは、SSPはCUI Boundary、資産分類、外部サービス、Customer Responsibility Matrix、証跡をつなぐ中核文書です。
SSPはなぜ重要なのか
CMMC評価では、評価者が「この組織はCUIをどのように守っているのか」を追跡できる必要があります。
SSPがなければ、評価者は次のことを判断できません。
- 評価対象システムはどこからどこまでか
- CUIはどこで処理・保存・送信されるか
- CUIを直接扱う資産は何か
- CUI環境を保護する資産は何か
- どのNIST/CMMC要求をどの技術・運用で満たしているか
- 外部サービスはどこまで責任を持つか
- 例外や制約はどこにあるか
- 証跡はどこに存在するか
SSPは、CMMC評価のための目次であり、システム設計の説明書であり、責任分界の文書です。
SSPに書くべきこと
1. システム境界
まず、どこからどこまでがCMMC Assessment Scopeなのかを明確にします。
これはネットワーク図だけではありません。ユーザー、端末、サーバー、クラウドサービス、アプリケーション、ストレージ、ログ、ID基盤、管理者端末、外部サービス、物理拠点まで含めて境界を定義します。
また、SPRSへCMMC評価結果を登録する実務では、CMMC Assessment Scopeで扱われる情報システムに関連するCAGE code(s)が関係します。SSPでは、評価対象システム、法人・拠点、CAGE / NCAGE、SAM.gov登録主体、SPRS登録内容が矛盾しないように整理しておくことが重要です。
2. CUIデータフロー
CUIがどこで作成され、どこに保存され、誰に送信され、どこで削除されるのかを示します。
CUIデータフローがないSSPは、CUI環境の説明として弱いです。CUIを守るには、CUIがどこにあるかだけでなく、どこへ流れるかを理解する必要があります。
3. 資産分類
CMMC Level 2では、CUI Asset、Security Protection Asset、Contractor Risk Managed Asset、Specialized Asset、Out-of-Scope Assetなどの分類が重要です。
32 CFR Part 170は、Level 2のCUI AssetやSecurity Protection Assetを資産台帳、SSP、ネットワーク図に文書化することを求めています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program
SSPには、単に資産名を書くのではなく、その資産がなぜその分類なのか、どの要求に関係するのかを説明する必要があります。
4. 要求事項ごとの実装
SSPでは、各要求について、どの技術、どの運用、どの手順、どの責任者で実装しているかを説明します。
たとえば、MFAであれば、どのID基盤で、どのユーザーに、どのアクセス経路で、どの例外管理で、どのログに残るのかを説明します。
ログ管理であれば、どのイベントを収集し、どこに保管し、誰が監視し、どの期間保持し、どのインシデント対応に接続するのかを説明します。
「有効にしている」だけでは、SSPとして不十分です。
5. 外部サービスと責任分界
CMMC環境では、CSP、MSP、SOC、EDR運用、SIEM、バックアップ、ヘルプデスク、脆弱性管理など外部サービスが関与することがあります。
32 CFR Part 170は、ESPを使用する場合、そのサービス、OSAとの関係、サービス内容をSSPに記載し、ESPのサービス記述やCustomer Responsibility Matrixで説明することを求めています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program
日本企業の場合、日本本社が米国子会社のITを支援するケースもあります。この場合、日本本社は外部サービス提供者に近い位置づけになる可能性があります。SSPでは、誰が何を実装し、誰が何を監視し、誰が何を証跡として提供するのかを明確にする必要があります。
SSPとネットワーク図・資産台帳の整合性
SSPは単独で成立しません。資産台帳、ネットワーク図、CUIデータフロー、アクセス権一覧、ログ設計、ポリシー、手順書と整合している必要があります。
たとえば、SSPには「CUIはSharePointに保存する」と書いてあるが、実際にはメール添付、ローカル端末、Teamsチャット、バックアップ、Gitにも存在する場合、SSPは実態を説明していません。
また、SSPには「SIEMで監視する」と書いてあるが、どのログソースがSIEMに送られているか、誰が監視しているか、インシデント時にどう対応するかが不明なら、要求実装として弱いです。
SSPは、実環境と一致して初めて価値があります。
SSPとPOA&Mの関係
SSPは、未達項目を隠すための文書ではありません。実装済みの要求、計画中の要求、例外、制約を正直に整理する文書です。
ただし、CMMCではPOA&Mに入れられる項目に制限があります。32 CFR Part 170では、Level 2のConditional statusにおいてPOA&Mが許容される条件を定めていますが、System Security Plan要求はPOA&Mに含められない項目の一つとして明記されています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program
つまり、SSPが未完成のまま「後でPOA&Mで対応する」という進め方はできません。
日本企業におけるSSPの難所
日本企業では、SSP作成時に次の点が難所になります。
第一に、米国子会社と日本本社の境界です。米国子会社がCUIを扱い、日本本社がID、ネットワーク、SOC、EDR、ヘルプデスクを管理している場合、SSPは米国子会社だけで完結しません。
第二に、グローバル共通ITです。CUI環境だけを分離するのか、既存のグローバルテナントを使うのか、管理者権限をどう制限するのかを設計する必要があります。
第三に、クラウド責任分界です。CSPが何を担い、顧客が何を担い、MSPが何を担うのかをCRMで明確にする必要があります。
第四に、輸出管理との接続です。CUI、ITAR、EARは同じではありません。しかし、防衛技術情報では重なる領域があります。SSP上でCUI保護を設計する際、輸出管理上のアクセス制限やUS Person要件も別途確認する必要があります。
よくある誤解
第一の誤解は、「SSPは監査前に作ればよい」というものです。SSPは後付けの作文ではなく、実装と運用の説明書です。評価直前に作ると、実態との不整合が出ます。
第二の誤解は、「テンプレートを埋めればSSPになる」というものです。テンプレートは形式を助けるだけです。実際のCUIデータフロー、資産分類、責任分界が入っていなければ、SSPとしては弱いです。
第三の誤解は、「SSPはIT部門だけで作れる」というものです。SSPには契約、CUI識別、物理管理、人事、外部委託、インシデント対応、経営責任が関係します。
第四の誤解は、「SSPは一度作れば終わり」というものです。SSPはシステム変更、外部サービス変更、CUIデータフロー変更、スコープ変更に合わせて更新する必要があります。
本質
SSPの本質は、CUIを保護するシステム設計と責任分界を、評価可能な形で記述することです。
SSPは文書ではありますが、単なる文書ではありません。CUI環境の設計、運用、証跡、責任を結びつける中心構造です。
まとめ
SSPは、CMMC対応の中心文書です。システム境界、CUIデータフロー、資産分類、要求事項の実装、外部サービス、責任分界、証跡の所在を説明します。
日本企業がSSPを作る際は、テンプレートからではなく、CUI Boundaryと責任分界から始めるべきです。SSPが実環境を正しく説明できていれば、CMMC対応は大きく前進します。逆に、SSPが曖昧なら、どれだけツールを入れても評価上の説明力は不足します。
次の記事
次は「POA&Mとは何か」です。未達項目をどう扱うべきか、CMMCにおけるPOA&Mの制限と本質を整理します。