驅動程式的威脅模型化

驅動程式寫入器和架構設計人員應該讓威脅模型化成為任何驅動程序設計程式不可或缺的一部分。 本主題提供建立 Windows 驅動程式威脅模型的指導方針。

安全性應該是任何驅動程式的基本設計點。 任何成功的產品都是目標。 如果您要撰寫適用於 Windows 的驅動程式，則必須假設有時候，有人會嘗試使用驅動程式來危害系統安全性。

設計安全驅動程式牽涉到：

• 識別驅動程式可能容易受到攻擊的點。
• 分析每個這類點可能掛接的攻擊類型。
• 確保驅動程序的設計方式是用來抵禦這類攻擊。

威脅模型化是這些重要設計工作的結構化方法。 威脅模型是分類和分析資產威脅的方法。 從驅動程式寫入器的觀點來看，資產是計算機或網路上的硬體、軟體和數據。

威脅模型可回答下列問題：

• 哪些資產需要保護？
• 資產易受攻擊的威脅為何？
• 每個威脅的重要性或可能有多重要？
• 如何減輕威脅？

威脅模型化是軟體設計的重要部分，因為它可確保安全性內建於產品中，而不是在事後解決。 良好的威脅模型有助於在設計程式期間找出並防止錯誤，進而消除稍後可能成本高昂的修補程式，以及貴組織的可能信譽損害。

本節將威脅模型化原則套用至驅動程序設計，並提供驅動程式可能易受攻擊的威脅範例。 如需軟體設計威脅模型化更完整的描述，請參閱這些資源。

• Microsoft SDL 網站：

  https://www.microsoft.com/sdl

• Microsoft SDL 的簡化實作：

  下載白皮書

• 此部落格文章說明如何下載 安全開發生命週期的免費複本：SDL，作者：Michael Howard 和 Steve Lipner：

  https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

建立驅動程序的威脅模型

建立威脅模型需要徹底瞭解驅動程式的設計、可能公開驅動程式的威脅類型，以及惡意探索特定威脅的安全性攻擊結果。 為驅動程式建立威脅模型之後，您可以判斷如何減輕潛在威脅。

在驅動程式設計期間以組織且結構化的方式執行威脅模型化時，威脅模型化最有效，而不是在程式代碼撰寫期間不複雜。 結構化方法會增加您在設計中發現弱點的可能性，進而協助確保模型全面性。

組織威脅模型化工作的其中一種方式是遵循下列步驟：

1. 建立結構化圖表，顯示透過驅動程序的數據流。 包含驅動程式執行的所有可能工作，以及驅動程式所有輸入和輸出的來源和目的地。 正式數據流程圖或類似的結構化圖表可協助您透過驅動程式分析數據的路徑，並識別驅動程式的外部介面、界限和互動。
2. 根據數據流程圖分析潛在的安全性威脅。
3. 評估您在上一個步驟中所識別的威脅，並判斷如何減輕威脅。

建立數據流程圖

數據流程圖以概念形式顯示驅動程式與其互動的外部實體之間的數據流，通常是操作系統、用戶進程和裝置。 正式數據流程圖使用下列符號：

下圖顯示假設核心模式 Windows 驅動程式模型 (WDM) 驅動程式的範例數據流程圖。 不論特定驅動程式類型的架構為何，概念模型都相同：顯示所有數據路徑，並識別進入或結束驅動程式的每個數據源。

注意 上圖顯示直接在使用者程式與驅動程式之間流動的數據，並省略任何中繼驅動程式。 不過，實際上，所有要求都會通過 I/O 管理員，而且可能會在到達特定驅動程式之前周遊一或多個較高層級的驅動程式。 此圖省略這些中繼步驟，以強調原始數據源的重要性，以及提供數據的線程內容。 內核模式驅動程式必須驗證源自使用者模式的數據。

由於來自操作系統的要求、來自用戶進程的要求，或要求 (通常會中斷裝置) ，因此資訊會進入驅動程式。

上圖中的驅動程式會以數種要求類型從作業系統接收資料：

• 透過對 DriverEntry、 DriverUnload 和 AddDevice 例程的呼叫，對驅動程式及其裝置執行系統管理工作的要求
• (IRP_MJ_PNP) 隨插即用 要求
• 電源管理要求 (IRP_MJ_POWER)
• 內部裝置 I/O 控制要求 (IRP_MJ_INTERNAL_DEVICE_CONTROL)

為了回應這些要求，數據會從驅動程式流回操作系統作為狀態資訊。 圖中的驅動程式會從下列類型的要求中接收使用者進程的數據：

• 建立、讀取和寫入要求 (IRP_MJ_CREATE、IRP_MJ_READ或IRP_MJ_WRITE)
• (IRP_MJ_DEVICE_ CONTROL) 公用裝置 I/O 控制要求

為了回應這些要求，輸出數據和狀態資訊會從驅動程式回到用戶進程。

最後，驅動程式會因為裝置 I/O 作業或使用者動作而從裝置接收資料 (，例如開啟 CD 磁碟驅動器上的匣，) 變更裝置狀態。 同樣地，驅動程序的數據會在 I/O 作業期間流向裝置，並變更裝置狀態。

上圖顯示驅動程序數據流在廣泛的概念層級。 每個圓形都代表相對大型的工作，而且缺少詳細數據。 在某些情況下，例如範例的一層圖表就足以了解數據源和路徑。 如果您的驅動程式處理來自不同來源的許多不同類型的 I/O 要求，您可能需要建立一或多個額外的圖表，以顯示更多詳細數據。 例如，標示為「處理 I/O 要求」的圓形可能會展開為個別圖表，如下圖所示。

第二個圖表顯示第一張圖表中每種 I/O 要求類型的個別工作。 (為了簡單起見，已省略裝置的數據路徑。)

外部實體和圖表中顯示的輸入和輸出類型可能會因裝置類型而異。 例如，Windows 提供許多常見裝置類型的類別驅動程式。 系統提供的類別驅動程式會與廠商提供的迷你驅動程式搭配運作，這通常是動態連結庫 (DLL) ，其中包含一組回呼例程。 使用者 I/O 要求會導向至類別驅動程式，然後呼叫迷你驅動程式中的例程來執行特定工作。 迷你驅動程式通常不會收到整個 I/O 要求封包作為輸入;相反地，每個回呼例程只會接收其特定工作所需的數據。

當您建立數據流程圖時，請記住驅動程式要求的各種來源。 在使用者計算機上執行的任何程式代碼都可以對驅動程式產生 I/O 要求，例如 Microsoft Office 到免費軟體、共用軟體，以及可能可疑來源的 Web 下載。 根據您的特定裝置，您可能也需要考慮貴公司所隨附的媒體編解碼器或第三方篩選器，以支援其裝置。 可能的資料來源包括：

• IRP_MJ_XXX驅動程式所處理的要求
• 驅動程式所定義或句柄的IOCTL
• 驅動程式呼叫的 API
• 回呼例程
• 驅動程序公開的任何其他介面
• 驅動程式讀取或寫入的檔案，包括安裝期間所使用的檔案
• 驅動程式讀取或寫入的登錄機碼
• 組態屬性頁，以及驅動程式取用的使用者所提供的任何其他資訊

您的模型也應該涵蓋驅動程式安裝和更新程式。 包含驅動程式安裝期間讀取或寫入的所有檔案、目錄和登錄專案。 也請考慮在裝置安裝程式、共同安裝程式和屬性頁中公開的介面。

驅動程式與外部實體交換數據的任何時間點都可能會容易受到攻擊。

分析潛在威脅

識別驅動程式可能易受攻擊的點之後，您可以判斷每個時間點可能發生的威脅類型。 請考慮下列型態的問題：

• 有哪些安全性機制可用來保護每個資源？
• 所有轉換和介面是否都受到適當保護？
• 不小心使用功能可能會危害安全性嗎？
• 惡意使用功能會危害安全性嗎？
• 默認設定是否提供適當的安全性？

威脅分類的 STRIDE 方法

縮略字 STRIDE 描述軟體的六種威脅類別。 此縮略字衍生自：

• 詐騙
• Tampering
• Repudiation
• Iformation洩漏
• 服務列舉
• 提高許可權

使用 STRIDE 作為指南，您可以提出可能以驅動程式為目標之攻擊類型的詳細問題。 目標是要判斷驅動程式中每個易受攻擊點可能的攻擊類型，然後建立每個可能攻擊的案例。

• 詐騙 是使用其他人的認證來存取無法存取的資產。 進程會透過傳遞偽造或遭竊的認證來掛接詐騙攻擊。

• 竄改 正在變更數據以掛接攻擊。 例如，如果必要的驅動程式檔案未充分受到驅動程式簽署和訪問控制清單的保護， (ACL) ，驅動程式可能會遭到竄改。 在此情況下，惡意使用者可能會改變檔案，因而違反系統安全性。

• 當使用者拒絕執行動作，但動作的目標沒有辦法證明時，就會發生拒絕。 如果驅動程式未記錄可能危害安全性的動作，可能會受到否認性威脅的影響。 例如，如果影片裝置的驅動程式未記錄變更其裝置的特性，例如焦點、掃描區域、影像擷取的頻率、所擷取影像的目標位置等等，可能會容易受到拒絕。 產生的映像可能已損毀，但系統管理員無法判斷哪個使用者造成問題。

• 資訊洩漏 威脅與名稱完全相同：資訊洩漏給沒有許可權查看信息的使用者。 任何將資訊傳遞給用戶緩衝區或從用戶緩衝區傳遞信息的驅動程式，都容易受到資訊洩漏威脅的影響。 若要避免資訊洩漏威脅，驅動程式必須先驗證每個用戶緩衝區的長度，並在寫入數據之前先以零初始化緩衝區。

• 拒絕服務 攻擊會威脅有效使用者存取資源的能力。 資源可能是磁碟空間、網路連線或實體裝置。 效能降低至無法接受層級的攻擊也會被視為拒絕服務攻擊。 如果資源耗用量阻礙其他有效使用者執行其工作的能力，用戶進程不必要地獨佔系統資源可能會受到拒絕服務攻擊的影響。

  例如，驅動程式可能會在 IRQL = PASSIVE_LEVEL執行時，使用旗號來保護數據結構。 不過，驅動程式必須在 KeEnterCriticalRegion/KeLeaveCriticalRegion 配對內取得並釋放旗號，這會停用並重新啟用異步過程呼叫的傳遞 (API) 。 如果驅動程式無法使用這些例程，APC 可能會導致操作系統暫停保留旗號的線程。 因此，其他程式 (包括系統管理員所建立的程式) 將無法取得結構的存取權。

• 如果非特殊許可權的使用者取得特殊許可權狀態，可能會發生 提高 許可權攻擊。 將使用者模式句柄傳遞至 ZwXxx 例程的核心模式驅動程式很容易遭受提高許可權攻擊，因為 ZwXxx 例程會略過安全性檢查。 核心模式驅動程式必須驗證他們從使用者模式呼叫端收到的每個句柄。

  如果核心模式驅動程式依賴 IRP 標頭中的 RequestorMode 值來判斷 I/O 要求是否來自核心模式或使用者模式呼叫端，也可能會發生提高許可權攻擊。 在從網路或伺服器服務抵達的 IRP 中， (SRVSVC) ，不論要求的來源為何， RequestorMode 的值都是 KernelMode。 若要避免這類攻擊，驅動程式必須執行這類要求的訪問控制檢查，而不只是使用 RequestorMode 的值。

驅動程式分析技術

組織分析的簡單方式是列出易受攻擊的區域，以及每種威脅類型的潛在威脅和一或多個案例。

若要執行徹底的分析，您必須探索驅動程式中每個可能易受攻擊點的威脅可能性。 在每個易受攻擊點，判斷可能 (詐騙、竄改、竄改、資訊洩漏、拒絕服務，以及提高許可權) 。 然後為每個合理的威脅建立一或多個攻擊案例。

例如，請考慮IRP_MJ_DEVICE_CONTROL要求的數據流，如上圖所示。 下表顯示驅動程式在處理這類要求時可能會遇到的兩種威脅類型：

易受攻擊點	潛在威脅 (STRIDE)	案例
IRP_MJ_DEVICE_CONTROL要求	拒絕服務 權限提高	用戶進程會發出一連串導致裝置失敗的 IOCTL。 用戶程式發出允許FILE_ANY_ACCESS的IOCTL。

一個威脅通常與另一個威脅相關。 例如，利用提高許可權威脅的攻擊可能會導致資訊洩漏或拒絕服務。 此外，某些類型的攻擊取決於一連串的事件。 惡意使用者可能會從惡意探索提高許可權威脅開始。 然後，透過提高許可權隨附的新增功能，使用者可能會發現並利用其他弱點。

威脅樹狀結構與大綱在模型化這類複雜案例中很有用。

威脅樹狀結構是顯示威脅或弱點階層的圖表;基本上，威脅樹狀結構會模擬惡意使用者掛接攻擊的步驟。 攻擊的最終目標是在樹狀結構頂端。 每個次級層級會顯示執行攻擊所需的步驟。 下圖是上述範例中拒絕服務案例的簡單威脅樹狀結構。

威脅樹狀結構會顯示掛接特定攻擊的必要步驟，以及步驟之間的關聯性。 大綱是威脅樹狀結構的替代方案。

大綱只會依階層順序列出攻擊特定威脅的步驟。 例如：

1.0 導致裝置停止回應。

1.1 失敗順序的問題 IOCTLS。

1.1.1 決定導致裝置失敗的序列。

1.1.2 取得提高許可權以發出內部IOCTLs。

任一種技術都可協助您瞭解哪些威脅最危險，以及設計中的哪些弱點最重要。

快速路徑威脅模型化

如果資源有限，而不是建立完整的威脅模型圖表，則可以建立摘要大綱，以協助評估驅動程式的安全性風險。 例如，下列文字描述上一個範例所描述之範例驅動程序中圖表的一些表面區域。

驅動程式會從作業系統接收數種要求類型的數據：

• 透過呼叫 DriverEntry、 DriverUnload 和 AddDevice 例程，執行驅動程式及其裝置的系統管理工作的要求
• 隨插即用 要求 (IRP_MJ_PNP)
• 電源管理要求 (IRP_MJ_POWER)
• 內部裝置 I/O 控制要求 (IRP_MJ_INTERNAL_DEVICE_CONTROL)

為了回應這些要求，從驅動程式流回操作系統作為狀態資訊。 驅動程式會在下列類型的要求中接收來自使用者進程的數據：

• 建立、讀取和寫入要求 (IRP_MJ_CREATE、IRP_MJ_READ或IRP_MJ_WRITE)
• (IRP_MJ_DEVICE_ CONTROL) 公用裝置 I/O 控制要求

為了回應這些要求，輸出數據和狀態資訊會從驅動程式流回用戶進程。

使用此對驅動程式數據流的基本瞭解，您可以檢查每個輸入和輸出區域是否有可能的威脅。

威脅評估的 DREAD 方法

判斷驅動程式可能受到攻擊的方式和位置不夠。 然後，您必須評估這些潛在威脅、判斷其相對優先順序，以及設計風險降低策略。

DREAD 是一種縮寫，描述評估軟體威脅的五個準則。 DREAD 代表：

• Damage
• Reproducibility
• Exploitability
• 已辨別的使用者
• Discoverability

若要排定驅動程式的威脅優先順序，請在 DREAD 評估準則的所有 5 個準則上，將每個威脅排名 1 到 10，然後新增分數並除以 5 (準則數目) 。 結果是每個威脅介於 1 到 10 之間的數值分數。 高分表示嚴重威脅。

• 損毀。 評估安全性攻擊所造成的損害，顯然是威脅模型化的重要部分。 損毀可能包括數據遺失、硬體或媒體失敗、子標準效能，或任何適用於您裝置及其操作環境的類似量值。

• 重現性 是指定型別攻擊成功頻率的量值。 容易重現的威脅比很少發生或無法預測的弱點更可能遭到惡意探索。 例如，依預設安裝或用於每個潛在程式代碼路徑的功能威脅，高度可重現。

• 惡意探索性 會評估掛接攻擊所需的工作和專業知識。 相對不具經驗的大學學生可能會攻擊的威脅非常惡意。 需要高度技能人員且執行成本高昂的攻擊較不具惡意探索性。

  在評估惡意探索性時，也請考慮潛在攻擊者的數目。 任何遠端匿名使用者都可以利用的威脅，比需要現場、高度授權用戶的威脅更具惡意探索性。

• 受影響的使用者。 受攻擊影響的用戶數目是評估威脅的另一個重要因素。 最多會影響一或兩位用戶的攻擊會針對此量值產生相對低的速率。 相反地，當機網路伺服器的阻斷服務攻擊可能會影響數千位使用者，因此會提高速率。

• 可探索性 是威脅遭到惡意探索的可能性。 可探索性很難正確估計。 最安全的方法是假設最終會利用任何弱點，因此依賴其他量值來建立威脅的相對排名。

範例：使用 DREAD 評估威脅

請繼續上述範例，下表顯示設計工具如何評估假設的拒絕服務攻擊：

DREAD 準則	Score	註解
Damage	8	暫時中斷工作，但不會造成永久損毀或數據遺失。
可複製性	10	讓裝置每次都失敗。
利用性	7	需要專注的心力來判斷命令順序。
受影響的使用者	10	影響此裝置在市面上的每一個型號。
可搜尋性	10	假設會探索每個潛在威脅。
總：	9.0	降低此問題是高優先順序。

緩和威脅

您的驅動程式設計應該減輕模型公開的所有威脅。 不過，在某些情況下，風險降低可能並不實用。 例如，請考慮可能會影響非常少使用者且不太可能造成數據或系統可用性遺失的攻擊。 如果降低這類威脅需要數個月的額外工作，您可能會合理地選擇改為花費額外的時間測試驅動程式。 不過，請記住，最終惡意使用者可能會發現弱點並掛接攻擊，然後驅動程式將需要問題的修補程式。

在更廣泛的安全性開發生命週期程式中納入威脅模型化

請考慮在更廣泛的安全開發生命週期中包含威脅模型化程式 - SDL。

Microsoft SDL 程式提供一些建議的軟體開發程式，可修改以符合任何組織大小，包括單一開發人員。 請考慮將 SDL 建議的元件新增至您的軟體開發程式。

如需詳細資訊，請參閱 Microsoft 安全性開發生命週期 (SDL) – 程式指引。

訓練和組織功能 - 尋求軟體開發安全性訓練，以擴充您辨識和補救軟體弱點的能力。

Microsoft 讓其四個核心 SDL 訓練課程可供下載。 Microsoft 安全性開發生命週期核心訓練課程

如需 SDL 訓練的詳細資訊，請參閱本白皮書。 Microsoft SDL 的基本軟體安全性訓練

需求和設計 - 建置信任軟體的最佳機會是在新版本或新版本的初始規劃階段，因為開發小組可以識別重要物件，並整合安全性和隱私權，進而將計劃與排程中斷降至最低。

此階段的主要輸出是設定特定的安全性目標。 例如，決定所有程式代碼都應該傳遞具有零個警告的Visual Studio程式碼分析「所有規則」。

實作 - 所有開發小組都應該定義和發佈核准的工具清單及其相關聯的安全性檢查，例如編譯程式/鏈接器選項和警告。

對於驅動程式開發人員，大部分有用的工作都是在這個階段完成。 撰寫程式代碼時，會檢閱是否有可能的弱點。 程式代碼分析和驅動程式驗證器等工具可用來尋找可強化的程式代碼區域。

驗證 - 驗證 是軟體功能完成的時間點，會根據需求和設計階段中所述的安全性目標進行測試。

其他工具，例如量化範圍和模糊測試人員，可用來驗證已符合安全性設計目標，且程式代碼已準備好寄送

發行和回應 - 在準備發行產品時，建議您建立事件響應計劃，以描述您將如何回應新威脅，以及如何在驅動程式出貨之後提供服務。 事先執行此工作表示，如果在隨附的程式代碼中識別出安全性問題，您將能夠更快回應。

如需 SDL 程式的詳細資訊，請參閱下列其他資源：

• 這是主要的 Microsoft SDL 網站，並提供 SDL 的概觀。 https://www.microsoft.com/sdl

• 此部落格說明如何下載 安全性開發生命周期的免費複本：SDL，作者：Michael Howard 和 SteveLipner。 https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• 此頁面提供其他SDL發行集的連結。 https://www.microsoft.com/SDL/Resources/publications.aspx

喚起行動

針對驅動程式開發人員：

• 讓威脅模型化成為驅動程序設計的一部分。
• 採取步驟，以有效率地降低驅動程式程式代碼中的威脅。
• 熟悉適用於驅動程式和裝置類型的安全性和可靠性問題。 如需詳細資訊，請參閱 Windows Device Driver Kit (WDK) 的裝置特定區段。
• 瞭解在使用者要求到達您的驅動程式之前，先檢查操作系統、I/O 管理員和任何較高層級驅動程式，以及哪些檢查不會執行。
• 使用 WDK 的工具，例如驅動程式驗證程式來測試及驗證驅動程式。
• 檢閱已知威脅和軟體弱點的公用資料庫。

如需其他驅動程式安全性資源，請參閱 驅動程式安全性檢查清單。

軟體安全性資源

書籍

撰寫安全程序代碼，由 Michael Howard 和 David LeBlanc 撰寫第二版

24 軟體安全性的死因：程序設計瑕疵和如何修正它們、Michael Howard、David LeBlanc 和 John Viega 的第一版

軟體安全性評估的藝術：識別並防止軟體弱點，作者：Mark Dowd、John McHn 和 Justin Schuh

Microsoft 硬體和驅動程式開發人員資訊

取消 Windows 驅動程式中的邏輯 白皮書

Windows 安全性模型：每個驅動程式寫入器都需要知道的內容

Microsoft Windows 驅動程式開發工具包 (DDK)

請參閱核心模式驅動程式架構中的驅動程式程式設計技術

測試工具

請參閱測試中的 Windows 硬體實驗室套件以取得效能和相容性

已知威脅和軟體弱點的公用資料庫

若要擴充軟體威脅的知識，請檢閱已知威脅和軟體弱點的可用公用資料庫。

• CVE) 常見的弱點和暴露 (： https://cve.mitre.org/
• 常見弱點列舉： https://cwe.mitre.org/
• 常見的攻擊模式列舉和分類： https://capec.mitre.org/index.html
• NIST 會維護一個網站，描述如何編錄弱點： https://samate.nist.gov/BF/

另請參閱

驅動程式安全性檢查清單