triaging-security-alerts-in-splunk

Splunk でのセキュリティアラートのトリアージ

使用する場面

以下の場合にこのスキルを使用します。

• SOC Tier 1 のアナリストが、Splunk Enterprise Security (ES) の Incident Review キューを処理する必要がある
• Notable event の重要度を迅速に分類し、エスカレーション前に初期調査を行う必要がある
• アラートの量が対応能力を超えており、アナリストが体系的なトリアージ手法を必要としている
• 管理者からアラートの処置（真陽性、偽陽性、良性）に関する指標を求められている

詳細なフォレンジック調査には使用しないでください。初期トリアージで悪意のある活動が確認された後、Tier 2/3 にエスカレーションしてください。

前提条件

• Incident Review ダッシュボードが設定された Splunk Enterprise Security 7.x+
• CIM で正規化されたデータソース（Windows イベントログ、ファイアウォール、プロキシ、エンドポイント）
• Notable event のステータスを更新するための ess_analyst 機能を持つロール
• SPL（Search Processing Language）の知識

ワークフロー

ステップ 1：Incident Review にアクセスし、キューに優先順位を付ける

Splunk ES で Incident Review ダッシュボードを開きます。重要度（severity x priority から算出）で notable event を並べ替えます。未割り当てのイベントに絞り込むには、次のフィルターを適用します。

| `notable`
| search status="new" OR status="unassigned"
| sort - urgency
| table _time, rule_name, src, dest, user, urgency, status
| head 50

まず Critical および High の重要度のイベントに注目します。各アラートを個別に扱うのではなく、src または dest で関連アラートをグループ化し、攻撃チェーンを特定します。

ステップ 2：Notable event のコンテキストを調査する

各 notable event について、ピボットして生イベントを確認します。ブルートフォースアラートの例を示します。

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4625
src_ip="192.168.1.105"
earliest=-1h latest=now
| stats count by src_ip, dest, user, status
| where count > 10
| sort - count

送信元 IP が内部（ラテラルムーブメント）か外部（境界への攻撃）かを確認します。アセットと ID のルックアップ結果と相互参照します。

| `notable`
| search rule_name="Brute Force Access Behavior Detected"
| lookup asset_lookup_by_cidr ip AS src OUTPUT category, owner, priority
| lookup identity_lookup_expanded identity AS user OUTPUT department, managedBy
| table _time, src, dest, user, category, owner, department

ステップ 3：データソース間で相関付ける

同じ送信元が他のテレメトリにも現れているか確認します。

index=proxy OR index=firewall src="192.168.1.105" earliest=-24h
| stats count by index, sourcetype, action, dest_port
| sort - count

裏付けとなる証拠を探します。同じ IP が DNS の異常、プロキシによるブロック、またはエンドポイントの検知アラートも引き起こしていないか確認します。

index=main sourcetype="cisco:asa" src="192.168.1.105" action=blocked earliest=-24h
| timechart span=1h count by dest_port

ステップ 4：脅威インテリジェンスによるエンリッチメントを確認する

脅威インテリジェンスフレームワークを検索し、既知の IOC を確認します。

| `notable`
| search search_name="Threat - Threat Intelligence Match - Rule"
| lookup threat_intel_by_ip ip AS src OUTPUT threat_collection, threat_description, threat_key
| table _time, src, dest, threat_collection, threat_description, weight
| where weight >= 3

ドメインについては、脅威リストと照合します。

| tstats count from datamodel=Web where Web.url="*evil-domain.com*" by Web.src, Web.url, Web.status
| rename Web.* AS *

ステップ 5：アラートを分類し、処置を決定する

Incident Review で notable event のステータスを更新します。

処置	基準	アクション
真陽性	裏付けとなる証拠によって悪意のある活動が確認された	Tier 2 にエスカレーションし、インシデントチケットを作成する
良性の真陽性	アラートは正しく発生したが、活動は許可されている（例：ペネトレーションテスト）	コメントを付けてクローズし、繰り返し発生する場合は抑制を追加する
偽陽性	アラートのロジックが良性の挙動に一致した	クローズし、相関サーチを調整して、パターンを記録する
判定不能	分類に十分なデータがない	調査メモを添えて Tier 2 に割り当てる

Splunk ES の UI または REST API から更新します。

| sendalert update_notable_event param.status="2" param.urgency="critical"
  param.comment="Confirmed brute force from compromised workstation. Escalated to IR-2024-0431."
  param.owner="analyst_jdoe"

ステップ 6：トリアージの調査結果を記録する

Notable event のコメント欄に次の内容を記録します。

• 関連する送信元／宛先
• 調査したデータソース
• 相関付けの結果（関連アラート、TI の一致）
• 処置の判断理由
• エスカレーション後の次のステップ

| `notable`
| search rule_name="Brute Force*" status="closed"
| stats count by status_label, disposition
| addtotal

ステップ 7：トリアージ指標を追跡する

トリアージのパフォーマンスを継続的に監視します。

| `notable`
| where status_end > 0
| eval triage_time = status_end - _time
| stats avg(triage_time) AS avg_triage_sec, median(triage_time) AS med_triage_sec,
        count by rule_name, status_label
| eval avg_triage_min = round(avg_triage_sec/60, 1)
| sort - count
| table rule_name, status_label, count, avg_triage_min

主な概念

用語	定義
Notable event	定義済みのリスクまたはしきい値の基準を満たす相関サーチによって生成された Splunk ES アラート
重要度	イベントの深刻度とアセット／ID の優先度を組み合わせて算出されるフィールド（Critical/High/Medium/Low/Informational）
相関サーチ	脅威のパターンを検知し、条件に一致すると notable event を生成する、スケジュール実行される SPL クエリ
CIM	Common Information Model — データソースをまたいだクエリを可能にする、Splunk の正規化されたフィールド命名規則
処置	アラートの最終分類：真陽性、偽陽性、良性の真陽性、または判定不能
MTTD/MTTR	Mean Time to Detect / Mean Time to Respond — 検知と解決の速度を測定する主要な SOC 指標

ツールとシステム

• Splunk Enterprise Security：インシデントレビューのダッシュボード、相関検索、リスクベースのアラート機能を提供する SIEM プラットフォーム
• Splunk SOAR (Phantom)：トリアージのプレイブックやエンリッチメントアクションを自動化するオーケストレーションプラットフォーム
• 資産・アイデンティティフレームワーク：コンテキストのエンリッチメントに利用するため、IP アドレスと資産所有者、ユーザーと部署を対応付ける Splunk ES のルックアップテーブル
• 脅威インテリジェンスフレームワーク：STIX/TAXII フィードを取り込み、IOC を重要イベントと照合する Splunk ES モジュール

よくあるシナリオ

• ブルートフォースアラート：同じ送信元からの EventCode 4625（ログオン失敗）と 4624（ログオン成功）を相関させ、攻撃が成功したかどうかを判断します
• マルウェア検出：エンドポイントの AV アラートをプロキシログと相互参照し、C2 コールバックを確認します
• データ流出アラート：DLP とプロキシログからの送信データ量を、ユーザーのベースラインと照合します
• 権限昇格：管理者以外のユーザーによる EventCode 4672（特別な権限の割り当て）と 4720（アカウント作成）を相関させます
• ラテラルムーブメント：単一の送信元から複数の宛先に対する EventCode 4648（明示的な資格情報を使用したログオン）をマッピングします

出力形式

TRIAGE REPORT — Notable Event #NE-2024-08921
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Alert:        Brute Force Access Behavior Detected
Time:         2024-03-15 14:23:07 UTC
Source:       192.168.1.105 (WORKSTATION-042, Finance Dept)
Destination:  10.0.5.20 (DC-PRIMARY, Domain Controller)
User:         jsmith (Finance Analyst)

Investigation:
  - 847 failed logons (4625) in 12 minutes from src
  - Successful logon (4624) at 14:35:02 after brute force
  - No proxy/DNS anomalies from src in prior 24h
  - Source not on threat intel lists

Disposition:  TRUE POSITIVE — Compromised credential
Action:       Escalated to Tier 2, ticket IR-2024-0431 created
              Account jsmith disabled pending password reset