传统网络安全发展的“三驾马车”，通常可以概括为信息化、监管、安全事件。

在过去很多年里，这套逻辑非常成立。信息化越深入，系统越多、连接越多、数据越多，安全需求也就越强；监管要求不断加码，又进一步推动了安全产品和安全建设落地；每一次大的安全事件，无论是勒索、漏洞利用还是数据泄露，也都会反过来刺激新一轮安全投入。

但是到了今天，这套逻辑已经明显跑不动了。在 AI 飞速发展的背景下，网络安全新的“三驾马车”正在形成，即 AI 化、AI 安全监管，以及 AI 所造就的脆弱环境中的安全事件。过去，安全主要依附于信息化建设；今天，安全开始直接依附于 AI 化建设。AI 已经不再只是某个业务系统上的一个功能模块，它正在重写业务流程、研发方式、运维方式，甚至也在重写攻击与防守的方法本身。

一、旧的安全产品范式，已经越来越难解决新的问题

如果从设备层面去看，这个问题会更明显。

传统网络安全设备的销售，实际上早已进入红海。大量安全产品已经从“新需求驱动”变成了“存量替换驱动”，从“解决问题”慢慢退化成“满足采购清单”。这些设备并不是完全没有价值，而是价值边界已经越来越清楚，很难继续承担新时代的安全任务。

但另一方面，AI + 安全的产品目前又普遍卖不动。

这背后当然有市场教育、预算、效果稳定性等问题，但更根本的原因在于，目前大量所谓的 AI + 安全产品，依旧没有跳出旧网络安全设备的范式。很多产品做的事情，无非是在传统设备能力之上再叠加一层智能告警研判、自然语言查询、报告生成或者问答助手。这些能力看起来更智能了，但底层运行方式并没有变，仍然是在用旧设备、旧规则、旧流程去承载新问题。

也正因为如此，今天真正跑不动的，不只是某几类产品本身，而是过去那种以单点设备、规则堆叠和人工运营为主的安全建设范式。问题已经不再是设备够不够多，而是这套体系本身还能不能在 AI 时代继续维持有效防守。

二、AI + 攻击先行，正在倒逼防守侧改变运行方式

而眼下更现实的压力，来自攻击侧已经先一步把 AI 用起来了。

当前 AI + 安全的发展里，一个非常明显的现实是，AI + 攻击已经先跑起来了。无论是钓鱼、社工、漏洞利用、恶意代码生成，还是针对暴露面的自动化探测，攻击侧都比防守侧更早找到了 AI 的高价值用法。

真正值得警惕的，并不只是攻击能力增强了，而是它正在倒逼防守侧改变原有运行方式。因为如果防守方还停留在规则驱动、设备驱动和人工填充为主的旧运行方式里，那么面对越来越低成本、越来越高频、越来越自动化的攻击，代差只会越来越大。

这背后有三个原因。

第一个原因，是网络安全攻防天然不对称。攻击者只需要找到一个点，防守者却要覆盖整个面。攻击方只要在钓鱼、社工、漏洞利用、口令爆破、横向移动或者恶意代码生成中的任意一个环节获得提升，就可能放大整体成功率；防守方面对的却是资产、身份、流量、终端、应用、数据、人员、流程、合规等多个层面的系统性责任。

第二个原因，与当前 AI 的能力结构有关。无论是大模型还是 Agent，现阶段最擅长的仍然是目标明确、链路线性、反馈快速的任务，比如自动写钓鱼邮件、自动生成恶意脚本、自动枚举暴露面、自动分析单个漏洞利用路径、自动尝试社工和信息拼接。这类任务边界清晰、收益明确、成功标准直接，天然适合 AI 发挥作用。相比之下，防守更依赖长期稳定的数据治理、复杂上下文理解、多系统协同和大量低确定性的全局判断。从这个角度看，攻击更像点状突破，防守更像系统工程，AI 自然会先放大前者。

第三个原因，是防守方背负的历史负担太重。攻击者可以轻装上阵，哪里有效就用哪里；防守者却必须继承大量既有系统、设备、流程和组织责任。现实里没有哪家公司会因为 AI 来了，就把原有的防火墙、EDR、WAF、堡垒机、审计平台、SIEM 和权限体系全部推倒重来。因此，AI 防守面对的局面并不是在一张白纸上重建，而是在一个已经复杂、已经异构、已经分裂的环境中改变旧体系的运行方式。

也正因为如此，AI + 防守现在最缺的，已经不是在原有安全产品上继续叠加几个智能能力，而是尽快拿出一套新的运行方式，把过去依赖规则体系和大量人工运营才能勉强维持的旧体系重新组织起来。AISOC 之所以重要，正是在这个背景下被推到台前的。

三、AISOC 不是旧 SOC 的智能增强版

在旧安全设备短期内无法被替代的现实前提下，AI + 防守的重点已经不应该继续停留在单点工具增强上，而应该转向一套新的安全运行中枢，我把它叫作 AISOC。

AISOC 当然不是传统 SOC 前面简单加一个 AI 前缀，也不只是“传统 SOC + 大模型助手”。如果只从这个角度去理解，它最后还是会退化成旧系统上的一个辅助功能。

在我看来，AISOC 真正要解决的问题，不是把原有安全设备更好地汇聚起来，也不是把旧 SOC 做得更聪明一点，而是把过去依赖规则体系和大量人工运营才能成立的那套运行方式，改写成一套以 AI 语义理解、持续判断和自动执行为核心的新体系。

这也是它和传统 SOC 最根本的差别所在。传统 SOC 的基本思路，是先把数据接进来，再靠规则去筛，再靠人去补。AISOC 要做的，则是让系统本身开始承担过去必须由规则和人工共同承担的那部分理解、关联、判断和执行工作。

从这个意义上看，AISOC 更像一个安全运行系统。它不只是换一个更智能的界面，而是在重写安全体系本身是如何运转的。

四、AISOC 要重写的四层能力

把 AISOC 拆开来看，要重写的能力大致可以按照旧的命名分成四层：感、知、态、势。

不同于一般的的命名：态势感知，这里的顺序更符合实际落地路径：没有输入，就谈不上理解；没有理解，就很难形成状态判断；没有状态判断，后面的编排和外部感知也很容易变成空转。

1. 感：接入与归一

AISOC 如果连输入问题都没有解决，后面的理解、判断和执行都无从谈起。所以“感”这一层最先要处理的，仍然是多源设备如何接入，以及接入之后如何完成统一语义归一。

设备接入

传统 SOC 长期“建而不用”的一个关键原因，就是设备接入成本太高。

现实中的设备接入，往往意味着一个设备一个设备去适配，一种日志一种解析方式，设备一改版接入逻辑就要重新调整。再加上字段不统一、文档不完整、样本不稳定，这项工作很容易演变成高度依赖人工经验的体力活。

这恰恰是 AI 非常适合发挥作用的地方。过去，接入人员需要手工写规则，告诉系统 request_header、request-header、reqHer 这些可能都是同一类字段。现在，AI 已经具备了足够强的语义泛化能力，即使没有完整规则，甚至没有完整说明文档，也可以通过样本日志、字段分布和上下文关系快速判断字段含义并完成归并。

因此，AISOC 应该具备一个真正可用的设备接入界面，能够展示当前设备接入状态，支持新增设备接入，支持输入 syslog、kafka、API 或文件拉取等获取方式，支持上传说明文档，也支持在没有文档时直接接入样本日志，然后由 AI 自动完成字段识别、字段孵化、语义映射和标准化，最终输出映射关系、字段解释与示例内容。如果设备版本发生变化，系统还应能够自动比对差异并重新学习映射。

这里还能继续往前走一步。传统接入的目标通常只是“把日志接进来”，但 AISOC 的接入目标不应该停留在采集层，而应该尽快让这些数据进入可理解、可关联、可直接参与判断的状态。换句话说，设备接入不再只是一个数据工程动作，它应该成为 AISOC 重写旧规则体系的起点。

字段规范

设备接入之后，更大的问题才真正开始。不同设备即使都接入了，也不代表它们能够被统一使用。

旧范式下，这个问题通常只能靠“并集字段”勉强处理。每个设备保留自己的字段体系，平台只抽取少量通用字段，查询依赖经验，关联依赖人工，规则复用性很差。结果就是设备虽然都进来了，但很多时候既看不清，也用不好，实际效果和没接进来差别不大。

在这个问题上，目前比较成熟的方向是 OCSF。OCSF 的意义并不只是给出一份字段字典，而是在于它试图把不同厂商、不同设备、不同类型的安全数据压缩进一套统一的语义框架中。

如果用更直白的话来说，这套框架要回答的是：谁，在什么时间，通过什么身份，从哪里，访问了什么资产，执行了什么动作，影响了什么数据，是否偏离了基线。

这套表达很关键，因为它把原来的“设备字段”转成了“安全语义字段”。AISOC 如果想真正成立，重点就必须从“接了多少设备”转移到“形成怎样的统一语义”上来。因为只有当系统真正理解这些数据表达的是同一件事，后面的降噪、研判、关联、溯源和联动才有可能摆脱过去那种靠大量规则和人工拼起来的状态。

再往上走一步，AISOC 的字段体系也不应只停留在日志字段标准，它还应该继续长成资产语义、身份语义、行为语义、攻击阶段语义和处置动作语义。只有这样，AISOC 才不只是一个日志仓库，而更像一个能够持续理解和组织安全信息的运行系统。

这一点再往前走一步，其实会带来 AISOC 边界的变化。过去大家谈安全数据接入，默认接的是防火墙、WAF、EDR、审计设备这类传统安全设备；但如果 AISOC 已经完成了数据格式规范化和统一语义归一，那么它理论上就不应该再被“安全设备”这个边界限制住。

只要能够进入同一套语义框架，能够参与安全判断，Nginx 日志、业务系统日志、ELK 中已经沉淀的日志与检索结果、身份与权限系统日志、云平台审计日志，甚至部分关键业务行为数据，都可以成为 AISOC 的输入源。

这件事很重要，因为真实安全事件本来就不只发生在安全设备里，很多关键线索往往最早体现在访问日志、身份调用链、接口行为和应用运行状态中。AISOC 只有把这些原本分散的数据一起纳入，才有可能真正建立跨设备、跨系统、跨业务的理解能力。

2. 知：降噪、研判与关联

“知”这一层解决的是理解问题。数据进来之后，如果系统仍然不能分辨什么重要、什么异常、什么值得关联、什么只是背景噪音，那么 AISOC 仍然只是在堆积信息，而不是形成认知。

告警降噪

告警降噪的核心，从来都不只是把数量降下来，而是要回答两个更关键的问题：哪些告警是业务导致的，哪些告警虽然异常，但在当前环境下是可以接受的。

这在规则时代属于非常典型的强人工任务，因为规则只能判断“像不像”，却很难判断“在这里是不是合理”。例如同样是深夜批量访问、同样是大流量下载、同样是频繁调用接口，在不同公司、不同业务、不同系统、不同时间窗口里，含义可能完全不同。

这是 AI 可以充分发挥价值的地方。

AI 可以结合历史告警处理结果、资产属性、用户角色、业务时间规律、上下游调用关系以及同类行为基线，对一个告警做更接近语境化的判断，进而分辨它更像是真实攻击，还是业务扰动。因此，AISOC 的告警降噪不应该继续主要依赖阈值调优、白名单堆叠和规则屏蔽，而应该逐步把过去依赖人工经验判断的那部分工作收进系统里。

传统 SOC 更多是在“删掉噪音”，AISOC 需要能够解释噪音为什么会产生。

智能研判的信任阈值

告警研判是网络安全领域最早落地 AI 的场景之一。很多厂商这么多年一直在宣传自己的智能研判准确率、覆盖率和自动化率，往往都能给出一个很高的数字。但从真实的安全运营体感来看，很多安全负责人并不真正相信 AI 研判结论。他们通常还是会要求分析人员对 AI 给出的结果进行二次确认。

这个现象很重要，因为它暴露出的关键问题并不是“AI 能不能研判”，而是“AI 研判能不能跨过安全负责人的信任阈值”。安全负责人需要的，不只是一个看起来像对的答案，更是一个可承担责任、可追溯、可复盘的答案。规则在今天依旧可用，是因为它更容易复现、更容易解释，也更容易审计和归责。

这就意味着，AISOC 在智能研判上的策略不能一上来就追求“AI 全接管”。如果某类告警已经有足够稳定、足够可信、足够可审计的规则链路，那么继续沿用规则往往是更务实的选择。AI 更适合优先去接管那些规则长期难以覆盖、而又大量消耗人工精力的地带，例如语义模糊的告警、跨设备跨场景的复合异常、高度依赖上下文的行为判断，以及需要快速拼接多源证据的分析过程。

AISOC 真正有价值的地方，不是简单替代所有规则，而是开始吃掉过去只能依赖人去补的那部分空白。

事件生成

SOC 的一大难点是事件。

单条告警本身通常价值有限，真正有价值的是多个告警、多个日志和多个行为片段，如何被组织成一个可判断、可处置、可追踪的安全事件。传统做法主要依赖 IP 关联、时间关联、MD5 关联、用户名关联和资产关联。这些方法当然有用，但它们本质上仍然是静态规则关联。

问题在于，真实攻击链往往并不完整，也不会恰好满足预设好的所有条件。很多关键线索分散在不同设备、不同时间和不同字段表达中，单靠规则很难把它们真正拼起来。

AISOC 在这里的优势，在于它可以把“规则关联”升级成“规则和语义联合关联”。规则继续负责确定性连接，AI 负责理解弱关系，图谱或攻击链模型负责结构化表达，最终由 AISOC 生成事件，而不是简单地堆叠告警。

这里还可以再往前推一步。AISOC 生成的最好不只是“事件记录”，还应该是“攻击叙事”，也就是不仅说明发生了什么，还需要尽可能解释攻击从哪里开始，中间经过了哪些路径，现在走到了哪一步，下一步最有可能发生什么。只有这样，事件才真正成为系统可以接着往下执行动作的单元，而不只是给人看的展示单元。

3. 态：溯源、处置与表达

在“态”这一层级，重点不再是单条数据如何理解，而是整个事态如何被还原、如何被改变、又如何被准确表达出来。这一层更接近真正的安全运营状态。

威胁溯源

如果说哪个场景最容易发挥 AI 优势，尤其是 Agent 的能力，我认为威胁溯源是最典型的一个。

原因很简单，溯源本身就是一个目标明确、步骤推进、需要不断查证和收敛的分析任务。比如从一个异常登录开始，逐步扩展到登录账号、源地址、相关主机、进程执行链、文件落地情况、横向访问轨迹、可疑外联目标，最后再还原完整攻击路径。这类工作非常适合 Agent 去承担大量基础分析、证据拼接和候选路径收敛工作。

过去这些事情高度依赖分析师一条一条去查、一段一段去拼。AISOC 的意义，就在于让系统开始接管这部分原本必须由人工完成的中间劳动。

自动化处置

传统 SOC 的一个长期问题在于，发现了、理解了、上报了，但处置链路跟不上。很多时候安全团队并不缺告警，也不缺报告，真正缺的是把分析快速转成动作的能力。

因此，AISOC 不能只做到“看见”和“理解”，还要尽可能推动“处置”。这里的处置当然不一定一上来就意味着全自动封禁，更合理的做法应该是分层推进。先从建议式处置开始，由系统给出处置建议、优先级、工单和核查路径；再往前走，可以进入半自动处置阶段，例如一键隔离主机、一键封禁账号、一键下发阻断策略或者触发加固流程；对于那些高确定性、低争议、可审计的事件，再逐步引入全自动联动。

这也是 AISOC 和传统 SOC 的一个明显差别。传统 SOC 很多时候停留在看板和研判层，而 AISOC 要开始真正接管动作链路本身。

态势表达

报告生成可能是当前成熟度最高的 AI 安全场景之一。更准确的说法，报告生成应该叫做态势表达。也就是说，AISOC 不只是要把分析结果写出来，更要把当前事态用不同角色都能理解的方式表达出来。对安全分析师来说，它可能是一条完整攻击链；对安全负责人来说，它可能是一份带有优先级和处置建议的事件摘要；对管理层来说，它可能是一段关于影响范围、业务风险和下一步决策的简化说明。

从这个角度看，报告只是态势表达的一种结果。真正成熟的 AISOC，应该能够理解不同客户、不同角色的表达目标，能够自主获取所需数据，能够根据场景重组内容结构，能够解释异常的成因和影响，也能够把发现、判断和建议串成完整叙事。只有做到这一步，表达能力才不是单纯的文书处理，而是系统开始承担原本需要大量人工整理、转译和汇报的那部分工作。

4. 势：编排与外部感知

再往前走一步，AISOC 应该具备对后续动作的编排能力，以及对外部变化的持续感知能力，这一层对应的就是“势”。

“势”很难一开始就做得很完整，因为它天然依赖前面几层能力是否扎实。设备没有接好，语义没有统一，告警没有降噪，事件没有稳定生成，后面的编排和感知大多都会沦为空转。但这并不意味着“势”不重要，恰恰相反，它决定了 AISOC 最终能不能从被动响应走向主动运营。

SOAR 剧本动态编排

这一层最容易落地、也最有现实价值的能力之一，就是 AI 自动完成 SOAR 剧本编排。

传统 SOAR 的问题，很多时候不在于没有剧本，而在于剧本太死、编排太固定，适应不了真实环境中的上下文变化。不同资产、不同系统、不同事件等级、不同业务时段，实际处置流程往往并不完全一样，但传统 SOAR 很难把这些差异真正吸收进去。

如果 AISOC 已经完成了统一语义和事件理解，那么它就有可能根据事件类型、资产重要性、当前环境状态和历史处置经验，自动选择、自动拼接，甚至自动生成更合适的响应剧本。

例如某类账号异常，系统可以自动决定是否先查登录地、再查权限变更、再触发 MFA 收紧；某类主机告警，系统可以自动安排先收集证据、再隔离网络、再通知运维；某类 Web 攻击，系统也可以先关联 Nginx 日志和 WAF 记录，再决定是否触发封禁。走到这一步，SOAR 就不再只是固定流程执行，而开始变成基于上下文的动态编排。

这本质上也是对旧体系的一次重写。过去依赖人工经验和固定剧本拼出来的响应流程，开始被系统本身吸收和重组。

外部安全信息获取与融合

除了内部事件的编排，我觉得“势”这一层还应该有一个很重要的能力，就是持续获取互联网上最新的网络安全信息，并把这些外部变化及时转成内部可用的判断。

这里的外部信息至少包括几类：最新安全政策、最新漏洞情报、最新攻击事件、最新威胁组织动向、最新利用链和公开 PoC、重点厂商或开源组件的高危风险通报。

这件事之所以重要，是因为很多风险的起点并不在企业内部，而是在外部环境已经发生变化，但内部系统还没有及时响应。例如某个高危漏洞刚公开、某类攻击手法突然开始流行、某项监管要求刚更新，这些变化如果不能尽快进入 AISOC 的认知体系，那么内部很多判断就会天然滞后。

因此，AISOC 不应该只是消费内部日志和告警，也应该能够持续获取外部安全信息，对这些信息做筛选、归类、去重、关联，并进一步结合自身资产、技术栈、业务系统和暴露面情况，判断哪些信息与自己真正相关。

例如一个新漏洞公开之后，AISOC 可以自动判断本单位是否存在相关组件、哪些资产可能受影响、是否已有暴露面、是否需要立即触发排查或加固；又比如某项安全政策更新之后，AISOC 可以进一步提示哪些现有能力需要补齐、哪些日志留存或审计要求需要调整。这样一来，外部信息才不是简单“看新闻”，而是被真正吸收到内部安全运营中。

五、AISOC 的产品形态：统一交互入口

如果说前面讨论的是 AISOC 具体要重写哪些能力，那么再往下看，还有一个同样重要的问题，就是这些能力最终该以什么样的产品形态呈现出来。

传统 SOC 有一个长期问题，是能力虽然很多，但入口始终是分裂的。查告警在一个页面，查日志在一个页面，做溯源在一个页面，写报告在一个页面，联动处置又在另一个页面。系统表面上功能齐全，但真正使用时，安全人员仍然需要在多个界面之间频繁切换，自己拼接上下文，自己串联流程。

这件事本身就说明，旧 SOC 的很多能力并没有真正被系统内化，而是依然依赖人去承担中间那部分组织工作。人负责跨页面切换，人负责理解上下文，人负责把分散的动作重新串成任务链。

如果 AISOC 真的是对旧体系运行方式的重写，那么这种分裂的交互方式也应该被一起重写。换句话说，AISOC 不只是要把能力放在一起，更重要的是把原来分散的任务入口重新收回来。

AI 时代的产品形态，是把主要能力尽量收敛到一个统一的 ChatBox 上，AISOC 也应如此。这个 ChatBox 当然不只是一个问答入口，也不只是自然语言检索框，而应该成为查询、分析、研判、联动和处置的统一交互界面。用户可以直接在里面完成大量日常安全工作，比如查询某个告警、追踪某个 IP、分析某个账号的异常行为、生成某个时间段的事件报告、发起一次威胁溯源、查看某类攻击趋势，甚至直接触发处置流程。

其中一部分简单操作，可以直接在 ChatBox 内完成，例如查询、总结、比对、解释、生成报告、归纳事件、给出处置建议。另一部分更复杂、涉及多步骤页面流转和外部系统联动的操作，则可以由 AISOC 背后的 Agent 自动接管，在后台自动操作浏览器或其他业务系统，完成页面跳转、参数填写、对象选择、策略下发、工单创建等动作。对于封禁账号、隔离主机、下发阻断策略、修改配置这类高影响动作，则应该在关键节点保留用户确认。

从这个角度看，ChatBox 对 AISOC 的意义，并不只是界面上的变化，而是在交互层上把过去依赖人去切换、去串联、去组织的那部分工作收回到系统里。只有这样，AISOC 才不只是一个更方便用的系统，而是真正开始替代旧体系中那部分高强度人工运营。

六、AISOC 最终解决的，是防守范式问题

很多人容易把 AI + 安全理解成一个效率提升命题，无非是希望少一些人力投入、多一些自动化处理、让报告写得更快、让告警研判更省时间。这些诉求当然都成立，但如果只把 AISOC 理解到这个层面，价值会被大大低估。

AISOC 真正要解决的，其实是防守范式问题。

在 AI 时代，攻击者正在获得越来越强的低成本自动化能力。如果防守方依然长期停留在单点设备、固定规则和人工运营为主的旧体系中，那么问题就不只是效率高低，而是这种防守体系本身很可能越来越难正面承受新的攻击强度。

因此，AISOC 的意义，并不是把旧 SOC 做得更智能一点，也不是在原有安全产品外面包一层 AI，而是重写旧安全体系那种依赖规则和人工勉强维持的运行方式。

这里还有一个很重要的变化，就是 AISOC 在完成数据格式规范化之后，接入范围其实已经不需要再被传统安全设备限制住。任何能够进入统一语义框架、能够参与安全判断的数据，都可以成为 AISOC 的输入源，包括 Nginx 日志、ELK 中沉淀的日志与检索结果、业务应用日志、云侧审计日志，以及身份和权限相关数据。

从这个角度看，AISOC 最终建设的也不只是一个安全设备汇聚平台，而是一套面向 AI 时代防守运行方式的新体系。因为很多真实风险，并不一定是先被某一台安全设备发现的，而可能是先体现在业务访问异常、身份调用异常、接口行为异常和应用运行异常上。AISOC 只有把这些数据一起纳入，并让系统自己开始承担理解、关联、判断和执行，才可能真正完成对旧体系的替代。

总结

网络安全行业几乎没有真正意义上的内部生产资料。规则、漏洞信息、攻击手法、威胁情报，这些内容大多都可以在互联网上持续获取。传统网络安全体系，本质上就是围绕这些公开信息，依靠规则体系和大量人工运营进行搭建的。

但 AI 时代到来之后，这套旧体系正在被快速推散。攻击者已经开始把 AI 变成真实能力，而防守侧如果还停留在规则驱动和人工填充为主的运行方式中，代差只会越来越大。

从这个角度看，AISOC 之所以重要，并不只是因为它代表一种新的产品形态，也不只是因为它比传统 SOC 更智能，而是因为它更有可能成为 AI 时代防守侧重写自身运行方式的起点。

AI 时代，SOC 需要被重写：我对 AISOC 的一些架构思考