本文是 Splunk overview 的 implementation-layer deep article。Overview 已說明 Splunk Enterprise Security 在 SIEM / Detection 譜系的定位、本文聚焦 Risk-Based Alerting (RBA) 的實作層 — 從「per-rule alert」轉到「score 累積 + threshold 觸發 notable」的方法論轉變、跟 tuning / scaling / 整合的具體做法。

為什麼 RBA：alert fatigue 是 detection engineering 的天花板

Detection engineering 的成熟度上限不是「能寫多少 correlation rule」、是「SOC analyst 能處理多少 alert / day 而不會麻木」。多數 SOC 在 200-500 alert/day 區間就到處理上限、再加 rule 只會推升 false positive、analyst 開始 silent ignore 中低嚴重度 alert。

RBA 的核心轉折是 把 alert 邏輯從「rule 觸發」拆成「score 累積」：每個 detection rule 不直接產 alert、而是給 user / asset / process 加 risk score；多個低嚴重訊號累積到 threshold 才產 notable（高優先 case）。SOC 看的不是「rule X 觸發了」、是「user Y 今天累積 70 分、上週 12 分」。

RBA 不是 寫 detection rule 的替代、是 aggregation 跟 prioritization 的新層。原本 100 條 rule 各自產 alert 變成 100 條 rule 共同貢獻 score、score → notable 是新的 alert 邊界。

RBA 三層 model：modifier、score、notable

Risk 流程的三個 first-class object：

關鍵設計選擇都在 modifier 層：

• 加分維度：per user / per asset / per process tree / per IP — 維度越細粒度、score 越能對應「個體」、但 query 成本越高
• 加分 weight：簡單做法 severity 直接對應（low=5 / med=15 / high=30 / critical=60）；細做要考慮 signal precision（rule 的歷史 FP rate）
• MITRE ATT&CK 對應：每個 modifier 標 tactic / technique、跟 ATT&CK 對應、用來判斷 kill chain 階段 是否完整（reconnaissance → exfiltration 全套出現 vs 單一 tactic 重複）

ES 配置 step-by-step

Risk modifier 從 correlation search 產出

| search index=auth user=* unusual_geo=true
| stats count by user, src_ip, _time
| eval risk_score=25
| eval risk_object_type="user"
| eval risk_object=user
| eval risk_message="Unusual login geography"
| eval threat_object=src_ip
| eval threat_object_type="ip_address"
| eval mitre_technique="T1078"
| collect index=risk

關鍵欄位：

• risk_object + risk_object_type：誰被加分、預設 user / system / other
• risk_score：加多少分、考量 signal precision
• threat_object：對應的 attacker artifact（IP / hash / domain）、用來跨 modifier 關聯
• mitre_technique：對應 ATT&CK ID、用於 kill chain analysis

Tuning 提醒：第一次部署別直接 collect index=risk、先 | table 看 output、估算每天會產多少 modifier；超出 indexer 容量規劃前先做 sampling（| where random()/2147483647<0.1 取 10%）。

Risk notable：threshold aggregation

| tstats summariesonly=t count, sum(All_Risk.calculated_risk_score) as total_risk
  from datamodel=Risk.All_Risk
  where earliest=-24h
  by All_Risk.risk_object, All_Risk.risk_object_type
| where total_risk > 80
| `risk_score_format`

total_risk > 80 是觸發 notable 的 threshold。Tuning 重點：

• Time window：-24h 是預設、但要看 attack pattern average duration 調整；APT 用 7-14 day window、commodity attack 用 4-12h
• Threshold value：80 是 當量 不是普世值、依 modifier weight 分佈調整；ES 7.0+ 預設建議 100、實務多在 60-150 區間
• Aggregation 維度：by user 是 default、但 lateral movement scenario 要 by asset、credential abuse 要 by service account

Tuning 提醒：第一週跑 shadow mode — 觸發 notable 但不 page、SOC 後續 review、調整 threshold 跟 weight；shadow 跑 1-2 週後再啟 production page。

Notable enrichment：人類能看的 case

| eval description="User ".risk_object." accumulated ".total_risk." risk over 24h"
| eval mitre_techniques=mvjoin(mitre_technique, ", ")
| eval contributing_rules=mvjoin(search_name, ", ")
| sendalert notable

Notable 進入 ES Incident Review、SOC analyst 看到的不只 score、還有 組成這 80 分的 N 條 rule + ATT&CK 覆蓋的 tactic；這是 RBA 比 per-rule alert 強的核心 — analyst 直接看完整 narrative、不用拼湊。

Tuning playbook：四類常見 drift

Playbook A：False positive 累積

徵兆：某 user 連續 N 天觸發 notable、SOC 每次 review 後 close 為 FP；但 modifier 仍持續加分。

根因：modifier 加分邏輯沒考慮 baseline — 例：DBA 每天用 psql 連 prod 是正常、unusual_command rule 把它當異常加 15 分、累積到 threshold。

修法：

1. Modifier 端加 whitelist_lookup：DBA / SRE / approved service account 跳過 specific modifier
2. 進階：modifier 加 signal_precision weight、historical FP rate > 30% 的 rule weight 降到 5 分以下
3. 不能輕易加 NOT user IN (...) exclusion、long whitelist 是反模式 — 用 role-based exclusion（query AD group）

Playbook B：Score inflation

徵兆：threshold 設 80、SOC 收到的 notable 每 day 從 5 個漲到 25 個、但「實際攻擊」沒對應增加。

根因：新加的 detection rule 沒對齊既有 weight 分佈、新 rule 都給 +30 / +40、global average 抬升、threshold 變相降低。

修法：

1. 每加新 rule 時跑「+1 rule 對 daily notable 數的影響」shadow simulation
2. 重新 calibrate threshold — 不是固定值、是 p95 daily total_risk 的 1.5 倍
3. 季度 review：跑 index=risk | stats sum(risk_score) by source 看 modifier 來源分佈、score 集中在少數 rule 是 inflation 訊號

Tuning 提醒：score inflation 跟 alert fatigue 是同樣症狀的不同根因；前者改 threshold + rule weight calibration、後者改 modifier 維度跟 whitelist。

Playbook C：Threshold drift

徵兆：threshold 設定半年沒動、但 attack landscape / business 行為都變了；要嘛 notable 太多（threshold 低於 baseline）、要嘛 missed detection（threshold 高於實際攻擊累積）。

根因：threshold 是 static value、但 baseline 是 dynamic；business 流程變動（雲端遷移 / 新部門 / WFH 比例變化）影響 modifier 觸發頻率。

修法：

1. Quarterly tuning cadence：每季跑 tstats sum(All_Risk.calculated_risk_score) by user | stats p50, p95, p99 看分佈
2. Adaptive threshold：用 p95 × 1.3 動態計算、寫 macro 自動 update
3. 不要把 threshold drift 當「rule 不準」、是 基準漂移、不是 rule 錯

Playbook D：Decay 設計

徵兆：user 7 天前的低分異常持續累積在 score 內、threshold 觸發 notable 但實際是 7 天分散事件、不是 當前攻擊 episode。

根因：default RBA 在 -24h window 內 sum、沒考慮 時間衰減；7 天前的低分跟今天的低分權重一樣。

修法：加 decay function、modifier weight 隨時間衰減：

| eval age_hours=(now() - _time)/3600
| eval decayed_score = calculated_risk_score * exp(-age_hours / 48)
| stats sum(decayed_score) as total_risk by risk_object

exp(-age/48) 是 48 小時半衰期、24h 前的事件權重剩 60%、48h 剩 37%、7 天前剩 < 3%。half-life 依 attack pattern 調整：commodity attack 12-24h、APT 5-14 day。

Capacity 規劃

RBA 的 capacity 三個面向：

實務 sizing：500K modifier/day、用戶 5K、tstats hourly trigger search、需要 3 indexer + 1 search head（含 RBA 之外的工作）。

注意 SC4S / Splunk Cloud ingest pricing — RBA 不增 ingest GB / day、但 datamodel acceleration 算 CPU 工作量、Splunk Cloud 是另外計費的 vCPU；on-prem 自管 indexer 沒這個 cost。

整合 / 下一步

跟 SOAR / case management

Notable 觸發後接 SOAR：

• enrichment：自動 query AD / asset DB / threat intel、把 user role / asset criticality / known IoC 補進 case
• decision tree：根據 risk score 區間決定 SOC tier（< 100 tier 1 / 100-200 tier 2 / 200+ tier 3 + page）
• playbook automation：disable user / isolate endpoint / rotate credential 走 SOAR pipeline、不要 SOC analyst 手動 click

跟 Elastic Security / Sentinel 對照

各家對 RBA 的實作命名不同：Splunk 叫 RBA、Elastic 叫 Risk Engine、Microsoft Sentinel 叫 Fusion + UEBA aggregation、Sumo Logic 叫 Insight Trainer；底層概念相同（score aggregation + threshold notable）、細節差在 modifier 寫法跟 ML 自動化程度。跨平台遷移時 modifier 邏輯多半要重寫、threshold + decay tuning 經驗可以平移。

跟 UEBA

RBA 跟 UEBA（user / entity behavior analytics）是 互補不是替代 — UEBA 用 ML 算 baseline 偏差、輸出 anomaly score 餵進 RBA 當一個 modifier 來源。實作順序通常是 先靜態 rule + RBA、再加 UEBA 補充；直接從 ML-first 開始通常 tuning 成本爆炸。

下一步議題

• Threat object correlation：跨 modifier 用 threat_object 串相同 attacker artifact、score 跨 user 跨 asset 聚合
• Kill chain coverage analysis：notable 拆成「ATT&CK tactic 覆蓋 N/14」、覆蓋越廣 priority 越高
• Risk-based response automation：score 區間自動觸發不同 SOAR playbook、人工只 review tier 3

相關連結

• 上游 vendor 頁：Splunk
• 對照案例：Okta Cross-Tenant Impersonation 2023、Microsoft Storm-0558
• 上游 chapter：7.13 偵測覆蓋率與訊號治理
• 平行 vendor：Elastic Security / Google Security Operations
• 平行 deep article：Vault Dynamic Credential
• Methodology：Vendor 深度技術文章的寫作方法論

本文是跨 vendor migration playbook、cross-link 到 Splunk（source）跟 Elastic Security（target）兩個 vendor overview。Migration playbook 跟 vendor deep article methodology 的 6-section flow 不同 — 是 phased process（audit → translation → parallel run → cutover → cleanup）、強調 時間軸 跟 回退邊界。

為什麼遷：cost / multi-vendor / cloud-native 三條 driver

Splunk → Elastic 遷移在 2022+ 變主流選項、driver 通常三條疊加：

反向 driver（Elastic → Splunk）也存在但少數 — 主要是 合規 / 政府客戶要 Splunk Cloud GovCloud、或 Splunk Premium ES 的 RBA + UEBA 成熟度仍領先。本文聚焦 Splunk → Elastic、反向流程結構相同但 schema 對位方向相反。

結構：phased migration 不是 6-section deep article

跟 single-feature deep article（Splunk RBA、Vault dynamic credential）不同、migration playbook 的核心是 time-sequenced phase + 回退邊界。6 段 phase：

整個遷移週期 4-9 個月、跟 single deep article 1-2 小時完全不同 scale。

Phase 0：rule audit 建 baseline

遷移前必須先知道 current state：

-- Splunk rule 盤點
| rest /servicesNS/-/-/saved/searches
  splunk_server=local search="alert"
| where disabled=0
| eval rule_age=now()-strptime(updated, "%Y-%m-%dT%H:%M:%S")
| stats count, avg(rule_age) by app, owner

每條 rule 量化四個指標：

Audit 階段的關鍵決策：哪些 rule 不翻譯 — production 通常 30-50% rule 是 legacy / dead code / 已 deprecated；遷移是 清理機會、不是「全部複製過去」。

Phase 1：Schema 對位

Splunk 跟 Elastic 的 data model 沒有 1:1 mapping、必須先建對位 spec：

Field mapping 是最大坑：Splunk 自由 schema（extract runtime）vs Elastic 強 type ECS。Splunk 端 src_ip 可能是 string；Elastic 端必須 source.ip 是 ip type — 任何 ingest pipeline 都要先把 raw event 轉成 ECS 結構。

Phase 2：Translation pipeline

實務 translation 用 3-tier hybrid：

Tier 1: vendor tool（cover 30-50%）

Elastic 官方提供 splunk-to-elastic migration assistant（SaaS / on-prem）— 對 簡單 SPL search 自動轉 KQL；cover ratio 視 SPL 複雜度而定。

Tier 2: LLM-assisted（cover 30-40%）

對 中等複雜 SPL（含 stats / eval / where）、用 Claude / GPT 翻譯：

1prompt template:
2"Convert this Splunk SPL to Elastic ES|QL. Preserve detection logic. List any
3unmappable functions.
4
5SPL:
6index=auth action=login user=* | bucket _time span=5m
7| stats count by user, src_ip, _time | where count > 10"

LLM output 必須 人工 verify：

• 對相同樣本資料跑 SPL vs ES|QL、output 對齊
• FP rate 不能 惡化
• Threshold / window 對等（5m window 跟 5m window 對應）

Tier 3: manual（cover 10-30%）

剩下的是：

• 含 macro 跨 SPL fragment 的 rule（macro 必須先展開或 inline）
• 含 summary index 跟 tstats 的高效能 rule
• 用 transaction / streamstats 的 stateful query

這類 rule 翻譯成 KQL 邏輯後、通常 效能差 5-20x（Splunk summary index 是 precomputed、KQL 是 runtime）；要評估 改用 Elastic transform 或 接受效能下降。

Phase 3：Parallel run

雙 SIEM 同時跑是 最重要的 confidence-building 階段：

1                 ┌─→ Splunk ──→ alert ──┐
2data source ─┤                          ├─→ alert dedup ──→ SOAR / SOC
3                 └─→ Elastic ──→ alert ─┘

Dedup 策略：

• Key：rule_name + event_id + timestamp_5min_bucket
• Window：5-10 分鐘（兩端有不同處理 latency）
• Routing：dedup 後送 SOAR、SOC 看「來自哪個 SIEM」標籤

跑 4-8 週累積：

不對齊的 rule 退回 Phase 2 重新 translation；累積到 95%+ 對齊才能進 Phase 4。

Phase 4：Cutover — routing 切換

1Before cutover:
2  Splunk → SOAR (active routing)
3  Elastic → SOAR (parallel, marked test)
4
5After cutover:
6  Splunk → ingest 持續 / alert disabled
7  Elastic → SOAR (active routing)

Cutover 期間：

1. PagerDuty / Opsgenie 端 先建 Elastic integration、不立刻 disable Splunk
2. 切換 dedup key 的 routing priority — 同一 alert 優先取 Elastic 那條
3. 保留 Splunk ingest — 不立刻停、提供 fallback 半小時
4. SOC 24h 監視、無異常進入 Phase 5

回退邊界：cutover 失敗（Elastic 端 alert 大量遺漏 / 延遲）→ routing 切回 Splunk、Elastic 端 alert 再標 test、回 Phase 3。回退時間 30 分鐘內。

Phase 5：Cleanup — 不可逆階段

Splunk ingest 停、license decommission、歷史資料 archive：

1# 1. 歷史 archive 到 S3（Splunk DDAS / Smart Store / 第三方）
2splunk export ... | aws s3 cp - s3://splunk-archive/
3
4# 2. 確認 archive 可查（cold storage retrieve test）
5# 3. Splunk indexer disable / Splunk Cloud subscription downgrade

不可逆邊界：Splunk license 退掉、historical query 必須走 S3 + 重 ingest 才能跑、SLA 從即時變天級。決策關鍵：

• 法規 retention（GDPR / SOX / HIPAA）多久
• Incident response 需要 historical query 的頻率
• 翻譯後的歷史資料 indexable in Elastic？多數情況 ECS 跟 CIM 結構差太大、historical 不直接可查

實務 default：Splunk Cloud 保留最低 tier 1 年、Elastic 接新資料；1 年後再評估 archive 策略。

Production 故障演練

Case 1：Macro 跨 SPL 沒對應 KQL function

徵兆：translation tool 把 macro \my_internal_lookup(…)`` 標 unmappable、人工翻譯後發現 macro 含 3 個巢狀 macro、共 80 行 SPL 邏輯；KQL 端拆成 5 個 runtime field + 2 個 ingest processor 才對等。

修法：

1. Audit 階段 用 splunk btool savedsearches list | grep <macro> 找所有 macro 使用點、估翻譯成本
2. Inline 策略：macro 在 5 處以下、直接 inline 到 detection rule、不重建 KQL macro
3. Ingest processor 策略：macro 是 資料轉換 邏輯、放 Elastic ingest pipeline、不放 detection rule
4. 退役策略：macro 已 deprecated、不翻譯、把使用的 rule 一起退役

Case 2：Time zone parsing 差異

徵兆：parallel run 階段、Splunk 跟 Elastic 對同一個 raw event 解出的 _time 差 8 小時；dedup key 沒對齊、雙 alert 都觸發。

根因：Splunk _time 是 epoch、time zone 由 props.conf 端決定；Elastic ingest pipeline 用 date processor、time zone 預設 UTC。raw event 有 Asia/Taipei timestamp、Splunk 解 UTC、Elastic 解 local。

修法：

1. Ingest pipeline 統一：所有 raw event 在 ingest 時轉 UTC、不依賴 source-side time zone
2. dedup 容忍 window：dedup window 拉到 30 分鐘、cover time zone 漂移
3. schema 對位 spec 明示時區處理：Phase 1 spec 要列「所有時間戳統一 UTC」

Case 3：Summary index 翻譯效能爆

徵兆：Splunk 端 tstats count from datamodel=Authentication where _time>=-7d 跑 2 秒、翻譯成 KQL 後 Elastic 跑 45 秒；SOC dashboard 端 timeout。

根因：Splunk summary index 是 precomputed（小時 / 天聚合預先算好）、tstats 直接讀 summary；KQL 直接跑 search 是 raw event scan、效能差數量級。

修法：

1. Elastic Transform：Elastic 端建 continuous transform、把 raw event 預先 aggregate 到 transform index、KQL 查 transform index、效能對等
2. Rollup index（Elastic legacy）：給 metric-style data 用、deprecated 但仍可
3. 接受 latency：dashboard query 可接受 30s、不必精準對等 Splunk

Case 4：Cutover 期間 PagerDuty dedup key 衝突

徵兆：cutover 後 24h、SOC 收到雙倍 alert；PagerDuty 兩條 incident 各標 splunk 跟 elastic source、實際是同一事件。

根因：PagerDuty 的 dedup key 用 rule_name + alert_id、Splunk alert_id 跟 Elastic signal_id 命名空間不同、PagerDuty 視為兩個獨立 incident。

修法：

1. 預先設計 dedup key：用 rule_name + event_hash、不用 SIEM 內部 ID
2. PagerDuty routing rule：cutover 期間 disable Splunk source routing、不要靠 dedup
3. Phase 3 parallel run 期間就測試 dedup：不要拖到 cutover 才發現

Case 5：過早 decommission Splunk、歷史 incident 無法回溯

徵兆：cutover 後 6 個月、發生 incident、需要回查 12 個月前的 auth log；Splunk 已 decom、Elastic 端歷史資料缺、S3 archive 無索引、4 小時找不到 evidence。

根因：Cleanup phase 過早走、沒先做 historical query rehearsal；S3 archive 沒可用的索引層。

修法：

1. 預防：Phase 5 前跑 5 個 historical query drill、驗證 incident response 時能用
2. 架構：S3 archive 配 Elastic frozen tier（searchable snapshot）、6 個月 retrieve latency 接受
3. 法規對齊：Cleanup 時間表必須跟 compliance retention requirement 對齊、不只是 cost-driven

Capacity / cost 對照

整合 / 下一步

跟 SOAR 整合

PagerDuty / Tines / Splunk SOAR：

• cutover 期間 SOAR playbook 仍用 Splunk-shaped event、Phase 5 後改 Elastic-shaped
• Playbook 內 SPL query 必須改寫 KQL / ES|QL、可 hybrid（短期保留 SOAR 端原 SPL 邏輯）

跟 case management 整合

Jira / ServiceNow / Elastic Cases：

• Splunk notable → Jira ticket 用 link field 帶 splunk_url
• Elastic alert → Jira 用 elastic_url
• 兩個 URL field 期間同時存在、Phase 5 後 archive

反向遷移（Elastic → Splunk）

結構 mirror 對稱、phase 仍 6 段、但 schema 對位方向相反：

• KQL → SPL 翻譯（vendor tool 對等度低、ES|QL → SPL 更困難）
• ECS → CIM 對位
• 多數企業 不會 反向遷、reverse migration 多半是合規驅動（特定客戶要 Splunk）

下一步議題

• Multi-vendor SIEM portfolio：不選一家、Splunk + Elastic + Sentinel 同時跑、routing 邏輯按 cost / use case 切
• AI-native detection：兩家都在發展、translation 流程可能再次重來
• Compliance migration constraints：金融 / 政府客戶 SIEM migration 需通過 audit、phase 時間表會被拉長

相關連結

• Source vendor：Splunk
• Target vendor：Elastic Security
• 上游 chapter：7.13 偵測覆蓋率與訊號治理
• 平行 deep article：Splunk RBA
• Methodology：Vendor 深度技術文章的寫作方法論