4. 关联规则设计原则
关联规则工程中最常见的失败模式，不是规则写不出来，而是规则写出来之后没人敢用：告警太多被忽略，或者关键攻击被漏掉。要避免这种局面，规则设计必须从检测目标出发，而不是从日志字段出发。换句话说，先明确“我要发现什么行为”，再反推需要哪些数据源、哪些字段、什么时间窗口和什么阈值。
一、从检测目标出发：先定义行为，再定义规则
检测目标应当是可观察、可判定的行为描述，而不是模糊的安全愿望。例如“检测横向移动”过于宽泛，而“同一账户在 5 分钟内从两台不同主机发起 SMB 登录，且目标主机此前未出现过该账户”就是一个可落地的检测目标。它明确了主体（账户）、动作（SMB 登录）、对象（目标主机）、时间窗口（5 分钟）和基线条件（此前未出现）。
从检测目标到规则，需要经过一次“数据可行性”校验：所需字段是否被采集？字段是否稳定？时间戳精度是否足够？如果数据源缺失或字段为空率高，再好的检测目标也无法实现。因此规则设计的第一步不是打开规则编辑器，而是确认数据链路。
检测目标拆解示例：
- 行为：账户在短时间内从多台主机登录
- 数据源：Windows 安全日志 4624（登录成功）
- 关键字段：TargetUserName、IpAddress、WorkstationName、LogonType
- 时间窗口：5 分钟
- 阈值：不同 WorkstationName 数量 ≥ 2
- 排除条件：服务账户白名单、已知跳板机
二、误报与漏报权衡：没有零误报的规则
误报（False Positive）和漏报（False Negative）是一对天然矛盾。阈值收紧，误报下降但漏报上升；阈值放宽，漏报下降但误报上升。规则工程师的任务不是消灭误报，而是把误报控制在可运营的范围内，同时保证关键攻击路径不被漏掉。
权衡时可以参考三个维度：攻击危害、行为普遍性、数据可信度。危害高、行为罕见、数据可信的检测目标，可以接受较高误报；危害低、行为普遍、数据噪声大的目标，则应优先降噪或改为关联多个条件。
实际操作中，常用手段包括：增加关联条件（如登录成功 + 进程创建）、引入白名单（服务账户、扫描器、运维跳板）、设置合理的抑制窗口（同一实体 10 分钟内只告警一次）、以及分级告警（低置信度进入观察队列，高置信度直接告警）。
三、规则可维护性：让规则能被别人接手
规则不是一次性代码，而是长期运行的资产。可维护性差的表现包括：规则名称含义不明、阈值散落在多个地方、白名单硬编码在规则内部、没有版本记录、变更后无人知道影响范围。这些问题在人员流动或规则数量增长后会迅速放大。
提升可维护性的核心做法是“配置与逻辑分离”。把阈值、白名单、时间窗口、抑制周期等参数抽到外部配置或变量中，规则主体只保留关联逻辑。这样调整阈值不需要改规则结构，也便于批量管理和审计。
另一个关键点是规则分层。基础规则负责单事件过滤和字段标准化，关联规则负责多事件组合，告警规则负责分级和抑制。分层之后，每层职责单一，修改一层不会意外影响另一层。
四、命名规范与文档化：规则的可读接口
命名规范是规则的第一层文档。一个好的规则名称应当包含：检测目标、数据源、关键条件、严重级别。例如 WIN-SMB-LateralMove-MultiHost-Login-Medium，从名称就能看出平台、协议、行为、条件和级别。避免使用 rule_001、test_rule、new_rule_v2 这类无意义名称。
文档化不是写一篇长文，而是把规则的关键决策点记录下来。建议每条规则至少包含以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 规则ID | 全局唯一，便于引用和审计 | SIEM-CORR-0042 |
| 规则名称 | 包含目标、数据源、条件、级别 | WIN-SMB-LateralMove-MultiHost-Login-Medium |
| 检测目标 | 可判定的行为描述 | 同一账户5分钟内从≥2台主机发起SMB登录 |
| 数据源 | 日志类型和字段 | Windows 4624，TargetUserName/WorkstationName |
| 阈值与窗口 | 可调参数，不硬编码 | 不同主机数≥2，窗口300秒 |
| 白名单 | 排除已知合法行为 | 服务账户、跳板机、扫描器 |
| 误报评估 | 上线前观察结果 | 日均告警约12条，其中约3条需人工确认 |
| 变更记录 | 时间、原因、影响、回滚 | 2025-03-10 调整窗口从600s到300s，降低误报 |
| 负责人 | 规则维护责任人 | 安全运营组-张三 |
命名建议：采用“平台-协议/行为-条件-级别”的结构，全部使用英文大写和连字符，避免空格和中文。级别可用 Critical/High/Medium/Low 或 P1/P2/P3/P4，但全组织必须统一。
常见误区：把白名单直接写死在规则条件里。一旦需要新增排除项，就必须修改规则逻辑，容易引入新错误。正确做法是把白名单作为独立配置表或变量引用，规则只负责判断“是否在白名单中”。
五、一个可参考的规则设计检查清单
在规则上线前，可以用以下清单快速自检。它不是强制流程，但能有效减少低级错误：
- 检测目标是否可以用一句话描述清楚？
- 所需字段是否已确认采集且空值率可接受？
- 阈值和时间窗口是否外部可配？
- 白名单是否独立管理？
- 是否评估过误报量和漏报风险？
- 规则名称是否符合命名规范？
- 是否记录了变更原因和回滚方式？
- 是否有明确的负责人和复核人？
规则设计不是追求“一次写对”，而是建立可迭代、可审计、可交接的工程习惯。从检测目标出发保证方向正确，误报与漏报权衡保证运营可行，可维护性保证长期存活，命名规范与文档化保证团队协作顺畅。四者缺一不可，共同构成关联规则工程的基础。