大家读完觉得有帮助记得关注和点赞摘要大语言模型LLM正越来越多地在安全运营中心SOC中被探索以支持文本密集型分析工作如告警情境化、事件摘要和调查文档起草。尽管存在这种兴趣从业者描述了关键的操作问题尤其是幻觉看似合理但错误的输出、不透明的推理以及在安全工作流中安全使用模型生成内容所需的验证工作。在本文中我们呈现了对20名SOC从业者进行的半结构化访谈结果涵盖一线分析师、SOC经理和工具开发者。参与者报告了在可快速验证的低风险任务如总结日志或起草初步调查线索中感知到的时间节省但他们一致将LLM输出视为初步草稿和建议而非决策级结论。参与者还描述了对LLM在高风险安全决策中的有限信任原因是不可靠的输出和模糊的模型推理并且他们报告主要依赖临时验证规范和持续人工监督而非标准化的缓解程序。基于这些访谈扎根的叙述我们引入了一个成熟度评分量表来表征LLM集成的准备程度并概述了一个研究议程强调可审计性和透明解释机制以支持在SOC工作流中更安全地采用LLM。1 引言安全运营中心SOC面临着来自日益增长的告警、日志和事件工件的数量和复杂性的持续超负荷。传统的机器学习ML技术可以支持狭窄的分类和异常检测任务如入侵检测、恶意软件分类和威胁关联[20]。然而这些方法通常止步于将事件标记为恶意或良性并不能一致地提供在时间压力下快速、可辩护的分析师决策所需的上下文、人类可读的解释。大语言模型LLM最近被定位为一种有前景的回应能够总结异构事件数据、生成人类可读的解释并以易懂的术语生成草稿响应[31]。这种能力超越了检测LLM可以将技术证据转化为叙述和候选的后续步骤供分析师审查、完善和沟通。鉴于分析师疲劳和网络安全技能短缺这种自动化潜力对许多组织具有吸引力。Gartner最近的一项调查反映了行业对生成式人工智能GenAI日益增长的兴趣约55%的公司正在试验此类技术然而只有约10%报告了生产部署表明对操作可靠性和可信度存在持续担忧[7]。大多数关于网络安全中LLM的先前工作集中在能力评估、基准风格研究或对机遇和风险的广泛调查上。相比之下关于LLM如何在实际SOC工作流中使用、当输出被视为调查线索或草稿工件时会出现哪些工作流扎根的失败模式以及验证输出和在实际操作中减轻幻觉风险需要哪些组织准备我们知之甚少。在运营SOC环境中失败可能难以快速检测模型可能产生看似合理但不正确的陈述、无效逻辑或难以验证的解释。即使是偶发错误也可能侵蚀信任并产生昂贵的返工因为从业者必须在采取行动前验证输出。部署还受到治理要求的进一步限制如可审计性、变更控制和审批流程以及获取专业数据集、快速老化威胁数据和计算能力的有限访问[9]。在本工作中我们研究SOC从业者如何看待基于LLM的安全工具的效用、局限性和缓解策略并描述感知收益何时受到失败模式和验证负担的制约。我们的研究由三个研究问题指导• RQ1LLM目前在SOC工作流中的哪些位置以及如何集成• RQ2在安全运营中使用LLM的感知收益和实际挑战是什么• RQ3SOC在组织层面多大程度上准备好识别、理解和缓解LLM幻觉风险为回答这些问题我们对SOC生态系统中的20名安全从业者进行了半结构化访谈包括一线分析师、SOC经理、工具开发者和探索LLM集成的研究人员。参与者描述了使用案例、感知收益、失败模式以及他们在日常工作中依赖的验证和缓解实践。这个范围界定决策是明确的而非事后的。在从业者遇到的失败模式中幻觉在SOC工作流中具有独特的危险性因为与对抗性操纵或语法错误不同幻觉的事实和误导性调查方向可能看起来足够合理以通过初步审查并静默地传播到分类检查清单、检测草稿和事件报告中。因此我们将RQ3的范围限定在幻觉周围因为评估管理此风险的准备程度需要从业者扎根的访谈证据而这仅靠能力基准无法提供。范围/非目标。 我们研究SOC从业者在日常工作流中将LLM作为助手使用时的非对抗性操作可靠性失败。在这里失败模式是指任何看似合理但错误、不完整、误导或难以验证的输出通过返工、错误分类、延迟或不正确报告增加工作流风险。我们的分类法扎根于参与者报告的日常使用包括幻觉事实、无效逻辑、误导方向、解释错误和验证负担假设分析师仍然是对决策负责的责任人。我们不评估对抗性攻击或攻击面有效性这些仅作为背景讨论因为它们在我们的访谈中没有被直接测量。贡献。 本文基于SOC实践做出了四个贡献• 一个按角色分层的实证映射展示LLM进入SOC工作流的哪些位置以及从业者委派与保留哪些任务RQ1• 一个从访谈记录中派生的SOC环境中LLM输出失败模式分类法FM1–FM7包含角色覆盖和显著性RQ2• 一个幻觉缓解成熟度评分量表包含可观察标准和参与者级分布RQ3• 以及一个决策级、验证优先的综合矩阵连接SOC任务类型、失败模式、验证负担、成熟度先决条件和安全集成模式。2 相关工作近期工作将网络安全中的LLM框架为一把双刃剑既提供防御收益也引入新的攻击风险。聚焦于运营SOC环境我们回顾两方面的文献防御性SOC导向的用途和攻击性/原生AI威胁然后突显激发RQ1–RQ3的评估和运营差距。2.1 LLM在网络安全中的防御用途越来越多的研究探索LLM如何支持语言密集和上下文依赖的安全分析任务包括安全调查辅助、叙述总结和解释。例如HuntGPT将异常检测和可解释AI与LLM集成以支持威胁狩猎和面向分析师的信号推理[2]。调查工作同样强调LLM如何在防御任务如分析、分类和知识提取中被探索[31, 33]。最近SOC特定文献开始围绕具体的SOC工作流组织这些能力。Habibzadeh等人提供了一个全面的SOC聚焦调查将LLM用例组织在核心功能周围如告警分类、事件响应支持、日志分析和威胁情报同时强调实际约束包括数据敏感性、评估真实性和可靠性[8]。补充调查早期面向系统的研究考察了LLM如何嵌入SOC工具链。Singh等人评估了多模型LLM与SIEM工作流的集成用于一级分类决策说明了潜在效率增益同时强调当LLM输出影响操作优先级时需要进行仔细验证[28]。Tseng等人针对一个持续的SOC瓶颈——对自然语言CTI报告的重复分析——并提出了一个基于LLM的代理来自动化关键的CTI分析步骤旨在减少情报驱动工作流中的分析师开销[29]。这些工作共同激发我们对LLM在实际SOC实践中如何集成RQ1以及从业者感知到哪些收益和摩擦RQ2的关注。第二方面的工作聚焦于开发者和代码中心的安全工作流。实证评估表明代码助手在实践中可能引入安全风险用户可能接受不安全的建议、误解生成的代码或在时间压力下过度信任输出[26, 21]。这些研究表明LLM可以作为辅助工具有价值但收益与验证实践、用户专业知识和工作流设计紧密耦合。2.2 攻击性用途和原生AI攻击类别先前工作表明LLM集成系统可能容易受到对抗性操纵如恶意提示和知识源操纵且LLM可能降低生成令人信服的恶意内容的成本。我们引用这些文献是为了将更广泛的风险格局置于背景中而非作为我们实证测试的现象。例如提示注入已被形式化并基准测试为LLM应用中的控制平面操纵[17]。RAG增加了对外部语料库的依赖[15]使得知识污染攻击如PoisonedRAG在某些条件下可以通过污染检索语料库的部分来引导生成[34]。其他工作强调了LLM使能的大规模攻击性内容生成如钓鱼邮件[24]、跨模型越狱式鲁棒性失败[27]以及受约束设置中代理工具使用配置的风险[6]。相比之下我们的基于访谈的证据聚焦于SOC工作流中的非对抗性操作可靠性失败——不正确或弱扎根的输出、提示到提示的可变性以及安全使用LLM生成的草稿和初步线索所需的验证负担——将对抗性风险视为背景动机而非测量的结果或贡献。2.3 本研究的定位现有工作已经考察了LLM可能在哪些方面帮助防御者包括SOC调查和早期SIEM/CTI自动化原型[8, 28, 29]以及这些系统可能引入的风险。然而这些文献主要强调技术解决方案和受控基准而对从业者经验、感知和组织准备给予较少关注。先前的定性SOC研究也描述了工作流和采纳障碍但通常止于产生LLM特定的、工作流扎根的指导。我们的研究通过贡献三个面向部署决策的从业者衍生工件来扩展此文献i一个失败模式分类法ii一个幻觉缓解成熟度评分量表以及iii一个连接任务类型与失败模式、验证负担、成熟度先决条件和更安全集成模式的SOC集成约束矩阵。尽管幻觉、提示敏感性、验证负担和持续人类监督需求等担忧与先前文献一致但我们的贡献在于展示它们如何在SOC工作流中具体出现——其中输出在时间压力下产生必须可追溯到日志或威胁情报源等证据并受治理要求约束。在此环境中问题不仅是LLM输出是否可能错误而是哪些任务可以安全地保持草稿导向哪些失败最难快速检测以及更广泛部署前需要哪些控制。我们的经验主张限于SOC工作流中的非对抗性操作可靠性失败对抗性操纵仅作为背景讨论。目标是支持负责任的部署帮助团队管理与安全要求一致的幻觉相关风险。3 方法论为调查我们的研究问题我们对20名从事SOC活动的网络安全专业人士进行了半结构化访谈。我们的目标是捕获关于LLM在安全运营中集成的实际使用、感知收益、挑战和组织准备的多样化视角。参与者被特别选择因为他们有在运营SOC环境中使用、管理或研究安全工具的直接经验。3.1 半结构化访谈每位参与者完成了一次30分钟的在线半结构化访谈以英语进行。访谈由三个主题部分组成直接与我们的研究问题对齐。最初参与者描述了LLM在其SOC工作流中的集成和使用RQ1。随后他们讨论了基于LLM的工具与替代方法相比的相对收益和局限性RQ2。最后我们考察了参与者对组织准备以及用于处理LLM输出中幻觉的策略的感知特别强调信任影响和缓解方法RQ3。为保持一致性我们制定并遵循了标准化的访谈协议包括介绍、同意过程、清晰且非引导性的问题以及访谈后补偿程序。在数据收集前访谈指南由一位不在作者团队中且具有SOC相关经验的网络安全专业人士独立审查以评估问题清晰度、术语和领域适当性指南据此修订。此外我们在正式数据收集前使用访谈指南进行了一次试点访谈并用它来完善问题措辞、流程和时长。3.2 参与者招募参与者于2024年6月至12月通过专业网络和平台特别是LinkedIn以及个人推荐招募。符合条件的候选人至少有一年的实际SOC经验年满18岁并积极参与网络安全运营。我们不要求具备AI或LLM的明确专业知识这使我们能够纳入反映更广泛SOC格局的多样化视角。此招募策略类似于网络安全中先前的定性研究[20, 5, 1]这些研究有低于20名参与者我们不声称基于样本量我们的发现是可推广的。相反我们使用数据来突显突出的新兴主题和概念。所有访谈在参与者同意下录音并由符合GDPR的专业服务机构逐字转录。每位参与者在完成后获得50加元的电子礼品卡。参与者人口统计总结在附录D的表4中突出显示了我们的样本中代表的各种角色、经验和组织背景。3.3 数据分析访谈录音由符合《通用数据保护条例》GDPR的专业服务机构逐字转录并使用Braun和Clarke的主题分析阶段熟悉、生成代码、搜索/审查主题、定义/命名、报告进行代码本主题分析[4]。两名研究人员独立编码初始子集5次访谈以开发共享代码本比较解释并调和差异。然后每几次访谈后在保留批次上使用Cohens κ估计评分者间信度IRR解释遵循Landis和Koch[14]。编码迭代进行定期更新代码本当一致性低于我们的阈值κ 0.80时我们通过讨论解决差异完善代码定义并在需要时对早期转录进行回溯拟合。经过五轮编码主题类别间的一致性稳定在κ 0.80。在保留转录上子代码级别计算的Cohens κ在各轮中从κ0.81提高到0.88[第1轮0.81第2轮0.83第3轮0.85第4轮0.86第5轮0.88]。最常见的分歧是数据泄露/模型诱导与提示/模型滥用之间的边界案例。与我们的招募理由一致我们在分析期间监测代码和意义饱和在第15次访谈后未观察到新的实质性代码继续到N20以加强意义饱和。我们将饱和定义为最后五份转录中没有新的子主题或维度出现且代码定义没有变化[10]。最终代码本、示例引用和IRR统计出现在附录C表2和表3中。根据附录E的表1为展示我们主题发现的内部鲁棒性我们通过追踪每个代码在参与者批次中的首次出现进行饱和审计。我们将饱和定义为一批五次访谈未产生新的顶层主代码且少于5%的新子代码的点。表1按参与者批次的代码饱和度访谈批次新主代码新子代码累计代码数最终编码手册百分比P01–P051410812282%P06–P1001814094%P11–P1509149100%P16–P2000149100%所有14个主主题类别如挑战与局限、适应性、与基于规则的比较在前五次访谈中建立。在第2批和第3批之间新子代码的出现从18降至9主要包含利基工作角色或特定工具名称而非新的概念挑战。在最后一批P16–P20中没有新的代码或维度被添加到代码本确认我们的N20样本足以捕获此区域SOC生态系统中从业者经验的广度。我们将参与者分类为LLM用户如果他们报告了任何工作场所LLM使用包括偶尔或低强度使用。报告没有工作场所LLM使用的参与者标记为“不适用”因为缓解成熟度评分量表对他们不适用。来自没有批准的工作场所LLM使用的参与者的陈述被视为感知或间接暴露不用于推断运营部署。对所有主题发现个体参与者N20是主要分析单位。虽然参与者代表13个不同的组织但他们报告的经验反映个体角色和特定子团队。因此成熟度级别和使用模式在参与者级别分类以捕获较大组织内实践的异质性。当某个指标在组织级别报告时如第4.1节的人口统计会明确注明。研究人员立场。 研究团队在网络安全研究和SOC邻近问题设置方面有经验这为访谈协议的框架和对从业者术语的解释提供了信息。为减少解释偏差我们使用了独立编码、迭代代码本完善和整个分析过程中的共识调和。3.4 局限性我们的研究有几个定性工作典型的局限性。首先虽然半结构化访谈能够深入但回应细节因后续探询对参与者不完全统一而有所不同核心问题被一致覆盖但某些主题比其他主题有更丰富的叙述证据。与大多数基于访谈的定性研究一样我们的发现反映参与者的叙述而非对工作流的直接观察造成自我报告和社会期望效应的可能性。其次样本在地理上集中20人中有19人在加拿大安大略省1人在美国加利福尼亚州。尽管参与者代表了不同规模的组织表4但我们不声称具有全球代表性也没有在自我描述的角色和背景之外系统控制SOC成熟度。因此结果应被视为早期LLM使用的深入区域快照和基于实践形成的假设而非行业范围的基准。性别作为人口统计变量收集16名男性4名女性但由于样本量小从表4中省略以保护参与者匿名男性参与者的性别不平衡可能限制所捕获视角的广度。第三保密性和NDA意味着我们不要求披露LLM供应商、模型版本、部署模式托管与本地或微调因此我们无法将模型/部署特定效应与更广泛的采用模式分开我们的发现捕获使用模式和从业者感知而非跨模型的比较性能。第四这些发现时间戳为2024年中后期在更集成的代理工作流和广泛的接地成为常见之前虽然工具可能快速演变但SOC治理和验证通常变化较慢因此我们将我们的主题框架为未来纵向研究的基线。此外我们的编码框架允许通过多标签编码使失败模式共现但共现报告不是本文预先指定的目标。因此我们在此不量化共现频率将最常见的共现对的系统分析留待未来工作。最后我们不测量运营KPI如事件响应时间、FP/FN减少、检测提升主张仅限于基于访谈的实践描述和感知效用通常以验证为条件。3.5 分析三角验证和鲁棒性检查我们采用了两种内部鲁棒性检查以确保我们的发现不受我们初始分析视角的偏见负例分析 虽然大多数参与者报告了沉重的验证负担但像P12和P17这样的异常值突显了一个关键的边界条件LLM效用高度依赖于任务。在代码中心的生成任务中如起草过滤逻辑或Python脚本从业者经历了最小的摩擦因为输出可以通过执行测试和语法检查等技术工具快速证伪。相反对于调查或叙述驱动任务——如事件推理或归因——怀疑仍然很高因为错误通常看起来合理且难以快速验证需要更重的人类判断。敏感性分析 为确认我们的结论不是呈现结构的伪影我们使用两种替代组织镜头重新聚合了编码片段i任务/工作流镜头第4节和ii评估标准镜头第5节。我们将任务/工作流镜头作为主要使用评估标准仅作为参与者如何证明信任和感知效用的支持性组织。跨越两种镜头核心结论保持不变感知的LLM效用在文本中心、草稿导向的任务中最高而采纳受到验证负担和对决策级输出的有限信任的瓶颈制约。4 结果工具使用RQ1在本节中我们首先概述参与者的专业背景然后呈现在SOC工作流中如何集成基于LLM的安全工具的发现使用LLM输出失败模式即不正确或不可信的输出作为理解此集成中准备和信任的中心镜头。我们的结果反映两种基于访谈的证据i报告的做法参与者表示他们当前如何在SOC工作流中使用LLM包括他们生成什么工件以及如何验证和ii感知参与者报告的收益、成本和信任判断。我们不评估决策级运营结果如检测提升、假正减少或事件响应时间减少。因此本节中的“有效性”和“效率”等术语指参与者报告的感知效用和工作流支持通常以验证为条件。4.1 参与者背景和人口统计表4总结了20名参与者的入口统计和专业背景涵盖多样化的网络安全角色一线分析师、SOC经理、威胁响应工程师、数据科学家和高级领导层拥有1.5–25年的经验。我们将参与者分类为SOC专业人士如果他们的主要工作涉及日常SOC运营如分类、事件响应、检测工程或SOC管理以及安全研究员如果他们主要在研究/RD工作但在过去12个月内有直接的SOC工作流参与没有运营SOC参与的纯学术研究员被排除。参与者的专业知识范围从仅防御到攻防结合实践具有不同的方法论偏好基于规则、AI驱动/ML/LLM或混合以及广泛的AI经验从概念熟悉到动手模型开发。样本在地理上集中20人中有19人在加拿大安大略省1人在美国加利福尼亚州来自13个组织涵盖内部企业SOC、公共部门SOC、MSSP/提供商和安全产品供应商跨越所有规模区间——小型50–249、中型250–999、大型1,000–9,999和超大型≥10,000为保护匿名我们报告规模区间而非确切员工数且没有单一组织主导样本。4.2 常见用例和上下文依赖跨参与者类别四个用例一致出现日志总结、初始事件调查支持、文档起草和检测规则完善。我们不是仅将其视为任务类型而是根据参与者叙述将每个表征为具有可识别入口点、决策门和转换条件的工作流段。日志总结。 入口是由量驱动的当日志工件超出可在分类速度下手动解析的范围时分析师调用LLM如P09, P10。在提示总结后他们应用快速合理性检查将输出与原始日志的抽查进行比较然后决定升级、关闭或继续。证伪条件是快速且具体的“这个实体在原始日志中吗”这解释了为什么参与者报告此任务的验证负担低。分类指导。 第二个入口点是对告警类型不熟悉。分析师如P13描述提示首步调查步骤然后根据内部操作手册过滤输出保留有可用遥测支持的步骤丢弃与已知安全行为矛盾或缺乏日志证据的步骤。LLM输出作为头脑风暴支架而非可执行操作手册每个建议步骤在执行前需要独立论证。检测规则起草。 工程师如P04, P12在检测差距已被识别后调用LLM提供自然语言描述或可疑日志摘录并接收候选查询或规则片段。即时决策门是语法的linting或沙箱执行以确认操作符和字段有效性。通过的规则在同行审查和生产推广前进行历史流量回溯测试。失败包括FM2案例LLM发明不存在的操作符P04触发手动修正或提示修订。CTI和报告综合。 研究人员如P07, P19在从多个源聚合情报后调用LLM提示TTP提取或结构化总结。决策门是交叉引用提取的指标在运营使用前对照内部威胁情报平台或MITRE ATTCK检查。P07描述将提示限制在提供的源文本以减少推理驱动的捏造。一个一致的结构模式在所有四个案例中出现LLM在现有工作流的特定交接点被调用其输出在采取任何下游行动前通过人工操作的决策门。该门的可行性因此实际的验证负担取决于输出类型是否允许快速、具体的证伪条件。此结构激发了附录F中SOC集成约束矩阵中的验证负担和成熟度先决条件映射。5 结果感知RQ2我们请参与者描述他们对将基于LLM的工具集成到SOC工作流中的经验和感知特别关注感知的收益和挑战。从我们访谈的主题分析中五个不同的评估标准一致出现有效性、可用性、效率、适应性和信任。下面我们详细阐述参与者对这些标准的见解特别强调突出的主题。5.1 有效性有效性指LLM生成准确且上下文相关输出以支持运营安全任务的能力[32]。参与者一致描述了在某些SOC任务中的感知工作流收益特别是输出为草稿导向且可快速验证的地方。5.1.1 LLM在文本中心任务中表现出色参与者20人中的13人的主导感知是LLM可以通过减少总结日志和报告、起草标准化检测内容以及生成文档所涉及的时间和手动工作在文本密集型SOC任务中提供有用的工作流支持。例如P09描述在LLM辅助下重写检测规则“比手动起草快得多”同时仍将输出视为需要审查的草稿。参与者进一步建议自动化常规语言相关任务可以使分析师将注意力重新转向需要人类专业知识的更复杂活动。我们将这些叙述解释为参与者报告的感知效用和工作流支持而非性能改进或运营生产力增益的直接证据。5.1.2 检测工程支持中的新兴用途一部分参与者描述了使用LLM进行检测工程支持其中模型帮助分析师起草和完善可能随后输入现有检测工作流的工件。报告的使用包括从日志摘录中提取显著字段、起草分类检查清单以及生成候选查询/规则片段或调查步骤。较小的子集讨论了LLM从日志片段提出候选检测想法的实验性试点但这些输出被一致地框架为建议在运营采纳前需要严格的人类验证和常规回溯测试/审查。总体而言参与者将LLM视为加速早期起草和假设生成而非替换检测流水线或分析师判断。三名参与者还提到LLM直接从日志摘录或可疑数据点建议检测的实验性部署再次这些建议被普遍描述为在接受前需要严格的人类验证。一起发现表明LLM正在谨慎但不断增长地融入SOC检测工作平衡自动化速度收益与持续准确性关注以及分析师监督的持续必要性设想的模型是LLM工具增强而非取代人类分析师。5.2 可用性可用性指SOC分析师能在其现有工作流中有效交互和配置基于LLM的工具的容易程度[35]。虽然参与者普遍欣赏与传统的、专业ML工具链相比聊天式界面的直观性但他们也强调了关键的可用性挑战特别是与提示工程和输出透明度相关。5.2.1 可访问界面加速上手参与者广泛认可对话界面的可访问性和直观使用特别是突显了广泛可用的平台如ChatGPT。七名参与者明确赞扬了用户友好特性如对话历史、自然语言提示和关于潜在不准确性的主动免责声明。另有四名参与者报告主要通过集成的、基于供应商的安全平台如Splunk、Microsoft Defender与LLM输出交互欣赏LLM功能在熟悉的安全仪表板内的无缝嵌入。一个经常被引用的优势n3是启动与基于LLM工具交互所需的最小技术设置。参与者描述了制定初始查询、检测规则或摘要的显著易用性无需自定义代码。例如P12强调了此可用性优势“我不需要编写复杂的过滤器我只描述我想要什么工具就起草它。”易用的界面降低了采纳障碍使快速上手成为可能并减少了起草和探索性任务如撰写初始摘要或首遍规则/查询草稿的障碍特别是对于能快速验证输出的分析师。5.2.2 提示工程的挑战尽管初始易用八名参与者强调了提示工程作为关键可用性挑战。他们指出模糊或指定不充分的提示经常导致过于通用或不相关的输出需要重复调整或澄清。P07强调了将真实世界示例或日志摘录直接纳入提示的有效性指出这种做法显著提高了输出准确性。此发现表明LLM界面的表面简单性与制定有效提示所需的微妙技能之间存在固有张力。虽然基于聊天的交互模型看起来直接但实现一致、相关的结果在很大程度上取决于分析师领域知识和精确查询表述。因此基于LLM工具的集成和持续可用性的成功在很大程度上取决于分析师的专业知识及其对有效提示技术的熟悉程度。5.2.3 不透明推理阻碍采纳七名参与者提出了与LLM推理过程不透明相关的显著可用性担忧。与基于规则的检测方法其中触发的规则明确阐明为什么生成某些输出不同LLM输出通常在没有清晰理由或可追踪推理的情况下呈现。P05生动地描述了此担忧“使用基于规则的系统至少我们知道哪个规则触发了。LLM只是给出一个答案我并不总是确定为什么。”这种不透明性经常迫使分析师进行额外的手动验证——检查日志、查阅历史记录或试图推断生成输出背后的理由。这种缺乏透明度不仅阻碍了对LLM生成结果的信任还可能减慢事件响应时间限制整体运营效率。总之虽然基于LLM工具的初始可用性被积极看待但实际采纳受到有效提示工程和输出透明度相关挑战的显著影响。通过改善用户培训、更清晰的解释机制或增强界面设计来解决这些问题可以显著提高这些工具在SOC环境中的可用性和运营效用。5.3 效率效率指基于LLM的解决方案如何帮助分析师以最小的时间、数据和计算开销完成安全任务[32]。参与者一致强调了感知的效率增益——特别是在自动化重复任务方面——但也强调了在验证开销方面平衡这些增益的重要性。5.3.1 重复任务的时间节省和工作量减少大多数n13参与者强调了LLM辅助在常规、语言密集型SOC任务如日志总结、事件文档和安全简报中带来的显著时间节省。例如P16指出先前“需要一两个小时来汇编”的电子邮件安全摘要现在“在几分钟内”生成。三名参与者明确提到了工作量减少表明LLM有效减轻了日常任务的负担使他们能够更专注于复杂调查。尽管有这些优势参与者承认有效的提示工程仍然是确保LLM生成输出的连贯性和相关性所必需的。这些叙述表明参与者在特定任务中感知到工作负载缓解特别是输出可快速验证的地方。5.3.2 超越文本总结的自动化潜力除基于文本的任务外五名参与者认识到LLM促进半自动化脚本编写和调查工作流的潜力。例如P17描述了使用LLM生成的Python代码片段进行快速日志分析在其工作流中减少了手动编码工作以验证为条件。类似地P13提到LLM有效地起草了“首遍分类步骤”使团队能够专注于更深入的取证分析。尽管如此所有使用此类半自动化工作流的参与者都强调了人类审查的重要作用因为自动输出中持续存在不准确和逻辑错误的风险。这突显了一个新兴的混合模型其中LLM加速初始任务阶段但需要分析师主导的验证平衡效率增益与准确性要求。5.3.3 验证开销可能侵蚀效率增益尽管对加速内容生成总体满意若干参与者表达了对相关验证负担的担忧。P04明确表示“我们节省一个小时起草规则但花半小时验证每一行。”这种开销在关键情况下——如近实时事件响应或高可见性报告——变得尤为突出其中彻底验证至关重要。许多参与者描述将LLM输出与内部程序或历史验证规则交叉引用以降低风险。此验证必要性突显了LLM在安全中部署的一个基本方面虽然速度优势明确持续的人类监督仍然至关重要。因此参与者通常将效率收益视为取决于他们快速识别和纠正偶发不准确性的能力特别是在低风险上下文中。5.4 适应性适应性描述基于LLM的工具无缝集成到现有组织流程并有效响应不同运营上下文的能力[32]。虽然参与者认识到LLM的总体适应性但他们强调了在面对新颖或高度专业化的安全场景时的显著局限性。5.4.1 跨数据源和任务的灵活性若干参与者n6积极评估了LLM跨多样化SOC任务和数据源的适应性包括资产风险评分、总结告警和综合漏洞指标。例如P17成功将LLM输出与内部分类数据集成指出模型“在给予正确输入时能轻松在不同环境间切换”。然而两名参与者澄清有效的适应通常需要来自知识渊博的分析师的显著领域特定输入和仔细的数据策划。这表明LLM适应性在很大程度上依赖于持续的分析师输入突显了领域专业知识和主动上下文提供在维持成功部署中的重要性。5.4.2 面对新颖或专业威胁的局限尽管总体多功能四名参与者对LLM在面对新颖或专业威胁如缺乏历史参考的零日漏洞时的性能退化表示担忧。P19描述“当面对全新零日或我们只有最小情报时LLM被迫猜测有时猜测是错误的。”因此在高度专业化的场景中LLM预测经常变得容易出错。参与者指出了两种主要策略来缓解此问题快速用专业威胁数据补充模型或恢复到手动调查。然而三名参与者对资源约束表示担忧指出持续微调模型以应对新兴威胁昂贵、耗时且经常受内部专业知识限制。5.4.3 组织障碍和数据政策除技术考虑外七名参与者指出了影响适应性的显著组织障碍。挑战包括合规性法规、数据治理政策、供应商审批流程和领导层犹豫。P15将部署内部LLM描述为“多层迷宫”需要法律、隐私和合规团队的广泛批准。相反两名参与者指出当高级管理层明确支持AI倡议时采纳更顺畅促进更快的试点和实验。预算约束进一步影响适应性P07观察到频繁的模型微调成本高昂导致一些组织仅依赖通用、供应商训练的模型。因此实际适应性不仅取决于技术灵活性还取决于组织结构、资源可用性和政策对齐。5.5 信任信任指用户对LLM输出可靠性和事实准确性的信心特别是关于对不准确和捏造信息的抵抗[32]。参与者一致将信任视为影响SOC环境中LLM采纳的关键因素。5.6 LLM输出失败模式分类法我们超越将幻觉视为单一问题定义了一个在SOC工作中观察到的LLM输出失败模式的从业者扎根分类法完全基于我们的访谈语料库。我们聚焦于产生不正确、无根基、无效或难以验证的输出的失败这些输出可能在常规SOC任务中被采纳如检测起草、解释可疑活动、调查指导。分类法反映从业者描述的故障和验证负担并有意排除对抗性威胁如提示注入除非参与者报告了第一手事件。使用关于信任失败和不正确输出的编码片段我们识别了七种失败模式并通过“若被采纳的后果”评分量表分配严重性低浪费时间/轻微混淆、中误导分类/调查和取证拖延和高看似合理的漏检、错误升级或不安全操作如阻断合法流量。这些严重性代表概念上的潜在后果而非我们研究中观察到的实际影响。附录表5附录E报告了带有包含/排除标准和代表性证据的分类法。为可复现性我们使用主题片段描述特定失败事件的句子组作为分析单位并对复合失败应用多标签编码如FM1 FM5。附录表9附录E.1总结了跨参与者的覆盖和基于角色的显著性。总体而言此分类法阐明了从业者在SOC环境中描述的幻觉涵盖了若干不同的失败模式每种具有不同的操作结果。这种结构化方法通过将缓解措施如FM2的模式验证或FM1的RAG与特定失败类别而非不可量化的信任概念相关联实现了更精确的建议。5.6.1 人类监督的重要作用几乎所有参与者n15明确强调了持续人类监督的必要性。虽然许多参与者描述了在特定任务中LLM辅助带来的感知工作流收益但参与者坚持认为人类判断对于验证输出是不可或缺的。P08简洁地表示“LLM是助手永远不是最终权威”反映了一种普遍情绪即分析师必须彻底审查LLM生成的检测、总结和建议。这种对人类监督的强调与网络安全中新兴的最佳实践一致将AI驱动的加速与专家人类审查相结合。参与者描述了一种使用模型其中任何潜在的工作流收益取决于保持分析师在循环中以验证输出并防止错误传播。总之虽然参与者认可LLM提供的感知运营效用但他们仍对完全将AI托付给关键安全决策任务保持谨慎。近期信任似乎根本上取决于能够管理当前LLM技术固有不确定性的强健监督和验证程序。6 结果准备度RQ3在本节中我们考察参与者如何描述其SOC工作场所上下文管理与LLM输出相关的幻觉相关可靠性风险的准备度利用第5.6节附录E表5引入的失败模式分类法。我们的发现反映参与者报告的做法分析单位参与者N20而非组织级成熟度估计。虽然参与者广泛承认这些风险是可信赖集成的核心障碍但他们描述了一套碎片化的准备实践正式化对策有限严重依赖人类验证。非采纳作为边界条件。 在我们的语料库中非采纳在分析上有意义而非简单的未使用。报告没有批准的工作场所LLM使用或描述其团队中非采纳的参与者将该边界与对输出可靠性的担忧、缺乏处理敏感数据的批准途径、关于如何在运营环境中使用此类工具的治理限制以及效率增益是否值得额外验证负担的不确定性相关联。因此我们将非采纳解释为早期SOC采纳中有限准备条件的证据而非缺失案例或缺乏相关性。运营风险模型。 为使我们的安全框架明确且可从访谈证据证伪我们将幻觉风险操作化为在SOC任务期间使用的LLM输出的一组可观察结果类型。当输出表现出以下一项或多项时我们将其视为失败i捏造的事实/实体如虚构的事件细节或不存在IOC/TTPii模式或工具无效的工件如无效的检测规则语法或发明的操作符或iii误导性程序建议如不正确的一级分类步骤或增加验证负担或错误引导分析调查指导。当失败足够合理以被采取行动或被视为线索或当它通过返工和验证造成分析师时间浪费或将错误传播到不正确的调查步骤、草稿规则或报告内容时它在操作上变得有后果即在风险意义上“成功”。重要的是我们不测量事件影响或业务损失也不评估攻击者适应或对抗性鲁棒性相反我们报告从业者描述的失败模式及其在运营环境中使用的缓解实践。附录E的表6总结了这些结果类型、使它们在实践中具有风险的操作后果以及参与者报告的缓解实践。6.1 关于幻觉的一般观察参与者一致将幻觉视为与基于规则系统或传统ML模型生成的假正不同的独特操作失败模式。具体而言他们指出LLM可以捏造广泛的叙述——如事件细节、虚构的妥协指标或不存在的战术、技术和程序TTP——对SOC工作流构成显著风险。P06简洁地捕捉了此情绪“我们大多数人都知道LLM可以编造东西但我们不确定如何系统预防。我们当前的方法基本上是‘睁大眼睛希望没有初级人员按字面接受。’”虽然参与者普遍避免让LLM输出在没有人类监督的情况下直接影响高风险决策但缺乏自动化或强健的验证过程经常导致手动、资源密集的分类工作。这些叙述直接映射到表6中的操作结果类型强化了我们研究的风险是基于可观察的工作流失败而非对抗性威胁覆盖。6.2 处理幻觉的具体策略参与者报告采用了若干不同的策略——从非正式手动验证到实验性自动化解决方案——以解决幻觉风险。下面我们根据其普遍性和成熟度总结这些策略。6.2.1 无正式缓解方法超过三分之一n8的参与者报告在其直接工作环境中他们没有观察到任何管理幻觉的形式化策略。相反幻觉被临时处理依赖分析师判断和手动交叉检查。P14例证了此方法“如果我们看到不符合日志或感觉不对劲的东西我们只知道要质疑它。”参与者将缺乏结构化方法归因于有限的组织资源、对自主AI的风险规避以及关于有效缓解实践的不确定性。因此幻觉识别在很大程度上取决于分析师的警惕和直觉而非定义的程序进一步增加了高级分析师的工作量和验证负担。6.2.2 严重依赖人类监督报告的最常见方法n10涉及广泛依赖人类监督。分析师经常将可疑的LLM生成输出与内部知识库、日志存储库和外部威胁情报平台交叉引用。P09总结了此实践“我们没有自动安全网因此我们将LLM输出视为线索而非结论。”分析师将自己描述为人类验证者负责手动验证和纠正可疑输出参与者承认这是一个资源密集型过程降低了最初从LLM驱动自动化中预期的效率收益。6.2.3 提示完善三名参与者明确讨论了提示完善作为主动最小化幻觉的有效策略。这些参与者不是让LLM无限制地自由生成叙述而是精心制作提示以约束响应——例如使用具体指令如项目符号或将内容仅限于提供的数据。P07指出当明确指示模型时错误显著减少“我告诉LLM‘永远不要假设我们未在日志中提供的任何东西’错误率急剧下降。”然而参与者承认此方法增加了分析师的认知负担因为有效的提示工程需要超出典型SOC分析师能力的专业技能。6.2.4 自纠正循环少数参与者n2报告了尝试使用自纠正循环其中LLM审查和评估其输出以识别不一致或矛盾。虽然这些方法偶尔标记逻辑错误但参与者对仅依赖单一模型进行自我验证持怀疑态度警告“它可能第二次幻觉。”然而他们建议将自纠正循环与来自可信来源的RAG结合可能提供未来潜力。6.2.5 置信度因子和跨模型检查少数参与者探索了涉及置信度分数或多模型交叉检查的高级验证方法n2。一名参与者将LLM生成的置信度指标与SIEM元数据集成另一名倡导并行查询多个LLM以检测矛盾输出。例如P17表示“如果我的本地LLM说一个IP是恶意的但ChatGPT说是良性的我会进一步调查。”虽然这种冗余偶尔识别不准确性参与者承认此方法是资源密集型的且不能完全防范跨模型一致的幻觉。6.2.6 与既定标准对齐一名参与者明确尝试通过参考公认的安全框架如MITRE ATTCK或NIST指南来验证LLM输出。如果LLM生成的信息缺乏与这些标准的可识别链接分析师将输出视为可疑。然而此方法需要持续的手动验证正如参与者所指出的“我仍然需要检查它给我的MITRE技术ID是否是捏造的。”6.2.7 结构化输出验证两名参与者描述了旨在针对权威数据模式或内部数据库验证LLM输出的早期阶段倡议。一人使用脚本自动将IP地址、主机或文件哈希与可信内部数据库交叉引用。另一人将LLM响应转换为结构化JSON以进行自动模式验证防止语法错误或不存在的操作符渗入SOC工作流。虽然这些结构化验证有效地捕获了基本语法级错误但参与者承认更深层的事实不准确性仍需要人工审查。6.3 幻觉缓解成熟度评分量表我们定义了一个幻觉缓解成熟度评分量表以用基于记录证据的幻觉缓解实践分类替代非正式准备评估附录E表7。使用参与者作为分析单位N20我们对每个参与者描述的约束、验证和管理LLM输出的实践如提示约束、审查门、自动检查进行编码并将其分配给他们明确描述为常规实践个人或作为组织/团队程序的最高成熟度级别。评分量表涵盖四个级别L0 临时个体验证L1 共享但未记录规范如常规手动交叉检查L2 至少一个已记录、一致使用的预防性护栏如提示库/模板或仅证据提示L3 至少一个超出手动审查的主动、可审计控制如自动验证脚本、模式验证、正式法律/合规签署门或验证审计日志。没有活跃工作场所LLM使用的参与者因此无法评估缓解标记为“不适用”并从准备声明中排除。应用此评分量表揭示了向较低成熟度级别倾斜的分布级别1最常见30%n6其次是级别020%n4。较少参与者报告与级别215%n3或级别320%n4一致的实践。三名参与者15%n3报告没有工作场所LLM使用因此标记为不适用表7。每个级别反映其记录描述与该级别一致实践的参与者比例不应解释为跨13个组织的组织级准备度估计。6.4 分层分析按角色的运营视角为提供可操作的设计启示我们对四个关键专业角色的发现进行了分层分析这些角色在我们的元数据中识别一线分析师、技术工程师、安全经理和工具开发者/研究员。表8总结了这些角色在使用、风险感知和缓解优先级方面的差异。研究得出结论一刀切的AI策略对安全中心无效因为不同角色需要不同的工具功能。要成功设计者必须解决三个关键领域平衡分析师对速度和来源的需求与管理层对政策合规和隐私的需求区分适合AI的任务——如生成性报告起草验证容易——和高风险调查推理AI不透明仍是障碍以及提供角色特定功能如分析师的并排数据比较和领导层的审计追踪。这些专门的重点领域对于应对当前挑战和安全运营中AI-人类协作的未来演变至关重要。6.5 决策级综合SOC集成约束矩阵本小节为SOC设计师引入了一个单一可操作工件SOC集成约束矩阵附录F表10。该矩阵通过将常见SOC任务类型映射到i主导失败模式FM1–FM7、ii验证负担低/中/高、iii所需最低缓解成熟度L0–L3和iv安全集成模式如仅聊天草稿、模板模式验证、门控部署来总结设计约束。它仅由编码访谈证据填充两名编码员独立执行映射并通过与主题编码相同的共识协议解决分歧不明确的情况标记为“证据不足”而非外推。矩阵突显了一个关键边界具有快速可证伪输出的任务如脚本/规则可以以较低的验证努力集成而叙述/调查决策支持需要更高的成熟度控制和更强的门控因为错误更难快速检测。7 讨论本研究考察了LLM在SOC中的集成提供了对从业者感知和使用的见解。虽然LLM在自动化文本密集型任务方面显示出潜力但我们的发现揭示了关于可信度、透明度和幻觉的显著担忧。一些观察可能是时间敏感的如特定产品集成或接地功能。然而参与者提出的时间稳定问题——验证开销、对输出的责任以及LLM建议可以安全进入工作流的位置——由组织过程塑造即使工具发展仍然相关。我们讨论关键含义将发现置于现有研究背景中并为部署LLM驱动的安全解决方案提供建议。我们的若干发现与更广泛LLM可靠性和AI辅助工作流文献一致特别是关于幻觉、提示敏感性、验证负担和对人类监督持续依赖的担忧。在SOC环境中似乎特别突出的是这些问题与操作时间压力、需要将主张追溯到日志、规则或威胁情报证据以及关于模型生成内容如何进入检测和响应管道的治理约束的组合[3, 25, 19]。这些因素有助于解释为什么参与者对将LLM用于可快速验证、草稿导向任务比对用于调查推理或更高风险决策支持更放心。如何在实践中使用这些工件。 这些工件支持三个决策点工程师/负责人使用约束矩阵选择安全的SOC用例管理层使用成熟度评分量表基于护栏门控部署分析师在调查期间使用失败模式分类法指导LLM输出的验证和升级。7.1 解决实际障碍数据、集成和组织障碍观察实践 参与者描述采纳通常受数据治理、集成开销、资源和部署成本的约束这可能在完全运营集成之前停滞试点。表达需求 他们想要更清晰的合规路径和可靠的内部流水线使SOC特定接地可行而无需依赖临时、逐例例外。我们建议 将LLM采纳视为数据与治理项目而非仅是模型选择决策。近期努力应优先构建可审计的数据流水线在明确的访问和使用规则下捕获和管理日志、威胁情报源和分析师注释并与法律和合规利益相关者密切协调。相关的分散日志分析研究说明了解决此张力的一种潜在架构。Federated LogTracer提取上下文关系并识别恶意日志同时将敏感遥测保留在本地而非整合到中央分析服务器[23]。虽然我们的访谈研究未评估此架构但它展示了如何在隐私和数据位置约束下追求SOC特定情境化。对于探索模型本地化的组织我们建议评估迭代精炼方法如人在回路更新/主动学习[18]和面向效率的微调策略如分数微调[12]作为降低运营成本和隐私摩擦的选项同时明确指出我们的访谈研究未评估其在现场的有效性或成本效益。最后我们建议执行赞助商和SOC领导层预先定义数据权利、隐私政策和试点过渡到持续运营工具所需的基础设施承诺。7.2 在高风险安全任务中缓解幻觉观察实践 参与者主要通过人在回路验证和对照日志、指标和内部知识交叉引用管理不正确输出。表达需求 他们想要减少验证拖累的缓解措施同时使输出是接地还是推测更清晰。我们建议 评估符合这些需求的分层缓解设计i使用对策划内部/CTI源的检索来接地输出如RAG作为将溯源附加到主张的方式[15]ii跨模型或常规系统的冗余或交叉检查以标记不一致[30]iii随着上下文和威胁信息变化定期重新验证高影响输出的监控方法[13]。这些是参与者报告激发的建议设计方向我们的研究未实证验证其有效性。7.3 设计可操作解释和工作流集成观察实践 参与者偏好可快速对照熟悉SOC工件如检测规则、已知指标和原始日志检查的简洁输出当验证不清楚时对长叙述接受度较低。表达需求 他们想要在时间压力下操作上可操作且易于验证的解释。我们建议 围绕验证优先解释设计界面提供简短的分类就绪总结加一个向下钻取视图将主张链接到具体证据如引用的日志行、查询结果或CTI项目并在适用时将关键元素映射到公认框架如MITRE ATTCK。我们还建议轻量级反馈渠道如标记/注释输出并捕获“使用了什么证据”以便组织可以迭代地将输出与本地工作流对齐而不假设反馈自动提高可靠性。7.4 操作化人为因素编码分析师资源fulness观察实践 参与者描述了一套操作者主导的护栏——仅证据提示、检查清单驱动分类、对照SOC系统的交叉检查、用于验证的结构化输出以及更高影响行动的双重控制——作为在不消除人类判断的情况下限制不正确输出的实用方式。表达需求 他们希望这些实践可重复和可审计而非依赖个体警惕。我们建议 将这些护栏编码到操作手册和工具中i对提示和响应采用仅证据政策ii为常见分类和起草任务维护策划的提示/检查清单库iii要求具有模式验证和显式溯源字段如引用的日志ID、CTI引用的结构化输出iv对源自LLM建议的高影响行动或变更应用双重控制审查v仪器化轻量级验证日志记录检查了什么以及基于什么证据[11, 16]。这些是基于参与者描述实践的过程和工具方向我们不声称它们消除失败模式特别是在新颖性或时间压力下。7.5 组织成熟度对LLM集成的影响观察实践 参与者描述了显著异质性较小的团队通常依赖商品界面进行一般协助而大型企业/MSSP描述了在更严格治理下在SIEM/XDR工具链内更结构化但仍实验性的集成。此模式与CISO级证据一致显示企业GenAI准备度在上游治理通常比运行时保证更强其中有限遥测和操作程序使检测主要停留在人在回路[22]。表达需求 组织想要匹配其成熟度约束的解决方案低成熟度SOC需要可用的护栏而无需专业AI专业知识而高成熟度SOC需要可审计性和政策对齐。我们建议 开发与评分量表表7对齐的成熟度定制配置。对于较低成熟度环境优先考虑安全默认和有界工作流如仅证据提示、结构化模板和清晰升级边界减少对临时判断的依赖。对于较高成熟度环境优先考虑支持治理控制如访问限制、审计日志和批准门并允许在合规约束下进行受控实验的API驱动集成。我们还建议面向SOC的AI成熟度基准帮助组织自我评估更高自主使用准备度如预期验证开销和问责要求而不暗示本研究中任何特定配置已被验证。8 结论我们对20名安全从业者的研究表明LLM正被谨慎地集成到SOC工作流中主要作为补充工具。参与者报告了在文本密集型任务如总结和起草中感知的时间节省通常以大量验证为条件。然而参与者描述了由于不可靠输出和不透明推理对LLM在高风险安全决策中的有限信任。参与者也很少描述标准化、文档化的缓解程序而是依赖临时验证规范和持续人类监督。总体而言这些叙述指向一个混合现实其中LLM输出作为初步线索或草稿必须使用现有SOC工具和专家判断进行验证。使用在参与者级别应用的成熟度评分量表我们发现准备度不均衡且通常反映非正式实践而非治理过程。未来工作应研究供应商托管部署模型如何在生产SOC环境中塑造隐私、数据驻留和可审计性约束。
评估安全运营中心中大语言模型集成的实际局限性
大家读完觉得有帮助记得关注和点赞摘要大语言模型LLM正越来越多地在安全运营中心SOC中被探索以支持文本密集型分析工作如告警情境化、事件摘要和调查文档起草。尽管存在这种兴趣从业者描述了关键的操作问题尤其是幻觉看似合理但错误的输出、不透明的推理以及在安全工作流中安全使用模型生成内容所需的验证工作。在本文中我们呈现了对20名SOC从业者进行的半结构化访谈结果涵盖一线分析师、SOC经理和工具开发者。参与者报告了在可快速验证的低风险任务如总结日志或起草初步调查线索中感知到的时间节省但他们一致将LLM输出视为初步草稿和建议而非决策级结论。参与者还描述了对LLM在高风险安全决策中的有限信任原因是不可靠的输出和模糊的模型推理并且他们报告主要依赖临时验证规范和持续人工监督而非标准化的缓解程序。基于这些访谈扎根的叙述我们引入了一个成熟度评分量表来表征LLM集成的准备程度并概述了一个研究议程强调可审计性和透明解释机制以支持在SOC工作流中更安全地采用LLM。1 引言安全运营中心SOC面临着来自日益增长的告警、日志和事件工件的数量和复杂性的持续超负荷。传统的机器学习ML技术可以支持狭窄的分类和异常检测任务如入侵检测、恶意软件分类和威胁关联[20]。然而这些方法通常止步于将事件标记为恶意或良性并不能一致地提供在时间压力下快速、可辩护的分析师决策所需的上下文、人类可读的解释。大语言模型LLM最近被定位为一种有前景的回应能够总结异构事件数据、生成人类可读的解释并以易懂的术语生成草稿响应[31]。这种能力超越了检测LLM可以将技术证据转化为叙述和候选的后续步骤供分析师审查、完善和沟通。鉴于分析师疲劳和网络安全技能短缺这种自动化潜力对许多组织具有吸引力。Gartner最近的一项调查反映了行业对生成式人工智能GenAI日益增长的兴趣约55%的公司正在试验此类技术然而只有约10%报告了生产部署表明对操作可靠性和可信度存在持续担忧[7]。大多数关于网络安全中LLM的先前工作集中在能力评估、基准风格研究或对机遇和风险的广泛调查上。相比之下关于LLM如何在实际SOC工作流中使用、当输出被视为调查线索或草稿工件时会出现哪些工作流扎根的失败模式以及验证输出和在实际操作中减轻幻觉风险需要哪些组织准备我们知之甚少。在运营SOC环境中失败可能难以快速检测模型可能产生看似合理但不正确的陈述、无效逻辑或难以验证的解释。即使是偶发错误也可能侵蚀信任并产生昂贵的返工因为从业者必须在采取行动前验证输出。部署还受到治理要求的进一步限制如可审计性、变更控制和审批流程以及获取专业数据集、快速老化威胁数据和计算能力的有限访问[9]。在本工作中我们研究SOC从业者如何看待基于LLM的安全工具的效用、局限性和缓解策略并描述感知收益何时受到失败模式和验证负担的制约。我们的研究由三个研究问题指导• RQ1LLM目前在SOC工作流中的哪些位置以及如何集成• RQ2在安全运营中使用LLM的感知收益和实际挑战是什么• RQ3SOC在组织层面多大程度上准备好识别、理解和缓解LLM幻觉风险为回答这些问题我们对SOC生态系统中的20名安全从业者进行了半结构化访谈包括一线分析师、SOC经理、工具开发者和探索LLM集成的研究人员。参与者描述了使用案例、感知收益、失败模式以及他们在日常工作中依赖的验证和缓解实践。这个范围界定决策是明确的而非事后的。在从业者遇到的失败模式中幻觉在SOC工作流中具有独特的危险性因为与对抗性操纵或语法错误不同幻觉的事实和误导性调查方向可能看起来足够合理以通过初步审查并静默地传播到分类检查清单、检测草稿和事件报告中。因此我们将RQ3的范围限定在幻觉周围因为评估管理此风险的准备程度需要从业者扎根的访谈证据而这仅靠能力基准无法提供。范围/非目标。 我们研究SOC从业者在日常工作流中将LLM作为助手使用时的非对抗性操作可靠性失败。在这里失败模式是指任何看似合理但错误、不完整、误导或难以验证的输出通过返工、错误分类、延迟或不正确报告增加工作流风险。我们的分类法扎根于参与者报告的日常使用包括幻觉事实、无效逻辑、误导方向、解释错误和验证负担假设分析师仍然是对决策负责的责任人。我们不评估对抗性攻击或攻击面有效性这些仅作为背景讨论因为它们在我们的访谈中没有被直接测量。贡献。 本文基于SOC实践做出了四个贡献• 一个按角色分层的实证映射展示LLM进入SOC工作流的哪些位置以及从业者委派与保留哪些任务RQ1• 一个从访谈记录中派生的SOC环境中LLM输出失败模式分类法FM1–FM7包含角色覆盖和显著性RQ2• 一个幻觉缓解成熟度评分量表包含可观察标准和参与者级分布RQ3• 以及一个决策级、验证优先的综合矩阵连接SOC任务类型、失败模式、验证负担、成熟度先决条件和安全集成模式。2 相关工作近期工作将网络安全中的LLM框架为一把双刃剑既提供防御收益也引入新的攻击风险。聚焦于运营SOC环境我们回顾两方面的文献防御性SOC导向的用途和攻击性/原生AI威胁然后突显激发RQ1–RQ3的评估和运营差距。2.1 LLM在网络安全中的防御用途越来越多的研究探索LLM如何支持语言密集和上下文依赖的安全分析任务包括安全调查辅助、叙述总结和解释。例如HuntGPT将异常检测和可解释AI与LLM集成以支持威胁狩猎和面向分析师的信号推理[2]。调查工作同样强调LLM如何在防御任务如分析、分类和知识提取中被探索[31, 33]。最近SOC特定文献开始围绕具体的SOC工作流组织这些能力。Habibzadeh等人提供了一个全面的SOC聚焦调查将LLM用例组织在核心功能周围如告警分类、事件响应支持、日志分析和威胁情报同时强调实际约束包括数据敏感性、评估真实性和可靠性[8]。补充调查早期面向系统的研究考察了LLM如何嵌入SOC工具链。Singh等人评估了多模型LLM与SIEM工作流的集成用于一级分类决策说明了潜在效率增益同时强调当LLM输出影响操作优先级时需要进行仔细验证[28]。Tseng等人针对一个持续的SOC瓶颈——对自然语言CTI报告的重复分析——并提出了一个基于LLM的代理来自动化关键的CTI分析步骤旨在减少情报驱动工作流中的分析师开销[29]。这些工作共同激发我们对LLM在实际SOC实践中如何集成RQ1以及从业者感知到哪些收益和摩擦RQ2的关注。第二方面的工作聚焦于开发者和代码中心的安全工作流。实证评估表明代码助手在实践中可能引入安全风险用户可能接受不安全的建议、误解生成的代码或在时间压力下过度信任输出[26, 21]。这些研究表明LLM可以作为辅助工具有价值但收益与验证实践、用户专业知识和工作流设计紧密耦合。2.2 攻击性用途和原生AI攻击类别先前工作表明LLM集成系统可能容易受到对抗性操纵如恶意提示和知识源操纵且LLM可能降低生成令人信服的恶意内容的成本。我们引用这些文献是为了将更广泛的风险格局置于背景中而非作为我们实证测试的现象。例如提示注入已被形式化并基准测试为LLM应用中的控制平面操纵[17]。RAG增加了对外部语料库的依赖[15]使得知识污染攻击如PoisonedRAG在某些条件下可以通过污染检索语料库的部分来引导生成[34]。其他工作强调了LLM使能的大规模攻击性内容生成如钓鱼邮件[24]、跨模型越狱式鲁棒性失败[27]以及受约束设置中代理工具使用配置的风险[6]。相比之下我们的基于访谈的证据聚焦于SOC工作流中的非对抗性操作可靠性失败——不正确或弱扎根的输出、提示到提示的可变性以及安全使用LLM生成的草稿和初步线索所需的验证负担——将对抗性风险视为背景动机而非测量的结果或贡献。2.3 本研究的定位现有工作已经考察了LLM可能在哪些方面帮助防御者包括SOC调查和早期SIEM/CTI自动化原型[8, 28, 29]以及这些系统可能引入的风险。然而这些文献主要强调技术解决方案和受控基准而对从业者经验、感知和组织准备给予较少关注。先前的定性SOC研究也描述了工作流和采纳障碍但通常止于产生LLM特定的、工作流扎根的指导。我们的研究通过贡献三个面向部署决策的从业者衍生工件来扩展此文献i一个失败模式分类法ii一个幻觉缓解成熟度评分量表以及iii一个连接任务类型与失败模式、验证负担、成熟度先决条件和更安全集成模式的SOC集成约束矩阵。尽管幻觉、提示敏感性、验证负担和持续人类监督需求等担忧与先前文献一致但我们的贡献在于展示它们如何在SOC工作流中具体出现——其中输出在时间压力下产生必须可追溯到日志或威胁情报源等证据并受治理要求约束。在此环境中问题不仅是LLM输出是否可能错误而是哪些任务可以安全地保持草稿导向哪些失败最难快速检测以及更广泛部署前需要哪些控制。我们的经验主张限于SOC工作流中的非对抗性操作可靠性失败对抗性操纵仅作为背景讨论。目标是支持负责任的部署帮助团队管理与安全要求一致的幻觉相关风险。3 方法论为调查我们的研究问题我们对20名从事SOC活动的网络安全专业人士进行了半结构化访谈。我们的目标是捕获关于LLM在安全运营中集成的实际使用、感知收益、挑战和组织准备的多样化视角。参与者被特别选择因为他们有在运营SOC环境中使用、管理或研究安全工具的直接经验。3.1 半结构化访谈每位参与者完成了一次30分钟的在线半结构化访谈以英语进行。访谈由三个主题部分组成直接与我们的研究问题对齐。最初参与者描述了LLM在其SOC工作流中的集成和使用RQ1。随后他们讨论了基于LLM的工具与替代方法相比的相对收益和局限性RQ2。最后我们考察了参与者对组织准备以及用于处理LLM输出中幻觉的策略的感知特别强调信任影响和缓解方法RQ3。为保持一致性我们制定并遵循了标准化的访谈协议包括介绍、同意过程、清晰且非引导性的问题以及访谈后补偿程序。在数据收集前访谈指南由一位不在作者团队中且具有SOC相关经验的网络安全专业人士独立审查以评估问题清晰度、术语和领域适当性指南据此修订。此外我们在正式数据收集前使用访谈指南进行了一次试点访谈并用它来完善问题措辞、流程和时长。3.2 参与者招募参与者于2024年6月至12月通过专业网络和平台特别是LinkedIn以及个人推荐招募。符合条件的候选人至少有一年的实际SOC经验年满18岁并积极参与网络安全运营。我们不要求具备AI或LLM的明确专业知识这使我们能够纳入反映更广泛SOC格局的多样化视角。此招募策略类似于网络安全中先前的定性研究[20, 5, 1]这些研究有低于20名参与者我们不声称基于样本量我们的发现是可推广的。相反我们使用数据来突显突出的新兴主题和概念。所有访谈在参与者同意下录音并由符合GDPR的专业服务机构逐字转录。每位参与者在完成后获得50加元的电子礼品卡。参与者人口统计总结在附录D的表4中突出显示了我们的样本中代表的各种角色、经验和组织背景。3.3 数据分析访谈录音由符合《通用数据保护条例》GDPR的专业服务机构逐字转录并使用Braun和Clarke的主题分析阶段熟悉、生成代码、搜索/审查主题、定义/命名、报告进行代码本主题分析[4]。两名研究人员独立编码初始子集5次访谈以开发共享代码本比较解释并调和差异。然后每几次访谈后在保留批次上使用Cohens κ估计评分者间信度IRR解释遵循Landis和Koch[14]。编码迭代进行定期更新代码本当一致性低于我们的阈值κ 0.80时我们通过讨论解决差异完善代码定义并在需要时对早期转录进行回溯拟合。经过五轮编码主题类别间的一致性稳定在κ 0.80。在保留转录上子代码级别计算的Cohens κ在各轮中从κ0.81提高到0.88[第1轮0.81第2轮0.83第3轮0.85第4轮0.86第5轮0.88]。最常见的分歧是数据泄露/模型诱导与提示/模型滥用之间的边界案例。与我们的招募理由一致我们在分析期间监测代码和意义饱和在第15次访谈后未观察到新的实质性代码继续到N20以加强意义饱和。我们将饱和定义为最后五份转录中没有新的子主题或维度出现且代码定义没有变化[10]。最终代码本、示例引用和IRR统计出现在附录C表2和表3中。根据附录E的表1为展示我们主题发现的内部鲁棒性我们通过追踪每个代码在参与者批次中的首次出现进行饱和审计。我们将饱和定义为一批五次访谈未产生新的顶层主代码且少于5%的新子代码的点。表1按参与者批次的代码饱和度访谈批次新主代码新子代码累计代码数最终编码手册百分比P01–P051410812282%P06–P1001814094%P11–P1509149100%P16–P2000149100%所有14个主主题类别如挑战与局限、适应性、与基于规则的比较在前五次访谈中建立。在第2批和第3批之间新子代码的出现从18降至9主要包含利基工作角色或特定工具名称而非新的概念挑战。在最后一批P16–P20中没有新的代码或维度被添加到代码本确认我们的N20样本足以捕获此区域SOC生态系统中从业者经验的广度。我们将参与者分类为LLM用户如果他们报告了任何工作场所LLM使用包括偶尔或低强度使用。报告没有工作场所LLM使用的参与者标记为“不适用”因为缓解成熟度评分量表对他们不适用。来自没有批准的工作场所LLM使用的参与者的陈述被视为感知或间接暴露不用于推断运营部署。对所有主题发现个体参与者N20是主要分析单位。虽然参与者代表13个不同的组织但他们报告的经验反映个体角色和特定子团队。因此成熟度级别和使用模式在参与者级别分类以捕获较大组织内实践的异质性。当某个指标在组织级别报告时如第4.1节的人口统计会明确注明。研究人员立场。 研究团队在网络安全研究和SOC邻近问题设置方面有经验这为访谈协议的框架和对从业者术语的解释提供了信息。为减少解释偏差我们使用了独立编码、迭代代码本完善和整个分析过程中的共识调和。3.4 局限性我们的研究有几个定性工作典型的局限性。首先虽然半结构化访谈能够深入但回应细节因后续探询对参与者不完全统一而有所不同核心问题被一致覆盖但某些主题比其他主题有更丰富的叙述证据。与大多数基于访谈的定性研究一样我们的发现反映参与者的叙述而非对工作流的直接观察造成自我报告和社会期望效应的可能性。其次样本在地理上集中20人中有19人在加拿大安大略省1人在美国加利福尼亚州。尽管参与者代表了不同规模的组织表4但我们不声称具有全球代表性也没有在自我描述的角色和背景之外系统控制SOC成熟度。因此结果应被视为早期LLM使用的深入区域快照和基于实践形成的假设而非行业范围的基准。性别作为人口统计变量收集16名男性4名女性但由于样本量小从表4中省略以保护参与者匿名男性参与者的性别不平衡可能限制所捕获视角的广度。第三保密性和NDA意味着我们不要求披露LLM供应商、模型版本、部署模式托管与本地或微调因此我们无法将模型/部署特定效应与更广泛的采用模式分开我们的发现捕获使用模式和从业者感知而非跨模型的比较性能。第四这些发现时间戳为2024年中后期在更集成的代理工作流和广泛的接地成为常见之前虽然工具可能快速演变但SOC治理和验证通常变化较慢因此我们将我们的主题框架为未来纵向研究的基线。此外我们的编码框架允许通过多标签编码使失败模式共现但共现报告不是本文预先指定的目标。因此我们在此不量化共现频率将最常见的共现对的系统分析留待未来工作。最后我们不测量运营KPI如事件响应时间、FP/FN减少、检测提升主张仅限于基于访谈的实践描述和感知效用通常以验证为条件。3.5 分析三角验证和鲁棒性检查我们采用了两种内部鲁棒性检查以确保我们的发现不受我们初始分析视角的偏见负例分析 虽然大多数参与者报告了沉重的验证负担但像P12和P17这样的异常值突显了一个关键的边界条件LLM效用高度依赖于任务。在代码中心的生成任务中如起草过滤逻辑或Python脚本从业者经历了最小的摩擦因为输出可以通过执行测试和语法检查等技术工具快速证伪。相反对于调查或叙述驱动任务——如事件推理或归因——怀疑仍然很高因为错误通常看起来合理且难以快速验证需要更重的人类判断。敏感性分析 为确认我们的结论不是呈现结构的伪影我们使用两种替代组织镜头重新聚合了编码片段i任务/工作流镜头第4节和ii评估标准镜头第5节。我们将任务/工作流镜头作为主要使用评估标准仅作为参与者如何证明信任和感知效用的支持性组织。跨越两种镜头核心结论保持不变感知的LLM效用在文本中心、草稿导向的任务中最高而采纳受到验证负担和对决策级输出的有限信任的瓶颈制约。4 结果工具使用RQ1在本节中我们首先概述参与者的专业背景然后呈现在SOC工作流中如何集成基于LLM的安全工具的发现使用LLM输出失败模式即不正确或不可信的输出作为理解此集成中准备和信任的中心镜头。我们的结果反映两种基于访谈的证据i报告的做法参与者表示他们当前如何在SOC工作流中使用LLM包括他们生成什么工件以及如何验证和ii感知参与者报告的收益、成本和信任判断。我们不评估决策级运营结果如检测提升、假正减少或事件响应时间减少。因此本节中的“有效性”和“效率”等术语指参与者报告的感知效用和工作流支持通常以验证为条件。4.1 参与者背景和人口统计表4总结了20名参与者的入口统计和专业背景涵盖多样化的网络安全角色一线分析师、SOC经理、威胁响应工程师、数据科学家和高级领导层拥有1.5–25年的经验。我们将参与者分类为SOC专业人士如果他们的主要工作涉及日常SOC运营如分类、事件响应、检测工程或SOC管理以及安全研究员如果他们主要在研究/RD工作但在过去12个月内有直接的SOC工作流参与没有运营SOC参与的纯学术研究员被排除。参与者的专业知识范围从仅防御到攻防结合实践具有不同的方法论偏好基于规则、AI驱动/ML/LLM或混合以及广泛的AI经验从概念熟悉到动手模型开发。样本在地理上集中20人中有19人在加拿大安大略省1人在美国加利福尼亚州来自13个组织涵盖内部企业SOC、公共部门SOC、MSSP/提供商和安全产品供应商跨越所有规模区间——小型50–249、中型250–999、大型1,000–9,999和超大型≥10,000为保护匿名我们报告规模区间而非确切员工数且没有单一组织主导样本。4.2 常见用例和上下文依赖跨参与者类别四个用例一致出现日志总结、初始事件调查支持、文档起草和检测规则完善。我们不是仅将其视为任务类型而是根据参与者叙述将每个表征为具有可识别入口点、决策门和转换条件的工作流段。日志总结。 入口是由量驱动的当日志工件超出可在分类速度下手动解析的范围时分析师调用LLM如P09, P10。在提示总结后他们应用快速合理性检查将输出与原始日志的抽查进行比较然后决定升级、关闭或继续。证伪条件是快速且具体的“这个实体在原始日志中吗”这解释了为什么参与者报告此任务的验证负担低。分类指导。 第二个入口点是对告警类型不熟悉。分析师如P13描述提示首步调查步骤然后根据内部操作手册过滤输出保留有可用遥测支持的步骤丢弃与已知安全行为矛盾或缺乏日志证据的步骤。LLM输出作为头脑风暴支架而非可执行操作手册每个建议步骤在执行前需要独立论证。检测规则起草。 工程师如P04, P12在检测差距已被识别后调用LLM提供自然语言描述或可疑日志摘录并接收候选查询或规则片段。即时决策门是语法的linting或沙箱执行以确认操作符和字段有效性。通过的规则在同行审查和生产推广前进行历史流量回溯测试。失败包括FM2案例LLM发明不存在的操作符P04触发手动修正或提示修订。CTI和报告综合。 研究人员如P07, P19在从多个源聚合情报后调用LLM提示TTP提取或结构化总结。决策门是交叉引用提取的指标在运营使用前对照内部威胁情报平台或MITRE ATTCK检查。P07描述将提示限制在提供的源文本以减少推理驱动的捏造。一个一致的结构模式在所有四个案例中出现LLM在现有工作流的特定交接点被调用其输出在采取任何下游行动前通过人工操作的决策门。该门的可行性因此实际的验证负担取决于输出类型是否允许快速、具体的证伪条件。此结构激发了附录F中SOC集成约束矩阵中的验证负担和成熟度先决条件映射。5 结果感知RQ2我们请参与者描述他们对将基于LLM的工具集成到SOC工作流中的经验和感知特别关注感知的收益和挑战。从我们访谈的主题分析中五个不同的评估标准一致出现有效性、可用性、效率、适应性和信任。下面我们详细阐述参与者对这些标准的见解特别强调突出的主题。5.1 有效性有效性指LLM生成准确且上下文相关输出以支持运营安全任务的能力[32]。参与者一致描述了在某些SOC任务中的感知工作流收益特别是输出为草稿导向且可快速验证的地方。5.1.1 LLM在文本中心任务中表现出色参与者20人中的13人的主导感知是LLM可以通过减少总结日志和报告、起草标准化检测内容以及生成文档所涉及的时间和手动工作在文本密集型SOC任务中提供有用的工作流支持。例如P09描述在LLM辅助下重写检测规则“比手动起草快得多”同时仍将输出视为需要审查的草稿。参与者进一步建议自动化常规语言相关任务可以使分析师将注意力重新转向需要人类专业知识的更复杂活动。我们将这些叙述解释为参与者报告的感知效用和工作流支持而非性能改进或运营生产力增益的直接证据。5.1.2 检测工程支持中的新兴用途一部分参与者描述了使用LLM进行检测工程支持其中模型帮助分析师起草和完善可能随后输入现有检测工作流的工件。报告的使用包括从日志摘录中提取显著字段、起草分类检查清单以及生成候选查询/规则片段或调查步骤。较小的子集讨论了LLM从日志片段提出候选检测想法的实验性试点但这些输出被一致地框架为建议在运营采纳前需要严格的人类验证和常规回溯测试/审查。总体而言参与者将LLM视为加速早期起草和假设生成而非替换检测流水线或分析师判断。三名参与者还提到LLM直接从日志摘录或可疑数据点建议检测的实验性部署再次这些建议被普遍描述为在接受前需要严格的人类验证。一起发现表明LLM正在谨慎但不断增长地融入SOC检测工作平衡自动化速度收益与持续准确性关注以及分析师监督的持续必要性设想的模型是LLM工具增强而非取代人类分析师。5.2 可用性可用性指SOC分析师能在其现有工作流中有效交互和配置基于LLM的工具的容易程度[35]。虽然参与者普遍欣赏与传统的、专业ML工具链相比聊天式界面的直观性但他们也强调了关键的可用性挑战特别是与提示工程和输出透明度相关。5.2.1 可访问界面加速上手参与者广泛认可对话界面的可访问性和直观使用特别是突显了广泛可用的平台如ChatGPT。七名参与者明确赞扬了用户友好特性如对话历史、自然语言提示和关于潜在不准确性的主动免责声明。另有四名参与者报告主要通过集成的、基于供应商的安全平台如Splunk、Microsoft Defender与LLM输出交互欣赏LLM功能在熟悉的安全仪表板内的无缝嵌入。一个经常被引用的优势n3是启动与基于LLM工具交互所需的最小技术设置。参与者描述了制定初始查询、检测规则或摘要的显著易用性无需自定义代码。例如P12强调了此可用性优势“我不需要编写复杂的过滤器我只描述我想要什么工具就起草它。”易用的界面降低了采纳障碍使快速上手成为可能并减少了起草和探索性任务如撰写初始摘要或首遍规则/查询草稿的障碍特别是对于能快速验证输出的分析师。5.2.2 提示工程的挑战尽管初始易用八名参与者强调了提示工程作为关键可用性挑战。他们指出模糊或指定不充分的提示经常导致过于通用或不相关的输出需要重复调整或澄清。P07强调了将真实世界示例或日志摘录直接纳入提示的有效性指出这种做法显著提高了输出准确性。此发现表明LLM界面的表面简单性与制定有效提示所需的微妙技能之间存在固有张力。虽然基于聊天的交互模型看起来直接但实现一致、相关的结果在很大程度上取决于分析师领域知识和精确查询表述。因此基于LLM工具的集成和持续可用性的成功在很大程度上取决于分析师的专业知识及其对有效提示技术的熟悉程度。5.2.3 不透明推理阻碍采纳七名参与者提出了与LLM推理过程不透明相关的显著可用性担忧。与基于规则的检测方法其中触发的规则明确阐明为什么生成某些输出不同LLM输出通常在没有清晰理由或可追踪推理的情况下呈现。P05生动地描述了此担忧“使用基于规则的系统至少我们知道哪个规则触发了。LLM只是给出一个答案我并不总是确定为什么。”这种不透明性经常迫使分析师进行额外的手动验证——检查日志、查阅历史记录或试图推断生成输出背后的理由。这种缺乏透明度不仅阻碍了对LLM生成结果的信任还可能减慢事件响应时间限制整体运营效率。总之虽然基于LLM工具的初始可用性被积极看待但实际采纳受到有效提示工程和输出透明度相关挑战的显著影响。通过改善用户培训、更清晰的解释机制或增强界面设计来解决这些问题可以显著提高这些工具在SOC环境中的可用性和运营效用。5.3 效率效率指基于LLM的解决方案如何帮助分析师以最小的时间、数据和计算开销完成安全任务[32]。参与者一致强调了感知的效率增益——特别是在自动化重复任务方面——但也强调了在验证开销方面平衡这些增益的重要性。5.3.1 重复任务的时间节省和工作量减少大多数n13参与者强调了LLM辅助在常规、语言密集型SOC任务如日志总结、事件文档和安全简报中带来的显著时间节省。例如P16指出先前“需要一两个小时来汇编”的电子邮件安全摘要现在“在几分钟内”生成。三名参与者明确提到了工作量减少表明LLM有效减轻了日常任务的负担使他们能够更专注于复杂调查。尽管有这些优势参与者承认有效的提示工程仍然是确保LLM生成输出的连贯性和相关性所必需的。这些叙述表明参与者在特定任务中感知到工作负载缓解特别是输出可快速验证的地方。5.3.2 超越文本总结的自动化潜力除基于文本的任务外五名参与者认识到LLM促进半自动化脚本编写和调查工作流的潜力。例如P17描述了使用LLM生成的Python代码片段进行快速日志分析在其工作流中减少了手动编码工作以验证为条件。类似地P13提到LLM有效地起草了“首遍分类步骤”使团队能够专注于更深入的取证分析。尽管如此所有使用此类半自动化工作流的参与者都强调了人类审查的重要作用因为自动输出中持续存在不准确和逻辑错误的风险。这突显了一个新兴的混合模型其中LLM加速初始任务阶段但需要分析师主导的验证平衡效率增益与准确性要求。5.3.3 验证开销可能侵蚀效率增益尽管对加速内容生成总体满意若干参与者表达了对相关验证负担的担忧。P04明确表示“我们节省一个小时起草规则但花半小时验证每一行。”这种开销在关键情况下——如近实时事件响应或高可见性报告——变得尤为突出其中彻底验证至关重要。许多参与者描述将LLM输出与内部程序或历史验证规则交叉引用以降低风险。此验证必要性突显了LLM在安全中部署的一个基本方面虽然速度优势明确持续的人类监督仍然至关重要。因此参与者通常将效率收益视为取决于他们快速识别和纠正偶发不准确性的能力特别是在低风险上下文中。5.4 适应性适应性描述基于LLM的工具无缝集成到现有组织流程并有效响应不同运营上下文的能力[32]。虽然参与者认识到LLM的总体适应性但他们强调了在面对新颖或高度专业化的安全场景时的显著局限性。5.4.1 跨数据源和任务的灵活性若干参与者n6积极评估了LLM跨多样化SOC任务和数据源的适应性包括资产风险评分、总结告警和综合漏洞指标。例如P17成功将LLM输出与内部分类数据集成指出模型“在给予正确输入时能轻松在不同环境间切换”。然而两名参与者澄清有效的适应通常需要来自知识渊博的分析师的显著领域特定输入和仔细的数据策划。这表明LLM适应性在很大程度上依赖于持续的分析师输入突显了领域专业知识和主动上下文提供在维持成功部署中的重要性。5.4.2 面对新颖或专业威胁的局限尽管总体多功能四名参与者对LLM在面对新颖或专业威胁如缺乏历史参考的零日漏洞时的性能退化表示担忧。P19描述“当面对全新零日或我们只有最小情报时LLM被迫猜测有时猜测是错误的。”因此在高度专业化的场景中LLM预测经常变得容易出错。参与者指出了两种主要策略来缓解此问题快速用专业威胁数据补充模型或恢复到手动调查。然而三名参与者对资源约束表示担忧指出持续微调模型以应对新兴威胁昂贵、耗时且经常受内部专业知识限制。5.4.3 组织障碍和数据政策除技术考虑外七名参与者指出了影响适应性的显著组织障碍。挑战包括合规性法规、数据治理政策、供应商审批流程和领导层犹豫。P15将部署内部LLM描述为“多层迷宫”需要法律、隐私和合规团队的广泛批准。相反两名参与者指出当高级管理层明确支持AI倡议时采纳更顺畅促进更快的试点和实验。预算约束进一步影响适应性P07观察到频繁的模型微调成本高昂导致一些组织仅依赖通用、供应商训练的模型。因此实际适应性不仅取决于技术灵活性还取决于组织结构、资源可用性和政策对齐。5.5 信任信任指用户对LLM输出可靠性和事实准确性的信心特别是关于对不准确和捏造信息的抵抗[32]。参与者一致将信任视为影响SOC环境中LLM采纳的关键因素。5.6 LLM输出失败模式分类法我们超越将幻觉视为单一问题定义了一个在SOC工作中观察到的LLM输出失败模式的从业者扎根分类法完全基于我们的访谈语料库。我们聚焦于产生不正确、无根基、无效或难以验证的输出的失败这些输出可能在常规SOC任务中被采纳如检测起草、解释可疑活动、调查指导。分类法反映从业者描述的故障和验证负担并有意排除对抗性威胁如提示注入除非参与者报告了第一手事件。使用关于信任失败和不正确输出的编码片段我们识别了七种失败模式并通过“若被采纳的后果”评分量表分配严重性低浪费时间/轻微混淆、中误导分类/调查和取证拖延和高看似合理的漏检、错误升级或不安全操作如阻断合法流量。这些严重性代表概念上的潜在后果而非我们研究中观察到的实际影响。附录表5附录E报告了带有包含/排除标准和代表性证据的分类法。为可复现性我们使用主题片段描述特定失败事件的句子组作为分析单位并对复合失败应用多标签编码如FM1 FM5。附录表9附录E.1总结了跨参与者的覆盖和基于角色的显著性。总体而言此分类法阐明了从业者在SOC环境中描述的幻觉涵盖了若干不同的失败模式每种具有不同的操作结果。这种结构化方法通过将缓解措施如FM2的模式验证或FM1的RAG与特定失败类别而非不可量化的信任概念相关联实现了更精确的建议。5.6.1 人类监督的重要作用几乎所有参与者n15明确强调了持续人类监督的必要性。虽然许多参与者描述了在特定任务中LLM辅助带来的感知工作流收益但参与者坚持认为人类判断对于验证输出是不可或缺的。P08简洁地表示“LLM是助手永远不是最终权威”反映了一种普遍情绪即分析师必须彻底审查LLM生成的检测、总结和建议。这种对人类监督的强调与网络安全中新兴的最佳实践一致将AI驱动的加速与专家人类审查相结合。参与者描述了一种使用模型其中任何潜在的工作流收益取决于保持分析师在循环中以验证输出并防止错误传播。总之虽然参与者认可LLM提供的感知运营效用但他们仍对完全将AI托付给关键安全决策任务保持谨慎。近期信任似乎根本上取决于能够管理当前LLM技术固有不确定性的强健监督和验证程序。6 结果准备度RQ3在本节中我们考察参与者如何描述其SOC工作场所上下文管理与LLM输出相关的幻觉相关可靠性风险的准备度利用第5.6节附录E表5引入的失败模式分类法。我们的发现反映参与者报告的做法分析单位参与者N20而非组织级成熟度估计。虽然参与者广泛承认这些风险是可信赖集成的核心障碍但他们描述了一套碎片化的准备实践正式化对策有限严重依赖人类验证。非采纳作为边界条件。 在我们的语料库中非采纳在分析上有意义而非简单的未使用。报告没有批准的工作场所LLM使用或描述其团队中非采纳的参与者将该边界与对输出可靠性的担忧、缺乏处理敏感数据的批准途径、关于如何在运营环境中使用此类工具的治理限制以及效率增益是否值得额外验证负担的不确定性相关联。因此我们将非采纳解释为早期SOC采纳中有限准备条件的证据而非缺失案例或缺乏相关性。运营风险模型。 为使我们的安全框架明确且可从访谈证据证伪我们将幻觉风险操作化为在SOC任务期间使用的LLM输出的一组可观察结果类型。当输出表现出以下一项或多项时我们将其视为失败i捏造的事实/实体如虚构的事件细节或不存在IOC/TTPii模式或工具无效的工件如无效的检测规则语法或发明的操作符或iii误导性程序建议如不正确的一级分类步骤或增加验证负担或错误引导分析调查指导。当失败足够合理以被采取行动或被视为线索或当它通过返工和验证造成分析师时间浪费或将错误传播到不正确的调查步骤、草稿规则或报告内容时它在操作上变得有后果即在风险意义上“成功”。重要的是我们不测量事件影响或业务损失也不评估攻击者适应或对抗性鲁棒性相反我们报告从业者描述的失败模式及其在运营环境中使用的缓解实践。附录E的表6总结了这些结果类型、使它们在实践中具有风险的操作后果以及参与者报告的缓解实践。6.1 关于幻觉的一般观察参与者一致将幻觉视为与基于规则系统或传统ML模型生成的假正不同的独特操作失败模式。具体而言他们指出LLM可以捏造广泛的叙述——如事件细节、虚构的妥协指标或不存在的战术、技术和程序TTP——对SOC工作流构成显著风险。P06简洁地捕捉了此情绪“我们大多数人都知道LLM可以编造东西但我们不确定如何系统预防。我们当前的方法基本上是‘睁大眼睛希望没有初级人员按字面接受。’”虽然参与者普遍避免让LLM输出在没有人类监督的情况下直接影响高风险决策但缺乏自动化或强健的验证过程经常导致手动、资源密集的分类工作。这些叙述直接映射到表6中的操作结果类型强化了我们研究的风险是基于可观察的工作流失败而非对抗性威胁覆盖。6.2 处理幻觉的具体策略参与者报告采用了若干不同的策略——从非正式手动验证到实验性自动化解决方案——以解决幻觉风险。下面我们根据其普遍性和成熟度总结这些策略。6.2.1 无正式缓解方法超过三分之一n8的参与者报告在其直接工作环境中他们没有观察到任何管理幻觉的形式化策略。相反幻觉被临时处理依赖分析师判断和手动交叉检查。P14例证了此方法“如果我们看到不符合日志或感觉不对劲的东西我们只知道要质疑它。”参与者将缺乏结构化方法归因于有限的组织资源、对自主AI的风险规避以及关于有效缓解实践的不确定性。因此幻觉识别在很大程度上取决于分析师的警惕和直觉而非定义的程序进一步增加了高级分析师的工作量和验证负担。6.2.2 严重依赖人类监督报告的最常见方法n10涉及广泛依赖人类监督。分析师经常将可疑的LLM生成输出与内部知识库、日志存储库和外部威胁情报平台交叉引用。P09总结了此实践“我们没有自动安全网因此我们将LLM输出视为线索而非结论。”分析师将自己描述为人类验证者负责手动验证和纠正可疑输出参与者承认这是一个资源密集型过程降低了最初从LLM驱动自动化中预期的效率收益。6.2.3 提示完善三名参与者明确讨论了提示完善作为主动最小化幻觉的有效策略。这些参与者不是让LLM无限制地自由生成叙述而是精心制作提示以约束响应——例如使用具体指令如项目符号或将内容仅限于提供的数据。P07指出当明确指示模型时错误显著减少“我告诉LLM‘永远不要假设我们未在日志中提供的任何东西’错误率急剧下降。”然而参与者承认此方法增加了分析师的认知负担因为有效的提示工程需要超出典型SOC分析师能力的专业技能。6.2.4 自纠正循环少数参与者n2报告了尝试使用自纠正循环其中LLM审查和评估其输出以识别不一致或矛盾。虽然这些方法偶尔标记逻辑错误但参与者对仅依赖单一模型进行自我验证持怀疑态度警告“它可能第二次幻觉。”然而他们建议将自纠正循环与来自可信来源的RAG结合可能提供未来潜力。6.2.5 置信度因子和跨模型检查少数参与者探索了涉及置信度分数或多模型交叉检查的高级验证方法n2。一名参与者将LLM生成的置信度指标与SIEM元数据集成另一名倡导并行查询多个LLM以检测矛盾输出。例如P17表示“如果我的本地LLM说一个IP是恶意的但ChatGPT说是良性的我会进一步调查。”虽然这种冗余偶尔识别不准确性参与者承认此方法是资源密集型的且不能完全防范跨模型一致的幻觉。6.2.6 与既定标准对齐一名参与者明确尝试通过参考公认的安全框架如MITRE ATTCK或NIST指南来验证LLM输出。如果LLM生成的信息缺乏与这些标准的可识别链接分析师将输出视为可疑。然而此方法需要持续的手动验证正如参与者所指出的“我仍然需要检查它给我的MITRE技术ID是否是捏造的。”6.2.7 结构化输出验证两名参与者描述了旨在针对权威数据模式或内部数据库验证LLM输出的早期阶段倡议。一人使用脚本自动将IP地址、主机或文件哈希与可信内部数据库交叉引用。另一人将LLM响应转换为结构化JSON以进行自动模式验证防止语法错误或不存在的操作符渗入SOC工作流。虽然这些结构化验证有效地捕获了基本语法级错误但参与者承认更深层的事实不准确性仍需要人工审查。6.3 幻觉缓解成熟度评分量表我们定义了一个幻觉缓解成熟度评分量表以用基于记录证据的幻觉缓解实践分类替代非正式准备评估附录E表7。使用参与者作为分析单位N20我们对每个参与者描述的约束、验证和管理LLM输出的实践如提示约束、审查门、自动检查进行编码并将其分配给他们明确描述为常规实践个人或作为组织/团队程序的最高成熟度级别。评分量表涵盖四个级别L0 临时个体验证L1 共享但未记录规范如常规手动交叉检查L2 至少一个已记录、一致使用的预防性护栏如提示库/模板或仅证据提示L3 至少一个超出手动审查的主动、可审计控制如自动验证脚本、模式验证、正式法律/合规签署门或验证审计日志。没有活跃工作场所LLM使用的参与者因此无法评估缓解标记为“不适用”并从准备声明中排除。应用此评分量表揭示了向较低成熟度级别倾斜的分布级别1最常见30%n6其次是级别020%n4。较少参与者报告与级别215%n3或级别320%n4一致的实践。三名参与者15%n3报告没有工作场所LLM使用因此标记为不适用表7。每个级别反映其记录描述与该级别一致实践的参与者比例不应解释为跨13个组织的组织级准备度估计。6.4 分层分析按角色的运营视角为提供可操作的设计启示我们对四个关键专业角色的发现进行了分层分析这些角色在我们的元数据中识别一线分析师、技术工程师、安全经理和工具开发者/研究员。表8总结了这些角色在使用、风险感知和缓解优先级方面的差异。研究得出结论一刀切的AI策略对安全中心无效因为不同角色需要不同的工具功能。要成功设计者必须解决三个关键领域平衡分析师对速度和来源的需求与管理层对政策合规和隐私的需求区分适合AI的任务——如生成性报告起草验证容易——和高风险调查推理AI不透明仍是障碍以及提供角色特定功能如分析师的并排数据比较和领导层的审计追踪。这些专门的重点领域对于应对当前挑战和安全运营中AI-人类协作的未来演变至关重要。6.5 决策级综合SOC集成约束矩阵本小节为SOC设计师引入了一个单一可操作工件SOC集成约束矩阵附录F表10。该矩阵通过将常见SOC任务类型映射到i主导失败模式FM1–FM7、ii验证负担低/中/高、iii所需最低缓解成熟度L0–L3和iv安全集成模式如仅聊天草稿、模板模式验证、门控部署来总结设计约束。它仅由编码访谈证据填充两名编码员独立执行映射并通过与主题编码相同的共识协议解决分歧不明确的情况标记为“证据不足”而非外推。矩阵突显了一个关键边界具有快速可证伪输出的任务如脚本/规则可以以较低的验证努力集成而叙述/调查决策支持需要更高的成熟度控制和更强的门控因为错误更难快速检测。7 讨论本研究考察了LLM在SOC中的集成提供了对从业者感知和使用的见解。虽然LLM在自动化文本密集型任务方面显示出潜力但我们的发现揭示了关于可信度、透明度和幻觉的显著担忧。一些观察可能是时间敏感的如特定产品集成或接地功能。然而参与者提出的时间稳定问题——验证开销、对输出的责任以及LLM建议可以安全进入工作流的位置——由组织过程塑造即使工具发展仍然相关。我们讨论关键含义将发现置于现有研究背景中并为部署LLM驱动的安全解决方案提供建议。我们的若干发现与更广泛LLM可靠性和AI辅助工作流文献一致特别是关于幻觉、提示敏感性、验证负担和对人类监督持续依赖的担忧。在SOC环境中似乎特别突出的是这些问题与操作时间压力、需要将主张追溯到日志、规则或威胁情报证据以及关于模型生成内容如何进入检测和响应管道的治理约束的组合[3, 25, 19]。这些因素有助于解释为什么参与者对将LLM用于可快速验证、草稿导向任务比对用于调查推理或更高风险决策支持更放心。如何在实践中使用这些工件。 这些工件支持三个决策点工程师/负责人使用约束矩阵选择安全的SOC用例管理层使用成熟度评分量表基于护栏门控部署分析师在调查期间使用失败模式分类法指导LLM输出的验证和升级。7.1 解决实际障碍数据、集成和组织障碍观察实践 参与者描述采纳通常受数据治理、集成开销、资源和部署成本的约束这可能在完全运营集成之前停滞试点。表达需求 他们想要更清晰的合规路径和可靠的内部流水线使SOC特定接地可行而无需依赖临时、逐例例外。我们建议 将LLM采纳视为数据与治理项目而非仅是模型选择决策。近期努力应优先构建可审计的数据流水线在明确的访问和使用规则下捕获和管理日志、威胁情报源和分析师注释并与法律和合规利益相关者密切协调。相关的分散日志分析研究说明了解决此张力的一种潜在架构。Federated LogTracer提取上下文关系并识别恶意日志同时将敏感遥测保留在本地而非整合到中央分析服务器[23]。虽然我们的访谈研究未评估此架构但它展示了如何在隐私和数据位置约束下追求SOC特定情境化。对于探索模型本地化的组织我们建议评估迭代精炼方法如人在回路更新/主动学习[18]和面向效率的微调策略如分数微调[12]作为降低运营成本和隐私摩擦的选项同时明确指出我们的访谈研究未评估其在现场的有效性或成本效益。最后我们建议执行赞助商和SOC领导层预先定义数据权利、隐私政策和试点过渡到持续运营工具所需的基础设施承诺。7.2 在高风险安全任务中缓解幻觉观察实践 参与者主要通过人在回路验证和对照日志、指标和内部知识交叉引用管理不正确输出。表达需求 他们想要减少验证拖累的缓解措施同时使输出是接地还是推测更清晰。我们建议 评估符合这些需求的分层缓解设计i使用对策划内部/CTI源的检索来接地输出如RAG作为将溯源附加到主张的方式[15]ii跨模型或常规系统的冗余或交叉检查以标记不一致[30]iii随着上下文和威胁信息变化定期重新验证高影响输出的监控方法[13]。这些是参与者报告激发的建议设计方向我们的研究未实证验证其有效性。7.3 设计可操作解释和工作流集成观察实践 参与者偏好可快速对照熟悉SOC工件如检测规则、已知指标和原始日志检查的简洁输出当验证不清楚时对长叙述接受度较低。表达需求 他们想要在时间压力下操作上可操作且易于验证的解释。我们建议 围绕验证优先解释设计界面提供简短的分类就绪总结加一个向下钻取视图将主张链接到具体证据如引用的日志行、查询结果或CTI项目并在适用时将关键元素映射到公认框架如MITRE ATTCK。我们还建议轻量级反馈渠道如标记/注释输出并捕获“使用了什么证据”以便组织可以迭代地将输出与本地工作流对齐而不假设反馈自动提高可靠性。7.4 操作化人为因素编码分析师资源fulness观察实践 参与者描述了一套操作者主导的护栏——仅证据提示、检查清单驱动分类、对照SOC系统的交叉检查、用于验证的结构化输出以及更高影响行动的双重控制——作为在不消除人类判断的情况下限制不正确输出的实用方式。表达需求 他们希望这些实践可重复和可审计而非依赖个体警惕。我们建议 将这些护栏编码到操作手册和工具中i对提示和响应采用仅证据政策ii为常见分类和起草任务维护策划的提示/检查清单库iii要求具有模式验证和显式溯源字段如引用的日志ID、CTI引用的结构化输出iv对源自LLM建议的高影响行动或变更应用双重控制审查v仪器化轻量级验证日志记录检查了什么以及基于什么证据[11, 16]。这些是基于参与者描述实践的过程和工具方向我们不声称它们消除失败模式特别是在新颖性或时间压力下。7.5 组织成熟度对LLM集成的影响观察实践 参与者描述了显著异质性较小的团队通常依赖商品界面进行一般协助而大型企业/MSSP描述了在更严格治理下在SIEM/XDR工具链内更结构化但仍实验性的集成。此模式与CISO级证据一致显示企业GenAI准备度在上游治理通常比运行时保证更强其中有限遥测和操作程序使检测主要停留在人在回路[22]。表达需求 组织想要匹配其成熟度约束的解决方案低成熟度SOC需要可用的护栏而无需专业AI专业知识而高成熟度SOC需要可审计性和政策对齐。我们建议 开发与评分量表表7对齐的成熟度定制配置。对于较低成熟度环境优先考虑安全默认和有界工作流如仅证据提示、结构化模板和清晰升级边界减少对临时判断的依赖。对于较高成熟度环境优先考虑支持治理控制如访问限制、审计日志和批准门并允许在合规约束下进行受控实验的API驱动集成。我们还建议面向SOC的AI成熟度基准帮助组织自我评估更高自主使用准备度如预期验证开销和问责要求而不暗示本研究中任何特定配置已被验证。8 结论我们对20名安全从业者的研究表明LLM正被谨慎地集成到SOC工作流中主要作为补充工具。参与者报告了在文本密集型任务如总结和起草中感知的时间节省通常以大量验证为条件。然而参与者描述了由于不可靠输出和不透明推理对LLM在高风险安全决策中的有限信任。参与者也很少描述标准化、文档化的缓解程序而是依赖临时验证规范和持续人类监督。总体而言这些叙述指向一个混合现实其中LLM输出作为初步线索或草稿必须使用现有SOC工具和专家判断进行验证。使用在参与者级别应用的成熟度评分量表我们发现准备度不均衡且通常反映非正式实践而非治理过程。未来工作应研究供应商托管部署模型如何在生产SOC环境中塑造隐私、数据驻留和可审计性约束。