CISA Insights：增强邮件与 Web 安全

美国网络安全和基础设施安全局（Cybersecurity and Infrastructure Security Agency, CISA）· 源自约束性操作指令 BOD 18-01《Enhance Email and Web Security》· 文献类型：CISA Insights 洞察报告（美国政府作品，公共领域）

一、概览（AT-A-GLANCE）

1.1 建议要点（RECOMMENDATIONS）

序号	建议动作
1	采用至少为 p=none 的 DMARC 策略
2	在所有对外域名上部署带 HSTS 的 HTTPS
3	在 Web 与邮件服务上禁用弱加密标准
4	持续保持对 DMARC 发现结果与报告的可见性

二、网络安全威胁（CYBERSECURITY THREAT）

钓鱼邮件与未加密的超文本传输协议（HTTP）的使用，始终是恶意行为者借以利用组织网络安全态势弱点的持续性通道。攻击者可能伪造（spoof）某个域名，发送一封看起来来自合法来源的钓鱼邮件。与此同时，通过未加密的 HTTP 协议传输数据的用户——该协议无法保护数据免遭拦截或篡改——面临被窃听、被追踪以及数据本身被修改的风险。

美国网络安全和基础设施安全局（CISA）鼓励其州、地方、部落与领地（State, Local, Tribal and Territorial, SLTT）政府伙伴以及私营实体，使用本指南来进一步了解该威胁及相应的缓解措施。本指南源自《约束性操作指令 18-01——增强邮件与 Web 安全》（Binding Operational Directive 18-01 - Enhance Email and Web Security），并纳入了经验教训，以及为那些希望按照 CISA 对联邦文职部门与机构的要求同步落实相关动作的非联邦实体所准备的补充考量。

三、攻击剖析（ATTACK BREAKDOWN）

3.1 攻击原理（How It Works）

邮件（Email）

• 攻击者伪造某个信誉良好的组织的域名，并发送一封看起来是合法邮件的邮件。

Web

• 通过 HTTP 发送的数据易被拦截、篡改和冒充。这些数据可能包括浏览器身份标识、网站内容、搜索词以及其他用户提交的信息。

3.2 为何奏效（Why It's Effective）

邮件（Email）

• 其他组织或公众成员可能收到被伪造的邮件，认为其来自权威来源，并据此采取行动。
• 内部员工可能会认定被伪造的邮件是合法的，并据此采取行动。
• 如果攻击者成功伪造某个域名并借此发送恶意邮件，将会严重损害受影响组织的声誉。

Web

• 未加密的 HTTP 连接会造成隐私漏洞，并暴露有关未加密网站与服务的用户的潜在敏感信息。

四、近期建议动作（NEAR-TERM RECOMMENDED ACTIONS）

为应对钓鱼邮件与使用未加密 HTTP 协议给组织信息与信息系统带来的重大风险，CISA 已要求联邦文职机构开展下列一系列近期动作，并鼓励非联邦组织同样照此执行：

4.1 缓解钓鱼邮件攻击的动作（Actions to Mitigate Phishing Email Attacks）

1. 当接收方邮件服务器启用 STARTTLS 时，STARTTLS 会向发送方邮件服务器表明：具备对传输中邮件进行加密的能力。虽然它并不强制使用加密，但启用 STARTTLS 会使被动式中间人（man-in-the-middle）攻击更加困难。

   STARTTLS

2. SPF（Sender Policy Framework，发件人策略框架）与 DKIM（DomainKeys Identified Mail，域名密钥识别邮件）允许发送域对其邮件进行有效的「水印」标记，从而使未经授权的邮件（例如垃圾邮件、钓鱼邮件）易于被检出。当收到一封未能通过某组织已发布的 SPF/DKIM 规则校验的邮件时，DMARC（Domain-based Message Authentication, Reporting & Conformance，基于域的邮件认证、报告与一致性）会告知接收方：域名所有者希望如何处置该邮件。
3. 将 DMARC 策略设置为 reject（拒绝）可提供针对伪造邮件的最强保护，确保未通过认证的邮件在投递之前即在邮件服务器上被拒收。此外，DMARC 报告为组织提供了一种机制，使其能够获知明显伪造行为的来源——这些信息在通常情况下是无法获得的。可以为接收 DMARC 报告定义多个收件人。

   v=DMARC1; p=reject;

4.2 增强 Web 安全的动作（Actions to Enhance Web Security）

1. HTTP 连接很容易被监听、修改和冒充；超文本传输安全协议（Hypertext Transfer Protocol Secure, HTTPS）可修补上述每一项弱点。HTTP 严格传输安全（HTTP Strict Transport Security, HSTS）可确保浏览器始终使用 https:// 连接，并去除用户点击忽略证书相关警告的能力。

   Strict-Transport-Security

2. 各组织应审视自身在 HTTPS 与 HSTS 部署上的进展，例如移除对已知弱加密协议与弱密码套件的支持。
3. 根据 CISA 的漏洞扫描数据，在《约束性操作指令 18-01》发布之时，其所观测网络中最常见的 10 类漏洞中有 7 类，都可以通过落实本指南中与 Web 安全相关的建议动作而得到解决。

4.3 从何入手（Where to Get Started）

增强邮件安全的建议

1. 将所有面向互联网的邮件服务器配置为提供 STARTTLS，并使所有二级组织域名都具备有效的 SPF/DMARC 记录，其 DMARC 策略至少为 p=none，且至少定义一个地址作为汇总报告（aggregate report）和／或失败报告（failure report）的接收方。

   v=DMARC1; p=none;

2. 确保在邮件服务器上禁用安全套接层（Secure Sockets Layer, SSL）v2 与 SSLv3，并在邮件服务器上禁用 3DES 与 RC4 密码套件。

   SSLv2, SSLv3, 3DES, RC4

3. 确保各组织将集中管理机构的地址加入 DMARC 汇总报告的接收方之列。
4. 为所有二级域名与发信主机设置 reject 的 DMARC 策略。

增强 Web 安全的建议

1. 确保所有可公开访问的网站与 Web 服务均通过安全连接提供服务（仅 HTTPS，并启用 HSTS），在 Web 服务器上禁用 SSLv2 与 SSLv3，并在 Web 服务器上禁用 3DES 与 RC4 密码套件。
2. 识别并向负责管理这些建议的集中管理机构提供一份可进行 HSTS 预加载（HSTS preload）的二级域名清单，这些域名的全部子域都将被强制使用 HTTPS。
3. 考虑就落实情况向负责管理这些建议的集中管理机构的领导层起草一份报告。
4. 在发布前收集合作方相关利益方的反馈与意见，以避免在实施过程中受到厂商方面的制约。
5. 在发布前确保验证权威机构及其机制健全并已就位，以便跟踪合规情况直至成功落实。
6. 每周向所有下属组织发送评分卡（scorecard），以在参与方之间形成竞争。

五、持续性建议动作（ONGOING RECOMMENDED ACTIONS）

1. 广泛开展宣贯外联工作，并为技术问题以及实施问题提供支持。
2. 举办实施活动与技术交流，为落实工作提供更多指导。
3. 每周向领导层发送评分卡，以提升关注度并激励改进。
4. 建设面向公众的网站，提供指导与常见问题解答（FAQ）。
5. 识别不合规情况，以便开展后续沟通。
6. 建立一个集中的 DMARC 报告汇集点，接收全部 DMARC 报告，并向所有相关方提供分析结果。

六、经验教训与补充考量（LESSONS LEARNED AND ADDITIONAL CONSIDERATIONS）

6.1 经验教训（Lessons Learned）

1. 由于人们对 DMARC 的工作原理普遍存在误解，且担心邮件可能「丢失」，负责管理这些建议的集中管理机构应编制指导材料，与非技术人员分享。
2. 许多组织并不理解为何需要用 DMARC 保护不发信的邮件域名。采用 DMARC 有助于组织更好地了解邮件使用情况，并对发信域名进行归类。
3. 各组织需要更高层级的治理来指导其在这些标准方面的行动。未来环境中的变更可能导致脆弱性上升。
4. 各组织在录入 DNS 记录时应格外谨慎，因为该环节对错误非常敏感。
5. 尽管目标是让缓解最佳实践达到 100% 的采纳率，但组织的环境会发生波动，导致成熟度参差不齐。采纳进度通常平均在 90%～95% 的水平上趋于「成熟」。

6.2 实施考量（Implementation Considerations）

1. 围绕「间接邮件流」（indirect email flows）——即邮件经由中间方（邮件列表、账户转发）发送——所存在的挑战已被公认为一个问题，并在下文参考资料中作了进一步讨论。
2. 在邮件环境中禁用 3DES 存在明显的厂商制约。
   1. Microsoft 已声明将于 2019 年 7 月开始禁用。
   2. Google 已推出 MTA-STS 作为解决方案。
      1. Google 博客：
3. 注意扫描需要身份认证的站点时可能出现的问题。
4. 在发布前对资产清单／环境有确切的掌握。
5. 在发布前确立内部的成功衡量指标。
6. IT 组织较为集中统一的实体在实施上效率更高。

6.3 资源考量（Resource Considerations）

1. 许多组织，尤其是规模较小的组织，可能缺乏 DMARC 方面的专业能力，需要外部支持才能落实 DMARC。
2. 在没有工具辅助的情况下，阅读和理解 DMARC 报告极其困难。
3. 落实本指南所建议的各项动作，可能会带来预算方面和／或合同／厂商方面的影响。

七、有用链接与参考资料（HELPFUL LINKS AND REFERENCE MATERIALS）

• CISA 约束性操作指令 BOD 18-01《Enhance Email and Web Security》及其常见问题解答（FAQ）
• 英国国家网络安全中心（UK National Cyber Security Centre, NCSC）Mail Check
• GitHub 仓库：ElasticMARC —— 基于 Elastic Stack 的 Windows 平台 DMARC 汇总报告摘要与分析工具
• GitHub 仓库：Dmarcian XML 转人类可读格式转换器
• DMARC.org 及其代码与程序库页面（Code and Libraries Page）
• 全球网络联盟（Global Cyber Alliance）——邮件认证与 DMARC TXT 记录的收益说明
• 认证接收链（Authenticated Received Chain, ARC）邮件转发指导
• 如需进一步指导，各组织应查阅美国国家标准与技术研究院（National Institute of Standards and Technology, NIST）特别出版物 SP 800-177《Trustworthy Email》（可信邮件）