有关安全事件响应的建议
适用于 Power Platform Well-Architected Security 检查清单建议：
| 东南：11 | 定义和测试有效的事件响应过程，涵盖从局部问题到灾难恢复的一系列事件。 明确定义运行过程的团队或个人。 |
|---|
本指南介绍为工作负荷实施安全事件响应的建议。 如果系统存在安全威胁，系统的事件响应方法有助于减少识别、管理和缓解安全事件所需的时间。 这些事件可能威胁到软件系统和数据的机密性、完整性和可用性。
大多数企业会有一个中央安全运营团队（也称为安全运营中心 [SOC] 或 SecOps）。 安全运营团队的责任是快速检测、确定潜在攻击的优先级并对其进行分类。 此团队还监视与安全相关的遥测数据，并调查安全漏洞。
但是，您也有责任保护您的工作负荷。 任何通信、调查和搜寻活动都是工作负荷团队和 SecOps 团队之间的协作，这一点很重要。
本指南为您和您的工作负荷团队提供建议，帮助您快速检测、分类和调查攻击。
定义
| 术语 | 定义 |
|---|---|
| 警报 | 包含事件相关信息的通知。 |
| 警报保真度 | 确定警报的数据准确性。 高保真警报包含立即采取行动所需的安全性上下文。 低保真警报缺少信息或包含干扰。 |
| 假正 | 指示事件未发生的警报。 |
| 事件 | 指示未经授权访问系统的事件。 |
| 事件响应 | 检测、响应和缓解与事件关联的风险的流程。 |
| 会审 | 分析安全问题和确定缓解措施优先级的事件响应操作。 |
关键设计策略
您和您的团队在信号或警报指示存在潜在安全事件时执行事件响应操作。 高保真警报包含充足的安全性上下文，让分析人员能够轻松做出决策。 高保真警报会让误报数减少。 本指南假设警报系统筛选低保真信号，将重点放在可能指示真实事件的高保真警报上。
分配事件通知
安全警报需要到达您的团队和组织中的相应人员。 在您的工作负荷团队中建立指定的联系点来接收事件通知。 这些通知应包括尽可能多的关于受影响资源和系统的信息。 警报必须包括后续步骤，让您的团队可以加快行动。
我们建议您使用保留审核线索的专用工具来记录和管理事件通知和操作。 使用标准工具，您可以保存潜在法律调查可能需要的证据。 寻找机会实现自动化，可以根据责任方的责任发送通知。 在事件发生期间保持清晰的通信和报告链。
利用您的组织提供的安全信息事件管理 (SIEM) 解决方案和安全业务流程自动化响应 (SOAR) 解决方案。 或者，您可以采购事件管理工具，并鼓励您的组织为所有工作负荷团队标准化这些工具。
与会审团队一起调查
收到事件通知的团队成员负责根据可用数据设定涉及适当人员的会审流程。 会审团队，通常称为桥梁团队，必须就通信的模式和过程达成一致。 此事件是否需要异步讨论或桥接通话？ 团队应该如何跟踪和传达调查进度？ 团队可以从何处访问事件资产？
事件响应是保持文档最新的关键原因，如系统的体系结构布局、组成部分级别的信息、隐私或安全分类、负责人和关键联系点。 如果信息不准确或过时，桥梁团队会浪费宝贵的时间来了解系统是如何工作的，谁负责每个领域，以及事件可能产生的影响。
如需进一步调查，让适当人员参与。 您可以包括事件经理、安全官员或以工作负荷为中心的负责人。 要保持将会审作为重点，将问题范围之外的人排除在外。 有时，单独团队会调查事件。 可能有一个团队在最初调查问题并尝试缓解事件，另一个专业团队可能会进行取证，进行深入调查，以查明广泛的问题。 您可以隔离工作负荷环境，让取证团队能够进行调查。 在某些情况下，同一团队可以处理整个调查。
在初始阶段，会审团队负责确定潜在的渠道及其对系统的机密性、完整性和可用性（也称为 CIA）的影响。
在 CIA 类别中，指定一个初始严重程度级别，指示损坏的深度和补救的紧迫性。 预期此级别会随着在会审级别发现更多信息，随时间发生变化。
在发现阶段，确定即时行动方案和通信计划非常重要。 系统的运行状态是否有任何变化？ 如何控制攻击以阻止进一步的利用？ 团队是否需要发出内部或外部通信，如负责的披露？ 考虑检测和响应时间。 您可能有法律义务在特定的时间段内（通常为数小时或数天）向监管机构报告某些类型的违规行为。
如果您决定关闭系统，后续步骤会引发工作负荷的灾难恢复 (DR) 过程。
如果您不关闭系统，确定如何在不影响系统功能的情况下对事件进行补救。
从事件恢复
将安全事件视为灾难。 如果补救需要完全恢复，从安全角度使用适当的 DR 机制。 恢复过程必须防止重新出现。 否则，从损坏的备份恢复会重新引起此问题。 重新部署具有相同漏洞的系统会导致相同的事件。 验证故障转移以及故障恢复步骤和流程。
如果系统仍在运行，评估对系统正在运行的部分的影响。 继续监视系统，确保通过实施适当的降级流程达到或重新调整其他可靠性和性能目标。 不要因为缓解措施而损害隐私。
诊断是一个交互过程，一直持续到确定了渠道以及潜在的修复和回退。 诊断后，团队进行补救，在可接受的时间内确定和应用所需的修复。
恢复指标度量修复问题所需的时间。 如果关闭，补救时间可能很紧迫。 为了稳定系统，应用修复、修补程序和测试以及部署更新都需要时间。 确定遏制策略，以阻止进一步的损坏和事件扩散。 制定根除过程，彻底消除环境中的威胁。
权衡：可靠性目标和修复时间之间存在权衡。 在事件过程中，很可能您没有满足其他非功能性或功能性要求。 例如，在调查事件时，您可能需要禁用系统的某些部分，甚至可能需要使整个系统离线，直到确定事件的范围。 业务决策者需要明确决定事件期间可接受的目标是什么。 明确指定负责该决策的人员。
从事件中吸取教训
事件会揭示设计或实现中存在的缺口或漏洞点。 这是一个由技术设计、自动化、包括测试在内的产品开发过程以及事件响应过程的有效性等方面的经验教训推动的改进机会。 维护详细的事件记录，包括采取的行动、时间表和调查结果。
我们强烈建议您进行结构化的事件后审查，如根本原因分析和回顾。 跟踪这些审查的结果并确定其优先级，并考虑在未来的工作负荷设计中使用得到的经验教训。
改进计划应包括安全演习和测试的更新，如业务连续性和灾难恢复 (BCDR) 演习。 使用安全损害作为执行 BCDR 演习的场景。 演习可以验证记录在案的流程的工作方式。 不应该有多个事件响应行动手册。 使用一个单一来源，您可以根据事件的大小以及影响的范围或本地化程度对其进行调整。 演习基于假设情况。 在低风险环境中进行演习，并在演习中纳入学习阶段。
执行事件后审查或事后分析，以确定响应流程中的薄弱环节和需要改进的领域。 根据您从事件中吸取的经验教训，更新事件响应计划 (IRP) 和安全控制措施。
发送必要的通信
实施通信计划，向用户通知中断情况，并向内部利益干系人通报补救和改进情况。 对工作负载安全基准的任何更改都需要通知组织中的其他人员，以防止将来发生事件。
生成事件报告供内部使用，如有必要，还可用于法规合规或法律目的。 此外，采用 SOC 团队用于所有事件的标准格式报告（包含定义章节的文档模板）。 在结束调查之前，确保每个事件都有相关的报告。
Power Platform 推进
以下各节介绍了可以作为安全事件响应过程的一部分使用的机制。
Microsoft 哨兵
Microsoft Sentinel Microsoft Power Platform 解决方案允许客户检测各种可疑活动，包括：
- 从未经授权的地理区域执行 Power Apps
- Power Apps 的可疑数据销毁
- Power Apps 批量删除
- 通过 Power Apps 进行的网络钓鱼攻击
- 离职员工的 Power Automate 流活动
- 添加到环境的 Microsoft Power Platform 连接器
- 更新或删除 Microsoft Power Platform 数据丢失防护策略
有关详细信息，请参阅 Microsoft Sentinel 解决方案的 Microsoft Power Platform 概述。
Microsoft Purview 活动日志记录
Power Apps、 Power Automate连接器、数据丢失防护和管理 Power Platform 活动日志记录从 Purview 合规门户进行跟踪和查看 Microsoft 。
有关详细信息，请参阅：
- Power Apps 活动日志记录
- Power Automate 活动日志记录
- Copilot Studio 活动日志记录
- Power Pages 活动日志记录
- Power Platform 连接器活动日志记录
- 数据丢失防护活动日志记录
- Power Platform 管理操作活动日志记录
- Microsoft Dataverse 和模型驱动应用活动日志记录
客户密码箱
由 Microsoft 人员（包括子处理商）执行的大多数操作、支持和故障排除不需要访问客户数据。 使用 Power Platform 客户密码箱， Microsoft 为客户提供一个界面，以便在需要对客户数据进行数据访问的极少数情况下查看和批准（或拒绝）数据访问请求。 它用于工程师需要访问客户数据的情况 Microsoft ，无论是回复客户发起的支持票证还是发现 Microsoft的问题。 有关详细信息，请参阅使用 Power Platform 和 Dynamics 365 中的客户密码箱安全地访问客户数据。
安全更新
服务团队会定期执行以下操作以确保系统的安全性：
- 扫描服务以识别可能的安全隐患。
- 评估服务以确有效地执行了密钥安全性控制。
- 对服务进行评估，以确定安全回复中心（MSRC）识别 Microsoft 的任何漏洞的暴露程度，该中心定期监控外部漏洞感知站点。
这些团队还会识别和跟踪所有已识别的问题，并在必要时采取迅速措施缓解风险。
如何了解安全更新？
因为服务团队努力以不需要服务停机时间的方式应用风险缓解，管理员通常不会看到安全更新的消息中心通知。 如果安全更新不需要影响服务，它被视为计划维护，发布时会提供预计的影响持续时间，以及工作执行的时间段。
有关安全性的更多信息，请参阅 Microsoft 信任中心。
管理维护时段
Microsoft 定期执行更新和维护，以确保安全性、性能、可用性，并提供新的特性和功能。 此更新流程每周提供安全性和次要服务改进，每个更新都根据安全部署计划按区域推出，在服务站中安排。 有关环境的默认维护时段的信息，请参阅服务事件的策略与通信。 另请参阅管理维护时段。
确保 Azure 注册门户包括管理员联系信息，以可以通过内部流程直接通知安全操作。 有关详细信息，请参阅更新通知设置。
组织一致性
Azure 云采用框架提供有关事件响应计划和安全操作的指导。 有关详细信息，请参阅安全操作。
相关信息
- Microsoft Sentinel 解决方案概述 Microsoft Power Platform
- 根据 Microsoft 安全警报自动创建事件
- 使用 Hunts 功能执行端到端威胁搜寻
- 使用 Hunts 在 Sentinel 中 Microsoft 执行端到端主动威胁搜寻
- 事件回复概述
安全清单
请参考整套建议。