NIST SP 800–190 Part 3結論

12 min readAug 3, 2023

根據NIST SP 800–190 Part 1與Part 2的介紹與說明之後。我們在本文中舉一個範例來驗證其反制措施的有效性。同時也會針對容器技術的生命週期安全管理說明，最後做出其結論。

容器威脅的場景

利用Image中的漏洞

容器化環境最常見的威脅之一是容器內軟體中的應用程式漏洞。例如，企業經常為Web service建立Image。如果該應用程式存在漏洞，則可能會被用來破壞容器內的應用程式。一旦被攻擊，攻擊者可能能夠mapping到環境中的其他系統，嘗試提升受感染容器內的權限，或用該容器來攻擊其他系統。

採用NIST SP 800–190反制措施的企業將針對此類威脅建立多層次縱深防禦：

在部署過程的早期階段偵測有問題的Image並採取適當的控制措施來防止部署易受攻擊的Image，可以防止將漏洞導入生產環境。
Container-aware network monitoring 與filtering將在嘗試mapping其他系統期間偵測到其他容器的異常連接。
Container-aware process monitoring和惡意軟體偵測將偵測無效或惡意的processes以及它們導入環境中的資料。

Container Runtime的利用

雖然這種情況並不常見，但如果container runtime受到攻擊，攻擊者就可以利用此存取權限來攻擊主機上的所有容器，甚至主機本身。

針對這種威脅場景的相關緩解措施包括：

使用MAC功能可以提供額外的屏障，以確保Processes和filesystem運作仍然在定義的邊界內分段(Segmentation)。
工作負載分段可確保危害範圍僅限於共享主機的具有一般機敏度的應用程式。例如，只運作 Web 應用程式的Host上被攻擊的runtime不會影響運作財務應用程式容器的其他Host上的runtime。
可以回報runtime的漏洞狀態並防止將Image部署到易受攻擊的runtime的安全工具可以防止工作負載在其中運行。

運作有問題的Image

由於Image很容易從公開的位置取得，而且來源通常未知，因此攻擊者可能會在已知目標使用的Image中嵌入惡意軟體。例如，如果攻擊者確定目標在有關特定專案的討論板上處於活動狀態並使用該專案網站提供的Image，則攻擊者可能會嘗試製作這些Image的惡意版本以用於攻擊。

相關的緩減包含:

確保只有經過審查、測試、驗證和數位簽章的Image才允許上傳到企業的Registry。
確保只允許運行受信任的Image，這將防止使用來自外部、未經驗證的Source Image。
自動掃描Image中的漏洞和惡意軟體，這可能會偵測Image中嵌入的惡意代碼，例如 Rootkit。
實施runtime conmtrol，限制容器”濫用資源、提升權限和run executable”的能力。
使用container-level network segmentation來限制有問題的Image可能影響的“爆炸半徑”。
驗證容器運行時遵循最小權限和最小存取原則。
建立container runtime的threat profile。這包括但不限於processes、network call和filesystem change。
利用hashes和數位簽章在運作前驗證Image的完整性。
根據建立可接受的漏洞嚴重性等級的規則限制Image的運作。例如，防止運作具有中等或更高 CVSS 等級的漏洞的Image。

容器技術的生命週期安全管理

在安裝、配置和部署容器技術之前仔細規劃至關重要。這有助於確保容器環境盡可能安全，並符合所有相關的企業政策、外部法規和其他要求。

容器技術和虛擬化解決方案的規劃和實施建議有很多相似之處。 NIST SP 800–125 的第 5 節已包含一整套針對虛擬化解決方案的建議。這裡就不重複所有這些建議，除了下面列出的例外情況之外，企業還應在容器技術環境中應用所有NIST SP 800–125 第5 節建議。例如，不建立virtualization security policy，而是建立container technology security policy。

本文的這一部分列出了 NIST SP 800–125 第 5 節建議的例外情況和補充內容，並按規劃和實施生命週期中的相應階段進行分組。

1.初始階段

企業應考慮其他安全政策可能如何受到容器的影響，並根據需要調整這些政策以將容器考量在內。例如，事故回應（尤其是鑑識）和漏洞管理的政策可能需要調整，以考量到容器的特殊要求。

容器技術的導入大部分都會破壞企業/組織內現有的文化和軟體開發方法。為了充分利用容器可以提供的優勢，企業的流程應該進行客製，以支持這種開發、維運和支持應用程式的新方式。傳統的開發方法、修補技術和系統升級流程可能無法直接適用於容器化環境，企業內的員工願意適應新模型非常重要。 新流程需要考量並解決技術轉變帶來的任何潛在的文化衝擊。可以向參與軟體開發生命週期的任何團隊與人員提供教育訓練，讓人們熟悉構建、發布和運行應用程式的新方法。

2.規劃與設計階段

規劃和設計階段針對特定容器的主要考慮因素是鑑識(Forensics)。由於容器主要構建在OS中已有的組件之上，因此在容器化環境中執行鑑識的工具和技術主要是現有實踐的演變。容器和Image的不可變特性實際上可以提高取證能力，因為Image應該做什麼和事故期間實際發生的事情之間的界限更加明顯。例如，如果 Web service的容器突然啟動mail relay，則很明顯new processes不是Original Image會做的事情。在傳統平台上，OS和應用程式之間的分離較少，因此實現這種差異化可能會更加困難。

熟悉Server的processes、memory和disk等事故回應活動的維運團隊會發現它們在使用容器時非常相似。但是，也需要記住一些差異。

容器通常使用從Host OS虛擬化的Layered filesystem。直接檢查Host上的路徑通常只能揭示這些layer的外部邊界，而不是其中的檔案和資料。因此，在回應容器化環境中的事故時，我們應識別正在使用的特定storage provider，並了解如何正確進行離線檢查其內容。

容器通常使用virtualized overlay networks相互連接。這些overlay networks經常使用封裝和加密來讓網路流量通過安全的流經現有網路。然而，這意味著在調查容器網路上的事故時，特別是在進行任何即時網路封包分析時，所使用的工具必須了解這些虛擬化網路，並了解如何從其中提取嵌入的IP frames，以便使用現有工具進行解析。

容器內的processes和memory活動在很大程度上與傳統應用程式中觀察到的類似，但具有不同的parent processes。例如，容器運行時可以以nested方式產生容器內的所有processes，其中運行時是top-level processes，每個容器具有first-level後代，並且容器內的每個processes具有第二級後代。例如：

3.實行階段

容器技術設計完成後，下一步是在將解決方案投入生產環境之前實施和測試設計原型。我們要認知到，容器技術不提供VM技術所提供的introspection capabilities類型。

NIST SP 800–125 引用了在生產部署之前應評估的虛擬化技術的幾個面向，包括身份驗證、連接和網路、應用程式功能、管理、效能以及技術本身的安全性。除此之外，評估容器技術的隔離能力也很重要。確保容器內的processes可以存取它們被允許存取的所有資源，並且不能查看或存取任何其他資源。

實行(Implementation)可能需要專門針對容器和雲原生應用程式的新的安全工具，並且能夠了解傳統工具所缺乏的維運可見性。最後，部署還可能包括更改現有安全控制和技術的配置，例如security event logging、network management、code repositories、authentication servers等，以便直接與容器一起運用並與這些新的容器安全工具整合。

當原型評估完成且容器技術可供生產環境使用時，容器最初應用於少量應用程式。發生的問題可能會影響多個應用程序，因此儘早識別這些問題很有幫助，以便在進一步部署之前解決這些問題。

4.維運與維護階段

此階段對於維護容器技術的安全性特別重要，因此應定期執行的維運流程包括更新所有Image並將這些new image分發到容器以取代舊的。其他安全最佳實踐，例如執行漏洞管理和其他supporting layer（如Host和Orchestrator）的更新，也是關鍵的持續維運工作。容器安全和監控工具同樣應與現有的SIEM整合，以確保與容器相關的＂事件流＂可以在企業的整個IT環境的安全性有著相同工具和流程。

如果容器化環境中發生資安事故，企業應準備好使用針對容器獨特面向進行優化的流程和工具進行回應。 NIST SP 800–61《Computer Security Incident Handling Guide》中概述的核心指南也非常適用於容器化環境。然而，採用容器的企業應該確保增強對容器安全的一些獨特面向的回應。

由於容器化應用程式可能由與一般傳統維運團隊不同的團隊維運，因此企業應確保負責容器操作的任何團隊都納入事故回應計劃並了解他們在其中的角色。
正如NIST SP 800–190中所討論的，容器管理的短暫性(ephemeral)和自動化性質可能與企業傳統上使用的資產管理策略和工具不一致。事故回應團隊必須能夠了解容器的角色、所有者和機敏度，並能夠將這些資料整合到他們的流程中。
應制定明確的程序來回應容器的相關事故。例如，如果某個特定Image正在被駭客利用了，但該Image正在數百個容器中使用，則回應團隊可能需要關閉所有這些容器以阻止攻擊。雖然單一個漏洞長期以來能夠在許多系統上引起問題，但對於容器來說，事故回應可能需要廣泛重建和重新部署new image，而不是向現有系統補丁。 這種事故回應的變化可能涉及不同的團隊和批准，應該提前理解和實踐。
如前所述，日誌記錄和其他鑑識資料可以以不同的方式存儲在容器化環境中。事故回應團隊應熟悉收集資料所需的不同工具和技術，並記錄專門針對這些環境的流程。

5.廢棄階段

根據應用程式的需求自動部署和銷毀容器的能力可以實現高效的系統，但也可能會給記錄保留、鑑識和事件資料要求帶來一些挑戰。企業應確保採取適當的機制來滿足其資料保留政策。應解決的問題範例包括如何銷毀容器和Image、在廢棄之前應從容器中提取哪些資料以及應如何執行資料提取、應如何銷毀或刪除容器使用的加密密鑰等。支援容器化環境的資料存儲和介質應包含在企業製定的任何廢棄計劃中。

結論

容器代表了應用程序建立和運作方式的變革。它們不需要全新的安全最佳實踐；相反，容器安全最重要的方面是完善成熟的技術和原則。 NIST SP 800–190做的是更新並擴展了一般安全建議，以考量到容器技術特有的風險。
NIST SP 800–190討論的是保護容器和保護虛擬機中相同應用程序之間的一些差異。

在容器環境中，有更多的實體，因此安全流程和工具必須能夠相應地擴展。規模(Scale)不僅僅意味著資料庫中支援的Object總數，還意味著管理政策的有效和自主程度(autonomously)。許多企業都在承受管理數百個到上千個VM的安全性。隨著以容器為中心的架構成為常態，並且這些企業負責數千或數萬個容器，他們的安全實踐應該強調自動化和效率以跟上容器運作的規模與變動性。

使用容器時，變動率比VM高得多，從每年更新幾次應用程式變為每週甚至每天更新幾次。過去可以接受的手動操作現在已經無法接受了。 自動化不僅對於處理實體的淨數量很重要，而且對於處理這些實體的變動率也很重要。 能夠集中呈現政策並讓軟體在整個環境中管理策略的強制化至關重要。採用容器的企業應該準備好管理這種變動率。 這需要全新的維運實踐和組織變革(R&R需要修改)。

容器的使用將大部分資安責任轉移給了開發人員，因此企業應確保其開發人員擁有做出明智決策所需的所有資訊、技能和工具。此外，資安團隊應該能夠在整個開發週期中積極加強品質。成功實現這一轉變的企業能夠比以往更快地回應漏洞並減少維運負擔，從而獲得安全優勢。

安全性必須像容器本身一樣具可移植性，因此企業應該採用開放的、跨平台和跨環境工作的技術和工具。許多企業都會看到開發人員在一種環境中進行構建，在另一種環境中進行測試，然後在第三種環境中進行部署，因此在這些環境中評估和執行的一致性至關重要。 可移植性不僅與環境有關，而且與時間有關。 CI/CD的實踐侵蝕了開發和部署週期各階段之間的傳統壁壘，因此企業需要確保在建立Image、在Registry中存儲Image以及在容器中運行Image時保持一致、自動化的安全實踐。

應對這些變化的企業可以開始利用容器來實際提高其整體安全性。 容器的不變性和宣告式特性使企業能夠開始實現更加自動化、以應用程式為中心的安全性的願景，這種安全性需要最少的手動參與，並且隨著應用程序的變化而自我更新。容器是一種使企業能夠從被動、手動、高成本的安全模型轉變為能夠實現更好的規模和效率的模型，從而降低風險的能力。