Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~
本篇是 建構安全軟體開發 系列文的 EP13。
首先,討論一下訂立安全開發相關文件規劃的議題。
增強改進保護資訊系統與資源是 SSP 的最主要目的。任何跟資訊系統有關的事物都或多或少有部分的機敏資料而需要透過好的管理方式進行被保護的處理,所以保護的作法應該被文件化紀載下來成 SSP。
而除了最主要的 SSP 制定外,更可以有其他額外文件來加強保障:
1. 組態管理計畫
2. 偶然應對計畫 (包含營運衝擊評估)
3. 持續監控計畫
4. 安全意識、訓練、教育計畫(SATE)
5. 事故應對計畫
6. 隱私衝擊分析
並且在制定其 SSP 後,應該隨著整個 SDLC 的進展過程對 SSP 有所調整。
軟體/應用/系統/服務的需求階段分析大致可分成以下兩個面向:
功能性需求 (functional requirement)
非功能性需求 (nonfunctional requirement)
X. 安全
而在上述的非功能性需求階段當中所提及的安全得再去考量:
威脅模型。
在一開始針對威脅模型進行考量的時候,也應該要定義出 "使用情境"、"各種使用者角色"、"依賴、假設、威脅情境"...等附屬文件產生。而這些文件都有助於在進行程式碼審查及建立安全測試案例。
威脅是透過弱點對資產造成影響的可能性,而其造成的方式有:
而針對以上的點表列出來,並且透過策略性的控制(A.A.M.T.)其影響的可能性(風險發生)到可接受的程度(剩餘風險)。
策略性的控制(A.A.M.T):
若從一個日常生活的例子來舉例,當今天出門帶了 1000 NTD 旅遊時,假定這 1000 NTD 是上述當中的 "資產",並且要確保回到家時 1000 NTD 這個資產。
那這個資產所帶來的威脅有哪些?
對於上述的每一點都可以有其策略性的控制(A.A.M.T.)方式,就舉點 1 (口袋破洞了) 再來繼續考慮:
所以,透過這樣的例子是否就能比較充分了解呢?
當然,建立 SSP 後很大的問題在於 "安全" 議題是否有被凸顯,並且讓整個組織從上到下都能有所共識去落實。
通常技術性的風險問題可能比較不被管理階層給重視,但若將其風險問題轉換其溝通角度為商業價值風險,那被接受與改善的可能性就會大幅提高。
例如,建構網路應用服務須掛上安全性憑證(SSL)進行加密,那不掛能不能使用,可以。
技術性的風險溝通:
但很容易造成服務的交易資料外洩等。
商業價值風險溝通:
但很容易造成服務被科技巨頭們(Google、Apple、Microsoft...等)聯手封殺其可用性。
不懂的管理階層,在前者的溝通中可能會認為 "加密" 這事應該由開發人員自行解決,而不予重視;但在後者的溝通中,就會比較容易被重視。
在一個軟體/應用/系統/服務建構過程中,至少會透過以下三種作業環境來處理:
而這三個作業環境的相關安全措施的執行,也務必要同樣重視並且同步實施,很多安全問題與風險,常常是因為某個環境的安全措施執行的疏漏而產生的。
文化是習慣的累積,而習慣是日常的累積
透過溫水煮青蛙的概念,讓安全意識與防範能在團隊文化中逐步的顯露出來,而各種安全措施要透過不斷的回顧與改善並且從過去發生過的錯誤學習,逐步的養成習慣進而變成文化。