Log4j 漏洞回溯分析第 4 部分：从 Log4j 漏洞中汲取的五个经验教训
在 Log4j 漏洞回溯分析系列的第 4 部分，我想着重总结一些重要经验教训。业界仍在为彻底封堵这一漏洞而努力，因此我们陆续还会总结出更多的经验教训。不过在这里，我们列出了目前总结出的五条基本要点供您参考。
1.新常态
软件的复杂程度迅速提高，最终用户更频繁地要求获得新功能，两者的发展呈现愈演愈烈的趋势。为了在最终用户所要求的时间段内满足其需求，开发者必须依靠快速发展壮大的现成库、语言生态系统以及第三方基础架构与服务。因此，任何软件都会利用开发者自身从未接触过或者并非完全理解的第三方组件来实现其部分功能，而且这部分功能的比例只会越来越大。
在各类软件的依赖项图表中，漏洞均继承自叶节点（即共享代码和服务），随后影响到上级的根节点（即所编写的产品）。就像前面所说的那样，开发者必须为项目添加这种叶节点，而随着所添加叶节点的数量增加，出现漏洞的风险会不断提高。
这就引出了一个确切的结论：这些类型的漏洞不但无法彻底避免，而且出现的频率会不断提高，影响力也会不断扩大。
这就是这个领域的新常态。
2.风险具有递归性
我们常常会错误地从自身可以直接控制的系统、软件和功能的视角思考风险。但一些更具前瞻性的企业已经开始跳出这样的固有视角，从另一个层面进行风险评估；例如，要求开发者检查给定库的可信性。
然而，随着越来越多的系统和软件在构造中采用多层第三方代码，企业不仅需要评估给定库或合作伙伴的风险，很多时候还必须评估开发社区或供应商的实践做法，从而确保这些开发社区和供应商也会严谨地审查其开发依赖项。
不论您、您的合作伙伴和/或各自的开发社区，都应该对依赖项树与供应链中的每一个节点进行评估，以确定其风险水平是否在可接受的限度内。
3.全面监测助力企业高效应对漏洞
即便落实了上述风险评估，漏洞依然会出现。这是我们必须接受的事实。重点并不是完全杜绝漏洞，而是一旦出现漏洞，我们要怎样才能更有效地加以应对。
从这个角度来说， 监测能力至关重要。许多企业在修补漏洞时都举步维艰，因为他们根本不知道究竟有哪些机器受到了影响。企业必须采用有效的系统来全面监测数据中心以及云环境中运行的所有内容。
这种监测能力越全面、越准确，企业做出反应并修补必要资产的速度就越快。
4.过滤掉显而易见的攻击
对于许多漏洞来说，唯一可行的攻击方式就是漏洞利用攻击链。通常情况下，只要切断这条攻击链上的任何一点，就足以全面抵御攻击。因此，通过系统来过滤掉前期攻击以及明显的攻击十分重要。
企业应该优先考虑以下系统：
- 端点保护平台 (EPP)
保护端点免受已知恶意软件的侵扰
Web 应用程序防火墙 (WAF)
保护 Web 应用程序，以抵御已知的恶意攻击载荷和威胁行为 - 为此，我们诚意为您推荐 Akamai 卓越的 Kona 保护产品
DNS 防火墙
保护端点，以避开恶意域名并过滤掉恶意的 DNS 攻击载荷 - 为此，我们诚意为您推荐 Akamai Enterprise Threat Protection 解决方案
安全 Web 网关 (SWG)
保护端点，以避免下载恶意软件以及访问互联网上的恶意网站 - 为此，我们诚意为您推荐 Akamai Enterprise Threat Protection 解决方案
多重身份验证 (MFA)
降低攻击者利用盗用凭据访问企业内部环境的风险，因为一旦攻击者得逞，即可传输漏洞利用攻击链 - 为此，我们诚意为您推荐 Akamai MFA
基于身份的细分
对软件和系统实施限制措施，仅允许其与完成任务所必须的机器通信 - 为此，我们诚意为您推荐 Akamai Guardicore Segmentation
Zero Trust 网络访问 (ZTNA)
一旦有受感染的最终用户进入网络，尽可能限制其影响 - 为此，我们诚意为您推荐 Akamai Enterprise Application Access
5.严格实施“最小特权”原则
最后，企业应该全面采纳“最小特权”原则。锁定服务器、机器和软件，仅允许为了执行任务而确有必要的系统访问它们。
例如，在 Log4j 漏洞利用攻击中，许多发出 LDAP 出站调用的系统实际上根本不需要使用 LDAP。此类系统应该在防火墙的保护下访问 LDAP。再举一个例子：如果某项服务仅负责应答入站请求，则应阻止其出站连接。
如果您能对自己控制范围内的所有系统和软件严格实施“最小特权”原则，那么即便出现漏洞，也能大大缩小威胁面，在很多情况下，您甚至可以在受到影响之前阻止攻击链。
了解更多
感谢您一直关注本系列博文。本系列博文虽然到这里就结束了，但我们围绕漏洞开展的研究以及客户保护措施的实施工作仍在继续。如果您想进一步了解我们有关缓解 Log4j 漏洞和其他威胁的建议，请随时联系您的 Akamai 联系人。
