对未来反入侵体系与产品的思考

0. 安全的本质

这里的安全是指狭义的反入侵，如基础安全、应用安全等，我认为是：

在预期的环境内，执行预期的逻辑

我们过去做的基线、加固、漏洞响应等是在服务于“预期的环境”，入侵检测等是在做部分的“非预期执行逻辑”的检测。

1. 如何重新定义“预期的逻辑”

过去主要的“非预期行为”的检测主要有几种：

• 基于已知的攻击手法和特征进行黑名单、行为检测，也有一些其他方式来提升准确度，如行为序列检测等；

• 通过传统机器学习、统计学的方式进行所谓的“自学习、自适应”的检测或异常检测。

在 AI 时代，我们也许可以从更源头来解决这个问题，当我们希望知道某个 Artifact 从 Linux Kernel 层看，正常业务逻辑下需要访问哪些路径？需要什么权限？需要访问哪些内部服务？从传统的 API 安全的角度，权限是如何定义的？敏感数据如何传递？从 DB Proxy 角度看，应该访问哪些表？哪些字段？对应权限是什么？

这些答案在过去也许需要长时间窗口的“学习”+人工确认，或者需要依赖某些内部流程，但是现在通过 AI 加持的代码扫描+读取 CI/CD 阶段配置文件就能确认了。

当 AI 时代，Agent 已经可以通过配置文件级别的方式回答你，某个版本的 Artifact 的“预期的逻辑”是什么的时候，也许“入侵检测”本身将不再是围绕着特征、异常的工作了。

2. 总有“非预期的预期内”

当然，上面的这些只能针对 Artifact 类，当服务器、云、应用本身的权限丢失后，攻击者带来的操作以及 Living-Off-The-Land 攻击如何识别呢？

我的答案是实时意图检测，我们最终还是需要让检测系统真正的理解一条 Telemetry Log 或者 Audit Log，因为入侵检测的本身就是希望真正的理解这条命令在做什么，并且可以实现高性能的、可稳定复现的（还记得在实习的时候在写 NIDS 策略实在不知道如何处理一些入侵场景的策略构建，会无奈的开玩笑说把 Gaba 你塞进盒子里去看吧）。

而这显然不可能寄希望于 Regex、统计学或者是 LLM 或者真的把安全工程师塞进盒子，看下下面的例子：

• grep 'password' 和 grep 'P4sswd'

• grep 'password' 和 grep 'password incorrect'

• grep 'password' 和 grep -v 'password'

Regex 和统计学都无法分准确识别其中微妙的差异，而 LLM 很难实现实时或者近实时的识别。

于是我在半年前实现了一个试验性的项目：https://github.com/EBWi11/SecEBL，一个小的微调后 Embedding 模型，可以实现单消费显卡下 5.3k/s 的针对 Linux Cmdline 或者 K8s Auditing 进行准确打标，给出诸如 read_system_config、search_credentials 这类标签，从而实现对操作的意图的解读，当然上面的三个 Case 都可以轻松且准确的识别出来。

我们也看到后来的 JEV 模型的威力。我相信实时意图检测会成为一个很有潜力的方向，在入侵检测、Agent 意图检测与围栏等多个方向都会有极大的价值。

3. 如何确保“预期的环境内”

上面两个部分回答了我认为的针对“预期行为”的定义和“非预期行为”的检测，我认为针对 Artifact 层面，如果他们的权限配置清单可以自动化生成+自动化测试通过，目前的运行环境是完全具备细粒度控制能力的，比如使用 Linux LSM（需要在一些高频 IO 下做一些优化）；而针对 API 级别的细粒度访问控制也是相当基础的 WAF 功能了。

当应用只能运行业务逻辑的时候，相当大一部分的攻击面和传统安全问题会被收敛掉，而 AI 可以帮助我们实现这一套零摩擦高准确的 Artifact 配置，那将会是理想状态，大部分的应用安全漏洞和依赖库的 0day 响应将不会在这么被动。

4. 中间状态会是怎样的？

我相信实现三点是非常困难的，会受制于一大堆现实情况的影响，比如标准化不健全、根本没有统一的 CI 流程、依赖混乱无法读到完整的代码、线上已经在跑的业务完全不知道源码在哪里、也没有成熟的 Sandbox 生态来实现现代的 MAC（Mandatory Access Control）等等，因此很长一段时间可能还是要在我们传统的入侵检测和响应体系基础上去增强，去提升检测准确度、提高响应效率等等。

在这个方向我觉得大家的思路是一致的，我举一些场景：

• 漏洞情报确认影响后，Agent 基于扫描器、主机安全资产等识别出受影响资产，然后登录到服务器进行进程、端口、具体配置确认，确认是否受影响，确认日志路径，再基于日志路径进行临时日志采集，构建一个临时的、针对该漏洞是否被利用的、实时的高准确检测体系，修复完成后自动进行关闭；

• 自动化渗透测试+自动化 Patch 生成+自动化入侵检测策略生成；

• 基于业务上下文的入侵检测策略编写（而不是千篇一律的通用策略）以及告警响应，实现自适应（这个词过去被过度营销太久了以至于大家可能已经不能理解这个词本来的含义了）；

• 等等，不赘述；

这部分在接下来一段时间会很重要，因为标准化、安全基础等问题会导致大部分公司相当长一段时间会更依赖后置的能力（风控等场景只能更持续的依赖）因此我这大半年也一直在研究以下几个方向：

• Data Agent：如何让 Agent 处理复杂、大量的数据，从而提取有价值业务数据？这里我目前的答案是现阶段已经不太需要单独考虑了，CLI+Python 足够了，反而是传统的流、离线数据的架构需要考虑和平衡；

• RL：如何从真实世界中不断持续学习来提升自己？这里我目前的实践是，通过大量模拟环境持续训练一个 FSM(Finite State Machine)+专业领域的 Handbook 后（比如某些库的内部依赖关系、一些 RFC 的细节等），再通过真实环境来不断优化这个 FSM 和 Handbook，我在今年 7 月的周末小项目：https://github.com/EBWi11/Gusion 就是这个思路的实验，最终实现了 Cybergym 平均每条 Poc 约 0.5 元人民币的超低成本和 87%的成绩；

• Agent Communication & Organization Protocol & Dynamic Group Scheduling，这部分是实践最少的，不过看了大量的论文，现阶段的结论是：Multi-Agent 未必会对任务结果有质的提升，但并行肯定是对任务效率是有提升的，我现在可能更倾向于当前类似 Claude Agent Teams + Reviewer Agent 的模式，然后更多的重点在结构化 Memory、FSM、FSM-RL、Evidence-Gated、Tools 自动化优化的设计上；

• 再次感叹工程化确实不再是问题了，如何设计架构、如何构建有效“循环”、如何拥有持续的从真实环境中验证的机会是现在最核心的部分。

这里忍不住插一句，我认为主机侧依然是最重要的阵地，没有之一，安全场景下大量的上下文、业务理解（在有授权的情况下你甚至可以拖下来逆向不是）、响应动作的执行、漏洞应急等都要落到主机侧，这里其实和当年可以覆盖容器安全的绝大多数场景一样。 哪怕在未来的 AI 时代，主机侧依然是最重要的上下文提取、响应的来源，某些团队所谓的为了聚焦 AI 安全而放弃主机侧安全产品的战略确实是不太能理解。

5. 最后

在 AI 时代，每天都在 “AI 马上要取代我了！” 和 “ AI 确实可以帮我们更快创造有价值” 间反复横跳和焦虑。

不过现在是想明白了，毋庸置疑未来 AI 当然是万能的，但至少现在我们设想的那个未来还没有来到，所以在现在这个阶段，还是需要我们来努力推动未来的实现。