GSS 資安電子報0003期【實現軟體安全的七個實用步驟 】

摘要

軟體安全是一個嚴肅的問題,並已逐漸受到關注。然而,讓應用程式更安全的方法相對而言並不成熟。你應該從哪裡開始?本文將提供企業今天就可以開始的七個實用步驟。

  1. 快速評估軟體安全的現狀,並為此制定一個貫穿整個開發生命週期的計畫。
  2. 詳細描述軟體所面臨的風險和威脅,以便在他們引入前就被消除。
  3. 在程式的開發階段就對新公布的安全漏洞進行程式碼審核。
  4. 測試以及驗證程式碼的安全漏洞。
  5. 建立一個門檻,以防止帶有漏洞的應用程式進入正式產品。
  6. 衡量安全計畫是否成功,以便不斷精進流程。
  7. 教育安全相關人員,讓他們能夠實施安全計畫。

任何開發組織都可以實施此一安全計畫,並在最小的時段內收到努力的回報。關鍵在於:「從現在開始」。

越來越多的組織賦予軟體安全以一個優先權。下面這七個步驟可以作為入門準則。

交付更安全的程式碼:七個步驟

如今沒有一個在IT環境中工作的人可以逃脫駭客的攻擊。蠕蟲、個人資料入侵、以及其他一些攻擊方法呈增長趨勢。這些攻擊所利用的是從作業系統到商業應用軟體上的特定漏洞。基於這個原因,應用程式開發團隊越來越關注這個問題。業界開始捫心自問如何才能構建更安全的軟體。
「軟體安全」的目的是讓應用程式更為安全。它在今天仍是一個非常新的領域,而且大部分的論述重點是在「理論」而非「實踐」。因此,解決軟體安全問題首重彌補「學理上概念」以及「真實軟體開發情形」兩者間的鴻溝。真實軟體開發的情況是:設定最後期限、提供功能、避免品質瑕疵。
越來越多的組織賦予軟體安全更高優先權。這些組織已經發現起步的關鍵在於選擇少數能夠產生開始改善迴圈效果的實踐活動。這些活動可以是單純的單一“門檻”或是軟體發展生命週期(SDLC)的每一步上的一系列小任務。不過,該方法說起來容易做起來難。來自內部抵制改變的抗拒可能大到導致計畫癱瘓,原因通常是在任何步驟中,「安全」都沒有被充分處理說明;設計、開發、測試、生產都沒有被充分處理。

本文的目的在於提供使組織可以交付更安全軟體的七個實用步驟,這些步驟側重“實用”。這些行動是每個人今天就可以採取的。雖然這些步驟可能會無法立即呈現巨大的效果,但在短期內它們會產生一個可量化的結果。關鍵是:「立即開始」。

步驟1 :快速評估和計畫

第一步是評估你所在組織的軟體安全現狀,並制訂一個計畫,決定有哪些額外步驟需要進行。這個評估和計畫並不需要全面的、多月的努力。最好的開始是創建一個簡單的行動列表,包括為解決安全問題當前所採取的行動和你希望執行的活動。例如,表1] 表示了一個專案的所有軟體安全準備活動,並提供了一個衡量的尺度。
「計畫」-- 無論是簡要或短期,能在組織內部獲得支持是至關重要的。實際上,你的第一個計畫可能需要一個“原理上的證明”,讓你可以在獲得積極的成果後建立一個更徹底、更大膽的計畫。無論你採用什麼方法,計畫應包括3個方面的元素:
(1)圍繞每一個軟體發展專案的軟體安全基礎結構;(2)每個專案小組所選擇進行的明確安全活動;(3)你將如何管理已發現的漏洞。[表2]提供了一個計畫要素的例子。在本頁剩餘部分中簡述的步驟對任何計畫而言都是極好的組成部分——因此,你也許想從這裏開始。

威脅分析協助您避免設計上的安全錯誤,並且針對最有可能的攻擊目標加強程式碼稽核以及安全測試

[表1] 評估

有內部安全專家並已標識

1 2 3 4 5

完成每個專案的威脅分析

12 3 4 5

定期的安全教育計畫

1 2 34 5

已獲得並分配了明確的工具和資源

1 23 4 5

開發完成後的安全與總體過程相結合

1 2 3 4 5

從漏洞回應中最大化獲益並防止重複

1 2 3 4 5

[表2] 計畫要素

指派安全專家或專案負責人

誰:為每個個體分配任務和角色

問題將如何被跟蹤和報告

支援步驟的自動化工具

什麼:列出步驟以及每個步驟成功的標準

在報告安全缺陷上採用的用於分類、確定優先順序和所採取行動的團隊規程

過程清單和必要條件

時間:包括在專案期限中的步驟和活動

 

步驟2 :詳細描述軟體所面臨的風險和威脅

安全是用於降低風險的。存儲客戶個人資訊的軟體應用程式會比進行會議室日程安排的內部應用程式更為敏感。因此,類似你如何列出你的團隊能力以構建更安全的軟體,您應該一一確定各軟體的風險,以及其所對應的安全威脅。

風險分析本身即自成一個領域,而且能夠在類似微軟的STRIDE的商業解決方案和NIST的ASSET的方法中應用。雖然實施方法各有不同,但這些方法通常有詳細的步驟並包括所投入的時間。

威脅分析是一種比全面風險分析更簡單的技術,它針對一個應用程式考慮威脅。威脅分析協助您避免設計上的安全錯誤,並且針對程式最脆弱的環節加強程式碼稽核以及安全測試。因此,你應該將此步驟視為你能採取的最重要的一步。

一個簡單的威脅分析可以分成兩個階段。第一階段確定應用程式必須保護的資產以及評估哪些資產是最重要的。這項工作有些棘手,因為有的資產可能會比其他的資產更加顯而易見、而資產的性質也會因應用程式的不同而不同。資產的例子包括個人資訊的記錄,如信用卡號碼,雇員/客戶記錄,或財務數位等;另一個例子包括組織間傳遞的資源,如電子商務解決方案、法人Web網站、為客戶提供支援的電子郵件;還有一些是類似公司信譽的無形資產,例如一個違背安全的事件將對公司的信譽造成什麼樣的影響。

一個簡單的威脅分析可以分成兩個階段。第一階段確定應用程式必須保護的資產以及評估哪些資產是最重要的。第二階段包括瞭解應用程式本身以及瞭解來自攻擊者的威脅。

威脅分析的第二階段包括瞭解應用程式本身以及瞭解來自攻擊者的威脅。組織應開發一個關於應用程式元件和資料流程路徑的高階模型。將應用程式面臨攻擊的層面做對應、識別使用者輸入的介面,以及識別應用程式與其他系統間的接界點。

專案團隊應該關注攻擊面上的任何危及資產完整性、可用性,機密性的攻擊點。最後,基於受影響的資產重要性和被攻擊的可能性,對威脅進行分級。這種威脅分析工作,雖然比全面風險分析簡單,但可能需要一個關於應用程式和駭客工作方法的高水準的專家意見。不過,這並不需要精確,並且功效可能強大,因為它集中所有精力在重要領域並沒有浪費大量能量。當然,即使是最徹底的威脅分析也不可能阻止在開發過程中造成安全漏洞,這就是我們要進行步驟3的原因。

程式碼審查和稽核是確保安全的關鍵。由於現今應用程式本身龐大以及複雜,「自動化」是達到全面性分析的重要關鍵。

步驟3 :程式碼審查

一個組織應在建置和測試階段審查程式碼,以減少可能在開發階段便會造成的安全漏洞。在多數情況下,這樣的審查會發現大量的安全漏洞,這些有安全漏洞的程式有可能要上線使用了。同時,再加上威脅分析,組織可以將審查作為根據,確認軟體沒有他們最擔心受威脅的安全漏洞。

今天許多團體依靠人工程式碼審查來執行此步驟。但是,人工審查需要豐富的安全專業知識和巨大的時間投入。所幸的是,關於開發者如何造成應用系統的安全漏洞,已有一個一致的並良好定義的研究模型,此為精確、自動化的安全性分析工具提供了一個基礎。最好的程式碼分析工具可以在一個應用程式中評估多個層次並能深入跟蹤資料流程。它們工作的範圍包括從小到大的程式碼,並有效地提出和管理其結果,使審核人員可以快速識別和優先考慮潛在的安全缺陷。

像Microsoft Visual DevStudio和Eclipse這種嵌入在開發環境中的安全程式碼分析工具,能夠作為針對開發者的基本的和正在使用的訓練工具。這些工具在當錯誤被發現的時候便提供回饋資訊,如此可降低修復成本,以及強化學習經驗。

以下列出高效能的自動安全程式碼工具所需的關鍵能力:
•大量、全面識別的漏洞類型
•有能力執行不同的分析,如全部的資料流程,控制流和設定檔分析,以減少誤報
•有能力針對跨應用程式分析,以便找到人工審查永遠無法發現的漏洞
•對分析結果提供多重過濾,查詢,排序選項
•支援您的開發團隊使用的所有語言
•可擴展性,以便執行特定的安全程式撰寫政策
•支援IDE環境的Plug-in,可直接在程式開發人員的電腦進行分析。

應用程式的滲透測試是最常使用,也是最濫用的。然而它是活躍在軟體安全領域的方法。安全測試不應該僅限於尋找安全漏洞,而是應該確認:在程式碼審查階段,發現的漏洞就應被清除。

步驟4 :測試和驗證程式碼

組織除了進行功能測試和正確性測試之外,還應該對程式碼的安全缺陷進行測試。「測試」是「程式碼審核」的互補技術,也是安全軟體發展生命週期的最終檢查階段。「測試」也可以透過自動化技術協助進行。

這裏需要警告的是:傳統的功能測試在尋找安全漏洞上是無效的。軟體品質測試歷來側重於確認功能正常,這些功能是被合理且具體的需求或期望的用戶行為所定義。「安全測試」需要不同的思維方法和做法。

一種常見的辦法是對應用程式進行滲透性測試。滲透性測試的目的是模擬軟體的攻擊以發現異常的行為。與程式碼審查一樣,這些測試可以手工執行或採用自動化的工具來執行。類似於程式碼分析,人工的滲透測試有能力發現那些用其他方法無法發現的複雜問題。然而,所需要的技能、專門知識和時間在大多數組織中是不具備的。

自動化滲透測試或應用程式掃瞄工具是當今用來維護軟體安全的常見方法。這些第一代的滲透測試工具常見的是使用「盲目」測試,亦即,透過攻擊Web應用程式的輸入點,然後再觀察攻擊後的癥狀。因此,這樣的測試常常沒有測試微小的程式漏洞,或者漏失真正駭客可能攻擊的程式進入點。此外,滲透測試覆蓋率(在滲透測試過程真正被測試的比率)常常過低。基於這些原因,應用程式滲透測試常由擁有必要知識與技巧的安全專家執行,以獲得測試功效。

最近,在自動化軟體安全測試工具方面已經有所進步。這樣的技術將「白箱測試」與「黑箱測試」整合,而且可與現有的QA測試流程結合。這樣的工具不僅利用了現有的功能測試,同時也使用了原始碼稽核的結果,對應用程式的漏洞提供根源的原因說明。

軟體安全測試已逐漸獲得重視,並視為達到安全軟體目標的一個關鍵元素。然而,企業不應該單純將安全測試視為發掘程式漏洞的唯一方法。相反地,安全測試應該被視為達到軟體安全整體目標的一個關鍵元素。

在開發過程中,取得實效的最根本的,以及可以說是最好的方法就是要落實安全“門檻”。

步驟5 :建立一個安全門檻

讓流程啟動以及取得實效,最根本的,或可以說是最佳途徑,是建設一個安全「門檻」。許多組織在軟體完成測試,但在發佈運營前或生產前,建立一個單一的門檻。這“最後檢查”的一關有一個好處,就是它是在軟體在發佈前進行簡單的推斷並提高安全問題的可見性。 一個不好的情況是在開發週期中的進度滯後,以至於沒有充足的時間來修正代碼中的安全缺陷。

顯然,一個關鍵的問題是:什麼樣的準則將被用來作為判斷軟體是否通過門檻里程碑的依據。因為基礎物品是該軟體本身,一種實用的標準將是審查程式碼。一個程式碼審查門檻——無論它是在現行的開發、測試,或將軟體作為產品發佈前的最後檢查,通常會發現大量的安全漏洞。

隨者組織安全開發過程成熟,標準可以擴大到需要完成的具體步驟細節和發現問題的補救措施;如完成威脅分析、完成程式碼審查並且修復已發現的問題、安全測試已經完成、沒有發現其他嚴重的漏洞、輕微的漏洞已修正。在宣佈應用程式進入“生產準備”前,更嚴格的門檻可能還包含一個通過獨立安全專家進行的專門的安全審查。

步驟6 :衡量

組織應對其安全活動的成果進行衡量,以使方法得以提升,並滿足持續變化的需求。作為在那個領域判斷活動有效性的指標,軟體安全依然是一個新興領域。然而,許多活動可以並且應該被衡量,以便組織和專案組瞭解軟體安全狀況。組織可以衡量開發人員安全流程在設計階段是否遵照原則,也可以衡量安全流程在建置過程成功的程度。

例如,微軟是對版本發佈的頭12個月裏的安全公告進行計數來衡量SDLC的效果(見圖2)。微軟的衡量標準是一個滯後的衡量標準,在開發期間採取的衡量可以在部署前提供充足的時間來對軟體漏洞進行補救。這些衡量標準包括跟蹤衡量指標,如按漏洞類別分類所發現的漏洞、按嚴重性分類發現的漏洞,以及全部時間所發現的漏洞數目。例如,某個專案的緩衝區溢位漏洞或SQL Injection錯誤的頻率比另一個專案高,這代表我們找到需要進行額外學習的程式開發者。審查覆蓋率及歷史資料、漏洞隨時間的轉變數據、甚至複合風險衡量都是可行的。

關鍵是在開發期間儘早收集資料,以建立基準線。

不要指望一個沒有必備的知識和技能的團體能夠通過“測試”。為您的特殊的情況尋找最優方法。


圖2


圖3


圖4

步驟7 :教育

在決定了什麼樣的安全衡量計畫將實施後,最關鍵的問題是教育軟體安全的相關人員,使他們能夠有效地執行安全活動。即使通過教育訓練,開發者也不太可能成為安全專家,因為他們還有其他緊迫的責任。通常,一些小組或選定的個人必須分配以安全“訓練者”的角色。他們可能是那些對安全有興趣的個人,也可能是在安全方面經過特殊訓練的個人,或是滿足該角色的明確聘用的個人。這些專家將從頭到尾負責執行安全計畫,並且他們對計畫的成功是至關重要的。

然而,安全專家的存在並不能減輕其他人的安全責任。組織內的每個成員都負有安全責任。沒有充分參與,任何安全計畫都不可能取得成功。但是,由於個人不能對他們所不懂的東西負責,因此,教育訓練至關重要。

建議派遣開發生命週期的關鍵人員去參加教育訓練,或請安全專家提供現場培訓。培訓所花費的金錢和時間的投入將會物有所值。

教育訓練的目標是使開發團隊的每個成員都有安全意識。每個人在設計功能、提出構架或者是編寫一行代碼時,都應該思考什麼可能導致漏洞。每人都應該問:“攻擊者將會如何利用我所做的呢?”。如果在每一步,每個人都在思索什麼可能出錯,那麼安全將得到提高。

總 結

軟體安全是一個嚴肅的問題。為減輕風險,軟體開發團隊必須將安全作為整個軟體發展生命週期每一步的組成部分。開發團隊可以利用一種實用的、由七個步驟所組成的計畫去提供更安全的軟體:

  1. 評估軟體安全的現狀並創建一個貫徹整個開發生命週期的計畫
  2. 詳細說明軟體面臨的風險和威脅,讓它們在被正式上線前就能被清除
  3. 建立一個門檻,以防止存有漏洞的軟體正式上線
  4. 審查程式原始碼以避免在開發過程中引入安全漏洞
  5. 對程式碼的漏洞進行測試
  6. 衡量安全計畫是否成功,讓整個流程可持續改進
  7. 對與安全相關的人員進行教育,協助其執行安全計畫

任何一個企業都可以實施這一安全計畫,並在極短的時間內開始,也可獲得他們努力的回報。關鍵是:從現在開始。

參考資料

Gary McGraw. Software Security: Building Security In. Addison-Wesley, 2006; and Michael Howard and Steve Lipner. The Security Development Lifecycle. Microsoft Press, 2006. Further background and information can also be found in the IEEE Security & Privacy editorial titled “Building Security In” guest edited by D. Gary McGraw. Specifically, this editorial provides additional discussion on source code analysis (May/June 2006)

Fortify — 軟體安全的根源

Fortify Software產品可保護組織免於因關鍵應用軟體存在安全問題而導致威脅。Fortify產品已獲領先的軟體公司和Fortune前500大的IT組織使用。
Fortify已發展出領先業界、正在申請專利中的技術,該技術從內到外的將安全引入到軟體應用程式中,使安全成為軟體固有的本質,藉由在部署前消除應用程式中的漏洞,應用程式可保護自己免受攻擊。你可以通過訪問 www.fortify.com 以進一步瞭解Fortify以及它的軟體安全產品。