freeBuf
主站

分類

漏洞 工具 極客 Web安全 系統安全 網絡安全 無線安全 設備/客戶端安全 數據安全 安全管理 企業安全 工控安全

特色

頭條 人物志 活動 視頻 觀點 招聘 報告 資訊 區塊鏈安全 標準與合規 容器安全 公開課

官方公眾號企業安全新浪微博

FreeBuf.COM網絡安全行業門戶,每日發布專業的安全資訊、技術剖析。

FreeBuf+小程序

FreeBuf+小程序

下一代網絡靶場:將事件響應演習帶入云端
2021-03-25 22:01:26

HW期間,為防范釣魚,即日起FreeBuf將取消投稿文章的一切外部鏈接。給您帶來的不便,敬請諒解~

IBM X-Force始終秉承“以事件響應為中心”,使客戶始終處于網絡安全體驗的最前沿,其中包括在云原生環境中進行響應。

那么,什么是“云原生”(Cloud?Native)?云原生這個概念最早于2013由Pivotal公司的Matt Stine首次提出。2015年,云原生剛推廣時,Matt Stine在《遷移到云原生架構》一書中定義了符合云原生架構的幾個特征:12因素、微服務、自敏捷架構、基于API協作、扛脆弱性;到了2017年,Matt Stine在接受采訪時又改了口風,將云原生架構歸納為模塊化、可觀察、可部署、可測試、可替換、可處理6特質;而Pivotal最新官網對云原生概括為4個要點:DevOps+持續交付+微服務+容器。

之后在2015年夏天,Linux基金會創建了云原生基金會CNCF。CNCF在宣布成立時也沒有一個關于云原生的具體定義。只是提到了一些相關的技術,包括開源,容器,微服務,編排工具。

可以說,時至今日,關于云原生并沒有一個明確的定義,每個人都有自己不同的注解。在IBM,其將云原生應用程序和基礎架構定義為“由離散的、可重用的組件(稱為微服務)組成,旨在集成到任何云環境中。這些微服務充當構建塊,通常打包在容器中。微服務作為一個整體協同工作以組成一個應用程序,但是,每個組件又都可以通過自動化和編排流程進行獨立縮放,不斷改進和快速迭代?!?/p>

隨著云原生已經成為許多組織IT基礎架構規劃的關鍵部分,我們認識到所有相關功能都需要擴展到云原生中,這包括事件檢測及響應過程,因為這些事件極可能影響這些環境。

從物理到虛擬再到云原生

網絡靶場的概念誕生于物理時代。如果企業部署了服務器,那么安全或IT管理員將控制物理機箱和機架,包括網絡接口卡、硬盤驅動器以及所有其他組件。如果企業運營軟件,其將控制其安裝的代碼。在虛擬和云原生環境中,管理員和安全人員幾乎無法控制物理硬件,甚至無法控制在云原生應用程序下運行的原始控制面。這就意味著網絡安全方法必須考慮架構、監視和控制方面的關鍵差異。

從許多意義上講,虛擬化可能會帶來一些復雜性。當組織以混合模式工作時,尤為如此。在這種模式中,組織的一些資產仍在公司內部,但他們也具有基于云的工作負載以及跨多個不同供應商的數據。

隨著疫情的持續以及整個員工隊伍向遠程辦公遷移,對云端事件響應功能的需求顯然已經變得越來越迫切。我們看到越來越多的攻擊者將目標鎖定在云原生環境中的薄弱環節,利用流行的平臺和應用程序,并在Linux和云環境中運行惡意軟件,這些惡意軟件通常以Go編程語言編寫,以在混合基礎架構中運行。

例如,眾所周知,Amazon Web Services(AWS)的S3存儲系統對于正確地進行安全保護就是一個挑戰。它也是云中最流行的對象存儲設備,并且公司將繼續把敏感數據放入S3存儲桶中。結果無疑是面臨更大的風險,要么是無意中將存儲桶暴露在公開的互聯網上,要么像CapitalOne在2019年夏天那樣遭受極具破壞性的攻擊。在CapitalOne攻擊事件中,一位前AWS員工利用配置錯誤的Web應用程序防火墻(WAF)暴露了超過1.06億人的信用卡應用程序。

云原生安全性演習有何不同?

在舊時代中,當檢測到問題時,安全團隊可以選擇將受影響的服務器與網絡隔離,刪除連接,但保留物理機以進行進一步檢查和分析。但是,在云原生時代,這些都是不可行的,因為根本不存在需要保留的物理設備。雖然可以從企業網絡中刪除虛擬實例,但是安全團隊并不具備快速簡便的方法可以從云提供商的網絡中刪除物理服務器。事實上,這些做還會破壞許多其他客戶的應用程序。

云原生應用程序和體系結構要求以不同的方式來考慮和應對安全威脅。例如,當容器或虛擬機受到威脅時,安全響應團隊必須立即凍結并隔離該計算實例,以進行適當的取證,這一點至關重要。這與最初關閉云服務器的沖動想法背道而馳,這種沖動可能會阻止其違規行為,但也會消除進行正確的分析所需的取證追蹤。

當DevSecOps團隊致力于跨多個云保護其應用程序和基礎架構時,這些差異將成倍增加。云之間的安全標準和功能差異很大。例如,像S3等存儲服務的默認配置可能具有不同的安全級別。兩種云日志文件服務AWS Cloud Trails和Microsoft Azure Sentinel中用于收集和分析云日志文件的標準也有所不同。在AWS和Azure上運行的基礎級應用程序編程接口(API)也存在根本差異,這要求與這些API進行通信的開發人員在命令腳本和DevOps工具中使用不同的語言標準以進行持續集成(CI)和連續部署(CD) 。

為了檢測潛在的安全事件,適當的監控必須使團隊能夠看到他們所需保護的整個環境。但不幸的是,在復雜的混合基礎架構中,創建一個簡單易用的單窗格視圖才是真正的挑戰。這就是為什么我們經常在企業和政府客戶的安全咨詢工作中生成此類儀表板和連接層的原因。

除了監控障礙外,團隊可用的安全工具和控件在整個云中也可能有所不同。例如,AWS具有三種類型的負載均衡器,它們具有不同的(或沒有)Web應用程序防火墻(WAF)。在AWS和Azure上運行的托管Kubernetes服務不允許將WAF輕松地放置在群集的前面。

此外,在內部部署和云中范式之間,安全團隊如何使用諸如SafeBreach之類的連續安全控制驗證平臺也存在很大不同。在云中,大多數應用程序是使用容器技術部署的。容器能夠大規模創建不可變且短暫的基礎架構的能力使云原生成為可能。因此,在這些演習中,我們針對容器使用攻擊模擬,攻擊其網絡堆棧、安全流程以及安全團隊在構建和保護多云環境的過程中必須管理的任何其他攻擊面。

向基于容器的安全性轉變也擴大了參與者的范圍。在這種情況下,開發人員將不斷部署代碼和應用程序,并控制容器中的內容。由于發布周期快,安全審查往往是自動化的。因此,云原生網絡靶場包括來自開發團隊和DevSecOps的參與者,而對于傳統事件響應團隊而言,情況并非總是如此。

將所有資源整合在一個平臺

在向客戶咨詢他們對事件響應培訓的需求時,我們聽說他們想要一個實踐平臺,在這里,安全團隊不僅可以在混合(傳統)實施和云之間,而且可以在多個云之間進行分析、監視和編排。這正是IBM X-Force的云原生網絡靶場的推動思想。

在網絡靶場中,演習始于緊急觸發,例如新聞工作者打來的電話或FBI發出的電子郵件,以告知企業團隊的違規行為。這些演習中的漏洞來源可能是公共云中眾多攻擊點之一。除此之外,我們還確保將不受參與者控制的云部分包括在內,以教會他們如何應對這一“新現實”,以及如何與公共云安全團隊進行互動,以最大限度地發揮成功響應的機會,從而盡可能地減少影響。

借助SafeBreach,我們可以運行以容器為中心的攻擊手冊,來著眼潛在的殺傷鏈進展,然后重點凸顯哪些控件有效,哪些控件失無效。SafeBreach規定的補救措施還可作為改善參與者的云原生安全狀態的指南。采取補救措施后,我們將運行同一本手冊,以確??丶F在可以按預期運行。

我們構建云原生網絡靶場的主要目標之一是幫助安全組織和開發者團隊了解在高速部署的分布式應用程序環境中驗證安全性的最佳方式。這就要求加強他們的安全代謝,因為如果可以將其納入CI/CD管道中,而不是作為對妥協指標(IoC)的反應進行添加,那么所需的補救措施實際上能得到更好地執行。

如今,大多數團隊已經了解了這一點,但是幫助它們實現并持續存在下去,才是適應這種轉變并更改安全立場,以反應新的云原生方式現實的最佳方式。

本文作者:, 轉載請注明來自FreeBuf.COM

# 網絡靶場 # YUNUCMSv2.0.4
被以下專輯收錄,發現更多精彩內容
+ 收入我的專輯
評論 按熱度排序

登錄/注冊后在FreeBuf發布內容哦

相關推薦
  • 0 文章數
  • 0 評論數
  • 0 關注者
文章目錄
登錄 / 注冊后在FreeBuf發布內容哦
收入專輯
四月天小说网