用ChatGPT为Sentinel告警做摘要与分流

简而言之： 把事件本身导出来——标题、严重级别、涉及的实体和关联告警，而不是原始日志——让ChatGPT按"人应该先看哪一条"给未处理队列排序，每条附一段大白话说明和下一步该做的检查。这能把一个读不完的队列变成十分钟能读完的简报。但它绝不能自行关闭、隔离或判定任何事件为无害。

SIEM完全做到了你买它时想要的事，而问题恰恰在这里。把身份系统、终端、防火墙和云订阅接进来一个月之后，Microsoft Sentinel产生的事件数量已经超出一个人能读完的范围，更别说逐条调查了。检测在工作，垮掉的是"读"这一环。

大多数中型公司撞上这堵墙的方式都一样：有一套SIEM，有一位还兼着别的活儿的IT经理或安全工程师，而在18:00到次日09:00之间根本没有人。队列在夜里变长，早上花在草草浏览上，而诚实的说法是：低级和中级事件是靠"眼熟"关掉的，不是靠调查。

一层AI摘要能解决的是其中很窄的一部分：在人开始处理之前，把队列变得可读、有次序。它不会让谁变成分析师，也覆盖不了凌晨三点。把"它解决了哪一半"说清楚，才能让这件事保持有用而不是危险。

SIEM为什么会先让告警疲劳变得更糟

SIEM上线后的头几周，是它一生中最吵的时候，而这是预期之内的，不是故障。

开箱即用的规则并不了解你的环境。 每晚02:00从某台服务器发起认证的定时备份任务、一位使用境外VPN出口的开发、一位正在做合规批量操作的管理员——每一件都会触发点什么。规则在普遍意义上是对的，只是在"你"这件具体的事上是错的。

事件到达时缺少让它可判断的上下文。 Sentinel会把相关告警归并成一个事件，并附上实体——账号、主机、IP、文件——但某个账号要不要紧，是一个关于你们组织的问题，而SIEM看不到这一层。

数量本身击垮了优先级。 严重级别是由触发的那条规则给的，不是由后果给的。四十条中级事件在列表里长得一模一样，而那条牵涉到一个有特权的财务账号的，和另外三十九条看上去毫无区别。

夜里没人在读。 这才是真正的缺口，而在"读"这一侧堆再多工具也补不上它。值得早点说明白，免得后面的内容被误当成这个问题的解法。

到这一步，人的本能是去调规则、压噪音——这是对的，也确实该做。但调优是一件推进很慢、还要和其他所有事抢时间的工作，而在它推进的同时，队列每天早上仍然要被读一遍。

一层AI摘要该放在处置链路的哪个位置

只有一个位置：在SIEM产出事件之后、在人决定打开哪几条之前。上游一切照旧，下游一切仍然属于人。

该喂给模型的是事件，还是原始日志？

是事件，而且不用多太多。Sentinel的事件记录本身已经带着一份摘要所需的东西：标题和描述、严重级别和状态、检测所映射的战术与技术、时间戳、被归并进来的告警，以及涉及的实体。这是一个紧凑的结构化对象。

原始日志表是错误的输入，有三个理由。它体量巨大，于是你为体量付费，又让模型的注意力从要紧的东西上散掉。它包含的敏感细节远多于这项分析所需。而摘要的价值本来也不在日志里——它在于解释"这一簇告警看起来加起来是什么意思"。

再加一样事件记录里没有的东西：你们环境的"正常态"。用一小段上下文说明你们的备份任务在做什么、员工合法地从哪些地方连接、哪些服务账号在无人值守地运行、哪些人和系统是真正敏感的——这一段对输出的改善，超过任何提示词技巧。没有它，模型只能套用泛泛的推理，然后每晚都把你们自己的定时任务标出来。

通过Sentinel自己的API、或对事件相关表执行KQL查询把事件拉出来；具体的字段名和查询接口请以微软当前文档为准，不要相信某段代码片段——这个平台是会变的。

该跑在Sentinel的自动化里，还是跑成一个外部脚本？

两条路都成立，只是适合不同的起点。

Sentinel的自动化规则和剧本（Playbook，构建在Azure Logic Apps之上）可以在事件创建时触发并调用外部API，这是原生路径，也让整条流程留在Azure里——权限和审计轨迹本来就在那儿。它是更好的长期归宿，也更费工夫搭起来。

而一个定时的只读脚本：查询过去24小时的事件、把整批一次性交给模型、把简报发到邮箱或聊天频道——这是更快地搞清楚"这件事到底有没有用"的办法。它还有一个值得刻意保留的性质：它跑在一个只读身份上，不往Sentinel里写任何东西。

先从脚本开始。等到提示词不再每隔几天就改一次、而且简报真的有人在读的时候，再把它搬进剧本。

另外值得知道的是：微软自己也为安全运营提供了AI能力，如果你们本来就在那套授权体系里很深，它值得按它自己的条件先评估一遍。本文这套做法的成本，是一个下午。

一个实际例子——从嘈杂的队列到一份排好序的晨报

设想一家约400人的公司，Sentinel工作区接入了Entra ID、Defender、一台防火墙和两个云订阅，还有一位有安全意识的IT经理。

一夜之间工作区产生了38条新事件，多数是低级和中级。07:30的定时任务查询最近24小时创建的事件，逐条取出标题、严重级别、战术、内含的告警名称和实体。这是几百行结构化文本——一次请求就装得下。

提示词给模型三样东西：这批事件、上面说的环境上下文，以及一个明确的输出格式。真正起作用的是格式。要求每条事件产出一个条目，包含：一个排序位次、用两句话说清这些告警看起来在描述什么、最可能的无害解释、人接下来该做的那一项检查，以及一个把握程度。要求它把它认为属于同一起底层活动的事件归到一组。并且要求它明确点名：哪些事件凭所给数据它无法判断。

08:00落到手上的这份简报，通常会把那38条事件收敛成大约四簇值得关注的、十来条能说明理由的已知活动、以及少数几条被标为"无法判断"的。IT经理十分钟读完，打开Sentinel时已经知道该从哪儿开始——处置的顺序和以前一样，只是省掉了那一小时的通读。

关于这个例子，有两点必须诚实。那组"已知活动"仍然需要抽查，因为"模型信心十足地把一次真实入侵解释过去"正是最要命的失败模式。而且那38条事件在Sentinel里依然是38条——什么都没有被关闭，队列是变得可读了，不是变短了。让它变短是规则调优的工作，这套做法不替代它。同样形状的"辅助分流"在服务台场景里也成立，我们在搭建内部IT服务台分流机器人那篇里写过。

AI辅助分流 vs 检测规则调优 vs 7×24小时SOC

多快能看到价值 — AI辅助分流轻松胜出。一份只读导出、一段提示词、一个下午，而另外两条路是几周的调优或一轮采购。
减少告警数量 — 检测规则调优完胜。三者之中只有它能让队列真的变短，而不只是更好读。
解释一条事件到底意味着什么 — AI辅助分流胜出。把一簇技术告警变成一句忙碌的IT经理能据以行动的话，正是语言模型擅长的事。
凌晨三点的覆盖 — 7×24小时SOC胜出，其余两者都不沾边。一份简报只有在有人读的时候才成立。
对事件做出判断并采取行动 — SOC胜出。在一次进行中的入侵里做遏制，是判断和动作，不是摘要。
给审计或保险公司的证据 — SOC、或一套有记录的调优计划胜出。一段聊天记录不构成"有人在监控"的证据。
长期成本 — AI辅助分流便宜得多，而它便宜正是因为它做得最少。

这三者是层次，不是替代关系。对一家中型公司而言，现实的顺序是：用AI摘要先扛住眼前的队列，把省下的时间投进规则调优让队列变短，再为没人醒着的那些小时买有人值守的覆盖。

这套做法绝不能做的事

三条界限，没有商量余地。

绝不自动关闭事件。 模型那句"这几乎肯定是备份任务"，是一个看不到你们流量、工单和上周上下文的假设。据此关闭会得到一个干净的队列和一种虚假的覆盖感，那比一个乱糟糟的队列更糟。

绝不让它隔离主机、禁用账号或封锁地址。 响应动作必须落在人的决定之后。一个能凭模型对告警的解读去隔离机器的自动化，既是新的故障来源，也在能被触发的那一刻成为攻击面。

绝不把"很可能无害"当成结论。 把它当成"先从哪儿看起"的一句说明。这个区别听起来像抠字眼，直到它要紧的那一周。

以及贯穿这三条的一个基本立场：模型只能看见你发给它的东西。任何不在导出里的——一条被抑制的规则、一个停止上报的数据源、一类你从未接入的日志——对它都是不可见的，而且它不会告诉你少了什么。

把这件事做对——日志数据治理、API密钥，以及什么时候该让IT介入

三个值得刻意决定、而不是默认滑过去的问题。

什么东西离开了你们的租户。 安全遥测属于你们持有的较敏感的数据：用户名、主机名、内部编址、你们的检测覆盖范围，以及由此暴露的缺口。把它发给一个外部API是一个真实的决定。请有意识地做：去读你们实际使用的那个产品档位的数据处理与训练条款，而不是想当然——商业版和企业版通常与消费者版不同，条款也会变。可以考虑在导出前把账号名和主机名做假名化处理，这通常不会损失多少分析价值。如果这些都不可接受，同样的方法在自托管模型上照样成立；而把AI工作留在合规基础设施上的这套模式，和数据驻留受限市场里适用的是同一套。

凭据。 用于导出的身份对Sentinel应当是只读、且仅此而已；模型的API密钥应当属于一个有独立计费和用量上限的公司账号——而不是属于当初搭这套东西的那位工程师。两者都放进密钥库，给它们一个轮换日期，并且确保除了创建者之外还有别人知道它们存在。一位已经离职的工程师的个人API密钥还在悄悄跑着生产任务，是一个反复出现、又完全可以避免的问题。

没人醒着的那些小时归谁管。 这一部分是本文解决不了的。检测工程、规则调优和有人值守的监控覆盖，正是一套SIEM与安全监控服务存在的意义，其中就包括那项能让队列变短、而不只是更好读的调优工作。我们的AI+支持服务负责把这类自动化建在受治理的凭据和公司账号上，我们的托管IT支持负责围绕它的访问权限生命周期。Brocent自2007年在北京创立以来一直在亚洲提供托管IT与安全服务，总部位于新加坡，并自2016年起设有香港办公室。

常见问题

把安全日志数据发给AI工具，本身会不会带来风险？

会，而且这值得做一个决定，而不是形成一个习惯。一份事件导出描述了你们的用户、系统和检测覆盖。请把发送内容压缩到事件级字段、考虑对账号名和主机名做假名化、并核对你们实际所用档位的数据处理条款。如果监管或客户合同不允许，就用自托管模型——这套流程并不取决于回答的是哪个模型。

AI能自动关掉误报吗？

不能。它可以提出哪些事件看起来像已知活动、并说明理由，这作为阅读顺序确实有用。但"关闭"是一个对审计轨迹和实际安全态势都有后果的决定，它必须留在人这里。

这能降低我们的Sentinel数据接入费用吗？

不能——它位于接入之后，完全不改变你们采集了什么。接入成本是一个数据采集与日志层级的问题：接了哪些数据源、哪些表放在分析层、保留多久。这值得复核，但那是与分流分开的另一件事。

凌晨三点产生的事件怎么办？

它们会一直待在队列里，直到有人读那份简报。这是诚实的答案，也正是为什么这是"可读性改善"而不是"覆盖"。如果非工作时间的响应对你们的风险状况确实要紧——对大多数持有客户数据的公司来说确实如此——那需要的是由人值守的监控，而不是更好的摘要。

这能替代调优检测规则吗？

不能，而把它当成替代品，正是这件事出错的主要方式。摘要让一个过吵的队列变得能扛；调优让它变短。用前者去回避后者，等于你在长期付钱请一个模型，去解释那些本来就不该被触发的告警。

我们怎么知道这些摘要是准确的？

抽查。头几周里，固定打开若干条被模型"解释过去"的事件，检查它的推理是否站得住。把简报保存下来，和调查后的实际结论做对照。如果它对你们环境的判断是"自信地错了"，修复办法几乎总是更好的环境上下文，而不是更好的提示词。

除了Sentinel，别的SIEM能用吗？

能。除了导出这一步，本文没有任何东西是Sentinel特有的——任何能通过API暴露事件和实体的SIEM都能喂进同一套流程。之所以拿Sentinel举例，是因为它正是被这个问题困扰的中型公司最常部署的平台。

从哪儿开始

挑一周你们已经处置完的事件导出来，用十句大白话写下你们的环境上下文。让它产出那份排好序的简报，再和你们那一周实际查到的结果做对照。你会很快学到两件事：这个排序是否和你的判断一致，以及模型对你们环境的哪些部分一无所知——后者本身就是一份有用的缺口清单。如果结论是"队列可读了，但夜里根本没人在读"，那是一个覆盖问题、而不是工具问题，值得聊一聊——联系我们。