面對大量可能不安全的應用程序、有限的評估資源和難以承受的壓力，在對企業的應用程序進行安全評估這一問題上，許多安全管理人員只能疲于應付。隨著應用程序迅速成為最受惡意攻擊者青睞的載體，攻擊者試圖利用應用程序中的漏洞破壞企業的日常業務活動，或者滲透企業的防御體系以竊取敏感數據。因此，安全管理人員應該確保對應用程序進行安全評估。
將對幾種應用程序安全評估技術進行分析，并對應用程序評估的策略范例進行比較，以進一步闡明企業應用程序安全評估流程。
專業的應用程序安全評估方法
對于不熟悉應用程序安全性的人來說，下面的三種評估方法可能會令他們暈頭轉向。不過，每種方法都有其值得稱道的地方，適用于不同的評估類型。
運行時漏洞評估（Runtime Vulnerability Assessment）——運行時漏洞評估有三種方式：自動、手動和兩者結合。一般來說，與手動評估相比，自動評估的速度更快，評估的范圍更廣。但是，自動評估往往會漏掉不明顯的漏洞，也不能發現業務邏輯缺陷。因此，大多數經驗豐富的應用程序安全專家通常傾向于采用自動和手動相結合的方式。
源代碼審查（Source-Code Review）——利用源代碼審查，評估人員可以發現應用程序中存在的各種漏洞，但該方法要求評估人員具有深厚的編程語言和安全功底，而且通常需要比運行時漏洞評估更長的時間。與運行時漏洞評估一樣，源代碼審查也有自動、手動和兩者結合三種方式。這些方式各有利弊，類似于運行時漏洞評估的三種方式。
威脅建模技術（Threat-Modeling Technique）——威脅建模技術主要是從設計的角度評估相關的、理論性的應用程序威脅。通常情況下，威脅建模先于源代碼審查和運行時漏洞評估進行。
然而，選擇適當的評估方法組合并不容易。許多企業都深受這一問題的困擾。下面我們將介紹幾種方法，以幫助企業確定適當的應用程序安全評估流程：
1、重點論法：或許，最傳統的方法是集中測試資源評估公開程度最高的應用程序，例如使用最為廣泛的面向Internet的Web應用程序。一旦確定了公開程度最高的應用程序，評估人員就可以對其執行全面的自動和手動運行時漏洞評估。然而，這種方法忽略了其他雖不顯眼但卻重要的應用程序，例如企業外部網應用程序、內部財務應用程序和關鍵的內部網站應用程序。
需要指出的是，盡管面向Internet的應用程序十分流行，但也往往容易受到外部攻擊。而且，由內部威脅和客戶端漏洞引起的風險也與日俱增。因此，忽略內部應用程序的安全性將會導致巨大的風險。此外，許多應用程序安全專家認為，單純的黑盒測試的效果不如源代碼審查與黑盒/灰盒評估相結合的方式。
2、兩點論法：通常情況下，當認識到重點論法帶來的風險以后，企業便會改弦更張，在較長的一段時間內將全面的測試計劃擴展到更多的應用程序上。我們已經看到，有些企業聘請了滲透測試團隊，對企業的每個Web應用程序進行測試?？梢韵胂竦牡剑挥猩贁灯髽I有實力采用這種方法。更為重要的是，對于那些尚未被立即測試的應用程序來說，在完成測試和漏洞修復之前，它們可能會受到攻擊，而測試和漏洞修復往往需要一年甚至更長的時間。
3、應用程序風險程度分級法：一個可取的方法是根據多個因素對應用程序的風險程度進行分級，這些因素包括基于應用程序風險程度的各種評估技術。在開始介紹該方法之前，我們先來看一下每個應用程序的以下方面：
應用程序的目的：該應用程序要用來干什么？有多少人使用它？顯然，一個電話簿應用程序的風險程度不會高于一個財務應用程序。
數據風險：該應用程序是否有機密性和完整性要求？該應用程序或運行該應用程序的服務器是否需要提供99.999%的可用性？該應用程序是否受任何合規性法規（例如支付卡行業數據安全標準PCIDSS、健康保險流通與責任法案HIPAA等）的影響？
架構與設計：該應用程序屬于Web應用程序還是Web服務，是運行在客戶端/服務器、大型機、中間層、臺式機還是其他地方？該應用程序是面向Internet還是企業內網的？該應用程序是使用何種程序設計語言、在什么框架下開發的？該應用程序是否使用了任何已知的高風險組件（例如Ajax或PHP）？該應用程序的規模大約有多大（以源代碼的行數計）？
現有安全功能：該應用程序已經具有哪些安全功能？例如，該應用程序如何執行身份驗證、授權、輸入驗證等？
采用這種方法，確立為上述各個因素賦以相應的風險值的準則至關重要。例如，“面向Internet的應用程序加25分”，“不共享數據和不與任何其他應用程序交互的應用程序減5分”，等等。最終的結果是，每個應用程序獲得一個表示其風險程度的數值，你可以根據該數值對應用程序的風險程度進行分級。需要記住的是，分析應用程序往往十分耗時，而且難以完全準確。因此，你應該嘗試設定一個采集應用程序信息花費時間的上限，而不是強迫自己采集所有應用程序的所有信息。你的評分方法應該接受不完全準確的信息，并能夠將這些應用程序的風險程度區分開來，即使你對這些應用程序的安全性有比較透徹的了解。不要過分迷信評分系統——如果安全專家認為一個應用程序的風險程度很高，而評分系統的結果與安全專家的意見不一致，則應以安全專家的意見為準。
對于高風險等級的應用程序，首先應該對其進行威脅建模，然后進行手動和自動運行時漏洞評估與源代碼審查。對于中度風險等級的應用程序，應該對其進行手動和自動運行時漏洞評估與源代碼審查。對于低風險等級的應用程序，可能只需對其進行自動運行時漏洞評估。如果時間允許，還可以對其執行手動運行時漏洞評估。如果低風險等級應用程序的測試結果特別糟糕，則應該對該應用程序進行更加全面的測試。
4、健康檢查法：一種替代常規風險程度分級法的方法是，采用手動和自動相結合的方式，對所有應用程序執行為期一天的短期運行時漏洞評估。在這種情況下，評估人員可以將自動掃描限制在較少的測試用例中，從而可以顯著減少掃描時間（通常約為一個小時）。為此，需要減少每種攻擊類型的測試用例的數目，例如10個跨站點腳本攻擊、10個SQL注入攻擊等等，這一點非常重要。如果采用健康檢查法，則需要對掃描結果進行審查和驗證，甚至還可能需要花費額外的時間執行有限的手動測試。經驗豐富的評估人員根據測試結果可以確定，究竟是優先對該應用程序進行額外的測試，還是將額外測試推遲到風險等級更高的應用程序評估完成之后進行。
5、未經身份驗證的健康檢查法：另一種健康檢查方法是不需要提供身份驗證憑據，在很短的時間內對所有應用程序執行為期1至2天的短期自動運行時漏洞評估。這種方法類似于腳本小子（script kiddies）和工具小子（bots）所使用的攻擊方法，例如一直困擾Web應用程序的、臭名昭著的ASPSQL注入工具。當獲得身份驗證憑據極為困難或耗時時，可以考慮采用未經身份驗證的健康檢查法。但需要注意的是，通過身份驗證的用戶可能導致非常嚴重的風險，而未經身份驗證的掃描將會漏掉所有針對這些漏洞的攻擊。
那么，究竟采用什么方法最好呢？通過協調應用程序安全評估與業務風險評估，企業可以更好地安排時間和資金。多種方法相結合的方式是最合適的：立即確定風險等級最高的一小部分應用程序（例如公司網站的Web應用程序），并對其進行全面測試。與此同時，對應用程序風險程度進行分級，以確定應該對哪些應用程序執行進一步的測試。如果測試資源允許的話，在對應用程序風險程度分級的同時，開始執行未經身份驗證的健康檢查評估。采用這樣的評估流程，你可以獲得對應用程序的全面分析和快速掃描的客觀結果，從而準確了解應用程序的安全性。接下來的評估流程與常規的應用程序風險程度分級法類似：先測試風險等級最高的應用程序，再測試風險等級較低的應用程序。
當然，評估只是整個應用程序安全體系的一部分，接下來的重要步驟是漏洞修復。幸運的是，應用程序風險程度分級為確定漏洞修復的優先順序奠定了基礎：從風險等級最高的應用程序中風險最高的漏洞開始，依次解決各個風險等級的應用程序中存在的漏洞。此外，優秀的應用程序安全評估團隊還能找出應用程序漏洞的根源，并在軟件開發生命周期中提出修復建議，從而使應用程序從源頭上更加安全。
需要強調的是，無論你采用何種應用程序安全評估方法，都比對不安全的企業應用程序引起的許多風險視而不見要好得多。
京公網安備 11010502049343號