Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86393260

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

採用CNAS需要對我們保護應用程序和基礎架構的方式進行重大改變。轉變是一個旅程,每個組織都不相同,甚至同一組織的不同部分也不同。

雖然選擇正確的道路是由你的決定,但為了讓它正確,模式和最佳實踐已經開始出現。在本文中,我提出了幾個可以考慮打破現狀的領域,以及如何打破現狀。

重新思考工具除了組織架構的改變,CNAS和“開發優先”還需要重新評估你的工具包。鑑於這種新視角,你應該重新考慮在技術解決方案中尋找的最重要特徵,以及你希望如何捆綁工具。

有很多方法可以重新評估工具,但我建議關註三個主要領域:開發工具採用、平台範圍和治理方法。

開發人員工具口徑如果我們的目標是讓開發人員在日常工作中能夠構建安全性,我們需要確保為他們提供針對該目標進行優化的工具。如果你購買專為審計人員設計的解決方案並要求開發人員使用它們,那麼你不太可能取得成功。

不出所料,開發人員習慣於使用開發人員慣用的工具。這些工具代表了整個行業,圍繞著什麼是優秀的開發者工具這一主題,已經在行業內發展了自己的最佳實踐。為了幫助你選擇開發人員將採用的安全解決方案,你應該根據開發者工具最佳實踐評估這些工具,並了解它們的表現如何。

以下是優秀的開發者工具的一些常見特徵:

成功的自助服務採用實際上,所有成功的開發工具都具有出色的自助服務用法,包括輕鬆的上手培訓、直觀的工作流程和出色的文檔。這是開發人員喜歡使用工具的方式,它迫使供應商確保他們的工具與開發人員相關,而無需銷售人員推動它。除非你想成為向開發人員推廣工具的銷售人員,否則請尋找具有開發人員自助服務採用的良好記錄的工具。

無縫集成到工作流程中在大多數情況下,開發工具經常與開發人員打交道,而不是要求他們再打開另一個工具。它們優雅地集成到其IDE、Git和研發管道中,並在正確的時間點提供價值。集成不僅僅是技術鉤子;他們需要適應工作流程和最佳實踐,否則將被拒絕採用。

豐富的API和自動化友好雖然需要固執己見的集成才能開始,但開發工具也必須是瑞士軍刀。豐富的API和自動化友好的客戶端(CLI/軟件開發工具包[SDK])是強制性的,既可以將該工具調整到每個管道,又允許社區在其上進行構建。如果你不能在工具上構建,它就不是一個偉大的開發工具。

開源和社區採用開發人員希望其他開發人員來驗證工具的可信度,而開源採用是最好的指標。看到開源項目集成了安全工具或基於此構建的開源項目,這些都是很好的開發人員社區驗證。在檢查安全工具時,檢查它在開源中的採用情況並得出自己的結論。

這些只是眾多開發工具最佳實踐中的一小部分。如果你想了解更多關於開發優先安全性的特定安全建議,請繼續往下看。此外,在評估任何工具時,請確保讓實際的應用程序開發人員參與進來,以便從現實生活中了解它與周圍環境的契合程度(如下圖所示)。

ce0ff4b0-0eee-4791-b04a-0cd56b885b79.png

開發人員友好的安全工具示例

平台範圍當前主流的AST平台主要關注自定義代碼,也許還有應用使用的開源庫。工具套件主要由SAST、DAST和IAST組成,最近又添加了SCA。當你擁抱更廣泛的雲原生應用程序範圍時,請重新考慮平台的構成。

首先,讓我們考慮一下哪些工具從成為單一平台的一部分中受益。它們可以分為下面幾個部分:

共享用戶:如果不同的工具是為不同的主要用戶設計的,那麼它們幾乎不需要成為單個平台的一部分,因為它們無論如何都會單獨使用。

共享工作流:如果以類似的方式使用多個工具並集成到用戶工作流的類似點中,則可以通過組合它們來節省集成時間以及用戶的時間和精力,而無需使用多個單獨的工具。

共享優先級:如果來自不同工具的行動項應彼此優先排序,則共享積壓工作可以提高效率和結果。

價值倍增:最後,工具共享平台的最強驅動力是當工具一起使用可以增強每個工具的價值。這個標準自然解釋了為什麼像SAST和SCA這樣的技術非常適合單一平台。兩者都為相同的開發人員用戶提供服務,運行掃描並在相同的位置吸引用戶,並共享同一開發人員需要優先考慮的安全漏洞的積壓。在高級SCA解決方案中,SAST技術可以指示你的自定義代碼是否調用庫中易受攻擊的代碼,從而提供更高的準確性,從而增加價值。

當你考慮將容器和IaC安全性添加到SAST和SCA的同一平台時,相同的邏輯也適用:共享用戶:容器和IaC現在由開發人員保護,就像SAST和SCA一樣,他們寧願沒有多個不同的產品需要花時間學習和參與。

共享工作流:保護容器和IaC需要跨生命週期的集成,例如IDE、Git和構建集成,就像SAST和SCA一樣。

共享優先級:同一個開發人員需要花費周期來修復容器或IaC漏洞,或者代碼或庫中的漏洞——所有這些都是保護應用的積壓工作。

價值倍增:保護這些組件有多種方式。掃描容器需要探索內部的應用程序,了解基礎設施配置有助於確定代碼和庫的漏洞優先級,了解跨組件的流程有助於緩解問題;這正是你在對漏洞進行分類時所做的。

即使CNAS範圍擴大,這種邏輯仍然有效,我鼓勵你將CNAS工具視為一個平台。一個簡單的準則是,Git存儲庫中的任何內容都可能與其周圍的文件相關,並遵循相同的開發工作流。因此,CNAS平台應有助於保護存儲庫中的所有內容(整個雲原生應用)。

DAST和IAST在這樣一個平台上是有點尷尬的參與者。儘管它們處理保護應用程序,但它們通常需要不同的工作流程。由於運行它們所花費的時間,很難將它們放入構建管道或IDE掃描中。在我看來,這是一個技術問題,而不是一個合乎邏輯的問題,一旦IAST和DAST解決方案發展到對管道更加友好,它有望得到解決。

治理和賦權方法採用開發優先的安全方法需要不同類型的協作。我們需要的工具不是專注於廣播和執行自上而下的任務,而是幫助我們協作構建安全應用程序的工具。

這聽起來可能很明顯,但在實踐中,這與許多安全工具的工作方式有很大的不同。讓我們深入研究一些具體的例子,以了解這意味著什麼。

首先,開發人員需要有能力平衡業務需求與安全風險。這意味著,例如,允許他們決定不修復發現的漏洞並繼續將其部署到生產環境。對某些人來說,這是一個可怕的命題,但這是實現獨立團隊的唯一方法。請注意,忽略漏洞仍應要求提供(且可審核)原因,並且某些約束應為硬槓槓(通常出於合規性原因),但作為默認立場,決策應留給開發人員。

其次,開發人員需要能夠管理他們的安全風險,這需要看到他們項目中的所有漏洞。這不僅需要包括漏洞列表,還需要包括確定優先級所需的所有信息,例如可利用性和資產映射。對此類信息保持透明可能會帶來一些風險,但這是擴展安全性的唯一方法;要賦予開發人員權力,你必須信任他們提供這些敏感數據。

第三,安全團隊應該投資於跟踪和推動安全控制的採用,甚至超過他們的產出。開發團隊應該管理其漏洞積壓工作,但安全團隊需要幫助他們成功做到這一點。開發優先安全治理意味著跟踪採用了哪些控件及其輸出的處理情況,並與開發團隊合作改進這些統計信息,而不是突出顯示他們應該修復的漏洞。

這些只是評估治理工具和技術時要考慮的幾個示例。關鍵是要擁抱平台心態;它的目標是幫助開發團隊成功構建安全軟件,而不是跟踪安全漏洞本身。

重新思考優先事項最後但並非最不重要的一點是,CNAS需要重新考慮應用程序安全優先級。如果開發人員需要保護整個雲原生應用程序,你希望他們最關注哪些方面?

從歷史上看,IT安全控制主導了更大的預算,並且比應用程序安全控制獲得了更多CISO的關注。這種不平衡可能有歷史原因,但歸根結底,它代表了CISO關於如何最好地使用他們的資金來降低組織風險的觀點。

換句話說,CISO認為,由於未修補的服務器或配置錯誤的基礎架構而導致的違規風險大於代碼中的自定義漏洞的風險。這種看法有相當多的數據來支持它,顯示了歷史違規行為及其原因。此外,它很容易理解;對於攻擊者來說,大規模運行已知的漏洞並尋找一扇敞開的門要比對應用程序進行逆向工程並找到自定義缺陷以使其通過要容易得多。

云不會減少這個等式;事實上,雲加強了這個等式。採用雲意味著使用更多的基礎設施和更多的服務器,它們往往更容易公開訪問,並且它們由不太熟悉管理它們的團隊(開發人員)定義,並配備了不太成熟的工具。

然而,雖然以前的平衡是在IT安全預算和應用程序安全預算之間,但現在一切都在應用程序安全世界中。在構建雲原生應用程序時,相同的開發人員需要保護其自定義代碼,管理其開源使用中的漏洞,並使服務器和基礎架構具有彈性。同一個應用程序安全團隊需要幫助他們做到這一點,並在他們之間分配相同的預算。

因此,我們回到開場白:你希望如何分配寶貴的開發人員的時間和有限的CNAS預算?

丟掉開發人員自己的設備和應用程序安全預算並讓開發人員的注意力集中在保護自定義代碼上。應用程序安全成熟度模型、行業最佳實踐以及團隊中個人的個人體驗都錨定在雲前的世界中,其中自定義代碼是開發人員必須保護的大部分內容。購買SAST和DAST等工具通常是應用程序安全新領導者名單上的第一件事,很少受到挑戰。

但是,考慮到CNAS的範圍,這仍然是你時間和金錢的最佳利用嗎?由於已知漏洞或配置錯誤而導致的違規風險仍然高於自定義代碼缺陷的風險,即使開發人員是配置它的人。如果你同意,難道不應該告訴你的開發人員和應用程序安全團隊首先要專注於保護這些層,然後才能處理他們的自定義代碼嗎?

這不是一個容易回答的問題。我不會假設知道你的優先事項應該是什麼,因為這些優先事項會因組織而異。但是,鑑於CNAS的範圍更廣,我強烈建議你在內部進行此對話並重新考慮你的優先事項。

結論改變你處理應用程序安全性的方式不僅僅是一種思考練習。它具有非常真實的下游影響,包括人們的職業生涯,預算分配以及對保持組織安全的最佳方式的重新評估。它需要擺脫一些關於你過去如何做事的肌肉記憶,而不是在選擇解決方案時回到第一原則,這需要寶貴的時間和精力。

好消息是,你不必一次完成所有操作。我在本文中概述的變化相互關聯,但可以按照自己的節奏應用。我建議你選擇與你最相關的那些內容,或者選擇你認為更重要的其他變化,並讓這些變化繼續下去。你將逐步調整安全功能以適應云原生現實。