GSS 資安電子報0024期【開放源碼的安全研究(上)】

研究摘要

超過百分之五十以上的企業都有使用開放源碼的經驗，而且成長的速度非常快。這一趨勢，基本上被許多IT和商界領袖假設：某些開源碼在功能與擴展性方面已達到企業等級了。但它安全嗎?開放源碼伴隨著引入了多少的商業風險呢?

作為提供軟體安全保證的產品供應商－Fortify經常被捲入這個問題爭論的中心。利用Fortify產品來辨識開放源碼軟體的弱點說明著該軟體的風險存在著，Fortfiy已嘗試藉著分享給開放源碼社群弱點報告來降低開放源碼的風險；然而，風險依然存在。為了弄清楚開放源碼抗拒資訊安全方面的議題，Fortify也研究調查了開源社群。我們的研究單位已經發現開放源碼專案缺乏安全的三個要素：人(People)、流程(Process)與技術(Technology)，由此，會引起重大的應用軟體安全風險。研究顯示許多的開放源碼專案失敗的原因：

  1. 提供安全技能知識管道

很少開放源碼專案提供有關開發中安全義涵和安全部署的文件，而且沒有給予使用者一個回報安全漏洞的專門郵件，或者一個可以很簡單跟其內部安全專家討論安全問題的溝通管道。

  1. 採用安全開發流程

我們掃描的專案裡，沒有一個例外，皆有重大的安全問題，但幾乎所有的專案安全問題一直持續存在著，只有一個專案有在修正安全問題，甚至有的專案在新的版本出現更多的安全問題。這顯示專案本身並未採用一個成功的安全開發流程方法。

  1. 利用技術來發現安全漏洞

著名的安全漏洞，例如：Cross-Site Scripting(XSS)以及SQL Injection，其實都是一般很常見且已知的很嚴重的問題，而且早被OWASP列入了。這些類漏洞可以通過參加免費的Fortify Java Open Review (JOR)專案計劃或其它的安全開放源碼產品，例如：FindBugs，很輕易地取得該資訊。這表示這些專案並未好好地利用技術去解決與發現這些安全問題。

這些發現可以提供一些倚賴開放源碼軟體的組織一個號召性的行動方案。Fortify特別地建議底下方案：

  • 政府和商業機構，利用開放源碼應用程式時應該十分謹慎。關鍵業務的開源專案應該要進行風險分析和源碼審查（Code Review），而且這些程序應在新版的開源元件審核通過前都要持續進行。
  • 開放源碼的專案應該從他們的商業對手中學習採取強而有力的安全做法。開放源碼的開發可以從一般私有企業做法中而受益──特別是那些金融服務機構和大型獨立軟體廠商(ISV)。開放源碼社群就可以證明與宣傳結合流程與技術的有效的安全做法。

介紹

Fortify最近進行了一項研究，旨在更好地瞭解流行的開放源碼專案的整體安全性和其發展過程中安全的角色。這項工作的動機是：

  1. 企業採用開放源碼快速地增長
  2. CIO.com在2008年4月時說明當時超過一半(53%)的回應者表示他們的企業正在使用開發源碼的應用程式，而且還有其它10%的企業將於下一年開始也採用。將近一半(44%)的企業認為開放源碼的程式應該與封閉源碼的方案採取相同的收購程序。
  3. 歐盟競爭委員會的專員(European Commission’s Competition Commissioner)Neelie Kroes說，比起封閉源碼軟體，一般企業更喜好開放標準、開放源碼。

資安專家一直尋找在同時運用這兩種技術之下，可以達到(1)讓測試更完整，涵蓋率更高(2)更佳的問題優先權結果(3)降低修正弱點的時間與成本的目標。同時使用這兩種技術的主要困難點在於如何有效率地在測試下，找出在特殊情況下應用程式行為的連結。解除這種連結，組織可以聚焦在大部分關鍵程序的安全性問題，開發者可以更有效率地找出根本原因進行程式修正。

  1. 大量攻擊應用層的資安事件
  2. 今日的攻擊正在走向應用軟體。Gartner的報告中表示百分之75的駭客攻擊是在應用層。
  3. 美國空軍發現應用層的攻擊從2004年的2%成長到2006年的33%。

Fortify透過改善軟體開發流程，持續與世界各地的組織致力於商業軟體(品質/安全)保證(Business Software Assurance)。幾年前，這僅限於軟體專家，這通常包括全球金融服務和軍事相關機構。今日，我們正在目睹一個現象：無論大與小以及廣泛的各行各業大量地跨組織的採用安全開發的實踐方法。這種廣泛地採用安全流程的做法，將有助於提高標準的安全性。它不再是可以被企業接受忽略開放源碼軟體所引進的風險，也不會針對開放源碼專案而忽略開發流程中安全所應扮演的重要角色。

研究方法論

這些專案在這項研究中被挑選出來的原因：它們是用Java語言實作（Java是企業開發中最普遍的程式語言），並且表示了有廣泛被應用的功能，此外，還被大量地建構與佈署至企業的應用軟體中。免費軟體(Freeware)不是開放源碼。表1列出了一些在這個研究裡的專案以及它的用途。

表1 研究中的專案

Fortify SCA產品依安全角度方式進行每個專案2到4個版本的靜態分析。程式碼與操作的安全敏感區域常常與安全弱點息息相關，例如：資料庫查詢以及動態使用者介面的元素，必須被手動檢視來確保與Fortify所找到的問題一致。Fortify SCA發現的重大安全問題也必須被手動驗證其正確性。Fortify SCA將找到的問題分類為Critical、High、Medium以及Low群組。由於大量的問題被歸納為Medium與Low類別，此篇文章將僅含括High以上的問題。根據負責披露準則，本報告不包括任何詳細的漏洞訊息。

Gartner分析師John Pescatore發現，「摧毀遠比鞏固得牢不可破更加容易」。在現有的程式碼查找和解決安全弱點，進一步必要的措施，則必須輔之以有效的安全流程，真正產生影響力。為了評估開放源碼組織提供給他們用戶的安全專業，以及評量置入強化軟體安全的開發流程，Fortify跟開放源碼的維護者互動並且檢查記錄開放源碼的安全實踐文件。

主要的發現

當Fortify的Java Open Review(JOR)專案剛開始啟動時，它發開源碼現數以百計各式各樣的弱點或漏洞。我們隨後的審查幾個額外的程式碼後，發現許多應用程式漏洞的嚴重安全威脅來自一個很糟或者根本沒有安全的流程。這個後續的調查發現，安全的最佳實踐通常是來自於低優先級的開放源碼專案社群。然而，開放源碼軟體經常聲稱具有企業級功能，但卻不採納或考量採用企業級的最佳安全實踐(Security Practice)。

僅有一些少數的開放源碼的開發團隊正朝著正確的方向前進。比如，2008年7月的Mozilla宣佈一項安全的行動方案來改善瀏覽器的安全，雇用Rich Mogul為獨立的安全顧問。這個行動成為所有開放源碼社群的一個好榜樣。

因此，雖然一些開放源碼軟體可以理所當然地擁有強大的安全團隊和堅實的開發的實踐做法，很多仍缺乏人員、流程與技術等方面將安全作對。下節概述了支持這一結論的證據。

  1. 失敗於安全技能知識的提供

我們找到了三個安全資源，開放源碼的用戶可以依靠：包含安全義涵和軟體安全部署的文件，一個專屬且可以回報安全漏洞的電郵，或是一個可以輕鬆與內部安全專家討論安全議題的管道。我們發現非常少開放源碼專案提供這些資源，這些資源被匯總在表2內。

表2:安全技能知識管道

2005年Gartner發起了一個以軟體安全為核心的安全流程：「應用程式的管理者與測試部門必須樂意從員工內找出安全專員，並且投資指導每一個團隊在認知與流程方面的教育訓練課程。」同樣的方法應適用於開放源碼。這些資源顯示著一個組織內發展的安全知識水準，專案人員對於開放源碼專案很少能洞察安全實踐的貧乏狀態，以及當遇到安全相關問題時，是否能追查求援。

我們不能過分強調一個專屬的安全專家的重要性。安全，不像品質，需要一個獨特的眼光。安全專案Bruce Schneier在他的部落格中表示「安全需要一個特別的心態…『安全專家』沒有想出如何投兩次票前，不會投下任何一票。」

…下期待續

上一篇 下一篇