112年法務部調查局調查人員三等系統分析與設計
|
二、貴公司正在準備針對某個政府標案進行投標，該標案要求專案的進行必須採 用所謂的安全軟體發展生命週期 (SSDLC) 來進行開發。 (一)請問為什麼客戶會要求採用 SSDLC 而非傳統的 SDLC 進行該系統的開發？（10分） (二)請說明 SSDLC 在需求分析、系統設計…等各個 SDLC 階段，如何將安全性納入這些軟體的開發中？（15分） |
答：
(一)請問為什麼客戶會要求採用 SSDLC 而非傳統的 SDLC 進行該系統的開發？
安全軟體發展生命週期 (SSDLC) 是在傳統軟體發展生命週期 (SDLC) 的基礎上，加入了資安的規範和標準，以確保在軟體的整個發展過程中，從需求分析到設計、開發、測試、部署，乃至於維護都能夠確保資訊的安全。以下是為什麼客戶會要求採用 SSDLC 而非傳統的 SDLC 來進行系統開發的原因：
1.資訊安全優先：
隨著資訊技術的發展，資安問題逐漸被重視。系統一旦被入侵或遭受攻擊，不僅會導致資料洩露，還可能影響到整個機構的營運。SSDLC 能夠從一開始就將資安考量納入，降低此類風險。
2.降低後期維護成本：
在開發初期就將資安納入考慮，可以避免在後期發現資安問題而進行大幅度的修改，這樣不僅可以節省成本，還能確保系統的穩定性。
3.符合法規要求：
許多國家和地區都有相關法律和規定要求公共機構或特定行業在開發系統時必須採用 SSDLC，以確保公眾的資料安全。
4.提高客戶信任度：
一個從設計到部署都考慮到資安的系統，會使得客戶更加信任該系統，也能夠提高系統的市場競爭力。
5.防範未知風險：
隨著科技的進步，新的安全威脅也在不斷出現。SSDLC 可以確保在面對未知威脅時，系統有一定的防護能力。
6.提高系統的完整性和可用性：
採用 SSDLC 不僅可以確保資訊的機密性，還可以確保系統的完整性和可用性，避免因為安全問題導致的系統當機或數據丟失。
總結來說，客戶要求採用 SSDLC 而非傳統 SDLC 是為了確保系統在整個生命週期中的安全性，並且降低資安問題所帶來的風險和成本。
(二)SSDLC在需求分析、系統設計等各個SDLC階段，如何將安全性納入這些軟體的開發中？
1.安全軟體需求：
(1)定義：
預先考量系統安全與隱私是安全軟體發展的基礎觀念。定義安全需求的最佳時機是在系統初始規劃階段，以及早定義安全需求使得開發團隊可以識別關鍵的查核點與產出，使得整合安全與隱私至系統的工作對原先的計畫與時程影響最小化。
(2)安全需求萃取方式：
a.腦力激盪 (Brainstorming)、需求訪談或工作會議。
b.問卷 (Survey) 或查檢表 (Checklist)。
c.資料分級 (Data Classification)。
d.誤用案例模型 (Misuse Case Modeling)。
e.來自設計階段活動的回饋。
2.安全軟體設計：
(1)定義：遵循安全設計原則並進行威脅建模與風險評估。
(2)安全軟體設計原則：
|
設計原則 |
說明 |
|
最弱環節(Weakest Link) |
1.軟體設計時應該從攻擊者的角度考量目前軟體架構或流程中，防護最不足甚至防護可能被繞過的情況，進行控制措施補強。 2.可以透過源碼檢測、主機弱點掃瞄、網站弱點掃描，以及滲透測試等方式找出弱點或防護不足之處，以進行安全控制措施強化工作 |
|
縱深防禦(Defense in Depth) |
1.單一的安控措施被突破或失效不會造成安全危害或只造成部分的危害，在軟體單一環節或進入路徑採用多重的安控措施，又稱作分層防禦 (Layered Defense) 2.為了避免帳號密碼容易被竊取，採用多重因素認證，例如增加使用OTP (One Time Password) 機制、帳號密碼及圖形驗證、軟體憑證登入及圖形驗證等 3.實體主機可以採用 IDS、IPS以及 Firewall 來增加防禦縱深 |
|
最小權限(Least Privilege) |
1.任何使用者或程式僅在被允許的最短時間區間內被給與必需的、最小的存取權限，以完成其作業任務 2.例如只需要查詢資料，只提供讀取權限即可，不需要多給予編輯權限 3.可以透過存取控制表 (Access Control List) 來檢視權限設定是否適當 |
|
權限分離(Separation of Duties) |
1.設計軟體功能時將條件設定在兩個或多個以上，而且需要滿足所有條件才能完成作業 2.使用某一項功能，除了需要先行使用帳號密碼登入系統外，另外需事先行提出申請，經過管理者簽核同意後，才可以使用該項功能 |
|
簡化設計(Economy of Mechanism) |
1.軟體設計愈複雜，愈容易產生安全漏洞，在安全分析中也更不容易被找出問題 2.模組化的設計、可重複使用的元件與服務、減少不必要的功能與服務 |
|
安全故障(Fail Secure) |
1.軟體發生錯誤或故障時，預設狀態為不允許存取，而且維持機密性、完整性與可用性，軟體中重要的功能或交易行為都應該設想發生錯誤的狀況，並且考慮在錯誤的狀況下，各項安全機制是否還處於有效的狀態 2.例如連續登入失敗5次，則鎖定帳號10分鐘 |
|
完全仲裁(Complete Mediation) |
1.每一次主體存取物件時，都重新檢查其合法授權。 2.軟體中重要的物件或功能，在每次存取時，重新要求使用者的身分認證及合法授權，以避免重送攻擊 (Replay Attack) 的危害 |
|
開放設計(Open Design) |
1.安全設計不應該依賴「隱藏式的安全」(Obscurity) [指安全性建立於別人不知道安全作法為何] 2.例如需要加密保護資料時，應該使用已公開且未被破解的加密演算法，不應該使用自行設計的加密演算法 |
|
使用現存元件(Leveraging Existing Components) |
1.重複使用現有、經過安全測試或實證的元件，得以避免增加新元件所產生的風險 2.評估採用一項技術或元件時，除了其功能是否符合需求，也應該考慮該項技術的安全性，以及過往是否發生安全事故 |
|
防範單點失效(Single Point of Failure) |
1.安全設計應該確保軟體不會有單點故障或錯誤造成全面停擺的可能，為達成高可用性的目的，實務上通常採取重複 (Redundancy) 方式進行備援處理 2.可以視實際需要採取備援機制 |
|
最少共用機制(Least Common Mechanism) |
1.儘可能減少適用於所有使用者或角色的機制，共享機制通常代表共享資料，必須很小心的設計以避免資訊流破壞安全性 2.明確地區分前、後端管理介面與網址 3.後端管理應該加強安全性身分驗證 |
|
可接受度(Psychological Acceptability) |
1.考量安全機制對於人員的可接受度，良好的安全機制應該儘可能的設計為容易使用、不影響原先的存取，以及儘可能做到讓使用者感受不到其存在，以增加轉換與接受程度 2.安全機制常常會影響到軟體的易用程度，使得步驟增加或是額外的動作，但是應該儘量將影響最小化在合理範圍內 |
(3)風險處理活動：
|
處理方式 |
活動 |
實施指南 |
|
風險降低 |
經由被選擇的控制機制來降低風險，一直到殘餘風險被接受 |
應該選擇適當與合理的控制措施，以滿足風險評估和風險處置中識別的要求 |
|
風險保留 |
根據風險評估，決定不採取進一步的活動而保持風險 |
如果風險等級符合滿足風險接受準則，則不需要實施額外的控制措施 |
|
風險避免 |
應該規避導致特定風險的活動或條件 |
識別的風險太高，或者實施其他控制處理成本超過了效益，必須改變或調整控制作為 |
|
風險轉移 |
根據風險評估結果，對於特定風險最有效的管理，可能是將風險轉移給其他方 |
1.移轉過程會牽涉組織外的夥伴，造成極有風險控制機制的改變可能會引起其他風險，因此必須考量特殊情況下的風險處置。 2.可以納入保險機制，或是與夥伴之間簽訂保障合約，請求發生風險失控時的支援 |
(4)安全設計審查：
a.收集需求與設計相關文件(Collection of Design Collection)。
b.研究設計(Design Study)。
c.分析設計(Design Analysis)。
d.修正安全需求(Propose Security Requirements)。
e.建議設計變更(Recommend Design Changes)。
f.與開發團隊討論(Discussion with the design team)。
g.設計定型(Design Finalization)。
(5)威脅建模(Threat Modeling)：
a.採用系統化的方法，以攻擊者角度，識別可能影響軟體系統的威脅並進行評估。
b.基於對架構與設計的了解，識別與評估威脅後，以風險高低的順序對威脅發展適當的控制措施。
(6)架構風險分析( Architecture Risk Analysis)：
a.抗攻擊能力分析(Attack Resistance Analysis)：
與「威脅建模」相似，但是採用「已知」攻擊或弱點清單。
b.模糊分析(Ambiguity Analysis)：用來發現新威脅的分析活動。
c.底層框架弱點分析(Underlying Framework Weakness Analysis)：
尋找底層軟體已知安全弱點。
3.安全軟體開發：
(1)定義：避免常見軟體漏洞並發展因應控制措施。
(2)安全軟體開發程序：
a.常見威脅：
由設計階段進行的風險分析評估結果找出威脅，發展控制措施與安全特點。
b.常見弱點：
彙整 OWASP、CWE/SANS、弱點資料庫等常見弱點與防禦方法。
(3)安全開發環境：開發、測試、正式三個作業環境應如何進行作業與部署？
|
項目 |
說明 |
|
軟體或系統處理、儲存、傳輸資料的敏感性 |
在開發或測試環境中存取使用機敏資料，需要有保護措施及管制程序 |
|
適用的內部及外部安全需求 |
包含政策與法規遵循與軟體安全需求來源所列項目 |
|
組織支援軟體開發的安全控制措施 |
包含管理面、實體與技術的控制措施 |
|
軟體開發工作環境中人員的可信賴度 |
人員進用前，對其進行背景查核 |
|
軟體發展的委外程度 |
需要確保相關資安風險有效識別分析，控制措施有效運作 |
|
區分軟體發展環境 |
開發、測試以及正式作業環境應該作區分，以避免資料混用以及源碼版本的問題 |
|
控制開發環境的存取 |
限制對程式碼、高權限的工具程式 (如後台管理工具) 以及重要資訊的存取 |
|
監控軟體發展環境及其中源碼的異動 |
開發、測試以及正式作業環境中，程式碼版本的變動應該受到控管，並且記錄其異動 |
|
備份另行儲存在安全地點 |
重要資料或軟體系統應定期備份，另行儲存在非正式作業環境外的地點 |
|
控制不同環境間資料的複製移動 |
開發與測試環境應避免使用正式環境的資料，並且建立程序管制不同環境之間的資料移動 |
(4)OWASP(Open Web Application Security Project)：
是一個線上社群，在 Web 應用安全領域提供免費的文章、方法、文件、工具和技術。
4.安全軟體測試：
(1)定義：驗證安全性需求並確保達成安全目標。
(2)工作內容：
a.安全性測試：
一般可以分為靜態分析與動態分析。
(a)靜態分析(Static Analysis)：
可以在不執行軟體的狀況下，針對軟體的內容進行分析，比對已知弱點模式，找出可能的缺陷或錯誤，例如源碼檢測。
(b)動態分析(Dynamic Analysis)：
將軟體在實際的環境中執行起來並進行分析的活動，例如弱點掃描。
b.安全需求驗證：測試軟體中安全相關功能是否符合需求並運作正確。
5.安全軟體部署：
(1)定義：確保安全控管機制與防護措施正常運作。
(2)安全軟體部署與組態設定原則：
a.作業系統：
(a)定期 Patch 更新，重要伺服器應於測試環境測試完畢後再行更新。
(b)關閉不使用的服務及 Port。
(c)正確的安全設定。
(d)注意安全警示 (Security Alert) 網站的通告。
b.網頁或應用程式伺服器：
(a)定期評估是否更新伺服器版本。
(b)安全限制。
(c)認證方法。
(d)錯誤處理頁面。
(e)Session Timeout 時間。
c.資料庫：
(a)不使用預設帳號密碼。
(b)不使用過高的管理權限連接資料庫。
(c)前後台 (一般功能與管理功能) 不使用相同帳號連接資料庫。
(d)定期更新資料庫的安全修補。
(e)儘可能採用加密連線。
(f)存取行為進監控，定期稽核。
d.軟體本身：
(a)敏感資料 (如帳號密碼) 不以明文方式放置於設定檔或源碼中。
(b)移除錯用的源碼。
(c)移除維護用的後門。
(d)移除測試帳號。
(e)不開啟底層非必要的服務。
(f)以所需的最低權限執行軟體。
(3)變更管理：
a.識別可能的變更：
(a)因為遭遇軟體錯誤或要求新功能而產生變更的需求。
(b)提出變更要求。
b.分析變更請求：
(a)分析變更的技術可行性。
(b)分析成本與效益。
c.評估變更：變更管理者根據可行性、成本與效益決定是否進行變更。
d.計畫變更：
(a)分析變更的影響，包含對「軟體安全性」。
(b)對變更進行計畫。
e.實作變更：
(a)根據計畫實作變更。
(b)測試變更。
(c)更新相關文件，包含「軟體安全性」。
(d)釋出變更，反應需求的版本上線。
f.檢視與結案：
(a)驗證變更生效。
(b)執行結案程序。
※參考資料：
1.財團法人資訊工業策進會-安全軟體發展流程指引.pdf
2.王耀華-安全性軟體開發流程概論.pdf
3.蔡宗霖-軟體安全發展流程實務.pdf
4.https://zh.wikipedia.org/wiki/OWASP
留言列表
國考資訊處理解答 (7)
