應該首先保護哪些應用程序

■鐵生

應該首先保護哪些應用程序

■鐵生

大多數企業IT環境中可能有數百個、乃至數千個應用程序。它們極有可能是在過去10年或20年編寫、更新和打上補丁的。你可能對那些應用程序并沒有做好足夠到位的安全工作，在人們不知不覺當中，安全這筆債很快會堆積如山。

不妨看一看應對這個挑戰的若干糟糕戰術：

第一個糟糕戰術：只保護面向外部的應用程序。

這是最常見的戰術之一。由于資源有限，企業的團隊專注于面向外部的應用程序，這絕對是采用的最糟糕戰術之一。某個應用程序是否暴露在互聯網面前，這僅僅是決定應用程序“內在風險”的諸多因素當中的一個。如果這是你唯一要考慮的因素，那么大量的時間和精力就會耗費在對貴企業來說風險不是那么高的應用程序進行深層安全審查的工作上。相反，應該考慮數據的敏感性、業務職能有多關鍵、用戶群體及攻擊者群體的數量和技能以及其他風險因素。

第二個糟糕戰術：每次只面對一種應用程序。

大多數方法試圖每次只面向一種應用程序來處理應用程序的安全。當你對應用程序執行深層安全分析時，許多時間浪費在了很小的安全漏洞上，而這些安全漏洞不太可能讓企業倒閉破產。每年，有更多的應用程序和更多的攻擊途徑需要考慮。所以，每年，安全團隊要做的工作越來越多。每次面向一種應用程序這個做法根本不具有可擴展性。相反，應專注于如何杜絕你所有應用程序面臨的最重大漏洞。

第三個糟糕戰術：進行年度安全測試。

許多企業采用了“每年一次”或“每三年一次”的應用程序安全測試計劃表。這種方法需要為新的應用程序、舊的應用程序、云應用程序和產品等制定一套復雜的計劃調度流程。如今新的安全漏洞和攻擊手法層出不窮，因而這種方法面臨極高的風險。新的代碼庫漏洞可能會讓應用程序完全暴露無遺，直到下一次審查才有所發現。新的安全漏洞往往迅速添加到黑客工具中，并成為廣泛的掃描活動的一部分。另外，現代化軟件開發流程每周或每天在發布代碼，而不是每年發布。安全必須加快跟上來。

第四個糟糕戰術：只保護關鍵應用程序。

另一種可能性是僅僅專注于關鍵業務型應用程序ˉˉ要是這些應用程序完蛋，業務就會隨之癱瘓?？紤]可能給業務造成的實際破壞是明智之舉，但是這通常僅僅牽涉一小批應用程序。在許多企業，應用程序安全團隊不堪重負、人手不足，他們的掃描方法并不具有可擴展性，處理不了任何更多的應用程序。遺憾的是，許多現實世界中的泄密事件是從不太重要的應用程序中招開始的(比如索尼事件)，隨后向更重要的系統擴散和蔓延。即使“小冊子軟件”網站遭到攻擊，那也將是需要收拾的爛攤子和公關災難。

所有上述戰術沒有一個支持迅速確保應用程序安全這個更廣泛的戰略，而且與現代軟件開發不兼容。我們需要這樣一種方法：可以適用于我們的全部應用程序組合，跟得上現代軟件開發的步伐，而且首先關注最大的風險。好消息是，我們可以充分利用持續集成和持續交付等諸多理念和技術，打造一種不同的應用程序安全流程，快速、準確、簡單。

正確的問題：你的應用程序有安全儀表化機制嗎?

儀表化讓你可以直接從應用程序收集安全信息，無需掃描、破解或任何其他額外的步驟。如果你的應用程序實現了儀表化，它們可以測試自己，不斷報告其狀態。這徹底改變了應用程序安全的規模問題。你沒必要去掃描所有應用程序，它們會測試自己，不斷地報告給你。

下面是證明儀表化魅力的一個例子。比方說，你關注的最重要的安全問題是SQL注入;你已規定，開發人員只可使用參數化查詢。很容易用數據庫接口中的一些安全儀表化機制來證實這一點。比如說，你可以對MySQL庫實現儀表化，報告非參數化查詢的使用。只要把類路徑(classpath)上的StatementImpl的這個版本放在實際版本前面。

雖然這是個很不起眼的例子，但頗有說服力。把這個儀表化版本推送到你的MySQL庫中心，很快你就有了一個完整的圖，可顯示貴企業中的所有非參數化查詢。設想一下：你可以用應用程序組合的安全儀表化來實現什么。

這就是區別。儀表化應用程序會證實自己的安全，并將問題報告給你。最簡單的好處是完整的應用程序清單。你還可以證實第三方庫是最新的，不存在已知的安全漏洞。儀表化還可以確保配置文件得到了適當的保護。更復雜的儀表化可以查明復雜的安全漏洞，以及你想對企業代碼庫了解的幾乎任何方面。它還持續適用于企業規模。

試圖查明先保護哪些應用程序只會浪費資源。相反，應該花時間打造你的安全儀表化能力。下一個Heartbleed或Shellshock出來后，你沒必要掃描任何東西。你只要進入到儀表板，搜尋受影響的版本，發送警報給受影響應用程序的項目負責人。你還能看到他們具體何時全部升級。