讀軟體開發安全之道：概念、設計與實施10安全設計審查

躺柒發表於2024-08-27

1. 安全設計審查

1.1. Security Design Review，SDR

1.2. 將安全性融入軟體設計的最佳方法之一是戴上“安全帽”進行單獨的設計審查

1.3. 安全審查員是熟悉軟體執行的系統和環境，以及知道如何使用它的人，但他們不參與設計工作，這能夠給予他們距離感以保持客觀性

1.4. 最好從一箇中等大小的設計開始，這樣你不會覺得太難上手，或者從一個大型系統中分出一個元件並只審查這一部分內容

2. SDR基本概念

2.1. SDR只會佔用總設計時間的一小部分，卻能夠識別出重要的改進以增強安全性，或者為設計出適當的安全性解決方案提供有力的保證

2.2. 對於較大的設計，審查過程提供了一個有用的框架來識別和驗證主要的熱點

2.3. SDR可以帶來有價值的新見解，從而促進與安全性無關的設計變更

2.4. 如果計劃在設計（或設計迭代）完成且穩定時執行SDR，通常要選在功能審查之後但在設計最終確定之前，因為可能有需要更改的地方

  • 2.4.1. 不要將安全性作為功能審查的一部分，因為兩者的思維方式和關注領域完全不同

  • 2.4.2. 關注安全性也很重要，但聯合審查會傾向於更多地關注設計的運作，因此很難關注到安全性

2.5. 複雜的或安全性第一的設計，通常能夠受益於額外的初步SDR，也就是在設計開始形成但仍未完全成形時執行SDR，以便能夠獲得有關重大威脅和整體策略的早期資訊

  • 2.5.1. 設計師永遠不應忽視安全性，也不能依靠SDR為他們解決相關問題

  • 2.5.2. 安全審查員扮演的是支援角色，其職責是幫助設計師並確保他們能夠很好地完成工作

2.6. 文件是必不可少的

  • 2.6.1. 有效的SDR依賴於及時更新的文件，以便參與的各方對審查中的設計有準確和一致的理解

3. SDR流程

3.1. 軟體設計可以以無數不同的方式開展，你可以將相同的策略和分析應用於不是很正式的組織機構

  • 3.1.1. 每個人都有不同的風格

3.2. 6個階段

  • 3.2.1. 研究設計文件和支援文件，對專案建立基本的瞭解

  • 3.2.1.1. 閱讀文件，從全域性上理解設計

  • 3.2.1.2. 戴上你的“安全帽”​，以威脅意識的心態重新審視它

  • 3.2.1.3. 記筆記，記錄你的想法和觀察結果以供將來參考

  • 3.2.1.4. 為未來標記潛在問題，但在此階段進行大量安全分析還為時過早

  • 3.2.2. 對設計進行詢問，並就基本威脅提出澄清問題

  • 3.2.2.1. 確保設計檔案清晰完整

  • 3.2.2.2. 如果有遺漏或需要更正之處，請在文件中修正它們

  • 3.2.2.3. 對設計的理解要通透，但不一定要達到專家級

  • 3.2.2.4. 詢問團隊成員他們最擔心什麼，如果他們沒有安全性擔憂，請追問其原因

  • 3.2.2.5. 安全審查員提出的問題不必嚴格侷限於設計文件中的內容

  • 3.2.3. 識別出設計中最需要保障安全性的關鍵部分，以引起更密切的關注

  • 3.2.3.1. 將其作為目標並進行仔細分析

  • 3.2.3.2. 從CIA、黃金標準、資產、攻擊面和信任邊界的角度進行思考

  • 3.2.3.3. 檢查介面、儲存和通訊

  • 3.2.3.4. 從外向內（從最易暴露的攻擊面到最有價值的資產）審查，這也是態度堅決的攻擊者會做出的嘗試

  • 3.2.3.5. 評估設計中明確的安全問題的解決程度

  • 3.2.3.6. 如果需要，指出關鍵的保護措施，並在設計中將它們標註為重要特性

  • 3.2.4. 與設計師合作，識別風險並討論緩解措施

  • 3.2.4.1. 審查員要針對風險及其緩解措施提供安全性見解

  • 3.2.4.2. 勾畫出一個場景，以說明安全更改能夠獲得的最終回報，從而幫助說服設計師在設計中新增緩解措施

  • 3.2.4.3. 儘可能為問題提供多個解決方案，並幫助設計師瞭解這些替代方案的優勢和劣勢

  • 3.2.4.4. 要接受設計師的決定，因為他們要對設計負最終責任

  • 3.2.4.5. 記錄交流的想法，包括設計中會涵蓋或者不會涵蓋的內容

  • 3.2.5. 撰寫一份審查結果和建議的評估報告

  • 3.2.5.1. 審查結果是安全審查員對設計安全性的評估

>  3.2.5.1.1. 要考慮的潛在設計更改，以及對設計安全性的分析

>  3.2.5.1.2. 應該在顯著位置對設計師已經同意的更改進行標識，並在以後進行驗證

  • 3.2.5.2. 圍繞著解決安全風險的特定設計變更來組織報告

  • 3.2.5.3. 將大部分精力和筆墨花費在優先順序最高的問題上，而在較低優先順序的問題上少著筆墨

>  3.2.5.3.1. 必須(must)的排名最高，表示對於這一點來說，應該沒有其他選擇，並且通常還包含緊迫性

>  3.2.5.3.2. 需要(ought)排名中間，我用它來表示傾向於“必須”​，但我們可以進行討論的更改

>  3.2.5.3.3. 應該(should)在可選的推薦更改中排名最低

  • 3.2.5.4. 提出替代方案和策略，而不要嘗試做該由設計師做的工作

  • 3.2.5.5. 對審查的發現和建議進行優先順序排序

  • 3.2.5.6. 關注安全性，但也可以提供單獨的評論以供設計師參考

>  3.2.5.6.1. 要對SDR範圍之外的設計更為尊重，不要吹毛求疵，避免淡化安全性資訊

  • 3.2.5.7. 將設計師和審查員的角色分離至關重要，但在實踐中，實現這一點的做法會有很大的不同，這取決於每個人的職責和他們的協作能力

  • 3.2.5.8. 很有可能你或其他從事該軟體工作的人員在日後會希望有詳細記錄的資訊以供參考

  • 3.2.5.9. 作為審查員，當你與軟體設計師密切合作時，你可能可以將所需的更改直接合併到設計文件中，而不是在報告中列舉需要更改的問題

  • 3.2.6. 跟進後續的設計變更，在簽署前確認解決方案

  • 3.2.6.1. 對安全審查做出的設計變更結果進行跟進，以確認這些問題已被正確地解決

  • 3.2.6.2. 對於重大的安全設計更改，你可能希望與設計師協作以確保正確地進行更改

  • 3.2.6.3. 如果意見不同，審查員應該書寫一份宣告，說明雙方的立場和未遵循的具體建議，並將其標記為未解決的問題

  • 3.2.6.4. 在最好的情況下，設計師會將審查員視為安全輔助資源，並使其隨著時間的推移繼續參與到專案中

4. 評估設計的安全性

4.1. 4個問題

  • 4.1.1. 我們的工作是什麼？

  • 4.1.1.1. 審查員應該瞭解設計的整體目標，並將其作為審查的背景，即思考實現這個目標最安全的方法是什麼

  • 4.1.1.2. 可以自信地建議割捨那些會帶來風險且實際上並不必要的部分

  • 4.1.2. 哪裡有可能出錯？

  • 4.1.2.1. “安全帽”思想的用武之地，也是應用威脅建模的地方，即思考這個設計是否未能預見或低估了關鍵威脅

  • 4.1.2.2. 設計師僅僅意識到這些威脅是不夠的，他們必須已經確實創造了一種能夠承受這些威脅的設計

  • 4.1.3. 我們打算怎麼辦？

  • 4.1.3.1. 審查你在設計中發現的保護機制和緩解措施，即思考我們能否以更好的方式應對重要威脅

  • 4.1.3.2. 隨著審查員的研究，設計中的安全保護機制和緩解措施應該變得清晰

  • 4.1.3.3. 如果在減小安全風險方面設計做得不夠，那麼你應該逐項列出設計中缺少的內容

  • 4.1.3.4. 當設計中確實為給定的威脅提供了緩解措施時，審查員需要評估緩解措施的有效性，並考慮是否有更好的替代方案

  • 4.1.4. 我們幹得怎麼樣？

  • 4.1.4.1. 評估設計中的緩解措施是否足夠，是否需要更多工作，或者是否缺少了一些緩解措施，即思考設計的安全性如何，如果缺乏安全性，我們如何才能使其達到安全標準

  • 4.1.4.2. SDR可以快速識別出問題和機會，或者至少能夠為現在值得考慮的權衡決策提出建議

>  4.1.4.2.1. 以後你將無法如此輕鬆地進行更改
  • 4.1.4.3. 總結
>  4.1.4.3.1. 認為設計是安全的，沒有需要更改的地方

>  4.1.4.3.2. 設計是安全的，但建議進行一些更改，以增強其安全性

>  4.1.4.3.3. 對當前的設計有疑慮，並提供了一些建議，以增強其安全性

4.2. 針對大型設計的每個角落都進行深入研究是不切實際的，因此審查員需要儘快關注那些對安全至關重要的領域

  • 4.2.1. 審查員要留意攻擊面，並給予其應有的重視

  • 4.2.2. 攻擊面越容易訪問，就越有可能成為潛在的攻擊源，典型的最壞情況就是匿名的網際網路暴露

4.3. 根據你的技能和組織機構職責，你可能希望在SDR範圍內處理資訊隱私，或單獨處理

4.4. 軟體一旦釋出，似乎就有了自己的生命，隨著時間的推移，變化是不可避免的

  • 4.4.1. 設計文件應該是一個能夠跟蹤軟體架構形式演變的動態文件

  • 4.4.2. 版本化的文件提供了設計成熟度的重要記錄，或者在設計變得複雜時提供了重要記錄

5. 處理分歧

5.1. 良好的人際溝通對於成功執行SDR至關重要

5.2. SDR在本質上具有對抗性，因為審查員通常會在人們投入了巨資的設計中指出其風險和潛在的缺陷

5.3. 一旦設計師理解了問題，他們通常會開始討論那些審查員可能錯過的其他領域

5.4. 有人指出自己設計中的漏洞，是瞭解安全性的最佳方式

5.5. 在SDR過程中，我們無法透過單方面的演講來強調安全是所有事務中的重中之重

5.6. 準備SDR會議是一種平衡行為

  • 5.6.1. 事先準備的問題，以便會面時你能夠深挖安全問題

  • 5.6.2. 你可以自己找到答案的問題

  • 5.6.3. 最好在會議中探討的主題

  • 5.6.4. 你將在評估報告中包含的觀察結果，但不需要對其進行討論

5.7. 一個好的經驗法則是，如果缺失的資訊對許多人都有用，則值得記錄這個資訊，但如果它僅與你的特定需求相關，那麼你應該不那麼正式地提出這個問題

  • 5.7.1. 如有必要，你可以在評估報告中包含這些問題的詳細資訊

5.8. 在完成這次SDR後，產品團隊對安全性有了更好的理解，進而對他們自己的產品也有了更深入的瞭解

5.9. 當設計師和審查員未能達成共識時，他們應該對分歧達成共識

  • 5.9.1. 強烈的分歧幾乎總是源於基本假設的南轅北轍，一旦確定了基本假設，分歧通常會被解決

  • 5.9.2. 產生嚴重分歧的另一個主要原因是設計師沒有意識到資料機密性或完整性的重要性，這通常是因為他們沒有站在終端使用者的視角，或者沒有考慮所有可能的用例

相關文章