メインコンテンツへスキップ

​
概要

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 をオフにしてください（下記参照）。

​
機能

​
前提条件

1

Splunk へのアクセス

Splunk のデプロイメント。notable のプル／クローズには Splunk Enterprise Security と edit_notable_events 権限を持つロールが必要です。HEC 転送には HTTP Event Collector トークンが必要です。
2

ネットワークの送信

CaseBender のデプロイメント（およびポーリング用のバックグラウンドポーラーサービス）は、 Splunk の HEC エンドポイント（例 :8088）に、REST 機能では管理エンドポイント （例 :8089）に到達できる必要があります。
3

CaseBender 管理者ロール

設定 → 統合で統合を作成・管理できる必要があります。

​
パート A — Splunk の準備

1

HEC トークンの作成（アウトバウンド転送用）

Splunk で Settings → Data inputs → HTTP Event Collector → New Token を開きます。HEC が 未有効ならグローバルに有効化し、対象インデックスを選択（または作成）して、トークン値を コピーします。
2

認証トークンの作成（REST 機能用）

notable のポーリングとクローズには、Settings → Tokens で Splunk の 認証トークンを作成します（または Basic 認証用のサービスアカウントを使用）。関連する ロールには、notable をクローズするための edit_notable_events と、notable インデックスへの 検索アクセスが必要です。

​
パート B — CaseBender で統合を構成

1

統合カタログを開く

設定 → 統合 → 作成に移動し、SIEM カテゴリから Splunk を選択します。
2

目的を選択

purpose を Inbound、Outbound、または Bidirectional に設定すると、関連する 構成カードが表示されます。
3

インバウンド Webhook（プッシュ）を構成

Webhook URL をコピーし、API キー（接頭辞 sk_splunk_）を生成します。Splunk で、 ヘッダー Authorization: Bearer <API_KEY> を付けてその URL に POST する Webhook アラートアクションを追加します。
4

Enterprise Security REST 接続を構成（任意）

Enterprise Security REST API カードに、管理 URL（例 https://splunk:8089）と資格情報を 入力します。この接続は notable のポーリングとクローズの両方を支えます。
5

自動ポーリングを有効化（任意）

Automatic polling カードで Enable automatic polling をオンにし、次を設定します。仕組みは自動ポーリングを参照してください。
6

アウトバウンドを構成（HEC + notable クローズ）

Outbound カードで HEC の URL、トークン、インデックスを入力し、次を有効化します。
7

接続をテスト

Test Connection を使って HEC エンドポイントにテストイベントを送信します。Splunk が 自己署名証明書を使用している場合は Verify SSL をオフにします。

​
インバウンド（自動ポーリング）

自動ポーリングを有効にすると、CaseBender は Enterprise Security の REST 検索 API 経由で 定期的に SPL を実行し、自ら結果を取り込みます。Splunk 側のアラートアクションや Webhook は 一切不要です。

​
仕組み

1

スケジュール検索

各間隔（pollingIntervalMinutes）ごとに、CaseBender はストリーミングエクスポート エンドポイント経由で、前回のカーソル以降のウィンドウに対して searchQuery を実行します。
初回実行時はカーソルがないため、pollingInitialLookbackHours 内の結果が取り込まれます。
2

カーソル + 重複排除

CaseBender は統合ごとのカーソルを、見た中で最新の結果 _time まで進めるため、各実行は 新しいアクティビティのみを取得します。結果は notable の event_id（フォールバックは 検索 sid）で重複排除されるため、ポーリングウィンドウが重なっても notable が二重に 取り込まれることはありません。
3

正規化

各結果行は CaseBender のアラートに正規化されます。urgency から重大度をマッピングし、 タイトル／説明を構築し、オブザーバブルとホストアセットを抽出します。後でアウトバウンドの クローズ同期が見つけられるよう、notable の event_id がアラートに刻印されます。
autoCreateCases を有効にすると、ポーリングされた各 notable は自動的にケースになります （notable ID で重複排除）。これは「notable をプル → ケースとして対応」というフローに一致します。 無効の場合、結果は手動昇格のためにアラート受信箱に届きます。いずれの場合も Splunk リンクは 保持され、ケースをクローズすると notable をクローズできます。
ポーリングは CaseBender のバックグラウンドポーラーサービスで実行されます。そのサービスが Splunk の管理エンドポイントに（直接または構成済みプロキシ経由で）到達できることを確認して ください。プロキシ専用ネットワークでは、内部の Splunk ホストを NO_PROXY に列挙してください。

​
インバウンド（Webhook / プッシュ）

ポーリングの代替（または併用）として、Splunk のアラートアクション（または任意の Webhook 送信元）が検索結果を CaseBender の取り込みエンドポイントにプッシュできます。

​
エンドポイント

リクエストは統合の API キー（Authorization: Bearer <key> として渡す。x-api-key ヘッダーも受け付けます）で認証されます。Splunk の Webhook API キーは接頭辞 sk_splunk_ を 持ちます。

​
ペイロード例

Splunk の Webhook アラートアクションは、result オブジェクトと検索メタデータを送信します。
成功したリクエストは HTTP 202 Accepted を返します。

​
処理パイプライン

1

取り込みプロキシ

/api/v1/ingest/splunk がソースを検証し、リクエストを取り込みサービス （POST /v1/sources/splunk）へ転送します。
2

キューへの発行

取り込みサービスが API キーを認証し、ペイロードを検証して、レコードを処理キューに発行します。
3

正規化

Splunk プロセッサがレコードを CaseBender のアラートに正規化します。重大度をマッピングし、 タイトル／説明を構築し、オブザーバブルとホストアセットを抽出します。

​
データマッピング参照

重大度マッピング（Splunk urgency → CaseBender 1–4）: オブザーバブル／アセットの抽出: タイトルは rule_title → search_name → alert_name → signature → message の順で 構築されます。取り込み時に付与されるタグには splunk、siem、notable（ES notable の 場合）、domain:<security_domain>、app:<app> が含まれます。取り込まれたレコードは既定で TLP:2 および PAP:2 です。

​
アウトバウンド: HEC 監査転送

syncCaseUpdates / syncCaseClose で有効にすると、CaseBender は JSON 監査イベントを HEC エンドポイントに発行し、ケースアクティビティを Splunk で検索できるようにします。 イベントは 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 エンドポイントを呼び出します。
  • status は既定で **5（Closed）**で、notableStatusOnClose で構成可能です。
  • comment は Case <id> closed in CaseBender with resolution: <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 をオフにしてください。

​
関連ドキュメント