本文章是由機器翻譯。

安全簡報

SDL 威脅建模工具入門

Adam Shostack

目錄

啟動威脅建模過程
分析威脅
環境螢幕
跟蹤報表
操作功能表
威脅建模會議
考慮資產

圖 1 威脅建模過程

2008 年 11 月，Microsoft 宣佈安全性開發生命週期 (SDL) 威脅建模工具的通用版本將在 MSDN 上提供免費下載。本專欄將跟隨一個團隊來體驗 SDL 威脅建模方法的整個過程，並向您展示如何使用這一新工具來開發強大的威脅模型作為安全流程的主幹。

本專欄並不是 SDL 威脅建模的初級讀本。要瞭解基本內容，請參閱我在 2006 年 11 月刊的《MSDN 雜誌》中與他人合著的關於使用 STRIDE 方法的文章“威脅建模：使用 STRIDE 方法發現安全設計缺陷”。圖 1 簡要概述了這一過程。

啟動威脅建模過程

當您啟動 SDL 威脅建模工具時，將會看到左下角與 Microsoft Office Outlook 非常相似，均包括四個螢幕：圖表、分析、環境和報表（有關詳細資訊，請參見圖 2）。請注意，這些螢幕與圖 1 中所示的略圖稍有不同，因為在威脅和緩解措施緊密相關的情況下將它們放在一起考慮是很有必要的。

在本章中，我將跟隨 Deb（開發人員）、Paul（專案經理）和 Tim（測試人員）體驗開發第一個威脅模型的過程，同時還將對此工具的各個螢幕逐一加以介紹。

“你好 Deb，我一直在研究這個威脅建模圖表，想和你一起體驗一下，以便確保我們得到了準確的細節。”

“沒問題，Paul！來吧。”

Paul 拿出利用威脅建模工具的“Diagrams only”（僅圖表）報表功能製成的列印輸出圖，如圖 3所示。

“Paul，我以前從來沒有見過這些圖表。它看起來非常簡單，你能簡單介紹一下不同形狀所代表的含義嗎？”

“具體含義是這樣的，Carl（我們的普通客戶角色）被繪製為一個外部實體（矩形）。他向我們的 Web 伺服器發出命令（圓圈可以是任何運行代碼，箭頭指示通信方向）。Web 伺服器將會諮詢資料庫（資料庫與我們存儲資料的任何位置一樣，用兩條平行線表示）。此系統稱為資料流程關係圖 (DFD)。Wikipedia 曾就 DFD 撰寫了一篇很翔實的文章。其中唯一沒有涉及的內容是由不同人員控制的不同位置之間用虛線表示的信任邊界。例如，您知道 IT 專業人員要求我們使用他們的 Active Directory 系統來註冊登錄資訊，因此 Active Directory 顯示在我們的控制範圍之外。”

圖 3 Paul 的 DFD 圖

該工具啟動後，將顯示此圖表螢幕。這是 Paul 使用 Visio 工具和提供的範本來繪製其 DFD 的位置（請參見圖 4）。儘管這是 Paul 第一次使用，但他也感到得心應手，因為作為 SDL 的一部分，左側的驗證程式根據他使用威脅建模的體驗為其提供了回饋。當他發現自己的繪圖有些複雜時，他通過按右鍵右上角的上下文資料夾添加了一些附加的詳細資訊，以便能夠創建複雜的分層圖。

圖 4 圖表螢幕

分析威脅

當 Paul 打開分析螢幕（請參見圖 5）時，他有點猶豫了。螢幕中出現了一個很長的威脅清單，這些威脅都是從哪裡來的呢？這些都是此工具使用被稱為“依據元素的 STRIDE”的 SDL 方法構建的。其理念是軟體通常會遇到可預測的一組威脅（如圖 5 中所示的威脅）。一些安全專家希望先追擊駭客，因為這種追擊本身會很有趣。我認為要保護您的家庭財產，首先應確保各扇門窗都安裝了某種類型的鎖，然後再考慮報警系統。同理，首先應按一下分析螢幕中的任意行，從“依據元素的 STRIDE”開始著手。

圖 5 分析螢幕

Paul 首先在元素清單中選擇了 database。他在螢幕頂部發現 "database" 是一個資料存儲庫，因此可能會遭到篡改、資訊洩漏和拒絕服務攻擊等威脅。他繼續往下閱讀，隨後的問題可説明他思考他人可能會採用什麼樣的手段來篡改資料，他意識到沒有人指定哪些人能夠連接到該資料庫。白板圖表和一些簡單的規則揭示了第一個威脅！威脅建模得一分。

經過幾分鐘的討論之後，他們意識到需要考慮存取控制和角色。Paul 在兩個威脅中填充了幾點注意事項。第一個注意事項是“無存取控制計畫”。他還將工作項歸檔到其 Team Foundation Server (TFS) 資料庫中。第二個注意事項是“存取控制計畫需要角色清單”。Paul 然後開始研究 TFS，但又產生了依賴于第一個錯誤的另一個錯誤。

Paul 在研究資訊洩漏時，意識到他們的存取控制計畫需要一些唯讀帳戶來進行審核和報表生成。他拿不准這算不算是一個新威脅，後來他認為不是，因為緩解措施完全相同，隨後他在 TFS 中對該錯誤進行了編輯。接下來他決定證明此威脅在其他位置已有所緩解，並寫下 "covered in TFS bug #235"。他並不十分確定這是否合適，但這的確是證書功能的目的（請參見圖 6）。

圖 6 證明威脅並未施加

他還對資訊洩漏做了一些考慮，意識到備份磁帶需要加密，但那屬於實施作業（我稍後將介紹他如何對此進行跟蹤，在那之前先介紹一個相關功能：位於頂部的“auto-generate threats for this element”（自動為此元素生成威脅）核取方塊）。

自動生成功能適用于一些大型團隊，他們擁有許多威脅模型，同時還有辦法確保測試人員和專案經理都關注威脅模型中的內容。因此，在這種情況下，Paul 可能會說是 Phil 負責他想要針對上下文顯示的多個元素以及它們與此功能交互的方式。預設情況下，自動生成框會被選中，但 Paul 可以取消選中它並聲明自己認為這是 Phil 的功能。

環境螢幕

由於擔心加密備份磁帶操作，Paul 打開了環境螢幕，看到了有關外部安全注意事項的部分（請參見圖 7）。他在那裡強調指出操作必須處理磁帶備份。他必須確保操作具有該工具的副本。

圖 7 外部安全注意事項

處在此螢幕中時，他想知道文檔標頭部分的內容，後來發現那裡有很多指導文本，說明這裡正是用來確定誰擁有該威脅模型的地方，另外還可以瞭解到威脅模型的用途等。他填充了相應的內容，並希望可以包括 Contoso 專案跟蹤號碼。

通過系統地遍歷樹中的各個元素，Paul 注意到對 SQL Server 和 Fabrikam Foxy Web Widgets 2.3 小元件庫存在依賴性。Paul 添加了一個備註，讓 Tim 對此進行調查，以確保它們都是最新的，並且會從 Fabrikam 獲得安全通知。

跟蹤報表

有五個威脅建模報表可供使用：

分析報表此報表為安全顧問或諮詢人員而設計，供其查看威脅模型，但實際上任何人都可以使用它來查看哪些圖表驗證問題已建立、哪些空白威脅尚未填充、哪些威脅沒有任何緩解措施、哪些威脅已經證明或者已被標記為不生成威脅。

威脅模型報表此報表包含輸入到威脅模型中的資訊，它們都顯示在單個資料頁檢視中。

僅圖表 此報表設計用於簡化圖表的列印。有些人喜歡將工作所需的內容列印到紙上，這可以使其在只需要圖表時不必列印整個報表。

錯誤報表此報表顯示已從威脅模型歸檔的錯誤及其狀態。

模糊報表 模糊報表使用圖表製作步驟中提供的體系結構資訊來提供模糊目標的優先順序清單。模糊化處理屬於一種測試技術，它牽涉到為程式生成隨機輸入內容。令人吃驚的是，即使是不錯的模糊化處理也可能會使任務崩潰，而其中的許多崩潰都是可被濫用的。（有關模糊測試的詳細資訊，請參閱為 Team System 創建自訂的測試介面提供程式或Microsoft 模糊測試和會審流程。）

操作功能表

“Action”（操作）功能表下包含幾個很有用的功能：縮略圖視圖、錯誤跟蹤設置以及團隊主管模式。縮略圖視圖使您即使在其他螢幕中，也可以輕鬆訪問圖表。如果您的圖表非常複雜，而您又想在分析模型時在螢幕上顯示它，則此功能會非常有用。它會自動調整縮略圖的大小使其佔用視窗的大部分區域，從而使您在重新調整其大小時整個圖表都在可視範圍內。

如果您只想記錄錯誤而不輸入任何錯誤資訊，錯誤跟蹤對話方塊將會彈出來提示您，但您也可以通過操作功能表隨時調用此對話方塊。有一個非常簡單的 XML 檔，利用它可以定義要填充的欄位，或者也可以只編輯這些欄位（假設“use template”（使用範本）框未選中）。記錄下來的錯誤會被自動加上 "TM:[threat] affects [element]" 標題，而內容將根據威脅和緩解措施資訊進行預填充。這些欄位可以被刪除，方法是選中它們並點擊 Delete 鍵。

團隊主管模式會在描述環境螢幕中顯示一部分新內容，被稱為“範本設置”。它允許團隊主管更改指導問題並設置一個預設位置來保存威脅模型。團隊主管還可以編輯文檔標頭資訊中的欄位，添加和刪除一些內容以適合具體的環境。

由於希望早些完成這些操作，故 Paul 添加了 Contoso 專案跟蹤號碼作為新欄位。在團隊主管模式中保存的任何威脅模型都可用作範本。（實際上，任何威脅模型都可以用作範本來完成更多其他工作。）

更改指導問題包括編輯 XML 檔，此工作將從 SDL 威脅建模工具的 \Data 資料夾開始。其格式非常容易掌握。

威脅建模會議

當 Paul 給大家發送其威脅模型時，測試人員 Tim 非常不以為然。所有事情都突然湧向他，他問 Paul：“你們作為專案經理始終都認為一切都能正常運行，是吧？”

當您瞭解到測試人員及其懷疑態度可能會對威脅模型起到巨大的補充作用時，您可能感到非常驚訝。出於這個原因，許多團隊都要求其測試人員來領導威脅建模過程。在本方案中，在 Tim 接手了威脅模型之後，他召開了兩次威脅建模會議：一次的主題是同步過程並介紹圖表，另一次的主題是審核並簽字認可威脅。

在第一次會議中，Tim 花了 10 分鐘的時間向所有人介紹了 SDL 威脅建模過程。然後，他提取出威脅模型圖表並開始詳細說明。不到五分鐘，就找出了一個非常重要的缺失元件。

幾分鐘後，Tim 和 Paul 開始深入討論 Web 伺服器的實際構建方式。這並不是使會議進行下去的理想方法，但所有人最終都認為及早發現差異會為以後的工作節省大量時間。

在第二次會議中，團隊遍歷了這些威脅，討論了一些解決方法，並針對威脅模型做簽字認可。他們將文檔簽入到原始程式碼控制中，然後繼續進行開發。

考慮資產

一些已經建立了威脅模型的讀者可能會注意到我們根本沒有談及資產。我們發現，許多軟體工程師對其軟體的瞭解要勝過對資產概念以及哪些資產可能會受到攻擊者青睞的瞭解。

如果您要對房子進行威脅建模，可能會首先考慮您的家人或那些承載著豐富情感的照片或價值不菲的藝術品。也可能會首先考慮可能的入侵者以及當前的安全系統。或者會首先考慮一些地形，例如泳池或前廊。這些都與考慮資產、攻擊者或軟體設計相似。這三種方法中的任何一種都能發揮作用。

我們這裡介紹的威脅建模方法要比 Microsoft 過去實現的方法簡單得多。Microsoft SDL 團隊發現這種軟體設計方法對許多團隊而言確實非常有效。我們希望這其中也包括您的團隊。

請將您想詢問的問題和提出的意見發送至briefs@microsoft.com。

Adam Shostack 是 Microsoft 安全性開發生命週期 (SDL) 團隊的專案經理。他負責開發 SDL 的威脅建模元件。