Log4j安全漏洞事件引发安全行业的几点思考

临近元旦，本来大家应该沉浸在一个安静祥和的节日氛围中，但由于有史以来最严重的漏洞CVE-2021-44228(Log4Shell)的出现，整个安全行业立即进入“全年无休模式”。是什么让这个漏洞变得如此特别和可怕?有多大规模的灾难正在等待着我们?我们如何才能避免发生最坏的情况?

笔者希望通过本文带大家简单了解一下这个Log4Shell漏洞，但本文并不是一篇技术性文章。因为目前很多业内专家和技术高手已经对该漏洞进行了详细的剖析并制定了应对措施，笔者在这里就不班门弄斧了。但是，笔者想从安全行业从业者的角度来简单说明一下为什么这个漏洞会引起如此大的恐慌，以及整个事件背后暴露了哪些值得我们思考的问题。

图片来源于互联网

为什么Log4Shell漏洞会引起如此大的恐慌

内因：Log4Shell漏洞涉及范围广泛且易于利用

Log4Shell漏洞本身就具有不良的特征，并且利用起来也非常简单。由于它是与数据相关的漏洞，因此不是与网络连接的系统，凡是与相关数据有关联的系统就会受到攻击。在云端深处的某个地方，可能就潜伏着Log4Shell漏洞。值得庆幸的是，目前利用Log4Shell漏洞的工具还没有出现，但一旦有人开发出使用工具，数据存在的整个网络空间极有可能发生爆炸性灾难。

我们之所以称其为“爆炸性灾难”的原因如下：

• 一是Log4j，这个被发现Log4shell漏洞的软件，毫不夸张地讲在世界上任何地方随处可见，您甚至不需要访问权限。

• 二是但凡使用Java的环境中，就无法保证100%的安全。虽然您可以对所有Log4j的漏洞进行修补，但您可能无法找到所有的Log4j，因为使用Java制作的应用程序无处不在。

• 三是该漏洞利用起来非常简单，攻击者只需要怂恿受害者在日志中写入一些东西就能完成。为此，黑客们迄今为止已设计出无数种方法，有很多简单的方法，也有很多虽然复杂但确实有效的方法。

• 四是检测结果可能由于开始检测的时间不同而存在显著差异。在这种情况下，检测结果可能不正确，脆弱的系统可能会被诊断为坚固。

外因：行业 “内卷”现象严重以及盲目的“安全信心”

修补Log4shell漏洞本身就是件很困难的事情，但在安全行业内部还出现了相互伤害的行为。例如，假设第三方添加了关于Log4j漏洞的新规则。当然，这种应对方式是非常积极的。然而，这样做使得很难相信外部的漏洞扫描结果。随着攻击者的攻击行为变得更加困难，安全行业的检测也将变得更加困难。如此以来就增加了虽然处于危险状态但在没有意识到危险的情况下通过检测的可能性。

打个比方，我们制造了一台扫描仪。这是一款能够遍历客户网站并查找漏洞的扫描仪。但是，由于客户更改了某种设置并添加了新的规则，导致扫描无法正常进行。当然，我们可以对每个站点进行额外的定制扫描，但我们制造扫描仪的初衷并不是仔细检查每个站点，而是快速找到所有站点的脆弱因素和漏洞。

并且，仅根据扫描结果就认为“我们是安全的”也是致命的错误。有人可能会问，谁会相信匆忙制造的扫描仪得出的结果呢?但是，如果市场上的其它扫描解决方案也存在类似的问题呢?为了暂时防止Log4Shell漏洞被利用而更改的设置正在向用户提交“看起来不错”的安全检测结果，这一事实现在对于任何扫描仪都不例外。

笔者在这里想强调的是，我们需要清楚地认识到我们现在使用的所有安全检测工具都存在局限性。不要通过一次检测就向客户报告“您的公司是安全的”，而是要告知我们的客户“即使您在这里得到了很好的检测结果，实际上也可能面临危险”。当扫描仪给出“良好”的结果时，并不意味着您的系统是“没有漏洞的干净状态”，而是意味着“用目前的方法很难找到漏洞”。

如上所述，漏洞扫描显然存在局限性。如果你想对扫描结果100%的有信心，你必须扫描所有数字元素的所有源代码。通过这种方式，您可以一一过滤掉所有存在漏洞的脆弱版本。然而这种漏洞扫描方式在现实生活中可能实现吗?因此，笔者认为，今后与Log4j安全漏洞相关的“事后处理工作”可能要持续数月，甚至更长的时间。因为我们目前还不具备能够方便地自动查找深入网络空间内所有要素的技术。

我们从此次漏洞事件中看出的几个问题

一是对大规模网络攻击没有做到未雨绸缪

过去，我们经历了多次诸如“永恒之蓝”(WannaCry)和“太阳风”(SolarWinds)等这种大规模网络攻击事件，它们的名字也被永远“铭记”在网络安全漏洞库中。为了防止再次出现类似的混乱，一部分安全组织研究制定了一整套的防范措施，但绝大部分的安全组织仍然没有对大规模网络攻击做好充分准备，并且对其技术堆栈中的内容一无所知。通常情况下，将修补程序应用于受影响的系统是缓解威胁的有效途径，但如果IT团队开始时没有全面了解其网络中的内容，则无法采取迅速果断的行动。

二是对资产清点和管理没有做到了然于胸

如此大规模和快速的攻击也凸显了资产清点和管理的重要性，而这在日常工作中往往会因IT运营和安全团队之间的裂痕而难以实现。在 Log4j漏洞爆发后，各地的首席信息安全官(CISO)都在询问他们的团队“我们的暴露情况如何?”如果安全团队没有准确的设备和软件目录，就无法正确回答这个问题。虽然这很困难，而且是安全运营框架中经常被遗忘的元素，但不断发展和严峻的 Log4j 漏洞事件表明，拥有一个完整的视图以在需要的地方快速修复补丁是多么的重要。

三是安全响应碎片化没有做到组织有序

近年来，随着网络攻击越来越有组织化和复杂化，因此也越来越强大难以应对。而当前安全行业对于网络攻击的响应是“无组织的”，仍然处于单打独斗式的“碎片化”处理。我们需要更多更先进的技术方法来系统应对这种大规模且性质严重的网络安全事件。无论 Log4Shell漏洞的情况是多么糟糕、多么严重，总有一天会得到解决。但是下次再发生类似的事件时，如果我们还是同样手足无措，那就是我们的错误。我们现在必须具备应对下一次Log4Shell漏洞事件的能力。

解决当前这种“响应碎片化”局面的技术方法

为了解决安全响应“碎片化”问题，在这里我们不得不介绍一下“安全统筹与自动化响应(SOAR)”技术。SOAR 的全称是 Security Orchestration, Automation and Response，意思为安全统筹自动化与响应。该技术聚焦安全运维领域，重点解决(但并不限于)安全响应的问题，最早是由Gartner公司在 2015 年提出的。

为了应对日益有组织化和复杂化的网络犯罪，如今的安全组织正在运营基于各种安全解决方案的安全控制(SOC, Security Operation Center)平台，识别和应对威胁要素。然而，随着高级网络攻击的数量日益增加，繁杂的安全工具、安全人员短缺、人员能力差距等问题也随之显现，目前的安全解决方案无法识别和有效应对所有安全威胁。因此，作为提高安全控制效率和降低安全控制中心复杂性的解决方案，预计未来对“安全统筹与自动化响应”技术的需求将进一步增大。

SOAR技术的三大核心能力包括：△着眼于规范响应流程，缩小人员能力差距，解决专业人才短缺问题的“安全事故响应平台(SIRP, Security Incident Response Platforms)”，△通过运营多种安全解决方案，以减少联动复杂性和管理负担的“安全统筹与自动化(SOA, Security Orchestration and Automation)”， 以及△通过收集和分析威胁数据提前构建响应体系的“威胁情报平台(TIP, Threat Intelligence Platforms)”。

与所有安全技术一样，并非所有安全威胁都可以通过采用SOAR来进行检测和响应。但是，利用以标准化的安全控制流程为基础，将不同攻击类型的响应要素组合到一个流程的“剧本”，可以避免安全组织在众多安全业务中出现“孤岛”现象，并能更快地找出潜在的威胁因素。通过这种方式，可以缩短从威胁检测到响应的过程，从而建立更先进的安全控制体系。

结语

虽然正确预测未来是一件非常困难的事，但这里有一点是可以肯定的：至少在接下来的几周时间内，许多组织将花费大量时间寻找Log4j中的安全漏洞。这并不一定是件坏事。就像新冠肺炎疫情很可能不是最后一次流行病一样，将来也无法避免像这样搜索所有网络空间和网络环境的事情。正好借助Log4Shell漏洞事件，作为一次全面了解网络空间的契机，这对安全行业发现自身存在的问题和不足也是大有裨益的。