在开始项目之前我们需要回答的问题 - 构建一个防御系统来保护我们免受欺骗邮件攻击 |第7部分#9

保护我们的邮件基础设施以及我们的用户免受欺骗邮件攻击的“防御系统”的规划阶段需要从某种框架的定义开始。该框架将充当“逻辑容器”，定义我们的防御系统的特定结构和特征，需要处理欺骗邮件攻击。

创建欺骗邮件攻击防御系统所需的框架

主要问题是——我们如何构建这个“框架”？

我的建议是 - 通过使用“问答”流程，涉及防御系统的不同方面，例如：我们想要使用什么类型的保护机制，我们想要针对事件执行的策略是什么欺骗邮件等等。

我这篇文章的目标是——向您提供一些需要提出的问题，涉及所需的结果以及我们想要构建的用于处理欺骗邮件攻击问题的防御系统的结构。

关于欺骗邮件攻击防御解决方案的好消息和不太好的消息

欺骗邮件攻击的基础设施植根于 SMTP 协议的特征，该协议不包含验证发件人身份的内置机制。

好消息是，有一些解决方案可以通过为我们提供验证发件人身份的能力来完成 SMTP 协议的“缺失部分”，从而防止欺骗邮件攻击的情况。

不太好的消息是，我们需要解决一些“重大障碍”，为我们的组织提供“良好的保护”，使其免受欺骗电子邮件攻击的威胁。

“主要障碍”包括

1. 需要为我们的特定组织需求决定“正确的解决方案”。
2. “技术方面”，涉及我们将选择的特定发件人验证解决方案的特征、组合两个或多个发件人验证解决方案的结构、发件人验证解决方案的管理等。

我们必须做出决定的主要领域。

一个好的、完整的解决方案与不成熟或部分的解决方案之间的区别，需要作为欺骗邮件攻击和网络钓鱼邮件攻击威胁的答案，取决于我们预测我们面前的障碍的能力，以及我们需要就“最佳解决方案”做出不同的决策，该解决方案将以最佳方式运作，并且最适合我们特定的组织需求和结构。

欺骗邮件的定义

让我们从一个非常基本但非常重要的问题开始，我们需要问自己。

Q1：我们如何定义欺骗邮件的场景？

A1：简单的答案是——敌对分子使用虚假身份的事件，敌对分子自称是X实体而实际上是Y实体的场景。

问题2：我们如何识别发件人冒充身份的事件？

A2：简单的答案是——通过使用发件人验证邮件标准，可以帮助我们验证发件人身份，这样我们就能够区分合法发件人和非合法邮件发件人（冒充其身份的敌对分子）。

嗯，事实并非如此简单！

著名的短语——“如果它看起来像鸭子，像鸭子一样游泳，像鸭子一样嘎嘎叫，那么它可能是一只鸭子”，它与一个场景有关，其中一种特定的动物具有某种动物的所有特征和迹象。鸭子，因此，我们可以假设它可能是一只鸭子。

问题是，对于一个场景，欺骗邮件（欺骗发件人），我们需要提供一个关于电子邮件消息发件人含义完整性的“大胆声明”，来决定发件人是否合法，答案是：没那么简单！

在我们声明我们需要立即停止所有欺骗邮件攻击之前，我想再问两个问题：

问题3：当我们说“某封电子邮件被识别为欺骗邮件”时，我们能100%确定该电子邮件确实是欺骗邮件吗？

问题3：当我们识别出一封看起来像欺骗邮件的特定电子邮件时，我们能否100%确定我们确实要“销毁”该电子邮件？

我的观点是什么？

我的观点是，在许多情况下，我们无法 100% 确定特定发件人是合法发件人，还是欺骗其身份的敌对分子。

为了能够证明当我们想要将特定电子邮件分类为“好电子邮件”或“坏电子邮件”时我们需要处理的现有挑战，让我们使用以下示例：

我们的组织正在实施特定的发件人验证邮件标准，例如 SPF。

发送到我们组织的每封电子邮件都会经过检查过程，我们将尝试验证发件人身份，并根据结果确定发件人身份是合法身份还是被视为欺骗身份。

当电子邮件到达我们的邮件服务器时，可以实现两种情况：

• 场景 1 - 发件人组织未发布 SPF 记录（不支持 SPF）。
• 场景 2 - 发件人组织发布 SPF 记录。

场景 1 - 发件人组织未发布 SPF 记录（不支持 SPF）。

这种情况（图中的情况 B）可以描述为 - 死胡同，因为我们（我们的邮件服务器）没有选项来验证发件人身份。发件人可以是合法发件人，但同时也可以是冒充合法发件人身份的敌对分子。

Q1：那么我们如何知道是“批准”还是“拒绝”电子邮件呢？

A1：简单的答案是——我们没有办法或“标志”，可以帮助我们做出正确的决定。

情况 1 - 如果我们因为发件人组织不支持 SPF 而决定拒绝电子邮件，我们将承担误报事件的风险。

其含义是 - 我们错误地将合法电子邮件识别为欺骗邮件并因此阻止或拒绝该电子邮件的情况。

情况 2 - 如果我们决定接受电子邮件，尽管发件人组织不支持 SPF，我们仍将面临误报事件的风险。

其含义是 - 我们接受非合法电子邮件
（欺骗电子邮件）的情况，该电子邮件设法绕过我们的“防御墙”，并到达我们其中一个收件人的邮箱。

场景 2 - 发件人组织发布 SPF 记录。

在成功实现发件人验证过程（A.2）并且发件人身份显示为合法身份的情况下，我们很高兴！

但是，“发件人验证失败”(A.1) 的情况该怎么办？

我们能否毫无疑问地确定该特定电子邮件是由试图执行欺骗邮件攻击并使用欺骗身份的“敌对分子”发送的？

显而易见的答案是——是的；这是典型的场景，我们的防御系统成功地识别出了“坏人”。

和往常一样，现实并不那么简单。

“发件人验证失败”结果的最常见原因之一是“发件人组织”没有完全且适当地提交所有必需的配置设置。

例如，发件人组织没有将代表其域的邮件服务器的所有必需信息添加到 SPF 记录中。

我们再次面临同样的困境：

情况 1 - 如果我们因 SPF 验证测试失败而决定拒绝电子邮件，我们将面临误报事件的风险。

其含义是 - 我们错误地将合法电子邮件识别为欺骗邮件并因此阻止该电子邮件的情况。

情况 2 - 如果我们决定接受电子邮件，尽管 SPF 验证测试失败，我们仍会冒出现误报事件的风险。
含义是 - 一个场景其中我们接受了一封非合法电子邮件
（欺骗电子邮件），该电子邮件设法绕过我们的“防御墙”并到达我们其中一位收件人的邮箱。

为我们的组织选择“正确的”发件人验证标准

可用于实施发件人验证过程的众所周知的公共标准是：SPF 和 DKIM。

DMARC 是一项附加邮件标准；作为 SPF 和 DKIM 发件人验证标准的消除或增强。

每个标准都使用不同的方法来验证发送者身份，每个标准都有其优点和缺点，并且每个标准的实施和管理都不同。

作为建设我们的国防基础设施过程的一部分，我们需要决定我们的国防基础设施中包含的具体成分。

我们需要回答的问题的示例可能是：

问题1：我们应该采用特定的发件人验证邮件标准还是多个发件人验证邮件标准的组合？

问题2：每个发件人验证邮件标准的优缺点是什么？

Q3：如果我们的邮件环境（例如基于Exchange的环境）提供了另一种解决方案来满足“发件人验证”的需要，我们应该使用该解决方案还是仅使用公共邮件标准？

Q4：如果我们决定使用两个或多个发件人验证标准的组合，是否有建议在开始和将来采用的特定标准，请采用“附加发件人验证”标准”？

有哪些因素会影响我们对“如何处理被识别为欺骗邮件的邮件？”这一问题的决定？

关于如何处理被识别为欺骗邮件的电子邮件的问题，我想涉及两个不同的方面：

1.欺骗邮件攻击的具体类型\方向

欺骗邮件攻击可以通过以下方式实现：

• 敌对分子通过向我们的用户发送欺骗邮件来攻击我们的组织的场景。
• 敌对分子利用我们的身份攻击其他组织的场景。

2.我们希望针对欺骗邮件“执行”的具体操作

可以对根据三个主要因素确定的电子邮件执行的特定操作：

• 欺骗邮件攻击的具体场景如上所述。
• 我们使用的特定邮件基础设施 - 我们可以选择的操作取决于我们使用的邮件基础设施。
• 我们对假阳性事件和假阴性事件的容忍程度。

有关欺骗性电子邮件的确定性级别

• 尽管对于欺骗邮件攻击的场景，我们的自然倾向是“黑白分明的答案”，但现实情况要复杂一些。即使我们的防御系统将特定电子邮件识别为“欺骗邮件”，我们也永远无法 100% 确定该电子邮件是欺骗电子邮件的中继。
• 造成这种“不确定性”的原因是，在我们的防御系统将特定电子邮件识别为“欺骗邮件”的情况下，总是存在合理的可能性，原因是技术问题或错误配置“另一方”（代表发件人的源邮件系统）。

欺骗邮件攻击以及受到攻击的具体系统

如前所述，欺骗邮件攻击可以通过两种主要方式实现：

情况1 - 敌对分子攻击我们组织用户的场景。

情况2——敌对分子利用我们的组织身份，攻击其他组织的情况。

区分这两种情况的必要性是——因为我们需要针对每个场景中的“如何处理欺骗邮件”的问题使用“不同的指令集”。

例如：

情况 1 - 在敌对分子攻击我们组织用户的情况下，关于“如何处理欺骗邮件”的答案是我们的决定，因为，E-邮件消息“试图进入”我们受保护的大院，而我们作为“看门人”，可以决定如何处理“欺骗性电子邮件”。

我们关于所需采取行动的决定取决于另一个问题——我们对误报事件场景的容忍程度是多少。

换句话说，我们是否愿意冒险，在某些情况下，合法的电子邮件会被错误地识别为欺骗邮件，并因此被阻止或删除？

如果我们不愿意冒误报事件的风险，我们将需要决定“另一项行动”，而不是仅仅销毁“欺骗邮件”。

情况2 - 在敌对分子利用我们的组织身份攻击其他组织的场景中，主要的不同之处在于，在这种情况下，我们实际上无法控制将要发生的“行动”被“另一边”带走。

• 我们不知道对方是否使用了发件人身份验证的保护机制。
• 如果对方使用保护机制来验证发送者身份，我们并不真正知道他使用的具体发送者验证标准是什么。
• 即使“另一方”使用与我们相同的发件人验证标准，我们也无法“强制”另一方对使用我们组织身份的欺骗邮件执行特定操作。

值得一提的是，一些发件人识别标准（例如 SPF 和 DMARC）使我们能够“指示对方”关于“如何处理
被识别为欺骗的电子邮件”的问题电子邮件消息。”

假设我们可以指示“另一方”在这种情况下（敌对分子利用我们的组织身份攻击特定组织的情况）应该做什么，那么关于“我们的指示将是什么”的答案取决于另一个问题——我们对假阳性事件的容忍程度是多少。

换句话说，我们是否愿意冒险，在某些情况下，我们的用户发送的合法电子邮件会被错误地识别为欺骗邮件，并因此被阻止或删除？

例如，如果我们指示“另一方”删除使用我们域名并被“标记”为欺骗邮件的电子邮件，则风险在于该特定电子邮件是合法电子邮件邮件消息，验证检查认为“失败”的原因是因为某些技术问题。

我们想对欺骗邮件做什么？

这个问题的明显答案是 - 删除每封被识别为欺骗邮件的电子邮件，因为该电子邮件是由敌对分子发送的！

这个问题的真正答案并不那么简单，因为实际上有几个因素会影响我们的决定。

在本节中，我想回顾一下当我们使用 Exchange 或 Exchange Online 邮件服务器时，针对被识别为欺骗邮件的电子邮件，我们可以使用的一些“操作”选项。

我们将选择的具体行动取决于我们的业务和组织需求。

情况一——敌对分子攻击我单位用户的场景。

在这种情况下，当我们的防御系统将特定电子邮件识别为欺骗邮件时，我们可以 100% 控制我们想要执行的“操作”。

我们使用的具体操作取决于我们使用的“邮件安全网关”。

在基于 Exchange 的环境（本地 Exchange 或 Exchange Online）中，我们通过使用 Exchange 规则来实施有关欺骗邮件的期望策略。

使用交换规则，使我们能够从大空间选项中选择所需的操作。

例如，我们可以选择以下“操作”之一：

• 删除电子邮件信息
• 将电子邮件发送到用户隔离区 - 术语“用户隔离区”定义了一个受限空间，Exchange 用户可以访问该空间并决定是否要接受或拒绝电子邮件。
• 将电子邮件发送到管理隔离区 - 术语“管理隔离区”定义了一个受限空间，只有 Exchange 用户可以访问该空间并决定是否要接受或拒绝该电子邮件。
• 将电子邮件标记为垃圾邮件 - 在这种情况下，我们不会阻止电子邮件，而是将电子邮件标记为可疑电子邮件。
• 转发电子邮件以供批准——将“可疑电子邮件”发送给指定人员的过程，该人员需要检查该电子邮件并决定是否批准发布该电子邮件。

如果您认为在决定采取所需的行动后，您的“头痛”就结束了，我们需要提供其他答案。

例如：

取证阶段

Lest 涉及“不受欢迎”的场景，其中欺骗邮件设法绕过我们的防御系统，并且攻击者设法执行网络钓鱼邮件攻击。

在此阶段，我们需要实施事后分析程序，其中我们需要收集攻击的证据和试验。

我们需要分析收集到的信息，并提供一份需要回答的报告——我们的防御系统是如何被破坏的？他们是否可以选择找到执行攻击的特定敌对分子？等等。

为了能够提供这些结果，我们需要使用取证程序，从“犯罪现场”收集证据。

这给我们带来了一个非常基本的问题——如果我们的系统将特定电子邮件识别为欺骗邮件，我们该怎么办？

问题1：我们是否应该屏蔽该电子邮件，但同时将“欺骗电子邮件”的副本发送给指定人员？

问题2：我们是否应该分配一个专门的邮箱来存储“欺骗电子邮件”的副本？

问题3：哪些“人”可以访问存储“欺骗性电子邮件”的邮箱？

该等式的另一部分涉及到以下问题：我们是否需要通知相关方有关由于电子邮件被归类为欺骗邮件攻击而阻止特定电子邮件的事件？

情况2——敌对分子利用我组织身份攻击其他组织的场景。

在这种情况下，解决问题的方法——如何处理被识别为欺骗邮件的电子邮件，是完全不同的，因为实际上，我们不能强迫“另一方”做某事，而只能“建议”做某事。

例如

SPF标准，以及给对方关于欺骗邮件的指南。

如果我们使用 SPF 标准，我们添加到 SPF 记录的部分信息将包括向另一方的“建议”，该建议涉及另一方实施的 SPF 验证检查失败的场景。

我们可以在两个选项之间进行选择：

软失败 - 选择此选项时，我们是在“告诉”对方，如果使用我们域名的电子邮件未通过 SFP 测试；我们建议对方不要阻止\删除该电子邮件，而是将该电子邮件标记为“有问题的电子邮件”。

硬失败 - 当选择此选项时，我们是在“告诉”对方，如果使用我们域名的电子邮件未通过 SFP 测试；我们建议对方阻止\删除电子邮件。

DMARC 标准，以及向对方提供的有关欺骗邮件的指南。

DMARC 标准提供了一些“操作”，我们建议“另一方”使用这些操作，以防使用我们组织身份的电子邮件未通过 DMARC 测试（被识别为欺骗邮件的电子邮件） 。

监控 - 一种“中立行动”，在我们的用户发送的电子邮件被归类为欺骗邮件的情况下，我们建议对方“不采取任何行动”。

隔离 - 在这种情况下，我们建议对方“隔离”“可疑电子邮件”，因为我们的用户发送的电子邮件已被分类作为欺骗邮件。

拒绝 - 在这种情况下，我们建议对方阻止\删除该电子邮件，因为我们的用户发送的电子邮件被归类为欺骗邮件。

当前文章系列的下一篇文章

使用发件人验证来识别欺骗邮件 | SPF、DKIM、DMARC、Exchange 和 Exchange Online |第 8 部分#9