1. 行业规范

NIST Computer Security Incident Handling Guide

• 
• 应急响应是一组用于在发生安全事件时准备、检测、控制、响应和学习的过程管理。
• 事件响应（与大多数网络防御一样）由三大支柱支撑：技术、人员和流程。
• 安全事件发生后，业务的主要目标是尽快以安全的方式恢复正常。
• 我们可能必须回答以下问题：
  • 什么被控制/泄露/破坏了？
  • 如何恢复正常？
  • 这是怎么发生的？
  • 我们如何防止这种情况再次发生？
• 这就是为什么用来衡量应急响应团队绩效的关键指标是MTTD和MTTR的原因：
  • MTTD平均检测时间：发现事件正在发生所需的时间。
  • MTTR平均响应时间：修复威胁所需的时间。
• 整体流程可以分为：
  • Preparation：人员，过程，技术三个维度展开
  • Detection and Analysis：监控告警、主动发现（威胁狩猎）和分析处置
  • Containment, Eradication, and Recovery：止损并恢复任何受影响的资源、数据和/或流程
  • Post-Incident Activity
    • 经验教训
    • 过程分析：处置时间、主观/客观评价、
    • 证据保留

ISO/IEC 27035

• 
• 目标与范围
  • 与网络安全相关的攻击不断演变，也对实体造成更多损害。因此，每个组织都需要有一个一致的事件响应计划 (IRP) 和事件管理技能，以根据风险评估的结果减轻弱点、保持业务运行、最大限度地减少损失和声誉。通过这种方式，它有助于减少发生的事件，同时要记住并非所有事件都可以预防。
  • ISO (27035:2016) 国际标准为大中型组织提供信息安全事件管理发布的指南、技术和最佳实践。除了小型组织可以遵循基本程序集和推荐的国际事件管理实践外，还可以提供外部各方来处理信息安全事件。
• 信息安全事件链见下图：
  • 
• 常见安全响应团队的类型如下：
  • 
• 整体流程可以分为：
  • Plan & Prepare：为事件管理政策计划和准备适当的计划，并考虑将事件管理、漏洞管理计划纳入此阶段，包括整体流程、政策、操作工具、模板、角色和职责。
  • Identify. Detect, &Report：该过程检测、收集与安全事件相关的信息并报告安全事件，信息安全事件和事件流程图如下：
    • 
  • Assessment & Decision：进行评估以确定安全事件是否处于可能性或误报状态，或已结束。ISIRT 进行评估以确认 PoC 的评估结果，以了解事件的真假；应根据结果进行二次评估。
  • Responses：有响应都是根据决策阶段的输出做出的，可以在实时基础上或在取证分析操作的帮助下在确定的时间范围内立即做出响应。
  • Lessons learnt：包括信息安全取证分析、确定经验教训、改进信息安全控制实施和信息安全风险评估和管理审查结果、信息安全事件管理计划和其他改进。

2. 行业实践

2.1. AWS

整体流程为：

• 准备阶段
  • 人员：尽管自动化程度有所提高，但安全组织内的分析师和响应者仍有许多工作要做。同质化的团队会产生盲点，因此必须建立一个多元化的团队，在复杂多变的情况下提供不同的思想体系、文化视角以及工作和生活经验。包括：确定角色和职责、响应机制等
  • 技术：使用AWS提供的相关工具/接口访问事件所涉及的环境和资源
• 模拟阶段
  • 安全事件响应模拟 (SIRS) ，可提供结构化机会在现实场景中练习事件响应计划和程序
• 持续迭代
  • 创建Runbook：提前计划并定义自己的安全响应程序，参考这里
  • 自动化能力：AWS提供了一整套API和工具来实现自动化应急响应，不同的工具对比如下：例如，AWS Lambda 提供更快的速度并且需要更少的技术技能。AWS Fargate 提供更大的灵活 性，并且需要更少的维护和技术技能。
  • 

2.2. Microsoft

• 核心衡量指标为：平均确认时间 (MTTA) 和 平均补救时间 (MTTR)
• 响应计划，见下表

- 相关流程：响应->恢复->运营
- 响应手册：如，[钓鱼响应手册](https://docs.microsoft.com/en-us/security/compass/incident-response-playbook-phishing)

• Microsoft 365 Defender 的事件响应

  • 检测
    • 
  • 工作流程
    • 
  • 安全操作
    • 
  • 自动化响应
    • 自动调查和响应功能通过以下方式帮助您的安全运营团队：
      • 确定威胁是否需要采取行动。
      • 采取（或建议）任何必要的补救措施。
      • 确定是否以及应该进行哪些其他调查。
      • 根据需要对其他警报重复该过程。
    • 警报会创建一个事件，该事件可以启动自动调查。自动调查会为每条证据做出裁决。判决可以是：
      • 恶意的
      • 可疑的
      • 没有发现威胁
    • 识别恶意或可疑实体的补救措施。补救措施的示例包括：
      • 将文件发送到隔离区
      • 停止进程
      • 隔离设备
      • 阻止 URL
      • 其他行为
  • 有关详细信息，请参阅 Microsoft 365 Defender 中的补救措施

  3. 总结

  应急响应有五个关键事项：

  • 记录在发生事故时要采取的考虑、决定和行动的过程
    • 应急响应计划:详细说明组织（或者，通常是组织的特定部分，例如 SOC）为响应网络事件所做的工作的总体文档
    • 技术操作手册:技术操作手册提供了有关一线团队（例如 SOC 或 CSIRT）在发生特定事件场景时应如何响应的详细指导（如：https://github.com/certsocietegenerale/IRM/tree/master/EN）
    • 知识库:提供了有关支持对一个或多个事件场景的响应的具体操作的详细指导
  • 熟练和经验丰富的人员来领导、协调和执行对事件的响应
    • 不仅是必要的技能和经验，还包括更广泛的网络安全、IT 和业务等相关能力，可以参考：
      • NIST 网络安全劳动力框架
      • 知道创宇研发技能表
      • 网络安全产业人才岗位能力要求
  • 通过日志进行事件调查，并帮助了解发生了什么、何时以及如何发生的
    • 在确定要存储哪些日志时，还应考虑任何适用的法规。例如，GDPR 对“数据最小化”的要求意味着安全日志不应包含个人数据
    • 日志保留期的选择应再次与可能的现实威胁和调查要求保持一致;日志的存储时间应该是它们通常对团队有用的时间。(例如，这可能是基于可能的攻击者的平均停留时间。FireEye 的 2021 M-Trends报告确定了非勒索软件调查的中位停留时间为 45 天，其中 25% 的非勒索软件调查的停留时间为 200 多天)
  • 执行遏制和根除行动以减轻事件风险的技术
    • 基于主机/网络/身份
  • 事件响应团队的协调技术，用于沟通和协作、委派和跟踪响应行动以及管理交付
    • 沟通: 内部和与外部合作伙伴的同步（例如，视频和电话呼叫和会议）和异步（例如，文本聊天）通信。
    • 协作: 在内部和与外部合作伙伴的工作上进行协作。
    • 任务跟踪: 记录响应事件所需的任务，跟踪截止日期、工作量、状态、受让人和后续步骤。这可以通过简单的电子表格或 Jira 等专用任务跟踪系统来实现。
    • 报告: 捕获每个事件的关键统计数据（例如，使用常见的模式，如VERIS），并输出这些数据以启用管理报告。

  4. 参考

  • https://medium.com/nerd-for-tech/how-to-plan-detect-assess-and-respond-to-information-security-incidents-by-using-iso-iec-27035-ed744c8b7cd5
  • https://gabrielcurrie.medium.com/ready-for-nearly-anything-five-things-to-prepare-for-a-cyber-security-incident-4fc49d665488
  • https://docs.microsoft.com/en-us/microsoft-365/security/defender/incidents-overview?view=o365-worldwide#incidents-and-alerts-in-the-microsoft-365-defender-portal
  • https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/cloud-security-incidents.html
  • https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf
  • https://www.iso.org/standard/60803.html