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

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

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

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

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

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

[[397574]]

▶ 你構(gòu)建的云應(yīng)用真的安全嗎?

隨著邁向云端的步伐，企業(yè)在為云重新設(shè)計的安全工具上投入了大量資金，投資重點通常是云工作負載保護和容器安全工具。此類工具有助于識別已知脆弱依賴，檢測錯誤配置，微分隔工作負載，以及防止偏離已確立的安全基線。但Kubernetes等平臺中未修復(fù)的漏洞和錯誤配置一直以來都是攻擊者的入口點，可供他們繞過訪問控制，在被黑集群上執(zhí)行惡意代碼，以及部署加密貨幣挖礦機。

Isbitski說道：“很不幸，此類新型云安全工具仍然無法解決很多應(yīng)用層安全問題。這些工具主要解決的是網(wǎng)絡(luò)安全和基礎(chǔ)設(shè)施安全，卻將應(yīng)用安全繼續(xù)置于脆弱境地。所以，公有云可能是安全的，但這并不意味著你內(nèi)部構(gòu)建的應(yīng)用是安全的。”

▶ 安全可以左移，但也必須右移

左移概念鼓勵開發(fā)團隊將安全過程和工具盡早納入軟件開發(fā)生命周期(SDLC)，并傳播安全專業(yè)技術(shù)知識。左移與DevSecOps實踐緊密相關(guān)，而后者的目標是在設(shè)計、構(gòu)建和部署階段集成和自動化安全。DevSecOps實踐為很多企業(yè)帶來了豐厚回報，因為采用此實踐的企業(yè)能夠更快速地迭代安全，驗證是否從一開始就恰當構(gòu)建了安全，還能減少SDLC后期修復(fù)漏的開支。

然而，企業(yè)無法以運行時安全為代價整體左移。開發(fā)人員不可能編寫出完美代碼，也無法在發(fā)布窗口期內(nèi)充分細致地掃描代碼，而且掃描器從設(shè)計上就是用來發(fā)現(xiàn)遵循明確模式的已知漏洞或弱點的。

安全左移從來就不是只意味著“左移”。但是，有利的一面是，左移確實讓開發(fā)團隊能夠更快找到并修復(fù)大量安全漏洞。

新型攻擊和零日漏洞總會出現(xiàn)，生產(chǎn)中的應(yīng)用也需要保護。很多公司應(yīng)該不會左移到將運行時安全排除在外。大多數(shù)人已經(jīng)意識到首尾兩端均需兼顧了。

▶ WAF和網(wǎng)關(guān)無法全面保護API

API是當今現(xiàn)代應(yīng)用的基礎(chǔ)，但只有少數(shù)企業(yè)真正認識到API的重要性或其呈現(xiàn)的風險水平。API對攻擊者的吸引力太大了，以致于承擔了與自身體量很不相稱的風險，但太多企業(yè)假定Web應(yīng)用防火墻(WAF)和API網(wǎng)關(guān)能夠充分保護自身API。實際上，這些技術(shù)由于固有的設(shè)計局限而無法阻止絕大多數(shù)類型的API攻擊，往往會給企業(yè)造成自身API和API驅(qū)動的應(yīng)用很安全的虛假感覺。

API對每個企業(yè)而言都很特殊，針對API的真實攻擊往往不遵循已知漏洞的明確模式。對抗這類安全風險需要運行時安全，運行時安全才能夠持續(xù)學習API行為并盡早阻止攻擊者，無論攻擊者所用的攻擊技術(shù)是哪種。

安全團隊需利用WAF或API網(wǎng)關(guān)之外的技術(shù)解決API安全問題。

記得2005年左右還有人爭論稱，網(wǎng)關(guān)供應(yīng)商會站出來滿足對額外安全功能的需求，至少Apigee這家供應(yīng)商確實發(fā)布了一個安全附加模塊。然而，API安全畢竟很大程度上是一組獨立供應(yīng)商的專屬領(lǐng)域，而不是API網(wǎng)關(guān)企業(yè)的專利。

企業(yè)通過API暴露出了大量應(yīng)用和海量數(shù)據(jù)。API造成的數(shù)據(jù)泄露和未授權(quán)訪問很常見。今天的API安全由大量工具組合構(gòu)成：一些擴展到API防護的運行時應(yīng)用安全工具，一些解決特定安全用例的API管理工具，可以測試API的應(yīng)用安全測試工具，以及專用于API的安全工具。

▶ 傳統(tǒng)補丁和漏洞管理工具無法保護API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

▶ 推出物聯(lián)網(wǎng)產(chǎn)品的企業(yè)未必關(guān)注安全

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

計算發(fā)展演進到今天就是這樣。不從事軟件開發(fā)業(yè)務(wù)的公司如今也在開發(fā)應(yīng)用和API來驅(qū)動自身核心業(yè)務(wù)了。但企業(yè)并非總能認識到自己應(yīng)該保護好支撐著這么多物聯(lián)網(wǎng)設(shè)備的API和應(yīng)用。

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

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