为什么平均修复时间并不总是有用的安全指标

为什么平均修复时间并不总是有用的安全指标

为什么平均修复时间并不总是一个有用的安全指标 PlatoBlockchain 数据智能。垂直搜索。人工智能。

安全团队传统上使用 平均维修时间 (MTTR) 来衡量他们处理安全事件的效率。 然而,事件严重性、团队敏捷性和系统复杂性的变化可能会使该安全指标变得不那么有用,Verica 的首席研究分析师和该报告的主要作者考特尼纳什说 打开事件数据库 (VOID) 报告。

MTTR 起源于制造组织,用于衡量修复故障物理组件或设备所需的平均时间。 这些设备具有更简单、可预测的磨损操作,有助于对 MTTR 进行合理标准和一致的估计。 随着时间的推移,MTTR 的使用已扩展到软件系统,软件公司开始将其用作系统可靠性和团队敏捷性或有效性的指标。

不幸的是,Nash 说,它的可变性意味着 MTTR 可能导致错误的信心或引起不必要的担忧。

“对于复杂的软件系统来说,这不是一个合适的指标,部分原因是持续时间数据的分布不均,而且此类系统中的故障不会随着时间的推移均匀出现,”Nash 说。 “与物理制造设备的问题不同,每次故障本质上都是不同的。”

远离 MTTR

“[MTTR] 几乎没有告诉我们一个事件对组织的真实情况,这在涉及的人员和团队数量、压力水平、技术和组织上需要什么来修复它,以及什么方面可能会有很大差异团队从中学到了东西,”Nash 说。

Jeli 的首席执行官兼联合创始人 Nora Jones 说,MTTR 是事件过度简单化的牺牲品,因为它计算的是平均时间——平均时间。 简单地测量报告时间的这个单一平均值(并且这些报告时间也被首先证明是不可靠的)会阻止组织看到和解决基础架构中发生的事情,导致重复发生的事件的原因以及人们如何响应事件。

“事件的形式和规模各不相同——您会看到它们在严重性、对客户的影响和解决方案的复杂性方面跨越了整个范围,所有这些都在一个组织内,”Jones 解释道。 “你真的必须同时审视人员和工具,并采用定性方法进行事件分析。”

然而,Nash 说摆脱 MTTR 并不是一蹴而就的——它不像将一个指标换成另一个指标那么简单。

“归根结底,要诚实地说明影响因素,以及人们在提出解决方案时所扮演的角色,”她说。 “这听起来很简单,但需要时间,而这些都是将建立更好指标的具体活动。”

扩大指标的使用范围

纳什说 分析事件并从中学习 是寻找更有洞察力的数据和指标的理想途径。 一个团队可以收集诸如参与事件的人数之类的信息; 有多少独特的团队参与其中; 人们使用了哪些工具; 有多少个聊天频道; 以及是否有并发事件。

随着组织越来越善于进行 事件回顾 并向他们学习,它将开始在参加事后审查会议的人数、增加阅读和共享事后报告以及在代码审查、培训和入职等方面使用这些报告等方面产生吸引力。

Cyentia Institute 的高级安全数据科学家 David Severski 表示,在研究 Verizon DBIR 时,Cyentia 创建并发布了事件报告和事件共享词汇表,以扩展用于衡量事件的指标类型。

“它定义了我们认为对收集安全事件很重要的数据点,”他说。 “我们在 Cyentia 研究中仍然使用这个基本模板,并进行了一些更新,例如识别使用的 ATT&CK TTP。”

衡量事件的指标并不是适用于所有组织规模和类型的一刀切。 琼斯说:“团队了解他们今天所处的位置,评估他们在当前限制范围内的优先事项,并了解他们的重点指标甚至可能随着组织的发展和扩展而随着时间的推移而演变。”

此外,它是关于将重点转移到学习上,然后根据这些学习不断改进,例如转移到评估趋势以及事情是否随着时间的推移朝着正确的方向发展,而不是单一的时间点指标。

时间戳记:

更多来自 暗读