4. 检测数据源盘点

检测工程的第一性原理是：没有数据，就没有检测。在写任何一条检测规则之前，必须先回答三个问题——这条规则依赖哪些日志源？这些日志从哪里采集、以什么方式进入分析平台？日志里的关键字段是否真的存在、语义是否可靠、延迟是否可接受？本章围绕终端、网络、身份、云、应用五类常见日志源，讲清采集方式、字段语义与可用性评估方法。

一、五类日志源的采集方式

终端日志主要来自操作系统与安全代理。Windows 侧核心是 Sysmon 与安全审计日志（Security 通道），Sysmon 通过驱动挂接内核回调，采集进程创建（Event ID 1）、网络连接（3）、文件创建（11）、注册表修改（12/13/14）、驱动加载（6）等事件；Linux 侧依赖 auditd、eBPF（如 Tetragon、Falco）与 syslog。采集方式通常是代理（Agent）本地读取事件通道后转发，或通过 Windows Event Forwarding（WEF）汇聚到收集器。

网络日志包括防火墙会话日志、IDS/IPS 告警、DNS 查询日志、代理（Proxy）访问日志、NetFlow/IPFIX 流记录。采集方式分两类：一是设备主动推送 syslog 到收集器；二是通过流量镜像（SPAN）或 TAP 交给 Zeek/Suricata 解析生成结构化日志。NetFlow 只记录五元组与字节数，不含载荷，适合做流量基线与横向移动发现，但不能替代全包分析。

身份日志来自域控、IdP 与 SSO。Active Directory 的关键事件是 4624（登录成功）、4625（登录失败）、4768/4769（Kerberos TGT/ST 请求）、4720（账户创建）；云身份侧对应 Azure AD / Entra ID 的 Sign-in logs 与 Audit logs，Okta 的 System Log。采集方式多为 API 拉取（如 Microsoft Graph、Okta API）或事件订阅推送。

云日志以控制面审计为主：AWS CloudTrail、Azure Activity Log、GCP Cloud Audit Logs 记录谁在何时对哪个资源做了什么 API 调用。数据面日志如 VPC Flow Logs、S3 访问日志、WAF 日志则反映实际流量与访问行为。采集通常通过云原生投递（CloudTrail → S3 → SQS → 采集器）或事件总线（EventBridge）实现。

应用日志来自 Web 服务器、业务系统与中间件，格式最不统一，可能是 Nginx access log、JSON 结构化日志或自定义文本。采集方式包括 Filebeat/Fluent Bit 读文件、应用直接写 Kafka，或 OpenTelemetry Collector 统一接收。

二、字段语义：同名不同义是最大陷阱

字段语义决定了检测规则能否跨源关联。以“用户”为例：终端 Sysmon 的 User 字段是进程运行账户，格式为 DOMAIN\user；AD 4624 的 TargetUserName 是被登录账户，而 SubjectUserName 是发起登录的账户；CloudTrail 的 userIdentity.arn 是 IAM 主体 ARN，可能是角色而非具体人。如果规则里直接拿这些字段做等值关联，很可能匹配不上或误匹配。

再以“IP”为例：网络日志的 src_ip 是连接发起方，身份日志的 IpAddress 是登录来源，云日志的 sourceIPAddress 可能是 NAT 后的出口 IP，也可能是 AWS 服务自身的 IP。做“同一 IP 先登录失败后横向扫描”这类关联时，必须确认各源 IP 的语义边界，并考虑 NAT 与代理带来的失真。

工程上的做法是建立字段映射字典：把各源字段统一映射到 ECS（Elastic Common Schema）或 OCSF（Open Cybersecurity Schema Framework）的规范字段，例如统一为 user.name、source.ip、process.command_line、event.action。映射时保留原始字段，便于回溯与排障。

三、可用性评估：五个维度与量化方法

可用性评估不是“有日志就行”，而是回答“这条检测规则能不能稳定跑起来”。建议从五个维度量化：

• 覆盖度：目标资产/账号中，实际产生日志的比例。例如 500 台终端中 470 台上报 Sysmon，覆盖度 94%。
• 完整性：关键字段的非空率与截断率。例如 CommandLine 非空率 99.2%，但超过 8192 字符被截断的比例约 0.3%。
• 时效性：事件发生到可查询的端到端延迟。终端 Agent 通常 5～30 秒，云审计 API 拉取可能 2～15 分钟。
• 保真度：是否采样、是否丢包。NetFlow 常按 1:1000 采样，DNS 日志可能只记录应答不记录查询。
• 成本：存储与许可。全量包捕获成本极高，通常只保留元数据。

实操中可以用一段查询快速评估。例如在 Elastic 中统计某日志源近 24 小时的字段非空率：

GET logs-*/_search
{
  "size": 0,
  "query": { "range": { "@timestamp": { "gte": "now-24h" } } },
  "aggs": {
    "total": { "value_count": { "field": "_id" } },
    "has_cmdline": { "filter": { "exists": { "field": "process.command_line" } } },
    "has_user": { "filter": { "exists": { "field": "user.name" } } }
  }
}

若 has_cmdline.doc_count / total.value 低于 0.95，说明该字段不可靠，依赖它的规则需要降级或补充其他数据源。类似地，可以按 host.name 聚合统计覆盖度，找出未上报的资产。

四、盘点成果：数据源清单

盘点的最终交付物是一份可维护的数据源清单，至少包含以下字段。下表为示例，数值为合理假设，用于说明填写方式：

完成本章盘点后，你应当能够为每一条待实现的检测规则标注其依赖的数据源、关键字段与可用性等级，并据此判断该规则是“可立即上线”“需补充数据源”还是“当前不可实现”。这份清单也是后续检测规则工程化、调优与复盘的基线。