[分享] 關於應用程式安全稽核的現況

上星期有朋友問到有關軟體/應用程式安全稽核的一些現況，以及什麼樣的工具才會是客戶願意使用的檢測工具，就個人的了解，將相關的資訊整理分享如下：

目前在應用程式安全稽核方面，大致可分為資安管理面和技術面的稽核，在管理面方面，可依據ISO 27001中A.12資訊系統取得、開發及維護的控制項目來進行，包括在軟體專案一開始的時候，是否識別了安全風險，並且加入所需要的安全控制；應用系統是否設計了輸入資料確認、處理程序查核機制、訊息完整性、輸出資料的確認等。

另外，若軟體使用了加密機制，就要注意是否制定了加密控制與使用政策；是否有適當的金鑰管理；還有如何確保系統檔案和源碼的安全，包括像是程式的組態與安裝控管、測試資料的保護、源碼的存取控制；最後是整個軟體開發與支援過程的安全如何確保，包括了控管專案與所需的支援、應用系統的變更程序、變更之後的技術審查、以及後續系統弱點修補的程序等，這些都是實施資安稽核時的重點。

至於技術性稽核，通常是使用一些檢測工具，進行白箱或黑箱的測試，之後會產出一份檢測報告，再依據報告內容進行改善。但是，若是沒有配合完整的稽核程序，這部份較像是單一軟體檢測和在專案驗收時才會進行的事項，比較不像是所謂的資安稽核。

在工具方面，黑箱部份知名的有HP Webinspect和IBM Appscan等，白箱則有Fortify等，當然也有一些免費開放的工具，這些工具已內建了許多模組，可以選擇依照法規要求(ex. ISO 27001, PCI DSS)或是Owasp Top10常見的弱點，進行掃瞄並產出對應的報告。

在報告之中，它會列出有問題的程式碼或參數是落在哪一行，也會提出建議的改善方法，當然這些只能供作程式開發人員的參考，讓他們明白需要改善的方向，而且通常在改善完成之後，也需要再作一次檢測，看看是否還有遺漏的部份。

如果回到需求面來看，組織會想要作應用程式的檢測，大致有以下幾個原因：

• 自我要求：通常是非常重視資安的企業，內部有自己的程式開發人員，為確保所撰寫程式在上線前沒有安全漏洞，所以需要進行檢測。

• 法規要求：為因應ISO法規或政府對相關單位的資安要求，所以需要定期實施安全檢測。

• 客戶要求：這部份是一些受到企業委外的軟體開發商，為確保程式需合RFP相關安全要求，故在驗收之前需要作軟體的安全檢測。

因此，使用檢測工具是最容易滿足以上要求的作法，不過像黑箱工具最容易受到質疑的地方，就在於是否能夠完全檢測出其所有的弱點，以及所提供的改善建議是否切實可用。所以客戶在評估使用檢測工具時，通常會有以下的考量：

1. 購置成本：以國外的工具而言，通常價格都不菲，雖然有些工具可以在程式開發階段時，就可以輔助開發人員來避免可能的漏洞，但是許多客戶都傾向於不購買工具，而是在程式開發完成後，甚至是已經上線了，再請提供服務的廠商來實施檢測。


2. 使用介面：國外工具大都使用英文介面，相關的選項設定，甚至對於弱點的修補建議都是英文，這對於一些IT人員而言，使用上可能不太容易上手。


3. 支援能力：可支援常見的程式語言，包括html、java、.net、vbscript、xml、ActiveX、Flash、AJAX等之外，也包括常見的通常協定如http、https、proxy等，以及相關的編碼方式如ISO-8859、UTF等。也會要求在檢測過程中，不得新增或修改其後端資料表的任何內容(針對黑箱工具)。


4. 法規模組：這部份和產出的報表內容有關，是否可支援常見的安全標準例如OWASP Top10、ISO 27001、PCI DSS、HIPPA等，可完整的檢測其提出的安全漏洞和安全要求事項。


5. 報表品質：是否包括執行摘要、漏洞描述、程式修補建議等。過去曾遇到的情況是，在掃瞄完成之後，出了厚厚一本詳盡的弱點報告給客戶，但客戶認為太繁瑣，甚至要求必須依照其需求，例如不同人員屬性像是開發人員、測試人員、法規人員，再客製化一份報表，以及提供中文化的修正建議。事實上報表的內容品質，也會是客戶是否願意採用這些工具的重點。

所以，針對以上提到的問題，若廠商都能有相對應的解決方案，相信就會是客戶想要使用的好工具，當然其中在實務面上有許多需要克服的困難，這也需要讓廠商來傷腦筋了~