SSDLC 各階段資訊安全作業參考筆記

2020-10-09

筆記 Secure Software Development Life Cycle, SSDLC 中各階段需要進行的資訊安全作業項目 🔱

logo

說明

需求階段

軟體的安全面向

  1. Confidentiality (機密性)
  2. Integrity (完整性)
  3. Availability (可用性)
  4. Authentication (驗證)
  5. Authorization (授權)
  6. Auditing (稽核)
  7. Session Management (資料傳輸機制管理)
  8. Error and Exception Handling (錯誤與例外處理)
  9. Configuration Management (組態管理)

資料來源：Official (ISC)2 Guide to the CSSLP

相關工作

安全需求萃取

📝OWASP ASVS

OWASP ASVS

Application Security Verification Standard, ASVS，提供對於應用程式的安全測試基準與指南，同時也對於軟體開發人員條列說明開發上需要注意的事項。ASVS 提供了兩項功能：
（一）指引組織開發與維護安全的應用程式
（二）提供資安廠商、資安工具開發者、資安需求者能夠契合對於資安的需求與供給

📝資通系統資安需求項目查檢表
📝需求追溯表

設計階段

安全軟體設計原則

  1. Weakest Link：常保警覺，資訊系統中最弱的環節在那裡？程式碼、服務或者介接介面？
  2. Economy of Mechamism：保持軟體的實作上的簡單，越複雜的軟體越有可能出現漏洞
  3. Leveraging Existing Components：使用已有經過測試、可受信任的軟體元件，不要自造輪子、製造麻煩
  4. Defense in Depth：縱深防禦，透過多個環節都分別設立資安防禦機制，例如軟體、網頁伺服器、防火牆、路由器
  5. Fail Secure：確保資訊系統的故障安全，當錯誤發生時是否會影響 Confidentiality, Integrity, Availability，是否有對應的處理方式
  6. Single Point of Failure：資訊系統的攻破只需要最後一個弱點環節就足夠
  7. Least Privilege：最小權限原則，只提供必要的權限
  8. Complete Mediation：對於每一次的請求都需要進行檢查（傳入的參數與物件綁定、宣稱的權限、要求的目標）
  9. Separation Of Duties：系統應保持責任分離，不論是使用者的權限、程式的功能
  10. Psychological Acceptability：太過繁複的安全設定，反而會讓使用者感到不便而使用具有風險的使用方式
  11. Open Design
  12. Least Common Mechanism

OWASP - Secure Design Principles

風險處理, Risk Treatment

  1. 降低, Reduce
  2. 保留, Retain
  3. 避免, Avoid
  4. 轉移, Transfer

威脅建模, Threat Modeling

使用 EDFD 建立資料流程圖，使用 STRIDE 識別威脅，接著使用 DREAD 評估威脅風險，最後提出對應的對策 (Countermeasure)。

  1. Identify Assets
  2. Create an Architecture Overview (繪製系統架構圖、列出使用的相關元件)
  3. Decompose the Application to create Security Profile
  4. Identify the Threats with STRIDE
  5. Document the Threats
  6. Rate the Threats with DREAD

MSDN - Threat Modeling

應用程式風險分類, Security Profile

這個風險分類方式年代較為久遠，可以考慮改以與時俱進的 OWASP ASVS 來取代 😗

🐧 Input validation, 輸入驗證:

  • 是否所有的資料都被驗證過 (validated)
  • 攻擊者有沒有 Injection (SQL, LDAP, Command) 的機會
  • 儲存在資料庫的資料是否可被信任

🐧 Authentication, 身分驗證:

  • 驗證方式是否安全
  • 是否使用憑證
  • 密碼政策的嚴格程度

🐧 Authorization, 授權驗證:

  • 各功能是否都有檢查權限

🐧 Configuration management, 組態管理:

  • 組態設定如何被保護

🐧 Sensitive data, 機敏資料:

  • 應用程式包含那些機敏資料
  • 在網路傳輸與資料庫中如何保護資料
  • 是否加密保護機敏資料

🐧 Session management, 會話管理:

  • 是否使用 Session
  • Session 的持續時間
  • Web Farm 如何同步 Session

🐧 Cryptography, 加解密:

  • 使用那些加密技術

🐧 Parameter manipulation, 參數竄改:

  • 是否檢查所有的參數 (Url Route, Query String, Form Field, Form Body, Cookie, HTTP Header) 是否被竄改

🐧 Exception management, 例外管理:

  • 應用程式如何處理錯誤 (Error) 與例外 (Exception)
  • 發生錯誤時是否會對使用者顯示詳細的錯誤訊息
  • 是否有機制紀錄錯誤訊息

🐧 Auditing and logging, 稽核與日誌:

  • 是否稽核紀錄使用者的操作
  • 如何保護日誌檔案

應用程式風險分類 | sdwh.dev

威脅分類 STRIDE

  1. Spoofing : 偽造身分
  2. Tampering : 惡意竄改輸入與資料
  3. Repudiation : 無法稽核使用者曾經執行的軌跡
  4. Information Dsiclosure : 機敏資訊外洩
  5. Denial of Service : 系統服務可用性被阻斷
  6. Elevation of Privilege : 未正常的取得授權

MSDN - STRIDE

威脅風險評估 DREAD

  1. Dangerous Potential
  2. Reproduciblity
  3. Exploitability
  4. Affected Users
  5. Discoverability

每個項目的分數為 1 (Low), 2 (Medium), 3 (High)，加總所有項目的總分，最少為 5 分，最高為 15 分。

分數與 Rating 對照表：

Score Rating
5 - 7 Low
8 - 11 Medium
12 - 15 High

範例 1：

威脅描述： 應用系統中的前端圖片未進行輸入驗證，可能導致錯誤圖片上傳。

Damage：Low (1) - 損害較低，因為僅涉及錯誤圖片上傳，不會對系統和用戶造成重大損害。
Reproducibility：High (3) - 可重現性較高，因為攻擊者可以多次上傳錯誤圖片。
Exploitability：Low (1) - 易受攻擊性較低，攻擊者需要對圖片上傳機制有一定了解。
Affected users：Low (1) - 受影響用戶較少，僅影響那些上傳圖片的用戶。
Discoverability：High (3) - 可發現性較高，因為攻擊者可能通過測試發現這個漏洞。

總計：9 歸類為 Medium。

對應對策： 實施適當的輸入驗證和圖片處理機制，以確保只有合法的圖片被上傳。可以使用圖片處理庫來檢測圖片的有效性，並在後端進行進一步驗證。此外，可以設置一些限制，如圖片尺寸、格式等，以防止不正當的上傳。

範例 2：

威脅描述： 應用系統的身份驗證機制存在漏洞，可能被惡意使用者利用。

Damage：High (3) - 損害高，因為攻擊者可以獲得系統中的敏感資訊。
Reproducibility：Low (1) - 可重現性較低，因為漏洞可能較難被攻擊者再次利用。
Exploitability：High (3) - 易受攻擊性較高，因為身份驗證漏洞可能被廣泛利用。
Affected users：High (3) - 受影響用戶廣泛，所有使用該身份驗證機制的用戶都可能受到影響。
Discoverability：Medium (2) - 可發現性中等，攻擊者可能需要進行某些掃描或測試來發現此漏洞。

總計：12 歸類為 High。

對應對策： 基於最佳實踐和安全建議來設計和實施身份驗證機制。使用多因素身份驗證（MFA）來增加安全性，並確保密碼的儲存和傳輸都是加密的。進行安全測試，包括滲透測試和漏洞掃描，以發現和修復潛在的身份驗證漏洞。同時，設置監控機制，追蹤可疑活動並採取適當的應對措施。

MSDN - DREAD

開發階段

儘早在開發階段就開始源碼檢測 (Checkmarx, Fortify)，以達到資安實踐的 SHIFT LEFT，甚至是專案的建立之初就先進行首次的掃描。

掃描應使用最新版本的 OWASP Top 10，需要注意的是無掃出高、中風險，只是最低限度的資安要求，仍應積極處理潛在的各式威脅。

例如可以延伸往 CWE / SANS Top 25 去檢視是否可能存在相關風險，也可使用 OWASP Top 10 Proactive Controls ，主動採取可提升應用程式資安防護措施的控制措施。

開發階段應紀錄所採用的第三方套件、函式庫，並比對是否存在弱點 (Mend, Vulnerability Database)，若有弱點應評估是否需要更新版本或者採取其他對策。

WASC Threat Classification (Attack List / Weaknesses List)

📝《Hacksplaining》Developer 不能錯過的安全應用程式設計觀念

測驗階段

源碼檢測, Static Application Security Testing, Checkmarx / Fortify
弱點掃描, Vulnerability Test, Acunetix / Nessus / WebInspect / IBM Security AppScan
📝OWASP ASVS

部署階段

滲透測試, Penetration Test
組態管理
變更管理
持續整合 CI
持續部署 CD
SSL Server Test
Security Headers Scan

維運階段

SIEM

參考資料

技服中心 NCCST

系統安全發展流程實務_20160812v2

資訊系統安全強化要點

台北區網中心

2020 - 安全軟體發展生命週期(Secure SDLC)

2017 - 安全性軟體開發流程概論

研討會論文

安全軟體開發生命週期設計階段最佳實務之探討

科技部推動SSDLC經驗分享

#CyberSecurity #Web #SSDLC