Apache Log4j 缺陷让第三方软件成为关注焦点

随着全球各地的企业争分夺秒解决严重的 Log4j 漏洞（又称为 Log4Shell），每个安全领导者心中的头号问题是：我如何知道企业中存在该漏洞？

开源日志记录框架 Apache Log4j 无处不在，让这个问题特别难以回答。

许多企业不仅在自己的源代码中使用 Log4j，而且在这些企业从第三方购买的许多产品中也在使用。对安全软件开发生命周期 (SSDL) 采用“左移”方法的企业可以分析自己的源代码，以发现并修复自己系统中的缺陷。

您需要采用包含静态应用程序安全测试 (SAST)、动态应用程序安全测试 (DAST)、第三方依赖性检查、容器安全扫描、漏洞管理和基础设施即代码 (IaC) 的 SSDL 方法。但是，即使采用了所有这些做法，企业仍将难于掌控软件开发生命周期左手侧的一切。特别是，如果采用了第三方软件，漏洞管理和 Web 应用程序扫描也是至关重要。仅仅发现缺陷是否存在不足以解决问题，您还必须了解这些缺陷在企业混合了应用程序、资产和业务流程的环境中所代表的风险等级。

最近，尽管拜登政府发布的行政命令要求企业制定一份软件物料单 (SBOM)，但大多数供应商并没有为其软件提供 SBOM。而且，即使提供了，大多数企业距离有效使用此物料单的流程和能力还遥不可及。因此，当 log4j 之类的安全事件发生时，网络安全领导者只有一个选择：把第三方供应商叫来并询问。这项工作十分艰巨、繁复且耗时，让企业在攻击者突然利用漏洞攻击时措手不及。

常见问题：CVE-2021-45046, CVE-2021-4104: 关于 Log4Shell 和相关漏洞的常见问题。

即使在最为成熟的企业中，SSDL 做法和 SBOM 已经在流程中牢牢扎根，还是会有安全缺口，让安全企业很难回答下面五个重要问题：

1. 在环境中运行这些软件吗？
2. 在基础设施中呢？
3. 在构建管道中呢？
4. 基础设施提供商呢？（如果您使用的是云服务提供商提供的服务，则这一点尤其与您相关）
5. 由于软件组成分析 (SCA) 不会发现 Log4J 的所有实例，我们是否运行了其他控制机制，如基础设施即代码 (IaC)、漏洞管理和网络应用程序扫描，以发现代码的所有组件？

结论是：修复 Log4j 并非举手之劳。一个显而易见的预防方法就是实施 Web 应用程序防火墙，这已被证明是防范此漏洞相当简单的方式。负责任的企业必须更新其核心软件，并了解该缺陷对整体风险状况造成何种影响。企业现在采取的措施都是在紧急模式下做出的决策；一旦初步度过危急，这个考验就会被宣布为“任务完成”，然后弃之不理。而从我们看来，这可是个毁灭性的错误。我们已经完美错过企业修复其基础架构，并且以安全优先的方式维护系统的时机。

Tenable 致力于维护 SSDL 并采取下列措施来应对 Log4j：

• 我们采用防堵法，在本例中，我们会防止使用任何有漏洞的软件实例，其中包含 Log4j。
• 我们在所有的基础设施以及在产品发运给客户前的预先发行版产品代码中，主动且持续执行漏洞管理扫描和 Web 应用程序扫描。
• 此外，我们还对所有入侵指标和攻击采取了措施，在网络和主机级别实施了控制措施。

我们将继续通过监控威胁情报来跟踪威胁态势并根据需要进行调整。处理任何安全事件归根结底要知道您的环境中有什么，弄清楚您的攻击面，包括所有第三方的攻击面，才能快速降低风险。时间是关键。攻击对手总是随时准备利用最新的漏洞，并根据自己的使用情况安排新用途。企业必须尽一切所能仔细审视他们当前的做法，此安全事件引发的连锁反应在未来数年仍会困扰企业软件。

了解详情

• 访问 Tenable Log4j 解决方案中心：https://www.tenable.com/log4j
• 阅读 SRT 警报：CVE-2021-44228: Apache Log4j 关键代码执行漏洞的概念验证现已可用 (Log4Shell)
• 阅读常见问题：CVE-2021-44228，CVE-2021-45046，CVE-2021-4104： 有关 Log4Shell 和关联漏洞的常见问题
• 阅读 CTO 的观点：Apache Log4j 缺陷： 网络安全行业的福岛时刻
• 访问用户社区深入了解 Tenable 如何提供帮助：https://community.tenable.com/s/