安全專業人士在工作中可能會有一種虛假的安全感。如果想要維護企業安全，舊有安全方法和技術中有幾處地方需要改進。

向云端遷移。安全左移。購買最新的XDR和欺騙工具。技術和網絡安全行業總是容易受到市場炒作的影響，但這些舉動真的讓企業更安全了嗎?或者說，這些動作不過是增加了復雜性?

從SolarWinds后門到微軟Exchange漏洞，重大黑客事件層出不窮，安全專業人員怎么才能睡個好覺?他們總覺得自己在做正確的事，但這難道真的難道不是一種虛假的安全感嗎?

Salt Security技術布道者Michael Isbitski表示，安全專業人員應該多加關注應用編程接口(API)安全，因為API支撐著上述很多技術策略。從托管內部云應用到依賴網關和傳統補丁管理工具，舊有安全方法對API安全并未投入足夠的重視，而API很容易遭到攻擊者染指。

Isbitski稱：“風險實在太大，企業應該老實承認自己在這些安全方法和工具選擇上過于自信了。面對現代威脅，企業真的應該尋找相應的工具和過程更新方法。”

下面謹列出七條建議，幫助安全專業人員梳理部署安全概念和技術的過程中應該考慮的問題。

[[397574]]

▶ 你構建的云應用真的安全嗎?

隨著邁向云端的步伐，企業在為云重新設計的安全工具上投入了大量資金，投資重點通常是云工作負載保護和容器安全工具。此類工具有助于識別已知脆弱依賴，檢測錯誤配置，微分隔工作負載，以及防止偏離已確立的安全基線。但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

盡管補丁和漏洞管理程序能夠幫助安全團隊應對現成軟件和組件的安全風險，但應用和API安全策略需要的不止這些。

可惜，因為急于避免淪為99%的已知漏洞的受害者，企業將大量精力放在了補丁和漏洞管理上。已發布軟件或硬件中定義明確的漏洞往往通過通用漏洞與暴露(CVE)分類法來跟蹤記錄。然而，這一分類法根本無法捕獲企業在構建或集成應用與API時可能引入的各種潛在漏洞與弱點。

攻擊者有時會以軟件中眾所周知的漏洞為目標，例如最近的Exchange服務器黑客攻擊事件。不過，更為普遍的情況是，攻擊者尋找目標企業特有的API或API集成中的漏洞。企業創建或集成的代碼可沒有“補丁”供安全工程師用來縫合應用與API。

通用缺陷列表(CWE)ID是更適合描述自主開發的應用與API中缺陷的分類法。如果企業自行開發代碼或集成其他代碼，那么安全人員應該很熟悉CWE和OWASP Top 10。這些都是更為相關的分類法，更適合自行構建應用或API而不是從使用CVE ID的其他地方采購的情況。

cwe.mitre.org表示，CWE可幫助開發人員和安全從業者做到以下事項：

• 以通用語言描述和討論軟件及硬件缺陷。
• 檢查現有軟件及硬件產品中的缺陷。
• 評估針對這些缺陷的工具的覆蓋率。
• 利用通用基準執行缺陷識別、緩解和預防。
• 在部署前防止軟件及硬件漏洞。

▶ 基本安全意識培訓遠遠不夠，尤其是針對工程師的培訓

安全意識培訓的重點往往圍繞勒索軟件攻擊、網絡釣魚和社會工程攻擊，因為這些技術是攻擊者常會利用的。

企業往往過于自信此類意識培訓能夠實際改變員工行為的程度了。太多企業采用的是照單劃勾的方法，往往每年通過第三方搞個一兩次培訓，確保員工都參加了這個培訓，然后就將之拋諸腦后，直到下一次培訓期到了再走一次過場。

這顯然遠遠不夠，老實說，完全是在浪費時間。專注即時安全培訓會好上很多，能夠改變員工的行為，讓他們以更具安全思維的方式工作。

很多企業的應用安全培訓和意識仍落后于時代。隨著應用發布節奏加快，開發人員和工程師往往根本沒有時間參加培訓。即使擠出時間學習，這些人也只會專注自己的技術棧，安全在很大程度上淪為了一項事后考慮。

大多數企業仍然缺乏安全專業知識，尤其是在“全棧”工程這方面。這就造成非安全人員在創建或更新應用時幾乎沒有安全指南。敏捷方法論和開發運維實踐導致的開發和發布時間線壓縮，也沒給安全設計審查或威脅建模演練等安全培訓和意識本可以產生成效的方面留下多少時間。

缺乏時間一直是一項安全挑戰，但開發生命周期中的安全左移不可避免;安全不能一直是事后考慮，從組織的角度考慮，為什么不前期構建安全呢?

事前預防可比安全事件或數據泄露發生后再補救省錢多了。但這確實需要給開發人員留出時間來培訓和學習，也需要開發人員愿意這么做。意識培訓不是一朝一夕之功。

▶ 僅僅購買新工具并不能保護企業安全

企業往往會覺得只要購買了最新、最熱門的安全工具就能保障安全了，但事實并非如此。

優秀人才的招募和保留頗不容易，所以企業購買的新工具相當程度上管理得并不恰當，管理員經常錯誤配置了這些工具。安全團隊需要捫心自問：我們真的用的是最新版本嗎?我們確實充分利用了新產品的所有功能?某些規則是不是在更新過程中被重寫了?

很多人都覺得靠買買買就能解決安全問題。但很不幸，多數情況下，最初安裝產品的人早已離職。這就是為什么有時候可能會有1000條規則放在那兒，現任管理員碰都不敢碰。他們害怕一旦動了會不會搞掉一些非常重要的東西。改一行代碼就導致整個系統崩潰這種事，大家就算沒經歷過也聽說過很多了。

企業還需要員工具備軟技能：遵循規程、閱讀文檔、向管理層報告/溝通問題。

另外，很多人都會認為所有這些新產品肯定是完全集成的。這也是擴展檢測與響應(XDR)興起的原因之一，因為XDR基本上就是包含了端點、網絡和云威脅檢測與響應的預集成解決方案。

但不管怎么說，安全問題總歸是個難題。所以，托管安全服務仍在發展，甚至頂級供應商都還在不斷推出托管服務。他們認識到，無論自己的產品平臺多么集成和有效，還是有越來越多的CISO想要盡可能多地外包技術的管理。而且這種趨勢可能會隨時間穩步發展。

▶ 推出物聯網產品的企業未必關注安全

企業的關注點可能落在制造汽車、電子消費品或家用電器上，未必總能意識到自己理應多投入點時間和金錢在這些產品及其集成移動應用的代碼開發與管理方面。

計算發展演進到今天就是這樣。不從事軟件開發業務的公司如今也在開發應用和API來驅動自身核心業務了。但企業并非總能認識到自己應該保護好支撐著這么多物聯網設備的API和應用。

圍繞物聯網的漏洞真的太多了。隨著5G在美國和很多發達國家的鋪開，各種類型物聯網設備的泛在連接將不僅僅是可能，而是會成為標準操作。而許多此類設備不僅沒有內置安全功能，還從開發伊始就沒考慮過安全。

因此，如果缺乏良好的5G物聯網防護，物聯網僵尸網絡可能會卷土重來，尤其是在對很多黑客而言僵尸網絡驅動的加密貨幣挖礦越來越有利可圖的情況下。未來十年，物聯網可能是網絡安全敘事的重點之一。