前言：别让规则变成噪音
说实话，我见过太多安全团队把 Splunk ES 当成一个“告警制造机”。配了一堆规则，结果每天几千条告警，真正能用的没几条。我去年接手一个客户的 SOC，他们 ES 上有 200 多条 Correlation Search，但平均每天有 70% 的告警是误报。这玩意儿不是越多越好。
今天我想聊聊我们团队在配置 Splunk 关联规则时的一些真实经验。不是那种官方文档的复读，而是你真正会遇到的坑和解决方案。
第一步：搞清楚你的数据源
很多人的第一步就错了。他们直接冲进 Content Management 开始写规则，完全不考虑数据质量。
我一般先问三个问题：
- 你的日志源覆盖了哪些 MITRE ATT&CK 战术？
- 日志时间戳是否准确？（这个能坑死你）
- 字段提取有没有做好？
实战：检查数据源
从 Splunk Enterprise 菜单栏选 Settings > Data inputs > Intelligence Downloads，然后过滤 mitre。这里你会看到 MITRE 的威胁情报更新。如果你连这个都没配，那你的规则基本是盲打。
我们团队的做法是：先跑一个 | datamodel 命令，看看 CIM 兼容性。如果数据模型都过不了，后面的规则就是白费劲。
第二步：创建你的第一个关联规则
好了，假设你的数据质量没问题。现在我们从 Splunk ES 菜单栏进 Configure > Content > Content Management。过滤 Type 为 Correlation Search。
一个真实的例子：检测暴力破解
我们当时需要检测 SSH 暴力破解。规则长这样：
index=linux_secure sourcetype=linux_secure "Failed password"
| bucket span=5m _time
| stats count by src_ip, dest_ip, _time
| where count > 10
| eval severity = if(count > 50, "critical", "high")
| `notable`
看着简单是吧？但这里有个坑：bucket span=5m 这个参数。如果你的日志量很大，5 分钟窗口可能产生大量假阳性。我们后来改成 span=10m，并且加了一个 lookup 来排除内部跳板机。
规则配置的细节
在 Content Management 里，你需要设置：
- Cron Schedule：我们一般用
*/5 * * * *，但如果是高频率规则，建议用实时搜索（Real-time） - Throttling：这个非常关键。不设限的话，一个攻击源能刷出几百条告警。我们通常按
src_ip在 1 小时内只告警一次 - Risk Score：别设太高也别设太低。我们内部有个标准：低危 20，中危 50，高危 80，严重 100
第三步：规则调优——这才是真正的技术活
误报处理
这是我最头疼的部分。去年有个规则检测到“DNS 隧道”，结果发现是某个开发团队在用 dig 做测试。我们花了三天才定位到。
我的建议是：永远不要直接删除规则，而是加例外条件。
比如：
index=dns sourcetype=dns
| search query_type=TXT AND query_length>500
| where NOT (src_ip IN [subsearch: index=asset_lookup | search category=dev_server | fields ip])
| `notable`
这样既保留了检测能力，又避免了误报。
性能优化
说实话，Splunk 的关联搜索性能是个大问题。我们有个规则跑在 100GB/天的数据上，结果把搜索头搞崩了。
几个优化点：
- 用
tstats代替stats：如果你用的是数据模型，tstats比stats快 10 倍以上 - 提前过滤：把
index=和sourcetype=写在最前面 - 避免子搜索：子搜索在数据量大时就是灾难
| 优化手段 | 性能提升 | 适用场景 |
|---|---|---|
| 使用 tstats | 10-20x | 数据模型已就绪 |
| 提前过滤 | 3-5x | 所有场景 |
| 避免子搜索 | 2-3x | 中等数据量 |
| 使用 summary index | 5-10x | 历史数据回溯 |
第四步：与 MITRE ATT&CK 对齐
这个很多人忽略。在 Content Management 里，每个 Correlation Search 都可以关联 MITRE 战术和技术。
我们团队的做法是：每个规则至少对应一个 MITRE 技术。这样当告警产生时，分析师能立刻知道攻击者在做什么。
比如我们的“横向移动检测”规则关联了 TA0008（横向移动）和 T1021（远程服务）。
第五步：告警响应自动化
规则配好了，告警也出来了。然后呢？
我们接入了 SOAR 平台。当规则触发时：
- 自动创建告警工单
- 提取关键字段（src_ip, dest_ip, user）
- 自动查询威胁情报
- 如果是高危，直接通知值班人员
这里有个小技巧：在规则里用 notable 命令时，可以自定义告警的 urgency 和 owner。
| `notable` urgency=high owner=soc_team
常见陷阱
时间窗口陷阱
我见过有人把时间窗口设成 earliest=-30d，结果规则跑了 3 小时还没出结果。关联规则的时间窗口不要超过 1 小时，除非你有特殊需求。
字段提取陷阱
eval 命令里用了不存在的字段，规则静默失败。我建议在规则末尾加一行 | fields + src_ip, dest_ip, user, action 来确保关键字段存在。
重复告警陷阱
没有配置 Throttling，结果一个攻击刷了 500 条告警。Throttling 是必须的。
FAQ
Q: Splunk 关联规则和普通告警有什么区别？
A: 关联规则是跨事件、跨数据源的逻辑组合。普通告警基于单一事件。比如“5 分钟内 10 次登录失败”是关联规则，而“一次登录失败”是普通告警。
Q: 如何测试新规则？
A: 先用 | stats 在搜索里验证逻辑，确认没问题后再部署到 Content Management。我们团队有个测试环境，所有规则先在测试环境跑 24 小时。
Q: 规则太多影响性能怎么办？
A: 优先使用 tstats，减少子搜索，使用 summary index。另外，定期清理不再需要的规则。
总结
配置 Splunk 关联规则不是一蹴而就的事。你得先搞数据，再写规则，然后调优，最后自动化。这个流程走下来，少说也得两个月。
但回报是值得的。我们团队通过这套方法，把误报率从 70% 降到了 15%，告警处理时间从平均 45 分钟降到了 8 分钟。
记住：好的规则不是写出来的，是调出来的。