你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

安全事件响应建议

  • 项目

适用于 Azure Well-Architected 框架安全清单建议：

SE：12 定义并测试涵盖各种事件（从本地化问题到灾难恢复）的有效事件响应过程。 明确定义运行过程的团队或个人。

本指南介绍有关为工作负荷实现安全事件响应的建议。 如果系统存在安全威胁，则系统事件响应方法有助于减少识别、管理和缓解安全事件所需的时间。 这些事件可能会威胁到软件系统和数据的机密性、完整性和可用性。

大多数企业都有一个中央安全运营团队， (也称为安全运营中心 (SOC) 或 SecOps) 。 安全运营团队的职责是快速检测、确定优先级并会审潜在的攻击。 该团队还监视与安全相关的遥测数据，并调查安全漏洞。

展示缓解潜在和已实现风险的协作方法的概念艺术。

但是，你也有责任保护工作负荷。 重要的是，任何通信、调查和搜寻活动都是工作负载团队与 SecOps 团队之间的协作工作。

本指南为你和工作负载团队提供建议，帮助你快速检测、会审和调查攻击。

定义

术语 定义
警报 包含事件相关信息的通知。
警报保真度 确定警报的数据的准确性。 高保真警报包含立即执行操作所需的安全上下文。 低保真警报缺少信息或包含噪音。
假正 指示未发生的事件的警报。
事件 指示对系统进行未经授权的访问的事件。
事件响应 一个检测、响应和缓解与事件关联的风险的过程。
会审 一个事件响应操作，用于分析安全问题并确定其缓解措施的优先级。

关键设计策略

当存在潜在危害的信号或警报时，你和你的团队会执行事件响应操作。 高保真警报包含充足的安全上下文，使分析人员能够轻松地做出决策。 高保真警报会导致误报数较少。 本指南假定警报系统会筛选低保真信号，并重点关注可能指示真实事件的高保真警报。

分配事件通知

安全警报需要联系团队和组织中的相应人员。 在工作负荷团队中建立一个指定的联系人，以接收事件通知。 这些通知应包含尽可能多的有关已泄露的资源和系统的信息。 警报必须包括后续步骤，以便团队可以加快操作速度。

建议使用保留审核跟踪的专用工具记录和管理事件通知和操作。 通过使用标准工具，可以保留潜在法律调查可能需要的证据。 寻找机会来实现可基于责任方的责任发送通知的自动化。 在事件期间保持清晰的通信和报告链。

利用安全信息事件管理 (SIEM) 解决方案和安全业务流程自动响应 (组织提供的 SOAR) 解决方案。 或者，你可以采购事件管理工具，并鼓励组织为所有工作负载团队标准化它们。

与会审团队一起调查

接收事件通知的团队成员负责根据可用数据设置涉及相应人员的会审过程。 会审团队（通常称为 桥牌团队）必须就沟通模式和过程达成一致。 此事件是否需要异步讨论或网桥调用？ 团队应如何跟踪和传达调查进度？ 团队可以在何处访问事件资产？

事件响应是使文档保持最新状态的关键原因，例如系统的体系结构布局、组件级别的信息、隐私或安全分类、所有者和关键联系人。 如果信息不准确或过时，桥牌团队会浪费宝贵的时间来尝试了解系统的工作原理、负责每个区域的人员以及事件的影响。

对于进一步调查，请让适当的人参与。 可以包括事件经理、安全官员或以工作负载为中心的潜在顾客。 若要使会审保持专注，请排除超出问题范围的人员。 有时，单独的团队会调查事件。 可能有一个团队最初调查问题并尝试缓解事件，另一个专门的团队可能会执行取证以深入调查以确定广泛的问题。 可以隔离工作负载环境，使取证团队能够执行其调查。 在某些情况下，同一团队可能会处理整个调查。

在初始阶段，会审团队负责确定潜在的向量及其对保密性、完整性和可用性的影响， (也称为系统的 CIA) 。

在 CIA 类别中，分配一个初始严重级别，指示损害的深度和修正的紧迫性。 随着会审级别中发现更多信息，此级别预期会随时间而变化。

在发现阶段，确定立即采取行动和沟通计划非常重要。 系统运行状态是否有任何更改？ 如何遏制攻击以阻止进一步利用？ 团队是否需要发送内部或外部通信，例如负责任的披露？ 考虑检测和响应时间。 在法律上，你可能有义务在特定时间段内向监管机构报告某些类型的违规行为，这通常是数小时或数天。

如果决定关闭系统，后续步骤会导致工作负荷的灾难恢复 (DR) 过程。

如果不关闭系统，请确定如何在不影响系统功能的情况下修正事件。

从事件中恢复

将安全事件视为灾难。 如果修正需要完全恢复，请从安全角度使用适当的 DR 机制。 恢复过程必须防止出现重复的可能性。 否则，从损坏的备份中恢复会重新引入此问题。 重新部署具有相同漏洞的系统会导致相同的事件。 验证故障转移和故障回复步骤和进程。

如果系统仍然正常运行，请评估对系统运行部分的影响。 继续监视系统，以确保通过实施适当的降级过程来满足或重新调整其他可靠性和性能目标。 不要由于缓解而损害隐私。

诊断是一个交互式过程，直到确定向量以及潜在的修复和回退。 诊断后，团队将进行修正，在可接受的期限内确定并应用所需的修补程序。

恢复指标衡量解决问题所需的时间。 在关闭的情况下，修正时间可能紧迫。 若要稳定系统，应用修补程序、修补程序和测试以及部署更新需要时间。 确定遏制策略，以防止进一步损坏和事件蔓延。 制定消除程序以完全消除环境中的威胁。

权衡：可靠性目标和修正时间之间存在权衡。 在事件期间，你很可能不符合其他非功能性或功能要求。 例如，在调查事件时，可能需要禁用系统的各个部分，甚至可能需要使整个系统脱机，直到确定事件的范围。 业务决策者需要明确确定事件期间可接受的目标是什么。 明确指定负责该决定的人员。

从事件中学习

事件发现设计或实现中的差距或漏洞。 这是一个改进机会，由技术设计方面、自动化、产品开发流程（包括测试）和事件响应过程有效性的课程推动。 维护详细的事件记录，包括执行的操作、时间线和结果。

我们强烈建议你进行结构化的事件后评审，例如根本原因分析和追溯。 跟踪这些评审的结果并设置其优先级，并考虑使用在将来的工作负载设计中学到的内容。

改进计划应包括对安全演练和测试的更新，例如业务连续性和灾难恢复 (BCDR) 演练。 使用安全威胁作为执行 BCDR 演练的方案。 演练可以验证记录的流程的工作原理。 不应有多个事件响应 playbook。 使用单个源，可以根据事件的大小以及效果的普及程度或本地化程度进行调整。 演练基于假设情况。 在低风险环境中进行演练，并在演练中包括学习阶段。

进行事后审查或事后调查，以确定响应过程中的弱点和需要改进的领域。 根据从事件中吸取的经验，更新事件响应计划 (IRP) 和安全控制。

发送必要的通信

实施通信计划以通知用户发生中断，并通知内部利益干系人有关修正和改进的信息。 组织中的其他人需要收到工作负载安全基线的任何更改的通知，以防止将来发生事件。

生成事件报告供内部使用，如有必要，出于法规遵从性或法律目的。 此外，请采用标准格式的报告 (包含 SOC 团队用于所有事件的已定义节) 的文档模板。 在结束调查之前，请确保每个事件都有与之关联的报告。

Azure 便利化

Microsoft Sentinel 是 SIEM 和 SOAR 解决方案。 它是针对警报检测、威胁可见性、主动搜寻和威胁响应的单一解决方案。 有关详细信息，请参阅 什么是 Microsoft Sentinel？

确保 Azure 注册门户包含管理员联系信息，以便可以通过内部流程直接通知安全操作。 有关详细信息，请参阅 更新通知设置。

若要详细了解如何建立从 Microsoft Defender for Cloud 接收 Azure 事件通知的指定联系点，请参阅为安全警报配置电子邮件通知。

组织遵循情况

Azure 云采用框架提供有关事件响应规划和安全操作的指导。 有关详细信息，请参阅 安全操作。

安全清单

请参阅完整的一组建议。

安全清单