最少有框架要求的安全主题，以及这为何重要

仅依据合规要求构建的安全计划，在各框架一致的地方往往最强，而在框架沉默的地方最弱。我们按十一个框架中有多少个将要求映射到各主题，对 ControlMapping 的全部五十个主题进行了排序。这份列表末尾的主题，正是以框架为导向的计划最可能存在盲区的地方。

要求最少的主题

主题	映射于	在…中无映射
DNS 安全	4 / 11	SOC 2, PCI DSS, CMMC, HIPAA, GDPR, NIS2, Essential Eight
API 安全	5 / 11	SOC 2, CMMC, HIPAA, GDPR, NIS2, Essential Eight
业务环境	5 / 11	CIS v8.1, CMMC, HIPAA, GDPR, NIS2, Essential Eight
威胁情报	5 / 11	CIS v8.1, SOC 2, HIPAA, GDPR, NIS2, Essential Eight
WAF	6 / 11	CMMC, HIPAA, GDPR, NIS2, Essential Eight
Web 安全	7 / 11	HIPAA, GDPR, NIS2, Essential Eight
取证分析	7 / 11	CIS v8.1, HIPAA, GDPR, Essential Eight
沟通	7 / 11	PCI DSS, HIPAA, GDPR, Essential Eight
移动安全	7 / 11	PCI DSS, GDPR, NIS2, Essential Eight
DLP	8 / 11	HIPAA, GDPR, Essential Eight

这些主题为何缺失

框架是在技术之上的抽象层面编写的。 ISO 27001、SOC 2 和 GDPR 描述的是适用于任何技术的结果（“保护网络中的信息”“安全开发”），因此很少点名 DNS、API 或 Web 应用防火墙。如果你的风险评估将这些主题纳入考虑，它们会通过宽泛的控制措施被隐含地覆盖。

框架跟不上威胁态势的变化。 许多框架起草时，边界还是防火墙，应用程序还是本地安装的软件。API、云托管的 Web 应用和 DNS 滥用成为常见攻击路径的速度，快于标准的修订速度。ISO 27001:2022 新增了威胁情报和网页过滤控制；CSF 2.0 加强了供应链和平台安全。其他方面则尚未跟上。

有些主题属于背景，而非控制措施。 “业务环境”（理解你的使命、利益相关方和依赖关系）是治理的基础工作。框架默认其已具备，而非对其提出要求。

为何重要

攻击者不会阅读框架。要求最少的主题中，有几个在实践中恰恰是被利用最多的：暴露的 API、存在漏洞的 Web 应用，以及 DNS 篡改。只执行审计人员要求之事的计划，可能每次审计都通过，却仍让这些漏洞敞开。

列表末尾的主题，正是你自己的风险评估必须承担框架未能承担之工作的地方。

核心要点

• DNS 安全、威胁情报、API 安全和 Web 应用防护，是我们所映射的框架中要求最少的主题。
• 这主要是因为框架在技术之上编写且修订缓慢，而非因为这些主题不那么重要。
• 要求最少的主题中，有几个在实践中正是被利用最多的攻击路径。
• 你自己的风险评估必须覆盖框架遗漏的内容，无论结论如何，都应记录一项有理有据的决定。

行动建议

• 将列表末尾的主题与你自身的攻击面进行对照检查。 如果你运行公共 API 或 Web 应用，无论框架怎么说，API 安全和Web 安全都很重要。
• 以覆盖某一主题的最具体的框架作为你的标准，即使你并未通过该框架认证。在技术主题上，CIS Controls 和 PCI DSS 往往比 ISO 27001 更具体；各主题页面会显示谁要求了什么。
• 记录决定。 如果你的风险评估认为某一主题不适用，请写明理由。审计人员接受有理有据的排除；攻击者则不在乎你怎么想。

对照映射矩阵一览全部五十个主题与十一个框架的对应情况。若想看列表另一端的内容，请参阅所有框架共有的主题。

常见问题

哪些安全主题要求的框架最少？

在 ControlMapping 的数据中，DNS 安全、威胁情报、API 安全、业务环境和 Web 应用防火墙，是 11 个框架中映射最少的主题。

如果某个框架没有要求某项控制，我能跳过它吗？

从合规角度看，或许可以；从安全角度看，几乎不行。大多数框架基于风险，因此某个主题缺失通常意味着“由你的风险评估覆盖”，而非“没有必要”。

哪个框架对 API 安全覆盖得最好？

没有哪个框架能全面覆盖。CIS Controls 的应用软件安全控制，以及 PCI DSS 关于安全开发和面向公众的 Web 应用的要求，是其中最具体的；OWASP 的 API Security Top 10 是常用的技术参考。