事件响应概述

项目
03/09/2024

事件响应是对组织遭受的活跃攻击活动进行调查和修正。事件响应属于安全运营 (SecOps) 领域，本质上主要为预防性的。

事件响应对衡量安全操作降低组织风险的效果的总体平均确认时间 (MTTA) 和平均修正时间 (MTTR) 具有最大的直接影响。事件响应团队严重依赖威胁搜寻、情报和事件管理团队（如果存在）之间良好的工作关系，以从实际上降低风险。有关详细信息，请参阅 SecOps 指标。

有关安全运营角色和职责的详细信息，请参阅云 SOC 功能。

事件响应过程

首先是部署事件响应计划，它包含内部和外部过程来响应网络安全事件。此计划应详细说明你的组织应如何：

应对随业务风险和事件影响而异的攻击；从不再可用的隔离网页到管理员级别凭据泄露，攻击可能有所不同。
定义响应的目的，例如恢复服务或处理攻击的法律或公共关系方面。
根据应有多少人处理事件及其负责的任务，对需要完成的工作设定优先级。

请查看事件响应规划文章，获取应考虑包含在事件响应计划中的活动清单。制定好事件响应计划后，针对最严重类型的网络攻击定期测试它，确保你的组织可快速有效地做出响应。

尽管每个组织的事件响应过程可能因组织结构和功能及历史经验而不同，但响应安全事件时请考虑本文中的这组建议和最佳做法。

在事件发生期间，必须：

保持冷静

事件具有极大的破坏性，可能会影响人的情绪。保持冷静，首先专注于影响最大的操作。
不造成任何损害

确保你的响应经过设计，且其执行方式可以避免数据丢失、业务关键功能损害和证据丢失。避免做出可能会损害你创建取证分析时间线、确定根本原因和学习关键教训的能力的决定。
让法律部门参与进来

确定他们是否计划采取法律措施，以便你可以适当地计划调查和恢复过程。
公开共享事件相关信息时请小心

确定与客户和公众共享任何信息时都征求了法律部门的建议。
在需要时获取帮助

在调查和响应熟练攻击者的攻击时，利用深度专业知识和体验。

与诊断和治疗疾病一样，网络安全调查和对重大事件的响应需要保护满足以下两个条件的系统：

至关重要（不能关机检查）。
复杂（通常不能由任何一个人独立理解）。

在事件发生期间，必须取得以下关键平衡：

速度

在快速行动以满足利益干系人的需求与快速决策的风险之间取得平衡。
共享信息

根据法律部门的建议通知调查者、利益干系人和客户，从而限制责任并避免设定不切实际的预期。

本文旨在通过识别应避免的常见错误，并提供有关可快速采取哪些操作来降低风险并满足利益干系人需求的指南，来降低组织发生网络安全事件的风险。

注意

如需更多指南来使组织为勒索软件和其他类型的多阶段攻击做好准备，请参阅准备恢复计划。

响应最佳做法

通过这些建议，可以从技术和操作角度有效地响应事件。

注意

有关更多详细的行业指南，请参阅 NIST 计算机安全事件处理指南。

技术响应最佳做法

对于事件响应的技术方面，需要考虑下面一些目标：

尝试确定攻击操作的范围。

大多数攻击者使用多个持久性机制。
如果可能，请确定攻击的目标。

持久性攻击者在将来的攻击中会经常返回其目标（数据/系统）。

下面是一些有用的提示：

不要将文件上传到联机扫描程序

许多攻击者监视 VirusTotal 等服务上的的实例计数，以发现目标恶意软件。
仔细考虑修改

除非面临丢失业务关键型数据的即时威胁（例如检测、加密和外泄），否则请在不进行修改所带来的风险与预测的业务影响之间取得平衡。例如，若要在主动攻击期间保护业务关键型资产，可能有必要暂时关闭组织的 Internet 访问权限。

如果不操作带来的风险比操作带来的风险大，因而有必要进行更改，请在更改日志中记录所作操作。在事件响应期间所做的更改侧重于干扰攻击者，这可能会对业务造成负面影响。你将需要在恢复过程后回滚这些更改。
不要无限拖长调查

必须不遗余力地优先处理调查工作。例如，仅对攻击者实际使用或修改过的端点执行取证分析。例如，在攻击者具有管理权限的重大事件中，几乎不可能调查所有可能遭到入侵的资源（这可能包括组织的所有资源）。
共享信息

确认所有调查团队（包括所有内部团队和外部调查人员或保险供应商）正在根据你的法律部门的建议彼此共享其数据。
使用适当的专业知识

确认将深入了解系统的人员（例如内部人员或供应商等外部实体）加入到调查中，而不只是安全专家。
预期响应能力降低

由于情景压力，计划有 50% 的员工只能达到正常产能的 50%。

要与利益干系人明确的一个关键期望是，你可能永远无法识别初始攻击，因为识别所需的数据可能在调查开始之前已被删除，例如攻击者通过日志滚动来隐藏其踪迹。

运营响应最佳做法

对于事件响应的安全操作 (SecOps) 方面，需要考虑下面一些目标：

保持专注

确认关注业务关键数据、客户影响，并做好修正准备。
提供协调和角色明确性

建立不同的操作角色以支持危机团队，并确认技术、法律和通信团队保持了解彼此的最新情况。
保持业务视角

应始终考虑攻击者操作和你自己的响应操作对业务运营的影响。

下面是一些有用的提示：

请考虑使用事件命令系统 (ICS) 进行危机管理

如果没有管理安全事件的永久组织，建议使用 ICS 作为临时组织结构来管理危机。
保持日常操作不变

确保正常 SecOps 未完全被搁置，以支持事件调查。此工作仍然需要完成。
避免浪费性支出

许多重大事件会导致人们在压力之下购买永远不会部署或使用的昂贵安全工具。如果在调查期间无法部署和使用工具（可能包括招聘和培训更多具有操作该工具所需技能集的员工），请将购买延迟到完成调查之后。
使用深度专业知识

确认你能够将疑问和问题上报给关键平台上的资深专家。此项能力可能需要访问业务关键型系统及企业范围组件（如台式机和服务器）的操作系统和应用程序供应商。
建立信息流

为高级事件响应负责人和组织利益干系人之间的信息流设定明确的指导和期望。有关详细信息，请参阅事件响应规划。

恢复最佳做法

通过这些建议，可以从技术和操作角度有效地从事件恢复。

技术恢复最佳做法

对于从事件恢复的技术方面，需要考虑下面一些目标：

不要好高骛远

限制响应范围，以便可以在 24 小时或更短的时间内执行恢复操作。计划一个周末来考虑应变和纠正措施。
避免分心

将长期安全投资（例如实施大型复杂新安全系统或替换反恶意软件解决方案）延迟到恢复操作之后。对当前恢复操作没有直接和即时影响的任何操作都是一种干扰。

下面是一些有帮助的提示：

切勿一次性重置所有密码

密码重置应首先侧重于根据调查已知泄露的帐户，可能是管理员帐户或服务帐户。如果有保证，应仅以分步且受控的方式重置用户密码。
合并恢复任务的执行

除非面临即将丢失业务关键型数据的威胁，否则应计划合并操作以快速修正所有已泄露的资源（例如主机和帐户），而不是在找到已泄露的资源时修正它们。压缩此时间窗口会使攻击操作员难以适应和维护持久性。
使用现有工具

在恢复期间尝试部署和学习新工具之前，请研究并使用部署的工具的功能。
避免打草惊蛇

在实际操作中，应采取措施来限制攻击者可用的有关恢复操作的信息。攻击者通常有权访问重大网络安全事件中的所有生产数据和电子邮件。但实际上，大多数攻击者没有时间来监视所有通信。

Microsoft 的安全运营中心 (SOC) 使用非生产 Microsoft 365 租户为事件响应团队成员提供安全通信和协作。

运营恢复最佳做法

对于从事件恢复的操作方面，需要考虑下面一些目标：

有明确的计划和有限的范围

与技术团队密切合作，构建一个具有有限范围的明确计划。尽管计划可能根据入侵活动或新信息发生变化，但你应坚持不懈地限制范围扩展并执行更多任务。
有明确的计划所有权

恢复操作涉及多人同时执行许多不同的任务，因此请为操作指定一个项目主管，以明确决策并让确定性信息在危机团队之间流动。
维护利益干系人通信

与通信团队合作，为组织利益干系人提供及时更新和主动期望管理。

下面是一些有帮助的提示：

了解你的能力和限制

管理大型安全事件非常具有挑战性，非常复杂，并且对行业中许多专业人员来说都是新鲜事。如果你的团队不知所措，或者不确定接下来要做什么，你应考虑从外部组织或专业服务引入专业知识。
获得经验教训

构建并持续改进特定于角色的 SecOps 手册，即使是在没有任何书面程序的情况下第一次遇到事件也可妥善处理。

如果没有练习或预见，就事件响应与执行层和董事层沟通可能会具有挑战性。请确保制定了沟通计划来管理进度报告和恢复预期。

SecOps 的事件响应过程

请考虑有关 SecOps 和工作人员的事件响应过程的这一一般指导。

1. 决定和操作

威胁检测工具（如 Microsoft Sentinel 或 Microsoft Defender XDR）检测到可能的攻击后，会创建一个事件。 SOC 响应能力的平均确认时间 (MTTA) 度量从安全人员告知你此攻击开始。

值班的分析师被委托或主动负责处理事件，并执行初始分析。它的时间戳是 MTTA 响应能力度量的结束时间，并开始平均修正时间 (MTTR) 度量。

由于拥有事件的分析师非常自信地了解攻击的情景和范围，因此他们可以快速开始计划并执行清理操作。

根据攻击的性质和范围，分析师可以随时清理攻击项目（例如电子邮件、终结点和标识），也可以构建泄露的资源的列表（称为 Big Bang）

随时清理

对于在攻击操作初期检测到的最典型事件，分析师可以在发现项目时快速清理它们。此实践会使攻击者处于劣势，防止其继续前进到攻击的下一个阶段。
准备 Big Bang

此方法适用于攻击者已融入环境并建立冗余访问机制的情况。这种做法常见于由 Microsoft 事件响应团队调查的客户事件中。在这种情况下，在彻底查明攻击者的存在之前，分析师应避免打草惊蛇，因为惊慌可能促使攻击者彻底胡来。

Microsoft 了解到，部分修正常常会惊动攻击者，这让他们有机会做出反应并迅速使事件恶化。例如，攻击者可能会进一步扩散攻击、更改其访问机制以规避检测、隐藏其踪迹，并造成数据和系统损坏及销毁作为报复。

通常可以在不惊动攻击者的情况下清除钓鱼和恶意电子邮件，但清理主机恶意软件并回收帐户控制权很有可能被攻击者发现。

这是艰难的决定，而进行这些判断和决策时，没有什么比经验更可靠。 SOC 中的协作式工作环境和文化有助于确保分析师可以分享彼此的经验。

具体的响应步骤取决于攻击的性质，但分析师使用的最常见过程包括：

客户端终结点（设备）

隔离终结点，并与用户或 IT 运营/支持人员联系，以启动重新安装过程。
服务器或应用程序

与 IT 运营和应用程序所有者合作，安排快速修正这些资源。
用户帐户

通过禁用帐户并重置已泄露帐户的密码来回收控制。随着你的用户使用 Windows Hello 或其他形式的多重身份验证 (MFA) 转换到无密码身份验证，这些过程可能会不断变化。一个单独的步骤是通过 Microsoft Defender for Cloud Apps 使帐户的所有身份验证令牌过期。

你的分析师还可以通过联系用户来检验 MFA 方法电话号码和设备注册，以确保其未被拦截，并根据需要重置此信息。
服务帐户

由于服务或业务影响的风险很高，你的分析师应该与服务帐户所有者合作，根据需要回退 IT 操作，以安排快速修正这些资源。
电子邮件

删除攻击或钓鱼电子邮件，有时还可清除它们，以防止用户恢复已删除的电子邮件。始终保存原始电子邮件的副本，以便稍后搜索攻击后分析，如标头、内容、脚本或附件。
其他

你可以根据攻击的性质执行自定义操作，例如吊销应用程序令牌以及重新配置服务器和服务。

2. 事件后清理

由于只有改变未来的操作才算从学到的教训受益，所以请始终将从调查中学到的任何有用信息集成回 SecOps。

通过相同的威胁参与者或方法确定过去和未来事件之间的联系，并习得这些知识以避免将来重复的手动工作和分析延迟。

这些知识可以采用多种形式，但常见的做法包括分析：

入侵指标 (IoC)。

将所有适用的 IoC（如文件哈希、恶意 IP 地址和电子邮件属性）记录到 SOC 威胁情报系统中。
未知或未修补的漏洞。

你的分析师可以启动过程来确保应用缺少的安全修补程序、纠正配置错误，并向供应商（包括 Microsoft）告知“零时差”漏洞，以便他们能够创建和分发安全修补程序。
内部操作，如对包括基于云的资源和本地资源的资产启用日志记录。

查看现有的安全基线，并考虑添加或更改安全控制措施。例如，请参阅 Microsoft Entra 安全运营指南，以了解有关在下次事件发生前在目录中启用适当审核级别的信息。

检查你的响应过程，确定并解决在事件期间发现的任何不足之处。

事件响应资源

Microsoft 主要安全资源

资源	说明
2023 Microsoft 数字防御报告	这份报告涵盖了 Microsoft 安全专家、管理人员和防御人员的经验，旨在增强各地人员抵御网络威胁的能力。
Microsoft 网络安全参考体系结构	一组直观的体系结构图，展示了 Microsoft 的网络安全功能及其与 Microsoft 云平台（例如 Microsoft 365 和 Microsoft Azure）和第三方云平台及应用程序的集成。
“时间至关重要”信息图下载	概述 Microsoft 的安全运营团队如何响应事件来缓解正在遭受的攻击。
Azure 云采用框架安全操作	为建立安全运营功能或使之现代化的领导者提供的战略指导。
Microsoft 安全最佳做法 - 安全运营	如何充分利用安全运营中心抢在组织攻击者前面行动。
面向 IT 架构师的 Microsoft 云安全模型	Microsoft 云服务和平台中用于标识和设备访问、威胁防护以及信息保护的安全措施。
Microsoft 安全文档	Microsoft 的其他安全指南。

通过