基于LLM的AISecOps实践案例2

  Leader又发话了 

Once again,  高瞻远瞩，英明的Leader，他在群里发话了。

安全机器人接收到用户输入后

LLM Intention节点分析了PDF内容，发现它是一个漏洞情报。随后，它输出了一个简单漏洞总结，并转交给下游Planner节点开始处理。这里最重要的信息自然是提取了CVE ID，以及漏洞影响范围。有了这些信息，足够Planner规划和执行任务了。

  Planner任务规划 

Planner接到信息，通过LLM生成任务如下：

它创建了一个查询需求，让EDR Agent查出哪些设备安装了Cursor，它比较谨慎，查询的是名称中包含Cursor的软件。

在我们的系统提示词中，LLM仅知道，当前存在几十个同事能够配合它的安全运营工作。看一个提示词例子

DNS:  该Agent能够查询最近收集的DNS日志记录，包括终端设备/虚机/容器等

• 内部设备的DNS 请求记录，记录了设备曾访问哪些网站

总之，要请求谁帮忙解决子问题，是LLM自己决策的。我们并没有提前设计Workflow。

  Planner的不足 

LLM的任务是否完美了？肯定差得远。 

如果EDR路径没有返回结果、查询异常了怎么办？Agent 是否具备RePlan的能力。假设，上面EDR根本没查出来，事情就结束了吗？ 并没有。如果它足够智能，就应该，比如，试图找出一个低版本Cursor的特征服务域名，尝试利用DNS日志去定位哪些设备疑似安装使用Cursor了。

但，这毕竟是运营的思路。 

你必须首先，教会它这样思考。

通常，这类深度推理的解法，由所谓提示词技术中的【思维树】解决。

  EDR处理查询任务 

这个环节没有多少亮点，如果非要说有。

那么让我澄清，因为某些原因，我们是利用Browser Use方式查询软件的。

第二，所有的Agent均只接受自然语言任务，并非MCP/tool call

请帮我查询所有安装的软件名称中包含Cursor的软件列表，包括软件名称（software_name），软件发布者（software_publisher），主机名（host_name），公网IP（public_ip），主机IP（host_ip），用户名（user_name），软件版本（software_version）等字段

这将帮助我确定内部使用的Cursor版本，并识别可能受到漏洞影响的机器。

上面就是EDR Agent收到和处理的原始消息。它处理完消息，把查到的数据原样返回即可。进度输出如下：

  版本匹配任务到底谁负责 

Agent之间，容易出现分工重叠。比如EDR查询就出现了，你可以选择：

1. 让EDR分析，找出version < 1.3的 Cursor软件 

2. 让EDR找出所有的Cursor软件，再让Planner分析过滤出版本小于1.3的

这取决于你，因为version < 1.3这个版本对比任务，对人是简单的。但对大模型来说，并不轻松，是容易出现错误判断的。笔者建议谨慎分工。

笔者将版本过滤统一交给Planner了，EDR不管分析，它只负责查。

这样做有利于单体Agent简化。 

我想说，我的一个负责处理具体任务的Agent，就只有100行代码规模。

  结果简单处理 

LLM对EDR查出的软件数据进行分析，挑选出了存在低版本的设备和人。如下图所示：

结果太长，只截取前面的几个。列表看起来可读性差，让其转换表格，如下图

  LLM做了哪些事情 

以上，便是我要介绍的LLM安全运营的例子。笔者的目标，是但凡英明的Leader群里at Bot，Bot应该圆满地交付答案和结果。总结如下：

• Intention: 解读PDF，提取出情报，总结情报，并下发自然语言任务

• Planner: 根据任务，规划协同任务，指派给EDR处理查询

• EDR Agent：理解查询请求，返回查询结果

• Planner：分析EDR给出的数据，匹配恰当的版本范围，捞出存在漏洞的终端

• Planner: 简洁表格输出

我不需要你告诉我Leader说的都对。

这一点我已经知道，你需要的是，证明它。

安全运营的本质，容我总结于这句Prompt:

Don't tell me the leader is right, that much is a given, I need you to prove it.