灵敏度与阈值
部分检测规则带触发阈值或灵敏度参数：在多长的时间窗口内命中多少次才告警。阈值过低容易误报——内网扫描器、企业自检、业务系统的批量请求都会触发；阈值过高又会漏报。调整依据应该是自己网络里的实际流量数据，而不是感觉。
基线怎么建
常见做法是让新规则先以告警模式运行一到两周，统计每条规则在正常业务下的触发次数与来源分布，据此决定是放宽阈值、增加例外还是保持默认；同时把未调整前的数据留档，便于判断调整前后检测能力是否发生了变化。
基本信息
| 典型参数 | 触发次数、时间窗口、统计阈值 |
|---|---|
| 基线方法 | 统计正常业务在新规则下的触发情况与来源分布 |
| 默认策略 | 上线初期保持默认，收集一到两周数据后再调 |
| 留痕要求 | 记录规则号、原值、新值、原因与日期 |
典型使用场景
- 扫描探测类规则被例行自检反复触发
- 暴力破解类规则需要区分堡垒机与自动化脚本
- 上线一批新规则后误报集中出现
- 业务流量结构变化后重新校准阈值
- 交接班时需要说明参数为什么设成这样
- 漏报案例复盘时回头检查阈值是否过松
调整思路示例
调整思路示例
# 扫描探测类规则：阈值适当放宽，避免正常扫描器与企业自检误报
# 暴力破解类规则：阈值偏低更敏感，但要排除堡垒机与自动化脚本
# 默认参数：上线初期保持默认，收集一到两周数据后再动
# 每次调整都记录：规则号、原值、新值、原因、日期
# 调整后用同一批流量回放验证，确认误报确实消失调整方向与代价
| 调整方向 | 收益 | 代价 |
|---|---|---|
| 阈值放宽 | 误报减少，值班负担下降 | 漏报风险上升，需评估攻击面 |
| 阈值收紧 | 敏感度提高，攻击更容易被发现 | 误报增加，真实告警可能被淹没 |
| 保持默认 | 沿用厂商标定的基线 | 可能不适配本网业务特征 |
阈值调整不是一次性工作：业务变化、系统升级、新业务上线后都需要重新校准，把复核写进例行巡检。
为消除误报把阈值调得过于宽松，检测能力随之下降，实际效果接近于把这条规则关掉。
调整前后各留一段数据：只记录调整动作而不记录效果，几个月后没人能判断当时的改动是否正确。