您的網路銀行應用程式 有多安全?
數位化是現代銀行不可或缺的趨勢。幾乎每家銀行都提供網站和行動 App，民眾的接受度也越來越高。最近的一項 PWC 調查(註 1)發現(https://www.pwc.com/us/en/industries/financial-services/library/digital-banking-consumer-survey.html)，46% 的消費者使用網路銀行，這比之前 2012 年調查的只有 27% 大幅增加。
對於銀行和其他金融機構而言，也必需因應這個趨勢提供網路銀行或行動銀行 App 資訊。用戶渴望隨時隨地享受銀行業務帶來的便利，雖然能夠在個人的行動裝置或電腦上執行銀行服務所帶來的優勢是不可否認的，但另一個問題仍然存在:這些網路銀行 App 安全嗎?
2017 年底發布的研究可能會回答這個問題。這項研究在伯明罕(Birmingham)大學進行，發現行動銀行 App 中的安全問題可能使數百萬用戶受到攻擊。他們發現的主要問題與憑證綁定有關，從 The Register(註 2)文章可以發現:系統測試未能發現「嚴重的漏洞，可能讓攻擊者控制受害者的網路銀行」。
這樣的安全問題顯示了在開發數位銀行 App 時需要考量所有基礎設施。雖然數位銀行可以幫助培養新客源並提供創新的服務，為金融機構帶來更多的收益，同時數位銀行也存在很大的風險。
對於銀行 App 開發人員的七個關鍵步驟
當使用者擁有不錯的安全意識，習慣使用安全的 wifi 去存取網路銀行 App，且設定於不使用裝置時鎖定系統、用獨立且唯一的密碼，且不在公用的電腦上登入時;那確保使用者安全的重責大任就落於應用系統開發人員與團隊身上。
軟體開發生命週期(SDLC)對於安全應用程式的持續開發至關重要。SDLC 將制定一項戰略，確保產品兼顧安全性與開發效率。以下是 SDLC 中的七個關鍵步驟，開發人員和安全團隊應共同努力確保發布安全的網路銀行與行動銀行 App。
1.定義安全需求
第一步是了解銀行應用程式的安全需求。由於銀行 App 的敏感性，分配至少一位安全團隊成員與系統建置團隊合作非常重要，這種合作關係需要在實際開發之前開始。
在 SDLC 的流程中，開發人員和安全人員應識別軟體中的關鍵安全風險，包括軟體必須遵循的標準(包含組織內和法律/法規)。而開發團隊與安全團隊應明確的溝通，確保流程中的任何差異。只有安全需求得到雙方同意，才能開始進行開發。
2.分析攻擊層面(註 3)
任何軟體都會具有風險區域，稱為可攻擊面(Attack Surface)。OWASP 將此定義為:
1. 資料/命令存取應用程式的所有路徑的總和
2. 保護這些路徑的程式碼
3. 應用程式中使用的資料，包括機密和金鑰，智慧財產權，關鍵商業資料與個資
4. 保護處理這些資料的程式碼
各種組織都提出了量化可攻擊面的方法:微軟 Michael Howard 設計了相對攻擊層面商數 (Relative Attack Surface Quotient);Carnegie Mellon 的研究人員創立了攻擊面度量法(Attack Surface Metric)。在設計最適合單位內部的方法時，可參考上述的方法可能會有所幫助。
分析攻擊層面是保護任何應用程式的一個複雜但至關重要的部分，因為它可以確定程式碼中最關鍵和最易受攻擊的區域，以確保它們在開發和測試期間得到適當的保護。
3.實作威脅模型分析(註 4)
SSDLC 的下一步是執行威脅模型分析。威脅模型分析可幫助開發人員了解應用程式需要哪些安全控制，以進一步確保從一開始就構建安全性。威脅模型分析過程涉及定義需要保護哪些資產和資源、獲取這些資產和資源的入口和接入點，以及對每個被優先排序的威脅制定管控計畫。
威脅模型分析和攻擊層面分析之間的關係非常緊密，這意味著對攻擊層面的任何更改都需要進行威脅模型分析，而威脅模型分析可以幫助利益相關者更容易了解攻擊層面。
4.執行靜態分析安全測試(註 5)
最基本的靜態分析安全測試(SAST)測試應用程式的源碼以檢測關鍵漏洞。進階SAST工具以自動化執行，從源頭保護程式碼，並可在開發過程的初始階段實施。 SAST 測試是 SDLC 的一個重要部分，因為它可以在應用程式進入正式環境之前檢測到漏洞，這意味著可以最簡單及最便宜的找到並修復錯誤。SAST 的工作原理是將開發人員指向程式碼中存在問題的特定區域。
除了檢測 OWASP Top 10 中包含的漏洞之外， SAST 還檢查程式碼是否存在與法律和監管標準相關的相容性問題，包括許多銀行必須遵守的 PCI-DSS。
5.執行互動式應用安全測試
IAST 是 SSDLC 的下一步，它會測試該軟體的實際版本。從本質上講，SAST 是安全開發人員，而 IAST 是一名駭客，致力於訪問應用程式中應該無法訪問的區域。IAST 不需要深入了解應用程式，只關注它是否容易遭受攻擊以及如何利用該漏洞。
混合使用靜態和動態安全測試是確保在程式碼和應用程式上線之前消除漏洞的最佳方法。特別是對於銀行軟體等更敏感的應用程式，這種組合決定性的減少漏洞和盡可能降低攻擊風險。
6.建立 Security Gates
SDLC 最重要的部分是確保有中高風險漏洞的軟體無法進入正式環境。微軟的SDL 流程將 Security Gates 稱為「bug bars」，但這個想法是一樣的。Security Gates 建立最低限度的安全性，並檢查程式碼是否存在高風險漏洞。任何標記為高風險的程式碼都應該發送給開發人員以實現修復。這些檢查最好在開發階段進行靜態分析測試時執行，因為 CxSAST 可以自動檢測這些漏洞，以協助開發人員在開發階段就能從源頭修復它。
基本上一旦建立了 Security Gates，它們就不會被打破，無論應用程式發布的程度如何: 永遠不允許中高風險的漏洞進入正式環境， Security Gates 有助於確認以及如何防範風險。
7.持續導入安全開發教育(註 6)
雖然不屬於 SDLC，但開發人員教育是 SSDLC 的一部分。開發人員培訓在安全開發組織中迅速發展，因為它有效地讓對安全一無所知的開發人員蛻變為安全開發人員。特別是在像銀行應用這樣的高度敏感的環境中，讓了解安全流程的開發人員可以更快地發布安全軟體。
現在，任何現代 App 都需要比以前更高的安全意識。客戶希望能夠在他們的手機和電腦上做所有事情，這需要考慮更多如何保護我們的企業和客戶。在數位銀行業務方面，這些考量因素甚至更大，需要強而有力的規劃和執行才能保持高水平的安全性。通過 SSDLC 引導，銀行 App 可以安全發布，讓客戶對您的企業和軟體充滿信心。