你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
安全事件响应建议
适用于 Azure 架构良好的框架安全清单建议：
| SE：12 | 定义和测试涵盖一系列事件的有效事件响应过程，从本地化问题到灾难恢复。 明确定义哪个团队或个人运行过程。 |
|---|
本指南介绍了为工作负荷实现安全事件响应的建议。 如果系统存在安全泄露，系统事件响应方法有助于缩短识别、管理和缓解安全事件所需的时间。 这些事件可能会威胁软件系统和数据的机密性、完整性和可用性。
大多数企业都有一个中心安全运营团队（也称为安全运营中心（SOC）或 SecOps。 安全运营团队的责任是快速检测、确定优先级和会审潜在攻击。 该团队还监视与安全相关的遥测数据，并调查安全漏洞。
但是，你还有责任保护工作负荷。 重要的是，任何通信、调查和搜寻活动都是工作负荷团队和 SecOps 团队之间的协作工作。
本指南为你和工作负荷团队提供建议，帮助你快速检测、会审和调查攻击。
定义
| 术语 | 定义 |
|---|---|
| 警报 | 包含有关事件的信息的通知。 |
| 警报保真度 | 确定警报的数据的准确性。 高保真警报包含立即执行操作所需的安全上下文。 低保真警报缺少信息或包含噪音。 |
| 假正 | 指示未发生的事件的警报。 |
| Incident | 指示未经授权访问系统的事件。 |
| 事件响应 | 检测、响应和缓解与事件相关的风险的过程。 |
| 会审 | 分析安全问题并确定其缓解优先级的事件响应操作。 |
关键设计策略
当存在潜在泄露信号或警报时，你和你的团队将执行事件响应操作。 高保真警报包含充足的安全上下文，使分析师能够轻松做出决策。 高保真警报会导致误报数较少。 本指南假定警报系统筛选低保真信号，并重点介绍可能指示真实事件的高保真警报。
指定事件通知联系人
安全警报需要联系团队和组织中的相应人员。 在工作负荷团队中建立指定的联系点，以接收事件通知。 这些通知应包含有关已泄露的资源和系统的信息。 警报必须包括后续步骤，以便团队可以加快操作。
建议使用专用工具记录和管理事件通知和操作，以保留审核线索。 通过使用标准工具，可以保留潜在法律调查可能需要的证据。 寻找实现自动化的机会，这些自动化可以根据责任方的责任发送通知。 在事件期间保持明确的通信和报告链。
利用组织提供的安全信息事件管理（SIEM）解决方案和安全业务流程自动响应（SOAR）解决方案。 或者，你可以采购事件管理工具，并鼓励组织为所有工作负荷团队标准化它们。
使用会审团队进行调查
接收事件通知的团队成员负责设置会审过程，该过程涉及基于可用数据的适当人员。 会审团队，通常叫 桥队，必须就沟通的模式和过程达成一致。 此事件是否需要异步讨论或桥接调用？ 团队应如何跟踪和传达调查进度？ 团队可以在何处访问事件资产？
事件响应是使文档保持最新状态的关键原因，例如系统的体系结构布局、组件级别的信息、隐私或安全分类、所有者和关键联系点。 如果信息不准确或过时，桥牌团队会浪费宝贵的时间，试图了解系统的工作原理、负责每个区域的人员以及事件的影响。
若要进一步调查，请让适当的人员参与。 可以包括事件经理、安全官员或以工作负荷为中心的潜在顾客。 若要使会审保持专注，请排除超出问题范围的人员。 有时，单独的团队调查事件。 可能有一个团队最初调查问题并尝试缓解事件，另一个专门团队可能会执行取证，以便进行深入调查，以确定广泛的问题。 可以隔离工作负荷环境，使取证团队能够进行调查。 在某些情况下，同一团队可能会处理整个调查。
在初始阶段，会审团队负责确定系统的潜在向量及其对机密性、完整性和可用性的影响（也称为 中情局）。
在 CIA 类别中，分配一个初始严重级别，指示损害深度和修正的紧迫性。 随着会审级别中发现更多信息，此级别预计将随着时间推移而变化。
在发现阶段，确定立即采取行动和沟通计划非常重要。 系统运行状态是否有任何更改？ 如何遏制攻击以阻止进一步利用？ 团队是否需要发送内部或外部通信，例如负责任的披露？ 考虑检测和响应时间。 你可能在法律上有义务在特定时间段内向监管机构报告某些类型的违规行为，这通常是几个小时或几天。
如果决定关闭系统，后续步骤会导致工作负荷的灾难恢复（DR）过程。
如果未关闭系统，请确定如何在不影响系统功能的情况下修正事件。
从事件中恢复
像灾难一样处理安全事件。 如果修正需要完全恢复，请从安全角度使用适当的 DR 机制。 恢复过程必须防止出现重复的可能性。 否则，从损坏的备份恢复会重新引入问题。 重新部署具有相同漏洞的系统会导致同一事件。 验证故障转移和故障回复步骤和进程。
如果系统仍然正常运行，请评估对系统运行部分的影响。 继续监视系统，确保通过实施适当的降级过程来满足或重新调整其他可靠性和性能目标。 不要因为缓解而损害隐私。
诊断是一个交互式过程，直到识别矢量和潜在的修复和回退。 诊断后，团队将处理修正，该修正在可接受的时间段内标识并应用所需的修补程序。
恢复指标测量修复问题所需的时间。 如果关闭，则可能是有关修正时间的紧迫性。 若要稳定系统，应用修补程序、修补程序和测试以及部署更新需要时间。 确定遏制策略，以防止进一步损坏和事件蔓延。 制定根除程序，彻底消除环境的威胁。
权衡：可靠性目标和修正时间之间存在权衡。 在事件期间，可能不符合其他非功能或功能要求。 例如，在调查事件时，可能需要禁用系统的某些部分，甚至可能需要使整个系统脱机，直到确定事件的范围。 业务决策者需要明确决定事件期间可接受的目标。 明确指定负责该决定的人员。
从事件中学习
事件可发现设计或实现中的漏洞或漏洞。 这是一个改进机会，由技术设计方面的课程、自动化、产品开发流程（包括测试）和事件响应过程的有效性驱动。 维护详细的事件记录，包括已执行的操作、时间线和调查结果。
我们强烈建议你进行结构化事件后评审，例如根本原因分析和回顾。 跟踪和确定这些评审结果的优先级，并考虑在将来的工作负荷设计中使用所学知识。
改进计划应包括对安全演练和测试的更新，例如业务连续性和灾难恢复（BCDR）演练。 使用安全泄露作为执行 BCDR 演练的方案。 钻取可以验证记录的进程的工作原理。 不应有多个事件响应 playbook。 使用一个源，可以根据事件的大小以及效果的广度或本地化程度进行调整。 钻取基于假设情况。 在低风险环境中进行演练，并在演练中包含学习阶段。
进行事后评审或事后验尸，以确定响应过程和改进方面的弱点。 根据从事件中吸取的教训，更新事件响应计划（IRP）和安全控制。
定义沟通计划
实施通信计划，通知用户中断情况，并通知内部利益干系人修正和改进。 组织中的其他人需要收到工作负荷安全基线的任何更改的通知，以防止将来发生事件。
生成事件报告供内部使用，如有必要，出于法规合规性或法律目的。 此外，采用标准格式报告（包含已定义节的文档模板），SOC 团队对所有事件使用。 在关闭调查之前，请确保每个事件都有与其关联的报告。
Azure 便利化
Microsoft Sentinel 是 SIEM 和 SOAR 解决方案。 它是针对警报检测、威胁可见性、主动搜寻和威胁响应的单一解决方案。 有关详细信息，请参阅 什么是 sentinel Microsoft？
确保 Azure 注册门户包含管理员联系信息，以便通过内部过程直接通知安全操作。 有关详细信息，请参阅 更新通知设置。
若要详细了解如何建立从 Microsoft Defender for Cloud 接收 Azure 事件通知的指定联系人，请参阅配置安全警报电子邮件通知。
组织遵循情况
azure 云采用框架提供有关事件响应规划和安全操作的指导。 有关详细信息，请参阅 安全操作。
相关链接
- 自动根据 Microsoft 安全警报创建事件
- 使用搜寻功能进行端到端威胁搜寻
- 为安全警报配置电子邮件通知
- 事件响应概述
- Microsoft Azure 事件准备情况
- 在 Microsoft Sentinel 中浏览和调查事件
- 安全控制：事件响应
- Microsoft Sentinel 中的 SOAR 解决方案
- 培训：Azure 事件就绪情况简介
- 更新Azure 门户通知设置
- 什么是 SOC？
- 什么是 sentinel Microsoft？
安全清单
请参阅完整的建议集。