iT邦幫忙

2022 iThome 鐵人賽

DAY 13
0
Security

建構安全軟體開發系列 第 13

建構安全軟體開發 EP 13

  • 分享至 

  • xImage
  •  

Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

本篇是 建構安全軟體開發 系列文的 EP13。


首先,討論一下訂立安全開發相關文件規劃的議題。

System Security Plan (SSP)

增強改進保護資訊系統與資源是 SSP 的最主要目的。任何跟資訊系統有關的事物都或多或少有部分的機敏資料而需要透過好的管理方式進行被保護的處理,所以保護的作法應該被文件化紀載下來成 SSP。

而除了最主要的 SSP 制定外,更可以有其他額外文件來加強保障:

1. 組態管理計畫
2. 偶然應對計畫 (包含營運衝擊評估)
3. 持續監控計畫
4. 安全意識、訓練、教育計畫(SATE)
5. 事故應對計畫
6. 隱私衝擊分析

並且在制定其 SSP 後,應該隨著整個 SDLC 的進展過程對 SSP 有所調整。

需求階段 (Requirements Phase)

軟體/應用/系統/服務的需求階段分析大致可分成以下兩個面向:

  • 功能性需求 (functional requirement)

  • 非功能性需求 (nonfunctional requirement)

    1. 可靠性
    2. 可用性
    3. 效能
    4. 擴充性
      ...

    X. 安全

而在上述的非功能性需求階段當中所提及的安全得再去考量:

  1. 內部造成 -> 回頭檢視功能性問題。
  2. 外部造成 -> 可能是誤用或濫用而造成,也可視作某種程度上的攻擊。

設計階段 (Design Phase)

威脅模型。

在一開始針對威脅模型進行考量的時候,也應該要定義出 "使用情境"、"各種使用者角色"、"依賴、假設、威脅情境"...等附屬文件產生。而這些文件都有助於在進行程式碼審查及建立安全測試案例。

威脅是透過弱點對資產造成影響的可能性,而其造成的方式有:

  1. 內部發生的 (Internal)
  2. 外部影響的 (Expternal)
  3. 意外造成的 (Unintentional)
  4. 蓄意產生的 (Intentional)

而針對以上的點表列出來,並且透過策略性的控制(A.A.M.T.)其影響的可能性(風險發生)到可接受的程度(剩餘風險)。

策略性的控制(A.A.M.T):

  1. Accept (接受)
  2. Avoid (避免)
  3. Mitigate (減輕)
  4. Transfer (移轉)

若從一個日常生活的例子來舉例,當今天出門帶了 1000 NTD 旅遊時,假定這 1000 NTD 是上述當中的 "資產",並且要確保回到家時 1000 NTD 這個資產。

那這個資產所帶來的威脅有哪些?

  1. 口袋破洞了 (Internal)
  2. 路過手搖店 (Expternal)
  3. 被風吹走了 (Unintentional)
  4. 扒手竊走了 (Intentional)

對於上述的每一點都可以有其策略性的控制(A.A.M.T.)方式,就舉點 1 (口袋破洞了) 再來繼續考慮:

  1. 還好只帶 1000 元而已,沒關係。 (Accept)
  2. 出門前檢查所有的口袋有沒有破洞。 (Avoid)
  3. 1000 元分好幾個口袋放,就算一個口袋破洞,還有其他的剩下來。 (Mitigate)
  4. 還好有旅遊遺失險,保險公司會理賠。 (Transfer)

所以,透過這樣的例子是否就能比較充分了解呢?

實作、測試階段、下一個循環階段 (Implementation, Testing, Next Lifecycle Phase)

  • 可攻擊面積分析
  • 程式碼靜態分析
  • 人工的程式碼審查
  • 滲透測試
  • 安全派送與部屬
  • 安全組態設定
  • 持續監控
    ...等

當然,建立 SSP 後很大的問題在於 "安全" 議題是否有被凸顯,並且讓整個組織從上到下都能有所共識去落實。

技術性的風險 v.s 商業價值風險

通常技術性的風險問題可能比較不被管理階層給重視,但若將其風險問題轉換其溝通角度為商業價值風險,那被接受與改善的可能性就會大幅提高。

例如,建構網路應用服務須掛上安全性憑證(SSL)進行加密,那不掛能不能使用,可以。

技術性的風險溝通:
但很容易造成服務的交易資料外洩等。

商業價值風險溝通:
但很容易造成服務被科技巨頭們(Google、Apple、Microsoft...等)聯手封殺其可用性。

不懂的管理階層,在前者的溝通中可能會認為 "加密" 這事應該由開發人員自行解決,而不予重視;但在後者的溝通中,就會比較容易被重視。

提升 "安全" 的意識並且落實

在一個軟體/應用/系統/服務建構過程中,至少會透過以下三種作業環境來處理:

  • 開發環境
  • 測試環境
  • 正式環境

而這三個作業環境的相關安全措施的執行,也務必要同樣重視並且同步實施,很多安全問題與風險,常常是因為某個環境的安全措施執行的疏漏而產生的。

文化是習慣的累積,而習慣是日常的累積

透過溫水煮青蛙的概念,讓安全意識與防範能在團隊文化中逐步的顯露出來,而各種安全措施要透過不斷的回顧與改善並且從過去發生過的錯誤學習,逐步的養成習慣進而變成文化。



上一篇
建構安全軟體開發 EP 12
下一篇
建構安全軟體開發 EP 14
系列文
建構安全軟體開發30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言