効果的なシステムセキュリティ計画（SSP）の書き方：CMMCコンプライアンスへの戦略的アプローチ

システムセキュリティ計画 (システムセキュリティ計画) は、防衛請負業者が制御されていない分類情報 (CUI) を取り扱い、共有し、保存する準備ができているかどうかを判断する上で重要な役割を果たします。そのため、サイバーセキュリティ成熟度モデル認証 (CMMC) のコンプライアンスプロセスにおいて重要な部分です。

効果的なSSPの準備には、情報資産を保護するために組織が採用するセキュリティ対策と実践を文書化するための包括的なアプローチが必要です。CMMCのためのSSPを作成するには、具体的なセキュリティコントロールを詳細に記述し、責任ある役割を割り当て、システムの境界を明確にすることが含まれます。

さらに、システムインフラストラクチャやセキュリティ体制の変更を反映するために、SSPを定期的に更新することが重要です。これらの領域を注意深く対処することで、組織はCMMC評価の準備を強化し、CUIを保護するために設定された厳格な基準を満たすことができます。

この包括的なガイドは、SSPが単なる文書以上のものである理由を明らかにし、CMMC認証の取り組みを成功させるための戦略的基盤となることを示しています。

システムセキュリティ計画 (SSP) とは何か？

システムセキュリティ計画は、組織のセキュリティ要件の包括的な概要を提供し、それらの要件を満たすために実施されている、または計画されているコントロールを説明する正式な文書です。制御されていない分類情報 (CUI) を取り扱う防衛請負業者にとって、SSPは特に、NIST 800-171 に記載されたセキュリティ要件をどのように実施しているかを文書化します。

SSPは単なるコンプライアンスのチェックボックスではなく、組織のサイバーセキュリティ体制の権威ある記録として機能し、以下を詳細に記述します：

• 情報システムの境界
• そのシステム内で実施されているセキュリティコントロール
• それらのコントロールがどのように実施されているか
• セキュリティの維持に責任を持つ人
• セキュリティプログラムが日常的にどのように運用されているか

国防総省 (DoD) がCMMCを通じてサプライチェーンのセキュリティを強化する中で、SSPは静的な文書からセキュリティプログラムの生きたロードマップへと変わります。

SSPとセキュリティポリシーの違い

関連はありますが、システムセキュリティ計画 (SSP) と組織のセキュリティポリシーは異なる目的を果たします。

セキュリティポリシーは、組織全体のセキュリティに対する管理の意図、期待、および包括的なルールを確立する高レベルの文書です。ポリシーは「何を」定義します。例えば、ポリシーは「機密データリポジトリへのアクセスは最小特権の原則に基づいて制限されなければならない」と述べるかもしれません。ポリシーは方向性とガバナンスの枠組みを設定します。

対照的に、システムセキュリティ計画は、CUIを取り扱う特定の情報システムのセキュリティコントロールの実施に関する「どのように、どこで、いつ、誰が」を詳細に記述するシステム固有の文書です。ポリシー要件を具体的な行動に変換し、定義されたシステム境界内で実施します。例えば、上記のポリシー例に対応して、SSPは次のように詳細に記述します：「CUIファイル共有 (\\SERVER01\CUI_Data) へのアクセスは、Active Directoryセキュリティグループを介して制御されます。IT管理者のジェーン・スミスが管理する「CUI_Users_ProjectX」グループは、読み取り/書き込みアクセスを許可します。アクセス要求はサービスデスクチケット (手順SD-015) を介して管理者の承認を必要とし、データオーナーのマーク・リーによって四半期ごとにレビューされます。」

SSPを単なるポリシーの集合と見なすのは一般的な誤解ですが、実際には特定のシステムのセキュリティ体制を記述する包括的な実施計画であり、ポリシーを参照しながらも、特にCMMC評価のためのSSPにおいてコンプライアンスを示すために必要なはるかに深い運用の詳細を提供します。

SSPが重要な理由

よく作成されたSSPの重要性は、単なるコンプライアンスを超えています。SSPは、セキュリティリスクを特定、評価、管理するための体系的なアプローチを提供する包括的なリスク管理ツールとして機能します。セキュリティコントロールを徹底的に文書化することで、潜在的な脆弱性への可視性を確保し、それらが悪用される前に対処するための堅牢な枠組みを確立します。

技術チームにとって、SSPは環境全体でセキュリティコントロールの展開と構成を指示する権威ある実施ガイドとして機能します。このガイダンスは、セキュリティ実施の一貫性を確保し、脆弱性を引き起こす可能性のある構成のずれを防ぐのに役立ちます。CMMC評価中、この同じ文書が評価者に対して組織が必要なセキュリティ実践を実施していることを示す主要な証拠となります。

技術的およびコンプライアンス機能を超えて、SSPはビジネス継続性資産としても機能し、重要な情報を保護し、セキュリティインシデントからの迅速な回復を可能にするセキュリティ手順を文書化することで、運用の回復力を確保します。おそらく最も重要なのは、SSPが技術スタッフ、管理者、外部評価者間の理解を促進するためのセキュリティプログラムを明確に表現するコミュニケーションブリッジとして機能することです。

不十分なSSPは、評価の失敗、認証の遅延、契約の喪失、最終的には財務的損失につながる可能性があります。逆に、よく開発されたSSPは、認証への道を加速し、コンプライアンスを超えた持続的なセキュリティの利点を提供します。

CMMCレベルにおけるSSP要件

どのCMMCレベルがSSPを必要とするかを理解することは、コンプライアンス計画において重要です：

• CMMCレベル1: レベル1認証にはSSPは必要ありません。組織は17の基本的な保護実践を実施する必要がありますが、SSP形式での正式な文書化は必須ではありません。
• CMMCレベル2: レベル2認証にはSSPが必要です。組織は、NIST SP 800-171から派生した110のセキュリティ実践の実施を文書化する包括的なSSPを開発し、維持する必要があります。
• CMMCレベル3: レベル3認証にはSSPが必要です。このレベルのSSPは、レベル2の要件を超えた追加の高度なセキュリティ実践の実施を文書化する必要があります。

レベル2またはレベル3の認証を目指す組織にとって、SSPは評価中にC3PAOが評価する基本的なアーティファクトとして機能します。これは、評価者がサイバーセキュリティの実施をガイドし、セキュリティ要件の理解を示すロードマップを提供します。

評価プロセス中、SSPは成功した認証の基盤として機能します。評価者が施設に到着する前に、彼らはSSPを徹底的にレビューして環境を理解し、評価アプローチを準備します。この文書がセキュリティプログラムの第一印象となります。評価が進むにつれて、評価者は文書化されたコントロールを実際の実施と比較して整合性を確認し、SSPを複雑なセキュリティ環境のロードマップとして使用します。

SSPと実施されたコントロールの間に発見された不一致は、修正が必要な潜在的なギャップとしてフラグが立てられ、重大または多数の場合、認証を危険にさらす可能性があります。明確で包括的なSSPは、このプロセスを大幅に簡素化し、評価時間と関連コストを削減し、組織のセキュリティ成熟度を示します。完全なコンプライアンスがまだ達成されていない場合、SSPは評価者の要件を満たす現実的で効果的な行動計画とマイルストーン (POA&M) を開発するための重要なコンテキストを提供します。

CMMC認証の成功のためには、SSPは正確で包括的であり、実際のセキュリティ実践を反映している必要があります。評価者は「文書化したことを実行し、実行したことを文書化している」ことを確認します。

CMMC認証プロセスは困難ですが、私たちのCMMC 2.0コンプライアンスロードマップが役立ちます。

CMMC SSPのためのNIST SP 800-171の基盤

CMMCレベル2および3に必要なシステムセキュリティ計画は、NIST 800-171、「非連邦システムおよび組織における制御されていない分類情報の保護」に記載された要件から直接派生しています。このNIST標準は、CMMCのセキュリティ要件の基盤を形成します。

具体的には、CMMCレベル2はNIST SP 800-171に詳細に記載された110のセキュリティコントロールに直接対応しています。NIST SP 800-171自体の中核要件 (コントロール3.12.4、セキュリティ評価ファミリー) は、組織が「システムの境界、運用環境、セキュリティ要件の実施方法、および他のシステムとの関係または接続を説明するシステムセキュリティ計画を開発、文書化、維持する」ことを義務付けています。したがって、CMMCのためのSSPは、CUI保護に焦点を当てたNIST SP 800-171システムセキュリティ計画です。

NIST SP 800-171付録Eは、この計画のための推奨される内容と構造を提供し、システム識別、運用環境、およびセキュリティ要件の実施などの主要セクションを概説しています。CMMCのためのSSPを開発する組織は、NIST SP 800-171および関連するNISTリソース (NISTハンドブック162などの評価手順) を活用して、すべての必要な要素が包括的に対処されていることを確認する必要があります。評価者はこれらの基礎的な基準に対してSSPを評価します。

効果的なSSPの主要コンポーネント

コンプライアンスに準拠し、有用なSSPには、セキュリティプログラムの包括的なビューを提示するために協力するいくつかの重要な要素が含まれています。その基盤として、SSPは、情報システムの目的、境界、および相互接続を明確に表現する徹底的なシステム識別と境界定義を含む必要があります。この基礎セクションには、詳細なネットワーク図、データフロー図、およびシステムインベントリが含まれ、CUI環境を一般的なビジネスシステムから正確に区別します。

SSPの中心は、セキュリティコントロールの実施記述にあります。各適用可能なNIST 800-171コントロールについて、SSPは、コントロールがどのように実施されているか、どこでコンポーネントまたはシステム全体で実施されているか、コントロールの維持に責任を持つ人、コントロール活動がいつ実行されるか、コンプライアンスを示す具体的な証拠は何かを説明する詳細な記述を提供する必要があります。これらの実施記述は、認証中に評価者が評価する主要なコンテンツを形成します。

SSPはまた、セキュリティプログラムをサポートする組織構造を文書化し、特定のセキュリティ役割、責任、および主要な担当者の連絡先情報を詳細に記述する必要があります。これに加えて、ハードウェア、ソフトウェア、ネットワークアーキテクチャ、セキュリティドメイン、および環境を定義する信頼関係をカバーする包括的な情報システムアーキテクチャの説明が必要です。

システムの運用コンテキストも同様に重要です。SSPは、システムが運用される技術的、物理的、および人員のセキュリティ環境を徹底的に文書化し、CUIがライフサイクル全体でどのように識別、マーク、処理、保存、処理、送信されるかの具体的な詳細を含める必要があります。このデータセキュリティセクションは、CUI保護に焦点を当てたCMMC評価において特に重要です。

継続的なセキュリティへの取り組みを示すために、継続的なコントロール評価、脆弱性管理、およびセキュリティステータス報告へのアプローチを概説する詳細な継続的監視戦略を含めます。最後に、コントロール実施の主張を裏付け、評価者に追加のコンテキストを提供するポリシー、手順、および技術的構成などのすべてのサポート文書を参照します。

SSPは、管理の監視と技術的な実施の両方を促進するように編成され、サイバーセキュリティプログラムの単一の真実の源として機能する必要があります。

SSP評価プロセスと基準

CMMC評価中、CMMC第三者評価機関 (C3PAO) はシステムセキュリティ計画 (SSP) を厳密に評価します。

プロセスは通常、評価者がSSPの完全性、明確さ、および明らかな正確性を精査する事前評価文書レビューから始まります。彼らは特に、各適用可能なCMMC実践 (レベル2のためにNIST SP 800-171から派生) の詳細な説明、明確に定義されたシステム境界、システム環境の正確な描写、責任者の特定、およびサポート証拠 (ポリシー、手順、構成) への参照を探しています。

SSPが評価に失敗する一般的な理由には、曖昧または一般的なコントロールの説明、実践文書の欠如、現在の環境と一致しない古い情報、定義が不十分または不正確なシステム境界、参照されていない証拠、または未熟な行動計画とマイルストーン (POA&Ms) への過度の依存が含まれます。

文書レビューの後、評価自体 (しばしばオンサイトまたはリモートコンポーネントを含む) 中に、評価者は主要な担当者 (ITスタッフ、管理者、ユーザー) とのインタビューやシステム構成の検査、プロセスの観察、ログのレビュー、物理的なセキュリティ対策の検査などの技術的な検証方法を通じてSSPの主張を検証します。彼らは組織が「文書化したことを実行している」ことを確認しています。

認証準備が整ったシステムセキュリティ計画は、最新で包括的で非常に詳細であり、実施されたコントロールを正確に反映し、サポート証拠を直接参照し、評価インタビューと技術的チェック中に確認された運用の現実と完全に一致しています。

効果的なSSPを書くためのトップ10のベストプラクティス

数百の防衛請負業者を評価した経験に基づいて、CMMC認証の取り組みをサポートするSSPを開発するための重要なベストプラクティスを以下に示します：

1. 明確なシステム境界を定義する

CUI環境の範囲内と範囲外を正確に区別します。多くの評価の失敗は、コントロールが適用されるべき場所について評価者が不確かになる曖昧な境界から生じます。

推奨アプローチ: CUI環境の境界を正確に特定し、すべての出入口、セキュリティドメイン、および信頼関係を明確に視覚的に区別する詳細なネットワーク図を作成します。CUI環境を一般的なビジネスシステムから区別するために、カラースキームなどの一貫した視覚的コーディングを使用し、境界をチームと評価者の両方に即座に明らかにします。これらの図は、CMMCコントロールの範囲内に含まれるシステムについて曖昧さの余地を残さない明示的なテキスト説明で補完されるべきです。環境が変化するたびにこれらの境界定義を更新し、認証の旅を通じて正確性を維持します。

避けるべき落とし穴: CUI処理に不必要なシステムを含むように境界を広げすぎないでください。これにより、コンプライアンスの範囲が不必要に拡大します。

2. 詳細なコントロール実施記述を提供する

「暗号化を使用している」や「ファイアウォールを持っている」といった一般的な声明は不十分です。評価者は、各コントロールが環境内でどのように実施されているかについての具体的な詳細を必要とします。

推奨アプローチ: 各コントロールについて、特定の環境内でコントロール目標がどのように達成されているかを正確に説明する包括的な記述を開発します。セキュリティ要件を満たすために使用される正確な技術やプロセスを詳細に記述し、ベンダー名、バージョン、特定の構成を含めます。各ソリューションがどのように構成され、管理されているかを説明し、単なる技術の言及を超えて運用プロセスを説明します。これらのコントロールが効果的であるかどうかを監視し、コンプライアンスを確保するためにどのくらいの頻度でレビューされるかを文書化します。技術的な専門性を十分に含め、他のセキュリティ専門家が追加の説明を必要とせずに実装を理解し、検証できるようにします。

例: アクセスコントロール (AC.L2-3.1.1) の場合、「システムアクセスを認可されたユーザーに制限する」と述べる代わりに、次のように詳細を提供します：「CUIシステムへのアクセスには、複雑なパスワード (最小12文字) と組み合わせたYubikeyハードウェアトークンを使用した多要素認証が必要です。すべてのアクセス要求は、文書化された管理者の承認と四半期ごとのレビューを必要とするアクセス管理手順 (AMP-201) に従います。」

3. サポート文書と証拠の参照を含める

SSPは、各コントロール実施をサポートする特定のポリシー、手順、および証拠を参照する必要があります。

推奨アプローチ: SSPとすべてのサポート文書との間に明確な接続を作成する包括的な参照システムを開発します。各コントロール実施記述には、コントロールを承認する関連する正式なポリシー文書への正確な参照を含め、特定の文書IDとセクション番号を含めます。各ポリシー要件を実施する詳細な運用手順を参照し、高レベルのガバナンスから日常的な実践への追跡可能性を確保します。実施決定をガイドする適用可能な技術基準やセキュリティベースラインへの引用を含めます。サポート証拠が見つかる特定の場所を文書化し、SSP自体に機密データを埋め込むことなく効率的な評価を促進する証拠マップを作成します。この参照アーキテクチャは、SSPが広範なセキュリティ文書エコシステムを通じて効果的なナビゲーションツールとして機能することを保証します。

避けるべき落とし穴: SSP自体に実際の資格情報、秘密鍵、詳細なセキュリティ構成などの機密情報を含めないでください。

4. POA&Mを適切に対処する

すべてのコントロールを初日から完全に実施する組織はありません。行動計画とマイルストーン (POA&M) は、特定されたギャップに対処するためのアプローチを文書化します。

推奨アプローチ: 継続的な改善への取り組みを示すコンプライアンスギャップを文書化するための構造化されたアプローチを開発します。特定された各ギャップについて、SSP構造と一致する一貫した識別子を使用して、完全に実施されていない特定のコントロール要件を明示的に参照するPOA&Mエントリを作成します。コンプライアンスギャップの正確な性質を明確に表現する現在の状態の詳細な説明を提供し、その重要性を最小限に抑えないようにします。ギャップを完全に解決するための具体的な技術的および手続き的な行動を含む包括的な修正計画を文書化し、論理的なマイルストーンに分割します。実施の責任を適切な権限と技術的能力を持つ個人に明確に割り当てます。ギャップのリスクレベルと修正の複雑さの両方を反映した現実的なタイムラインを確立し、高リスク項目に対する緊急性を示しながら、実施制約を認識します。

重要な洞察: POA&Mは許可されていますが、コントロールの少数に対処する必要があります。過剰なPOA&Mは、認証に十分な成熟度を持たないセキュリティプログラムを示します。

5. 一貫したフォーマットと組織を維持する

よく組織されたSSPは、開発と評価の両方のプロセスを促進します。

推奨アプローチ: セキュリティコントロールのナビゲーションと理解を向上させる標準化された文書フレームワークを実施します。各セキュリティ要件を同じ構造パターンで提示する一貫したコントロール記述フォーマットを採用し、評価者が複数のコントロールにわたって特定の情報を迅速に見つけることができるようにします。NIST 800-171コントロール識別子と直接一致する番号システムを使用し、要件と実施の間の即時の追跡可能性を作成します。階層的な組織とハイパーリンクを備えた包括的な目次を開発し、文書を効率的にナビゲートできるようにします。補足情報を提供する付録を使用し、主要な文書の流れを妨げることなく重要なコンテキストを提供します。表、図、一貫したフォーマットなどの視覚要素を考慮し、読みやすさを向上させ、重要な情報を強調し、SSPを技術的に正確でありながらさまざまな利害関係者にアクセスしやすくします。

ツールの推奨: NISTの無料のSSPテンプレートを出発点として使用し、組織のニーズに合わせてカスタマイズすることを検討してください。

6. システムの変更を反映するために定期的に更新する

SSPは生きた文書であり、システムやセキュリティコントロールが変更されるたびに進化する必要があります。

推奨アプローチ: セキュリティプログラムの進化を通じてSSPの正確性を維持するための正式な変更管理プロセスを確立します。技術文書が実際の実施と一致し続けるように、重要なシステム変更後に自動的にSSP評価をトリガーする文書化されたレビュー手順を実施します。さもなければ文書化されない可能性のある漸進的な変更を特定するために、最低でも四半期ごとの包括的なレビューを実施します。すべてのレビュー活動と承認の詳細な文書を維持し、SSPのメンテナンスの監査証跡を作成し、継続的なガバナンスを示します。SSPとすべてのサポート文書の両方に対して堅牢なバージョン管理を実施し、セキュリティコントロールが時間とともにどのように進化したかの明確な履歴記録を提供します。このSSPメンテナンスへの規律あるアプローチは、コンプライアンス文書が過去の実践のますます不正確なスナップショットになるのではなく、現在の環境を継続的に反映することを保証します。

避けるべき落とし穴: 現在の環境を反映していない古いSSPは、評価の成功を損ない、セキュリティの脆弱性を引き起こす可能性があります。

7. クロスファンクショナルな利害関係者を巻き込む

セキュリティコントロールは技術的、物理的、管理的なドメインにまたがり、組織全体からの入力が必要です。

推奨アプローチ: 組織の運用環境全体からの専門知識を結集する多分野のSSP開発チームを作成します。コントロール目標と技術的実施を理解する専任のITセキュリティ担当者を含め、重要なシステムの日常運用を管理するシステム管理者を含めます。接続性と境界コントロールを正確に文書化できるネットワークエンジニアを参加させ、人的セキュリティ要件に対処できる人事担当者を補完します。物理的なセキュリティコントロールに対処するために施設管理を組み込み、規制の整合性を確保するために法務/コンプライアンスの専門家を含めます。包括的なSSP開発のための権限とリソースの両方を提供するエグゼクティブスポンサーシップを確保します。この多様なチームは、SSPが技術的なコントロールにのみ焦点を当て、同様に重要な管理的および物理的な保護策を無視するのではなく、すべてのドメインにわたってセキュリティコントロールを包括的に対処することを保証します。

ベストプラクティス: コントロール記述を開発する際に関連する利害関係者からの入力を収集するための協力的なワークショップを実施します。

8. NIST 800-171コントロールファミリーと整合させる

SSPをNIST 800-171の構造に合わせて整理し、評価者がコンプライアンスを確認しやすくします。

推奨アプローチ: 関連するコントロールを14の一貫したファミリーにグループ化し、サイバーセキュリティ要件の完全なスペクトルをカバーするNIST 800-171フレームワークの論理的な組織に従ってSSPを構築します。認可されたユーザーとトランザクションにシステムアクセスを制限するアクセスコントロールの基本から始め、次にセキュリティ責任を理解するための人員を確保する意識とトレーニングのコントロールを続けます。監視とレビューを通じて透明性を確保する監査と説明責任の措置と、システムの整合性を確立し維持する構成管理の実践を並行して行います。ユーザーの身元を確認するための識別と認証の要件に対処し、次にセキュリティイベントのためのインシデント対応手順を文書化します。システムの維持のためのメンテナンスコントロール、情報処理のためのメディア保護、労働力保証のための人員セキュリティ、および施設の保護のための物理的保護を含めます。リスク評価プロセス、セキュリティ評価の実践、システムと通信の保護メカニズム、およびシステムと情報の整合性の保護策でカバーを完了します。この包括的な構造は、すべてのセキュリティドメインを体系的にカバーし、C3PAOが使用する評価フレームワークと完全に一致することで効率的な評価を促進します。

重要な洞察: この整合性は、SSPと評価基準の間のマッピングを簡素化し、認証プロセスを合理化します。

9. サプライチェーンの考慮事項に対処する

CMMCは、防衛サプライチェーン全体のセキュリティを強調し、ベンダーやサービスプロバイダーとの関係を含めます。

推奨アプローチ: 外部パートナーシップによって作成される拡張されたセキュリティ境界に対処する包括的なサプライチェーンセキュリティ戦略を開発します。第三者プロバイダーが特定のセキュリティコントロールをどのように直接サポートしているかを詳細に文書化し、これらの関係を個々のCMMC要件にマッピングして完全なカバーを示します。CUIを取り扱うまたは処理するすべてのベンダーに対する明確なセキュリティ要件を確立し、契約上の義務と検証メカニズムを含めて文書化します。共有コントロールの責任境界を正確に定義し、各セキュリティ側面の実施、監視、および報告の責任をどの組織が維持するかを明確に表現します。継続的なベンダーコンプライアンスを検証するための堅牢な監視と監督手順を実施し、定期的な評価、証拠収集、および修正の追跡を含めて文書化します。この詳細なサプライチェーン文書化アプローチは、外部関係の複雑なセキュリティの影響を理解し、積極的に管理していることを評価者に示します。

避けるべき落とし穴: クラウドサービスプロバイダーを使用することが自動的にセキュリティ責任を組織から移転するとは考えないでください。プロバイダーのコントロールがCMMC要件を満たしていることをどのように確保するかを文書化する必要があります。

CMMCに準拠する必要がありますか？こちらが完全なCMMCコンプライアンスチェックリストです。

10. 例外の正当化を文書化する

特定の環境に適用されないコントロールもありますが、単に「適用不可」とマークするのではなく、これらの例外を正当化する必要があります。

推奨アプローチ: 特定の環境に本当に適用されないコントロールに対する徹底的で証拠に基づいた正当化を開発します。各例外について、除外される特定のコントロール要件の正確な引用から始めて、何が正確に除外されているかについての明確さを確保します。技術アーキテクチャ、ビジネスプロセス、またはシステム機能に基づいて、環境にコントロールが適用されない理由を包括的に説明し、実施の難しさではなく、根拠を示します。元のコントロールが対処するために設計されたリスクを軽減する代替手段を示し、セキュリティ目標が依然として代替手段を通じて達成されていることを示します。例外が組織内の適切なセキュリティガバナンス当局によってレビューされ、承認されたことを示す正式な承認証拠を含めます。この厳格な例外へのアプローチは、困難なコントロールを回避するのではなく、思慮深い分析の結果として除外が行われていることを示し、セキュリティの成熟度を示します。

重要な洞察: 例外はまれであり、徹底的に正当化されるべきです。評価者は例外の正当化を厳密に精査します。

SSPテンプレートとリソース

CMMCコンプライアンスのためのシステムセキュリティ計画 (SSP) を開発するために、いくつかのリソースが利用可能です。

NIST SP 800-171付録Eは、SSPの期待されるセクションを概説する公式の、ただし高レベルのテンプレート構造を提供します。出発点として価値がありますが、このNISTテンプレートは大幅なカスタマイズが必要です。一般的なコンテンツを使用する落とし穴を避けてください。SSPは、特定のシステム境界、技術、構成、ポリシー、および手順を正確に反映する必要があります。一般的なSSPはCMMC評価に合格しません。

必要な詳細を示すために、CMMC実践AC.L2-3.1.5 (非特権ユーザーが特権機能を実行するのを防ぐ) のセクションを考慮してください：「特権機能の実行 (例：システム構成変更、ソフトウェアインストール) は、「ドメイン管理者」と「サーバーオペレーター」Active Directoryグループ内の人員に制限されています。標準ユーザーアカウントは、CUI境界内のワークステーションおよびサーバーで管理者権限を持っていません。ユーザーアカウント制御 (UAC) は、ベースライン構成 [Config-Std-Win10-v2.1] に従ってすべてのWindowsエンドポイントで有効になっています。特権アクセスの試みは、[SIEMツール名] に中央でログ記録され、[ログレビュー手順ID] に従ってレビューされます。」

SSPの開発と維持を管理するために、カスタマイズされたワードプロセッシングテンプレートやスプレッドシート (より複雑でない環境に適しており、手動での追跡が必要) から専用のガバナンス、リスク、およびコンプライアンス (GRC) ソフトウェアプラットフォームまで、さまざまなオプションがあります。GRCツール (多くの場合、有料ソリューション) は、効率的なSSPのためのCMMCプロセスを目指す大規模またはより複雑な組織にとって非常に有益な、制御マッピングの自動化、バージョン管理、証拠管理、POA&M追跡、および報告などの機能を提供します。使用されるツールに関係なく、NISTの出版物のような無料のリソースは依然として重要な参考資料です。

KiteworksがSSP文書化サポートを提供する方法

よく作成されたシステムセキュリティ計画は、成功したCMMC認証の基盤です。それは、コンプライアンスを困難な課題から明確なマイルストーンと責任を持つ構造化されたプロセスに変えます。

SSPは単なる文書以上のものであり、組織が以下を可能にする戦略的資産であることを忘れないでください：

• 必要なセキュリティコントロールを体系的に実施する
• 評価者にコンプライアンスを示す
• セキュリティギャップを特定し対処する
• 継続的なセキュリティ改善の基盤を確立する

このガイドで概説されたベストプラクティスに従い、Kiteworksのような目的に特化したソリューションを活用することで、CMMC認証の目標をサポートするだけでなく、全体的なセキュリティ体制を強化するSSPを開発できます。Kiteworksは、SSP開発のためのコンプライアンスを文書化するために組織を支援し、以下を含みます：

• コントロール実施の証拠: Kiteworksは、コントロール実施の直接的な証拠として機能する構成可能なセキュリティレポートと監査ログを提供します。
• ポリシー施行の文書化: プラットフォームのポリシー施行機能は、CUI処理全体でのセキュリティコントロールの一貫した適用を保証し、文書化します。
• システム境界の定義: Kiteworksは、安全なコンテンツ通信チャネルを通じてCUI環境の明確な境界を確立するのに役立ちます。
• リスク評価のサポート: プラットフォームのセキュリティ分析は、リスク評価文書のための潜在的な脆弱性を特定し、文書化するのに役立ちます。

Kiteworksは、コンプライアンスを合理化するためにCMMCに焦点を当てた機能も開発しており、以下を含みます：

• CMMCコントロールマッピング: Kiteworksは、SSP開発を簡素化するために、特定のCMMCレベル2コントロールに機能をマッピングする詳細な文書を提供します。
• CUI処理ワークフロー: プラットフォームには、コンプライアントなCUI処理のために特別に設計された事前構成済みワークフローが含まれています。
• 安全なコラボレーション: Kiteworksは、CMMCコンプライアンスを損なうことなく外部パートナーとの安全なコラボレーションを可能にします。
• 継続的な監視: 組み込みのセキュリティ監視ツールは、セキュリティコントロールの効果を継続的に評価するのをサポートします。

KiteworksをCMMCコンプライアンス戦略の一部として実装することで、認証に必要な技術的コントロールと包括的なSSPを開発するための文書化サポートの両方を得ることができます。

KiteworksはCMMC 2.0コンプライアンスをサポートします

Kiteworksのプライベートコンテンツネットワーク、FIPS 140-2レベル検証済みの安全なファイル共有およびファイル転送プラットフォームは、メール、ファイル共有、ウェブフォーム、SFTP、マネージドファイル転送、および次世代デジタル著作権管理ソリューションを統合し、組織がファイルを制御し、保護し、追跡することを可能にします。

Kiteworksは、CMMC 2.0レベル2コンプライアンスコントロールの約90%を即座にサポートします。その結果、DoD請負業者および下請け業者は、適切な機密コンテンツ通信プラットフォームを確保することで、CMMC 2.0レベル2認定プロセスを加速できます。

Kiteworksは、以下を含む主要な機能と特徴を備えた迅速なCMMC 2.0コンプライアンスを可能にします：

• SSAE-16/SOC 2、NIST SP 800-171、およびNIST SP 800-172を含む、米国政府の主要なコンプライアンス基準と要件に基づく認証
• FIPS 140-2レベル1の検証
• 中程度の影響レベルCUIのためにFedRAMP認可
• データの保存時にAES 256ビット暗号化、転送時にTLS 1.2、および唯一の暗号化キー所有

Kiteworksについて詳しく知りたい方は、カスタムデモをスケジュールしてください。

システムセキュリティ計画に関するFAQ
1. システムセキュリティ計画はどのくらいの長さにするべきですか？
システムセキュリティ計画には規定されたページ数はありません。長さは情報システムの複雑さ、適用可能なコントロールの数 (例：CMMCレベル2のための110) 、および実施を正確に説明するために必要な詳細レベルに完全に依存します。明確さ、完全性、および正確性が長さよりもはるかに重要です。CMMCのための包括的なSSPは、50ページから数百ページに及ぶ可能性があります。
2. SSPはどのくらいの頻度で更新するべきですか？
システムセキュリティ計画は生きた文書です。NIST 800-171は、少なくとも年に一度、またはシステム、運用環境、セキュリティコントロール、または人員に重大な変更があった場合にレビューおよび更新することを要求しています。CMMCのために、SSPを最新に保つことは認証を維持するために重要です。
3. CMMC評価者がSSPと実際の実施の間に不一致を発見した場合、どうなりますか？
評価者は、システムセキュリティ計画に文書化された内容が現実と一致していることを確認します。不一致は発見またはギャップとしてフラグが立てられます。軽微な不一致は評価中に対処される可能性がありますが、重大な逸脱 (例：実施されたと文書化されたコントロールが実際には欠落しているまたは誤って構成されている) は評価の失敗につながるか、行動計画とマイルストーン (POA&M) に詳細なエントリを必要とし、CMMC認証を遅らせる可能性があります。
4. クラウドサービス (例：IaaS、PaaS、SaaS、Microsoft 365 GCC Highなど) をCMMCのためのSSPに含めることはできますか？
もちろんです。クラウドサービスがシステムの一部としてCUIを処理、保存、または送信する場合、システムセキュリティ計画で定義されたシステム境界内に含める必要があります。共有責任モデルを明確に文書化し、クラウドサービスプロバイダー (CSP) から完全または部分的に継承されるコントロールと組織の責任を詳細に説明する必要があります。CSPのコンプライアンスの証拠 (例：FedRAMP認可、SOCレポート) を参照する必要があります。
5. SSPで継承されたセキュリティコントロールをどのように適切に文書化しますか？
第三者 (CSPやマネージドサービスプロバイダーなど) から継承されたコントロールについては、システムセキュリティ計画で特定のコントロールとプロバイダーを特定します。プロバイダーのコンプライアンス文書 (例：FedRAMPシステムセキュリティ計画、顧客責任マトリックス) を参照します。重要なのは、継承されたコントロールがCMMC要件を満たしていることをどのように確認し、共有モデル内での責任をどのように管理するかを説明することです。単にコントロールが継承されていると述べるだけでは不十分です。デューデリジェンスを示す必要があります。