Fortify 與 資訊安全
安全是相對 不是絕對
2009年Pwn2Own駭客大賽在溫哥華的CanSecWest會議中舉行，本次駭客大賽主題為「瀏覽器安全」與「手持式系統安全」，參賽者為前美國國安局資訊安全幹員Charlie Miller，另外一位為25歲的德國奧爾登堡大學電腦科學系學生Nils。大賽比賽規則是這樣的：參賽者手上各自有一台全新的電腦，一開始只有作業系統與瀏覽器（如列表所示），不安裝其他plugins。在比賽開始2分鐘內，Charlie Miller就攻陷Safari（Zero-Day Exploits），成功的獲得5,000美金，以及他所使用的全新MacBook。
接著Nils也找出了IE8的漏洞，而且還順手找出Safari與Firefox的漏洞，不但把手上的全新Sony VAIO帶回家，還多領了15,000美金。
當白帽駭客能夠在兩分鐘內成功的解決當時最新版本的IE8，那有多少數量的駭客在我們無法得知的遠端虎視眈眈我們脆弱的系統？
資安專家努力加強防禦工事，讓駭客無法輕易入侵系統。在遇到強大的系統安全機制阻撓，駭客入侵的效益就會降低，大部分的駭客會另覓較簡單的目標。這個現象說明了提高系統安全性的經濟效益，可以用個例子說明：如果在野外遇上了熊，你不必跑贏熊，只要跑得比同伴快就行了。
75%以上的安全漏洞出現在應用程式
早期的資訊安全漏洞多半發生在網路層或通訊網路之中，早期數據機使用的電話線路，到後期Internet流行後，駭客使用省力又有效的方式攻擊受害者（如蠕蟲或DDoS攻擊），這個時期的防禦策略是防火牆，或入侵偵測系統\入侵防禦系統。
應用程式安全的重視並非在今年才特別流行，早在2005年，Gartner Group根據1,000個受訪單位的調查顯示，75%的安全漏洞已經發生在應用程式層，而非我們以往認知的網路層；而NIST（National Institute of Standards and Technology）也發佈相似的調查數據，92%已知的安全漏洞存在於應用程式中，而非網路。
應用程式的攻擊更早可以追溯至1998年「NT Web Technology Vulnerabilities」這篇文章發佈後，應用程式層的攻擊就被駭客或有心人士盯上，成為最近幾年最火紅的攻擊方式。這十年來攻擊手法雖然不斷變化，但是攻擊對象都是相同的，暴露在Internet上，公眾使用最多的Web應用程式。
當攻擊者的攻擊對象轉移，被動的防禦者錯守防禦位置，只會讓組織的資安投入成本更為高昂，沒有對症下藥更是情勢評估與決策上的錯誤。正所謂知己知彼，百戰不殆，就是這個道理。
以滲透測試為主的資安界
若我們想要瞭解網站到底安不安全，首先想到的就是滲透測試！沒錯，滲透測試的確是一個瞭解網站安全程度的好方法。以駭客/入侵者角度、思維或手法，攻擊使用者的系統。這樣的測試方式行之有年，而且資安業界與政府機關也有了相關標準、訓練課程與認證。
倘若您做過滲透測試，您可以在報表上面得到什麼樣的資訊？不外乎網站的弱點數量、種類統計及發生的URL，還有呢？可能會有弱點的概略說明與修復建議。但是我們能從弱點掃瞄的報告上看到哪一支程式有問題？看到我們呼叫的哪一個方法有問題？或是滲透測試能夠指出資料流的路徑與流向嗎？對不起，這些滲透測試都無法做到，因為這已經遠超過滲透測試（所謂黑箱測試）的能耐。
若長官或老闆因為客戶對資安的要求，而要求承辦人評估系統的資訊安全狀況與等級，並附上所謂的「資安證明」好讓客戶放心，承辦人要評估的是進行ISMS的導入，還是請廠商來作滲透測試服務？即便已拿到ISMS，或是做完滲透測試掃出網站弱點，我們的漏洞就可以因此消除？
目前弱點類別第一名：Cross-Site Scripting
不論是OWASP（Open Web Application Security Project）或是CWE（Common Weakness Enumeration），跨網站腳本攻擊（Cross-Site Scripting）都是連續幾年排名第一的弱點類別。
現在絕大部分的網站系統可允許使用者自行輸入資料字串，如留言版或查詢欄位，某些網站功能會將這些資料寫入後端資料庫。當駭客輸入攻擊語法被網站存入資料庫，往後使用者訪視這些頁面，再度撈出這些資料並由網站執行後，會造成不可預期的威脅，如以下例子：
iframe+src%3Dhttp://www.youtube.com/watch_popup?
若駭客在欄位內加上這樣的語法，透過釣魚手法在電子郵件或是部落格上發佈嵌有這個危險字串的網址列，使用者在毫無預警下點選該網址列，成為Cross-Site Scripting的受害者。
Cross-Site Scripting可能造成加密連線（SSL）失效、駭客偷取使用者的cookie、駭客假冒使用者身份，駭客可以存取具有身份控管機制的網站，或是將使用者瀏覽器導向釣魚網站，以獲得帳號密碼等個人資訊，或是將使用者瀏覽器導向惡意網站，安裝惡意後門程式、導致使用者瀏覽器無法正常運作。
為何程式會有問題？
我們來舉一個簡單的例子，在此以Java語言作為範例。
上圖範例程式是一個「非Web介面」的Java程式，使用者輸入的參數（userName與passwd）會從main函式（第4行）進入。如果該程式在動態執行時已經被駭客掌握並獲得控制權，則非常有可能從此輸入攻擊資料（或字串）。所以相對地，query變數（第9行）也可能被污染。
等字串準備好要進入資料庫去查詢時（第12行），在此就形成一個引爆點，若執行了這一行程式碼，受污染的資料就會真正進入資料庫。此外，這支程式還有其他問題，像是Hardcoded Password（第10行），System Information Leak（第21行），都是開發人員一般不會注意的安全問題。
真正問題其實不在網站上
當大家都一窩蜂的開始重視資訊安全，談論哪一家應用程式防火牆（WAF）比較好，哪一家的滲透測試工具比較厲害，哪一個白帽駭客身手矯健可深入系統如入無人之境，當我們把焦點放在錯誤的位置上，真正的問題就無法顯現出來。
還記得我們學習撰寫程式的時候，課堂上的老師滔滔不絕的講授程式該怎麼寫，怎樣寫才是好程式，怎樣寫才會有效率，怎麼作程式碼的測試，程式碼的資料結構開發的一些量化公式。假使上課沒有打瞌睡，每堂課點名都能舉到手，再加上自己的練習，相信都能寫出一手的好程式。但是當有人問，你能寫出「安全」的程式否？這就不是上課不打瞌睡不遲到就可以寫的出來，因為老師根本沒有教授這樣的觀念。
Gary McGraw是在安全開發流程非常具有專精的一位學者與科學家，他提倡在傳統的開發流程中，將資訊安全的檢核點（他稱為Touchpoint）放入。例如在傳統的需求訪談中，我們只會詢問應用程式的範圍、功能/非功能列表、功能/非功能數量概估等等，而在Gary McGraw認為在需求訪談時就必須加入資訊安全要求，比如搭配組織的資安政策等等。
而在架構與功能設計時必須作風險評估，傳統的風險評估的估算方式如下：
傳統的風險評估方式無法明確的指出風險所在的弱點，也不能標示出可能的攻擊者，在目前資安業界所使用的風險評估方式為：
- 列舉要保護的系統範圍，識別出系統重要的資產（assets），並進行重要性排序。
- 瞭解保護的對象與可能的攻擊者，進行威脅塑模（Threat Modeling）。
接著在系統測試計畫裡，要將一般的測試個案化身為考慮資安的測試個案，稱為功能安全測試（Risk Based and Functional Security Testing）。除了原本考量的功能性測試之外，每個測試個案還都必須盡可能將該個案所擁有的功能安全缺失給測試出來。而這樣的Security testing技術包括：
- 身份假扮：試著以非授權者身份進入系統。
- 修改資料：將修改後資料送入系統，或修改簽章雜湊值。
- 記錄竄改：是否可能有記錄檔無法運行的狀況，或被寫入假記錄的狀況？
- 資料揭露：是否能用更高權限帳號使用非授權的資料，或讓應用程式無法執行產生錯誤記錄檔，供駭客查看。
- 拒絕服務：將過多資料餵給process，造成無法服務正常資料。
接下來就是源碼檢測。
源碼檢測可分為人工與自動化。傳統的人工源碼檢測就是以人工方式檢查原始碼，找出程式不合理的邏輯、不一致的命名，或架構編寫不好的地方。人工源碼檢測效率不佳，而且還必須有高素質的人力，通常這部分是開發人員自己執行，或是開發人員相互檢查對方的程式碼，當然，您也可以聘請所謂的「專家」協助，但是這些專家都非常昂貴。有了資訊安全考量後，源碼檢測的水準取決於開發人員的資訊安全能量是否足夠，而足量的資安能力才有辦法讓開發人員真正能「看得出」不安全的程式。訓練一位開發人員的資安觀念必須耗用許多時間，在客戶提出資安要求後才訓練開發人員的資安觀念，其實是緩不濟急。
現在自動化源碼檢測正處於百家爭鳴的戰國時代。自動化源碼檢測效率是人工檢測的1000倍以上，內建安全知識庫，並且可以一年365天無時無刻的運行（人會累阿！）。自動化源碼檢測工具可檢測品質面與安全面的問題，較成熟的自動化源碼檢測工具除了有語意/資料流分析，支援多種語言，多層次分析，對於大型專案程式碼也能游刃有餘。
傳統的滲透測試在程式上線後才進行，這樣的滲透測試結果並不能令人滿意。在SSDLC（Security System Development Life Cycle）架構下，滲透測試（黑箱測試）成為QA測試的一部份，搭配QA測試（動態測試）可以驗證在白箱測試下所得到的結果。
一些有趣的統計數據
IBM內部開發人員發現，在程式測試前就進行源碼檢測，可減少82%的程式碼錯誤；而且在正式環境找到錯誤並修改錯誤的成本，是百倍於在設計時期就找到並修改錯誤。HP的開發人員也發現，80%的程式錯誤不見得在測試階段可以找得出來。在醫學上，「及早發現，盡早治療」是不變的道理，而現在這句話也可以套用在軟體開發。
靜態分析技術
靜態分析技術與計算理論有關，在此並不贅述。而靜態分析起源於Church、Gödel 與Turing 在1930年代的研究成果，而基於Halting Problem與Rice Theorem理論，靜態分析理論才有辦法得以進展。
或許Unix的grep指令就是一種最簡單也最直覺的靜態分析方法。Grep指令的搜尋字串能力，用來對付程式碼最好不過；缺點則是grep並不瞭解他掃瞄的是什麼檔案。註解、字串、宣告與函式呼叫也都只是比對的字元一部份而已。比較好的作法是加入程式語言的語彙規則。這樣做工具可以分辨有風險的函式呼叫。
基本的語彙分析能力已實作在分析工具的先期分析過程，包括ITS4（http://www.cigital.com/its4/）、FlawFinder（www.dwheeler.com/flawfinder/）與RATS（www.securesoftware.com）等工具，將程式碼轉為符記（token，這也是編譯器進行編譯的第一步），再讓符記與弱點函式庫進行比對。更早之前，Matt Bishop與Mike Dilger寫了一支檢查TOCTOU（time-of-check與time-of-use）專用的語彙分析工具。
即使語彙分析工具比grep指令強了很多，但是沒有針對語意進行分析，誤報率很高。將程式碼轉譯為符記比起直接將源碼載入比對引擎要來的好，但是要瞭解程式碼運作仍有一大步要走。有些高安全風險的程式碼辨視度很高，不需要再進行語意分析就可正確判斷，但大部分都不是這麼好判斷。
為了提高精確度，分析工具必須採用許多編譯器的技術，例如將源碼編譯為中間檔（AST、abstract syntax tree）這種語意分析技術就會納入。
有了AST技術，下一步要決定分析範圍。分析範圍分成三種：
- Local analysis一次檢查一個函式，不考慮函式之間的關係。
- Module-level analysis檢查一個類別，或整個編譯單元，所以要考慮同一編譯單元函式之間的關係，但是不檢查跨模組之間的函式關係。
- Global analysis必須分析整支程式，所以必須考慮所有函式之間的關係。上下文的關連性（context）分析也必須在分析範圍裡決定。若要減少誤判，要檢查的上下文關連性範圍勢必變大，但是得花很多計算時間。
Fortify的資料流分析技術
Fortify SCA引入了類似taint mode的概念，工具會以污染標示元（taint flag）自動標示出受污染的變數源，稱為Source，這個污染源通常是網頁的輸入或是程式參數輸入點，變數經過一連串的傳遞，到達可能會引發真正安全風險的函式呼叫，稱為Sink，也就是事件的引爆點。
我們以之前的程式碼為例，在程式的起始點main就被工具視為一個受污染的變數源Source，而第12行被視為可能會引發安全風險的函式呼叫，則是Sink。這樣的安全風險解決方式為，撰寫一支檢查輸入變數值的函式，檢查邏輯可依據該變數屬性撰寫（如變數為使用者名稱，就應該檢查該變數長度，或是做黑名單的篩選）。
成熟的掃瞄工具設計
軟體工具最先映入眼簾的就是使用者介面。一個成熟的源碼檢測工具除了給專業人員使用外，一般不太懂資安的稽核人員或是承辦人員也應該可以輕鬆上手。Fortify SCA的使用者介面非常的簡單易懂，最左上角就是掃瞄結果風險分類，以顏色和數值標明，並且有多種風險弱點分類方式，使用者可依需求使用不同的分類方式方便查找風險弱點。
- Fortify SCA可掃瞄17種語言，並且可以支援多種平台（Windows/Unix/Linux/MAC），以單一語言來說，Fortify SCA的購置成本相對非常的低。
- 對於多層次的系統架構，Fortify SCA亦遊刃有餘，以Fortify 最自豪的X-Tier分析技術，從前端網頁，中間層的商業邏輯，到後端的資料庫語法，Fortify SCA可串起資料流程並加以分析。
- Fortify SCA具有大型專案的處理能力，美國知名銀行Wells Fargo擁有10,000名以上開發人員，掃瞄的可執行程式碼超過7,500萬行，Fortify確實地保護該銀行的資訊安全。
- 客製化彈性大。可依據組織或個人需求彈性設定安全政策、報表、分析條件與安全規則，可在組織內部間不同部門分享設定，減少重工。
- Fortify SCA具備全中文（台灣）的問題說明與修復建議，可作為開發人員的資訊安全學習平台。
- 內建稽核機制。工具能找出安全風險漏洞並不足夠，能完整且有效的稽核才是王道！Fortify SCA的稽核機制可以協助組織精準追蹤風險弱點問題。
- 完整的擴充性。可與Fortify 360 Server整合，在多人多專案組織內，稽核人員或主管人員可指派問題給開發人員。Fortify 360 Server可統計並展現專案的各項數據與趨勢資料，對於主管人員掌握專案進度與趨勢非常有幫助。
軟體安全成熟度評量
在源碼掃瞄技術面逐漸成熟之際，軟體安全成熟度也是目前正火紅的管理議題。在推動資安最不遺餘力的美國，軟體安全成熟度的評量機制與架構正逐漸成型。相較之下，軟體安全從技術面著手是治標，而治本的方式則要從管理面著手，因應組織的文化與內部管理流程，這就不是只有IT或稽核部門單方面參與就足夠。
資訊安全應該從單一專案或系統提升為整個企業或組織都應該考慮或是參與的議題，組織投入資訊安全是一件花錢的事，量化安全的評量標準並不容易，軟體安全成熟度評量可協助組織瞭解目前內部軟體安全程度，瞭解組織運作的內部流程的改善空間，評估應投入多少資源協助修補該漏洞，開發更成熟的軟體。
OpenSAMM（Security Assurance Maturity Model）是OWASP眾多計畫其中一個子計畫，目的是讓開發人員與管理者有一個類似CMMI軟體成熟度一般的依循標準，衡量自己開發的軟體是不是在安全度上已臻成熟。
BSIMM（Building Security In Maturity Model）則是廣泛訪問業界知名9家廠商廠商，如EMC、Adobe、Google、Wells Fargo、QUALCOMM、DTCC與微軟等，從中吸取許多軟體安全領域的經驗與教訓建構出來的，包含著許多活動（activity）的安全框架（Security Framework），這些活動提供組織依循的標準（guideline）。不論是OpenSAMM或是BSIMM，背後都隱藏了Fortify點滴的心血。
在Fortify 360產品中，更加入了依據業界的Best Practice的SSA（Software Security Assurance）模組，依據組織內部的軟體專案調查結果，提供內建的風險評估機制與專案流程控管機制，使得組織能有系統的監控組織安全政策或專案執行活動的狀態與過程，並且內建相關的表格或是文件供組織參考使用。
縱深防禦的資安觀念
新一代的資訊安全並非在網路入口擺上幾台入侵偵測系統或是防火牆就能滿足，面對不斷進化的入侵者與駭客，使用者的防禦觀念也必須跟上時代。Fortify從技術面的軟體安全開發生命週期，到管理面的軟體安全成熟度評量，都有業界淬煉出來的最佳範例，可成為組織資訊安全的最佳後盾。