Share via

Essential Eight 應用程控

  • 發行項

本文詳述使用 Microsoft App Locker 和 Windows Defender 應用程控來達成澳大利亞網路安全中心 (ACSC) 應用程控的基本八個成熟度模型的方法。

為何要遵循 ACSC Essential Eight 應用程控指導方針？

應用程控是一種安全性方法，旨在防範在系統上執行的惡意代碼。 實作此安全性方法時，它只會確保只有核准的程序代碼，例如可執行檔、軟體連結庫、腳本、安裝程式和驅動程式，才有權執行。 由於其有效性，應用程控是 ACSC 降低 網路安全性事件策略中的 Essential Eight 之一。

應用程式控制

應用程控是一種安全性方法，旨在防範在系統上執行的惡意代碼。 實作此安全性方法時，它只會確保只有核准的程序代碼，例如可執行檔、軟體連結庫、腳本、安裝程式和驅動程式，才有權執行。

雖然應用程控主要是設計來防止在系統上執行和散佈惡意代碼，但也可以防止安裝和使用未經核准的應用程式。

達到組織成熟度層級需求

  • 成熟度層級 1 (ML1) ：可以使用 Microsoft AppLocker 來達成
  • 成熟度層級 2 和 3 (ML2 & ML3) ：可以使用 Microsoft Windows Defender 應用程控來達成

應用程控的實作

實作應用程控涉及組織的下列高階步驟：

  • 識別已核准的應用程式
  • 開發應用程控規則以確保只能執行已核准的應用程式
  • 使用變更管理程式維護應用程控規則
  • 經常驗證應用程控規則

判斷如何在組織內強制執行應用程式授權時，澳大利亞網路安全中心會將下列方法視為正確實作時適用的方法：

  • 密碼編譯哈希規則
  • 發行者認證規則
  • 當檔案系統許可權設定為防止未經授權修改資料夾和檔案許可權、資料夾內容和個別檔案時，路徑規則 ()

應用程控可以防止未經授權執行未經核准的應用程式。 應用程控也有助於識別威脅執行者嘗試在系統上執行惡意代碼。 設定WDAC以產生授權和未經授權執行的事件記錄檔，可為組織的安全性作業中心提供寶貴的資訊。

請務必注意，應用程控解決方案不會取代已備妥的防病毒軟體和其他安全性軟體解決方案。 WDAC 一律與 Defender 防病毒軟體等防病毒軟體解決方案搭配運作。 一起使用 Microsoft 安全性解決方案有助於有效深入探索，以防止系統遭到入侵。

應用程控 (ML) 的成熟度層級

澳洲網路安全中心有三個成熟度層級，其風險降低策略構成 Essential Eight。 成熟度層級是以降低威脅執行者所使用之日益增加的交易手動程度為基礎。 在應用程控的內容中，澳大利亞網路安全中心會決定符合 ML 1、2 和 3 所需的專案。

ISM 2024 年 3 月控制 成熟度層級 風險降低
ISM-0109 3 工作站中的事件記錄會及時分析，以偵測網路安全性事件。
ISM-0140 2, 3 網路安全性事件會在發生或探索之後儘快回報給 ASD。
ISM-0123 2, 3 網路安全性事件會在發生或探索到之後，儘快回報給資訊安全長或其委派之一。
ISM-0843 1, 2, 3 應用程控是在工作站上實作。
ISM-1490 2, 3 應用程控是在因特網面向的伺服器上實作。
ISM-1656 3 應用程控是在非因特網對向伺服器上實作。
ISM-1544 2, 3 Microsoft 建議的應用程式封鎖清單已實作。
ISM-1657 1, 2, 3 應用程控會將可執行檔、軟體連結庫、腳本、安裝程式、編譯的 HTML、HTML 應用程式和控制面板小程式的執行限制為組織核准的集合。
ISM-1658 3 應用程控會將驅動程序的執行限制為組織核准的集合。
ISM-1582 2, 3 應用程式控制規則集會每年或更頻繁地進行驗證。
ISM-1659 3 Microsoft 的易受攻擊驅動程式封鎖清單已實作。
ISM-1660 2, 3 系統會集中記錄允許和封鎖的應用程控事件。
ISM-1815 2, 3 事件記錄檔會受到保護，免於未經授權的修改和刪除。
ISM-1819 2, 3 在識別網路安全性事件之後，會制定網路安全性事件響應計劃。
ISM-1870 1, 2, 3 應用程控會套用至作業系統、網頁瀏覽器和電子郵件用戶端所使用的使用者配置檔和暫存資料夾。
ISM-1871 2, 3 應用程控會套用至作業系統、網頁瀏覽器和電子郵件用戶端所使用之使用者配置檔和暫存資料夾以外的所有位置。
ISM-1228 2, 3 系統會及時分析網路安全性事件，以識別網路安全性事件。
ISM-1906 2, 3 系統會及時分析來自因特網對向伺服器的事件記錄，以偵測網路安全性事件。
ISM-1907 3 系統會及時分析來自非因特網對向伺服器的事件記錄，以偵測網路安全性事件。
ISM 2024 年 3 月控制 成熟度層級 Control 測量
ISM-0109 3 工作站中的事件記錄會及時分析，以偵測網路安全性事件。 使用適用於端點的Defender P2。 Windows 事件記錄檔是在 Microsoft Sentinel 內擷取，Microsoft Defender 全面偵測回應 透過 AMA 或 Windows 轉送事件解決方案使用 Windows 安全性 事件。
ISM-0140 2, 3 網路安全性事件會在發生或探索之後儘快回報給 ASD。 不在此檔的範圍內。 請參閱此數據表後面的附註。 3
ISM-0123 2, 3 網路安全性事件會在發生或探索到之後，儘快回報給資訊安全長或其委派之一。 不在此檔的範圍內。 請參閱此數據表後面的附註。 3
ISM-0843 1, 2, 3 應用程控是在工作站上實作。 根據組織的成熟度層級需求，設定及使用 Windows Defender 應用程控/AppLocker。
ISM-1490 2, 3 應用程控是在因特網面向的伺服器上實作。 設定和使用應用程控 Windows Defender
ISM-1656 3 應用程控是在非因特網對向伺服器上實作。 設定和使用應用程控 Windows Defender
ISM-1544 2, 3 Microsoft 建議的應用程式封鎖清單已實作。 Microsoft 的「建議的區塊規則」已實作
ISM-1657 1, 2, 3 應用程控會將可執行檔、軟體連結庫、腳本、安裝程式、編譯的 HTML、HTML 應用程式和控制面板小程式的執行限制為組織核准的集合。 Microsoft 建議在應用程控原則內建立已定義的檔案發行者規則或檔案哈希清單。 1
ISM-1658 3 應用程控會將驅動程序的執行限制為組織核准的集合。 已啟用受 Hypervisor 保護的程式代碼完整性，且預設為 Windows 11 2022+
ISM-1582 2, 3 應用程式控制規則集會每年或更頻繁地進行驗證。 不在此檔的範圍內。 請參閱下表的附註。 3
ISM-1659 3 Microsoft 的易受攻擊驅動程式封鎖清單已實作。 Microsoft 的「建議的驅動程式封鎖規則」已實作
ISM-1660 2, 3 系統會集中記錄允許和封鎖的應用程控事件。 使用適用於端點的Defender P2。 Windows 事件記錄檔會在 Microsoft Sentinel 內擷取，並透過 AMA 或「Windows 轉送事件」解決方案使用「Windows 安全性 事件」來 Microsoft Defender 全面偵測回應。
ISM-1815 2, 3 事件記錄檔會受到保護，免於未經授權的修改和刪除。 系統會強制執行 Microsoft Defender 全面偵測回應 和 Microsoft Sentinel 的 Role-Based 存取控制。
ISM-1819 2, 3 在識別網路安全性事件之後，會制定網路安全性事件響應計劃。 不在此檔的範圍內。  請參閱下表的附註。 3
ISM-1870 1, 2, 3 應用程控會套用至作業系統、網頁瀏覽器和電子郵件用戶端所使用的使用者配置檔和暫存資料夾。 Microsoft 建議在應用程控原則內建立已定義的檔案發行者規則或檔案哈希清單。 您可以使用 Microsoft AppLocker 來達成成熟度層級 1。 成熟度層級 2 和 3 需要 Windows Defender 應用程控。 2
ISM-1871 2, 3 應用程控會套用至作業系統、網頁瀏覽器和電子郵件用戶端所使用之使用者配置檔和暫存資料夾以外的所有位置。 Windows Defender 應用程控的實作和設定
ISM-1228 2, 3 系統會及時分析網路安全性事件，以識別網路安全性事件。 不在此檔的範圍內。  請參閱此數據表後面的附註。 3
ISM-1906 2, 3 系統會及時分析來自因特網對向伺服器的事件記錄，以偵測網路安全性事件。 使用適用於端點的Defender P2。 Windows 事件記錄檔是在 Microsoft Sentinel 內擷取，Microsoft Defender 全面偵測回應 透過 AMA 或 Windows 轉送事件解決方案使用 Windows 安全性 事件。
ISM-1907 3 系統會及時分析來自非因特網對向伺服器的事件記錄，以偵測網路安全性事件。 使用適用於端點的Defender P2。 Windows 事件記錄檔是在 Microsoft Sentinel 內擷取，Microsoft Defender 全面偵測回應 透過 AMA 或 Windows 轉送事件解決方案使用 Windows 安全性 事件。

重要事項

1 若要符合 ISM-1657，Microsoft 建議在應用程控原則內建立已定義的檔案發行者規則或檔案哈希清單。 如果太利用檔案路徑規則，組織必須確保使用者無法未經授權修改資料夾和檔案許可權、資料夾內容和個別檔案。 例如，使用者不應該在NTFS記憶體有檔案路徑規則位置的寫入存取權。

2 若要符合 ISM-1870，Microsoft 建議在應用程控原則內建立已定義的檔案發行者規則或檔案哈希清單。 您可以使用 Microsoft AppLocker 來達成成熟度層級 1。 由於其他 ISM 需求，成熟度層級 2 和 3 需要 Windows Defender 應用程控。 ISM-1870 不建議使用檔案路徑規則，因為使用者在使用者的配置檔和暫存資料夾記憶體有檔系統許可權。

3 控件 ISM-0140、0123、1582、1819 和 1228 是明確的主要人員和處理控件。 Microsoft 建議在 Purview 合規性管理員中將人員和程式記錄並儲存為精靈，作為 Essential 8 合規性檢閱的自動化技術辨識項的一部分。

適用於 Windows 的應用程控

要使用的解決方案為何？

Microsoft 建議客戶實作 Windows Defender 應用程控 (WDAC) ，而不是 AppLocker。 Windows Defender 應用程控正在持續改善。 雖然 AppLocker 會繼續收到安全性修正，但不會收到功能改善。

不過，對於共用裝置等案例，AppLocker 也可以部署為 Windows Defender 應用程控的補充，其中請務必防止某些使用者執行特定應用程式。 Microsoft 建議您的組織應強制執行 Windows Defender 應用程控，作為您組織最嚴格的層級，並視需要使用AppLocker進一步微調使用者模式限制。

提示

雖然這是慣用的 WDAC，但大部分組織只要使用 AppLocker 做為起點，就能更輕鬆地達成 ML1，這兩個解決方案都是免費的。

AppLocker

AppLocker 是隨 Windows 7 引進的，可讓組織控制哪些使用者模式 (允許應用程式) 程式在其 Windows 操作系統上執行。 AppLocker 原則可以套用至系統上的所有使用者，或適用於具有可根據下列定義規則的個別使用者和群組：

  • 密碼編譯哈希規則
  • 發行者認證規則
  • 路徑規則

AppLocker 原則可以在任何支援的 Windows 作業系統版本和新增版本上建立，並可使用 群組原則、PowerShell 或行動裝置 裝置管理 解決方案進行部署。

Windows Defender 應用程式控制

Windows Defender 應用程控 (WDAC) 是透過 Windows 10 導入。 它可讓組織控制哪些使用者模式 (應用程式) 和內核模式， (驅動程式) 程式可以在其 Windows 操作系統上執行。 WDAC 原則會套用至整個受控系統，並影響裝置的所有使用者，並具有可根據下列專案定義的規則：

  • 密碼編譯哈希規則
  • 發行者認證規則
  • 路徑規則
  • Microsoft Intelligent Security Graph 所決定的應用程式信譽
  • 由受控安裝程式起始應用程式安裝之程式的身分識別

WDAC 原則可以在任何支援的 Windows 10 版、Windows 11 版或 Windows Server 2016 版及更新版本上建立。 WDAC 原則可以使用 群組原則、行動裝置 裝置管理 解決方案、Configuration Manager 或 PowerShell 來部署。

由於 Microsoft 的 Windows 即服務允許開發和部署新功能給客戶，因此 WDAC 的某些功能僅適用於特定的 Windows 版本。

如需 Windows Defender 應用程控和 Applocker 的詳細資訊，請參閱 Windows Defender 應用程控和 AppLocker 功能可用性。

使用 AppLocker for ML1 的基本八個應用程控

使用 AppLocker 達成 ML1

當系統管理員為使用者型應用程控部署AppLocker原則時，可以使用下列規則作為路徑型實作的範例。 這包括規則、強制執行規則，以及自動啟動應用程式身分識別服務。

建議您至少) 下列路徑封鎖 (：

  • C：\Windows\Temp\*.*
  • %USERPROFILE%\AppData\Local\*.*
    • 新增 %USERPROFILE%\AppData\Local\Microsoft\WindowsApps 的例外狀況
  • %USERPROFILE%\AppData\Roaming\*.*

如需 ML1 AppLocker 的相關信息，請參閱下列文章：

建立 AppLocker 原則以達成 ML1

您可以使用數種方法來建立 Microsoft AppLocker 原則。 Microsoft 建議使用 Microsoft 開放原始碼專案 AaronLocker 來協助建立 AppLocker 原則。 AaronLocker 可讓您盡可能輕鬆且實際地使用 PowerShell 腳本的服務，為 AppLocker 建立和維護健全、嚴格、應用程控。 AaronLocker 的設計目的是要限制非系統管理員使用者執行程式和腳本。

如需有關 Aaronlocker 的詳細資訊，請參閱 AaronLocker：適用於 Windows 的健全且實用的應用程控。

部署 AppLocker 原則以達成 ML1

您可以使用 Microsoft Intune、群組原則 或 PowerShell 來部署 Microsoft AppLocker。 部署方法會相依於組織目前的管理解決方案。

如需部署App保險箱的詳細資訊，請參閱下列文章：

監視 AppLocker 原則事件

Microsoft AppLocker 相關事件會由安全性資訊和事件管理解決方案監視，例如 Microsoft 的 Sentinel。 也會使用 適用於端點的 Microsoft Defender的進階搜捕資訊來監視事件。

適用於端點的 Microsoft Defender：AppLocker 參考

適用於端點的 Microsoft Defender 會擷取與 Microsoft AppLocker 相關的下列事件。

ActionType 名稱 事件來源標識碼
AppControlExecutableAudited 8003
AppControlExecutableBlocked 8004
AppControlPackagedAppAudited 8021
AppControlPackagedAppBlocked 8022
AppControlPackagedAppBlocked 8006
AppControlScriptBlocked 8007
AppControlCIScriptAudited 8001

如需 事件檢視器 和進階搜捕的詳細資訊，請參閱下列文章：

使用 WDAC for ML2 的基本八個應用程控

Microsoft 概述設計程式、生命週期管理、部署和操作指引，以符合使用 WDAC 的 Essential Eight 應用程控 ML2 和 ML3。

具有 Essential Eight 應用程控 ML1 需求的客戶可以使用 Microsoft AppLocker 來達成。

需要使用此指引的必要條件：

  • Windows 11 22H2 Enterprise
  • 使用 Intune 管理解決方案
  • 適用於端點的Defender，適用於端點安全性解決方案
  • 適用於安全性資訊和事件管理的 Microsoft Sentinel;和
  • 系統管理員在本檔中所使用之解決方案的適當許可權

不在本指南範圍內的 Windows Server 操作系統上的 WDAC。 未來版本將提供 Windows Server 的指引。

授權需求

M365 相關服務可以位於 Microsoft 365 內，並 Office 365 服務描述，以瞭解所需的必要服務、價值主張和授權需求：

Microsoft 365 和 Office 365 服務描述

如需與 WDAC 相關聯之產品的相關信息，請參閱下列文章：

開始使用 WDAC

原則設計

當組織開始規劃 WDAC 時，設計決策的考慮會形成它如何影響原則部署和應用程控原則維護。

如果下列情況成立，WDAC 應該作為組織應用程控原則的一部分：

  • 您已部署或計劃在組織中部署支援的 Windows 版本
  • 您需要改善對組織應用程式存取權和使用者存取資料的控制
  • 您的組織具有妥善定義的應用程式管理和部署程式
  • 您有資源可根據組織的需求來測試原則
  • 您有資源可讓技術支援人員參與，或建置使用者應用程式存取問題的自助程式
  • 群組的生產力、管理性和安全性需求可由限制性原則來控制

WDAC 納入了「信任圈」的概念。 每個組織都有不同定義的「信任圈」專屬於其商務需求。 ACSC Essential 8 的相關定義是 ISM 控件 1657 –「應用程控會將可執行檔、軟體連結庫、腳本、安裝程式、編譯的 HTML、HTML 應用程式和控制面板小程式限制為組織核准的集合。」

Microsoft 在位於 Windows 中 %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies 下的 XML 格式內提供數個範例原則。 Microsoft 範例原則可讓您的組織從現有的基底原則開始，並視需要新增或移除規則來建置自定義原則。

如需原則設計的詳細資訊，請參閱下列文章：

原則格式

WDAC 支援兩種原則格式：

  • 單一原則格式：使用 Windows 10 RTM 和 Windows Server 2016 發行的原始原則格式。 單一原則格式在任何指定時間只支持系統上的單一作用中原則

  • 建議使用多個原則格式 () ：Windows 10 1903+、Windows 11 和 Windows Server 2022 支援此原則格式。 多重原則格式可讓您更靈活地部署 Windows Defender 應用程控，並在裝置上支援最多 32 個使用中的原則。 此外，它允許下列案例：

    • 並行強制執行和稽核：在部署強制執行之前驗證原則變更。 用戶可以與現有的強制模式型原則並存部署稽核模式基底原則
    • 多個基底原則：用戶可以同時強制執行兩個或多個基底原則
    • 補充原則：用戶可以部署一或多個補充原則來擴充基本原則。 您可以針對組織內的不同角色使用增補原則，例如 HR 和 IT

Microsoft 建議使用多個原則格式，並且只針對定義完善的案例使用單一原則格式，或無法使用多個原則格式，例如 Windows Server 2016 和 Windows Server 2019。

如需 WDAC 控制原則的詳細資訊，請參閱使用多個 Windows Defender 應用程控原則。''

原則規則和檔案規則

WDAC 包含兩個概念：：

  • WDAC 原則規則：WDAC 原則規則會指定組態，例如稽核模式、受管理的安裝程式、腳本強制執行、補充原則 (多重原則格式) 、Reputation-Based 智慧 (ISG 授權/智慧應用程控) 等等。 原則規則也會判斷核心模式和使用者模式二進位檔的 WDAC
  • WDAC 檔案規則：WDAC 檔案規則會指定在 Windows 上執行的授權和重新授權。 檔案規則支援哈希、檔名、檔案路徑和發行者規則，可讓客戶定義一組組織核准的允許應用程式。 規則會先處理它找到的所有明確拒絕規則，然後處理所有明確允許規則。 如果沒有拒絕或允許規則存在，WDAC 會檢查受管理的安裝程式。 最後，如果這些集合都不存在，WDAC 會回復 Reputation-Based 智慧

如需原則規則和檔案規則的詳細資訊，請參閱下列文章：

建立原則

使用 PowerShell 或 WDAC 精靈建立 WDAC 原則的主要方式有兩種：

  • PowerShell：WDAC 原則是使用 PowerShell 中可設定的程式代碼完整性 Cmdlet 來建立。 PowerShell 可讓 IT 專業人員自動化 WDAC 原則系統掃描，這會產生原則 XML。 PowerShell 可用來合併原則 XML、設定原則規則，以及視需要新增另一個原則檔案規則。可設定的程式碼完整性 Cmdlet 也可用來修改 WDAC 範例原則，以符合組織的需求。
  • Windows Defender 應用程控精靈 (建議的) ：WDAC 原則精靈是以 C# 撰寫的開放原始碼 Windows 傳統型應用程式，並配套為 MSIX 套件。 其建置目的是為安全性架構設計人員和系統管理員提供更方便使用的方式來建立、編輯和合併應用程控原則。 此工具會在後端使用 Config CI PowerShell Cmdlet，因此工具和 PowerShell Cmdlet 的輸出原則完全相同

如需原則建立的詳細資訊，請參閱下列文章：

Microsoft 建議使用 Windows Defender 應用程控精靈來實作應用程控的 Essential Eight。 或者，具有 DevOps 作業模型進階需求的組織也可以使用 PowerShell，並使用範例原則作為基底，或是想要從參考系統建立妥善定義案例的原則。

原則生命週期

在組織開始實作應用程控解決方案之前，您必須考慮原則在一段時間內的管理和維護方式。 大部分的 WDAC 原則會隨著時間而演進，並在其存留期期間繼續進行一組可識別的階段。 這些階段包括：

  1. 定義原則並建置原則 XML 的稽核模式版本。 在稽核模式中，會產生封鎖事件，但不會防止檔案執行
  2. 將稽核模式原則部署至預期的系統
  3. 監視預期系統中的稽核封鎖事件，並視需要精簡規則以解決非預期/不必要的區塊
  4. 重複這些步驟，直到其餘的封鎖事件符合您在稽核內的預期
  5. 產生原則的強制模式版本。 在強制執行模式中，系統會防止原則所允許定義的檔案執行，併產生對應的區塊事件
  6. 將強制模式原則部署至預期的系統
  7. 持續重複所有這些步驟，以解決任何非預期/不必要的封鎖動作

若要有效地管理 WDAC 原則，您應該在中央存放庫中儲存和維護原則 XML 檔。 Microsoft 建議使用原始檔控制解決方案，例如 GitHub 或檔管理解決方案，例如提供版本控制的 SharePoint。

受管理安裝程式的 WDAC 預先要求

本節旨在提供客戶關於使用 PowerShell 和 Microsoft Intune 設定 WDAC 受管理安裝程式需求的指引。

  • 檢閱 Windows 威脅防護自動允許受管理安裝程式部署的應用程式，Windows Defender 應用程控 (/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)

注意事項

此範例腳本不會使用AppLocker，因此步驟1中不會出現 良性DENY規則 。 此 AppLocker 設定會針對所有需要受管理安裝程式的裝置建立。

  • Create 完成下列動作的 PowerShell 腳本：
    • 儲存 AppLocker XML
    • 匯出 AppLocker XML
    • 設定 AppLocker 原則
    • 啟動AppLocker服務

以下是可使用 Intune 管理延伸模組 - PowerShell 腳本部署的腳本範例：

$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path

$AppLockerMIPolicy = 
@"
<AppLockerPolicy Version="1">
<RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
  <FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
          <BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
        </FilePublisherCondition>
  </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection> 
</AppLockerPolicy>
"@

$AppLockerMIPolicy | Out-File -FilePath $ScriptDir\AppLockerMIPolixy.xml
Set-AppLockerPolicy -XmlPolicy $ScriptDir\AppLockerMIPolixy.xml -Merge -ErrorAction SilentlyContinue
Start-Process -FilePath "$env:windir\System32\appidtel.exe" -ArgumentList "start -mionly" | Wait-Process
Remove-Item -Path $ScriptDir\AppLockerMIPolixy.xml

重要事項

系統管理員必須透過哈希或發行者，將設定腳本新增至 WDAC 檔案規則原則。

WDAC 受管理的安裝程式

概觀

WDAC 的受控 安裝程式 功能可讓組織在強制執行應用程控原則時，平衡安全性與管理性。 這可讓軟體發佈解決方案安裝應用程式，例如 Microsoft Configuration Manager 或 Intune。

常見的誤解是，在 WDAC 的原則中設定「受管理的安裝程式」規則是唯一的必要步驟。 不正確，而且需要另一個 AppLocker 設定，此功能才能運作。

受管理的安裝程式會使用AppLocker內的規則集合來指定貴組織信任的二進位檔以進行應用程式安裝。 Windows 會監視已設定的二進位檔進程，以及它啟動的任何子進程，同時監視寫入磁碟的相關聯檔案。 這些檔案會標記為源自受管理的安裝程式，因此允許執行。

部署Managed安裝程式

在 GPO 編輯和 AppLocker PowerShell Cmdlet 內建立 AppLocker 原則，無法直接用來建立受控安裝程式集合的規則。 您必須使用 VS Code 或其他編輯器工具來建立受控安裝程式規則集合。

AppLocker 設定服務提供者 (CSP) 目前不支援受管理的安裝程式規則集合類型，因此 AppLocker 原則必須使用 PowerShell 進行 Microsoft Intune 輸入。

由於 Windows Defender 應用程控的「腳本強制執行」功能必須符合 ISM-1657，因此需要強制執行腳本，才能控制 PowerShell、VBscript、cscript、cscript、HSMTA 和 MSXML。 設定「受控安裝程式」的PowerShell腳本必須位於使用哈希或發行者的 WDAC 檔案原則規則內。

Microsoft 建議針對 Microsoft Intune 設定 Managed 安裝程式。 Intune 可讓您強固管理使用 Microsoft Intune 封裝的應用程式，而不需要經常更新 Windows Defender 應用程控原則。

為 Managed 安裝程式部署 PowerShell 腳本

您可以使用兩種方式來部署受管理安裝程式的此組態文稿 Microsoft Intune 視案例而定：

  • 哈希：腳本的哈希必須在 WDAC 檔案原則中得知，並使用 Microsoft Win32 內容準備工具或 Microsoft Intune 內的 PowerShell 腳本功能進行封裝和部署。
  • 程式代碼簽署 (發行者) ：PowerShell 腳本已由受信任的授權單位簽署，且已知具有 WDAC 檔案原則、已封裝，並在 Microsoft Intune 內使用 Microsoft Win32 內容準備工具或 PowerShell 腳本功能進行部署。

如需部署PowerShell腳本的詳細資訊，請參閱下列文章：

建立 WDAC 審核策略

Create 審核策略

在瞭解選項並做出設計決策后，組織就能夠使用 [Windows Defender 應用程控精靈] 來建立第一個審核策略：

  1. 開啟 [Windows Defender 應用程控精靈]，然後選取 [原則建立者]。

  2. 在 [ 原則建立者] 中，選取 [ 多原則格式 ]，然後選取 [基本原則 ]，然後選取 [ 下一步]。

  3. 在原則 範本中，您會看到三個選項：

    • 默認 Windows 模式包括 Windows OS、市集應用程式、適用於 Enterprise (Office 365 Pro Plus) 和 WHQL 簽署核心驅動程式的 Microsoft 365 Apps。
    • [允許 Microsoft 模式 ] 包含預設 Windows 模式和所有 Microsoft 簽署應用程式內的所有區段。
    • 「已簽署」和「可輸送量模式 」包含所有先前的章節，以及 Reputation-Based 智慧。

重要事項

Reputation-Based Intelligence for Application Control 不符合基本的八個應用程控，因為 ISM 1657) 和「應用程式控制規則集每年或更頻繁地驗證」 (ISM 1582) (需求。WDAC 內的這項功能將不符合 ML2 或 ML3 的需求。 Microsoft 建議使用 Reputation-Based Intelligence，在 Essential Eight 應用程控的內容之外，組織採用 WDAC。

  1. 根據貴組織的需求，選取 [預設 Windows 模式 ] 或 [ 允許 Microsoft 模式 ]。 在本檔中，Microsoft 使用 允許 Microsoft 模式。
  2. 將 [ 原則名稱 ] 和 [位置 ] 修改為您想要的 [ 原則名稱 ] 和 [ 原則檔案位置 ] 以儲存盤案，然後選取 [ 下一步]。

注意事項

WDAC 的詳細資訊 – 您可以在這裡找到原則規則。

  • ISM 1657 和 1658 需要停用設為 「已停用」的腳本強制執行，才能控制腳本、符合規範的 HTML 和 HTML 應用程式。
  • ISM 1657、1658 和 1582 需要將 Intelligent Security Graph 設定為 [已停用]。
  • 建議將受管理的安裝程式「啟用」，以協助組織使用WDAC原則生命週期。
  • WDAC 原則需要使用者模式程式代碼完整性，才能同時套用至核心模式和使用者模式二進位檔。
  • 需要允許補充原則 ，才能使用多原則格式來協助組織使用WDAC原則生命週期。

注意事項

所有其他 WDAC 原則規則都取決於組織內的需求。

  1. 在 [簽署規則] 中，系統管理員可以看到已新增為 [允許發行者規則] 的所有 Microsoft 憑證。 本文稍後將討論 新增自定義規則 。
  2. 選取 [下一步]。

Windows Defender 應用程控精靈會產生：

  • 原則 XML
  • {GUID}。Cip

WDAC 的詳細資訊 – 您可以在這裡找到原則規則。

注意事項

使用 [Windows Defender 應用程控精靈] 產生的每個原則都會 (GUID) 取得新的全域唯一標識符。

已成功建立 WDAC 原則。

原則 XML

由於組織已使用 WDAC 精靈建立 WDAC 原則，因此組織能夠在文本編輯器中檢視此檔案的內容。 XML 會分割成數個不同的區段，針對 Essential Eight 的內容，記下 PolicyID 和 BasePolicyID。

注意事項

雖然可以直接編輯原則 XML。 Microsoft 建議使用 Windows Defender 應用程控精靈或 PowerShell 中的可設定程式代碼完整性 Cmdlet，對原則規則或簽署檔案進行所有其他變更。

WDAC 審核策略部署

透過 Intune 部署 WDAC 審核策略

現在組織已建立審核策略，現在可以使用 Intune 裝置管理來部署它。

  1. 登入 Intune 系統管理中心。
  2. 在 Intune 系統管理中心內，移至 [裝置]，然後移至 [組態配置檔]。
  3. 接下來，建立配置文件>平臺 – Windows 10 或更新版本、配置檔類型範本和自定義。
  4. Create 原則的名稱 (例如，[應用程控 - Microsoft 允許 – 稽核] ) ，然後選取 [下一步]。
  5. 在 [OMA-URI 設定] 下，選取 [ 新增]。

注意事項

此資訊取決於從 Windows >Defender 應用程控精靈針對從上一節的「Create 審核策略」建立的原則 XML 所產生的原則標識碼：

- 名稱 = Microsoft 允許稽核
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- 資料類型 = Base64 (檔案)

  1. 當 Windows Defender 應用程控精靈產生原則 XML 時，也會建立 (GUID) 。CIP 檔案。 CIP 檔案必須複製，並將擴展名重新命名為 。BIN 例如 {CB46B243-C19C-4870-B098-A2080923755C}.bin。
  2. 上傳Base64 (檔案) 下的 BIN。
  3. 選取 [儲存]。
  4. 依照提示建立組 態配置檔。
  5. 將您建立的原則部署到預定的系統，例如「應用程控 - Microsoft 允許 – 稽核」、組態配置檔。

WDAC – 稽核原則監視

在 WDAC 原則生命周期之後，組織必須檢閱從「允許 Microsoft 稽核」原則產生的事件。 WDAC 審核策略監視可以使用兩種方法來達成：

  • 應用程控事件標識碼：應用程控事件標識碼是檢閱 Windows 操作系統上稽核事件的傳統方法。 您可以使用 Windows 事件記錄檔轉送或第三方安全性資訊和事件管理，將這些事件標識碼轉送到集中位置。

如需事件標識碼的相關信息，請 參閱瞭解應用程控事件標識碼 - Windows 安全性。

  • 適用於端點的 Microsoft Defender (建議的) ：端點和 AppLocker 相關事件的 Windows Defender 會擷取在進階搜捕中 適用於端點的 Microsoft Defender。 事件中包含的資訊包括 Device、FileName、FolderPath、InitiatingProcessFileName、File Hashes 等。 請參閱： 使用 Windows) 進階搜捕 (查詢應用程控事件 - Windows 安全性

Microsoft 建議使用與 Microsoft Sentinel Microsoft Defender 全面偵測回應 (MDE) 整合。 相較於 適用於端點的 Microsoft Defender，MDE 和 Sentinel 允許進階搜捕遙測數據儲存超過 30 天。

如需連線和監視的詳細資訊，請參閱下列文章：

使用 適用於端點的 Microsoft Defender 監視 WDAC

下列範例示範用戶有數個應用程式用於組織的日常工作。 此範例同時包含 Microsoft 應用程式和各種 開放原始碼 應用程式。

因為範例處於強制 稽核模式，系統管理員 (可以看到它，但不會影響使用者) 針對 WinSCP、VLC、Putty 和 FileZilla 觸發的事件，因為這些應用程式不是初始審核策略的一部分。

現在使用 Microsoft Defender 入口網站，輸入進階搜捕以縮小稽核事件的範圍，以瞭解如果停用稽核模式，將會發生哪些非預期/不想要的區塊，因此在此範例中會變成強制執行模式。

進階搜捕的螢幕快照。

使用上一頁的參考架構，尋找過去七天內由WDAC觸發的所有原則稽核事件，並使用範例鍵盤查詢語言 (KQL) 查詢來呈現相關信息：

DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

以下是使用先前 KQL 查詢的輸出範例。

進階搜捕輸出的螢幕快照。

記錄中有詳細的信息報告，例如處理樹狀結構、檔案路徑、SHA 資訊、簽署者和簽發者資訊。

下一個步驟是縮小結果範圍。

使用相同的 KQL 查詢，新增另一個字段，其中 起始進程檔名 是 Windows 檔案總管。 KQL 查詢會顯示使用者在 GUI 內執行的應用程式。

 DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "explorer.exe" // Users starting an Application via File Explorer / GUI
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

以下是使用先前 KQL 查詢的輸出範例。 查詢輸出的螢幕快照。

KQL 查詢動作現在已將資訊縮小為更詳細的管理數據集。 可以看到預期系統所使用的應用程式。 這些應用程式必須新增至組織的原則，或視為透過組織變更控制新增。

注意事項

KQL 是一種功能強大的工具，可顯示非結構化和結構化數據集。 這隻是使用 KQL 的範例，Microsoft 建議您檢閱下列檔：瞭解 Microsoft Defender 全面偵測回應 的進階搜捕查詢語言

WDAC – 更新審核策略

使用 適用於端點的 Microsoft Defender和 WDAC 精靈更新審核策略

透過使用 KQL 縮小搜尋結果的範圍，下一個步驟是更新 WDAC 基底原則或使用補充原則。 下一個範例會使用補充原則。

  1. 開啟 [Windows Defender 應用程控精靈]，然後選取 [原則建立者]。

  2. 在 [ 原則建立者] 中，選取 [ 多個原則格式]，然後選取 [補充原則]，流覽至您的基底原則、更新位置以儲存補充原則，然後選取 [ 下一步]。

  3. 在 [原則規則] 中選取 [下一步]。

  4. 在 [ 原則簽署規則] 中 ，選取 [ 自定義規則]。

  5. 在 自訂規則條件中，有許多選項可供使用：

    • 規則範圍使用者模式規則/核心模式規則
    • 規則動作：允許/拒絕
    • 規則類型
      • 發行 者 (建議)
      • 檔案
      • 檔案屬性
      • 已封裝的應用程式
      • 散列
    • 參考檔案

注意事項

Microsoft 建議在適當時使用以發行者為基礎的規則，並針對未簽署的參考檔案切換回哈希型規則，以實作 Essential Eight 應用程控。

使用 適用於端點的 Microsoft Defender

  1. 搜尋 搜尋 中的檔名，然後流覽至檔案資訊並下載檔。 更新審核策略 2 的螢幕快照。
  2. 直接從進階搜捕檢查記錄並下載檔案，然後下載所需的二進位檔。 更新審核策略 3 的螢幕快照。
  3. 使用必要的二進位檔，接下來繼續為組織的ISV應用程式建立另一個原則。
  4. 在 [Windows Defender 應用程控精靈] 中，選取所需的 [規則類型]，然後流覽至上一個步驟中的參考二進位檔。 下一個範例示範 VLC 符合必要的發行者資訊。 更新審核策略 4 的螢幕快照。

注意事項

Microsoft 建議您 至少 選擇發行 CA、發行者，以建立以發行者為基礎的規則。 產品名稱可以包含在內，而且 ACSC 建議用於發行者型規則。

  1. 按 [下一步] 並 Create。
  2. Deploy this Supplement Policy using the steps previously described in section "Deploy Windows Defender Application Control Audit Policy via Microsoft Intune".

WDAC – 切換以強制執行原則

若要切換以強制執行原則：

  1. 開啟 [Windows Defender 應用程控精靈]，然後選取 [原則 編輯器]。

  2. 流覽至要變更為強制執行的原則 XML。

  3. 停用原則規則內的稽核模式切換。

  4. 在 [原則規則] 中選取 [下一步]。

  5. 更新原則是以修改過的版本號碼建立，並已建立新的 CIP 檔案。

  6. 在 Microsoft 端點管理員 管理員 中心內，移至 [裝置]，然後移至 [組態配置檔]。

  7. 接下來，建立配置檔、平臺 – Windows 10 或更新版本、配置檔類型範本和自定義。

  8. Create 原則的名稱，例如[應用程控 – 強制執行原則]，然後選取 [下一步]。

  9. 在 [OMA-URI 設定] 下，選取 [ 新增]。

    注意事項

    此資訊取決於從上述建立稽核區段建立之原則 XML 的 Windows Defender 應用程控精靈所產生的原則標識符。

    - 名稱 = Microsoft 允許強制執行
    - OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
    - 資料類型 = Base64 (檔案)

  10. 當 Windows Defender 應用程控精靈產生原則 XML 時，也會建立 (GUID) 。CIP 檔案。 下一個步驟是複製此 CIP 檔案，並將延伸名重新命名為 。BIN 例如 {CB46B243-C19C-4870-B098-A2080923755C}.bin。

  11. 上傳Base64 (檔案) 下的 BIN。

  12. 選取 [儲存]。

  13. 依照提示建立組 態配置檔。

  14. 部署 應用程控 – 將原則 組態配置檔強制執行至預定的系統。

    注意事項

    系統管理員必須從要切換以強制執行的預定系統中排除先前建立的應用程式 – 審核策略