GSS 資安電子報0001期【衡量指標的重要性 】

衡量指標的重要性：量化軟體的安全風險

摘要

任何值得做的工作，都值得被測量。但軟體安全帶來了新的測量難點：沒有既定的公式或程式來量化那些程式中的安全風險。本文先說明軟體安全量化的重要性，再討論了當今普遍採用、但仍不讓人滿意的方法。接著本文會提出了一套新的指標，來全面、精確地量化軟體專案。這些專案可能是遺留的原有軟體專案，也可能是新部署的Web應用程式。

如果你的企業將其安全預算削減一半，會發生什麼呢？如果財政預算案增加了一倍呢？在今天的大多數企業中，或許沒人知道這些問題的答案。安全，與其說是科學，不如說更像是一門藝術。支持此論斷的一個非常有利的證據就是，安全的相關參與人員並不能量化其工作的具體效果。

軟體安全也不例外：當今部署的每一個商業關鍵應用程式，幾乎都存在漏洞，除了常見的緩衝區溢位漏洞與跨站腳本攻擊漏洞外，還有很多不太知名的漏洞。這些問題一旦暴露出來，就可能被外部駭客或有惡意企圖的內部員工利用，將會造成相當大的損失。

資訊安全團隊雖然知道這些錯誤的存在，但大多數的錯誤卻難以被準確地量化。有關改進這種情形的問題包括：

• 今天的應用程式與昨天相比，是更安全了還是更不安全了？
• 安全教育訓練是否真的有效果？
• 我們如何才能知道，何時才是安全？

本文調查了軟體安全量化實踐的當前狀況，然後提出解決此問題的兩種新方法：(1)量化安全開發的生命週期；(2)利用程式碼分析結果內建的量化數據，重點分析許多漏洞產生的根本原因。

一、先建設後入侵：將滲透性測試作為衡量指標

事實上，多數組織都採用該方法來量化軟體安全，可將其概括為：“先建設，後入侵” 。開發人員在開發應用程式時，只是最低限度地考慮安全因素，就將該應用程式部署上了。隨後，運營團隊試圖在週邊安全方面進行補救。資料進出週邊防禦體系，其方法與途徑會有多種，當團隊對這些途徑進行清點時，就會清楚地發現這些週邊防禦體系的安全是不夠的。從這個角度來看，運營團隊應該進行滲透性測試，以在駭客與內部惡意用戶之前發現安全問題。滲透性測試人員的工作通常有固定的進度安排，其目標在於找到少量的嚴重問題，以證明諮詢費用沒有白花。一旦解決了這些問題，每個人都會很高興。但沒有理由相信，所做的測試已覆蓋到了應用程式中所有的已存問題。事實上，往往隨後的稽核工作將會證實，之前所做的測試並不完整。同時，由於幾乎沒有什麼資訊回饋給開發人員，所以滲透性測試總是一次又一次地發現同樣類型的問題。

二、將軟體安全作為軟體品質的一個部分來進行測量

在軟體安全方面有一個幼稚的想法，就是將安全作為軟體品質的一個方面來考慮。這種方法的問題在於，傳統品質保障方法的目標在於驗證開發出來的功能是否與其規格定義相符合，而軟體安全遠不止是實現某些好的安全特性而已。現實情況就是，在傳統軟體品質問題與安全問題之間，沒什麼類比關係。換句話說，為了改進軟體安全，你必須特別專注於軟體安全自身。好的安全性並非是好的軟體品質的副產品。

圖1：以品質導向的方針來處理安全問題，將為攻擊者提供很多的攻擊機會

這一做法進一步惡化的情況是，大多數品質保證（QA ）部門缺乏必要的安全專業知識來進行充分的安全性測試。最終，就如同圖1所示的那樣，一些基於正常用戶行為的品質保證方法將給攻擊者留下許多未經測試的攻擊機會。

三、自我感覺良好的指標：如果它沒有被駭客攻垮，那它可能就是好的

因為安全通常沒有被量化，因此，對於安全性測試的底線往往是憑感覺。人性的特點與安全的特性在這一點上是衝突的：人與組織隨著時間的推移，往往趨向於滿足現狀，但隨著時間的推移，安全性可能會下降。新類型的攻擊以及屬於原有攻擊類型的新應用程式——甚至是因為安全“沒有問題”導致一個組織變得越來越自滿，都會危害程式的安全性。

類似的謬論還包括認為一個程式的安全與其所應用的範圍相關。有趣的是，這種推理方式，似乎始終在有利於現狀的情況下獲得認可。對於一個小用戶群所使用的應用程式，人們會假設攻擊者將不會感興趣。對於一個大用戶群所使用的應用程式，人們會假設在版本發佈後的較短時間內，安全問題就會從系統中暴露出來。實際上，與其應用的範圍相比，安全問題與其使用壽命的關係更密切一些。BugTraq郵件列表（那裏發佈許多新漏洞首次出現的消息）中有許多規模小和不引人注意的應用程式。此外，歷史悠久的緩衝區溢位在廣泛使用的程式如同在Sendmail和Internet Explorer中一樣，無論使用年限長短還是大型安裝都不能阻止攻擊者發現新的漏洞。

令人鼓舞的跡象表明，長期以來對軟體安全忽視、無知、或表現出冷漠的態度已經開始改變。微軟已經採用可信任計算安全開發生命週期過程來生產需要抵禦惡意攻擊的軟體（http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/sdl.asp 參考由Steve Lipner 和Michael Howard撰寫的“The Trustworthy Computing Security Development Lifecycle（可信任計算安全開發生命週期）” 。在微軟的軟體發展過程的每一個階段中添加了一系列以安全為重點的活動和產出。這些活動和產出包括在軟體設計中的風險分析，在實作過程對程式碼分析工具的應用，以及在安全推動之前的程式碼審查和安全測試。採用SDL的軟體專案在發佈前，必須進行最後的安全審查，該審查由獨立於開發團隊的小組執行。與那些至今尚未採用SDL的軟體相比，經歷了SDL的應用軟體能夠顯著降低外部發現安全漏洞的幾率。

圖2顯示的數目是Windows 2000和Windows Server 2003在其發佈的最初12個月內安全公告的數量，雖然作業系統的大小和複雜程度都增加了，但問題的數量反而減少了50 ％以上。

圖2：微軟作業系統安全上的明顯改善

不過，圖2是一個事後指標(trailing indicator)的例子。它只是表明在OS發佈後安全已得到改善。如果微軟每隔5到6年只發佈一款作業系統，那就需要很長的時間才知道與過去發佈的版本相比軟體安全上是否有一個明顯的改善。這個過程就過於緩慢了。在軟體發展的整個生命週期中，安全必須在一個持續的基礎上進行量化，為軟體的安全性，我們需要前導指標(leading indicator)。

解釋了量化問題以及為什麼沒有解決的原因，我們現在要談二個實際的量化軟體安全的方法。

一、量化安全開發生命週期

必須將軟體安全看作軟體發展生命週期的一部分（參見由Gary McGraw在Building Security In available上發表的一系列的白皮書，網址：http://www.cigital.com/labs/security/appsec.php）。

那裏有在生命週期的每個階段，開發團隊能夠採取的實用的步驟，這些步驟有利於提高目標系統的安全性。這些步驟包括：

1. 評估軟體安全的現狀，並創建一個計畫以便在整個開發生命週期中處理它。
2. 列出威脅清單，找出雙方的業務和技術風險，並計畫一個對策。
3. 建立一個把關機制，以防止帶漏洞的應用程式進入生產環節。需要關鍵的開發人員和安全人員的簽字。
4. 在程式開發階段審查程式碼，發掘安全漏洞。
5. 在初期所識別的威脅和風險的基礎上測試程式的漏洞。
6. 對安全計畫是否成功進行衡量，使這一過程能夠不斷改善。
7. 對有關成員進行安全教育，使他們能夠有效的實施安全計畫。

上述每個步驟都可以進行量化。例如，如果你的安全計畫包括教育開發者，你可以對參加軟體安全培訓的開發者的百分率進行計算。關於把這些步驟付諸實施的更多資訊，請參考Fortify Software的白皮書“交付安全軟體的7個實用步驟（Seven Practical Steps to Delivering More Secure Software）”

並非所有組織都必須採取所有的步驟以達到相同的程度。透過跟蹤和量化安全開發實踐的採用情況，你將很快獲得資料並得出與你組織之間的相互關係。例如，你可能會發現，剛開始「威脅和風險的指標」與「版本發佈前是否更快且更容易簽署通過」兩者間密切相關。

二、透過程式碼分析測量安全

所有的軟體開發組織，無論使用什麼樣的編程語言、開發方法或產品類別如何，都有一個共通點：他們都有原始程式碼。

原始程式碼是系統的一個非常直接的體現，而且大部份的漏洞都是因為原始程式碼而產生的。這意味著原始程式碼應作為評估軟體安全性最根本的部分來衡量。當然，原始程式碼審查的益處並不是僅提供一個可量化指標。以下各節討論一些原始程式碼分析的基本面，然後研究如何將原始程式碼分析結果作為原始資料，當作強而有力的軟體安全指標。

程式碼分析器分析程式碼，並尋找已知類型的安全缺陷。從抽象意義上來說，程式碼分析器是基於「模式」(pattern)來搜索程式碼，分析器將與軟體漏洞模式相符的程式碼提供給稽核員進行審核。程式碼分析的三個關鍵是：準確、精確、以及穩健。

程式碼分析器應該準確的標識漏洞，這些漏洞與被分析的程式的類型有關。舉例來說，Web應用程式通常的風險是SQL注入，跨站腳本攻擊，和訪問控制問題等。 此外，分析結論應說明每個結果可能的重要性。

程式碼分析器必須精準，並指出「可供管理」量的漏洞，而非盲目地產生大量的誤判(false positives)。此外，如果一個程式在今天進行了分析，並隨後在明天重新進行了分析，並且很可能只有一小部分的程式碼有所改變，在這種情況下，程式碼分析器必須能夠對同樣的問題給出同樣的名稱，無論是在今天還是明天，如此才能在問題出現和消除的時候有能力進行跟蹤。這種「能夠從原始碼的分析結果中，提取有意義的分析指標」的能力是至關重要的。

最後，原始碼分析器必須是穩健的：它必須能夠處理大型的、複雜的程式碼。當然，並不是程式碼分析器所確定的每個問題都將是一個真正的漏洞。因此，穩健的另一個方面是允許稽核員進行評估並對潛在的問題劃分優先順序。首選的情況是由一個稽核員從分析器的輸出分成以下幾類：1）必須予以糾正的嚴重漏洞，2）陋習，3 ）與組織無關的問題。甚至，程式碼分析的最好應用就是允許開發人員像他們寫程式碼那樣分析他們自己的程式碼，將程式碼分析作為每天程式開發的一部分。

最佳衡量指標可以從程式碼的分析結果中產生，在某種程度上，取決於組織以何種方式使用程式碼分析。
我們會考慮下列情況：

1. 程式開發人員定期的使用程式碼分析器，並將其作為他們開發工作的一部分。他們積極主動地將安全意識貫穿到程式碼的編寫中。
2. 由軟體安全團隊使用程式碼分析器並將它作為週期性程式碼審查的一部分。大部分的程式碼在開發時期很少考慮到安全。該組織計畫透過事後安全稽核修正程式碼。

當然，第一種情況是比較好的，但大多數組織無法實現這一目標。在不久的將來，在大多數組織中，可能是這兩種情況共同存在。

在程式開發團隊採用了程式碼分析工具、並依據安全政策調校後，他們可以將程式碼的分析結果集中起來進行趨勢分析和專案間的比較。圖3顯示的是兩個專案間的比較，其中的一個專案用紅色表示，另一個用藍色表示，圖中使用的是經過嚴重程度等級分類的程式碼分析結果。該圖提供一項行動計畫的建議：首先消除紅色的專案中等級為嚴重(critical)的問題；接著消除藍色的專案中等級為高風險(high)的問題。

圖3：兩個專案中，按問題的嚴重程度劃分的程式碼分析結果

將發現的問題按種類進行歸類，這對於問題類型的研究也是非常有益的。圖4顯示是與前面相同的兩個專案用這種方式表示的結果。在這種情況下，紅色和藍色項目之間的不同就顯得非常突出：藍色項目有相當數量的緩衝區溢位問題，因此，制定防止緩衝區溢位的策略勢在必行。

圖4：程式碼分析出的問題按漏洞類型進行分類表示

程式碼分析結果也可以被用來研究漏洞的趨勢。隨著時間的推移，注重程式安全的團隊，因為他們越來越多地使用自動化工具以減少安全問題，其程式碼分析中發現漏洞的數量終將減少。若趨勢呈現明顯的變化，則代表出現了新的值得關注的安全焦點。圖5顯示了在每一次晚上編譯建置(build)時所發現的問題數目。趨勢指標顯示了該專案是如何演變的。在此案例，問題數量瞬間大幅成長，其原因是該開發團隊接管了一個模組，而該模組是由從不關注程式安全團隊所開發的（該程式碼也許是由外包團隊或遠端開發團隊開發的）。這新加入的不安全程式代表一項新風險，需要在軟體開發生命週期的後續部分進行修正。

圖5：隨著時間的推移源程式碼的分析結果

對於「安全」並不重要的大型codebases而言，它所面臨的安全挑戰是不一樣的。在大多數情況下，即使是為了安全的目的，也不可能在一瞬間改裝整個的codebase。相反地，審核團隊需要將問題劃分優先順序，先消除最嚴重的問題。當然，即使發生了分流情況，新的開發也將繼續。

舊有codebase的量度指標影響並提升了程式碼分析器的功能：針對不同的編譯建置(build)，可提出相同的問題以及相同的問題名稱。隨著時間的推移，跟蹤同樣的問題並將它與審核員提供的回饋資訊進行關聯，程式碼分析器就能提供對整個專案演變過程的詳細觀察。

舉例來說，程式碼的分析結果可以揭示開發團隊回應安全漏洞的方式。在審核員確認了漏洞之後，開發團隊進行修復的平均時間是多長？將這個量度指標稱為“漏洞滯留”。圖6顯示的是一個專案中，開發者在兩天內修復了嚴重漏洞，並隨著漏洞嚴重程度的降低，修復嚴重程度較輕的問題的時間逐漸增長。

圖6：按功能的優先次序處理漏洞滯留

因為一個舊有的codebase往往處於不斷的發展中，審核員將需要不斷地返回到同樣的專案中去。但頻率是多少呢？每個月還是每六個月？審核的頻率應該跟上開發的進度，或者跟上潛在的安全性問題引入到程式碼的比率。隨著時間的推移並對個別問題的跟蹤，從程式碼分析工具的輸出結果可以看出一個專案中有多少沒有審核過的問題。圖7介紹了一個典型的圖。在該專案進行首次審核的時候，審核覆蓋面達到100％ 。隨著時間的推移，審查覆蓋範圍逐漸減少，直至該專案再次進行審核。

圖7：隨著時間的推移，審計範圍的變化

對同樣的資料，另一種觀點為該專案提供了更全面的看法。審核的歷史資料以時間為橫軸，表明了問題的總數(total)、已審核問題的數量(reviewed)、以及已確定的漏洞的數量(validated)。這種觀點考慮的不僅是審核員的工作，也包括程式開發者對專案的影響。圖8 表明對多個產品進行的審核（以紅色表示）。在審核同時，發現的問題正在增加（以藍色表示）。審核員的工作是發掘漏洞（以黃色表示）。當藍色和紅色相遇的時候，審核員已經檢視所有發現的問題。然而程式開發工作尚未完成，並且很快該專案將再次出現未審核的問題。當開發者對審核團隊確認的漏洞進行回應的時候，問題的數量開始下降，一些已確定的漏洞開始進行修復。圖表的右側明顯表示，另一個審核正準備開始。

圖8：審計歷史

雖然軟體安全一直是公認的風險，但當前的軟體產業仍缺少對安全風險進行量化的確實步驟。只有通過測量，組織才能夠征服軟體的安全問題。

這個過程的第一步，是採用SDLC流程規範，並在軟體發展過程中的每個階段遵從一系列以安全為重點的活動和交付。這些活動和交付，包括在軟體設計中的風險分析、在建置過程中對程式碼分析工具的應用、程式碼審查和安全測試，以及最後再由獨立于開發團隊的小組進行的最後的安全審查。

或許遵循SDLC規範會加重組織的工作量，但組織可分階段採用SDLC規範。關鍵是要從現在就開始並持續優化你的過程。藉由量化安全開發生命週期以及查明漏洞產生的根源(利用量化程式碼分析結果)，組織對付安全風險問題情況將由被動轉為主動。

Fortify Software產品可保護組織免於因關鍵應用軟體存在安全問題而導致威脅。Fortify產品已獲領先的軟體公司和Fortune前500大的IT組織使用。

Fortify已發展出領先業界、正在申請專利中的技術，該技術從內到外的將安全引入到軟體應用程式中，使安全成為軟體固有的本質，藉由在部署前消除應用程式中的漏洞，應用程式可保護自己免受攻擊。

Follow us

立即訂閱以收到最新資安文章