你打造的雲端應用真的安全嗎？
隨著邁向雲端的步伐，企業在為雲重新設計的安全工具上投入資金，投資重點通常是雲工作負載保護和容器安全工具。此類工具有助於識別已知的脆弱性，檢測錯誤配置，微分開的工作負載，以及防止更改已初始化的安全措施。但Kubernetes等平台中未修復的漏洞和錯誤配置一直以來都是攻擊者的入口點，發現他們繞過訪問控制，在被黑的上執行惡意代碼，以及部署加密貨幣挖礦機。
Isbitski文章：“非常不幸，此類新型雲安全工具仍無法解決很多應用層安全問題。這些工具主要解決的是網絡安全和基礎設施安全，卻將應用安全繼續放置脆弱境地。所以，公有云可能是安全的，但這並不意味著您內部整合的應用是安全的。”
安全可以左移，但也必須右移
左移概念鼓勵開發團隊將安全過程和工具儘早替換為軟件開發生命週期（SDLC），並傳播安全專業技術知識。
左移與DevSecOps實踐緊密相關，而另外的目標是在設計，部署和部署階段集成和自動化安全。
DevSecOps實踐為很多企業帶來了豐厚收益，因為採用此實踐的企業能夠更快速地進行迭代安全，驗證是否從一開始就恰好改善了安全性，還能減少SDLC隨後修復漏的擴展。
然而，企業無法以運行時安全為代價整體左移。開發人員不可能編寫出完美的程式碼，也無法在發布窗口中進行充分細緻的地掃描程式碼，而且掃描器從設計上就是發現發現直接模式的已知突破或弱點的。安全左移從來就不是只意味著“左移”。但是，有利的一面是，左移確實讓開發團隊能夠重新找到並修復大量安全漏洞。新型攻擊和零日進攻總會出現，生產中的應用也需要保護。很多公司應該不會左移到將運行時安全排除在外。大多數人已經有權首尾兩端均需兼顧了。
WAF和網關無法全面保護API
API是當今現代應用的基礎，但只有少數企業真正認識到API的本身呈現出來的風險水平。API對攻擊者的吸引力太大了，以致於承擔了與自身體量很不相稱的風險，但過多的企業估計Web應用防火牆（WAF）和API網關能夠充分保護自身API。實際上，這些技術由於固有的設計局限而無法阻止插入類型的API攻擊，經常會給企業造成自身API和API驅動的應用很安全的虛假感覺。
API對每個企業而言都很特殊，針對API的真實攻擊經常不遵守已知突破的明確模式。對抗此類安全風險需要運行時安全，運行時安全才能夠持續學習API行為並儘早阻止攻擊者，無論攻擊者所用的攻擊技術是哪種。
安全團隊需利用WAF或API網關之外的技術解決API安全問題。
記得2005年左右還有人漸變稱，網關供應商會站出來滿足對額外的安全功能的需求，至少Apigee這家供應商確實發布了一個安全附加模塊。然而，API安全畢竟本身是一個獨立供應商的專屬領域，而不是API網關企業的專利。
企業通過API暴露出預防應用和海量數據。API造成的數據過多和未授權訪問很常見。今天的API安全由大量工具組合構成：一些擴展到API防護的運行時應用安全工具，一些解決特定安全用例的API管理工具，可以測試API的應用安全測試工具，以及專用於API的安全工具。
傳統補丁和防禦管理工具無法保護API
因為急於避免淪為為99％的已知擴張的受害者，企業將大量浪費放在了補丁和突破管理上。已發佈軟件或硬件中定義明確的擴展經常通過通用漏洞與暴露（CVE）分類法來跟踪記錄。然而，這一分類法根本無法捕獲企業在整合或集成應用與API時可能發布的各種潛在突破與弱點。
攻擊者有時會以軟件中潛在的突破為目標，例如最近的Exchange服務器黑客攻擊事件。不過，更為普遍的情況是，攻擊者尋找目標企業特有的API或API集成中的漏洞。企業創建或集成的代碼可沒有“補丁”供安全工程師使用替換應用與API。
通用缺陷列表（CWE）ID是更適合描述自主開發的應用與API中缺陷的分類法。如果企業自行開發代碼或集成其他代碼，那麼安全人員應該很熟悉CWE和OWASP排名前10位。這些都是常規相關的分類法，更適合自行構建應用或API而不是從使用CVE ID的其他地方採購的情況。
cwe.mitre.org表示，CWE可幫助開發人員和安全從業者做到以下事項：
。以通用語言描述和討論軟體及硬體缺陷。
。檢查現有軟體及硬體產品中的缺陷。
。評估針對這些缺陷的工具的覆蓋率。
。利用通用基準執行缺陷識別，緩解和預防。
。在部署前防止軟體及硬體突破。
基本安全意識培訓遠遠不夠，尤其是針對工程師的培訓
安全意識培訓的重點經常圍繞勒索軟體攻擊，網絡釣魚和社會工程攻擊，因為這些技術是攻擊者常會利用的。
企業經常過於自信此類意識培訓能夠實際改變員工行為的程度了。太多企業採用的是照單劃勾的方法，經常每年通過第三方從事一個一對雙重培訓，確保員工都參加了這個培訓，然後就將之拋棄諸腦後，直到下一次培訓期到了再走一次過場。
大多數企業仍然缺乏安全專業知識，尤其是在“全站”工程這方面。這就造成非安全人員在創建或更新應用時幾乎沒有安全指南。敏捷方法論和開發運維實踐導致的開發和發佈時間線壓縮，也沒給安全設計審查或威脅建模演練等安全培訓和意識本可以產生的方面留下多少時間。
事前預防可比安全事件或數據合併發生後再恢復省錢多了。但這確實需要給開發人員留出時間來培訓和學習，也需要開發人員願意這麼做。意識培訓不是一朝一夕之功。
僅購買新工具並不能保護企業安全
很多人都覺得靠買買買可以解決安全問題。但很不幸，多數情況下，最初安裝產品的人早已離職。這就是為什麼有時候可能會有1000條規則放在那兒，現任管理員碰都不敢碰。他們害怕一旦動了會不會搞掉一些非常重要的東西。改一行代碼就導致整個系統崩潰這種事，大家就算沒經歷過也聽說過很多了。
企業還需要員工具備軟技能：遵守規程，閱讀文檔，向領導報告/溝通問題。
另外，很多人都會認為所有這些新產品肯定是完全集成的。這也是擴展檢測與響應（XDR）興起的原因之一，因為XDR基本上就是包含端點，網絡和雲威脅檢測與響應的預集成解決方案。
但不管怎麼說，安全問題總歸是個難題。所以，託管安全服務仍在發展，甚至頂級供應商都還在不斷推出託管服務。他們認識到，無論自己的產品平台如何集成和有效，還是有越來越多的CISO想要替代多地擴展技術的管理。而且這種趨勢可能會隨時間穩步發展。
推出物聯網產品的企業未必關注安全
計算發展趨勢到今天就是這樣。不從事軟件開發業務的公司，現在也在開發應用和API來驅動自身核心業務了。但企業並非總能認識到自己應該保護好支撐著這麼多物聯網設備的API和應用。
圍繞物聯網的突破真的太多了。隨著5G在美國和很多潛在的鋪開，各種類型物聯網設備的泛在連接將兩次可能，甚至會成為標準操作。而許多這類設備既沒有內置安全功能，又從開發伊始就沒考慮過安全。
因此，如果缺乏良好的5G物聯網防護，物聯網殭屍網絡可能會捲土重來，尤其是在對很多黑客相對殭屍網絡驅動的加密貨幣挖礦越來越有利可圖的情況下。未來十年，物聯網可能是網絡安全敘事的重點之一。
聲明：此處來自數世諮詢，版權歸作者所有。文章僅代表作者獨立觀點，不代表安全內參立場，轉載目的在於傳遞更多信息。如有可能，請聯繫webmaster@dwitco.com