搜尋此網誌

2010年7月21日 星期三

[資安標準] OWASP Application Security Verification Standard (ASVS)

Dude_Writing_Check_List

近幾年應用程式所產生的安全漏洞數量已經明顯高於網路與作業系統層級的總和,其中尤其以 Web 相關的應用程式為最大宗。包含網站本身所存在的安全問題,再加上各式各樣瀏覽器與外掛程式 (如惡名昭彰的 Flash),都讓相關問題日益嚴重。雖然目前有很多方法與工具可以幫助服務供應商與使用者解決相關問題,但是因為缺乏共通性的標準而讓整個事情變得很難有效地管理與追蹤。舉例來說,身為一個使用者,你怎麼知道 Gmail 與 Hotmail 哪一個比較安全?好吧,或許 Google 與 Hotmail 本來就各自擁有為數眾多的愛用者,所以這個問題可能不是那麼難回答 (答案對不對是另外一回事)。但是如果今天換成是兩個名不見經傳的小網站,要回答哪一個網站比較安全可就不是那麼容易的事情了。

OWASP 是一個專注於 Web 應用程式安全的非營利性組織,在 2008 年開始推動應用程式安全認證的計畫, 並於 2009 年推出正式的版本,稱之為 OWASP Application Security Verification Standard 2009 (後簡稱 ASVS)。OWASP 是一個中立的組織,所以 ASVS 也不侷限應用在特定的架構或平台之上。不過儘管標準的名稱是 Application Security Verification,但是整個計畫依舊是以 Web 應用程式的安全議題為主。在軟體開發的領域中,Verification 這個動作指的乃是檢查最後的產出 (例如可執行的程式碼) 是否符合當初規範。至於規範本身合不合於實際的應用,乃至於製作過程當中是否有什麼需要改進的作法,則都不屬於 Verification 的範疇。規範本身合用與否,可以透過 User Acceptance Testing 等方式加以確認。而製作過程的合適與否,目前則以 CMMI 這類標準為主。不過 CMMI 是以確保軟體的品質為主要目標,因此 OWASP 提出了另外一個稱之為 Software Assurance Maturity Model (SAMM) 的標準與之對應,SAMM 正是專注於軟體的可靠度 (Assurance)。簡而言之,ASVS 與 CMMI/SAMM 等著重在整體作業流程的標準不同,反倒是比較像 Common Criterion (CC)。

OWASP 希望透過 ASVS 可以提供 Web 應用程式所有相關人員一個共通性的語言,清楚的標示出必須完成哪些安全性的需求。這裡所謂的相關人員,除了我們平常慣稱為甲乙方的直接人員外,也包含了最終的使用者。只是對於最終使用者而言並不需要了解標準的詳細內容,只需知道最後的檢驗結果就足夠了。除此提供共通的語言與標準外,ASVS 還將所有需要檢驗的項目分成 4 個大的層級 (其中兩個層級又各自分成 A、B 兩個子層級),層級越高表示檢驗項目的數量與深度也隨之增加。透過層級的劃分讓相關人員可以評估不同系統之間何者較值得信任,較高的層級往往也就表示更值得信任。ASVS 層級的定義如下:

  • Level 1 Automated Verification
    • Level 1A Dynamic Scan
    • Level 1B Source Code Scan
  • Level 2 Manual Verification
    • Level 2A Penetration Test
    • Level 2B Code Review
  • Level 3 Design Verification
  • Level 4 Internal Verification

由層級的劃分我們可以看到 ASVS 包含利用程式進行自動化的檢驗與人工檢驗這兩種不同的形式,而檢驗的主題除了程式碼之外,也包含(部分的)設計文件。

標準規範對於資訊安全到底是正面抑或負面的影響,至今雖然仍存有很大的爭議,但是不可否認的是唯有透過標準才能夠 (公平地) 量化我們想要了解的項目,而這也是我們想要管理、改進這些項目前最基本也是最重要的一個先決條件。也因此儘管目前採用 ASVS 的組織與專案還是不多,但是網站應用程式安全的檢驗標準依舊是大家值得關注與採行的事項。

沒有留言:

張貼留言

About