如何为安全运营指标构建坚实的基础
安全运营经理需要报告威胁检测、调查和响应计划的有效性,但难以驾驭大量潜在的 SOC 指标。本研究提供了设计针对 SOC 的指标系统的示例和实践。
主要发现
-
需要清晰、一致的衡量标准来向董事会成员或服务提供商等更广泛的团队传达安全运营中心的效力和效率。
-
SOC需要如何测量、测量什么以及如何确定基准结果,需要采用系统的方法。
-
在报告指标时,重要的是要考虑尽管威胁暴露状况和 IT 基础设施发生了变化,工具和团队是否仍能继续达到预期的水平。
建议
负责衡量 SOC 性能的安全运营经理应该:
-
通过记录每个团队所需指标的参数来构建指标策略的基础。这包括定义成功并验证联系相关利益相关者所需的数据。然后可以持续跟踪结果并将其呈现给适当的受众。
-
使用关键绩效指标验证指标,认识到指标可能需要随着组织的成熟而发展。在各个层面,收集每个告警或用例的数据时都要有条不紊、细致入微。反过来,这可以重新构建以满足不同受众的需求。
-
迭代流程以推动战略和战术决策的变革。使用指标来确定工具和分析师之间的差异,让 SOC做出调整,提高可见性和成熟度。
概述
现代安全运营中心 (SOC) 根据其各自的安全用例或威胁检测和调查响应 (TDIR) 程序涵盖越来越多的指标。指标提供了改进 SOC 技术能力、培训和发展员工以及了解效率潜力的机会。它们还可用于证明安全团队的存在以及额外预算或资源的必要性,以及其他战术、运营和战略举措。一些指标每天都相关,而其他指标可能每年只用到几次,例如在审计或取证期间。
创建一个详尽的测量列表来跟踪每个告警、流程或载体是不切实际的。相反,这项研究为安全运营经理提供了利用KPI来定义、验证和迭代指标流程的策略。
分析
构建SOC 关键绩效指标
指标饱和是 SOC 未能为指标计划设计正确基础的常见问题。基础不应仅基于告警数据;它应该推动运营商和利益相关者需要做出的关键决策。有多种方法可以确定指标,无论是构建自己的指标还是使用第三方信息。
在2024 年 Gartner设计和构建现代安全运营调查中,约五分之二 (39%) 的 SOC 报告称他们正在开发自己的指标,另有三分之一 (35%) 的 SOC 使用供应商提供的指标,这些指标会持续且定期进行测量。近五分之三 (57%) 的受访者表示,安全运营指标对于推动网络安全决策非常有效。
为了正确定义 SOC 指标,管理人员需要确定要跟踪的适当 KPI。KPI 显示了 SOC 中完成的工作与利益相关者的安全目标之间的关系,以及对 SOC 的投资如何抵御最新威胁。这些应该包括:
-
分析师表现
-
SOC 和分析师总体工作量
-
每次告警的告警检测和补救时间(例如MTTD/MTTR)
-
告警升级率(使用 SOC 服务提供商时很重要)
-
每日告警量
-
事故解决率
-
工具和告警性能(误报率/误报率)
-
安全工具ROI (投资回报率)
对于告警补救时间,每个告警必须有一个标准化流程,每个分析师都必须平等遵循。否则,指标将有很大差异,可能导致结果无效。
缺少每个告警的指标和/或所有告警的报告也会使结果产生偏差,因为补救时间较长的告警会将补救时间较短的告警拉向末尾,反之亦然。
请注意,数据集和用例之间总是存在一些重叠,这意味着可能会收集一些用于不同指标的数据。安全运营主管应确定需要哪些指标或 KPI 来正确衡量绩效并满足业务需求。表 1显示了指标与可以利用的 KPI 之间的关系。
表1 :SOC KPI 和相关指标
关键绩效指标 | 衡量指标 |
分析师表现 | 根据每个告警的平均 MTTR(平均响应时间) |
SOC 和分析师的工作量 | 根据工作时间和非工作时间的回应 |
告警升级率 | 根据上报给更高级别分析师的告警百分比 |
告警音量 | 根据每日告警总量 |
工具和告警性能 | 根据假阳性/阴性率 |
事故解决率 | 根据已解决事件占总报告事件的比例 |
安全工具投资回报率 | 根据事件迁移和事件成本 |
来源:Gartner(2025 年 1 月)
需要注意的是,出色的 KPI 结果并不意味着 SOC 能够检测和应对所有威胁。这些结果通常表明 SOC 按照设计在特定监控目标下表现良好。
SOC KPI 旨在与一组特定的监控目标(而非所有可能的威胁)保持一致,以便 SOC 经理更好地了解其运营情况。例如,两个监控目标可能是确定新告警产生额外分析师工作量的误报率,或分配给更高级别分析师的告警升级率。
KPI 未涵盖的攻击和威胁可以由其他指标涵盖,但不应影响 KPI。然而,此类攻击和威胁应该引发有关是否需要资金来实施新监控目标的讨论。
SOC 经理需要了解,某些 KPI 需要更精细的粒度才能实现其目的,具体取决于其受众。董事会成员可能不需要了解分类每种类型的告警需要多长时间,也不需要了解正在监控的全部告警范围。然而,在 SOC 级别,这成为强制性要求。
优秀的 KPI 结果并不意味着 SOC 能够检测和应对每一种威胁;它们只与特定的安全监控目标有关。
使用 KPI 来验证指标
好的指标与其目标直接相关。如果目标是绩效,则指标可能会衡量固定时间段内的时间和改进情况,它还需要突出趋势和异常值。在这方面,SOC 指标与可能应用于业务流程或员工的任何其他指标没有什么不同。然而,与这些指标相关的各个问题类别的多样性以及网络安全领域的发展速度,使得在需要可运营结果时测量 SOC 变得更加困难。
虽然可以制定指标来惩罚表现不佳或发现表现不佳的服务提供商,但这不应该是其最初目标。衡量员工和/或服务提供商的表现很重要,但使用指标来施加惩罚可能会导致不正当的激励,其目的是改进指标报告的内容,而不是改进流程或服务。
创建有效的结果驱动指标的机制必须始终基于四个相互关联的重点领域。
-
目标问题:指标应始终有一个有效且相关的目标问题,并客观地寻求改进流程或团队/个人的工作绩效。
-
范围/边界:计算指标时应该设定边界和要衡量的特定范围。
-
计算方法:数据必须格式和内容一致,并在合理的时间内可用。
-
时钟方面:每个指标都必须提供数据捕获和分析的开始和结束时间段。
一致性很重要,主要是数据和时间方面的一致性。更改特定指标的计算方法会调整核心方法,并可能使历史比较具有误导性或不相关。应对数据应用多个时间测量,以确保人为截止期不会对结果产生误导。例如,当变更过程具有每月周期时,每周测量应用的漏洞补丁将显示三周的低活动性和一周的高活动性。结果将无法反映流程性能的真实性质。
测量时间特征应始终与上下文指标相结合。例如,在测量 SOC 分析师正确识别真阳性的能力时,重要的是要考虑工作人员对特定检测输出的偏好以及所呈现信息的复杂性。
因此,始终建议根据检测源安全信息和事件管理器 (SIEM) 规则或分析名称以及发现的类别或事件(例如MITRE Att&ck 技术)对基于时间的性能指标进行分组。通过这样做,管理层可以确定特定告警输出的偏好(以及它提供的详细程度)并衡量分析师对特定威胁类别(如命令和控制渠道)的知识广度。目的应该是回答设定的问题,以提高 SOC 的相关性、质量、速度和可操作性。以下是一些设定问题的示例及其解决方法:
-
哪位分析师拥有最广泛的威胁知识并应该受聘来培训更广泛的团队掌握分类技术?
-
哪条 SIEM 规则最容易分类? 哪些包含的上下文数据对此过程贡献最大?
-
SOC 的哪些输出对于其他业务部门来说容易/重要的采取行动?
设定问题通常针对以下三个主要领域之一的要求。这些包括:
-
SOC 组织的效率及其生产力(或为增强此功能而提供的服务的价值)
-
内容的相关性和准确性(例如关联规则或分析)
-
安全工具投资的价值(例如 SIEM、端点检测和响应或扩展检测和响应平台 -见表 2)
这些指标域必须旨在衡量工作人员(例如 SOC 分析师)或分析团队,包括网络运营中心 (NOC)、参与流程的服务提供商或工具投资。了解要衡量的目标群体是了解使用什么指标的关键。应该注意的是域,甚至单个指标,在按不同数据分组时可以衡量多个目标。表 2 列出了 SOC 可用于跟踪变化的指标类别列表、会发现数据有用的预期目标以及用于收集数据的潜在指标或 KPI。
表2 :域与指标的配对
衡量指标域 | 目标 | 示例指标 |
SOC效率/生产力 | 员工/服务 | 平均响应时间 (MTTR) |
内容相关性/准确性 | 员工/工具 | 转化率——告警量与事件量之比 |
安全工具投资回报率/价值 | 工具 | 避免的入侵数量 |
来源:Gartner(2025 年 1 月)
通过思考指标的预期结果,并考虑使这些发现可付诸行动所需的粒度,可以制定一套指标和关键绩效指标,这些指标和绩效指标对业务和安全运营团队有切实的好处。指标的特征应围绕改进工具配置、流程或员工的目标和目的进行具体设想,如表 3 所示。
表3 :每个目标的最佳指标
衡量指标 | 目标 | 预期成果示例 |
平均判决时间 ( MTTV ) | 职员 | 更好地理解:
|
平均修复时间 | 职员 | 更好地理解:
|
平均诊断时间 | 工具 | 更好地理解:
|
平均控制时间 (MTTC) | 服务 | 更好地理解:
|
告警转为事件的转化率 | 工具 | 更好地理解:
|
事故到补救的转化率 | 职员 | 更好地理解:
|
来源:Gartner(2025 年 1 月)
做出调整以提高可见性和成熟度
有三个主要领域可以确保指标不断发展,满足 SOC 提高可见性和展示成熟度的需求。对指标进行的迭代需要确保测量的一致性,而目标可能会调整以与任何新的业务驱动目标保持一致。下面概述了三个主要领域。
功能对齐
指标衡量团队和工具对更广泛的业务使命的整体绩效和影响。同样重要的是要考虑指标如何描述 SOC 提供的特定功能,以及每个功能的单独影响。
-
SOC 运营的内部功能应反映在任何指标的元数据中,例如工作流程不同阶段所花费的时间(例如威胁情报研究)。
-
应该衡量外部功能。工作流程的影响(例如等待第三方澄清或批准所花费的时间)应该能够识别和区分。
-
还应记录工具的影响、由于不可用而导致的延迟能力不足以及投资的响应时间。
重要的是要让指标能够传达哪些内部或外部功能对生产力和准确性产生积极和消极影响。这样就可以在未来的投资轮次中解决可能出现的变化。
此外,在 SOC 功能的初始设置期间,记录和了解成熟度对新功能建立的影响非常重要。在达到成熟度里程碑之前,衡量团队或工具的直接绩效是没有用的。但是,使用度量指标作为目标将是一种有效的应用。
一般来说,在讨论影响组织的外部功能时,定期趋势报告会很有帮助。但是,指标应该与您可以控制和改进的内部功能保持一致。
指标基线开发
规划如何建立各个指标的基线以及这些基线的更新频率非常重要。基线是用于未来比较的最低标准或起点。标准偏差较高的高度可变指标可能不适合特定基线,您可能需要改用偏差数字。例如,如果响应时间范围比其他时间段更宽,那么在繁忙时段测量变化响应时间的频率可能是一个更有价值的改进描述符。
任何没有基准的测量都将缺乏有效传达影响的背景。SOC 管理应在呈现任何绩效结果之前,努力在一定时间内收集所有指标的一致数据。即使在呈现第一份报告之前从您自己的指标中获得三到六个月的一致数据,也可以帮助为利益相关者提供有意义的背景信息。
另一种常见的比较机制是使用其他类似组织的同类指标。虽然这种方法可能建立得更快,但从同类组织中找到基线数字则更加困难。这是因为在计算不同组织中的指标时,很少会遵循一套标准。
理解和传达指标的变化
利益相关者可能并不总是了解指标逐月变化的增量。这是一个经典问题,很难证明并向企业报告。它可能会引发以下问题:数据显示,上个月我们受到的攻击比这个月少。这对我们组织来说是好事还是坏事?
出现明显差异的原因可能有多种:
-
引入新技术、第三方或订阅
-
重大业务组织变革(合并/收购)
-
软件改进或重大发布(浏览器更新、主要操作系统发布)
-
威胁行为者行为的变化
规划指标的增量,临时调整基线并准备解释。任何指标的重大变化都应包括对变化原因的分析。分析应以数据为导向,而不是以观点为导向。媒体关于某些攻击类型增加的证据,或威胁情报主导的新攻击技术证据,通常可以帮助解释突然的变化。此外,随着技术的老化,或者显然必须添加新技术,分析这项技术如何或为何促成了这种变化是有益的背景,并可以推动高管做出积极的反应。
在讨论路线图上优先考虑 SOC 成熟度的哪些领域时,了解指标变化也会很有帮助。将指标的增量与识别差距联系起来,有助于 SOC 领导者确定为什么应该优先考虑某个路线图项目,并有助于推动变革(图 1)。
图 1.SOC 指标步骤