3. 安全数据源接入与规范化

安全运营的检测能力，最终取决于数据是否被正确接入、解析并映射到统一语义。Splunk 的检测工程实践中，这一步通常被称为“数据接入与规范化”。如果原始日志只是被采集进来却未做字段提取和 CIM（Common Information Model，通用信息模型）映射，那么搜索、关联分析和检测规则都会变得脆弱：同一类事件在不同数据源中字段名不同，检测逻辑无法复用，仪表盘也无法统一呈现。本节围绕五类最常见的数据源——Windows 事件、防火墙、EDR、云审计和代理日志——说明接入方法、字段提取思路以及 CIM 映射的关键做法。

一、接入前先明确三件事

在动手配置输入之前，先回答三个问题，能避免后续大量返工。第一，数据以什么方式到达 Splunk？常见有 Universal Forwarder 转发文件、Syslog 接收、API 拉取（如云审计、EDR）以及 HEC（HTTP Event Collector）推送。第二，事件的时间戳来自哪里？应优先使用日志自带时间，而不是采集时间，否则回溯分析会出现时间错位。第三，数据属于哪个 CIM 数据模型？例如 Windows 登录事件对应 Authentication，防火墙流量对应 Network Traffic，代理日志对应 Web，云审计对应 Change 或 Authentication。明确这三点后，接入、解析、映射才有清晰目标。

二、五类数据源的接入要点

Windows 事件日志：通常通过 Universal Forwarder 采集，在 inputs.conf 中启用 WinEventLog，并指定需要的主机与事件通道。安全运营最关注安全通道中的登录、进程创建、账户变更等事件。接入后应确认 EventCode、Account_Name、ComputerName 等字段可被正确识别。

防火墙日志：多数设备以 Syslog 输出，可让 Splunk 监听 UDP/TCP 514 或通过转发器读取日志文件。防火墙日志字段多、格式差异大，建议在 props.conf 中为每个厂商/型号定义独立的 sourcetype，再配合 transforms.conf 做正则提取。

EDR 日志：通常通过厂商 API 或 HEC 推送。EDR 事件包含进程树、命令行、文件哈希、网络连接等丰富上下文，是端点检测的核心。接入时要关注事件类型字段（如 process_start、network_connect）和进程唯一标识，便于后续关联。

云审计日志：以 AWS CloudTrail、Azure Activity、GCP Audit Log 为代表，一般通过云厂商的 Splunk 官方 Add-on 或 SQS/S3 拉取。云审计事件的关键字段包括 userIdentity、eventName、sourceIPAddress、requestParameters，映射到 CIM 后可用于检测权限变更和异常 API 调用。

代理日志：Web 代理记录用户访问的 URL、域名、HTTP 方法、状态码和流量大小，是发现恶意下载、C2 通信和异常外联的重要来源。代理日志通常为文本或 JSON，接入后应重点提取 url、dest、http_method、status_code 等字段。

三、字段提取的常用手段

Splunk 的字段提取主要发生在索引时和搜索时。索引时提取通过 props.conf 与 transforms.conf 完成，适合高频、结构稳定的日志；搜索时提取则用 spath、rex、kv 等命令，适合临时分析或结构不固定的数据。对于 JSON 格式的 EDR 和云审计日志，优先使用 KV_MODE = json 或 spath，让 Splunk 自动展开嵌套字段；对于防火墙和代理这类半结构化文本，通常需要编写正则表达式。

一个实用的做法是先在搜索界面用 rex 验证正则，确认能稳定命中后再写入 transforms.conf。例如从代理日志中提取 URL 和状态码，可先用如下方式验证：

index=proxy sourcetype=bluecoat:proxysg
| rex field=_raw "^\S+\s+\S+\s+(?<src>\S+)\s+\S+\s+\S+\s+\S+\s+\S+\s+(?<http_method>\S+)\s+(?<url>\S+)\s+\S+\s+(?<status>\d{3})"
| table src http_method url status

验证通过后，把正则写入 transforms.conf 的 REGEX，并在 props.conf 中通过 TRANSFORMS 引用。注意正则要尽量锚定字段边界，避免误匹配；同时为每个 sourcetype 单独维护提取规则，不要用一条正则覆盖所有厂商。

四、CIM 映射的核心思路

CIM 的价值在于把不同来源的字段统一成标准名称。例如 Windows 的 Account_Name、云审计的 userIdentity、EDR 的 user，最终都应映射到 CIM 的 user 字段；防火墙的 src_ip、代理的 client_ip 都应映射到 src。映射方式主要有三种：一是通过 fieldalias 做字段别名，二是通过 tag 给事件打标签，三是通过 eventtype 定义可复用的搜索片段。

以 Windows 登录事件为例，若要让其符合 Authentication 模型，需要确保事件包含 user、src、action、signature 等字段，并打上 authentication 标签。这样后续写检测规则时，就可以直接使用 tag=authentication action=failure，而不必关心底层是 Windows 还是云审计。映射完成后，建议用 datamodel 命令验证：| datamodel Authentication Authentication search | head 10，如果能正常返回事件，说明映射基本生效。

五、接入质量的检查要点

数据接入完成后，至少检查四项：时间戳是否正确、字段是否可搜索、sourcetype 是否合理、CIM 映射是否生效。可以用如下搜索快速判断字段提取情况：

index=* sourcetype=your_sourcetype
| fieldsummary
| table field count distinct_count

如果关键字段缺失或大量为空，说明提取规则需要调整。对于云审计和 EDR，还要关注事件延迟和 API 限流，避免因拉取频率过高导致数据缺口。代理日志则要注意 URL 字段是否被截断或编码，必要时先做 urldecode 再映射。

总体而言，安全数据源接入与规范化是一条从“原始日志”到“可检测语义”的链路：接入决定数据是否完整，提取决定字段是否可用，CIM 映射决定检测逻辑能否复用。三者缺一不可，而 CIM 映射往往是区分“能搜到”和“能检测”的关键一步。