📚 课程目录第3章日志源接入与规范化

3. 日志源接入与规范化

SIEM 关联规则的质量，首先取决于进入规则引擎的事件是否“干净、统一、可关联”。如果防火墙日志里的源 IP 叫 src_ip，EDR 里叫 source_address，AD 里叫 ClientIP，云审计里叫 sourceIPAddress，那么任何跨源关联都无从谈起。本节围绕四类最常见日志源——防火墙、EDR、AD、云审计——讲清从采集、解析、字段映射到规范化的完整落地方法。

一、四类日志源的采集方式与关键字段

不同日志源的采集通道和字段结构差异很大，接入前必须先明确“从哪里拿、拿什么、以什么频率拿”。

防火墙：通常通过 Syslog（UDP/TCP 514）或厂商 API 采集。以常见下一代防火墙流量日志为例，关键字段包括时间戳、动作（allow/deny）、源 IP、目的 IP、源端口、目的端口、协议、应用识别、规则名、字节数。这类日志量大，是网络层关联的主力。
EDR：多通过管理控制台 API 或事件转发器采集，格式常为 JSON。关键字段包括主机名、进程名、进程命令行、父进程、文件哈希、目标 IP/域名、检测名称、处置动作。EDR 提供的是终端行为视角，是“进程—网络”关联的关键。
AD（Active Directory）：通过 Windows 事件转发（WEF）或域控安全日志采集，典型事件包括 4624（登录成功）、4625（登录失败）、4768（Kerberos TGT 请求）、4720（创建用户）。关键字段是账户名、域、登录类型、源工作站、源 IP、登录结果。
云审计：通过云厂商的操作审计服务（如 CloudTrail 类服务）投递到对象存储或消息队列，再拉取解析。关键字段包括事件时间、事件名称、操作者身份、源 IP、请求参数、资源 ARN、结果状态。

采集阶段要特别关注三点：一是时间同步，所有源必须使用 NTP，否则跨源关联的时间窗会失真；二是采集断点续传与去重，避免重复事件触发重复告警；三是原始日志留存，规范化失败时可回溯重解析。

二、解析：从原始文本到结构化字段

解析的目标是把非结构化或半结构化的原始日志，转成键值对。以一条防火墙 Syslog 为例：

2024-06-11T08:23:41Z FW01 traffic: src=10.20.3.15 dst=203.0.113.77
sport=51422 dport=443 proto=TCP action=allow app=SSL rule=OUT-Web bytes=18432

解析时用正则或分隔符提取，得到 src=10.20.3.15、dport=443、action=allow 等键值。EDR 的 JSON 日志则直接按字段路径取值，例如 event.process.name、event.network.destination.ip。AD 日志需要从 Windows 事件 XML 中提取 EventID 与 EventData 下的数据项。云审计日志通常嵌套较深，需要按 userIdentity、sourceIPAddress、eventName 等路径展开。

解析阶段最常见的失败是字段缺失或类型错误，例如端口被解析成字符串、时间戳格式不统一。建议在解析后立即做一次字段存在性与类型校验，校验不通过的事件进入“隔离队列”而非直接丢弃。

三、字段映射与规范化：统一到同一套语义

字段映射是把各源字段名映射到 SIEM 的统一字段模型。规范化则是在映射基础上统一取值格式和语义。下面这张图展示了四类日志源从采集到统一事件模型的处理链与字段映射关系。

映射表建议以配置文件形式维护，每接入一个新源，只增加映射条目，不改动规则。例如：

mapping:
  firewall:
    src_ip: [src, source_ip, srcaddr]
    dst_ip: [dst, destination_ip, dstaddr]
    action: [action, disposition]
  edr:
    src_ip: [event.network.source.ip]
    host: [event.host.name]
    user: [event.user.name]
  ad:
    src_ip: [EventData.IpAddress]
    user: [EventData.TargetUserName]
    action: [EventData.Status]
  cloud_audit:
    src_ip: [sourceIPAddress]
    user: [userIdentity.userName]
    action: [eventName]

四、规范化中的典型陷阱与处理

规范化不是简单改名，而是统一语义。几个高频陷阱：

时间格式：防火墙用 ISO8601，AD 用 Windows FILETIME 或本地时间，云审计用带时区偏移的字符串。统一转为 UTC 的 ISO8601，并保留原始时间字段备查。
动作语义：防火墙的 allow/deny、EDR 的 blocked/allowed、AD 的 0x0/0xC000006D、云审计的 Success/Failure，必须映射到统一的 action 取值集合，否则关联条件无法跨源比较。
账户格式：AD 是 DOMAIN\user，云审计是 userName，EDR 可能是 user@domain。统一为小写 域\用户名 或纯用户名加独立域字段，避免同一账户被当成两个实体。
IP 表示：IPv4 与 IPv6、带端口与不带端口、整数与点分十进制混用。统一为点分十进制或标准 IPv6 文本，端口单独成字段。

规范化完成后，建议用“同一攻击场景跨源验证”来检验：例如一次外部扫描，防火墙记录 deny、EDR 记录进程外连、云审计记录异常 API 调用，三条事件应能在统一模型下按 src_ip、user、host 正确关联。若关联不上，优先检查时间、账户和 IP 三类字段的规范化是否一致。

五、可执行的接入检查清单

每接入一个日志源，按以下清单逐项确认，可显著降低后续规则调试成本：

检查项	确认内容	不通过的典型表现
采集连通性	源端持续发送，SIEM 端有事件到达	索引无数据或数据延迟超过 5 分钟
时间同步	源与 SIEM 均使用 NTP，偏差小于 1 秒	跨源关联时间窗错位
解析成功率	抽样 100 条，解析成功率达 99% 以上	大量事件进入隔离队列
关键字段完整	src_ip、user、host、action、event_time 非空率达标	关联条件命中率低
映射覆盖	该源所有用到的字段名均在映射表中	出现未映射字段导致语义丢失
规范化一致	与已有源在时间、动作、账户、IP 上格式一致	同一实体被拆成多个值
去重与留存	重复事件可识别，原始日志可回溯	重复告警或无法重解析

完成上述工作后，四类日志源就具备了进入关联规则引擎的基本条件。后续编写规则时，只需面向统一事件模型中的字段表达条件，而不必再关心每个源原始字段叫什么、格式如何。这正是“接入与规范化”作为 SIEM 关联规则工程第一步的价值所在。