1. Splunk安全运营与检测工程导论
在正式进入Splunk的查询语法、数据模型与检测规则编写之前，有必要先建立一张"全局地图"：安全运营中心（SOC）每天究竟在做什么，检测工程在其中扮演什么角色，而Splunk又为什么能成为这条链路的中枢。本章不涉及具体SPL命令，而是回答三个问题：SOC的工作流长什么样、检测工程的定义与边界在哪里、Splunk在安全运营中的定位与核心价值是什么。
一、SOC的工作流：从信号到闭环
SOC并不是"看告警的团队"，而是一条持续运转的处理流水线。典型的一级（L1）到三级（L3）分工背后，是一条稳定的数据与决策链路：
- 数据采集与归一化：把防火墙、EDR、Windows事件日志、云审计日志、身份认证日志等接入平台，统一时间戳、字段名与主机标识，形成可检索的原始事件层。
- 检测与告警生成：基于规则、关联分析、行为基线或威胁情报匹配，从海量事件中筛出"值得看"的少量告警。
- 分诊与调查（Triage）：L1判断告警真伪、影响范围与紧急程度，决定升级、关闭还是补充上下文。
- 深入分析与响应：L2/L3进行横向关联、时间线重建、取证与遏制，必要时联动SOAR或工单系统。
- 复盘与反馈：把误报、漏报、新TTP转化为检测规则的调整，回到第二步，形成闭环。
这条链路的关键矛盾是信噪比：原始事件量可能是每天数十亿条，而真正需要人工介入的告警可能只有几十条。检测工程的价值，正是把这条"漏斗"做得既不过宽（淹没分析师）也不过窄（漏掉攻击）。
二、检测工程的定义与边界
检测工程（Detection Engineering）是把"攻击者行为"翻译成"可被机器稳定识别的逻辑"的学科。它介于威胁情报、安全运营与数据工程之间，核心产出不是某一次告警，而是可维护、可测试、可版本化的检测规则集。
它与相邻概念的区别值得明确：
| 概念 | 关注点 | 典型产出 |
|---|---|---|
| 威胁情报 | 攻击者是谁、用什么TTP | IOC、TTP报告 |
| 检测工程 | 如何稳定识别这些TTP | 检测规则、测试用例 |
| 安全运营 | 告警来了怎么处置 | 调查结论、响应动作 |
| 数据工程 | 数据能否可靠到达 | 采集管道、字段规范 |
检测工程的工作对象通常包括：检测假设（"如果攻击者用PsExec横向移动，会留下什么痕迹"）、数据可用性验证（该痕迹是否已被采集）、逻辑实现（SPL或Sigma规则）、测试（用模拟数据验证命中与不命中）、部署与监控（规则是否在跑、是否产生告警）、以及生命周期管理（规则何时该退役）。
三、Splunk在安全运营中的定位与核心价值
Splunk在SOC中的定位可以概括为"数据中枢 + 检测执行引擎 + 调查工作台"三合一。它的核心价值不在于"能存日志"，而在于把分散、异构、格式不一的安全数据变成可关联、可检索、可复用的分析资产。
具体体现在四个层面：
- 统一检索层：无论数据来自防火墙、EDR还是云平台，进入Splunk后都可以用同一套SPL进行检索、统计与关联，分析师不需要切换多个控制台。
- 字段归一化（CIM）：通过通用信息模型把不同厂商的字段映射到统一名称（如src、dest、user、action），使一条检测逻辑可以跨数据源复用。
- 关联与基线能力：支持时间窗口关联、事务（transaction）、统计基线（如用eventstats计算某用户7天登录均值），从而识别"偏离正常"的行为，而不仅是匹配已知特征。
- 检测资产化：保存的搜索、关联规则、仪表板、ES用例库都可以版本化、复用和审计，使检测能力从"个人经验"变成"团队资产"。
举个具体例子说明Splunk如何支撑检测工程。假设要检测"同一账号在短时间内从多个地理位置登录"这一可疑行为。在Splunk中，检测逻辑大致是：先按user和src_ip聚合登录事件，统计每个账号在5分钟窗口内出现的不同地理区域数量，再筛选出数量超过阈值（例如3）的账号。这个过程中，CIM提供的Authentication数据模型保证了不同认证来源的字段一致，而SPL的stats与eventstats命令则完成了聚合与基线比较。检测工程师要做的，是确认数据模型已正确映射、阈值有依据、并且用历史数据回放验证误报率。
四、本课程的学习路径
基于以上定位，本课程将沿着"数据—检测—运营—工程化"的主线展开：先理解Splunk的数据接入与字段体系，再掌握SPL检索与统计，进而学习关联规则、数据模型与ES用例，最后进入检测规则的生命周期管理、测试与调优。每一章都会尽量落到可操作的对象、参数与判断依据上，而不是停留在概念复述。