ASPIRE

衡量安全分析运营的指标

=Start=

缘由：

了解一些最常见的事件指标

在当今永不停机的世界中，中断和技术事件比以往任何时候都更加重要。故障和停机期间会带来现实后果，错过截止时间、付款逾期、项目延迟。

这就是为什么公司必须量化和跟踪有关正常运行时间、停机期间以及团队解决问题的速度和有效性的指标。

业界最常跟踪的一些指标包括 MTBF（故障前平均时间）、MTTR（平均恢复、修复、响应或解决时间）、MTTF（平均故障时间）和 MTTA（平均确认时间），这一系列指标旨在帮助技术团队了解事件发生的频率以及团队从这些事件中恢复的速度。

正文：

参考解答：

一开始在准备写这个主题的时候想写的大而全且尽量深入和通用，但在查阅了大量文档资料之后发现这太麻烦了，而且对我来说必要性不大（但在了解的过程中从指标的定义和设定初衷里还是学习到了很多），虽然说大部分时候你需要用业界通用的名词来定义某个指标，但这其实也不是必须的，对于大部分概念而言，在你要沟通和讨论的文档/会议/公司范围内定义清楚，参与方都认可就行了，不用过于纠结。核心还是要保证最终效果，指标含义定义的再准，文档写的再高大上，说的再天花乱坠，等到出事的时候都是扯淡（不过很多领导其实并不关心这个，他们还是喜欢好看的指标和文档，细节无需关心也不用关心）。

关于 MTTR 的免责声明

我们在谈论 MTTR 时，很容易假设它是一个含义单一的指标。但事实是，它可能代表了四种不同的衡量标准。R 可以代表修复、恢复、响应或解决(Repair, Recover, Respond, or Resolve)，虽然这四个指标确实重叠，但它们都有自己的含义和细微差别。

因此，如果您的团队正在谈论跟踪 MTTR，最好弄清楚他们在说哪个 MTTR 以及他们是如何定义的。在您开始跟踪成功和失败之前，您的团队需要同步了解您正在跟踪的内容，并确保每个人都知道他们在说同样的事情。

MTTRepair：平均修复时间
MTTRecover：平均恢复时间
MTTRespond：平均响应时间
MTTResolve：平均解决时间

几个关键时间点

其实这里有张自己画的图，后面有机会补上

1⃣️事件发生时间 -1-> 2⃣️自动告警/人工反馈时间 -2-> 3⃣️事件发现时间 -3-> 4⃣️分析决策时间 -4-> 5⃣️止损开始时间 -5-> 6⃣️止损完成时间 -6-> 7⃣️问题根治时间

1 - 告警时长 #在真实的世界里，除了要求事件发生之后我们能准确发现（准召率要高），还希望能尽早发现（告警延迟要低），以方便我们尽快介入好降低损失和影响，这就对数据分析和安全策略制定的同学提出了很高的要求（间接的底层的平台能力和数据质量也要足够的好才行，否则巧妇难为无米之炊）。

2 - 确认时长 #直接体现的是值班oncall同学的响应速度和告警系统的有效性，比如值班oncall同学如果关注消息及时，确认时长是几乎可以忽略不计的；还比如严重级别的告警发出去了之后本来应该是秒级别响应的，结果值班oncall同学刚好在和其它同学当面讨论着其它的技术问题没有及时关注消息，这个时候告警系统如果是直接电话通知的，就不会受此情况影响；还有告警升级的问题等等。

3 - 分析时长 #告警确认只是个开始，确认告警很快只能说明值班oncall同学很负责，但是真正影响整体运营指标的还是分析时长，当应急响应的同学接收到告警之后，可以借助平台/工具快速的获取全量的数据和信息来完整复现“案发”场景时，分析的效率就会很高、分析结论的可信度也高，也有助于后面做出更合理的决策，降低整体时长和事件产生的影响。

4 - 决策时长 #如果分析报告全面立体，平时的应急预案做的比较完善，决策速度相应的也会快很多，甚至可以忽略不计，比如通过 SOAR 按照既定剧本进行决策执行的效率就非常高。

5 - 止损时长 #线上问题的处理思路一般是先止损，再谈其他的。事故之中的核心是「快速止损」，因为查找问题是一个相对来说难度比较大，也比较漫长的过程，这个时间是不可控的。

6 - 问题根治时长 #这个要看具体问题和所处阶段，有些问题的根治时间和止损时间相同，因为临时止损完之后问题也就解决了，有些问题涉及到的链路比较长、业务方比较多，那根治的时长就可能会比较长也不太可控，如果有大老板盯着可能处理起来也很快，但如果没有的话就说不好了。


MTT Detect #平均 检测 时间，是指从系统故障到检测或告警所需的平均时间。这个指标用于直接标记安全策略的召回率（系统出问题了要能够检测出来）和警报系统的及时性（策略命中了之后告警要能及时触达到值班运营同学甚至是相关负责人那里）。但是这个指标其实也间接标记了几个其它的问题，安全策略的准确率和相关日志以及数据分析的时延大小。主要用于考核数据分析和安全策略同学，而数据分析和安全策略同学为了达到设定的准召率和时延指标，一方面是要加强对已有数据的深度挖掘，另一方面也需要对底层依赖的日志提供方提出更多和更高的需求才能完成目标。

MTT Acknowledge #平均 确认 时间，是从触发警报到开始处理问题所花费的平均时间。此指标可用于跟踪团队的响应能力和警报系统的有效性。MTTA 在跟踪响应速度方面很有用。您的团队是否受警报疲劳困扰并且响应时间过长？此指标将帮助您标记问题。oncall值班同学看到了告警之后要及时确认，如果发出来的告警都是准确的，那只需要认真负责就行，如果发出来的告警准确率没那么高（包括但不限于正确性和分类分级的合理准确情况），oncall值班同学就容易陷入警报疲劳的困扰从而降低跟踪响应的速度以及后续的一系列指标。

MTT Investigate #平均 调查 时间，是指从确认一个安全事件到开始调查其原因和解决方案的平均时间。表面检验的是应急响应、安全分析人员的经验和能力水平，但其实也是对安全工具、平台的易用性，日志的完整性、丰富程度的检验，因为在事件发生之后，如果安全分析人员可以通过安全平台快速准确的拿到相关日志和数据，就可以减少调查研究所需时间，尽可能的降低MTTI这个数字。

MTT Respond #平均 响应 时间，是从首次收到产品或系统故障警报开始，到从产品或系统故障中恢复所需的平均时间。这不包括警报系统中的任何延迟时间。通常将此 MTTR 用于网络安全。

MTT Repair #平均 修复 时间，是修复系统所需的平均时间。这包括修复时间和任何测试时间。直到系统恢复完全正常运行，此指标才会停止计时。平均修复时间并不总是与系统中断本身的时间相同。某些情况下，修复会在产品故障或系统中断后的几分钟内开始。在其他情况下，在问题出现、检测到问题和开始修复之间会有一段时间间隔。此指标在跟踪维护人员修复问题的速度时最有用。它并不是要识别系统警报问题或修复前延迟，这两者也是评估事件管理计划成败的重要因素。目标是通过提高修复流程和团队的效率来尽可能降低这个数字。

MTT Recover #平均 恢复 时间，用于衡量您的完整恢复流程的速度。它有您想要的那么快吗？它与您的竞争对手相比如何？这是一个高级指标，可帮助您确定是否有问题。但是，如果您想诊断问题出在流程的哪里（是您的警报系统有问题吗？团队在修复上花了太长时间吗？有人响应修复请求的时间太长吗？），您将需要更多的数据。因为故障和恢复之间会发生很多事。

MTT Resolve #平均 解决 时间，是完全解决故障所需的平均时间。这不仅包括检测故障、诊断问题和修复问题所花费的时间，还包括确保故障不会再次发生所花费的时间。该指标将处理修复的团队的责任扩展到长期提高绩效。这是灭火与灭火然后对房屋进行采取防火措施之间的区别。这个 MTTR 与客户满意度之间有很强的相关性，因此需要重点注意。
NIST 的应急响应生命周期

Incident Response Life Cycle Step1 - (Preparation)(准备)
Incident Response Life Cycle Step2 - (Detection and Analysis)(检测和分析)
Incident Response Life Cycle Step3 - (Containment, Eradication, and Recovery)(遏制，根除和恢复)
Incident Response Life Cycle Step4 - (Post-Incident Activity)(事件后的活动-复盘、整改等)


review:
* 发生了什么，什么时候发生的(what happened and when)
* 应急响应团队的表现(how well the IR team performed)
* 是否按文档流程操作的(whether documented procedures were followed)
* 当前的流程是否完备(whether those procedures were adequate)
* 什么信息在需要的时候存在缺失(what information was missing when it was needed)
* 哪些动作让恢复变慢了(what actions slowed recovery)
* 可以做些什么不同的事情(what could be done differently)
* 可以做些什么来预防未来的事故(what can be done to prevent future incidents)
* 未来可以寻找哪些先兆或指标(what precursors or indicators can be looked for in the future)
参考链接：

MTBF、MTTR、MTTA 和 MTTF #nice
https://www.atlassian.com/zh/incident-management/kpis/common-metrics

应急响应中你到底该关注哪些指标？ #nice
https://www.freebuf.com/articles/es/321522.html

如何选择事件管理 KPI 和指标
https://www.atlassian.com/zh/incident-management/kpis

INCIDENT RESPONSE PLAN: FRAMEWORKS AND STEPS #nice
https://www.crowdstrike.com/cybersecurity-101/incident-response/incident-response-steps/

Computer Security Incident Handling Guide #nice
https://www.nist.gov/publications/computer-security-incident-handling-guide
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

Top 5 Incident Response Metrics with Real-World Examples & Impact #nice
https://www.splunk.com/en_us/blog/learn/incident-response-metrics.html

What Is Incident Management?
https://www.splunk.com/en_us/data-insider/what-is-incident-management.html

14 Cybersecurity Metrics + KPIs You Must Track in 2023 #nice
https://www.upguard.com/blog/cybersecurity-metrics

什么是MTTR，MTBF，MTTF和MTTA？ 事件管理指标指南
https://www.motadata.com/zh-CN/blog/incident-management-metrics/

MTTR、MTBF、MTTF、可用性、可靠性傻傻分不清楚？
https://zhuanlan.zhihu.com/p/439348834

常见的设备可靠性指标: MTBF/MTTF/MTTR/MTBR
https://blog.digiinfr.com/%E5%B8%B8%E8%A7%81%E7%9A%84%E8%AE%BE%E5%A4%87%E5%8F%AF%E9%9D%A0%E6%80%A7%E6%8C%87%E6%A0%87mtbf-mttf-mttr/

基于ISO12489看设备的可靠性指标MTBF/MTTF/MTTR
https://blog.digiinfr.com/%e5%9f%ba%e4%ba%8eiso12489%e7%9c%8b%e8%ae%be%e5%a4%87%e7%9a%84%e5%8f%af%e9%9d%a0%e6%80%a7%e6%8c%87%e6%a0%87mtbf-mttf-mttr/

无法衡量谈何改进？提升安全运营效率的7个关键指标
https://www.aqniu.com/hometop/88814.html

评估安全运营中心能力的七大关键指标
https://www.goupsec.com/guide/8895.html
https://www.secrss.com/articles/47494

Top 5 security analytics to measure
https://www.helpnetsecurity.com/2022/04/28/security-analytics-importance/

【顶会解读】安全运营中的告警分诊技术解析
http://blog.nsfocus.net/soc-aisecops/

现代企业应重点跟踪的12个网络安全建设指标
https://www.secrss.com/articles/51625

应急响应指标什么是MTTR、MTTD、MTTA、MTTI、MTTC
https://www.cnblogs.com/fczlm/p/16904168.html

Top 15 Cybersecurity Metrics and KPIs for Better Security
https://cybertalents.com/blog/top-15-cybersecurity-metrics-and-kpis-for-better-security

7 Incident Response Metrics and How to Use Them
https://securityscorecard.com/blog/how-to-use-incident-response-metrics/

=END=

Docker

, ,
, , , , , ,

《“衡量安全分析运营的指标”》 有 3 条评论

  1. 14 Cybersecurity Metrics + KPIs You Must Track in 2023
    https://www.upguard.com/blog/cybersecurity-metrics
    `
    Why are Cybersecurity Metrics Important? 为什么网络安全指标很重要?

    14 Cybersecurity KPIs to Track 14个可跟踪的网络安全关键指标
    1. Level of Preparedness 准备程度
    2. Unidentified Devices on Internal Networks 内部网络中未识别的设备
    3. Intrusion Attempts 入侵尝试数量
    4. Security Incidents 安全事件数量
    5. Mean Time to Detect (MTTD) 平均检测时间
    6. Mean Time to Resolve (MTTR) 平均解决时间
    7. Mean Time to Contain (MTTC) 平均遏制时间
    8. First Party Security Ratings 第一方安全评级
    9. Average Vendor Security Rating 供应商安全评级与能力评价
    10. Patching Cadence 问题修补节奏
    11. Access Management 访问管理
    12. Company vs Peer Performance 和同行业公司表现对比
    13. Vendor Patching Cadence 供应商问题修补节奏
    14. Mean Time For Vendors Incident Response 供应商事件响应的平均时间

    How to Choose the Right Cybersecurity Metrics? 如何选择正确的网络安全指标?
    `

    无法衡量谈何改进？提升安全运营效率的7个关键指标
    https://www.aqniu.com/hometop/88814.html
    `
    如今，网络安全运营已经成为企业网络安全保障建设的一项重要内容。安全运营做的好，企业的安全风险就会降低，反之，则可能会存在重大安全隐患。不过，随着网络攻击技术的日新月异，企业安全运营体系也需要不断的优化和改进，并定期对安全运营中心（SOC）及运营计划的有效性进行评估，但这并不容易。
    据最新研究数据显示，目前大多企业组织的安全运营成熟度有待改进和提升。在对250多名安全运营人员的调查中，仅有不到2成的受访者对目前的安全运营能力感到满意；其余受访者则认为，其所在组织的安全运营工作并不成熟，或者并不了解安全运营水平究竟如何。
    MTTD（平均检测时间）和MTTR（平均响应时间）是目前最常用于衡量安全运营效率的评价指标，减少MTTD和MTTR已经成为企业增强安全运营弹性的主要目标。但随着企业成熟度的提高，这时候需要更全面的评估安全运营团队是否可以实现其关键绩效指标（KPI）和服务等级协议（SLA）。因此，**除了MTTD和MTTR外，企业还应该跟踪更多的关键性能力指标，以衡量组织应对网络威胁的真实安全运营能力。**
    以下总结了7个关键指标，可以帮助企业更好地设置安全运营基线，从而更全面了解安全运营计划的执行情况，并从中发现存在的问题和不足：

    01 – 平均事件检测时间（Mean Incident Time to Detect，MTTD）

    MTTD是指安全风险事件从最初被检测到最终确定其有效性所花费的时间。它是衡量安全运营效率的关键指标，可以反映企业在识别安全事件的真实威胁方面的能力和水平。
    指标价值：
    * 实现基于威胁/事件类型（例如通过MITRE ATT&CK类别）的事件调查和报告；
    * 实现基于威胁检测方法（捕获、行为分析、场景分析、特定威胁检测技术等）的安全事件调查和报告；
    * 发现安全运营体系在支持威胁发现和威胁鉴定方面的能力水平和不足。

    02 – 平均事件响应时间（Mean Incident Time to Response，MTTR）

    MTTR是衡量调查和减轻已确认事件所花费的时间。它是衡量安全运营效率的关键指标，显示了安全运营团队在分析和缓解安全事件的实际威胁方面的能力与不足。
    指标价值：
    * 实现基于威胁/事件类型的安全事件调查与报告；
    * 发现安全运营体系在安全事件响应方面存在的问题和不足。

    03 – 平均警报分类时间（Mean Alarm Time to Triage，MTTT）

    MTTT是指从警报信息出现到运营团队开始检查告警信息所需的时间。它可以帮助企业了解对威胁的实时响应水平。
    指标价值：
    * 实现对警报信息的优先级范围划分；
    * 明确安全运营团队需要承担的监控负载和范围；
    * 可以明确安全运营团队的监控重点，并以此优化团队配置。

    04 – 平均警报合格时间（Mean Alarm Time to Qualify，MTTQ）

    MTTQ是指警报信息经过全面检查到确定其有效性或添加为威胁所需的时间。MTTQ可帮助企业了解安全运营团队识别威胁的能力以及其中所存在的能力瓶颈。
    指标价值：
    * 实现警报优先级范围内的有效报告；
    * 实现对警报结果的评价；
    * 发现安全运营解决方案在警报查询、分析和上下文检索方面存在能力不足。

    05 – 平均威胁调查时间（Mean Threat Time to Investigate，MTTI）

    MTTI是指新添加的威胁经过全面调查到确定有效性或升级为事件所需的时间。它可以帮助企业识别对新安全威胁事件的识别和调查能力。
    指标价值：
    * 实现基于威胁/事件类型（例如通过MITRE ATT&CK类别）的调查和报告；
    * 评估安全运营解决方案在搜索、数据分析、上下文分析和协作领域的进展状况和能力水平。

    06 – 平均事件缓解时间（Mean Time to Mitigate，MTTM）

    MTTM是指从安全事件创建到事件风险缓解并消除所花费的时间。它可以帮助企业了解安全运营团队能够以多快的速度解决新出现的安全风险事件。
    指标价值：
    * 实现基于威胁/事件类型（例如通过MITRE ATT&CK类别）的风险处置流程；
    * 发现现有安全运营体系在调查取证、标准化操作、自动化和团队协作方面的能力水平和存在问题。

    07 – 平均事件恢复时间（Mean Time to Recover，MTTV）

    MTTV是指从安全风险事件缓解到完全恢复所需的时间。它可以帮助企业了解安全运营团队和其他相关群体从突发安全事件中完全恢复的能力和速度，也可以从中识别出安全运营和协作的难点及瓶颈。
    指标价值：
    * 实现基于威胁/事件类型（例如通过MITRE ATT&CK类别）的安全事件应对和处置；
    * 发现现有安全运营体系在调查取证、标准化操作、自动化响应和团队协作方面的能力水平和存在问题。
    `

    回复

  3. 有效告警的最佳实践
    https://newrelic.com/resources/ebooks/effective-alerting-guide
    `
    No one ever said that alerting was easy. How do we ensure that alerts are delivered in a timely manner while preventing as many false positives and negatives as possible? Additionally, how do we make sure we’re detecting issues on time and not waking up our users in the middle of the night with false alarms? Alert fatigue is a real thing.
    没人说过问题告警是件容易的事。我们如何确保及时发送告警，同时尽可能多地防止误报和误报？此外，我们如何确保及时发现问题，而不是在半夜用假告警唤醒用户？警觉性疲劳是真实存在的。

    随着软件开发的速度越来越快，警报成为一种不可或缺的做法，对于现代 DevOps 团队来说更是如此。为什么会这样？

    首先，重要的是要考虑不同维度的站点性能的服务级别质量：

    * 可靠性。软件是您业务成功的核心；您需要知道您的系统已启动并正常运行。
    * 故障排除。你无法解决你不知道的问题。如果出现问题，您需要上下文来快速修复它。
    * 自动化。您不能每 10 秒手动刷新一次主页；您需要一个可以全年无休地为您监视事物的工具。
    * 复杂性。你的系统太复杂了，你不可能时时刻刻都在看；您需要一种可以随着系统的增长而扩展的警报实践。
    * 对结果负责。最终，您要对提供给客户和利益相关者的数字体验负责。不可用、损坏或缓慢的系统肯定会让他们对您失去信心。

    由于这些基本问题，我们必须在行动中保持警惕，我们需要设置警报的指南。在本指南中，我们将向您介绍如何为您的技术堆栈创建和管理有效的警报策略。在高层次上，我们将涵盖：

    * 现代技术堆栈的转变如何导致警报策略的转变
    * 动态和扩展环境的一些警报最佳实践
    * 如何设计和维护对您的组织和团队有用的警报系统

    有效实施的警报系统是任何成功的 DevOps 团队最重要的部分之一。

    # Modern Technology Stacks: Affecting Alerting Through Challenges and Change

    # Alerting Design Principles
    1. 考虑质量而不是数量。 自信的团队通常拥有更稀疏、更高质量和更有意义的警报策略。对其警报策略缺乏信心的团队通常有一种“囤积者心态”，并且会积累低质量的警报策略，这些策略最终会变得嘈杂且用处不大。
    2. 创建可操作的页面。 质量警报策略是可操作且有意义的。页面应呈现需要积极参与和响应的情况；否则，它们会产生不必要的噪音和警报疲劳。许多警报系统的功能是不断发出不可操作的通知——如果没有任何问题，就不应该有任何来自警报的噪音。
    3. 广播信息项。 对于某些警报，您可能需要提供有关系统事件的详细信息，即使它们不是立即可操作的。通过电子邮件或 Slack 等渠道向您的团队广播此类项目。
    4. 确定上游依赖项是可操作的还是信息性的。 如果上游依赖项出现故障，您的团队可能无法对此做任何事情，因为他们不拥有该依赖项。在这种情况下，信息广播更为合适。但是，如果团队可以做些什么来减轻上游依赖性的影响，那么页面是合适的。
    5. 优先考虑人工发送的通知。 人类对他们的系统有自动化无法提供的理解。如果有人发送通知，例如支持人员提出问题，请优先处理。
    6. 投资警报自动化。 作为优先考虑人工通知的必然结果，自动化您的策略、通知渠道和事件跟踪。您预先花在这方面的时间将在以后实际中断期间为您节省时间。
    7. 建立警报文化。 这些指导方针都不是特别具有革命性，但工程团队往往无法建立一种警报文化，从而导致理解和流程方面的差距。确保您的所有团队成员都了解您的警报策略，并将其记录为整体工作流程的一部分。

    # Creating an Alerting Strategy

    # Alerting for Dynamic and Scaled Environments

    # Managing Different Alerting Sources

    # Making Alerting Work for Your Team

    # Incident Response Lifecycle Framework

    # Next Steps

    # Successful DevOps starts here
    `

    回复

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注