智能威胁检测:用 AI 识别“规则看不见”的攻击

一、为什么规则不够：攻击者在用 AI 量产变种

规则检测（比如 Snort 规则、YARA 规则、WAF 特征）的逻辑是"命中已知特征就报警"。它快、准、可解释，至今仍是主力。但规则有个天生的死穴：它只能抓"见过的样子"。攻击者现在用 LLM 和脚本批量生成钓鱼邮件话术、变种恶意脚本、变形后的 Web 攻击载荷，一个攻击手法能在几小时内裂变出几百种外壳、内核不变。规则来不及写、写了也被绕过。这就是规则在 AI 时代最尴尬的地方——对手在量产变种，你在手工补特征，永远慢半拍。更现实的是，规则维护本身有成本：特征库越堆越大，误报和性能开销一起涨，安全运营团队被"特征疲劳"拖垮是常态。一个真实常见的场景：攻击者用 LLM 批量改写钓鱼邮件话术，每封邮件措辞、发件人仿冒方式都不同，基于关键字的规则基本失效；但这类邮件在发信频率、发信域名年龄、正文链接结构上的行为模式是稳定的，ML 模型反而能抓到。规则不是没用，是在"变种量产"面前天然吃力。

机器学习（ML）看的是行为模式而不是固定特征。举个例子：一条 SQL 注入攻击，外壳千变万化，但底层"把外部输入拼进查询并执行"的行为模式是稳定的。ML 模型可以从海量请求里学到"这条请求虽然长得陌生，但行为轮廓像注入"，从而抓到"合法但反常"的东西。这里要讲清"规则+ML 双轨"的分工：规则负责抓已知、抓得狠、可快速响应；ML 负责兜底未知、抓反常、给规则补盲。两者不是替代关系，是互补。很多团队一上来就想"用 AI 取代规则"，结果误报和漏报一起炸，反而把原本稳的防线拆了。工程上常见的组合是：Suricata、Snort 这类引擎抓已知特征，上面叠加一层 ML 异常打分（如 Elastic 的 ML 作业、Splunk MLTK、或自研的孤立森林模型），把规则放行的流量再筛一遍。Wazuh 这类轻量平台也自带一些基于阈值的异常检测，小团队可以先用起来验证价值，再决定是否投入自研模型。

工程上更务实的定位是：规则做第一道硬闸（已知恶意必拦），ML 做第二道软筛（把规则放过的反常流量挑出来给分析师），最后人工或自动化做确认。这样即便 ML 抽风，已知攻击也还在规则手里兜着。判断该不该上 ML，先看你的"未知威胁"占比高不高：如果业务面窄、攻击手法固定，规则够用就别硬上；如果资产暴露面广、对手会用自动化变种，ML 才值得投入。别为了"用 AI"而用 AI。

二、行为基线怎么做才不虚

行为基线（behavioral baseline），一句话解释：先搞清楚"这个人、这台机器、这个服务平时正常是怎么干的"，然后把"偏离正常"的当异常。它的好处是不依赖已知攻击特征，能抓没见过的攻击。但基线做不好，比没有还糟——误报能把分析师逼疯，最后大家干脆把告警全静音，真正的攻击反而埋在静音里。

最大的坑是"用一套全局基线套所有人"。一个运维半夜批量登录服务器在他那是正常的，对财务就是异常；工作日 9 点的流量曲线和凌晨 3 点根本不是一回事。所以基线必须分维度：分时段（工作日/周末、白天/夜间）、分角色（运维/开发/普通员工/服务账号）、分实体（每台主机、每个账号各自建模）。粒度越贴近业务，误报越少。这正好承接前面数据安全系列讲的"流动监测"思路——不是看单点事件，而是看"和平时比，这次流动正不正常"。还有一种实用的做法是同侪基线（peer-group baselining）：把职责相同的账号放一组互相比较，某个账号的行为明显偏离组内其他人就告警，比和全公司比更准。

基线冷启动：别一上来就全量告警

新基线头两周要先"学习"再"执法"。先只记录、不告警，等模型攒够正常样本、置信度上来了再开启告警，否则一开始的噪音能直接劝退团队。这段时间正好让业务方帮你标一批"这是正常新业务"。

基线要能解释"为什么异常"

一条告警至少要带"偏离了哪个维度、偏离多少"，否则分析师没法判断真假。可解释性是后面要专门讲的兜底前提，没有它就只能靠人肉翻日志，效率归零。

三、无监督发现未知威胁

无监督学习（unsupervised learning，不需要提前标好"这是攻击"就能跑的算法）适合干一件事：从没标签的数据里把"长得像的异常"自动归成一堆，帮分析师聚焦。两种常用打法：聚类（clustering）把行为相似的实体聚到一起，攻击者往往因为动作雷同而在聚类里扎成一簇，和正常用户明显分开；异常打分（anomaly scoring）给每个实体算一个"有多反常"的分，按分数从高到低排，分析师只看 Top N，不用翻全量。常用算法如孤立森林（Isolation Forest，越容易被"孤立"出来的点越可疑）、自编码器重建误差（正常样本重建误差小、异常样本误差大）都能当打分器。

但这里有两个工程上必踩的坑。第一是冷启动：模型刚上线没有历史，分出来的"异常"可能只是"新业务还没学进来"，前几周假阳性会很高，要有人工反馈把误判标回去，逐步把无监督发现的结果沉淀成有标签样本，反哺后面的监督模型。第二是概念漂移（concept drift）：业务一变，原来的"正常"就不正常了。比如公司上了新系统，全员行为模式整体迁移，旧基线全作废，模型如果不跟着迭代，告警要么全误报要么全沉默。所以 AI 检测模型不是"训一次管一辈子"，要随业务版本一起迭代、定期用新数据回训，最好对"基线漂移量"本身也做监控，漂移过大就自动降级并通知人工重训。

四、AI 检测的局限与兜底

必须坦诚：AI 检测会漏，也会被对抗样本骗。一个 ML 模型如果只靠少数几个特征判异常，攻击者针对性构造就能绕过；更麻烦的是模型本身不可解释时，你根本不知道它为什么报警、又为什么没报，出了事没法复盘，合规上也讲不过去。曾经有团队上了个黑盒异常检测，平时检出率报表很好看，结果一次真实入侵里模型压根没响，事后查才发现它学到的"正常"恰好被攻击者绕开了——而没人能说清模型到底看了什么。

所以兜底原则有三条。第一，检测结果必须可解释——能说清"因为哪几个行为偏离、偏离多少"才判异常，不能只给个黑盒分数。第二，检测结果必须可复核——留有完整的原始证据（日志、会话、进程链），事后能拉出来看。第三，高风险动作仍人工确认，不能全自动封。前面讲的"人在回路"红线在这里直接落地：AI 可以帮你把 1000 条告警压成 20 条值得看的，但"封账号、断网、删数据"这种一刀下去的动作，先把人请进来确认。这也是对误报的最后一道德防——模型再自信，也给人留个否决键。落到系统设计上，建议把"AI 判异常→人工确认→执行处置"做成标准工作流，AI 的输出只是工作流的一个输入节点，而不是决策终点；所有自动处置动作都记录"AI 给了什么信号、人确认了什么"，既能复盘也能满足审计。

五、落地清单：可直接照着做的检查项

1. 核心域先上行为基线，分时段分角色建模

先在高危资产（域控、核心数据库、出口网关）上建分时段、分角色的基线，必要时用同侪基线提升精度，别一上来铺全公司，避免误报淹没团队。

2. 检测模型保留规则冗余

ML 判异常的同时，传统规则、白名单仍在线交叉验证，避免单点模型被绕过或抽风导致全盘失守。

3. 告警可解释、可复核

每条 AI 告警带"偏离维度+原始证据"，高风险动作人工确认，不全自动封；模型误报要能回溯到具体特征。

4. 模型随业务版本迭代

把检测模型纳入版本管理，业务大变更后回训、重估概念漂移，对基线漂移量做监控，异常时自动降级并通知人工。

（本文为「AI 赋能安全 · 攻防对抗」系列之一，工程实践视角，约 4000 字。部分内容AI生成。）