大语言模型评估面向安全运营中心的多视角报告评估设计

大家读完觉得有帮助记得关注和点赞！！！

摘要

安全运营中心（SOC）经常生成关于安全事件的分析报告，而大型语言模型（LLM）在不久的将来很可能被用于此任务。我们假设，更好地理解资深分析师如何评估报告（包括他们的反馈），有助于在SOC中生成分析报告。在本文中，我们的目标是利用LLM来分析报告。为此，我们首先构建了一个“分析师视角检查清单”，以通过文献综述和与SOC从业者的用户研究，反映SOC从业者对分析报告评估的意见。接下来，我们设计了一个新颖的基于LLM的概念框架，命名为MESSALA，进一步引入了两种新技术：细粒度指导方针和多视角评估。MESSALA可以最大化报告评估效果，并提供关于资深SOC从业者认知的反馈。当我们用MESSALA进行大量实验时，与现有的基于LLM的方法相比，MESSALA的评估结果最接近资深SOC从业者的评估结果。然后，我们展示了两个关键见解。我们还用MESSALA进行了定性分析，然后确定MESSALA可以提供改进分析报告所必需的可执行建议。

1. 引言

许多组织的网络攻击事件不断增加，建立安全运营中心（SOC）以分析安全警报并做出响应，近年来对每个组织而言变得紧迫且至关重要。SOC的一项重要任务，除了提供安全警报及其分析外，是撰写分析报告，对其底层的网络攻击提供清晰且具有可操作性的见解[sharma2024decoding]。有趣的是，与分析报告的质量成正比，包括分析师及其管理者在内的各种利益相关者能够理解安全警报的内容，从而使整个组织都能意识到安全问题[jawad2024m]。

然而，为安全警报撰写分析报告要求SOC从业者承担沉重的工作负荷，因为这些报告必须包含可操作的见解[kokulu2019MatchedandMismatchedSOCs]。为减轻此工作负荷，提取网络安全可操作见解的方法需求很高[albanese2025towardsAI-driven]。尽管存在几种为安全警报生成分析报告的工具[loumachi2025advancing, zhao2025information]，但自动生成的报告经常包含不准确的信息，从而影响SOC的性能[kokulu2019MatchedandMismatchedSOCs]。即使使用最先进的大语言模型（LLM），它们也会产生幻觉[CHEN2024SurveyoflargelanguagemodelsforCyberThreat, hasanov2024applicationoflargelanguagemodels]。此外，按照报告撰写指南的精确要求撰写分析报告压力很大[nepal2024burnout]。原因是分析报告的评估应从专家视角识别描述和判断上的不足[RYAN2012Quantifying]：例如，“根据内容，响应是否具有可操作性”。针对上述问题最常见的缓解方法是不断调整和修改报告[kokulu2019MatchedandMismatchedSOCs]，而对SOC分析报告的评估需要专业知识[kerstenfield2025tier1analyst]。

基于上述背景，本文中，我们讨论使用LLM对SOC中的安全警报分析报告进行评估，以提高报告质量。具体来说，我们在本文中讨论以下研究问题：

RQ1

从专业知识出发，保证分析报告质量的评估标准是什么？

RQ2

在定义的评估标准下，LLM能否根据专家视角的判断，定量评估分析报告的质量？

RQ3

在定义的评估标准下，LLM能否提供专家视角判断的反馈，从而定性评估分析报告的质量？

作为对RQ1的回答，我们首先提出“分析师视角检查清单”作为评估标准，以反映SOC从业者关于分析报告的知识。为此设计，我们还进行了文献综述和包含半结构化访谈的用户研究。在文献综述中，我们收集了IT和OT领域的13份公开指南和手册作为主题分析，并联系了这些领域中具有不同背景的15名SOC从业者作为模板分析[bushra202299False]。我们还与多名SOC从业者进行了检查清单的验证测试。（详见第3节。）

接下来，基于上述检查清单，我们提出了一个新颖的框架，称为“使用LLM辅助进行安全分析的多视角评估系统”（MESSALA），以最大化SOC中分析报告的评估效果。简而言之，MESSALA通过从多个视角利用“分析师视角检查清单”来指导LLM评估分析报告。如第4节所述，MESSALA可以模仿人类认知，从人类专家的视角通过检查清单获取专家知识，因此能够返回适当的评估结果以及对给定分析报告的反馈。当我们用MESSALA进行大量实验时，我们发现MESSALA在定量评估方面优于现有方法[fu2023gptscore, liu2023g-eval]。因此，作为对RQ2的回答，我们确认MESSALA是否能使LLM从人类专家的视角定量评估分析报告。（详见第5节。）

第三，我们通过定性评估来检验从MESSALA返回的反馈是否符合人类专家视角的判断。根据多指标评分，MESSALA凭借其反馈在大多数指标上获得了更高的评分，这些反馈比常见的LLM基线更具体且更易于理解。这意味着MESSALA还能使其反馈使LLM能够定性评估分析报告。（详见第6节。）

总而言之，我们在本文中做出了以下贡献：

• 我们设计了一个“分析师视角检查清单”，其中包含分析报告评估的条目，以通过文献综述和半结构化访谈反映SOC从业者的知识，作为对RQ1的回答。

• 我们提出了MESSALA，一个新颖的框架，可以最大化报告评估效果，并提供来自SOC从业者视角的反馈，并通过大量实验确认MESSALA是否能使LLM定量评估分析报告。这等同于对RQ2的回答。

• 我们检验了从MESSALA返回的反馈，然后确定MESSALA也能通过其反馈使LLM能够定性评估分析报告，这是对RQ3的回答。

2. 相关工作与问题设定

本节我们将从LLM和SOC两方面描述相关工作作为背景。然后，我们将描述SOC中分析报告的评估作为主要问题设定。

2.0.1 大型语言模型

LLM是结合语言处理与数据生成的模型。它们将观察到的标记作为字符序列学习，然后在输出序列中找到最可能的标记[sandoval2023LostAtC]。对LLM的输入称为提示。LLM可以提供与资深数据分析师相当的性能[cheng2023-IsGPTaGoodDataAnalyst]，并用作LLM即法官服务来评估数据[hu2024llm]。我们重点关注GPTScore[fu2023gptscore]和G-Eval[liu2023g-eval]。LLM的一个常见问题是幻觉，即输出不正确[huang2025hallucination]。

LLM已被用于许多网络安全研究，例如数据收集[BAYER2023multi-levelfine-tuning, papa2023AnAttackersDream, sharma2023HowWellDoesGPTPhishPeople]、数据预处理[liu2023NottheEndofStory, wadhwa2023RevisitingRelationExtraction]、特征提取[BOFFA2024Logprecis, jiang2024Xpert]、攻击检测[ali2023HuntGPT, Ghourabi2023EnhancingSpamMessage, koide2024ChatPhishDetector]和报告生成[Gupta2023fromChatGPTtoThreatGPT, mitra2024LocalIntel, perrina2023agir, yamin2024applications]。然而，LLM需要对网络安全的每个特定任务进行进一步微调[ferrag2023RecolutionizingCyberThreat]。我们讨论一种基于LLM的网络安全报告评估方法。

2.0.2 安全运营中心

SOC处理网络攻击的各个方面，包括数据收集、确定入侵存在和响应威胁[Tilbury2024HumansandAutomation]。SOC的主要作用是检测网络攻击[gupta2019AutomatedEventPrioritization, renners2019AdaptiveandIntelligible]、调查安全警报[yen2013Beehive, zhong2019LearningfromExpertsExperimence]并针对这些警报做出判断[kokulu2019MatchedandMismatchedSOCs]。SOC大致由两个过程组成，即分析师的评估过程和管理者的判断过程。为了支持并连接这两个过程，创建分析报告至关重要[kokulu2019MatchedandMismatchedSOCs]。

尽管近年来的SOC引入了自动化工具[AGYEPONG2023ASystematicMethod, shahjee2022IntegratedNetwork]以减轻工作负荷[Tilbury2024HumansandAutomation]，但工作量仍然繁重[nepal2024burnout, kerstenfield2025tier1analyst, kersten2024securityalert]。SOC中的分析师还需要基于碎片化信息理解网络攻击[VANDERKLEIJ2022DevelopingDecisionSupport]，并经常需要源信息来确定适当的响应[hassan2019NoDose, happa2021Assessing]。尽管近年来，包括LLM在内的机器学习已为SOC中的分析师开发[ANDRADE2019CognitiveSecurity, ban2021CombatSecurityAlert, baroni2021Self-AwareEffective, gonzalez2021SIEM, HUSAK2022Crusoe, mitra2024LocalIntel, jiang2024Xpert, albanese2025towardsAI-driven, singh2025llms, cui2025trafficllm, li2024dollm, singh2025contextbuddy]，但在提供分析报告[michelet2024chatgpt]和安全建议[chen2023can]方面，LLM存在局限性。

2.0.3 SOC中分析报告的评估

我们关注SOC中分析报告的评估作为主要问题设定。当前的报告生成工具存在局限性，因为LLM通常无法生成高质量的分析报告[michelet2024chatgpt]。相反，我们旨在探索LLM是否能有效评估这些报告。我们注意到，分析报告的评估仍然具有挑战性：通用的LLM可能无法与人类判断保持一致，因为这些报告通常包含特定领域的上下文[chiang2023closer]。

问题设定

我们的目标是设计一个系统，将分析报告作为输入，并将评估结果作为输出返回。输出包括来自SOC分析师视角的定量评分和定性反馈，例如可操作的反馈。我们认为分析报告的读者既是分析师也是管理者，而报告本身的生成不在本文讨论范围内。

3. 为安全报告评估设计分析师视角检查清单

本节旨在阐明评估安全警报分析报告质量的标准，并构建“分析师视角检查清单”作为反映这些标准的质量评估度量。以下内容构成了对RQ1的回应。这类报告是高度专业化的文档，预设了高级的安全领域知识。有观点指出，通用的文本评估度量标准不足以准确评估此类特定领域报告的质量[stufflebeam2000guidelines]。所提出的“分析师视角检查清单”整合了通过文献综述和访谈迭代验证的评估标准，并旨在将评估重点放在与实际决策直接相关的关键方面。

3.1 分析师视角检查清单的构建过程

“分析师视角检查清单”条目的构建通过以下分阶段和迭代的过程完成。这种方法是将知识库利用和用户需求/现场情境纳入设计的常见做法[benton2020usability, kwong2025design, rose2022co]：1) 候选条目收集：基于对安全指南和现有相关文献的回顾，我们收集并制定了应在分析报告中记录的信息以及初始的候选评估条目集。2) 报告质量访谈：与SOC分析师进行半结构化访谈，以提取关于报告质量的实用且关键的评估视角。3) 起草分析师视角检查清单：我们将从文献综述中提取的分析报告结构元素，与通过访谈从SOC分析师那里引出的隐式评估标准相对应，并基于这些对应关系，新设计了对于评估分析报告质量特别重要的具体检查清单条目。4) 通过专家评审和评估测试进行精炼：对于起草的检查清单，我们首先根据专家评审修订了条目结构和措辞。然后，我们进行了试评估，其中多位作者独立地将检查清单应用于样本报告，并通过调和主要的评分差异并精炼有问题的条目措辞，在最终确定检查清单前确认了可接受的评估者间一致性水平。该检查清单的细节将在下面描述。

3.2 通过文献综述收集候选条目

开发分析报告检查清单条目的初始阶段涉及系统的文献综述。此综述旨在通过确保报告警报分析结果所需信息的全面性和清晰度，来建立检查清单的设计基础。该过程包括以下步骤：

1. 文献收集：为确保检查清单条目知识所需的相关性，将公共组织和专家社区建立的关于事件报告和SOC操作的正規指南作为收集标准。共针对了13份文档，包括NIST SP 800系列事件处理指南，以及来自国内外CSIRT、监管机构和行业团体的事件报告公共信息[johnson2003handbook, force2020security, johnson2016guide, scarfone2008sp, stouffer2023guide, brenner2007iso, cisa_incident_reporting_2024, enisa_eecc_incident_2021, uscert_incident_guidelines_2015, enisa_incident_management_2010, isogj_soc_textbook_2023, isogj_5w1h_2019, enisa_iot_sm_2019]。

2. 提取相关内容：为确保提取过程的效率，我们将关键词搜索（使用诸如“报告”、“应描述”、“应包含”、“信息共享”等术语）与人工阅读相结合。这样做是为了提取列举报告中应包含信息的句子。对于长达数十页甚至数百页的冗长指南，我们使用了LLM。具体来说，我们向LLM查询“列出该指南设想的事件报告中应包含的信息，并指定其书写位置”。这提供了一个候选列表，以有效缩小相关部分的范围。

3. 语句的手动选择：为确保检查清单条目所需的清晰度和具体性，通过关键词提取和LLM候选列表获得的语句被手动选择。通过对照原始文本，只保留了那些真正可以被视为“报告中应包含的信息项”的描述。

4. 信息组织：提取的段落列表由两位作者系统地编码，涉及分析报告中应记录的项目。通过此编码过程，提取的描述根据其在分析报告中的功能角色被概念性地分组，并组织成三个总体类别和十一个具体文档项，从而建立了检查清单的基础。然后，由两位SOC专家审查了三类别十一项草案集，并随后进行了修订。为确保文献基础的全面性，我们用几个额外的来源扩展了初始文档集。由于此扩展审查未产生需要提取的任何新内容，我们认为关于从文献中识别的信息数据已达到饱和。

下面，我们展示应在分析报告中记录的项集及其所属类别。

决策支持和行动计划：此类别将有助于一线人员和管理者把握当前情况并确定适当后续步骤的报告元素分组。检查清单条目评估推荐行动和后续行动是否具体、可执行且理由充分，以及它们是否将即时响应与长期改进联系起来。[enisa_incident_management_2010, isogj_5w1h_2019, isogj_soc_textbook_2023, johnson2003handbook, force2020security, johnson2016guide, scarfone2008sp, uscert_incident_guidelines_2015]。主要报告要素：分析状态；影响评估；确认请求；响应行动；复发预防与经验教训。

调查与分析过程的责任性和质量保证：此类别确保调查活动和分析判断以透明、可追溯的方式记录，支持SOC操作的可靠性和可审计性。检查清单条目评估流程是否被系统地描述并有足够的细节，以便第三方审查、合规性验证和未来事件处理。[stouffer2023guide, enisa_incident_management_2010, cisa_incident_reporting_2024, brenner2007iso, isogj_5w1h_2019, force2020security, johnson2016guide, scarfone2008sp, uscert_incident_guidelines_2015] 主要报告要素：调查与分析方法；证据与支持数据；相关策略、指南与标准。

事件的技术理解与根源澄清：此类别涵盖了事件发生的技术性描述，包括发生了什么、在哪里、对谁、以及如何发生。检查清单条目评估事件是否被描述得足够具体，以便进行技术重建并证明所报告的结论是合理的。[enisa_incident_management_2010, enisa_iot_sm_2019, enisa_eecc_incident_2021, johnson2003handbook, cisa_incident_reporting_2024, force2020security, scarfone2008sp, uscert_incident_guidelines_2015] 主要报告要素：事件描述与解释；根本原因；事件来源与受影响系统；通信详情；漏洞信息。

3.3 报告质量访谈

表1：参与者信息。对于“专业水平”行，我们根据参与者自我报告的专业水平和经验年限将其分类为“高”、“中”、“低”。

用户ID	专业水平 / 经验（年）	职位	目标环境
1	高 / 7	SOC经理、架构师	工厂、建筑
2	高 / 5	工程师、SOC分析师	建筑、家电
3	高 / 9	SOC经理、架构师	IT、工厂
4	高 / 6	SOC分析师、主管	IT
5	中 / 4	工程师、SOC分析师	工厂、家电
6	高 / 17	SOC分析师	数据中心
7	高 / 23	SOC分析师	数据中心
8	低 / 3	SOC分析师	IT、工厂
9	高 / 5	SOC分析师、主管	IT、工厂
10	高 / 12	SOC分析师、主管	IT
11	高 / 20	FSIRT/CSIRT成员	工厂
12	中 / 2	PSIRT成员	交通、冷链
13	高 / 20	控制厂商安全人员	建筑
14	低 / 3	安全经理（制造现场）	IT、工厂
15	低 / 2	SOC分析师、网络工程师	IT、工厂

我们与负责起草和审阅分析报告的SOC人员进行了半结构化访谈，以开发一个反映SOC从业者对分析报告的关注点及其使用操作情境的检查清单[rose2022co]。这些访谈的目的是引出分析师在判断报告“质量”时所依赖的隐式评估标准，并将这些标准作为检查清单条目明确化，重点关注被认为特别重要的视角。对于之前识别的“应记录的报表元素”，通用的文本质量标准可以在一定程度上应用。然而，在本研究中，我们特意聚焦于SOC从业者自身在日常工作中强烈认为是问题的视角，并优先澄清哪些方面应该最仔细地检查。例如，虽然拼写和排版错误等纯粹的形式方面不能完全忽视，但在分析报告中，实际的“质量”更可能由内容相关因素决定，例如检测事件的技术准确性、操作情境描述的充分性，以及推荐响应行动的具体性和可行性。因此，我们认为必须适当地捕捉这些观点，并确保它们在检查清单中得到明确和透明的体现。

3.3.1 研究设计

我们对来自8个不同SOC相关组织的15名参与者进行了访谈。参与者包括负责警报分析和面向客户报告的高级分析师、团队负责人和管理者，他们都至少参与了报告生命周期——撰写、审阅或批准报告的至少一个部分。参与者是通过B2B访谈平台、作者所在组织内部以及合作伙伴公司招募的。参与者包括不仅负责IT也负责OT/IoT环境的SOC成员，从而确保了从多个视角的多样性。参与者的详细人口统计和组织属性见表1。所有访谈均使用会议工具（如Microsoft Teams）在线进行。在可能的情况下，访谈由多位作者进行，以减轻提问和解释中潜在的偏见。在参与者同意的情况下，所有访谈都进行了录音并随后转录，共产生337条编码评论。在分析之前，转录文本被匿名化并存储，并采取适当的安全措施，以确保数据的道德处理。对于来自作者所在组织外部的参与者，我们提供了一笔统一金额的酬金。为使对话自然展开同时涵盖关键主题，我们采用了半结构化访谈形式，每次访谈持续约30至60分钟。

作为我们的分析方法，我们采用了模板分析（TA），它从一组先验的兴趣主题开始，并通过整合新出现的主题迭代地精炼和扩展编码模板。TA在SOC研究等领域特别有用，因为先前的工作仍然有限，研究人员对数据中需要识别的概念只有部分理解。[bushra202299False] 首先，我们基于文献综述获得的描述进行了一轮初始编码，并开发了一组初步的主题代码。然后，我们分析了访谈数据，每当遇到与任何现有主题代码不匹配的值得注意的片段时，我们就引入新的代码或精炼和扩展现有的主题。编码迭代进行了三次，中间代码集由SOC领域专家审查，最终编码方案基于这些迭代的结果建立。此外，由于在第14次访谈后没有出现新的代码，我们判断主题已饱和，因此未对超过15名参与者进行额外访谈。在下文中，我们描述了从访谈结果中得出的评估报告质量的评估标准。

3.3.2 安全报告质量的隐式评估标准

表2：面向质量的分析报告评估视角

决策支持和行动计划

(1) 用于快速理解情况的底线结论的清晰度和说服力

(2) 所提议后续行动的具体性和优先级排序质量

(3) 所描述的客户或业务影响的充分性和清晰度

(4) 根据接收者的角色和理解水平调整内容、语气和细节层次的适当性

事件的技术理解与根源澄清

(5) 事实描述的准确性和解释力，包括明确的假设和约束

(6) 现场情境信息（如资产角色和操作背景）使用的适当性和深度

(7) 超越简单罗列日志，在描述事件时的技术深度充分性

(8) 通过使用多种分析方法（如趋势和比较）进行异常识别的稳健性

分析过程的责任性与质量保证

(9) 关键分析元素结构化呈现对于支持准确理解分析的有效性

(10) 通过证据与结论之间明确且连贯的联系，实现分析过程的清晰性和可验证性

(11) 分析范围和责任界定的清晰性，以促进无缝升级和角色划分

本节整理了SOC从业者在评估安全报告质量时使用的隐式标准，并将其精炼为评估报告质量的明确维度。尽管我们访谈的大多数组织没有维护明确定义“报告评估标准”的正規文档，但我们发现经验丰富的Tier-2级别分析师、接收方管理者以及SIRT成员在审阅报告时有效地应用了类似的标准。关于报告评估标准之外的访谈发现概述，请参见表2。此外，大多数评论指向报告实质性内容的不足，而非其形式质量。在下文中，我们根据报告中应包含项目的三个类别，呈现由此产生的评估标准和相关评论。

决策支持和行动计划的评估视角

评估标准 (1)：用于快速理解情况的底线结论的清晰度和说服力。受访者强调，分析报告应呈现一个清晰且有说服力的底线结论，使接收者能够快速掌握情况并做出明智决策。特别是，报告应明确说明警报是否有效、其紧急性、以及针对情况的推荐立场，同时附上支持这些判断的推理。然而，参与者指出，许多报告只是列举事实观察，而没有阐明决定性结论。“高质量的报告清楚地说明警报是否应被视为真阳性，其紧迫程度如何，以及为何做出该判断。没有这个底线，就很难快速决定下一步。” – 用户ID 1。“对于决策而言，关键在于报告是否清楚地解释了问题是什么、为何重要，以及我们应该从分析中得出什么结论。” – 用户ID 3。

评估标准 (2)：所提议后续行动的具体性和优先级排序质量。参与者强调，报告不应停留在分析结果上，而应具体描述要采取的后续行动及其相对优先级。有效的报告区分必须立即采取的行动和可选或有条件的行动，使接收者能够适当分配资源。相反，仅仅列出发现而没有可操作指导的报告被认为不足以用于实际操作。“重要的是明确说明下一步应该做什么，并标明优先级，例如，某个行动是强制性的还是资源允许时应处理的。” – 用户ID 9。“读者不仅需要了解存在什么问题，还需要了解他们自己针对这些问题应采取什么行动。” – 用户ID 6。

评估标准 (3)：所描述的客户或业务影响的充分性和清晰度。受访者认为，报告必须从客户视角清楚地描述警报如何影响客户的业务、运营或生产力，这一点至关重要。仅关注技术细节而让业务影响模糊不清的报告，使接收者难以判断可接受性或风险。在可能的情况下，量化影响被认为对于促进协调和决策特别有价值。“如果业务或运营影响被清楚地描述，甚至大致量化，解释情况和推进工作就会容易得多。” – 用户ID 11。“最终，客户想知道是什么导致了问题，以及情况是否真的可以接受。如果这一点不清楚，报告会让他们感到不安。” – 用户ID 14。

评估标准 (4)：根据接收者的角色和理解水平调整内容、语气和细节层次的适当性。受访者强调了根据接收者的角色和专业知识调整内容、语气和技术细节层次的重要性，以减少认知负担并使紧迫感认知保持一致。参与者指出，以统一风格撰写的报告往往无法弥合一线分析师和决策者之间的差距，导致误解或延迟响应。“可读性至关重要。每个接收者的理解水平不同，因此需要相应地调整解释和术语。” – 用户ID 2。“最重要的是缩小一线人员和决策者之间在紧迫感上的差距。报告应反映导致分析的背景和讨论。” – 用户ID 10。

2) 事件技术理解与根源澄清的评估视角

评估标准 (5)：事实描述的准确性和解释力，包括明确的假设和约束。分析师强调，报告必须准确描述事件期间发生的情况，并提供令人信服的解释来证明所得结论的合理性。除了事实正确性之外，受访者强调了明确陈述分析所基于的假设、分析依据和约束条件的重要性。遗漏这些要素的报告被认为难以信任，因为读者无法评估结论是否有充分依据。“最重要的是准确描述实际发生的情况，并以读者可以合理接受的方式进行解释。” – 用户ID 7。“如果分析背后的假设、依据或约束不明确，就很难判断情况是否真的被正确理解。” – 用户ID 4。

评估标准 (6)：现场情境信息（如资产角色和操作背景）使用的适当性和深度。参与者报告称，正确解读警报需要使用现场情境信息，包括资产角色、系统使用情况及其在操作或业务流程中的位置。没有这种情境，分析师通常无法确定警报是真正的问题还是误报。受访者指出，对操作情境的利用不足经常导致过于保守或模棱两可的结论。“操作情境是不可或缺的。根据资产的角色及其使用方式，警报的优先级和含义可能完全不同。” – 用户ID 13。“如果缺少诸如资产角色、流量是否与业务相关，或现场访谈结果等信息，我们通常无法明确确定警报是否是误报。” – 用户ID 5。

评估标准 (7)：超越简单罗列日志，在描述事件时的技术深度充分性。报告不仅应列举通信记录或日志条目，还应提供对事件具有技术意义的解释，例如哪些系统进行了通信、出于什么目的，以及应如何解释该行为。几位参与者表示沮丧，因为解读原始技术数据的负担往往完全留给接收者。“SOC报告通常只列出通信的IP地址，我们必须重新调查这些系统在哪里以及用途是什么。” – 用户ID 6。“如果报告也能解释通信的含义，将显著减轻我们这边的调查工作量。” – 用户ID 11。

评估标准 (8)：通过多种分析方法（如趋势和比较）进行异常识别的稳健性。最后，受访者强调了使用多种分析视角识别异常的重要性，包括时间趋势、与历史数据的比较，以及跨不同日志的相关性。仅依赖孤立日志条目的报告被认为不足以理解观察到的行为是否真正异常。参与者指出，时间和比较分析在许多当前报告中仍未得到充分利用。“我们真正想知道的是与过去相比发生了什么变化，但报告往往缺少这个视角。” – 用户ID 9。“展示从趋势差异或日志组合中得出的见解将使异常情况更加清晰。” – 用户ID 3。

3) 调查与分析过程的责任性与质量保证的评估视角

评估标准 (9)：关键分析元素结构化呈现对于支持准确理解分析的有效性。参与者强调，结构化和明确呈现关键分析元素（如假设、检查的证据和中间判断）对于确保读者能够准确理解分析至关重要。虽然存在标准化的格式和程序，但受访者指出，事件和分析师经验的差异往往导致这些元素的阐述清晰度不同，从而导致报告间的可理解性参差不齐。“报告质量存在明显差异，并且往往依赖于个别分析师的经验，特别是在分析结构的清晰度方面。” – 用户ID 4。“即使格式标准化，关键分析点的组织和解释方式仍因分析师和案例而异。” – 用户ID 1。

评估标准 (10)：通过证据与结论之间明确且连贯的联系，实现分析过程的清晰性和可验证性。报告通过明确地将证据与结论联系起来，清晰地记录推理过程，以便第三方能够追踪和验证判断是如何得出的，这一点被认为至关重要。参与者指出，报告往往未能充分记录如何检查替代性解释（例如误报），这削弱了对结论和分析整体质量的信心。“重要的是，分析结果如何导致结论之间没有逻辑断层或矛盾，并且第三方可以复现相同的推理。” – 用户ID 7。“特别是对于确定警报是否为误报，证据和推理必须清晰相连。如果这部分薄弱，整个报告的质量就显得较低。” – 用户ID 11。

评估标准 (11)：分析范围和责任界定的清晰性，以促进无缝升级和角色划分。参与者强调，有效的分析报告应明确定义SOC执行的调查范围，并明确说明后续行动的责任边界。高质量的报告并不试图详尽地涵盖事件的所有方面；相反，它们阐明在SOC可见性范围内分析了什么、可以合理得出什么结论，以及在何处有意识地将责任移交给其他利益相关者，例如CSIRT团队或客户侧组织。这种清晰性有助于无缝升级，避免超出分析师职责范围的多余或推测性分析，并基于对所有权和责任制的共同理解，实现跨角色和组织层级的有效协作。“必须清楚地说明已经分析了什么以及我们的评估是什么，然后一旦超出我们的范围就及时升级案件。界定边界并尽早移交对于实现快速有效的响应至关重要。” – 用户ID 12。“因为角色和范围——无论是在SOC和CSIRT之间，还是在Tier 1、Tier 2和高级分析师之间——都有明确界定，我们可以毫不犹豫地升级，并避免过度分析超出我们责任范围的事项。” – 用户ID 11。

表3：类别、报告要素及映射了评估标准的检查清单条目的代表性示例

类别 / 报告要素	映射了评估标准的检查清单条目示例
决策支持和行动计划​
影响评估​	现场影响、严重性级别和风险评估是否被描述并有理由？ — (3)
确认请求​	关于此事件，是否描述了需要接收方确认的具体事项或问题？ — (2), (4)
响应行动​	是否描述了已采取的具体行动、其必要性以及效果和评估方法？ — (1), (2)
事件的技术理解与根源澄清​
事件描述与解释​	报告是否基于对观察到事件的分析得出具体结论？ — (5), (7)
根本原因​	如果假定事件是操作影响，这一点是否得到解释？ — (6), (7), (8)
事件来源 / 受影响系统​	源设备是否与其角色、重要性和可疑性一起被明确识别？ — (6), (7)
调查与分析过程的责任性与质量保证​
调查与分析方法​	分析方法、决策标准和视角是否以多方面的形式进行了解释？ — (9)
证据与支持数据​	是否为每个观察或响应提供了证据，并说明了来源和获取方法？ — (10)
分析状态​	当前分析进度和后续步骤是否被明确说明？ — (11)

3.4 分析师视角检查清单草案的开发

该检查清单是通过系统整合1) 通过文献综述提取的应包含在分析报告中的结构元素，与 2) 通过访谈引出的SOC分析师在实践中使用的隐式评估标准而开发的。然后通过专家评审和应用测试最终确定了整合的条目集。这种方法也被广泛认为是构建评估检查清单的通用方法。[hales2008development]

整合方法

为了构建检查清单条目，我们首先为分析报告的每个结构元素映射了从业者感知的挑战总结（见第3.3.2节）中得出的评估视角。然后，我们借鉴访谈评论和从文献综述中提取的最佳实践描述，定义了具体的评估条目。

在设计检查清单条目时，我们的主要要求是它们在日常SOC操作中保持可操作性。简单地将受访者的关注点转化为条目可能会产生超出典型SOC组织权限或资源的需求[rose2022co]。因此，我们引入了一个步骤，从访谈发现中提炼出实际可行的元素，并将其精炼为检查清单条目。例如，针对评估标准(6)：现场情境信息的使用，受访者反复报告，缺乏当地情境通常使他们无法决定警报是否为误报。然而，对于一个标准的SOC来说，为每个客户环境维护详细、最新的业务背景是不现实的。因此，我们的检查清单不仅仅询问事件是否在考虑客户背景的情况下进行分析，还询问分析师是否明确说明了哪些情境信息是可用的，并将缺失但对决策关键的信息组织成具体的确认请求。这产生了一个现实的检查清单，它假设与现场工作人员存在角色分工，同时仍然减少了因情境不足而导致的模糊性。

“分析师视角检查清单”也适用于SOC中人员的一般任务，原因如下：1) 检查清单条目的粒度被通用化以在多个领域使用，2) 考虑到实际操作中的难度和现实系统的灵活性，移除了特定的评估标准，3) 并非应用整个检查清单，而是为每个分析报告选择相关的条目。

这些整合步骤主要由包括第一作者在内的两名研究人员进行。此外，我们使用通用LLM（gpt-4.1）作为头脑风暴辅助：给定组织好的评估视角和结构元素，我们提示模型“为每个视角列举候选检查清单条目”，并使用生成的建议来扩展和精炼候选条目及其措辞。在专家评审之前，草案条目在作者之间进行了讨论并加以精炼，只保留了有希望的候选条目。

3.5 通过专家评审和评估测试进行精炼

通过专家评审和小规模应用测试检验了所构建检查清单的有效性。首先，三位SOC领域专家评审了该检查清单，并就他们是否愿意在实践中使用它、它是否有助于防止审查时的遗漏，以及其内容是否与SOC中应执行的活动一致提供了反馈。具体来说，我们收到了基于实际SOC实践的评论，例如：“规定具体的响应行动不是SOC的职责，但他们应提供评估；因此，不应将这种严格性直接反映在检查清单条目中。”基于这些结果，我们增加、合并并精炼了几个条目的措辞，进行了第二轮评审，并参考德尔菲法[rose2022co]，选择了至少两位专家评估为有用的条目作为共识条目。

作为最终的验证步骤，三位专家中的一位和一位具有七年以上SOC相关经验的作者独立地将该检查清单应用于十份真实世界安全警报分析报告。对于每个检查清单条目，他们在五点量表上评估其被满足的程度，并记录结果。对于评分方向存在重大分歧的条目（例如，一位判断该条目基本满足，而另一位判断其几乎不满足），他们调和了解释，并相应地精炼了条目的描述和措辞。

最终，我们确认对于超过60%的检查清单条目，两位评估者在判断方向上达成一致，即条目是否被满足，然后我们最终确定了检查清单。表3展示了检查清单的一个子集；完整的检查清单见附录。

关于访谈结果使用的伦理考量见第7.0.2节。

3.6 对RQ1的回答

基于文献综述和半结构化访谈的发现，我们将分析报告的质量定义为以下三个立场：1) 为利益相关者提供决策支持和行动计划，确定需要什么行动以及为什么；2) 分析师对事件的技术理解和原因澄清，提供对系统行为及其操作的准确描述；3) 每个组织的分析过程的责任性和可重现性，确保报告的结论与其证据和推理透明地联系起来。SOC分析报告的质量由来自专家多视角的评估标准来判断。我们的“分析师视角检查清单”包含了这些评估标准。

4. 提出的方法：MESSALA

在本节中，我们提出了MESSALA，以克服使用上一节构建的“分析师视角检查清单”向分析报告创建者提供反馈所面临的挑战。我们首先解释MESSALA背后的主要思想，然后介绍MESSALA的细节，包括其整体工作流程。

4.1 动机与设计要求

为了解决向报告作者提供适当反馈的挑战，我们引入了以下关键思想。首先，如第1和第2节所讨论，为了克服对资深分析师的依赖、审阅者时间和人员有限以及需要快速反馈的挑战，我们引入了基于LLM的自动评估机制。上一节开发的“分析师视角检查清单”与报告一起用作LLM提示的一部分，使模型能够从专家导向的视角进行评估。

然而，先前的工作指出，基于LLM对文本好坏与否的判断往往与专家评估存在差异[murugadoss2025evaluating]。我们也凭经验检查了这个问题：我们首先让LLM使用我们的“分析师视角检查清单”天真地评估多个样本报告，然后在后来，请参与访谈的15位资深分析师中同意此操作的5位，审阅这些基于LLM的评估并提供评论。结果与先前工作的发现一致[murugadoss2025evaluating]。评论见附录XXX。1) LLM质量判断（好与坏）的趋势与人类分析师不同。2) LLM生成的反馈评论效果不佳。为了提供适当的反馈，LLM必须以与专家评估一致的方式判断报告的好坏，并将这些判断准确地综合成明确的反馈评论[zhou2024llm]。在本文中，在安全分析报告的背景下，我们将这两个要求表述为RQ2和RQ3。作为对RQ2和RQ3的回应，我们提出了MESSALA，这是一种转变基于LLM的分析报告评估过程的方法。MESSALA包含了以下关键思想。

4.2 关键思想

MESSALA基于两个关键思想。首先，细粒度指导方针通过将“分析师视角检查清单”转化为细粒度、可操作的评估提示，引导LLM的推理，融入分析师的专业知识和实践反馈。这将模型的注意力集中在报告中与专家相关的方面。

此外，为了更好地近似资深分析师对报告质量的判断及其有效反馈，我们设计了一种新的架构，即多视角评估LLM。这种架构整合了一个两阶段的评估过程。1) 高级别评估：基于简单提示配置和报告表面信息进行的初步评估。2) 深度评估：通过应用细粒度指导方针，深度考虑报告上下文进行的详细评估。整合两个评估的结果可实现多视角评估。这种设计模仿了人类文本理解的认知模型[wharton1991overview]。人类首先在构建阶段通过表面特征激活知识片段，然后在整合阶段整合其上下文，以理解文本的整体含义。

通过复现这种人类认知过程，多视角评估LLM使LLM能够更深入地理解从专家视角构建的“分析师视角检查清单”的内容。因此，MESSALA有望达到与资深分析师相当的评估和反馈提供水平。

4.3 方法细节

图1：MESSALA概述。​ 顶层模块运行两个并行评估器：一个高级别LLM和一个由细粒度指导方针引导的深度LLM；它们的输出由多视角评估LLM融合。

MESSALA的整体框架如图1所示。MESSALA由三个组件组成：分析师视角检查清单、细粒度指导方针和多视角评估。由于分析师视角检查清单已在上一节解释，以下将描述其余两个构成组件。

4.3.1 细粒度指导方针

细粒度指导方针是根据分析师视角检查清单的每个类别定义的。它具体说明，例如，应该向LLM提供什么类型的上下文，以及在评估过程中应该强调哪种描述。该指导方针作为一个抽象的"如何检查"规则来指导LLM的评估判断，而分析师视角检查清单则规定"检查什么"。每个类别的细粒度指导方针如表4所示。例如，在类别1："假设验证"中，它侧重于引导LLM在报告中找到假设的证据。

上述细粒度指导方针的类别旨在评估SOC中使用的实际分析方法是否适当地反映到分析报告中，以及是否提供了足够支持分析的上下文。它们还评估假设是否通过合理的理由进行了解释，如表4所示。这些类别是通过对现实世界中SOC分析报告的评估迭代精炼的。此外，在由作者所属组织的两位SOC相关专家检查类别后，还进行了修订。

细粒度指导方针提示主要处理以下几点："此检查清单项的目标是什么？"；"应检查报告中的哪些部分或类型的信息？"；以及"应如何评估已识别的信息？"。每个指导方针类别使用的提示示例如附录0.C中的图6所示。该指导方针的设计遵循了支持SOC分析[kersten2023give, kerstenfield2025tier1analyst]的现有实地研究。

通过利用细粒度指导方针，可以引导深度评估LLM进行详细评估。它使LLM不仅能够评估内容的存在，还能评估分析报告上下文的一致性。细粒度指导方针在深度评估LLM中起着至关重要的作用，如图2所示。细粒度化利用它来更深入地理解分析师视角检查清单中的每一项。然后它确定给定分析报告的哪些部分是重要的。最后，深度评估LLM返回一部分输入给稍后描述的多视角评估LLM。

图2：细粒度指导方针。​ 细粒度指导方针可以将检查清单中的项目分解为每个类别的具体评估步骤。

表4：细粒度指导方针中的评估类别概述。

类别	名称	详情
1	假设验证	检查报告是否为关键结论提供了充分的推理和证据。
2	基本警报信息	检查是否包含了关键警报详情（时间、位置、受影响的设备）。
3	模式与比较分析	检查报告是否将事件与过去案例或已知模式进行比较。
4	详细通信分析	检查带有技术上下文的通信分析。
5	周围环境与时间分析	评估涉及警报设备的周围及时间相关通信的分析。

4.3.2 具有高级别和深度评估的多视角评估LLM

我们的多视角评估LLM整合了两种评估，即LLM的高级评估和深度评估。我们首先在下面描述每种评估，然后描述多视角评估。

高级评估LLM

高级评估允许LLM依赖简单的评估项和表面信息，例如语法正确性。对于这种评估，LLM输出与人类评分之间的相关性通常很高[murugadoss2025evaluating]，而专家知识的使用可能对评估质量产生负面影响。同时，当LLM在没有详细指导方针的情况下进行文档评估时，它们通常会产生整体评估[zhou2024llm]。这可能导致注意力不足，从而产生与资深分析师不同的分析。用于高级评估的提示如图7附录所示。它由三个部分组成：目标安全报告、分析师视角检查清单中的具体项，以及评估设置，包括评估任务及其方法。评估使用五点李克特量表进行，它可以提供类人的分析[parker2024large, murugadoss2025evaluating]以及评分方案的可靠性[kusmaryono2022number]。我们注意到，在提示中，仅通过遵循先前研究[fu2023gptscore]中的提示结构提供了最少的评估方法。

深度评估LLM

深度评估引导LLM理解哪些描述对每个项是重要的。这使得LLM能够基于分析报告的上下文进行评估，并近似来自资深分析师视角的判断。深度评估提供了几个优势。首先，它使提示能够为LLM提供更丰富的上下文，从而实现严格的评估。其次，它提高了评估过程的可解释性，并使LLM更容易证明其输出的合理性。它还通过LLM自动评估每个项的细粒度化[liu2023g-eval, lee2024checkeval]。我们还注意到，基于通用LLM的评估可能由于分析报告（包含特定领域的上下文，与通用文档不同[chiang2023closer]）以及包含详细指令的提示有时无效[murugadoss2025evaluating]而无法与人类判断保持一致，如前一小节所述。为了克服上述问题，用于深度评估的提示由三个关键部分组成：待评估的分析报告、分析师视角检查清单以及细粒度指导方针，如图7附录所示。LLM的任务是基于分析报告的内容生成细粒度化的评估版本。

多视角评估LLM

此步骤整合了高级别和深度评估，以便从更接近资深分析师的视角评估分析报告。由于每种评估方法具有不同的特点，利用它们的输出有望产生更可靠和可解释的评估结果。此外，通过交叉参考从不同级别评估获得的输出，有助于减轻因依赖单一视角而产生的潜在盲点和偏见判断。

提示的结构如下。首先，基于深度评估，指导LLM为多视角评估检查清单中的项生成初始分数，该检查清单由两个评估的输出组成。重新考虑初始分数后，LLM输出一个使用五点李克特量表的最终分数。提示示例如图7附录所示。

5 LLM评分的定量评估

在本节中，我们进行了广泛的定量评估实验，以确定MESSALA是否能与人类专家一致地评估分析报告，从而解决RQ2。具体来说，我们比较了LLM评估的五点李克特量表与人类专家对从现实世界SOC收集的分析报告的评估。我们首先概述了实验设置，然后呈现结果。

5.1 实验设置

我们描述了数据集、评估指标和基线，包括它们的实现。

5.1.1 数据集

我们在本实验中使用以下两个数据集。

真实世界分析报告

第一个数据集是一个私有数据集，由现实世界SOC生成的分析报告集合。这些报告收集自监控三种不同环境（包括工厂、建筑和IT基础设施）的多个SOC。每个SOC都有独立的运营和环境，其监控范围、IDS配置和警报类型存在显著差异。所有分析报告都包含由网络监控触发的警报，但出于第7.0.2节所述的伦理原因，我们省略了其细节。

该数据集包含2022年4月至2024年4月期间收集的40份报告，其中12份用于工厂，18份用于建筑，10份用于IT基础设施。报告格式在每个环境内独立标准化，所有报告都得出结论认为警报代表良性情况；然而，每份报告都描述了具有不可忽略风险或模糊行为的事件，这些事件需要相应客户的确认。其内容包括基本元数据（例如日期和警报信息）、事件摘要、影响评估、详细分析、需要确认和行动的事项以及复发预防。报告的平均长度约为2200个字符，大多数报告为PDF格式。敏感信息，如IP地址和专有名称，已匿名化以在本地环境中供LLM使用。出于伦理原因，我们不打算发布报告本身。

伪分析报告

第二个数据集是由LLM生成的伪分析报告数据集。我们使用此数据集是因为，在撰写本文时，没有公开的分析报告数据集。为了保证此评估的可重现性，我们采用了基于LLM的伪数据生成方法[pmlr-v252-hao24a]，这种方法在难以发布真实世界数据的领域常用。特别是，我们使用结合了MITRE ATT&CK 1模式的RAG增强CoT流水线生成伪分析报告。通过验证这些伪分析报告，选择了10份报告作为最终数据集。

对于伪分析报告生成，我们首先准备了报告骨架和CoT风格提示。骨架定义了一个基本结构，其中环境上下文和警报概述、分析状态、分析结论、推荐行动和支持证据以一致的顺序描述。CoT提示指定了一个高级生成程序，以确保这些元素被连贯地描述。因为仅凭骨架和程序会导致内容过于抽象，我们在生成的早期阶段注入了外部知识和经验信息以增加具体性。具体来说，我们向LLM提供了(i)来自MITRE ATT&CK的攻击模式，(ii)从过去的内部报告中提取的检测、结论和响应的典型模式，以及(iii)关于假设关键资产的知识。此外，对于每种目标攻击技术，我们让LLM参考外部技术报告，以便生成的分析和对策能更好地反映环境和情境特定的解释。这些步骤通过将提示链与RAG风格的检索过程相结合来实现。通过此流水线生成大量伪分析报告后，我们使用LLM进行自动质量评分，并迭代丢弃低质量样本。最后，我们进行了手动质量审查，并选择了10份伪分析报告，用作我们评估实验中的第二个数据集。

示例提示和代表性的生成伪分析报告在附录0.F中提供。

分析师视角检查清单的人类黄金评估

使用第3节中的分析师视角检查清单，我们也能够从第3节用户研究的五位参与者那里获得评估结果。分析师视角检查清单中的每个项都在五点李克特量表上进行评分，最终分数计算为他们各自分数的平均值。为了使我们对评估标准的理解一致，前20份报告进行了联合审阅。然后，剩余的30份报告由两位作者处理。对于此人类黄金评估，选择了10到15个检查清单项，侧重于分析报告的重要上下文。限制项数基于两个原因：1) 评估过多项会增加参与者的工作量并可能导致低准确性；2) 在现实操作环境中，更实际的做法是集中关注与分析报告内容一致的关键项，以提供有意义的反馈。

在构建专家评估数据集时，我们遵循了三个重要的注意事项：1) 为了最小化偏见，评估者只被分配给他们不直接负责的SOC环境的报告。因此，每份报告通常由大约三名评估者评分，他们的平均值被用作最终的专家评分。2) 为确保评估者之间的一致性，我们对检查清单项进行了初步简报，并利用Microsoft Teams举行了问答环节以统一理解。3) 为保持评估过程的独立性，在所有评估完成之前，不允许评估者查看彼此的评分。

5.1.2 评估指标

根据第4.3.2节的讨论和LLM-as-a-judge[lee2024checkeval, liu2023g-eval, fu2023gptscore]的典型设置，我们测量五点李克特量表并计算LLM与人类之间的相关系数作为主要评估指标。我们计算斯皮尔曼等级相关系数ρ、肯德尔tau系数τ和皮尔逊相关系数r作为相关系数，以及均方根误差（RMSE）来衡量分数的偏差。虽然先前的工作[fu2023gptscore]计算并平均每个独立文档的相关性，但我们汇总所有分析报告然后计算相关性，因为每个报告的检查清单项数量有限且不同。我们使用了来自50份分析报告在n次执行上得出的总共755个项目。

5.1.3 基线

我们实现了MESSALA以及以下四种方法作为基线，也包括消融研究，即方法1、方法2、方法3和方法4。每种方法使用相同的多个模型集进行评估。超参数为温度=0，top-p=0，以及n=5。所有方法都使用分析师视角检查清单。

方法1：仅高级评估。​ 此方法执行第4.3.2节描述的高级评估。它遵循GPTScore[fu2023gptscore]作为一个典型的提示，简单地评估给定文本，利用分析师视角检查清单，但不应用细粒度指导方针，并依赖于高级评估提示。

方法2：无细粒度指导方针的仅深度评估。​ 此方法遵循G-Eval框架[liu2023g-eval]，首先将分析师视角检查清单的每个项细粒度化为一系列更深入的评估标准，然后基于这些详细标准进行评估。值得注意的是，虽然此过程引入了细粒度化步骤，但它并未使用我们的细粒度指导方针。

方法3：有细粒度指导方针的仅深度评估。​ 与前两种方法相比，此方法使用分析师视角检查清单和细粒度指导方针进行深度评估。注意，它既不包含高级评估，也不包含多视角评估。

方法4：无细粒度指导方针的多视角评估。​ 在此方法中，由方法1产生的高级评估结果和以类似方法2（其中未应用细粒度指导方针）获得的细粒度项结果作为输入提供给LLM，然后输出综合评估结果。

5.2 结果

我们在下面展示结果，总结每种方法的数值分数，并比较MESSALA与基线方法，以回答RQ2。结果的概述见表5和图3。如表所示，在大多数情况下，MESSALA在所有指标上都优于所有其他方法。这些结果突出了从我们的两个关键模块获得的优势，即1) 分析师视角检查清单和细粒度指导方针，以及2) 具有高级和深度评估的多视角评估。同样，图3显示MESSALA展现出最接近人类黄金评估的分布。这些结果表明MESSALA对分析报告的评估显著有效，因为它比其他方法更符合人类判断。

我们在消融研究中也发现了一些见解。当结合高级和详细评估时，MESSALA通过将其判断基于具体的报告内容和分析师视角检查清单，而不是依赖表面的理由，始终与人类黄金评估保持高度一致。相反，单独使用方法1往往会产生更高的评估分数，因为它依赖于粗略的高级评估，缺乏批判性评估报告详细内容的能力。

当比较仅依赖深度评估的方法2和方法3时，我们观察到不同的失败模式，方法2由于缺乏细粒度指导方针而表现出不一致的评估行为。因此，方法2有时无法足够详细地指定评估点，导致评估过于笼统。此外，我们观察到多个案例，其中方法2进行了与报告内容弱相关或不相关的评估，导致分数较低。相比之下，方法3即使仅识别出小问题时，也始终分配过低的分数。这种趋势源于其细粒度和局部化的检查过程，这鼓励了更严格的判断，正如先前工作[Kim2023prometheus]所报告的那样。

最后，方法4和MESSALA之间的比较表明，两种方法在不同模型下始终产生接近人类评估的结果，展示了多视角评估的益处。此外，MESSALA优于方法4，表明简单地聚合多个评估是不够的。这些结果强调了对分析报告进行稳定和实际的评估需要在细粒度指导方针引导下整合高级和深度评估。

表5：闭源模型（左）和开源模型（右）的比较分析。

(a) 闭源模型

模型	方法	ρ	τ	r	RMSE
gpt-4o	方法1	0.54	0.46	0.54	1.16
	方法2	0.51	0.42	0.51	1.05
	方法3	0.49	0.40	0.49	1.27
	方法4	0.55	0.45	0.53	1.01
	MESSALA​	0.58​	0.49​	0.58​	1.04​
gpt-4.1	方法1	0.63	0.53	0.61	1.27
	方法2	0.60	0.50	0.57	1.07
	方法3	0.49	0.40	0.49	1.30
	方法4	0.60	0.50	0.60	0.97
	MESSALA​	0.64​	0.53​	0.64​	0.88​

(b) 开源模型

模型	方法	ρ	τ	r	RMSE
gpt-oss (20B)	方法1	0.56	0.44	0.55	1.27
	方法2	0.41	0.33	0.39	1.56
	方法3	0.56	0.43	0.54	1.16
	方法4	0.46	0.36	0.44	1.34
	MESSALA​	0.59​	0.46​	0.59​	1.13​
qwen3 (14B)	方法1	0.56	0.44	0.55	1.01
	方法2	0.52	0.40	0.51	0.97
	方法3	0.50	0.39	0.49	1.00
	方法4	0.57	0.44	0.56	0.93
	MESSALA​	0.58​	0.46​	0.56​	0.97​

(a) GPT-4.1各方法得分的提琴图。

(b) GPT-4.0各方法得分的提琴图。

图3：​ 提琴图展示了每个模型产生的各方法评估分数的分布，与人类黄金标准评估进行比较。

5.3 对RQ2的回答

对于所有指标，MESSALA始终优于所有基线方法：特别是，它实现了与人类黄金评估最高的相关性，同时表现出最低的分数偏差和分布差异。这些结果表明，凭借MESSALA，LLM可以根据专家评分定量评估分析报告，作为对RQ2的回答。

6 LLM反馈评论的定性评估

在本节中，我们针对MESSALA生成的反馈评论进行定性评估的实验。此评估的目标是确定LLM能否从SOC从业者的角度产生可操作且有意义的反馈。本实验解决RQ3。为此，我们设计了两个互补的评估。第一个评估遵循先前工作[zubaer2025gpt]，从定性角度考察LLM对分析报告生成的反馈评论对人类专家和LLM的有用程度。第二个评估使用由注入缺陷的分析报告组成的数据集，考察LLM是否能正确指出分析报告中的缺陷作为反馈。

6.1 人类专家和LLM法官的多指标评分

我们描述由人类分析师和LLM评估的多指标评分，作为对LLM生成的反馈评论的定性评估。

6.1.1 实验设置

3名参与者（用户ID 1、2和5）参与了此评估，他们也参与了第3节描述的访谈。他们是作者所属机构SOC的资深分析师和管理者，属于不同的SOC领域，例如工厂、建筑和家电。每位参与者被分配了6份不同的分析报告，包括来自三个领域各两份报告，从而评估了18份分析报告的反馈评论。每份报告的任务限制在大约10-15分钟内，每位参与者的总任务时间大约为一小时，以减少他们的工作量。我们还对整个数据集应用了相同的LLM评估，这是辅助人类评估的常见方法[zubaer2025gpt]。这个额外的评估使我们能够在人类分析师的结果方面获得更稳定的结果。

考虑到第3节的访谈，我们采用了以下指标：整体有用性来衡量反馈的实用性；准确性与有效性来衡量反馈的精确性；具体性与明确性来衡量反馈的可操作性；以及支持新手/资深人员来衡量反馈如何支持从新手到资深不同经验水平的分析师。我们使用五点李克特量表对上述指标进行了用户问卷调查，其中"1"表示"非常低"，"5"表示"非常高"。参与者还可以提供自由文本评论来解释他们的评分。我们还利用了上一节描述的方法1作为基线，其中LLM为GPT-4o和GPT-4.1，并计算了它们结果的平均值。

LLM的反馈评论

我们将反馈评论的长度限制在500个token以内，通过总结从每种方法得出的结果。虽然如前所述，MESSALA有时会生成信息过度的反馈评论，但对用户来说适量的反馈大约在500-700个token[zhou2024llm, liang2024can]。在总结过程中，我们关注低分项。虽然反馈的最佳实践[hattie2007power]通常建议包含积极的评论以支持用户动机，但分析报告通常需要快速行动。因此，此评估中的反馈评论仅限于分数小于等于"3"的检查清单项，使用以下提示："基于以下评估结果，生成用于改进报告的反馈评论，不超过500个token。尽可能保留原始评估的信息，具体描述问题，并且不要添加任何新信息。"

6.1.2 结果

表6：基于LLM评估结果的人类和LLM评分（1-5）。

用户反馈方面	人类评估		LLM评估
	方法1	MESSALA	方法1
整体有用性​	3.00	4.00	4.03
准确性与有效性​	4.00	3.67	4.15
具体性与明确性​	2.67	4.67	4.03
支持新手​	4.00	4.67	3.48
支持资深人员​	3.00	3.67	4.08

结果如表6所示。我们还在附录0.E中展示了LLM生成的反馈示例。总体而言，除了"准确性与有效性"，MESSALA获得了更高的评分。我们在下面描述了每个指标的原因。

整体有用性：MESSALA被评为比方法1更有用，因为它更清晰地指出了分析报告中的具体改进点。正如一位参与者指出的："与方法1相比，MESSALA的评估和改进建议更具体、更容易理解。" – 用户ID 1。相比之下，方法1的反馈可读但常常不一致且笼统："报告简洁易懂，但其反馈与MESSALA相比缺乏一致性，降低了其有用性。" – 用户ID 5。

准确性与有效性：方法1以4.0分略高于MESSALA的3.67分。尽管其反馈仍然停留在表面，但通常是合理的，很少有错误或矛盾，这促成了有利的判断。而MESSALA更详细，但有时关注参与者认为次要的问题，导致分数略低："MESSALA有时过度强调次要问题，导致对不太重要的点反馈过于详细。" – 用户ID 5。总体而言，MESSALA可以提供详细的评估，但仍然难以从人类分析师的角度优先处理最关键的问题。每个检查清单项的更细粒度指导方针可能会改善这一点。

具体性与明确性：MESSALA在此指标上优于方法1。参与者评估了反馈评论如何将每个关键点与其建议对应起来，使得LLM输出更容易转化为可操作的项目："在MESSALA中，关键点和改进建议是一一对应的，使得行动项易于推导。" – 用户ID 5。方法1合理但常常缺乏评估和反馈之间的明确联系，其措辞有时模糊。参与者更喜欢更直接的表达，如"缺失"、"不清晰"或"不足"："需要更直接的反馈——例如'缺失'、'不清晰'或'不足'——而不是模糊的评论。" – 用户ID 2。

支持新手和资深人员：MESSALA在支持新手和资深分析师方面也获得高于方法1的评分。其反馈针对关键点进行了结构化，因此新手分析师可以快速识别报告的哪些部分应该修改："因为MESSALA的反馈集中且简洁，对于新手来说比方法1更容易理解，后者需要阅读全文才能理解。" – 用户ID 2。对于资深分析师，来自MESSALA的一对一反馈比方法1更容易提取相关信息。然而，参与者指出，两种方法都倾向于误解技术术语并依赖间接表达，突显了LLM需要更强的领域专业知识："两种方法有时会独立解释技术术语，这模糊了它们的本意，尽管它们提取了隐含信息，但在提高报告质量方面，它们的反馈不如人类专家直接和有针对性和直接性。" – 用户ID 5

6.2 对注入缺陷的分析报告的评估

本节对注入缺陷的分析报告进行评估，以考察每种方法如何识别和解释缺陷及其原因，遵循先前的工作[liu2023reviewergpt, d2024marg]。为了有效地评估分析报告，一种方法必须准确识别报告中需要改进的具体点以完善报告。先前的工作[liang2024can]指出一个局限性，即LLM的评估有时过于宽松，可能无法突出关键缺陷。因此，我们的目标是调查MESSALA是否能减轻这种局限性，并提供更具可操作性和有意义的反馈。

6.2.1 注入缺陷的分析报告

注入缺陷的分析报告数据集旨在评估LLM是否能准确识别分析报告中的缺陷。它包含在SOC环境中观察到的具有现实缺陷的报告：例如，缺失上下文信息、判断理由不足、有缺陷的因果推理以及不明确或不切实际的响应描述。该数据集还定义了缺陷类别及其参考审阅评论。这些参考审阅评论用于评估LLM是否能生成适当的反馈。

注入的缺陷被明确标记，因此可以可重现地对报告进行评估。这里，我们将缺陷定义为至少缺少或不满足第3节导出的11个评估视角中的一个。基于先前工作[liu2023reviewergpt, d2024marg]中的缺陷类别以及从作者所在组织SOC收集的参考审阅评论，我们将原始的11个评估视角合并为4个缺陷类别，并经过SOC从业者确认。表7显示了4个缺陷类别与11个视角之间的对应关系。

表7：缺陷类别及其对应的面向从业者评估视角

缺陷类别	简要描述	相关的评估视角
不透明的决策理由​	关键判断和结论缺乏充分的理由或连贯的推理，削弱了对最终评估的信心。	(1), (10), (4)
不可验证或片面的分析​	在没有充分验证（如基线、比较或替代解释）的情况下提出分析主张。	(8), (10), (4)
无视上下文的技术解释​	在没有充分考虑现场上下文（如资产角色、操作背景或约束）的情况下解释技术观察。	(5), (6), (7), (9), (4)
不可操作的结果呈现​	分析结果未能转化为具体的、有优先级的行动或清晰阐明的影响和升级含义。	(2), (3), (11), (4)

此外，遵循这些类别，我们将缺陷注入报告中，期望LLM生成反馈以捕捉与缺陷对应的参考审阅评论。此类参考审阅评论源自真实分析报告，例如："报告没有解释通信发生的原因，也没有评估通信或相关终端是否异常。"我们选择了人类分析师和LLM都认为高质量的分析报告子集来注入缺陷。然后，根据预定义规则修改每份报告，以注入上述缺陷类别中的一个或多个缺陷。在上述注入过程中，仅修改了每份分析报告的相关部分，同时保留了整体结构和写作风格。这些数据集使用LLM构建，其输出由作者审阅和完善，缺陷样本通过SOC从业者的审阅进一步确认。我们最终使用了44份分析报告作为数据集。

我们进行了初步验证，以确认由注入缺陷引起的分析报告质量下降是可测量的。对于每个缺陷类别，我们比较了来自同一原始报告的干净和注入缺陷分析报告的评估分数，然后确定在相应的评估视角上分数是否下降，而不相关评估视角的分数保持不变。缺陷注入和验证是独立进行的，LLM在没有访问缺陷标签或人工验证结果的情况下进行评分。

6.2.2 实验设置

我们使用上述注入缺陷的分析报告数据集来检验每种方法如何识别分析报告中的缺陷。我们关注它是否能生成超出表面缺陷检测的反馈，并捕捉根据参考审阅评论应该改进的问题。

评估针对LLM为每份注入缺陷的分析报告生成的反馈评论。我们通过人工检查评估这些评论是否捕捉到了参考审阅评论。具体来说，每个反馈评论被分为三个级别：(1) 明确覆盖：它充分捕捉了参考审阅评论；(2) 部分覆盖：尽管关注点和措辞不同，但它部分捕捉了参考审阅评论的基本部分；(3) 未覆盖：它没有捕捉到参考审阅评论的任何内容。判断评论是否覆盖缺陷的标准由作者事先商定。作为基线，我们使用第5节描述的方法1。与此基线进行比较使我们能够评估MESSALA如何生成更有意义的反馈。

表8：覆盖结果（左）和缺陷检测细分（右）。

(a) 参考审阅评论的覆盖情况

方法	明确覆盖	部分覆盖	未覆盖
MESSALA	29	9	6
方法1	16	15	13

(b) MESSALA：缺陷类别细分

类别	部分覆盖 / 明确覆盖	未覆盖
不透明的决策理由	10	2
不可验证 / 片面	7	2
无视上下文	12	2
不可操作的结果	9	0

6.2.3 结果

表8展示了所有方法的缺陷识别结果。MESSALA识别了86.4%的注入缺陷，在所有缺陷类别上都超过了方法1。这种性能差异反映了每种方法在评估结论、支持证据、上下文信息和与决策相关的行动之间的关系方面存在系统性差异。

不透明的决策理由

此类别捕获评估是否需要从观察到结论的明确且可追溯的推理，而不是仅接受结论本身。

方法1经常给明确陈述结论的报告打高分，即使没有解释根本原因或技术理由。在图4中，方法1评估一份报告为充分，因为它提到了设备角色和相关漏洞，尽管缺乏将这些因素与具体操作影响联系起来的解释。

相比之下，当缺少这种可追溯性时，MESSALA分配较低的分数。如图4所示，MESSALA指出，报告没有解释所识别设备的异常或状态变化将如何影响建筑运营，即使存在技术上正确的描述。这种行为反映了MESSALA要求结论必须由明确证据和可解释的推理支持。

不可验证或片面的分析

此类别区分评估是倾向于看似合理的叙述，还是要求可验证和可重现的分析过程。

方法1倾向于接受内部一致且在操作上看似合理的解释，即使这些解释的分析基础没有记录。在图5所示的示例中，方法1接受了基于高层操作解释的误报判定，而没有检查通信发生的原因。

相比之下，MESSALA通过明确质疑缺失的通信因果关系和终端行为分析分配较低的分数。如图5所示，MESSALA指出报告未能证明观察到的流量模式如何对应于合法的业务活动，从而将不可验证的推理视为缺陷，而不是可接受的合理性。

图4：评估评论比较：不透明的决策理由类别

方法1

…

报告指出，IP地址为XXX的设备很可能是一台带到现场的维护笔记本电脑，并明确请求确认其是否为合法的维护设备。此外，报告包含了与BA服务器上运行的工业软件WebAccess Node相关的漏洞信息，部分解释了设备的关键性和相关风险。

…

MESSALA

…

• 检查点X。设备角色和关键性的清晰度：…

• 检查点Y。基于设备关键性的影响描述：在"对建筑的潜在影响"部分，报告提到了漏洞的存在以及如果设备不合法可能受到网络攻击的可能性。然而，它对这些设备的异常或状态变化将如何具体影响建筑运营的解释有限。影响评估停留在高层的风险指示，缺乏对操作后果的详细描述。

  …

图5：评估评论比较：不可验证或片面的分析类别

方法1

…

报告基于现场操作上下文（如受影响的产品是否在使用中、目的IP地址是否用于业务目的）解释了为什么检测到的警报被认为是误报以及为什么不需要响应。它假设这些高层操作解释的有效性，而没有质疑通信发生的原因，或者通信本身或相关终端是否表现出异常行为。它还描述了一个具体的缓解行动，即白名单，展示了一种与实际操作实践一致的解释。

…

MESSALA

…

• 检查点X。具体操作上下文的验证：…

• 检查点Y。误报判定中理由和责任性不足：警报基于高层陈述（如"这没有问题"或"受影响的产品未在使用中"）被判定为误报，但这些主张并未建立在具体解释实际操作上下文或系统架构的基础上。此外，尽管IDS检测到异常通信模式（例如，构造的双字节字符），但报告未能解释这些模式如何对应于——或偏离——合法的业务通信。相反，它仅仅断言流量"被确认为用于业务目的"，而没有提供足够的技术或上下文理由来支持误报判定。

  …

对于上下文无关的技术解释和不可操作的结果呈现类别也观察到了类似的现象（表LABEL:tab:breakcate）。方法1通常在技术描述准确或全面时给报告打高分，即使其反馈评论既不包含充分的上下文，也没有可操作的项目。相比之下，MESSALA始终给那些不顾上下文解释的报告打低分，即使解释在技术上是正确的，以及给没有决策可操作项目的评论打低分。

6.3 对RQ3的回答

我们的结果表明，MESSALA可以定性评估分析报告，并根据评估标准生成与人类专家一致的反馈评论。在多指标评分中，MESSALA生成的反馈评论在除准确性与有效性外的所有类别中都持续获得人类专家的更高评分，这表明LLM可以作为可操作且有意义的反馈评论来近似人类分析师的判断视角。

7 局限性与伦理考量

7.0.1 局限性

我们的研究有一些局限性，需要在未来的工作中解决。首先，我们使用了私有数据集进行分析报告。虽然伪分析报告也被用于支持可重现性，但报告数量及其长度有限，因此我们需要将其扩展到更广泛的环境中。其次，分析师视角检查清单包含大量项目，重要的评估项目可能因报告而异。未来的工作将集中于自动选择这些项目的机制，尽管本文中是手动选择的。第三，参与人类黄金评估的SOC从业者数量有限。为了确认MESSALA在现实环境中减少分析工作量和提高分析报告质量的影响，我们还需要与更多参与者进行进一步的调查。最后，本文中的评估视角，包括指导方针和缺陷类别，是基于文献综述和与从业者的半结构化访谈，并未完全覆盖所有现实世界SOC的评估过程和缺陷模式。我们正在完善来自多样化操作上下文的反馈。

7.0.2 伦理考量

我们在下面讨论访谈和分析报告中的伦理问题。

访谈：​ 关于本研究中的访谈数据，我们事先向参与者告知了研究目标、访谈程序、数据使用范围和隐私保护政策，并获得了他们的同意。参与者是志愿者，我们在上述知情同意下解释了他们可以在任何时候退出而不会受到任何不利影响。访谈的录音仅用于转录和为既定研究目的进行定性分析，并存储在仅作者可访问的本地环境中。在编码过程中，我们移除了任何可能导致重新识别的信息，如个人和组织名称（包括其项目细节），并仅使用假名ID进行匿名化处理。

分析报告：​ 在本研究中使用分析报告之前，我们向负责SOC的利益相关者解释了有关保密性和研究伦理的以下几点，并获得了进行实验的同意。根据数据最小化原则，两位作者手动匿名化了敏感信息，如专有名称，并检查了个别设备和组织可能被重新识别的风险。只有经过处理的数据才被提交给我们所属机构有正式合同的LLM服务（即禁止二次使用、第三方提供和数据保留），并获得了安全批准。即使在作者所属机构内部，也禁止访问数据以及在本研究范围之外的任何使用，从而降低了实验产生的风险。

8 结论

在本文中，我们讨论了使用LLM对SOC中的分析报告进行评估。为此，我们首先通过文献综述和与SOC从业者的访谈，从人类专家的多个视角识别SOC分析报告的评估标准，构建了分析师视角检查清单，作为对RQ1的回答。接下来，我们设计了MESSALA，除了分析师视角检查清单外，还进一步引入了细粒度指导方针和多视角评估LLM。MESSALA可以从人类SOC从业者的视角最大化分析报告的评估效果并提供反馈评论，作为对RQ2的回答。我们还利用MESSALA对分析报告进行了广泛的定量评估实验，然后证明与基线方法相比，MESSALA能提供最接近SOC从业者的评估结果。最后，我们利用LLM对分析报告的反馈评论进行了另一项定性评估实验。然后我们表明，MESSALA可以根据评估标准定性评估分析报告并生成与人类分析师一致的反馈评论，作为对RQ3的回答。我们计划在更多样化的设置下进行进一步的实验，包括更大数量的样本和来自多样化操作上下文的反馈评论，以及在现实世界SOC环境中的部署。

附录

附录0.A 用户研究和定性分析的问题表

我们使用了表9和表10中所示的问题表。

表9：用户背景和初步用户研究问题表

类别	编号	摘要
用户信息​	1-1.	您从事安全警报分析有多少年经验？
	1-2.	您负责哪些安全监控领域？（IT（各行各业）、IoT（工厂、电力、汽车等））
	1-3.	SOC的角色是什么？
	1-4.	您的专业是什么？（网络安全、软件工程、计算机科学等）
	1-5.	您主要覆盖哪些类型的安全警报？
	1-6.	您向客户提供哪些类型的报告？
	1-7.	您向客户报告的频率是多少？
	1-8.	创建安全警报分析报告的过程是怎样的？
	1-9.	您从哪里获取创建报告所需的信息？（例如，SIEM、日志管理系统、手动调查）
	1-10.	创建一份报告需要多长时间？
初步用户研究​	2-1.	您使用什么工具或自动化系统来提高报告创建效率吗？如果有，是什么？
	2-2.	您在创建报告时对所使用工具有什么不满或挑战吗？如果有，是什么？
	2-3.	在不久的将来，即使不能完全自动化，您认为哪些工具支持会有用？
	2-4.	您认为报告中有哪些部分可以自动化？反之，哪些部分难以自动化？
	2-5.	您在创建报告时对使用LLM有很高的期望吗？您如何看待将LLM用于报告？
	2-6.	您是否致力于建立通用的报告格式和模板？如果没有，是什么阻碍了格式的统一？
	2-7.	虽然报告项目在一定程度上是固定的，但详细内容是否因事件不同而有很大差异？是否因为依赖经验而难以描述细节？
	2-8.	您是否从客户或资深分析师那里获得了关于报告内容的充分反馈？如果有，您收到了哪些评论？
	2-9.	在审阅他人创建的报告时，您使用什么标准来判断其质量？
	2-10.	您认为评估分析报告的主要挑战是什么？
	2-11.	您认为分析报告最重要的部分是什么？
	2-12.	哪些类型的报告项目使决策更容易？
	2-13.	您认为您创建的报告与理想状态相比足够好吗？如果不够，主要原因是什么？（例如，时间限制、信息缺乏）
	2-14.	现场的上下文信息在报告内容中重要吗？如果是，为什么？以及处理此类信息存在哪些挑战？
	2-15.	由于内容或收集和组织过程的原因，哪些类型的信息使报告创建变得困难？
	2-16.	您觉得报告的哪些方面特别具有挑战性？

表10：LLM生成报告的用户反馈评估项

类别	编号	摘要
整体有用性​	F-1.	您认为LLM生成的反馈对分析师整体上有用吗？
准确性与有效性​	F-2.	反馈是否准确识别了报告中的错误或缺失信息？它与专家级别的反馈契合程度如何？
具体性与明确性​	F-3.	评估是否提供了具体的改进点和可复现的建议？
支持新手​	F-4.	即使对于新手分析师，反馈是否易于理解且有帮助？
支持资深人员​	F-5.	反馈对于资深分析师仍然有用吗？

附录0.B 分析师视角检查清单项

我们使用了表11和图12所示的检查清单项。

表11：分析师视角检查清单项类型示例。此检查清单总结了典型安全事件分析报告中应确认的基本项。标记为“可选”的额外列指示该项是否根据事件上下文有条件地要求——例如，某些项可能主要由专门的安全事件响应团队（SIRT）处理。

报告内容类别	检查清单项类型	详情	可选
事件的技术理解与根源澄清​	基本警报信息	基本警报元数据，如时间戳、警报名称、警报ID以及触发事件的检测系统。	否
	事件描述与解释	对观察到事件的清晰描述和解释，包括发生了什么、如何被检测到以及为何被视为相关。	否
	根本原因	识别并解释导致事件的根本技术或人为原因。	否
	事件来源	事件的来源，例如攻击源、发起资产、用户或涉及的外部实体。	否
	受影响系统	受事件影响或可能受影响的系统、资产、服务或环境。	否
	通信详情	可疑或相关通信的细节，包括终端、协议、目的地、内容特征和频率。	否
	漏洞信息	与事件相关的已知或可疑漏洞的信息（如适用）。	否
决策支持与行动计划​	影响评估	对事件的操作影响、严重性、业务相关性和相关风险的评估。	否
	确认请求	需要接收方对此事件确认的具体项目或问题。	是
	响应行动	已采取或建议的具体响应行动及其优先级、必要性和预期效果。	否
	复发预防与经验教训	为防止类似事件再次发生而提出的措施或建议，以及从事件中吸取的经验教训。	是
调查与分析过程的责任性与质量保证​	调查与分析方法	使用的分析技术、工具、假设和决策标准的描述。	否
	证据与支持数据	支持观察或结论的证据及其来源、获取方法和可靠性说明。	否
	相关策略、指南与标准	与事件分析相关的内部政策、外部指南、法规或标准的引用。	是
	分析状态	当前分析进度和计划或建议的后续步骤。	否