> ## Documentation Index > Fetch the complete documentation index at: https://docs.casebender.com/llms.txt > Use this file to discover all available pages before exploring further. # Splunk > CaseBender と Splunk（Enterprise Security）間の双方向統合。notable/アラートの取り込み、HEC による監査転送、notable クローズの同期に対応します。 ## 概要 Splunk 統合（**INT-001**）は、**Splunk Enterprise Security (ES)** の notable イベントを含め、 CaseBender と Splunk 間の**双方向**同期を提供します。 Splunk の notable とアラートは CaseBender に取り込まれます。ES の REST 検索 API 経由で スケジュールにより**自動的にプル**されるか、Splunk のアラートアクション／Webhook から **プッシュ**され、その後で正規化され、オブザーバブルで強化され、アラート（またはケース） に変換されます。 ケースのライフサイクルイベントは **HEC** 経由で Splunk インデックスに転送されます。 また、リンクされたケースがクローズされると、CaseBender は REST API 経由で監査コメント付きで **元の ES notable をクローズ**できます。 **2 つのインバウンド経路。** すでに Splunk でアラートを作成している場合は \*\*アラートアクション／Webhook（プッシュ）**を、CaseBender にスケジュールで保存済み検索を 実行させたい場合は**自動ポーリング（プル）\*\*を使用します。ポーリングには Enterprise Security の REST 接続が必要ですが、Webhook 経路では不要です。 アウトバウンド HEC は **HTTP Event Collector**（既定 `/services/collector/event`、通常はポート `8088`）を使用します。notable のプルとクローズは**管理 REST API**（通常はポート `8089`）を 使用します。オンプレミスの Splunk は両方で**自己署名証明書**を使うことが多いため、必要に応じて **Verify SSL** をオフにしてください（下記参照）。 ## 機能 | 機能 | 方向 | 説明 | | ------------------------ | ------- | ------------------------------------------------------------------------- | | **notable ポーリング（プル）** | インバウンド | CaseBender が ES の REST 検索 API 経由で SPL をスケジュール実行し、結果を自動取り込み。Splunk 側の設定は不要 | | アラート取り込み（プッシュ） | インバウンド | Splunk のアラートアクション／Webhook がペイロードを送信し、CaseBender のアラートに正規化 | | オブザーバブル抽出 | インバウンド | `src`/`dest`/`user`（および `*_ip`）フィールドが IP／ホスト名／ユーザーのオブザーバブルになる | | アセット抽出 | インバウンド | `host`（および IP でない `dest`）がホストアセットになる | | ケースの自動作成 | インバウンド | 取り込んだレコードを自動的にケースへ昇格可能（notable ID で重複排除） | | HEC 監査転送 | アウトバウンド | ケースの作成／更新／クローズとアラート昇格を Splunk インデックスに記録 | | notable クローズ（write-back） | アウトバウンド | ケースクローズ時、元の ES notable をコメント付きで `notable_update` によりクローズに設定 | | 接続テスト | アウトバウンド | HEC エンドポイントにテストイベントを送信 | ## 前提条件 Splunk のデプロイメント。notable のプル／クローズには **Splunk Enterprise Security** と `edit_notable_events` 権限を持つロールが必要です。HEC 転送には **HTTP Event Collector** トークンが必要です。 CaseBender のデプロイメント（およびポーリング用のバックグラウンドポーラーサービス）は、 Splunk の **HEC** エンドポイント（例 `:8088`）に、REST 機能では**管理**エンドポイント （例 `:8089`）に到達できる必要があります。 **設定 → 統合**で統合を作成・管理できる必要があります。 ## パート A — Splunk の準備 Splunk で **Settings → Data inputs → HTTP Event Collector → New Token** を開きます。HEC が 未有効ならグローバルに有効化し、対象インデックスを選択（または作成）して、トークン値を コピーします。 notable の**ポーリング**と**クローズ**には、**Settings → Tokens** で Splunk の **認証トークン**を作成します（または Basic 認証用のサービスアカウントを使用）。関連する ロールには、notable をクローズするための `edit_notable_events` と、notable インデックスへの 検索アクセスが必要です。 ## パート B — CaseBender で統合を構成 **設定 → 統合 → 作成**に移動し、**SIEM** カテゴリから **Splunk** を選択します。 `purpose` を **Inbound**、**Outbound**、または **Bidirectional** に設定すると、関連する 構成カードが表示されます。 **Webhook URL** をコピーし、**API キー**（接頭辞 `sk_splunk_`）を生成します。Splunk で、 ヘッダー `Authorization: Bearer ` を付けてその URL に POST する **Webhook** アラートアクションを追加します。 **Enterprise Security REST API** カードに、管理 URL（例 `https://splunk:8089`）と資格情報を 入力します。 | フィールド | 説明 | | ------------------------------- | --------------------------------------- | | `restUrl` | Splunk の管理 URI（通常はポート 8089） | | `restAuthType` | `token`（bearer）または `basic`（ユーザー名／パスワード） | | `restToken` | Splunk 認証トークン（bearer） | | `restUsername` / `restPassword` | Basic 認証の資格情報 | この接続は notable の**ポーリング**と**クローズ**の両方を支えます。 **Automatic polling** カードで **Enable automatic polling** をオンにし、次を設定します。 | オプション | 効果 | | ----------------------------- | ----------------------------------------------------------------- | | `pollingEnabled` | Splunk 結果のスケジュールプルを有効化 | | `searchQuery` | 各間隔で実行する SPL（例 `` search `notable` ``、`search` または `\|` で始める必要あり） | | `pollingIntervalMinutes` | ポーリング頻度（既定 `5`、範囲 1–1440） | | `pollingInitialLookbackHours` | 初回実行時、このウィンドウ内の結果を取り込む（既定 `24`、範囲 1–168） | 仕組みは[自動ポーリング](#インバウンド自動ポーリング)を参照してください。 **Outbound** カードで HEC の URL、トークン、インデックスを入力し、次を有効化します。 | オプション | 効果 | | ------------------------- | ------------------------------------------------------------------ | | `syncCaseUpdates` | `case_created` / `case_updated` / `alert_promoted` 監査イベントを HEC に転送 | | `syncCaseClose` | `case_closed` 監査イベントを HEC に転送 | | `closeNotableOnCaseClose` | リンクされたケースのクローズ時に、元の ES **notable** を REST 経由でクローズ | | `autoCreateCases` | 取り込んだ各 Splunk レコードを自動的に**ケース**へ昇格 | **Test Connection** を使って HEC エンドポイントにテストイベントを送信します。Splunk が 自己署名証明書を使用している場合は **Verify SSL** をオフにします。 ## インバウンド（自動ポーリング） **自動ポーリング**を有効にすると、CaseBender は Enterprise Security の REST 検索 API 経由で 定期的に SPL を実行し、自ら結果を取り込みます。**Splunk 側のアラートアクションや Webhook は 一切不要**です。 ### 仕組み 各間隔（`pollingIntervalMinutes`）ごとに、CaseBender はストリーミングエクスポート エンドポイント経由で、前回のカーソル以降のウィンドウに対して `searchQuery` を実行します。 ``` POST https://:8089/services/search/jobs/export search=<あなたの SPL>&earliest_time=<カーソル>&latest_time=now&output_mode=json ``` 初回実行時はカーソルがないため、`pollingInitialLookbackHours` 内の結果が取り込まれます。 CaseBender は統合ごとのカーソルを、見た中で最新の結果 `_time` まで進めるため、各実行は 新しいアクティビティのみを取得します。結果は notable の **`event_id`**（フォールバックは 検索 `sid`）で**重複排除**されるため、ポーリングウィンドウが重なっても notable が二重に 取り込まれることはありません。 各結果行は CaseBender のアラートに正規化されます。`urgency` から重大度をマッピングし、 タイトル／説明を構築し、オブザーバブルとホストアセットを抽出します。後でアウトバウンドの クローズ同期が見つけられるよう、notable の `event_id` がアラートに刻印されます。 **`autoCreateCases` を有効**にすると、ポーリングされた各 notable は自動的に**ケース**になります （notable ID で重複排除）。これは「notable をプル → ケースとして対応」というフローに一致します。 無効の場合、結果は手動昇格のために**アラート**受信箱に届きます。いずれの場合も Splunk リンクは 保持され、ケースをクローズすると notable をクローズできます。 ポーリングは CaseBender のバックグラウンドポーラーサービスで実行されます。そのサービスが Splunk の管理エンドポイントに（直接または構成済みプロキシ経由で）到達できることを確認して ください。プロキシ専用ネットワークでは、内部の Splunk ホストを `NO_PROXY` に列挙してください。 ## インバウンド（Webhook / プッシュ） ポーリングの代替（または併用）として、Splunk の**アラートアクション**（または任意の Webhook 送信元）が検索結果を CaseBender の取り込みエンドポイントにプッシュできます。 ### エンドポイント ``` POST https://<あなたの-casebender-ドメイン>/api/v1/ingest/splunk ``` リクエストは統合の **API キー**（`Authorization: Bearer ` として渡す。`x-api-key` ヘッダーも受け付けます）で認証されます。Splunk の Webhook API キーは接頭辞 `sk_splunk_` を 持ちます。 ### ペイロード例 Splunk の Webhook アラートアクションは、`result` オブジェクトと検索メタデータを送信します。 ```bash theme={null} curl -X POST "https://<あなたの-casebender-ドメイン>/api/v1/ingest/splunk" \ -H "Authorization: Bearer sk_splunk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \ -H "Content-Type: application/json" \ -d '{ "sid": "scheduler__admin__search__RMD5...", "search_name": "Threat - Brute Force Access - Rule", "results_link": "https://splunk.example.com/app/search/...", "app": "SplunkEnterpriseSecuritySuite", "result": { "event_id": "A1B2C3D4-...", "rule_title": "Brute Force Access Behavior Detected", "urgency": "high", "security_domain": "access", "src": "10.0.0.5", "dest": "10.0.0.20", "user": "jdoe" } }' ``` 成功したリクエストは HTTP `202 Accepted` を返します。 ```json theme={null} { "success": true, "messageId": "..." } ``` ### 処理パイプライン `/api/v1/ingest/splunk` がソースを検証し、リクエストを取り込みサービス （`POST /v1/sources/splunk`）へ転送します。 取り込みサービスが API キーを認証し、ペイロードを検証して、レコードを処理キューに発行します。 Splunk プロセッサがレコードを CaseBender のアラートに正規化します。重大度をマッピングし、 タイトル／説明を構築し、オブザーバブルとホストアセットを抽出します。 ### データマッピング参照 **重大度マッピング**（Splunk `urgency` → CaseBender 1–4）: | Splunk urgency | CaseBender 重大度 | | ----------------------- | -------------- | | `critical` | 4 | | `high` | 3 | | `medium` | 2 | | `low` / `informational` | 1 | **オブザーバブル／アセットの抽出:** | Splunk フィールド | オブザーバブル／アセット | | ------------------ | -------------------------------- | | `src` / `src_ip` | `ip` または `hostname` オブザーバブル（IOC） | | `dest` / `dest_ip` | `ip` または `hostname` オブザーバブル | | `user` | `user` オブザーバブル | | `host` | ホストアセット | **タイトル**は `rule_title` → `search_name` → `alert_name` → `signature` → `message` の順で 構築されます。取り込み時に付与される**タグ**には `splunk`、`siem`、`notable`（ES notable の 場合）、`domain:`、`app:` が含まれます。取り込まれたレコードは既定で **TLP:2** および **PAP:2** です。 ## アウトバウンド: HEC 監査転送 `syncCaseUpdates` / `syncCaseClose` で有効にすると、CaseBender は JSON 監査イベントを HEC エンドポイントに発行し、ケースアクティビティを Splunk で検索できるようにします。 | イベント | HEC `action` | 条件 | | ------- | ------------------------ | ----------------- | | ケース作成 | `case_created` | `syncCaseUpdates` | | ケース更新 | `case_updated` | `syncCaseUpdates` | | アラート昇格 | `alert_promoted_to_case` | `syncCaseUpdates` | | ケースクローズ | `case_closed` | `syncCaseClose` | イベントは `source: casebender:case`（または `casebender:alert`）と `sourcetype: _json` で 構成済みインデックスに送信されます。 ## アウトバウンド: Splunk notable のクローズ（write-back） CaseBender でケースがクローズされると、`case_closed` イベントが Splunk ハンドラーに ディスパッチされます。ケースが Splunk notable にリンクされており、**かつ** `closeNotableOnCaseClose` がオンの場合、CaseBender は ES の REST API 経由で notable を クローズします。 ### リンクされた notable の解決方法 取り込みパイプラインは、各 Splunk アラートの `customFields` に `splunkEventId`（notable の `event_id`）と取り込み元の統合 ID を刻印します。ケースクローズ時、ハンドラーはケースに リンクされたアラートからそれらのイベント ID を収集するため、ポーリングまたは Webhook の notable から昇格したケースは、作成方法に関係なく自動的に解決されます。 ### 送信される内容 CaseBender は ES の `notable_update` エンドポイントを呼び出します。 ``` POST https://:8089/services/notable_update ruleUIDs=["", ...]&status=&comment=&output_mode=json ``` * `status` は既定で \*\*5（Closed）\*\*で、`notableStatusOnClose` で構成可能です。 * `comment` は `Case closed in CaseBender with resolution: ` です。 結果（クローズした notable、またはエラー）はケースのタイムラインに記録され、アナリストが同期を 確認できます。 `syncCaseClose`（HEC 監査イベント）と `closeNotableOnCaseClose`（REST による notable write-back）は、統合ごとに独立したトグルです。notable の write-back には Enterprise Security の REST 接続と `edit_notable_events` 権限を持つロールが必要です。 ## セキュリティ上の考慮事項 * **トークンの取り扱い** — HEC トークンおよび REST のトークン／パスワードは統合設定に保存され ます。組織の方針に沿ってローテーションし、その都度統合を更新してください。 * **最小権限** — REST ロールには notable インデックスへの検索アクセスと `edit_notable_events` のみが必要です。HEC トークンは専用インデックスを対象にすべきです。 * **Webhook キー** — `sk_splunk_` API キーは秘密として扱ってください。漏洩した場合は ローテーションし、Splunk のアラートアクションを更新します。 * **TLS** — 信頼された証明書を優先してください。自己署名証明書を使う必要がある場合（オンプレミス で一般的）、**Verify SSL** をオフにできます。接続は暗号化されたままですが、証明書は検証され ません。送信先は Splunk の HEC および管理エンドポイントに制限してください。 ## トラブルシューティング HEC の URL とトークン、HEC が有効であること、CaseBender が HEC ポート（通常 `8088`）に到達 できることを確認してください。Splunk が自己署名証明書を使用している場合は **Verify SSL** を オフにします。そうしないと証明書エラーで失敗します。 `Authorization: Bearer`（または `x-api-key`）ヘッダーが欠落しているか無効です。統合に構成した Webhook API キーと一致する `sk_splunk_` キーを送信していることを確認してください。 **Enable automatic polling** がオンで、**ES REST** 接続が入力され、**検索クエリ**が設定されて いることを確認してください。ロールが検索を実行でき管理ポート（通常 `8089`）に到達できること、 カーソルより新しい結果があることを確認します。初回実行では `pollingInitialLookbackHours` 内の結果のみが取り込まれます。統合の最終同期ステータスで具体的なエラーを確認してください。 `closeNotableOnCaseClose` がオンで、**ES REST** 接続が `edit_notable_events` を持つロールで 構成されていることを確認してください。ケースは Splunk notable にリンクされている必要があります — ポーリング／Webhook の notable から昇格したケースをクローズすると、リンクは自動的に解決され ます。同期結果はケースのタイムラインで確認してください。 `403` は REST ロールに `edit_notable_events` 権限がないことを意味します。`404` は通常、URL が Enterprise Security の管理エンドポイントでないことを意味します。`restUrl` が ES がインストール された Splunk の管理ポートを指していることを確認してください。 プロキシ専用ネットワークでは、接続が直接になるよう内部の Splunk ホストを `NO_PROXY` に追加し、 証明書が自己署名の場合は **Verify SSL** をオフにしてください。 ## 関連ドキュメント * [統合の概要](./introduction.mdx) * [Splunk HTTP Event Collector](https://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector) * [Splunk ES notable イベントアクション](https://docs.splunk.com/Documentation/ES/latest/User/Triagenotableevents)