从身份开始，而不是事件标签
商业电子邮件泄露 描述了一种有害的业务场景，而不是一个唯一的电子邮件身份验证结果。欺骗性请求可能来自冒充域、受损的供应商邮箱、被滥用的内部帐户或使用合法发送基础设施的未经授权的应用程序。调查必须确定所提供的身份、哪个系统对其进行了身份验证以及接收者认为其代表哪个业务机构。如果没有这种分离，团队可以修复错误的控制，而潜在的风险仍然存在。
这 IC3 基于云的电子邮件咨询，日期为 2020 年 4 月 6 日，描述了受损的云电子邮件帐户如何支持 BEC，并建议独立验证和帐户保护。这是背景指导，而不是当前事件的证据。 Microsoft 的受损帐户指南 同样描述了Microsoft 365中的邮箱滥用和调查。两个消息来源都没有证实假设练习中讨论的任何帐户实际上已被泄露。
保留请求并暂停业务操作
第一个操作问题是消息要求某人做什么：更改付款详细信息、发布信息、批准访问、更改供应商记录或采取其他相应操作。用中性语言记录动作。当请求可疑时，通过组织既定流程暂停执行。避免将调查本身变成未经授权的付款、账户变更或披露。分析师可以记录该请求而不需要遵循它。
将原始消息和相关业务记录保存在经批准的限制位置。屏幕截图可以显示演示，但不能替代完整的消息证据。转发的副本可能会更改上下文并添加标头；相应地标记它。保留时区的年表并确定每个物品的收集者。对于共享摘要，请删除不必要的个人数据，同时保留比较身份所需的区别。请勿将凭证、访问令牌或完整的敏感信件作为常规故障排除材料进行传播。
构建身份堆栈
列出可见的显示名称、解析的发件人地址、回复地址、 信封发件人, DKIM 签名域、接收者身份验证结果和所谓的业务角色。仅当授权调查证据表明其存在时才添加邮箱或应用程序帐户。这些是单独的行，不能互换“发件人”的标签。验证消息的域可能与接收者推断其权限的人不同。
RFC 9989 使边界明确： DMARC 用途 域对齐 并且不验证域以外的实体或分析内容。因此，成功的一致结果不能证明发票、新的银行详细信息或高管的批准。相反，失败的结果并不能证明 帐户接管。调查应避免从协议结果跳到关于谁控制某人账户的结论。
为每个观察建立信任边界
确定哪个接收者产生了身份验证结果以及记录是否是通过该接收者的受信任接口或日志获取的。 RFC 8601 解决信任问题 Authentication-Results 断言。发件人可能包含具有误导性的文本，因此仅存在字段是不够的。记录将断言视为本地且受信任的基础。如果不存在该基础，请将结果标记为未经验证，而不是将其重复为事实。
应用程序日志和帐户审核记录回答不同的问题。发送日志可能会显示提交成功，但无法证明是人为的。邮箱审核可能会显示规则更改，但无法证明该规则是恶意的。在授权的情况下将按时间、帐户和消息标识符进行的观察结合起来，在链接较弱时保留不确定性。避免将单个异常位置或孤立的错误视为妥协的决定性证据。
在选择控制措施之前比较机制
使用恒等和控制矩阵。对于没有一致身份验证的精确域模拟，请检查域策略和发送路径。对于显示名称或相似域名滥用，请检查表示、识别和独立业务验证。对于可疑的帐户泄露，请检查帐户访问和未经授权的操作。对于被滥用的应用程序，检查其授权和消息构造边界。在同一情况下可能会出现不止一种机制。
微软的指南列出了潜在的症状，例如可疑的收件箱规则、转发以及丢失或删除的邮件。这些是调查线索，而不是自动判决。其补救措施包括禁用受影响的帐户、撤销访问权限以及检查身份验证设备、同意的应用程序、角色和转发器。这些是授权响应者相应的行政行为。本文并不指示助手执行这些操作、授予权限或收集凭据；一旦证据支持假设，它就会确定适当的响应域。
操作比较工作表
每个假设创建一行。包括所声称的身份、支持性观察、观察来源、相互矛盾的证据、受影响的控制、提议的下一次授权检查和负责人。添加带有简单语言解释的置信标签。 “受信任的接收者报告与供应商域一致的DKIM ”比“供应商确认安全”更窄且更有用。 “收件人记住显示名称”并不等同于经过身份验证的供应商地址。
添加单独的业务验证行。确定在可疑请求之前建立的联系渠道、需要确认的确切更改、授权验证者和记录的结果。响应应确认或拒绝所请求的业务操作，而不仅仅是联系人识别发件人姓名。请勿使用仅在可疑消息中提供的电话号码、链接或替代地址作为独立验证。本建议的工作表不是已执行的事件响应记录。
虚构诊断：发票变更请求
虚构制造商收到更改供应商付款目的地的请求。显示名称与客户经理匹配，可信接收者证据显示供应商真实域的一致身份验证。收件人认为这排除了 BEC。相反，安全团队记录了一个更狭隘的结论：该消息使用了经过身份验证的供应商域路径。供应商帐户、集成或授权人员是否发起了更改仍然未知。
使用先前记录的供应商联系方式，企业主将验证具体提议的变更。授权的供应商响应者将调查他们自己的帐户和应用程序证据。如果供应商拒绝该请求，则该拒绝支持停止更改，但其本身并不识别电子邮件的发送方式。在账户或服务证据解决该机制之前，案件将保持开放状态。整个例子都是虚构的；未获得付款详细信息、供应商帐户或真实信件。
用正确的证据消除每一个不确定性
合理的结论说明观察到了什么、支持什么机制、仍然不确定什么以及通过授权改变了哪些控制。不要将来自受影响域的每封邮件都标记为恶意，声称DNS编辑包含帐户接管，或者仅仅因为稍后的邮件经过身份验证就声明修复已完成。业务流程验证、帐户遏制和邮件身份验证各自回答了不同的问题。
该目录需要根据可信消息证据构建经过编辑的身份和控制比较。该证据仍然存在。该草案提供了一种方法和虚构的案例，并非可信的原始消息材料。独立的专家审查、当前来源的适用性、生产路线检查、视觉可达性和所有者发布也都是开放的。发布应等待授权的证据包来证明比较，而不会暴露敏感帐户数据或暗示发生了未执行的响应操作。