\"告警疲劳\"--报警报得太多太假，人的神经早就麻了。

原创

snortman
snortman

网络安全攻防与治理

2026年10月21日 21:45
安徽

去阅读

如果你在安全团队待过，下面这个场景多半不陌生：

凌晨1点，值班手机又震了。你摸黑爬起来，屏幕上弹出一整屏告警：扫描试探、端口探测、账号锁定、设备例行检查…… 九成都是 \"熟悉的陌生人\"。你一条条点开、确认、关闭，等真正出事的那条出现时，你已经彻底被淹没在里面，根本没看见。这一天，基本就废了。

安全圈管这种感觉叫 \"告警疲劳\"，报警报得太多太假，人的神经早就麻了。

一组行业数据挺扎心：一家中型企业的安全运营中心，平均每天收到约 4484 条告警，其中 44% 因为太多太累，从头到尾没人看过；看过的那些里，又有约 68% 最后被判定为 \"虚惊一场\"。

这种状态持续久了，人会垮。业内调研里，因为 \"天天盯误报\" 而倦怠、甚至离职的安全分析师，不在少数。而告警疲劳的直接代价，是真实的漏报 ，真攻击混在误报堆里，等被发现时，损失已经造成了。

怎么办？今天想聊聊 告警降噪。

1、告警为什么会泛滥

先看一条信息逐层衰减的链条：

原始日志 ->安全事件 ->真实威胁 ->人工能处理的量

就像一座金矿，挖出来几吨矿石，筛到最后只剩几克金子；安全分析师要做的，恰恰是从海量矿石里找出那几克。

有家企业，单日告警量高达 5000多条，专职安全运维 5 个人，所有人从早忙到晚也只能最多大约 250 条，处置率不足5%。

另一组数字是：一名一线分析师，一个班次的极限处理能力大约只有 40 到 60 条；大型企业的安全中心，一天能冒出几 万条告警。

这不是人手不够的问题，而是 \"警报太多\" 这件事本身，就把人淹死了。你再怎么加班加点，产出也上不去 —— 瓶颈不在人，在噪音。

告警降噪要解决的，不是 \"怎么发现威胁\"，而是 \"怎么把真正值得看的捞出来\"。

一句话：降噪就是帮团队省掉九成瞎忙，留着力气盯真正要紧的事。

2、降噪到底在干什么

降噪是在不漏掉真实威胁的前提下，把需要人看的告警数量大幅压下去，同时让留下的每一条，信息更有用。

像整理邮箱：不是把所有邮件删光，而是把垃圾邮件过滤掉、把相似的归到一起、把最重要的几封标红置顶，让你打开收件箱就知道先看哪个。

降噪三件事：

• 删掉没用的：明确无害的、重复上报的，去掉；
• 合并相似的：几十条同一类问题，折叠成一条；
• 把重要的排前面：让分析师先看最像真威胁的。

做得细一点，还能顺手给告警补上下文 —— 这台机器是干什么的、这个账号平时怎么用、这次登录是不是出差期间，让分析师一眼就知道该不该紧张。但要降噪不等于检测。底层检测本身不行的话，降噪做得再好，风险啥都没发现。

3、主流做法：从便宜到贵

业内常用的讨论，按成本从低到高可以排成五层。

第一层，规则过滤：门卫查名单

事先定好规则：这个 IP 是自家扫描器，放行；这种备份任务天天都有，不必惊动人类；同一个事件 60 秒内只报一次，别刷屏。

规则过滤就像小区门卫：认识的人、登记过的人，直接放行，省得每个人都拦下来盘问一遍。

优点：便宜、快、看得懂。缺点：死板 —— 攻击者只要稍微换个 \"马甲\"、换个端口特征，规则就抓瞎了。白名单还不能开太宽，宽了等于给攻击者发 \"免死金牌\"。

这里有个常见的坑：规则不是越多越好。规则库从 500 条加到 5000 条，误报往往不降反升 —— 新旧规则互相打架，反而制造新噪音。

第二层，模式归并：几百条变一条

原始日志千奇百怪，但很多其实是一个模子刻出来的，只是时间、IP、数字在变。

比如几百条 \"磁盘使用率 87%、88%、89%……\"，本质上都是 \"磁盘快满了\" 这一件事。归并就是把它们抽象成一条模板，折叠计数，让 \"几百条\" 变成 \"一条 + 计数\"。

这一层是整个体系的 \"地基\"：成本极低，却常常能压掉六七成的日志量。有个关键提醒：没打地基就急着上大模型，是把最贵的工具用在了最便宜的活上。

第三层，聚类压缩：按时间窗打包

短时间内同一类告警疯狂刷屏（比如扫描、爆破），把它们按时间窗合并成一条带计数的记录：\"5 分钟内同一来源触发 300 次\"。

注意：合并时必须保留首尾时间和次数。攻击的典型特征就是 \"短时间高频触发\"，你要是把计数抹掉了，反而把最有价值的线索给扔了。

第四层，关联分析：把碎片拼成故事

单看一条日志，可能都是 \"正常操作\"：有人打开了钓鱼附件、有人执行了一段脚本、有人试着连了内网共享……

但把这些碎片按时间、按 IP、按账号串起来，就是一条完整的攻击链。就像侦探破案：单个证据都不起眼，连起来就是犯罪过程。

一个小例子：单看一条 \"执行 whoami\"（查看当前用户名），毫无意义，运维天天干；但当它出现在 \"钓鱼文档 → 执行脚本 → 查看身份 → 内网探测\" 这条链上时，它就是决定性证据。

这一层不减少数量，但能把信息的 \"密度\" 拉满 —— 这是其他方法做不到的。

第五层，机器学习与大模型：最后的大招

前几层靠 \"形式\" 干活，大模型能读懂 \"含义\"：它知道一段 Base64 编码解出来是下载执行命令，知道某个漏洞编号意味着什么风险，是把安全专家脑子里的知识，搬进了模型参数里。

主流方案叫 \"快慢模型级联\"：便宜的小模型先处理 75%–85% 的 \"一眼能定\" 的告警，剩下模糊的少数，才交给更贵的推理模型慢慢分析。既省钱，又够快。

但用大模型有三条红线：一是攻击者可能往日志里塞恶意指令（安全圈叫提示注入），所以模型绝不能直接动手处置；二是模型可能一本正经地编瞎话（叫幻觉），结论必须能追溯到原始日志；三是每条日志都调大模型，成本会爆炸，必须先用前几层把量压下来。

4、通用大模型和安全大模型，怎么挑？

聊到大模型，还有个绕不开的问题：到底用 \"什么都会一点\" 的通用大模型，还是用专门训练过的安全大模型？

这两者不是谁更聪明，而是分工不一样。通用模型博而不专，安全模型专而不博，各管一段。六个方面对照下来，差别很清楚：

① 模型定位

• 通用大模型：什么都懂一点，安全知识 \"稀释\" 在通用知识里，密度低；
• 安全大模型：用漏洞库、攻击手法、威胁情报、真实日志专门训练，知识密度高，也更 \"专\"。

② 适用场景

• 通用大模型：适合 \"难啃的少数\" —— 看不懂的长尾日志、开放式分析、写研判报告；
• 安全大模型：适合 \"量大的日常\" —— 批量研判告警、识别常见攻击手法、直接给处置建议。

③ 能力边界

• 通用大模型：冷门漏洞容易认错，复杂多步的攻击链推理容易断；
• 安全大模型：能认出冷门漏洞、稳定对应攻击手法编号、多步推理更连贯；但知识会随攻防框架更新而 \"过期\"，需要持续维护。

④ 安全策略

• 通用大模型：多为云端 API，日志送出去就 \"出域\" 了，防提示注入主要靠服务商；
• 安全大模型：可本地私有化部署，配合 \"确定性策略闸门\" —— 模型只提议、规则来执行，处置权限始终在自己手里。

⑤ 数据与隐私要求

• 通用大模型：走云端 API 时，内网拓扑、账号名、业务参数都可能跟着日志 \"出域\"，政企和关键行业往往一票否决；
• 安全大模型：支持私有化、数据不出域、全程留痕可审计，天然贴合等保和关基要求。

⑥ 响应风格

• 通用大模型：回答全面、解释性强，但有时 \"论文腔\"，适合开放式探讨；
• 安全大模型：回答更像 \"工单\" —— 直接给结论、证据链和处置建议，贴合一线分析师 \"看完就动手\" 的节奏。

到底怎么选？

• 小型团队、预算有限：先用开源的通用模型做零样本初筛（不训练、拿来直接用），别急着花钱微调；
• 有专职工程师、能接受私有化：选安全垂域小模型（8B 级别，一张显卡就能跑），轻量微调 + 本地知识库增强；
• 政企、关键信息基础设施、数据敏感单位：数据不出域是硬底线，直接本地化部署安全大模型 + 确定性闸门；

5、先从哪儿动手

想动手的团队，先做便宜且见效快的，最后才上贵的。

大致四步：

1. 先把数据规整好：日志采集齐全、字段统一、时间同步；
2. 然后上 \"地基\"：日志归并 + 去重聚合 + 白名单过滤，这一步通常就能压掉大部分量；
3. 再上关联规则，把攻击链拼出来；
4. 最后才引入大模型做智能研判。

最后，容易踩的几个坑

• 只报降噪率，不报漏报率 —— 这等于只报喜不报忧。两个数必须一起看，单看一个都是耍流氓。
• 白名单开太宽 —— 等于给攻击者发 \"免死金牌\"。要定期复核、设有效期，离职账号及时清理。
• 为了合并丢掉细节 —— 聚合时一定要保留时间和次数，否则攻击节奏就被抹平了。
• 让 AI 直接处置 —— 模型只做 \"提议\"，动手执行必须由规则和人来把关。真出了事，还得能说清是谁、依据什么做的决定。
• 一上来就上大模型 —— 先做便宜的事，再谈智能；否则成本失控，效果还不一定好。