Fortify RTA 簡介及與Web Application Firewall 之比較
"我和Fortify公司實際上並沒有什麼特別的關係，但是Fortify軟體看起來的確十分有趣。它是解決目前網站安全問題方面的一個比較聰明的解決方案" －OWASP創辦人
Fortify RTA（Real-Time Analyzer）可以說是多年來解決Web Security的一個創新解決方案，它的主要功能是讓企業的網站應用程式能夠抵擋駭客的攻擊行為，譬如SQL injection、跨網站腳本攻擊（cross site scripting）、跨網站請求偽造（cross-site request forgery, CSRF）、身份盜用詐欺（fraud）、以及異常存取（abnormal access）等，而這些攻擊是防火牆、入侵偵測系統、以及應用層防火牆等傳統資安設備所窮於應付的。Fortify RTA運用了創新的技術，讓其辨識網站攻擊的能力較傳統的資安設備更為準確及有效率。本文將介紹Fortify RTA的原理，同時比較其與WAF（Web Application Firewall）功能上的差異。
Fortify RTA創新的關鍵–將保護措施運作在網站應用程式之「內」
傳統資安防護設備的運作模式，是「保護者」與「受保護者」相互獨立，然而Fortify RTA突破了這項思維，將保護者（Fortify RTA）與被保護者（網站應用程式）整合為一。Fortify RTA本身是一個純軟體解決方案，它透過一種稱作「安全強化」（instrument）的程序，先分析受保護網站程式的ByteCode，並在分析過程中找出受保護應用程式的關鍵API（Application Program Interface），然後再一一在這些關鍵的API前插入Fortify所獨有的保護程式碼。這些關鍵API往往就是駭客攻擊的網站程式關鍵出入點，像是駭客攻擊的進入點（譬如供使用者輸入資料的網頁表單）、駭客攻擊的目標點（譬如網站資料庫）以及駭客攻擊呈現點（譬如網頁資料輸出）等等。此外，Fortify RTA在應用程式作安全強化的過程完全不需要受保護程式的原始程式碼，僅需受保護程式的ByteCode。
Fortify RTA為網站應用程式的各關鍵出入口把關
以圖一為例，某Web應用程式有以下8類關鍵的程式出入點：
1. 透過Internet HTTP/HTTPS通訊協定進入的Web網站入口
2. Partner應用程式輸入點
3. 檔案系統輸入點
4. 其他輸入點
5. 檔案系統輸出點
6. Web Services輸出點
7. 資料庫輸出點
8. 網路輸出點
Fortify RTA在對該網站應用程式的ByteCode完成API分析及安全強化（instrument）的工作之後，便在上述8類關鍵出入點進行把關的工作。如此Fortify RTA偵測入侵行為的依據是分析網站程式的商業邏輯，來發掘可疑的攻擊行為。這樣運作的優點是直接、分析針對性強，並可大幅提昇攻擊判斷的準確度。
相對地，由於WAF及其所保護網站應用程式分別是獨立的個體，因此WAF僅能在網站入口處進行檢查（如圖二），其偵測入侵行為依據是透過解析複雜的HTTP通訊協定，然後再透過當網路資料通過WAF時所得的非常有限的前後文範疇（context），來判斷進出的資料是否真正的惡意攻擊，或是一般正常資料。這樣的傳統分析模式彈性較差，且容易有誤判或漏判的情形發生。
Fortify RTA與Web Application Firewall之比較
一、SQL injection攻擊偵測能力比較
Fortify RTA的獨有運作架構讓Fortify RTA較WAF在偵測SQL injection攻擊上擁有更準確的判斷能力。由於SQL Injection攻擊是屬於專門針對資料庫的攻擊，Fortify RTA的作法則是專門在資料庫的API，也就是圖一的(7)，前面把關，而且當SQL指令準備藉由(7)進入資料庫前，指令已透過應用程式解析為完整的SQL指令，此時Fortify可以精準無比地判斷將要進入資料庫的SQL指令是否為SQL injection攻擊，並予以適時攔截。
由於WAF僅能在網站的HTTP/HTTPS入口處檢查，會發生以下兩個情形：
1. 誤判（false positive）：當疑似SQL injection字元進入時，譬如：搜尋名為SELECT的產品；透過表單上傳名為UPDATE.doc的檔案；地址中含有「‘」的符號，但目的不是資料庫(7)，而是檔案系統(5)，此時可能會有誤判的情形。WAF需要經過調校學習期，才能逐漸減少誤判的發生。若應用程式經過修改，WAF可能需要再調校。
2. 漏判（false negative）：若網站入口處的資料經過編碼傳輸、網站資料經過gzip壓縮傳輸、或者資料由其他入口處進入，但目的卻是資料庫，此時可能造成WAF的漏判。
二、SSL支援能力比較
由於Fortify RTA在受保護的網站程式「內部」運作，當透過SSL所加密的資料在進入網站程式時，資料就已經解密為明文。因此Fortify RTA的整個部署過程完全不需要因為支援SSL而作任何變動。此外，Fortify RTA的運作效能絲毫不會因為支援SSL而受影響。
WAF設備傳統上是安裝在資料進入網站程式前。為了要能解析經SSL加密後的資料內容，WAF需要先扮演SSL傳輸的一個端點，將SSL傳輸解密後，再將資料傳送至網站應用程式。這樣的運作機制會影響網站的運作效能；此外，當需保護的網站數量增多時，網路管理者需要同時為眾多的WAF設備以及Web Server管理其所搭配的SSL認證（certificates），會增加管理複雜。傳統上，「支援SSL」一直是企業建置WAF時所遇的頭痛問題之一。
三、外部認證機制支援比較
有些網站的認證需要透過外部的認證機制，這對於Fortify RTA可以說幾乎沒有任何影響，原因是這些認證機制在網站外部運作，而Fortify RTA在網站內部運作。某些WAF設備僅支援少數的外部認證機制。若WAF需要支援外部認證機制，此時WAF必須扮演代理人（proxy）的角色來處理外部認證流程，這會影響使用者認證的流程速度。
四、攻擊回應能力比較
除了傳統的攔截（block）、紀錄（log）、警告（alert）外，Fortify RTA還可讓網管者客製化當網站遇到可疑攻擊時的回應，並可幾乎套用網站程式的所有商業邏輯。譬如，當Fortify RTA發現可疑的信用卡交易時，可以客製化回應一個網頁，詢問客戶的聯絡電話，作為第二層安全機制。
WAF在與商業邏輯API整合的客製化能力十分有限，一般僅提供網頁轉向（page redirects）以及http回應程式碼（http response code）功能。
五、支援HTTP通訊以外協定能力比較
由於Fortify RTA在網站程式內部運作，與網路傳輸協定、傳輸過程是否加密、編碼、壓縮無關，因此可以支援所有的通訊協定，也支援任何專屬通訊協定（proprietary protocol）。WAF傳統上僅支援HTTP以及XML over HTTP通訊協定，對於透過其他通訊協定傳送的資料，基本上不在其保護範圍。
六、延伸API整合比較
Fortify RTA內建一個特殊的引擎，可將它自己與保護的應用程式以及商業邏輯整合。客製化的Java/ .NET classes可以直接與保護的應用程式整合，而不需要修改應用程式原始碼。此外，網管者可以透過客製化API與應用程式的整合大幅提昇「紀錄」（logging）以及「稽核」（auditing）的彈性。相對地，由於WAF在其設計架構上的限制，沒有延伸API整合之功能。
結論
Fortify RTA利用創新的技術，為企業網站安全帶來新的契機。Fortify RTA的獨特創新技術在於它將保護措施運作在受保護的應用程式之「內」。Fortify RTA透過一種稱作「安全強化」（instrument）的程序，將其與網站應用程式整合為一，並在網站應用程式的各API出入口處擔任把關的工作。Fortify RTA偵測入侵行為的依據是分析網站程式的商業邏輯，而非如傳統透過解析複雜的HTTP通訊協定，如此可大幅提昇攻擊判斷的準確度。由於Fortify RTA與WAF運作上的架構不同，Fortify RTA在眾多方面充分展露其優勢，同時獲得2007年Network Computing product review、SC Magazine Reader Trust Award等諸多單位之大獎，誠為企業保護網站應用程式安全之最佳解決方案。