> For the complete documentation index, see [llms.txt](https://docs.dispel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dispel.com/documentation/documentation-ja/shisuru/overview/compliance-and-audit-readiness.md).

# はじめに

NERC CIP、NIST 800-53、NIS2 の管理策に対する Dispel による監査準備の自動化。

## 使い始める

Dispel Compliance パッケージの作成は、4段階のワークフローです：

1. [**次を選択します**](#step-1-select-a-framework) 組織が報告対象とするフレームワーク。
2. [**評価**](#step-2-assess-dispels-coverage) テナントの現在の構成に対する Dispel のカバレッジ。
3. [**確認**](#step-3-review-coverage-and-close-gaps) Dispel がどの管理策をカバーしているかを確認し、カバレッジの欠落箇所を特定し、シミュレーターを使ってそれらを解消する設定変更を計画します。
4. [**エクスポート**](#step-4-export-the-inheritance-package) OSCAL Component Definition と PDF レポートを出力し、GRC チームまたは監査人に渡します。

***

#### ステップ 1: フレームワークを選択する

フレームワークを選択すると、Dispel がどの管理策の用語体系でカバレッジを表現するかが決まります。多くの組織は、監査人または所管当局が基準とするフレームワークを選択します。複数のフレームワークを同時に有効化できるため、同じ Dispel デプロイメントが複数の規制レジームに対して監査される場合に便利です。

1. 左サイドバーで **設定**.
2. 次を開いて **Compliance** タブに移動します。
3. クリック **フレームワークを追加**.
4. 次を選択します： **カタログ** （例： *NIST SP 800-53 Rev 5*).
5. 次を選択します： **プロファイル** または **ベースライン** （例： *Moderate*）。プロファイルは、カタログを特定の影響度レベルで必要となる管理策のサブセットに絞り込みます。
6. クリック **追加**.

フレームワークは直ちに有効なフレームワーク一覧に表示されます。Dispel はバックグラウンドでカバレッジ評価を開始し、評価が完了するたびにダッシュボードが更新されます。

{% hint style="info" %}
複数のフレームワークを追加しても **重複作業には** なりません。Dispel は、自身の実装について単一の証跡セットを生成し、それを各有効フレームワークに合わせて再表現します。NIST 800-53 に加えて NIST CSF を追加しても、同じ基礎証跡が再利用されます。
{% endhint %}

**フレームワークを削除する**

有効なフレームワークを削除するには、有効フレームワーク一覧でその横にあるゴミ箱アイコンをクリックします。フレームワークを削除しても、そのスコアカードは削除されますが、他の有効フレームワークや基礎となる証跡レコードには影響しません。 **削除したフレームワークは、履歴を失うことなく簡単に再追加できます。**

***

#### ステップ 2: Dispel のカバレッジを評価する

**自動評価**

Dispel には次のライブラリが含まれています： **管理策評価器** これは、テナントの現在の構成を前提として、Dispel が各対象内の管理策を実装しているかを確認します。たとえば： `このテナントで MFA が強制されているか`, `セッション記録が有効か`, `パスワードポリシーがフレームワークのしきい値を満たしているか`、および `ベンダーのアテステーションが保管されているか`。各評価器は、各有効フレームワークの1つ以上の管理策に対応します。

評価を実行するには：

1. 次へ移動します： **設定** > **Compliance**.
2. 評価したいフレームワークを開きます。
3. クリック **評価を実行**.

評価結果はタイムスタンプ付きで保存されます。各管理策には次のいずれかのステータスが付与され、テナント上でのその管理策に対する Dispel の実装状況を示します：

| ステータス    | 意味                                                                                        |
| -------- | ----------------------------------------------------------------------------------------- |
| **実装済み** | Dispel はこの管理策をテナント上で完全に実装しています。継承可能です。                                                    |
| **失敗**   | Dispel は **重複作業には** 現時点ではこの管理策をテナント上で実装していません。通常は、Dispel の設定変更が必要なためです。現在の構成のままでは継承できません。 |
| **未評価**  | この管理策に対して自動評価器が実行されていないか、評価器がまだ完了していません。                                                  |
| **適用外**  | この管理策は Dispel の対象範囲外（たとえば、施設の物理セキュリティ）であり、Dispel からの継承は適用されません。                           |

{% hint style="info" %}
評価は非破壊かつ読み取り専用です。Dispel の構成を観測するだけで、テナントを変更することはありません。
{% endhint %}

***

#### ステップ 3: カバレッジを確認し、ギャップを解消する

Compliance ダッシュボードは、テナント上で Dispel が何をカバーしているか、またどこを改善できるかを把握するための日常的な作業領域です。

**スコアカード**

各有効フレームワークには、Dispel が現在テナント上で実装している対象内管理策の割合を示すスコアカードがあります。サブ管理策や拡張機能の一部のみが実装されている場合は、部分点が付与されます。任意の数値にカーソルを合わせると、内訳を確認できます。

**サンバーストチャート**

階層型のサンバースト可視化により、Dispel のカバレッジを一目で確認できます：フレームワーク → 管理策ファミリ → 個別管理策。実装済み（継承可能）な管理策は緑、失敗（現時点では継承不可）は赤、未評価は灰色で表示されます。任意のセグメントをクリックすると、管理策詳細ページにドリルダウンできます。

**管理策詳細ページ**

管理策を選択すると、次が表示されます：

* **ステータス** — このテナントにおける、管理策の Dispel の現在および過去の実装
* **証跡** — ステータスに寄与した具体的な評価器。タイムスタンプと、観測した基礎値を含みます
* **説明文** — その管理策に対する Dispel の実装ステートメント
* **系譜** — この同じ証跡にマップされる管理策を持つ他のすべてのフレームワーク（そのため、1つの継承主張を複数のフレームワーク言語で表現できます）
* **是正ガイダンス** — 失敗した管理策について、継承を回復する Dispel 設定または構成変更の説明

**構成変更の影響シミュレーション**

テナント上の Dispel 設定を変更する前に、シミュレーターを使ってカバレッジの変化を予測します：

1. ダッシュボードで **推定影響** の下の **推奨事項**.
2. オーバーレイパネルで1つ以上の Dispel 設定を見つけます（例： *すべてのユーザーに MFA を有効化*).
3. 予測スコアカードを現在のスコアカードと比較します。

シミュレーターは実際の設定を一切変更しません。Dispel の継承を強化する変更の順序を計画するためだけのツールです。

{% hint style="info" %}
最も多くの継承可能な管理策をまず回復できる順序で、シミュレーターを使って構成変更を並べます。
{% endhint %}

***

#### ステップ 4: 継承パッケージをエクスポートする

**OSCAL Component Definition**

OSCAL Component Definition は、顧客の System Security Plan に対する単一コンポーネントの寄与を文書化するための標準化された成果物です。Dispel においてそのコンポーネントはあなたの Dispel デプロイメントであり、Component Definition は監査人が継承として認められる内容の正式な記録です。

1. フレームワークの詳細ページを開きます。
2. クリック **エクスポート** > **OSCAL Component Definition**.
3. OSCAL 1.1.2 に準拠した JSON ファイルがダウンロードされます。

エクスポートには以下が含まれます：

* 継承主張が表現されるカタログとプロファイル
* Dispel 側から見た各対象内管理策の実装ステータス（`実装済み`, `部分実装`, `未実装`, `適用外`)
* 各管理策に対する Dispel の実装説明
* 基礎となる証跡レコードへのリンク

このファイルは、eMASS、Xacta、RegScale、FedRAMP、GovRAMP の提出物、または OSCAL を受け付ける任意のツールに取り込めます。そこで、このファイルは他ベンダーの Component Definitions や社内 SSP コンテンツと並んで格納されます。

**経営層向け PDF レポート**

社内関係者向けおよび監査用カバーレター向け：

1. フレームワークの詳細ページを開きます。
2. クリック **エクスポート** > **PDF レポート**.

レポートには以下が含まれます：

* 現時点で Dispel から継承できる対象内管理策の割合を示すエグゼクティブサマリー
* フレームワークのスコアカード
* Dispel が現在テナント上で実装していないすべての管理策と、継承を回復するための構成変更
* 評価に寄与した証跡ソースの一覧
* 生成タイムスタンプと評価者の識別情報

***

### 継続的な証跡と監査証跡

各評価器の実行は **証跡スナップショット** を生成し、タイムスタンプ付きで保存されます。スナップショットには、その時点で Dispel が自身のカバレッジについて観測した内容が記録されます。

特定時点を検証する必要がある監査人は、次のことができます：

1. 該当日の評価レコードを見つける。
2. 任意の個別管理策の証跡スナップショットを掘り下げる。
3. 評価器が観測した正確な値と、観測タイムスタンプを確認する。

***

### Dispel がカバーするもの（およびカバーしないもの）

Dispel は、Dispel プラットフォーム自体に実装されているセキュリティ管理策、主にリモートアクセス、ID、セッション監視、ネットワーク分離、OT 接続レイヤーをカバーします。Dispel 自身の企業としての体制（ベンダー管理、サプライチェーン、SDLC、人員スクリーニング）に依存する管理策も、Dispel が公開している実装説明を通じてカバーされます。

Dispel は **重複作業には** その適用範囲外の管理策はカバーしません。たとえば、施設の物理セキュリティ、Dispel が管理しない機器のエンドポイント強化、業務システム内のアプリケーション開発、組織の HR 実務などです。そうした管理策は、すべて企業 GRC ツール側に残ります。

次の表は、Dispel が生成する証跡のカテゴリと、それらが通常サポートするフレームワークの管理策ファミリを要約したものです。これは例示であり、有効なフレームワークに対する正式なマッピングは、各管理策の詳細ページに表示されます。

| 証跡カテゴリ                   | 代表的な NIST 800-53 ファミリ | 代表的な NERC CIP 要件        | 代表的な NIS2 措置（実施規則 2024/2690） |
| ------------------------ | --------------------- | ----------------------- | ---------------------------- |
| ID、MFA、セッションライフサイクル      | AC、IA                 | CIP-004、CIP-005、CIP-007 | IDおよびアクセス制御；認証               |
| リモートアクセスと分離              | AC、SC                 | CIP-005、CIP-007         | ネットワークセキュリティ；アクセス制御ポリシー      |
| セッション記録とフォレンジック          | AU                    | CIP-007、CIP-008         | インシデント対応；ログ記録と監視             |
| 構成および変更記録                | CM                    | CIP-010                 | 資産管理；変更管理                    |
| ベンダーおよびサプライチェーンのアテステーション | SR、PS                 | CIP-013                 | サプライチェーンセキュリティ               |
| プラットフォームのアテステーションと整合性    | SI、SC                 | CIP-007、CIP-010         | 脆弱性対応と開示；暗号技術                |

***

### よくある質問

<details>

<summary>評価を実行すると、テナントに何か変更がありますか？</summary>

いいえ。評価は読み取り専用です。Dispel 構成の現在の状態を観測し、Dispel のカバレッジに関する証跡スナップショットを生成するだけです。設定、ユーザー、デバイス、ポリシーを変更することはありません。

</details>

<details>

<summary>評価はどのくらいの頻度で実行すべきですか？</summary>

多くの組織では、重要な構成変更の後に評価を実行すれば十分です。定期評価の証跡（たとえば毎月または四半期ごと）を要求する監査人もいるため、監査プログラムで求められる頻度に合わせて評価を予定してください。OSCAL エクスポートと PDF レポートには評価タイムスタンプが記録されます。

</details>

<details>

<summary>Dispel を完全な GRC システムとして使えますか？</summary>

いいえ。Dispel は、Dispel 自身が実装する管理策、つまり監査の下にある継承レイヤーに対する system of record にすぎません。Dispel の対象範囲外の管理策（物理セキュリティ、HR プロセス、ソフトウェア開発手法、Dispel が管理しないエンドポイントなど）については、証跡は企業 GRC プラットフォームに存在します。Dispel の OSCAL Component Definition は、そのプラットフォームに多数のコンポーネントの1つとして取り込めるよう設計されています。

</details>

<details>

<summary>管理策で「未評価」とはどういう意味ですか？</summary>

管理策が *未評価* 、まだ自動評価器が実行されていない場合、または評価器がまだ完了していない場合に表示されます。これは *適用外*とは異なり、こちらはその管理策が Dispel の対象範囲外であり、Dispel から継承できる対象に含まれないことを意味します。

</details>

<details>

<summary>Dispel で NIS2 コンプライアンスを実証できますか？</summary>

Dispel がカバーする NIS2 の範囲については、可能だと考えています。次を選択してください： **NIS2** 有効なフレームワークとして NIS2 を選択すると、Dispel は EU NIS2 実施規則（2024/2690）の措置に対して表現された Component Definition を生成し、ENISA の Technical Implementation Guidance に従って NIST 800-53 にマッピングされます。これを、リモートアクセス、ID、セッション監視、OT 接続の管理策に対する継承レイヤーとして、その他の NIS2 文書とともに所管当局に提出してください。

ENISA は公式の NIS2 OSCAL カタログを公開していません。Dispel のカタログは実施規則の法文から直接作成されています。将来 ENISA が公式カタログを公開した場合、Dispel はそれを採用します。

</details>

<details>

<summary>一部の管理策が「適用外」と表示されるのはなぜですか？</summary>

管理策は *適用外* Dispel の適用範囲外であるため、Dispel から継承できるものではない場合に「適用外」とマークされます。たとえば、施設への物理アクセス、組織の採用慣行、社内アプリケーションのソフトウェア開発を管理する管理策などです。N/A 判定は OSCAL エクスポートに記録されるため、監査人は Dispel の継承主張から除外された管理策を正確に把握し、他の手段で検証できます。

</details>

<details>

<summary>フレームワークを削除するとデータはどうなりますか？</summary>

何も起こりません。完全に安全です。フレームワークを削除すると、そのスコアカードは削除され、ダッシュボードからも削除されます。基礎となる証跡スナップショットと管理策説明は保持され、フレームワークを再追加すると再び利用できます。評価履歴が破棄されることはありません。

</details>

<details>

<summary>OSCAL エクスポートには機密性の高いテナント構成が含まれますか？</summary>

いいえ。Component Definition に含まれるのは、Dispel の実装ステータス、説明文、証跡への参照であり、テナントの生の構成値、認証情報、IP アドレス、ユーザーデータではありません。監査人と共有したり、OSCAL 対応 GRC プラットフォームにアップロードしたりしても安全です。

</details>

<details>

<summary>同じ Dispel の証跡で複数のフレームワークをサポートできますか？</summary>

はい。これが OSCAL ベースのアーキテクチャの中核的な利点です。Dispel の1つの証跡（例：「このテナントで MFA が強制されている」）は、NIST 800-53 IA-2(1)、NIST CSF PR.AA-03、NERC CIP-005-7 R2、および同じ評価器にマッピングされる他の任意の管理策に同時に寄与します。同じ継承主張は、各監査で必要とされるフレームワーク言語で表現できます。

</details>

<details>

<summary>監査期間中に Dispel の継続的なカバレッジをどう証明すればよいですか？</summary>

監査期間の開始時と終了時にそれぞれ評価を実行し、その間の基礎証跡スナップショットを参照してください。各スナップショットにはタイムスタンプが付いているため、評価が生成された日だけでなく、監査期間の全日について Dispel からの継承主張が有効だったことを示せます。

</details>

<details>

<summary>独自の内部管理策フレームワークを追加できますか？</summary>

カスタムカタログの取り込みはロードマップ上にあります。現時点では、内部フレームワークは通常、最も近い公開ベースライン（たとえば NIST 800-53 Moderate）を選択することで表現されます。Dispel はその用語体系で継承証跡を生成し、その後 GRC チームが企業 GRC プラットフォーム内で内部フレームワークへ再マッピングできます。

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.dispel.com/documentation/documentation-ja/shisuru/overview/compliance-and-audit-readiness.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
