1. 組織一個威脅模型小組
2. 把程式分解
3. 找出已知的系統威脅
4. 由最高風險而下，依序為風險排序
5. 選擇回應威脅的方式
6. 選擇能避免威脅的技術
7. 由能避免威脅的技術中挑選一個適當的技術出來
2. 在進行威脅模型工作前，告訴所有的參與者，會議的目的並不是在會議解決問題，而是確認應用程式的元件，及它們的互動方式，及最後盡量找出會威脅安全的威脅。設計及程式變更(及爭論)在後面的會議再行討論。然而，採用一些減輕威脅的技術是不可避免的，不要落入太多的細節，在微軟我們稱之落入老鼠洞 (rat hole)。
3. 很多的錯誤，都是來自錯誤的資料假設而引發安全臭蟲，當資料自非信任的領域中，進入到信任的領域時，最常發生這類型的錯誤。
4. 在定義資料流程圖的範圍時，思考下列幾點:
* 忽略應用程式內部的運作問題。在這個階段，事情是如何運作及發展的並不重要，我們所定義的是範圍，不是功能內容。
* 系統所要回應的事件或請求為何?
* 處理程序應該要如何回應?
* 定義每個有關請求及回應的資料來源。有些資料來源是持續不變的(檔案、登錄值、資料庫)，而其他的資料則可能是短暫的 (如暫存資料)
* 確認每個回應的回應對象
5. 在建立資料流程圖時，你應該要遵守一些簡單的規則
* 一個處理程序必須至少有一個資料輸入及一個資料輸出
* 所有的資料流會在一個處理程序中被啟動或者是暫停
* 資料儲存經由資料流連接處理程序
* 資料儲存彼此間無法直接連接，必須通過一個處理程序
* 處理程序名稱是動詞及名詞或是動詞片語 (ex: 顯示股價，計算成績)
* 資料流程名稱是名詞或是名詞成語 (ex: 股價、成績)
* 外部單元或是互動者的名稱都是所謂的名稱 (ex: 交易員、考生)
* 資料儲存名稱是名詞 (ex: 股票資料、成績結果資料)
6. 在製作威脅模型時，別落入分析癱瘓 (analysis paralysis)的陷阱中 --- 只要深入到某個程度來判斷威脅即可。分析癱瘓是指一群人陷入無窮盡的討論分析中，直到專案被取消才會停的狀態。
7. 當你判斷威脅時，查看每個應用程式中的每個元件並且詢問下列的問題
* 未經授權的使用者可以檢視這些機密的網路資料嗎?
* 不可靠的使用者可以在資料庫中修正專屬於他人的資料嗎?
* 有人可以拒絕使用者使用這個應用程式服務嗎?
* 有人可以從提高自己的權限的方式，自這些元件或者是功能中取得像是系統管理員一樣的功能嗎?
8. 你可以將安全性想成威脅、弱點、及資產的同義詞。三種成分可以被視為火的三元素：熱度、柴火及氧氣。若拿走一個元素，火就會被熄滅。在安全性也是相當的，如果你移除了資源，潛在的攻擊者就沒有攻擊目標。如果你移除了系統的弱點，攻擊者就無法進一步的存取資源。最後，如果你移除了攻擊者，那就沒有什麼好擔心的了。然而，在這個世界上，有很多資源值得我們保護，系統一定有瑕疵，因此就有很多威脅。
9. 檢視威脅及弱點
* 它是本機或者遠端的威脅? 攻擊者可以不用取得本機存取權限就進行攻擊嗎?
* 威脅的順序為何? 快速的增強權限嗎? 如果是的話，它的層級到哪? 會因此而洩漏機密嗎?
* 需要採取一些行動才能成功攻擊嗎?
10. 當你使用你選擇的評估系統來思考整體的風險評估時，你必須思考攻擊最可能的途徑 (或者是攻擊最後出現的地方)。
11. 什麼都不要做對你的商業活動以及用戶端是很糟糕的一件事情，因為這樣做會讓他們暴露於風險下。若因什麼理由而讓你決定什麼都不要做，你至少應該檢查一下是否哪個軟體功能是威脅發生的原因，而你可以將它預設為關閉的。
12. Threat Mitigation
13. Authentication
-
Basic authentication
-
Digest authentication
-
Forms-based authentication
-
Passport authentication
-
Windows authentication
-
NT LAN Manager (NTLM) authentication
-
Kerberos v5 authentication
-
X.509 certificate authentication
-
Internet Protocol Security (IPSec)
-
RADIUS
14. 抑制 (Throttling) 代表限制對你的統提出存取要求的數量。舉例來說，你可能會允許較少量的使用者以匿名的方式存取你的系統，而允許較多數的使用者以通過認證的身分存取你的系統。這樣做的原因是因為攻擊者可能會因為需要通過認證才能存取系統而放棄攻擊。限制匿名使用者的數量很重要。
沒有留言:
張貼留言