安全性簡報
重振威脅分析模型的程序
Adam Shostack
目錄
我同事 Ellen 的說法是，每個人隨時隨地都在建立威脅分析模型。我們會針對機場的安全性建立威脅分析模型。我們會針對住家建立威脅分析模型。我們會考量個人資產的種種威脅：包括家庭、珠寶，以及充滿情感又無可取代的相片 (不過這比較適用於我們這些有點年紀，照片尚無數位格式之年代的人)。我們會根據建築結構來建立威脅分析模型：這裡有面牆，有扇大觀景窗，還有一顆很好爬的樹，萬一忘了帶鑰匙就能派上用場。我們也會根據攻擊者來建立威脅分析模型。我們會擔心竊賊，也會害怕孩子失足而掉進泳池內。我們還會擔心天災人禍，像是地震、暴風雪或龍捲風。
如果換成管理顧問的口吻，我會說您要套用成熟、多面向的評量程序，同時在各案例之間大幅仰賴啟發式學習法並降低重複性。然而，您可能無法料想到所有可能發生的情況，也無法針對所有可能發生的攻擊採取防禦措施。您的家中可能沒有擬出一套居家防禦管理計劃，更不可能執行居家侵入性測試。
但是在建置軟體時，不論我們採取捷徑式或傳統式的開發模型，都必須對建置目標達成共識，溝通要建置與不建置的項目，以確認我們建置的軟體是正確的。過去幾年來，大家逐漸認為威脅分析模型是沈重、官僚的程序。不過有些不錯的理由值得加入這些程序；我將討論這些原因、這些程序的相關經驗談，以及如何威脅分析模型變得更有趣，同時使威脅分析模型變成有效率、敏捷又友善的活動，讓每個人都能做到。
建立威脅分析模型的方法
有許多東西都稱為威脅分析模型。重點並不是要爭論「單一最佳方法」，而是要根據您的需求、技術和能力以及時間表，來找出最適合您的方法。在這樣的方法中，有些人會問：「你的威脅分析模型是什麼？」，或者問「你曾經為該元件建立威脅分析模型嗎？」一是必要條件的定義，另一則是設計的分析。在 Microsoft，我們幾乎都是談論後者這項技巧。
其實威脅分析模型有很多種，多到我根本無法在一篇專欄中討論。另外還有極多元化的目標。您的威脅分析模型的程序到底應該要求速度或者深度呢？是要專注於保證品質和完整性，或者著重於使用的便利性？每次開會是否應邀請專家或開發人員參與？有沒有必要遵守的組織或產業規則，例如 Microsoft® Security Development Lifecycle (SDL) 或者醫療設備生產規定？高階目標應該把焦點放在要儘早了解安全性議題，以便於設計期間解決問題，而非在事後再嘗試克服設計上的缺陷。
建立威脅分析模型活動的主要方法如下：
資產 以資產導向的威脅分析模型，有如在思考您需要保護的家中物品。您一開始要先列出軟體相關聯的資產，接著思考攻擊者可能會如何危及這些資產。範例包括儲存客戶信用卡資料的資料庫，或者包含已加密密碼的檔案。
有些人可能會將資產解譯為威脅分析模型圖表的元素，以為網路伺服器本身就是一項資產。這種想法太瘋狂了。數位資產指的是攻擊者想要讀取、竄改或拒絕讓您使用的事物。
攻擊者 以攻擊者導向的威脅分析模型，包括思考誰會想要您的資產，並且要藉由了解這些攻擊者的能力，進而得知他們可能使用的攻擊方式。若您的對手是個外來軍團，具有已知的策略信念、實體限制，且需要長時間來建立武器系統，這個方法最為管用。然而，若您的敵人是一群組織鬆散的匿名駭客團體，這招恐怕就無效了。
大體上而言，我們不確定這在威脅分析模型中是否有用。對某些人而言，「洞悉駭客思緒」的方式可以是有效的設計分析。不過，能否複製這樣的程序來訓練更多人，則必須持保留的態度。若您準備要從駭客的角度著手，或許值得使用標準組合。因為它將有助於排除某些負面案例。
軟體設計 以設計導向的威脅分析模型，是根據您門戶位置的設計。您需要畫出圖表，並分析圖中的每件事物可能會在哪裡出錯 (這是現今 SDL 威脅分析模型之程序的本質，因為軟體界每個人都會在白板上畫圖表)。
軟體中等同於門戶的包括各種形式的攻擊面，例如檔案剖析器或網路接聽服務 -- 通訊端、遠端程序呼叫 (RPC) 服務、Web 服務描述語言 (WSDL) 介面或者 AJAX API。上述信任的界限，是攻擊者最可能入侵的位置。
速成威脅分析模型
威脅分析模型可以很簡潔。根據 [圖 1] 所示的程序，以下是基本威脅分析模型之程序的大綱，可讓您快速又輕鬆地上手：
- 畫出應用程式圖表，並用來在白板前說明應用程式 (請見 [圖 2)。使用圓圈代表程式碼，方塊代表其外部的東西 (人員、伺服器)，並以桶型代表儲存體。我們的團隊使用外形有趣的平行線來代表資料存放區。使用虛線來畫出信任界限，以區別網域。
- 藉由腦力激盪找出威脅。若遭遇瓶頸，請針對應用程式的每個元素套用 STRIDE 威脅分析模型，如 [圖 3] 所述。暫時別擔心程式的修復，只要讓腦力激盪順利進行即可。
- 思考威脅是否為整體性的，或是完全零散的，以考慮重新設計的因素。無論如何，最好設計出一個元件，或者加入一個元件來解決中心問題。若所有威脅皆位於單一位置，可能代表您只有顧到前門，而忽略了其他部分。
- 降低第一順位的風險。放寬範圍，不要深度切入。排列威脅的優先順序以及降低風險之方式的優先順序，會有所幫助。威脅的第一順位是開門。降低風險的第一順位則是上鎖。威脅的第二順位，是有人偷開鎖或是鎖壞了。降低風險的第二順位，包括安裝一把好鎖和一扇堅固的門。防禦方式的第三順位，可能是在門上加裝警報系統，而且為了降低有人切斷訊號線的風險，您可從定期傳送訊息以示運作正常。就軟體而言，若您沒有先考慮到門鎖，而是先擔心有人切斷警報系統的線路，那麼您的順序就搞錯了。
- 提出錯誤報告，以便針對威脅分析模型所找出的問題進行修復。
圖 1 威脅分析模型的程序 (按一下影像以放大圖片)
圖 2 繪製您的應用程式有助於建立威脅分析模型 (按一下影像以放大圖片)
圖 3 STRIDE 威脅分析模型
| 安全性威脅 |
屬性 |
定義 |
範例 |
| 詐騙 |
驗證 |
模仿某事或某人。 |
假冒為以下任一者：billg、microsoft.com 或 ntdll.dll。 |
| 竄改 |
完整性 |
修改資料或程式碼。 |
修改磁碟或 DVD 上的 DLL，或者修改周遊 LAN 的封包。 |
| 否認 |
不可否認性 |
宣告未執行某動作。 |
「我並未傳送該封電子郵件」，「我沒有修改那個檔案」，「親愛的，我絕對沒看過那個網站！」 |
| 洩漏資訊 |
保密性 |
將資訊洩漏給未經授權的人。 |
允許某人讀取 Windows 原始碼；將客戶清單發佈到網站上。 |
| 拒絕服務 |
可用性 |
拒絕或降低使用者服務。 |
造成 Windows 或網站當機、傳送封包並吸收 CPU 時間，或者將封包傳遞至黑洞。 |
| 提高權限 |
授權 |
取得未經授權的功能。 |
典型的範例是允許遠端網際網路使用者執行命令，但從有限的使用者成為管理員亦為 EoP 的範例。 |
知道何時結束
當您的圖表顯示出系統所有相關部分，並完成圖表中所有元素的 STRIDE 模型，就表示您做的很好 (如果您也提出了每個弱點的錯誤報告就更好)。
不過，這說起來就像是您只要檢查過所有門窗皆已鎖好後，就大工告成了。這樣或許已經足夠；可能您的時間只夠做這麼多。又或者您打算更深度思考已就定位的防禦機制還會有哪些漏洞。
您可以更深入的程度，大多端視您的組織或是客戶的風險承受度而定。另外也必須視您的預算和經驗來決定。您或許只想以合理範圍內最快的速度來執行威脅分析模型的程序，以證實成功與否。或許您正在設計某些安全性關鍵的控制系統，所以需要花許多時間進行深入分析。
因此，何時結束的這個問題其實需要有所取捨。首先，您需要考量相關政策、法令，規範的要求。然後您還必須評估欲開發系統的風險。最後，您必須針對威脅分析模型的程序以及任何為降低風險與測試的工作，評估所需時間與資源。
推動威脅分析模型的程序
威脅分析模型不會自行建立，必須有人推動才行。而推動者也會大幅影響其效能。若能由一位或多位重視安全性的人員來推動，就能有效地在整個組織中推動威脅分析模型的建立。
問題在於如何或者是否應該讓其他人參與。這是一項同時牽涉文化與資源的問題。若這些熱血人士可以將一切威脅分析模型化、和大家分享成果，並且將發現的問題修復，那就太好了！何必要麻煩其他人？
但是有些時候，需要負責的專案工作量，會遠比這些注重安全性的人士能處理的還要多，因此您必須找其他人參與。Microsoft 發現安全性專家有助於威脅分析模型的建立，但卻不一定找得到。
所謂的安全性專家，是一位專注於安全性且能夠組織化地考量問題的專業人員。他必須了解在您的設計內容中，何謂否認性威脅。這位專家或許應該擁有某些證照。他應該能夠指出您程式碼及作業中的安全性缺陷。她應該定期參與 (至少要有興趣參與) 例如 SANS 或 BlackHat 的會議，抑或她曾經出現在 Microsoft 資訊安全佈告欄的感謝名單中。
藉由提供結構資訊並回應作品上的意見，將內容細分為易於處理的部分區塊，並為每一個區塊提供相關規則和自我檢測技巧，就能夠獲得不錯的成果。不過，若將威脅分析模型細分為太多太零散的部分，並且賦予太多規則 (或錯誤的規則)，則有可能引來排斥，進而使威脅分析模型變成一項煩瑣的雜務。因此您細分的方式，必須依照可參與的專家人數，以及這些專家能夠投入的時間而定。
維持同步處理：因應變化
計劃總是會改變。這是無法避免的事。發生這種情況時，就必須讓相關文件與其他人腦袋裡已深記的實際計劃進行同步處理。無論您有多機靈，一個大型專案絕對會有架構文件。或許是一組大型牆面尺寸的 Visio® 圖表，又或許是個擦不掉的白板。
就威脅分析模型而言，您必須了解哪些東西會在架構上增添信任界限。在這種情況下，您必須考量這些新威脅的影響。
有時候威脅是直接的。例如，若您將某元件所接聽的通訊埠改為 80。當該元件遭遇直接威脅時，您就可以輕易發現威脅、排除威脅，再繼續工作。
有些時候，威脅則是間接的。例如，若您決定從 Active Directory® 和 Lightweight Directory Access Protocol (LDAP) 取得組態資料。這可能需要幾項新元件 (目錄介面及抽象層，以便進行切換)，但也同時需要變更組態資料。資料原本或許是由系統管理員輸入到您的 GUI。現在則會透過網路，以多種不同的通訊協定傳入。您應該要在抽象層仔細驗證資料，也需要注意如何讀取和處理組態資料。
幫幫忙，我昏頭了！
您或許會發現自己竟坐在桌前驚呼：「我們現在該怎麼辦？」也許您無法理解整個程序。也許有一個步驟把您難倒了。以下是 SDL 團隊曾遇過的一些問題，以及解決的方法：
有些團隊對於圖表的繪製很難。若您不了解系統的功用，請找熟悉系統的人，或者細分威脅分析模型的程序，並花時間了解您接手的東西。
若您不知道系統應該做什麼 (也許您正在撰寫新系統，且有兩個彼此競爭的設計方案)，威脅分析模型可以幫助您脫離停滯的決策進度。這時請將兩種設計都繪出，然後詢問：「哪一個的弱點比較嚴重？」
即使您不知道如何表現某元素，也不用太操心。若您用了錯誤的元素類型，到時候還是會發現的。重點是，不論程式碼是誰撰寫的，所有您負責的程式碼都應該視為程序。您讀取和寫入的所有資料，皆儲存在資料存放區。
您也有可能發現列舉威脅方面的問題。首先，絕對不要讓自己陷入單一威脅的問題而停擺。先用旗標標示起來，後續再回頭處理。如果這樣仍無法解決，請參閱 Larry Osterman 的威脅分析模型系列文章 (
go.microsoft.com/fwlink/?LinkId=118281)。另外， Michael Howard 撰寫的 Writing Secure Code 以及 The Security Development Lifecycle 等書籍，也都值得參考。
針對威脅分析模型的驗證以及降低風險計劃等問題，請找出圖表是否可完整表現程式碼，以及開發人員和軟體測試人員之間是否有共識。請確認您是否已為各元素的每一種威脅類型列舉威脅 (請見 2006 年 11 月的 MSDN
® Magazine 文章＜使用 STRIDE 方法發掘安全性設計瑕疵＞，位於
msdn.microsoft.com/magazine/cc163519)。最後，請確認是否有為每一項威脅提出錯誤報告，並已確實修復。
若您剛好有位專家在身旁，可以請求他的協助。即使是專家都會互相問道：「您認為應該用什麼方法來解決這個問題？」若您身邊沒有專家可以詢問，不妨試著找一位專家，不論是以聘任的方式或在部落格上提出問題皆可。
別讓自己為了單一問題而陷入困境。威脅分析模型對您而言實在太重要，不容略過。而且千萬記得要享受其中的樂趣。能夠在產品出貨之前先發現並解決問題，總比事後的修復工作更有價值。