如何将 AI 融入现代 SOC 工作流

人工智能（AI）正快速渗透到安全运营中，但许多从业者仍在努力将早期实验转化为持续的运营价值。这是因为 SOC 在采用 AI 时缺乏有意的运营集成方法。一些团队将其视为修复破碎流程的捷径，另一些则尝试将机器学习应用于定义不清的问题。

强化了这种脱节现象。相当大比例的组织已经在实验 AI，然而 40% 的 SOC 在未将 AI 或 ML 工具明确纳入运营的情况下使用它们，42% 完全使用“开箱即用”的 AI/ML 工具而不做任何定制。结果是 AI 已经出现在 SOC 中，却未实现运营化。分析师非正式使用 AI，可靠性参差不齐，管理层也尚未建立一致的模型来确定 AI 的定位、输出验证方式以及哪些工作流已足够成熟以受益于增强。

AI 能切实提升 SOC 的能力、成熟度、流程可重复性以及人员容量和满意度。只有在团队缩小问题范围、验证逻辑、并以与任何工程工作同等的严谨态度对待 AI 输出时，AI 才能发挥作用。机会不在于创造全新工作类别，而在于细化已有工作，并为现有能力的测试、开发和实验提供支持。当 AI 被应用于特定、界限明确的任务并配合清晰的审查流程时，其影响既可预测也更有价值。

以下是 AI 能为 SOC 提供可靠支持的五个领域。

1. 检测工程

检测工程本质上是构建高质量警报，以便放入 SIEM、MDR 流水线或其他运营系统。要实现可行性，逻辑必须经过开发、测试、优化并以高度可信的方式运营化。这正是 AI 常被低效使用的地方。

除非 AI 本身是预期的结果，否则不要假设 AI 能修复 DevSecOps 的缺陷或解决警报流水线的问题。AI 只有在针对可支持持续运营验证和调优的明确定义问题时才有用。一个来自

课程的明确示例是，使用机器学习检查数据包流的前八个字节，以判断流量是否重建为 DNS。如果重建结果与已知的 DNS 模式不匹配，系统会触发高保真警报。价值在于任务的精确性和训练过程的质量，而非广泛自动化。预期实现方式是检查所有 UDP/53（以及 TCP/53）流，并基于机器学习调校的自动编码器评估重建损失。阈值违规的流被标记为异常。

该细粒度示例展示了可实施的 AI 驱动检测。通过检查数据包流的前八个字节并依据历史流量中学习到的模式判断其是否重建为 DNS，我们创建了明确、可测试的分类问题。当这些字节与 DNS 正常模式不符时，系统报警。AI 在此有效是因为范围狭窄且评估标准客观。它可能比基于启发式规则的检测更有效，因为它学习对熟悉的内容进行编码/解码，而不熟悉的内容（此处指非 DNS）则无法正确编码/解码。AI 无法解决定义模糊的警报问题或弥补缺失的工程纪律。

2. 威胁狩猎

威胁狩猎常被描述为 AI 能“自动发现”威胁的场所，但这误解了工作流的目的。狩猎不是生产环境的检测工程，它应是 SOC 的研发能力，分析师在此探索思路、检验假设、评估尚未足够强大以实现运营化的信号。这是因为漏洞与威胁环境快速变化，安全运营必须不断适应信息保障领域的波动和不确定性。

AI 在此适用，因为工作本身是探索性的。分析师可以利用 AI 试点方法、比较模式或检查假设是否值得调查。它加速了分析的早期阶段，但并不决定何为重要。模型是有用的工具，而非最终权威。

狩猎也直接为检测工程提供素材。AI 可帮助生成候选逻辑或突出异常模式，但分析师仍负责解释环境并决定信号的意义。如果他们无法评估 AI 输出或解释其重要性，狩猎可能一无所获。AI 在此的价值在于加速和扩展探索范围，而非提供确定性判断。我们提醒在使用时注意运营安全（OpSec）和信息保护，仅向授权系统提供与狩猎相关的信息。

3. 软件开发与分析

现代 SOC 依赖代码。分析师编写 Python 脚本自动化调查，使用 PowerShell 工具进行主机询问，并为 SIEM 编写特定查询。持续的编程需求让 AI 成为软件开发与分析的自然匹配。它可以生成草稿代码、优化现有片段或加速先前手工编写的逻辑构建。

但 AI 并不理解底层问题。分析师必须解释并验证模型生成的所有内容。如果分析师在某个领域缺乏深度，AI 的输出即使听起来正确也可能是错误的，且分析师可能无法辨别。这导致一种独特风险：分析师可能会部署或依赖自己并未完全理解且未充分测试的代码。

AI 在此最有效的地方是降低机械性开销。它帮助团队更快获得可用起点，支持 Python、PowerShell 或 SIEM 查询语言的代码创建。但正确性责任始终由懂得系统、数据及生产环境后果的人承担。

作者建议团队制定适当的代码风格指南，并仅使用经授权（即已测试并批准）的库和包。将这些指南和依赖要求作为每次提示的一部分，或使用能够配置这些规范的 AI/ML 开发工具。

4. 自动化与编排

自动化长期是 SOC 运营的一部分，但 AI 正在重塑团队设计这些工作流的方式。分析师不再需要手动拼接行动序列或将运行手册转换为自动化逻辑，而是可以让 AI 起草框架。AI 能列出步骤、提出分支逻辑，甚至将自然语言描述转化为编排平台所需的结构化格式。

然而，AI 不能决定何时应运行自动化。编排的核心问题仍未改变：自动化动作是应立即执行，还是先交由分析师审查？此决定取决于组织的风险容忍度、环境敏感性以及具体动作。

无论平台是 SOAR、MCP 还是其他编排系统，启动动作的责任必须在人工，而非模型。AI 可以帮助构建和优化工作流，但永远不应成为激活它的权威。明确的边界使自动化保持可预测、可解释，并与 SOC 的风险姿态保持一致。

当组织对自动化的舒适度达到一定阈值时，就能实现快速、自动化的行动。此舒适度来源于广泛测试以及人员对自动化系统行为的及时响应。

5. 报告与沟通

报告是安全运营中最持久的挑战之一，并非因为缺乏技术能力，而是因为将技术能力转化为清晰、可操作的沟通难以规模化。2025 SANS SOC 调查显示，69% 的 SOC 仍依赖手动或主要手动的方式报告指标。这一缺口极其重要：报告不一致会导致管理层失去可视性、上下文被稀释，进而拖慢运营决策。

AI 提供了一种即时且低风险的方式来提升 SOC 报告的表现。它可以通过标准化结构、提升清晰度来平滑报告的机械环节，帮助分析师将原始笔记转化为良好形成的摘要。AI 让每位分析师的风格保持一致，避免技术细节淹没要点，从而产生易于管理层快速解读的报告。包括移动平均、标准差边界以及整体一致性等信息，都值得在向管理层汇报时呈现。

价值不在于让报告看起来更华丽，而在于让报告连贯且可比对。当每一次事件摘要、每周汇总或指标报告遵循可预测的结构时，领导层能够更快识别趋势并更有效地进行优先级排序。分析师也能节省在措辞、格式或重复说明上花费的时间。

你是采纳者、塑造者还是创造者？欢迎在 SANS Security Central 2026 与我交流

当团队在这些工作流中开始尝试 AI 时，需要认识到没有唯一的采用路径。SOC AI 的使用可以划分为三类：采纳者直接使用供应商提供的 AI 工具；塑造者对这些工具进行调整或定制以符合工作流；创造者则自行构建新方案，例如前文提到的高度限定机器学习检测示例。

所有这些示例都可能属于一种或多种类别。你可能在检测工程中既是采纳者又是创造者，使用 SIEM 供应商的 AI 规则并自行打造检测；在报告中既是手工创造者也是采纳者（仅使用开箱即用的工单系统报告）；在自动化中可能是塑造者，部分定制供应商提供的 SOAR 运行手册。希望你至少在使用基于 IOC 的供应商狩猎；若能做到内部驱动的狩猎，则进入创造者行列。关键在于每个工作流都要明确 AI 的使用场景、输出验证方式、持续更新机制，并始终让分析师对信息系统的保护负最终责任。

我将在即将于新奥尔良举办的

主旨演讲中深入探讨这些主题，帮助你评估当前 SOC 的 AI 采纳现状，并设计强化团队专业能力的 AI 采用模型。期待与你相见！

注：本文由 SANS 高级讲师 Christopher Crowley 精心撰写并贡献。