Apache Log4j 缺陷讓第三方軟體成為目光焦點

當全球各地的企業爭相解決名為 Log4Shell 的 Log4j 重大弱點時，浮現在每一位安全主管心中的第一個問題都是：我怎麼知道我們的環境中有沒有這個弱點？

開放原始碼記錄架構 Apache Log4j 的無所不在，是讓這個問題難以回答的原因。

許多企業不只在他們本身的原始程式碼中會使用 Log4j，這些企業從第三方購買的許多產品中也有使用。已採用「shift left」方式來保護軟體開發生命週期 (SSDL) 的企業可分析本身的原始程式碼，以找出與修復他們本身系統中的軟體缺陷。

您需要採用包含了靜態應用程式安全測試 (SAST)、動態應用程式安全測式 (DAST)、第三方獨立檢查、容器安全掃描、弱點管理和基礎架構即程式碼 (IaC) 的 SSDL 方式。不過，即使採用了上述所有做法，企業還是難以掌握軟體開發管線中左手邊的一切。在談到您的第三方軟體時，弱點管理與 Web 應用程式掃描也很重要。不只要能發現有沒有軟體缺陷，您也必須瞭解這些缺陷在貴公司混合了應用程式、資產與業務流程的背景下所代表的風險等級。

雖然近期拜登政府的行政命令要求企業製作一份軟體物料清單 (SBOM)，大多數的廠商還是沒有提供他們軟體的 SBOM。甚至即使他們做了，大多數企業距離具備流程及善用此清單的能力，還天差地遠。因此，當像是 log4j 的資安事端發生時，網路安全主管只有一個選擇，那就是把他們的第三方廠商叫來詢問。這項工作十分艱鉅、繁複且耗時，讓企業在攻擊者突然惡意刺探此缺陷時措手不及。

常見問題：CVE-2021-45046、CVE-2021-4104：有關 Log4Shell 和相關弱點的常見問題。

即使在最成熟的企業裡，SSDL 做法和 SBOM 都已根深蒂固於流程中，還是會有未發現的缺口讓資安部門難以回答以下 5 個重要的問題：

1. 我們的環境中有嗎？
2. 我們的基礎架構呢？
3. 在我們的組建管線中又是如何？
4. 我們的基礎架構供應商呢？(如果您正在使用雲端服務供應商的服務，這一點尤其與您相關)
5. 由於軟體組成分析 (SCA) 不會搜尋 Log4J 的所有執行個體，我們是否執行了其他控管機制，例如基礎架構即程式碼 (Infrastructure as Code，簡稱 IaC)、弱點管理以及 Web 應用程式掃描，以找出程式碼的所有元件？

結論是：要修復 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 和相關弱點的常見問答集
• 閱讀技術長觀點：Apache Log4j 缺陷：網路安全產業的福島核電廠等級重大事故
• 造訪我們的使用者社群，深入瞭解 Tenable 如何提供協助：https://community.tenable.com/s/