李舟,唐聰,胡建斌,陳鐘
(北京大學信息科學技術學院,北京 100871)
面向SaaS云平臺的安全漏洞評分方法研究
李舟,唐聰,胡建斌,陳鐘
(北京大學信息科學技術學院,北京 100871)
對不同的第三方提供的云服務進行漏洞評分是一項充滿挑戰的任務。針對一些基于云平臺的重要因素,例如業務環境(業務間的依賴關系等),提出了一種新的安全框架VScorer,用于對基于不同需求的云服務進行漏洞評分。通過對VScorer輸入具體的業務場景和安全需求,云服務商可以在滿足安全需求的基礎上獲得一個漏洞排名。根據漏洞排名列表,云服務提供商可以修補最關鍵的漏洞。在此基礎上開發了VScorer的原型,并且證實它比現有最具有代表性的安全漏洞評分系統CVSS表現得更為出色。
SaaS;云服務;漏洞評分系統;CVSS
云計算越來越受歡迎,它作為大數據的下一代基礎設施,應用于許多應用軟件中。此外,云計算提供了一種新的商業模式,軟件服務和核心計算應要求外包給第三方平臺,如蘋果的 iCloud和谷歌的應用平臺。最近,Ristenpart等[1]指出這項新的商業模式也引入了一系列的風險。因為云平臺中的軟件和應用服務來自不同的服務商,在這些服務和軟件中不可避免地存在許多漏洞。不幸的是,以往的研究[2,3]表明,現有的漏洞發現和風險管理技術不適用于評估和處理業務環境的情況。如圖1所示,定義業務環境為某一項業務,業務間的依賴關系如箭頭所示。另外,vi用于表示不同服務的漏洞,它呈現不同服務間具體依賴關系圖表。綜上所述,很有必要研究如何對云服務漏洞進行評級和打分。
事實上,漏洞發現一直都是安全服務行業的重要一環,每年有成千上萬的新的服務漏洞被檢測并且發布出來[4],同時投入大量努力去解決這些問題。然而,目前已有的大部分解決方法都是通過打補丁和其他減緩策略,這會耗費大量的人力。

圖1 云服務中業務場景的服務間相關性
因此,目前一些研究者致力于提出解決方案[3],以期能基于威脅等級來打分,讓開發者可以先處理這些比較嚴重的漏洞。換言之,組織者有充足的人力處理每個發現的漏洞(比如給每個漏洞打補丁),這個方法可能影響到這些公司。因此,云服務開發者應該能夠合理分配和規劃工作,使最嚴重的一些漏洞可以優先定位和解決。基于安全方面的考慮這也是很重要的,如果業務中的一些關鍵服務的某些漏洞被攻擊者利用,重要業務就會遭受影響。如圖1所示,由客戶端來執行的某項具體業務環境,對手可以很輕易地利用和攻擊服務器 S3的漏洞來使整個業務癱瘓,而不是攻擊其他服務器的漏洞(如S2和S5)。
現有一些系統設計是基于漏洞打分策略[3,5~7]。然而,這些系統存在各種各樣的問題,致使無法應用于現在的云服務中:1)未成功考慮業務環境,目前打分系統不僅對于云服務的精確打分漏洞的要求來說過于簡單,而且并未成功考慮業務環境,比如服務器間(如軟件)的依賴關系,這樣并不能夠用來在云服務中進行給漏洞評分,目前的漏洞打分系統過于局限,針對漏洞不能提供較強的預測能力[3];2)未能區分安全需求,目前的漏洞打分系統(比如 CVSS)未能基于不同的安全需求來區分相同漏洞的威脅等級,例如,對于某一業務,某個漏洞可能對于它的可用性來說非常關鍵,但是對于它的健全性來說并不如此,因此,缺乏安全需求的考慮,致使在漏洞方面以前的系統的可預測能力是難以使人信服的。
為了使云服務更加讓人信賴,在云服務中根據具體的安全需求來評估和評級漏洞,本文提出了一種新型架構 VScorer,可以應用于目前云服務基礎架構,并且在云服務中根據特定的安全需求進行漏洞打分。具體而言,對于某個業務環境,通過向VScorer系統中輸入業務環境(比如服務器間的依賴關系)以及安全需求,云服務開發者(比如云服務公司的安全開發者)能夠獲得業務中存在的漏洞評級列表。這份漏洞評級列表不僅能讓云服務開發者明確哪些漏洞應該優先處理,而且能讓云服務客戶端理解云服務是否處于危險中。
實際上,VScorer針對具體的業務環境對某特定的漏洞v進行打分,依賴于以下3個因素:1)對于特定安全需求(或者成為安全特性)中v的威脅等級;2)包含漏洞 v的服務的重要性;3)漏洞 v的可利用性。定義服務器Si中漏洞v的可利用性為可以從Si中利用的可能性。對于某些漏洞,不同的服務中可利用性是不同的。在實際的應用中,安全開發者按照以下3個步驟來執行VScorer。
1)針對特定的業務構建或者獲取服務器間的依賴關系圖表,并且將相關性和具體的安全需求輸入VScorer。一些軟件和應用[8,9]可以自動生成產生服務器間的相關圖。
2)VScorer基于之前提過的3個因素來計算每個漏洞的得分,并且給所有漏洞來評級,產生基于特定安全需求的漏洞評級列表。
3)根據評級列表,云服務的開發者通過某些有效方法(比如給漏洞打包)來處理這些漏洞。
VScorer設計為可以在云服務中用于評分漏洞的安全框架,適用于:1)不同環境的很多業務,每個業務由可能包含漏洞的服務組成;2)場景中有 3類身份,即普通用戶、云開發者和攻擊者。相對來說,普通用戶目標是執行他們想要的業務,他們可稱為云服務的客戶端;云服務開發者的目標是確保整個云服務的安全;攻擊者利用漏洞來攻擊不同的服務。
如圖2所示,服務器的相關圖(如業務環境)和安全需求輸入VScorer。一般而言,VScorer的主要任務是在業務環境中進行漏洞打分,并且根據輸入的安全需求輸出漏洞的評級列表,云服務開發者以此來對最重要的漏洞優先進行處理。服務器S1~Sn輸入到生成器來獲取服務間的相關圖。相關圖表和具體安全需求輸入到基礎架構中,VScorer能夠生成根據漏洞得到的評級列表。對于某個漏洞 v,VScorer關于v的評分算法主要基于3個因素:包含v的服務器的重要性、安全需求以及不同服務v的可利用性。

圖2 VScorer系統框架
VScorer的設計主要回答以下2個問題。
1)假定某個安全需求,具體業務環境中哪個漏洞是最重要的(比如最危險的)。
2)怎樣合理并且精確地為這些漏洞打分。
下面來討論用于設計VScorer系統漏洞打分算法的因子。
后續描述都會設計到給定的漏洞集V '。為了合理地計算V '中所有漏洞的分數,有2個影響到V '中每個元素(vi)打分的事情:1)計算中所考慮到因素(或者部分);2)獲取這些因素的方法。下面將分開討論這2個影響因素。
計算每個漏洞得分時,需考慮以下3個要素。
1)包含vi的服務器的重要性。因為所面對場景是云服務,這些服務器存在很多依賴關系(比如業務環境),服務的重要程度有必要考慮到。以前的策略(比如 CVSS[5]和USCERT[10])并未考慮到業務環境。例如,作為具有代表性的漏洞打分系統,CVSS的“漏洞基礎得分”按照影響因子I和可利用度E要素來表示的

影響因子(I)是由CVSS的開發者或者專家提供的。很明顯,CVSS的算法不能應用于云服務基礎架構中,因為等式的2個要素與云服務的業務場景并無關聯。
2)按照給定安全需求的vi的威脅等級。幾乎所有目前的工作都未考慮不同安全需求中漏洞的威脅等級這個因素。為了更加合理可信地對vi進行打分,需注意到不同安全特性下對vi的威脅等級評估的必要性。比如,對于某個特定服務,某個漏洞對這個服務的可用性非常關鍵,但是對于健全性遠遠沒那么重要。因此,對于某個漏洞,有必要考慮不同安全特性下的威脅等級。將這個因素設計為一個函數,它的輸入是具體的威脅vi、安全需求pj,返回的值是關于安全需求pj的vi的威脅等級。
3)不同服務中 vi的可利用性。如上面所提到的,漏洞的可利用性應該考慮到。實際上,以往的系統,如CVSS和USCERT也考慮到這個因素。考慮到CVSS已經發布很多可靠的數據和可利用性的信息,因此,本文的框架直接從CVSS系統中提取可利用性的信息。事實上,以往的工作[3]也直接從CVSS中使用了這部分數據。
總而言之,以往的系統(如CVSS和USCERT)并未考慮到業務環境,它們并未成功合理地對云服務進行漏洞評分。更進一步說,以往所有致力于漏洞評分的研究只考慮了2個因素:影響力(比如可利用性的結果的重要程度)以及可利用性(比如漏洞利用的難易程度),這些考慮并不充分。
實際上,VScorer能夠從一些已有系統(如CVSS)的信息獲取這3個因子。這是VScorer主要貢獻之一,因為,以往的工作需要一些專家學者的參與。自動獲取這3個因素的方法如下所示。
包含漏洞的服務重要性評估計算參考了如PageRank和AssetRank[11]的重要程度計算算法。由于云服務中存在特殊的特征(比如云服務間存在直接的依賴關系),重要性算法可以認為是一項給云平臺場景中的不同服務進行評級的有效方法。
為了獲取漏洞的可利用性,VScorer直接利用了 CVSS或者其他漏洞評分系統的可利用性評分。以往的研究[3]指出,CVSS的可利用性可直接借用,但是CVSS其他的要素(如漏洞的影響程度)應該由某些安全專家提供。因此,可利用性度量來自 CVSS,實際上并未違反設計自動化的原則。另一方面,CVSS的可利用性支持本文的理念,以往研究中的可借鑒之處是應該直接借用的。
為了獲取給定安全需求下的某些漏洞的威脅等級,VScorer使用了兩大在線漏洞數據庫提供的信息:OSVDB[12]和 CVE[13]。例如,OSVDB 包含超過57 000個漏洞的報告,并且能夠提供這些漏洞在不同安全特性下的威脅等級信息。總之,可以基于自動化方法和現有系統獲取3個因子。這不僅節約了人力成本,也充分利用了以往研究成果。
基于以上討論和描述,圖 3給出了 VScorer結構的詳細設計。接收到業務環境和安全需求的數據后,VScorer結合從3個組成部分(重要程度算法、VE_DB和 FS_DB)中提取的 3個因素來計算所有漏洞的得分。VE_DB和FS_DB是分別存儲不同安全需求下漏洞可利用性和威脅等級的數據庫。最后一步,此架構生成基于漏洞威脅等級的評級列表。
由于VScorer是基于可擴展的架構,圖3中并未標示出系統要素的詳細算法。接下來,將給出計算具體安全需求下給定漏洞v的得分的具體算法。

其中,Sv是包含漏洞v的服務器集,si是Sv集的元素,如漏洞v的服務。E(v,si)是函數返回的可利用性,如漏洞 v能被服務 si利用的可能性。Rank(si)是服務si的重要性,是由重要性算法(如PageRank和 AssetRank)計算出的服務器得分。P是用于澄清語義的安全需求。F(v,P)是此函數用于計算某特定安全特性P的漏洞v的威脅等級,如返回0~5的某個數值,以對關于P的v的威脅等級來進行評級。α和β是基于[0,1]的可調參數。
眾所周知,對漏洞進行評級和打分是非常具有挑戰性的[2]。接下來討論式(2)對于漏洞評分的合理性。
1)因為漏洞的嚴重性直接相關于包含它們的服務的重要性,不同服務的重要性明顯是漏洞評級的一個關鍵因素。對于某給定漏洞 vi,包含vi的服務的重要程度應該用于衡量 vi的威脅等級和可利用性,以控制威脅等級和可利用性的波動范圍。
2)α和β是控制式(2)中2部分特性的2個關鍵可調參數。實際上,它們具體的數值應該基于實際需求。例如,實際中如果漏洞的可利用性比它的威脅等級更重要時,α的值應該設置更大一些。并且,當分別設置 α=1、β=0.5和 α=0.5、β=0.5時,本文通過公式得到類似的評級列表。
在一些實際場景中,服務重要程度的計算可能需要考慮到服務間相關性的度量,如有區別地看待相關性,這將包含業務場景進程而不是目前的一個。對于這種情況,VScorer允許管理者根據具體需求來調整Rank(si)的計算,因此,Rank(si)實際上是能夠適用于不同場景的通用的重要程度計算算法。另外,如第2部分所提到的,盡管目前VScorer根據 PageRank算法來計算重要程度;然而,更多特殊的關系,如服務器間需要考慮“或”和“與”,AssetRank[11]應該替代PageRank來作為重要程度算法;同理,如果目標業務場景的某些服務已經癱瘓,應該借助 TrustRank[14]來為每個服務進行打分和區分。因為目前CVSS和USCERT漏洞打分系統不能做到這些,VScorer的通用性和適應性要比已存在的研究成果更加優秀。
圖4所示的例子可以更清晰地理解式(2)。示例中有9個服務器(S1~S9),其中有些有漏洞(v1~v3)。云管理者Alice試圖評估這3個漏洞,它將服務器的依賴關系輸入VScorer系統;同時,它評估的安全需求設計為“integrity”。為了簡化計算,假設不同服務器中漏洞的可利用性是1.0,即E(v1,s1)=E(v1,s4)=E(v2,s4)=E(v2,s7)=E(v3,s6)=E(v3,s9)。對于不同的漏洞威脅級別,安全的需求是鑒權,即P=“integrity”),假設F(v1,P)=1,F(v2,P)=2,F(v3,P)=3。VScorer首先通過pageRank算法得到所有服務的Rank(si),從而獲得Rank(s1)=0.15,Rank(s2)=0.21,Rank(s3)=0.21,Rank(s4)=0.24,Rank(s5)=0.24,Rank(s6)=0.33,Rank(s7)=0.35,Rank(s8)=0.5,Rank(s9)=1.01。然后VScorer可以通過式(2)計算出v1、v2和v3的Alice分數。

圖3 VScorer的具體方案

圖4 通過式(2)對漏洞v1、v2評分

α和 β如果賦值為 0.5,那么漏洞排名是:R(v3)=2.68,R(v2)=0.885和R(v1)=0.39。
雖然已經證明了式(2)可以在云端對漏洞評分,本文還是希望呈現更多能被選擇的算法來對漏洞進行打分。因此,提出了另一個公式用來對給定的漏洞v打分,如式(4)所示。

式(4)中所有符號的解釋在式(2)中已經給出。
研究表明,符合條件的風險是一個棘手的問題[2]。因此沒人能證明該算法評估的風險(例如漏洞)是最準確的。最好有多種不同的選擇(即不同的公式)對漏洞進行打分,通過實驗和模擬不同的情況來評估哪些是最合適的。事實上,此功能體現了本文框架的靈活性和可用性,因為 VScorer能夠通過部署不同的漏洞評估機制來滿足各種實際的需求。
除了上述討論,在現實中的應用,還有如下 2種需要考慮的實際問題。
1)有一些服務或者軟件在漏洞排名前已經被泄露。
2)由于隱私方面的一些原因,某公司不希望公開服務的依賴關系。
要回答上述實際問題,需要通過引入一些新的機制來加強VScorer。
1)對于第1個實際問題,本文引入TrustRank[14]來替代PageRank計算各服務的重要性和信任關系,以此來發現攻擊者的服務妥協;另一方面,TrustRank和PageRank在計算服務的重要性方面具有相同的功能。因此,引入TrustRank對服務進行打分不會影響對漏洞的打分。
2)對于第2個實際問題,可以要求公司自己對服務進行排名。請注意,這個排名列表僅包含由該公司提供的服務順序,而不是服務的重要性。在現實中,要求一個公司給出他們服務的順序(基于重要性)應該不是問題。這是因為對每個服務評級對一個公司來說很難,但是他們必須明白哪些服務是最重要的,相對重要和不重要的。
實際上,附加采納上述2種解決方案不是什么問題。VScorer的設計使添加其他組件或模塊是非常方便的。
本節的主要目的是評估 VScorer的性能,建立VScorer原型系統;然后通過3個案例,基于真正的業務環境和模擬漏洞信息來驗證 VScorer的有效性。
為了評估VScorer,本文提出了3個基于真實業務流程的案例,用CVSS對比2個公式(即式(2)和式(4)),從而表明VScorer的有效性。每個案例的研究如下。
1)輸入具體的包括安全需求和業務流程的實驗數據進入 VScorer模型,從而獲得對給定的安全需求的漏洞排名。分別通過式(2)和式(4)生成2個排名列表;因此,實際上是由VScorer獲得2個排名。
2)通過 CVSS生成另一個排行榜,比較CVSS的結果和之前通過VScorer的2個公式生成的排行榜。使用CVSS來比較VScorer的原因將在后面給出。
3)比較并評估哪一個排行榜是最好的,通過模擬評估漏洞排行榜。之后,分析和討論得到的結果。
目前,已經在實際使用中的幾個漏洞評分系統,CVSS已經逐漸成為公共的標準,因此選擇CVSS和VScorer比較。此外,現有的研究[3]也指出CVSS是目前具有代表性的漏洞評分系統。接下來,討論如何比較和評估不同系統的排行榜,3個研究案例將給出。
假定每個服務運行在給定的業務流程中是不同的,因此,當運行一個具體的任務在那個業務中時,可以通過在任務運行過程中所有服務的運行時間的總和獲取該任務的運行時間。比如,在圖5中,如果得到VCL接入服務的運行時間為0.3,VCL管理服務的時間為0.5以及應用服務3的運行時間為0.4,所以任務的運行時間為0.3+0.5+0.4=1.2。此外,如果某個漏洞被攻破,執行這些有漏洞的服務將花費更多的時間,即可以認為泄露的漏洞延遲了有漏洞任務的運行時間。在模擬中,延遲時間為 0.2,例如在圖5中,如果VCL訪問服務有一個泄露漏洞,然后它由VCL接入服務任務的運行,VCL管理服務和應用服務 3的運行時間應該為0.3+0.5+0.4+0.2=1.4。
描述如何計算性能指標后,運行模擬器的詳細步驟如下。
1)根據給定的業務流程產生的模擬環境(包括服務、依賴和漏洞)。
2)在給定的業務流程中分別泄露每個漏洞,并計算每個泄露的漏洞的性能值。特別地,對于每個漏洞,隨機在指定的業務中執行不同的任務1 000次,然后計算運行1 000次的平均時間作為該漏洞的性能指標。
在獲取不同泄露漏洞的性能指標之后,可以評估哪一個排行榜最優。顯而易見的是性能指標應該是最高的(即延遲時間最高),如果最關鍵的漏洞被攻破。也就是說,如果v3是最關鍵的漏洞,模擬器的性能指標應該是最高的。因此,在得到所有性能指標的排行榜之后(從高到低),比較2個排行榜之間的匹配程度,即漏洞排名和性能指標排名(性能指標排序由高到低)。2個排行榜更匹配的就是更準確的漏洞排行榜。下面將提出3個研究案例來評估本文方法。
在這個案例中,使用一個來自 VCL的真實業務流程來評估VScorer,業務流程的信息展示在圖5中,菱形表示漏洞,其他表示 VCL中的服務。漏洞的可利用性和威脅級別(對于給定的安全需求)展示如表1所示,假設不同的服務中相同漏洞的可利用性是一樣的。威脅等級是根據給定的安全性要求在0~5中取值。請注意,只能從VCL中提取業務流程,但不是所有的漏洞。由于隱私問題,本文通過仿真生成漏洞。類似地,案例2和案例3利用真實的業務流程和漏洞進行了模擬。

圖5 VCL數據集的具體業務流程

表1 案例1漏洞的可利用性和威脅級別
基于VScorer的2個公式,即式(2)和式(4),得到了2個對于給定安全需求漏洞的排行榜;同時,使用CVSS產生了另一個排行榜。表2展示了這3個排行榜。相對于α和β的值,設置α=1.0,β=0.5。實際上,也可以為它們設置不同的值(如α=0.5,β=0.5),并且得到一個相同的結果;因此α和β的值實際上不能顯著影響結果。

表2 案例1 VCL的漏洞排名
評估排行榜并且討論。要了解3個排行榜的準確性,本文的模擬器執行評估3種方法的有效性。當漏洞CVE-2008-5410被攻破時性能指標最高,根據該指標從高到低,模擬器基于性能指標對漏洞進行的排序為:CVE-2008-5410、CVE-2008-0600、CVE-2007-1747、CVE-2008-3648、CVE-2006-6077和 CVE-2008-0231。實際上,這個順序與 VScorer產生的排行榜正確匹配;另一方面,由于未能考慮給定安全需求的業務環境和威脅級別,CCVS的排行榜是不準確的。因此,在案例 1中,實驗表明VScorer可以工作得比CVSS更好。
在此案例中,本文使用一個EC2[15]的真實業務流程。圖6所示為服務的具體依賴關系和位于業務流程中的漏洞,菱形表示漏洞,其他表示EC2的不同服務。漏洞的可利用性和威脅級別(根據安全要求)如表3所示。

表3 案例2 漏洞的可利用性和威脅級別

圖6 EC2數據集的一個具體業務流程

表4 案例2 EC2特定業務流程的漏洞排名
運行模擬器之后,模擬器的結果表明漏洞的正確順序應該為:V-2009- 3508、V-2007-6410、V-2009-4447、V-2006-6077和 V-2008-3631。另一方面,如表4所示,可得出2個結論:1)式(2)得出的排行榜是最準確的,因為它和模擬器得出的結論最匹配;2)雖然式(4)得出的結果在案例1中是正確的,它不能在本案例中給出一個正確的結果;同時,CVSS的結果也不準確。實際上,這是因為 2種方法(VScorer的式(4)和 CVSS)背后的算法。特別地,CVSS沒有考慮服務間的依賴,而式(4)具有算法方面的薄弱點。因此,我們證明了VScorer的式(2)比其他2種方法工作得更好。
案例3使用的數據和信息來自于IBM的災難援助理賠服務。如圖7所示,菱形表示漏洞,其他表示業務中的不同服務,可以看出具體的依賴關系和位于各種服務上的漏洞。漏洞的可利用性和威脅級別(根據安全要求)如表5所示。

表5 案例3 漏洞的可利用性和威脅級別

表6 案例3 IBM的災難援助理賠服務的漏洞排名
評估排行榜并且討論。運行模擬器之后,可得出 3個結論:1)從式(2)得到的排行榜在本案例中對漏洞的排序是正確率最高的,因為它和模擬器得出的結論最匹配;2)式(4)的結果也是準確的,但是不如式(2)精準。事實上,式(4)在本案例中至少比CVSS表現得更好;3)CVSS的算法在本案例中沒有得到一個好的結果,因為CVSS的機制不能在考慮業務流程的情況下,取得良好的效果。因此,可以得出VScorer的式(2)應該是最準確的,并且在云服務中可以工作得比CVSS更好。

圖7 IBM的災難援助理賠服務的一個具體業務流程
3個案例得到的漏洞評級列表如圖8所示。

圖8 在3個案例中基于仿真器性能得到的漏洞評級列表
為了幫助安全管理員,許多漏洞評分系統已經被提出。幾乎所有的人都關注于如何基于2個因素對漏洞打分:影響和可開發性。很明顯,它們不能被采用到云基礎設施中,因為它們沒有考慮具體的業務流程上下文這個云服務中的關鍵因素。特別地,USCERT產生了一個0~180內的量化程度評分,從一系列的定性問題的答案中直接計算[10]。另外,微軟的安全公告記錄漏洞的嚴重性(用定性的方法),用來作為Secunia的報告。近來,一個新的嚴重性指標,常見漏洞評估系統(CVSS)[5],被一些安全專家和研究人員所提出。CVSS定義了一些獨立的指標;然而,根據這項研究[3],CVSS只是“基礎指標”,被典型的使用于第三方漏洞數據庫。事實上,以前進行了一些努力來分析和改進CVSS[16,17]。與本文的方法相比,CVSS未能提供其明確考慮到業務流程上下文的機制。相反,為了克服這些困難,VScorer采用PageRank算法,來計算云服務的服務重要程度。實際上,本文進一步補充用于計算云服務重要程度的 PageRank的算法,加入具體安全需求的考慮。
目前,很多關于漏洞發現的報告已經通過多資源如 CVE[16]和 OSVDB[12]發布出來。特別是 CVE明確地將某些安全需求下的不同漏洞威脅等級列入考慮之列;然而 CVE并未為漏洞評分提供合理的機制。而且,大量研究檢測到可被修復漏洞的可能性[18]。
本文設計了一種新型架構 VScorer,來為云服務中的漏洞進行評分和評級。與以往研究成果不同,VScorer不僅考慮到它的內在特性,如可利用性,而且將可利用性的這些服務場景考慮在內,比如在組成的服務器中所扮演的角色,以及服務安全目標的重要性。漏洞的評分和評級結果對于組成的服務而言具有高相關性和價值。通過基于實際中服務場景進程的實驗,對VScorer的有效性進行了評估,并且將VScorer和CVSS進行了比較,結果表明在云服務的漏洞評分場景中,VScorer比現有的研究成果表現更為出色。
[1]RISTENPART T,TROMER E,SHACHAM H,et al. Hey,you,get off of my cloud: exploring information leakage in third-party compute clouds[C]//ACM Conference on Computer and Communications Security.c2009:199-212.
[2]BELLOVIN S. On the brittleness of software and the infeasibility of security metrics[J]. IEEE Security and Privacy,2006,4(4): 96.
[3]BOZORGI M,SAUL L,SAVAGE,et al. Beyond heuristics: learning to classify vulnerabilities and predict exploits[C]//ACM Sigkdd International Conference on Knowledge Discovery amp; Data Mining. ACM,c2010:105-114.
[4]IBM. IBM Internet Security Systems X-Force 2008 Trend and Risk Report[R]. White paper,2009.
[5]A complete guide to the common vulnerability scoring system[S].
[6]OWASP Top Ten[EB/OL].http://www.owasp.org/,2013.
[7]SANS Top-20 Security Risks[EB/OL]. http:// www. sans. org/ top20,2009.
[8]CHEN X,ZHANG M,MAO Z,et al. Automating network application dependency discovery: Experiences,limitations,and new solutions[C]// Usenix Symposium on Operating Systems Design amp; Implementation. c2008:117-130.
[9]ENSEL C. A scalable approach to automated service dependency modeling in heterogeneous environments[C]// IEEE International Enterprise Distributed Object Computing Conference,c2001:128-139.
[10]DOUGHERTY C. Vulnerability metric[EB/OL]. https :// www. securecoding.cert.org/con fl uence/display/seccode/Vulnerability+Metric,c2008.07.24.
[11]SAWILLA R and OU X. Identifying critical attack assets in dependency attack graphs[C]// European Symposium on Computer Security-esorics. c2008:18-34.
[12]OSVDB. The open source vulnerability database[S].
[13]CVE Editorial Board. Common vulnerabilities and exposures: the standard for information security vulnerability names[S].
[14]GYONGYI Z,GARCIA H,PEDERSEN J. Combating web spam with trustrank[C]//Thirtieth International Conference on Very Large Data Bases. c2010: 576–587.
[15]CHRISTOS T. Software for Cloud[S].
[16]SCARFONE K,MELL P. An analysis of cvss version 2 vulnerability scoring[C]//International Symposium on Empirical Software Engineering amp; Measurement. c2009: 516 -525.
[17]FRUHWIRTH C,MANNISTO T. Improving cvss-based vulnerability prioritization and response with context information[C]//ESEM,c2009:535-544.
[18]MOORE D,SHANNON C,CLAFFY K. A case study on the spread and victims of an Internet worm[C]//Internet Measurement Workshop.c2002: 273-284.
Vulnerabilities scoring approach for cloud SaaS
LI Zhou,TANG Cong,HU Jian-bin,CHEN Zhong
(School of EECS,Peking University,Beijing 100871,China)
There are full of challenges to score vulnerabilities of cloud services developed by different third-party providers. Although there have been a few systems for scoring vulnerabilities (e. g.,CVSS)of many existing software,most of them are unable to be leveraged to score vulnerabilities in cloud services,because they fail to consider some important factors located in the clouds such as business context (i. e .,dependency relationships between services). VScorer,a novel security frame work to score vulnerabilities in various cloud services were presented based on different given requirements. By inputting concrete business context and security requirement into VScorer,cloud provider can get a ranking list of vulnerabilities in the business based on the given security requirement. Following the ranking list,cloud provider was able to patch the most critical vulnerabilities first. A prototype was developed and VScorer can be demonstrazed to work better than current representative vulnerability scoring system CVSS.
SaaS,cloud service,vulnerability scoring system,CVSS
The National Natural Science Foundation of China(No.61272519,No.61170297,No.61572080,No.61472258)
TP393
A
2016-06-17;
2016-08-01
國家自然科學基金資助項目(No.61272519,No.61170297,No.61572080,No.61472258)
10.11959/j.issn.1000-436x.2016166

李舟(1987-),男,湖北荊州人,北京大學博士生,主要研究方向為信息安全、基于身份的公鑰加密。

唐聰(1984-),男,湖南永州人,北京大學博士生,主要研究方向為信息安全、云計算、社交網絡。

胡建斌(1971-),男,湖北洪湖人,北京大學副教授,主要研究方向為云計算、物聯網、計算機網絡安全。

陳鐘(1963-),男,江蘇徐州人,北京大學教授、博士生導師,主要研究為密碼學、計算機網絡與信息安全。