ドメイン分離と セキュリティインシデントレスポンス

  • リリースバージョン: Washingtondc
  • 更新日 2024年02月01日
  • 読む11読むのに数分

    • ドメイン分離は セキュリティインシデントレスポンス でサポートされています。 ドメイン分離では、データ、プロセス、および管理タスクをドメインと呼ばれる論理的なグループに分けることができます。どのユーザーがデータを表示できるか、データにアクセスできるかなど、このアプリケーションのいくつかの側面を制御できます。

    サポートレベル：標準

    • ベーシックレベルサポートを含みます。
    • ビジネスロジック：サービスプロバイダー (SP) によって顧客ごとにプロセスを作成または変更できます。ユースケースには、単一のインスタンスでの複数のサービスプロバイダー顧客によるアプリケーションの正しい使用が反映されています。
    • インスタンスのオーナーは、特定のアプリケーションに期待される通りに、テナントごとに MVP ビジネスロジックとデータパラメーターを設定できる必要があります。

    サンプルユースケース：管理者は、レコードを他のテナントに対してはクローズしないが、1 つのテナントに対してクローズする場合、コメントを必須にすることができる必要があります。

    サポートレベルの詳細については、「アプリケーションでのドメイン分離のサポート)」を参照してください。

    概要

    セキュリティインシデントレスポンス アプリケーションでは、サービスプロバイダー (SP) は、ドメイン分離によって、顧客ベース全体で SOC (Security Operations Center) および Security Incident Response (SIR) 手順を標準化し、運用コストの削減とサービス品質の向上を実現できます。顧客データは、ワークフロー、ダッシュボード、レポートなどに別個の顧客ワークスペースを使用することで分離され、他のクライアントに公開されることはありません。

    表 : 1. バージョンリリースごとの Security Incident Response でのドメイン分離のサポート
    リリース サポートレベル メモ
    Geneva、Helsinki サポートはありません データレベルのドメイン分離の開始
    Istanbul データのみ
    Jakarta レベル 2 (データ、要求者、履行者) 新機能：単一の統合インスタンスでのレベル 2 ドメイン分離によるサードパーティ統合のサポート (Threat Intelligence 統合を含む)
    Kingston レベル 2 (データ、要求者、履行者) 新機能：SIR のサイティング検索統合は複数のインスタンスで有効になりますが、すべてのインスタンスは引き続き単一のドメインの下で動作します。例：Splunk Integration の 2 つのインスタンス (SplunkCLOUD および SplunkCORP) が構成されている場合は、実装が最初に構成された単一のドメインでのインシデント応答アクティビティにその両方が引き続き利用されます。
    London レベル 2 (データ、要求者、履行者) 新機能：すべての統合を複数のドメインに配置できます。
    Madrid レベル 2 (データ、要求者、履行者) すべての統合を複数のドメインに配置できるようになりました。上記の例では、SplunkCloud を domain1 に配置し、SplunkCORP を domain2 に配置できます。
    New York レベル 2 (データ、要求者、履行者) すべての統合を複数のドメインに配置できます。
    Orland 標準 すべての統合を複数のドメインに配置できます。
    Paris 標準 すべての統合を複数のドメインに配置できます。

    セキュリティインシデントレスポンス アプリケーションのドメイン分離は、次の製品機能をカバーしています。

    • セキュリティアラートは、インシデントがその ID/資格情報/スコープで生成され、セキュリティインシデントとして登録されているユーザーの適切なドメインに送信されます。
    • アラートは、ステートフルなプロパティまたは測定可能なイベントを表す「観測事象」を生成します。セキュリティインシデントのドメイン内のセキュリティワークフローを使用して、応答を調整します。
    • 統合は、応答の自動化のためにセキュリティインシデントのドメイン内で構成されます。
    • 機能は、応答の自動化のためにセキュリティインシデントのドメイン内で構成されます。機能には、次のものが含まれます (Kingston リリース時点)。
      • 脅威のルックアップ
      • 観測事象を拡張
      • 構成アイテムを拡張
      • 実行中のプロセスを取得
      • ネットワーク統計情報を取得
      • ブロック要求
      • ホストを隔離
      • サイティング検索
      • メールの検索と削除
      • ウォッチリストに公開
    • 応答の自動化の結果 (脅威のルックアップやサイティング検索など) は、セキュリティインシデントのドメインに保存されます。
    • 他のセキュリティインシデントは、観測事象の共有セットに基づいて、セキュリティインシデントの同じドメイン内で相互参照されます。
    • 他のユーザーは、セキュリティインシデントのドメイン内で相互参照されます。
    • 構成アイテムは、セキュリティインシデントと同じドメイン内で相互参照されます。
    • 手動応答タスクは、セキュリティインシデントのドメインに追加されます。
    • ナレッジベース記事と Runbook は、セキュリティインシデントのドメイン内で参照されます。
    • ドメイン内のインシデントに関連する Security Incident Response 測定基準は、ダッシュボードとレポートに表示されます。
    注:
    上記のケースでは、NOW Platform の分離されたドメインでの可視性の包括的な原則が適用されます。通常どおり、親ドメインのインシデントは子ドメインのアーティファクトを参照できますが、その逆はできません。

    Security Incident Response におけるドメイン分離の仕組み

    セキュリティインシデントレスポンス アプリケーションは、セキュリティインシデントのライフサイクルをエンドツーエンドで管理します。次のユースケースはドメイン分離に対応しています。

    • 顧客の SOC または MSP のアナリストが応答するセキュリティインシデントを作成するためのイベントとアラートの取り込み：
      • メールパーサー (プラットフォームベース、ユーザーから報告されたフィッシング、カスタム)
      • インシデント作成前の重複排除イベント/アラート
      • 観測事象の自動抽出
      • サードパーティ SIEM ストアにあるアプリケーション
    • インシデントに関連するアーティファクトの拡張 (IP、URL、ドメイン、ファイルハッシュ)：
      • 資産の拡張 (CMDB)
      • ユーザー (プラットフォーム)
      • 自動化：観測事象の拡張 (例：WhoIs)
    • アーティファクトとその評判または既知の脅威との関連付けを使用したインシデントの調査
      • 調整：Playbook とナレッジベース記事
      • 自動化：脅威のルックアップ (例：VirusTotal)、サイティング検索 (例：Splunk)、実行中のプロセスを取得 (例：Carbon Black)
    • 実行された調査に基づく、インシデントに関連する脅威関連のアーティファクトの根絶
      • 調整：Playbook とナレッジベース記事
      • 自動化：メールの検索と削除 (例：Microsoft Exchange)、IP のブロック (例：Palo Alto ファイアウォール)
    • 効率性またはインシデント応答操作の測定
      • Performance Analytics ダッシュボード：生産性とインシデントの傾向
      • 作業メモからのインシデント調査ステップの再構築
      • インシデントの事後レビュー

    ドメイン分離のセットアップ

    セキュリティインシデントレスポンス のドメイン分離を設定するには、追加の手順は必要ありません。インスタンスがドメイン分離された後、すべての セキュリティインシデントレスポンス テーブルで [ドメイン] 列が取得されます。

    ドメイン分離データ

    データはドメイン分離できます。これは、次のことを意味します。

    • あるドメイン内のセキュリティインシデントを他のドメインから表示することはできません。
    • セキュリティインシデントから抽出された観測事象は同じドメインに配置され、他のドメインから表示することはできません。
    • Kingston リリースまで、構成されたサードパーティ統合はグローバルドメインに存在し、インスタンス内の他のすべてのドメインからアクセスできます。
    • Madrid リリースでは、サードパーティ統合をドメインごとに構成してアクティブ化できます。これは、あるドメインでアクティブ化および構成された統合を別のドメインで活用できないことを意味します。
    • (脅威の調査、封じ込め、または根絶のために) サードパーティ統合を使用して観測事象で実行される自動化では、結果がセキュリティインシデントのドメインに配置され、別のドメインから結果を表示することはできません。
    • あるドメインで作成された Orchestration ワークフローを別のドメインで表示することはできません。
    • 呼び出される機能 (前の機能のリストに記載) は、呼び出される機能のドメイン固有の実装により、ドメイン全体で汎用的なままになります。たとえば、IP のサイティング検索で、あるドメインで Splunk 実装を呼び出し、別のドメインで QRadar 実装を呼び出すことができます。

    構成

    製品構成のすべての側面は、ドメイン分離された環境で自己完結型です。セットアップは、個々のドメインに合わせてカスタマイズできます。
    注:
    ビジネスロジックと下記の #2 ～ 5 のプロセスは、テナントドメイン内で管理できます。

    次のタスクを構成する必要があります。

    1. システム管理
    2. セキュリティインシデントレスポンス 管理
    3. セキュリティインシデントメールの設定
    4. セキュリティインシデント Playbook の設定
    5. 機能の設定

    テナントドメインが独自のアプリケーションデータを管理する方法

    • テナントドメインオーナーは、セキュリティインシデントを取り込むための独自のメール解析ルールを作成します。
    • テナントドメインオーナーは、ドメイン内で使用するために特定の統合を構成できます。
    • テナントドメインオーナーは、独自のインシデント応答ワークフローを作成できます。
    • テナントドメインオーナーは、独自のインシデントカテゴリ、インシデント応答のナレッジベース記事、および Runbook を作成して、インシデント応答ワークフローに関連付けることができます。
    • テナントドメインユーザーは、独自のセキュリティインシデントを作成し、クローズします。

    インスタンスオーナーがドメイン分離できるビジネスロジックとプロセス

    • セキュリティインシデントレスポンス ユーザーとグループ
    • セキュリティインシデントレスポンス 統合 (Madrid リリースから)
    • インシデント作成のためのメール解析ルール
    • 複数のイベントまたはアラートをセキュリティインシデントに統合するビジネスルール
    • インシデント応答オーケストレーションのワークフロー
    • セキュリティインシデントリスクスコア算出
    • セキュリティインシデントのエスカレーションパス
    • セキュリティインシデント SLA
    • セキュリティインシデントプロセス定義
    • セキュリティインシデントのインシデント後のレビュープロセス