GSS 資安電子報0005期【確認企業資產是否安全的10個關鍵問題 】

現代的商業基礎架構倚賴應用軟體以管理公司資產，自動化關鍵流程，以及儲存隱私資料。這些應用系統不僅提供給內部人員使用，更提供給公司網路以外的人員服務包括客戶，供應商和合作夥伴。大多數應用系統含有漏洞，可被惡意使用者入侵。這正是為什麼大多數駭客的攻擊並非針對網路基礎設備而針對應用系統軟體攻擊的真正原因。

讓我們檢視10 個關鍵問題，看看我們的應用系統是否安全

1.我的企業軟體安全風險是什麼？
很可能，你的企業軟體是企業面臨的最大風險。有一件事很關鍵，是清楚的瞭解軟體風險對你的企業會造成影響。客戶信賴度，企業流程，甚至你的品牌和政府法規遵程度，可能會因為一個重大的安全事件而瞬間改變。風險的大小可以被仔細的分析與確認。什麼是企業軟體風險所指？如果一個駭客控制軟體系統，可能的腳本是什麼？你的企業活動能被關閉嗎？正常營運時間的損失的後果將是什麼？企業系統中哪些是關鍵資訊，如果這些資訊的流失會造成什麼虧損的結果？這些事件的是否會讓你的公司系統出現在新聞上？你的軟體所管理的資訊，一旦外洩，會危害到你的企業還是你的用戶和企業合作夥伴？在你的企業活動過程中欺詐是可能，而你的軟體扮演的角色是什麼？如果那些系統被損害，影響將是什麼？這些問題是在你的公司部署的一切關鍵的應用系統時所必須要求的。一旦你的系統分析完成後，你需要在你的企業合作夥伴的數據中心系統中分析相同的情形來確認他們符合您企業的安全標準。相反的，你也必須確定，當你的系統遭到破壞，是否會引起一些重要的企業合作夥伴或客戶的關鍵資訊外洩。

2.駭客和存心不良的內部人員怎樣使用軟體攻擊我的企業？
在軟體程式碼裡留下可被利用的安全缺陷對於黑客來說太容易找到。在一商業應用系統中不小心留下無惡意的弱點能允許敵人（駭客或存心不良的內部人員）︰

1. 讓商業流程的控制改變或產生Buffer Overflow(緩沖區溢出)並且使用程式啟動另一個程式，或讓一個存心不良的木馬程式儲存在這個主系統上
2. 進行SQL Injection攻擊並且提升登入後的權限，以觀看或修改隱私資料
3. 引起應用系統損壞或停止服務而造成作業流程上的損失或停工
4. 發掘資料洩漏並找出內嵌入程式中的驗証方式，並讓不當使用者可存取資料，資料庫或其他服務
5. 執行XSS（跨網站攻擊）以扮演成為一個合法的會員，而可以檢視或修改資料和執行交易

這些只是其中的一些著名軟體攻擊清單以及一些常見每個軟體中的弱點。Fortify公司的軟體安全研發團隊將這些清單公佈(目前有380，持續增加中) 。知道如何利用全部弱點的駭客的人數相對很少。但問題是，防禦者必須解決所有的安全漏洞。

3. 我的程式碼多安全？
令人遺憾，可能有很高的機會，你的公司所依靠的套裝軟件含有許多的安全漏洞。問題是公司現在面對一整列的常見軟體安全漏洞，然而這些漏洞對軟體開發人員卻是神秘的。嚴重的是大部分的人有個錯誤的概念，就是只有程式中的臭蟲（bug）或品質的問題可讓駭客操縱而造成傷害。應用系統的安全性和品質是不相同的，一個程式能從把一個功能執行完成，但不代表應用系統中沒有嚴重的安全弱點。一個應用系統實際的安全標準可以依據企業對其所依靠的程度，進行適當的分析，包括它將執行的風險和威脅環境。這是一件很主要的工作。不過，使用程式碼分析自動化工具可更迅速和方便的產出更可靠的結果。

4.用什麼保證我的軟體是安全的？
我們透過用非正式的投票調查軟體開發人員和軟體開發經理，他們回答”你的程式碼安全嗎？” 這個問題– 通常他們的回答是不合格或無根據的說“Yes!沒問題”。就政府責任限制而言，很少公司能尋找資源，即使在第三者承諾是安全的，卻往往找到軟體漏洞。因此購買及操作軟體雙方都有義務的保證他們的程式碼是安全的。一種好方法是採用在1960年代的核子武器談判者所使用的理論— 只要你能證明就是真實。除非你的發展軟體的部門，不管內部還是外面的公司， 已經有適當的驗證安全標準的過程，否則你已經收到的保證可能無意義。

5. 哪些步驟可以驗證這些保證？
最基本的(以及通常最容易的)方式是關鍵系統在申請部署到正式上線環境之前，確實執行保證軟體安全性的測試。很多企業首先要求有”security gate（安全把關機制）”，指的是當軟體從開發部門完成要上線前的驗收。在這個轉移階段，安全把關機制可能由是一個功能單位，通常有安全專家和人員來執行。或者可能是一個開發部門組成一個測試單位來執行測試的功能。沒有達到“Passing grade(通過等級)” ，軟體就不可以上線到正式環境。這”Final check(最後安全把關)” 在上線之前清楚找到並理解可能會發生的安全問題。

這方法的好處是阻止不安全的程式碼上線，但缺點是它可能阻擋相當多的程式碼上線。如果在最後的測試之前沒有做任何修正安全弱點的動作，大多數程式碼還是不會通過。實際上，沒有給開發人員清楚的指導方針如何修正弱點，軟體將持續被測試和不通過，再不斷的重複測試，並且失敗，最後造成上線的期限無限的延長。
所以”security gate（安全把關機制）”是真正讓應用系統安全的第一步，可以讓軟體真正的管理公司資產，關鍵流程自動化，以及安全的保存隱私資料。

6. 我們是否需要驗證商業軟體和開放性軟體或是合作夥伴開發的軟體等的安全保證？
為了確保你公司資產安全，你也必須考慮廠商開發的程式碼，系統整合廠商，或是使用開放性的軟體所開發的程式碼。
現在大多數商業軟體產品大多有上百甚至上千個品質效能的問題。然而，用戶一般使用的產品內容，大部分的bug都存在於“corner cases”（角落區），並且使用者也不會遇到。這種產品不完美，但是可滿足大多數使用者的需要。

可能你的一些軟體開發公司仍然錯誤地相信他們能生產的產品可以有一些安全缺漏洞，就像他們沒有處理這些品質問題一樣。但只要一個安全漏洞就可能讓所有的隱私資料被盜取，而且駭客將積極尋找。以我們的經驗，相對很少有商用軟體公司(以及開放性程式碼專案)裡有人員完全真正瞭解這些安全問題的嚴重性。這是因為大部分他們的客戶和使用單位沒意識到這些問題，所以還沒要求軟體必須符合安全要求。你要對軟體供應商使用你應有的權力。一些公司已經開始將軟體安全性要求編寫到他們與委外開發廠商的合約中。大多數委外開發廠商，一旦他們知道問題，將有所行動來修復問題。
這些安全問題在開放性軟體裡非常明確的。當你接受開放性軟體程式碼時，你將繼承它所有的缺陷， 例如品質或安全(除非他是由開發廠商所支援的，在這種情況下你能要求他們提供安全性保證)。修復任何會影響你系統的安全性缺陷是公司的責任。就像軟體開發廠商一樣，開放性軟體也應該受其用戶的回饋來修復其隱藏的安全缺陷。

7. 要管控軟體安全性風險需要公司組織的變動嗎？
我們尚未看過一個堅決、集中、和主動對軟體安全性負責任的組織無法成功擁有安全軟體。一剛開始時，軟體開發單位的動力將與企業安全目標有所落差。對很多開發者和系統架構師來說，安全問題考量將與他們的用新技術的願望相抵觸。對軟體開發部經理來說，將安全問題與系統新功能和期限交付的壓力相提並論似乎毫無意義。公司欲顯著的降低軟體安全性風險，需要在公司內建立一個軟體安全專責單位，它有責任和權力管理軟體開發部門並能有量化的評量標準，並可分派改進的相關工作。

8. 什麼是最有效管控安全風險的選擇？
最有效的管控軟體安全性風險是建置一個軟體安全開發生命週期(Secure Development Life Cycle, SDLC)並且要求你的軟體開發廠商和所有合作夥伴以及供應商建立相同的機制。軟體安全開發生命週期(SDLC)包含了許多開發軟體的最佳實踐。最佳實踐來自於交付的軟體有可證實不會發生那些在上線階段很可能遇到威脅的安全保證。各產業領導品牌如Oracle 和微軟公司也透過跟隨SDLC最佳實踐大步前進。
有許多參考來源描述如何建構SDLC的最佳實踐。微軟公司非常樂意提供在他們自己的內部的最佳實踐，並出版許多文章和書籍描述關於如何達到安全目標的過程。另一個好的參考是如何在你的組織建構一個完善的SDLC工具書，例如Dr. Gary McGraw所寫的Software Security: Building Security In。不管哪種的方法，最成功的SDLC 最佳實踐包括︰

1. 訓練開發人員關於軟體安全性觀念和程式碼等級的安全弱點
2. 軟體規劃階段增加Threat Modeling(威脅模型化)和系統架構的風險評估
3. 在開發階段使用自動化的程式碼安全弱點分析技術的檢測工具
4. 在QA 階段做軟體安全弱點攻擊測試
5. 在上線階段，詳細的監控所有應用系統的攻擊並且收集相關的資料

9. 最先要做的3 件事情是什麼？
首先，分派並授權個人負責軟體安全相關工作，不要讓它在最後成為資安單位及開發單位三不管地帶而最後胎死腹中。其次，執行企業內軟體資產全面的稽核，確定企業軟體的整體安全狀況。要確認稽核包括風險分析和威脅評估每個應用系統和一份關鍵系統的安全弱點詳細報告。第三，實際建構SDLC 保證應用系統有明確的安全要求，並且確認廠商與合作夥伴也做相同的事。如果要立即實現全部SDLC最佳實踐，好像有點難度，也可以做從由Dr. Gary McGraw和其他專家所建議的基礎動作：系統架構風險分析與程式碼安全分析。

10. 哪裡可以有更多的學習資源或更多的協助？
找全世界許多大型的金融服務性企業和軟體開發公司都肯定的專業軟體安全顧問公司︰Fortify。