急救员给出的云事件响应两大要诀

拥有许多与众不同的爱好，其好处之一是它们会让您的大脑以稍有不同的方式运转。当您在心里把不同领域交叉融合时，就会发现自己从另一个角度来看待问题。作为一名半在职的急救员，我发现处理血肉之躯的紧急情况与处理比特与字节的紧急情况之间有大量相似之处。

过去几年里，我讲授了大量云事件响应课程，并开始使用两句来自急救领域的话，它们似乎很能引起初入门的事件响应人员的共鸣。这些记忆辅助手段能很好地帮助人们聚焦重点并优化流程。虽然它们适用于任何事件响应，但我发现在云这一侧它们的作用更大，这主要源于管理平面的存在所带来的固有差异。

危重还是不危重

与街头的普通人相比，急救员能做的事情很多，但在医学领域我们的能力相当有限。我们受过精湛的训练，能够迅速识别危及生命和肢体的威胁，无论是内科还是创伤，并稳定患者病情、将其转运至确定性治疗。有一句被反复灌输给我们的关键短语是“危重还是不危重”。这是一个记忆辅助手段，帮助我们记住要着眼全局，判断患者是否已陷入严重危险。

我很喜欢用这一点来帮助信息安全专业人员判断一起事件有多严重。在云环境中，我们教他们识别重大发现，这些发现要求他们当场深入处理问题，然后才能继续推进。在急救医疗服务中，这被称为“生命威胁”。由于云事件响应是在一种新的底层技术之上运用既有的事件响应技能，这句话只是提醒人们思考某个发现可能带来的后果，而这类发现通常并不会触发响应人员的直觉。以下是一些简单的例子：

• 对象存储（S3）中本不应公开的数据被公开。
• 具有管理员权限或其他高权限的 IAM 实体可能已被入侵。
• 来自同一个未知 IP 地址、使用不同 IAM 用户的多次成功 API 调用。
• 将映像或快照跨账户共享给未知账户。
• 拥有 IAM 权限的实例/虚拟机可能已被入侵。

当我把这些写出来时，大多数响应人员会说：“这不是明摆着吗。”但根据我的经验，传统的响应人员需要一点时间才能识别出这些问题，并意识到它们远比一台普通的被入侵虚拟机更为关键。

在云环境中，“危重还是不危重”几乎总是等同于“它是否被公开，或者攻击者是否已进入管理平面（IAM）”。

危重还是不危重。每当您发现一条新证据、拼图中的一块新碎片时，都要在脑中过一遍这个问题，判断您的患者是即将崩溃，还是只是有点鼻塞。

止血

你们中的许多人可能上过心肺复苏和急救课程。您很可能学过“ABC”：气道（Airway）、呼吸（Breathing）和循环（Circulation）。

是的，事实证明我们在这一点上真的搞砸了。

研究开始表明，在紧急情况下，人们会专注于 ABC 而忽略更全局的状况。甚至连急救员也会出现这样的情形：给一个腿部伤口正在大出血的人做心肺复苏。有时那还是完美的心肺复苏。从患者失血的速度就能看得出来。如今我们在最前面加上了“处理生命威胁”，而“止血”是首要任务。

明白我要说什么了吗？

在我讲授的每一堂课上，我都会看到经验丰富的响应人员埋头于分析和调查，而云环境正在他们眼前大出血。为什么？

因为他们不习惯一切（可能）都暴露在互联网上。整个管理平面都在互联网上，所以如果攻击者获得了凭证，您无法用防火墙或关闭对某台服务器的访问来阻止他们。如果某样东西被入侵并暴露，那么它就是被入侵并暴露给了……嗯，可能是所有人、所有地方、同时发生。

止血与危重还是不危重相辅相成。如果您发现了危重的情况，是否需要当场遏制它才能继续往下走？这是一个微妙的平衡，因为如果您判断错误，在攻击者继续推进的同时，您可能正在浪费宝贵的时间。止血就等于“这太糟糕了，我现在就必须修复它”。但一旦完成止血，您就需要立即回到之前的位置，继续您的分析和响应流程，因为可能还有大量恶意活动在进行。

我的简短清单是什么？

• 任何看似已被入侵的高权限 IAM 实体。
• 以某种方式被公开的敏感数据。
• 跨账户/订阅/项目共享，或对未知目标的访问。

还有更多，但这就是简短清单。其中每一项都表明正在发生数据丢失或入侵，您需要立即予以遏制。

实战演示

下面是一个示例。截图混合使用了 Slack、AWS 控制台和 FireMon Cloud Defense。这是我的工具链，不过无论您手头有什么工具，这套方法都适用。在培训课程中，我们还会使用 Athena 查询来模拟 SIEM，但我想让这篇文章尽量简短。

我们先从 Slack 中由我们整合的 CSPM/CDR 平台发出的一条中等严重性告警开始：

危重还是不危重？我们还不知道。这可能完全是合规的操作。好，该开始调查了。我会同时在平台和 AWS 控制台中演示。我的第一步是查看共享了什么、共享给了谁。由于告警中包含 AMI ID，我们可以直接定位过去：

好——我可以看到它被共享给了另一个账户。那是我拥有的账户吗？是我认识的账户吗？我的工具将其标记为不受信任，因为它不是在系统中注册过的账户，但在实际工作中，我会去核对本组织的主账户清单，以再次确认。

好，危重还是不危重？在我心里，这仍然是“可能”。我发现一个映像被共享给了一个可能不受信任的账户。但我还不知道共享的是什么内容。我需要把它追溯到源实例。我不打算做完整的取证；我会依靠上下文信息，因为我需要相当快地弄清楚这件事。在这个案例中，我们运气不错：

它的名称中带有“Prod”，所以……我判定这是“可能危重”。要止血吗？在实际工作中，我会先设法联系那个 AWS 账户的所有者，但今天，我认为我掌握的信息已经足以隔离该 AMI。以下是在控制台和 Cloud Defense 中的操作方法：

好，我们止血了吗？我们止住了……一部分血。我们锁定了该 AMI，但仍然不知道它是如何被共享到那里的。我们也不知道那个 AWS 账户归谁所有。我们能查出来吗？不能。如果它不属于我们，我们能做的就只有向 AWS 报告，剩下的交由他们处理。

我们来搜寻 API 调用，查明是谁共享了它以及他们还做了什么。接下来这部分我会在平台中操作，但您也可以在自己的 SIEM 或 Athena 中运行查询来获取同样的信息。今后我会专门写文章介绍这些查询，而本文聚焦于危重/止血这两个概念。

好——我看到一个名为 ImageBuilder 的 IAM 实体是操作方。同样，由于这篇文章已经写得有点长，我检查了几项内容，以下是我了解到的情况：

• ImageBuilder 是一个 IAM 用户，拥有创建映像和修改其属性的权限，但仅此而已。然而，该策略没有资源约束，因此它可以为任何实例创建映像；也没有条件约束，因此它可以共享给任何账户。这属于中低程度的影响范围——权限过大，但还不算糟糕透顶。我称之为“有点危重”。
• 该 API 调用来自一个未知 IP 地址。这很可疑，但仍然只是“有点危重”。
• 这是我第一次看到这个 IAM 用户使用该 IP 地址，而该用户此前的活动与某个批处理进程相符。好，现在我倾向于判定为危重。通常我们不会在这类作业中看到轮换的 IP 地址，这有一股凭证泄露的味道：

• 那个 IAM 用户可以继续执行这些操作。除非有人告诉我这是有意为之，否则我判定它为危重，并且我将止血，并对该用户账户施加 IAM 限制（如果这不是关键进程，可能会用一条 Deny All 策略；如果是关键进程，我会改用 IP 限制）。

总结如下：

• 我发现一个 AMI 被共享给了未知账户：危重
• 该 AMI 属于一项生产资产：危重，需止血
• 该操作来自一个 IAM 用户，它拥有创建并共享 AMI 的广泛权限，但没有其他权限：可能危重，仍在调查中。
• 该 IAM 用户是从一个未知的新 IP 地址创建这个 AMI 的：危重，止住（其余的）血。
• 未检测到该 IP 地址的其他活动：很可能已被控制，不再属于危重状态
• 我仍然不清楚这些凭证是如何泄露的：属于危重状态，此时应当请传统事件响应的同行介入，判断是网络层面还是主机层面遭到入侵。

我快速梳理了这一过程，以说明我如何看待此类问题。只要存在少许差异，同样的发现就可能完全正常。设想我们发现它是共享给一个由我们控制但尚未注册的新账户。或者该 AMI 属于某个不含任何敏感内容的开发实例。又或者这些 API 调用来自我们自己的网络、发生在预期时间，或来自管理员的系统且其本意就是要共享。这个示例并不算严重，但它是一种已知的数据外泄方式，活跃的威胁行为者正在使用。每获得一条信息，我都会评估它属于危重还是非危重，以及是否需要先止血。

这在云环境中有何不同？因为当一切都可能与互联网相连时，风险也更高。我们需要更快地思考和行动，而我认为这个记忆法有助于让我们不偏离方向。