Essential Eight 應用程控
本文詳述如何使用 Microsoft App Locker 和 Windows Defender 應用程控,達成澳大利亞網路安全中心 (ACSC) 應用程控的基本八個成熟度模型的方法。
應用程控是一種安全性方法,旨在防範在系統上執行的惡意代碼。 實作此安全性方法時,它只會確保只有核准的程序代碼,例如可執行檔、軟體連結庫、腳本、安裝程式和驅動程式,才有權執行。 由於其有效性,應用程控是 ACSC 降低 網路安全性事件策略中的 Essential Eight 之一。
應用程控是一種安全性方法,旨在防範在系統上執行的惡意代碼。 實作此安全性方法時,它只會確保只有核准的程序代碼,例如可執行檔、軟體連結庫、腳本、安裝程式和驅動程式,才有權執行。
雖然應用程控主要是設計來防止在系統上執行和散佈惡意代碼,但也可以防止安裝和使用未經核准的應用程式。
- 成熟度層級 1 (ML1) :可以使用 Microsoft AppLocker 來達成
- 成熟度層級 2 和 3 (ML2 & ML3) :可以使用 Microsoft Windows Defender 應用程控來達成
實作應用程控涉及組織的下列高階步驟:
- 識別已核准的應用程式
- 開發應用程控規則以確保只能執行已核准的應用程式
- 使用變更管理程式維護應用程控規則
- 經常驗證應用程控規則
判斷如何在組織內強制執行應用程式授權時,澳大利亞網路安全中心會將下列方法視為正確實作時適用的方法:
- 密碼編譯哈希規則
- 發行者認證規則
- 當檔案系統許可權設定為防止未經授權修改資料夾和檔案許可權、資料夾內容和個別檔案時,路徑規則 ()
應用程控可以防止未經授權執行未經核准的應用程式。 應用程控也有助於識別威脅執行者嘗試在系統上執行惡意代碼。 設定WDAC以產生授權和未經授權執行的事件記錄檔,可為組織的安全性作業中心提供寶貴的資訊。
請務必注意,應用程控解決方案不會取代已備妥的防病毒軟體和其他安全性軟體解決方案。 WDAC 一律會與防病毒軟體解決方案搭配運作,例如 Defender 防毒軟體。 一起使用Microsoft安全性解決方案有助於有效深入探索,以防止系統遭到入侵。
澳大利亞網路安全中心對於構成 Essential Eight 的風險降低策略有三個成熟度層級。 成熟度層級是以降低威脅執行者所使用之日益增加的交易手動程度為基礎。 在應用程控的內容中,澳大利亞網路安全中心會決定符合 ML 1、2 和 3 所需的專案。
ISM 2024 年 9 月控件 | 成熟度層級 | 風險降低 |
---|---|---|
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 年 9 月控件 | 成熟度層級 | 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 合規性檢閱的自動化技術辨識項的一部分。
Microsoft建議客戶實作 Windows Defender 應用程控 (WDAC) ,而不是 AppLocker。 Windows Defender 應用程控正在持續改善。 雖然 AppLocker 會繼續收到安全性修正,但不會收到功能改善。
不過,對於共用裝置等案例,AppLocker 也可以部署為 Windows Defender 應用程控的補充,其中請務必防止某些使用者執行特定應用程式。 Microsoft建議貴組織應強制執行 Windows Defender 應用程控,以盡可能為組織限制最嚴格的層級,並視需要使用 AppLocker 進一步微調使用者模式限制。
提示
雖然這是慣用的 WDAC,但大部分組織只要使用 AppLocker 做為起點,就能更輕鬆地達成 ML1,這兩個解決方案都是免費的。
AppLocker 是隨 Windows 7 引進的,可讓組織控制哪些使用者模式 (允許應用程式) 程式在其 Windows 操作系統上執行。 AppLocker 原則可以套用至系統上的所有使用者,或適用於具有可根據下列定義規則的個別使用者和群組:
- 密碼編譯哈希規則
- 發行者認證規則
- 路徑規則
AppLocker 原則可以在任何支援的 Windows 作業系統版本和新增版本上建立,並可使用 群組原則、PowerShell 或行動裝置 裝置管理 解決方案進行部署。
Windows 10 導入了 Windows Defender 應用程控 (WDAC) 。 它可讓組織控制哪些使用者模式 (應用程式) 和內核模式, (驅動程式) 程式可以在其 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原則時,可以使用下列規則作為路徑型實作的範例。 這包括規則、強制執行規則,以及自動啟動應用程式身分識別服務。
建議您至少) 下列路徑封鎖 (:
- C:\Windows\Temp\*.*
- %USERPROFILE%\AppData\Local\*.*
- 新增 %USERPROFILE%\AppData\Local\Microsoft\WindowsApps 的例外狀況
- %USERPROFILE%\AppData\Roaming\*.*
如需 ML1 AppLocker 的相關信息,請參閱下列文章:
Microsoft可以使用數種方法來建立 AppLocker 原則。 Microsoft建議使用 Microsoft 開放原始碼專案 AaronLocker 來協助建立 AppLocker 原則。 AaronLocker 可讓您盡可能輕鬆且實際地使用 PowerShell 腳本的服務,為 AppLocker 建立和維護健全、嚴格、應用程控。 AaronLocker 的設計目的是要限制非系統管理員使用者執行程式和腳本。
如需有關 Aaronlocker 的詳細資訊,請參閱 AaronLocker:適用於 Windows 的健全且實用的應用程控。
Microsoft可以使用 Microsoft Intune、群組原則 或 PowerShell 來部署 AppLocker。 部署方法會相依於組織目前的管理解決方案。
如需部署App保險箱的詳細資訊,請參閱下列文章:
Microsoft AppLocker 相關事件是由安全性資訊和事件管理解決方案監視,例如Microsoft的 Sentinel。 也會使用 適用於端點的 Microsoft Defender的進階搜捕資訊來監視事件。
適用於端點的 Microsoft Defender:AppLocker 參考
適用於端點的 Microsoft Defender 會擷取與 appLocker Microsoft相關的下列事件。
ActionType 名稱 | 事件來源標識碼 |
---|---|
AppControlExecutableAudited | 8003 |
AppControlExecutableBlocked | 8004 |
AppControlPackagedAppAudited | 8021 |
AppControlPackagedAppBlocked | 8022 |
AppControlPackagedAppBlocked | 8006 |
AppControlScriptBlocked | 8007 |
AppControlCIScriptAudited | 8001 |
如需 事件檢視器 和進階搜捕的詳細資訊,請參閱下列文章:
Microsoft概述設計程式、生命週期管理、部署和操作指引,以符合使用 WDAC 的 Essential Eight 應用程控 ML2 和 ML3。
具有基本八個應用程控 ML1 需求的客戶可以使用 Microsoft AppLocker 來達成。
需要使用此指引的必要條件:
- Windows 11 22H2 企業版
- 使用 Intune 管理解決方案
- 適用於端點的Defender,適用於端點安全性解決方案
- Microsoft Sentinel 安全性資訊和事件管理;以及
- 系統管理員在本檔中所使用之解決方案的適當許可權
不在本指南範圍內的 Windows Server 操作系統上的 WDAC。 未來版本將提供 Windows Server 的指引。
M365 相關服務可位於 Microsoft 365 內,並 Office 365 服務描述,以瞭解所需的必要服務、價值主張和授權需求:
Microsoft 365 和 Office 365 服務描述
如需與 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 原則會隨著時間而演進,並在其存留期期間繼續進行一組可識別的階段。 這些階段包括:
- 定義原則並建置原則 XML 的稽核模式版本。 在稽核模式中,會產生封鎖事件,但不會防止檔案執行
- 將稽核模式原則部署至預期的系統
- 監視預期系統中的稽核封鎖事件,並視需要精簡規則以解決非預期/不必要的區塊
- 重複這些步驟,直到其餘的封鎖事件符合您在稽核內的預期
- 產生原則的強制模式版本。 在強制執行模式中,系統會防止原則所允許定義的檔案執行,併產生對應的區塊事件
- 將強制模式原則部署至預期的系統
- 持續重複所有這些步驟,以解決任何非預期/不必要的封鎖動作
若要有效地管理 WDAC 原則,您應該在中央存放庫中儲存和維護原則 XML 檔。 Microsoft建議原始檔控制解決方案,例如 GitHub 或檔管理解決方案,例如提供版本控制的 SharePoint。
本節旨在提供客戶關於使用 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 設定會針對所有需要受管理安裝程式的裝置建立。
- 建立完成下列動作的 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 的受控 安裝程式 功能可讓組織在強制執行應用程控原則時,平衡安全性與管理性。 這可讓軟體發佈解決方案安裝應用程式,例如 Microsoft Configuration Manager 或 Intune。
常見的誤解是,在 WDAC 的原則中設定「受管理的安裝程式」規則是唯一的必要步驟。 不正確,而且需要另一個 AppLocker 設定,此功能才能運作。
受管理的安裝程式會使用AppLocker內的規則集合來指定貴組織信任的二進位檔以進行應用程式安裝。 Windows 會監視已設定的二進位檔進程,以及它啟動的任何子進程,同時監視寫入磁碟的相關聯檔案。 這些檔案會標記為源自受管理的安裝程式,因此允許執行。
在 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 應用程控原則。
您可以使用兩種方式來部署受管理安裝程式的此組態腳本,Microsoft Intune 視案例而定:
- 哈希:腳本的哈希必須在 WDAC 檔案原則中得知,並使用 Microsoft Win32 內容準備工具或 Microsoft Intune 內的 PowerShell 腳本功能進行封裝和部署。
- 程式代碼簽署 (發行者) :PowerShell 腳本已由受信任的授權單位簽署,並使用 Microsoft Intune 內的 Microsoft Win32 內容準備工具或 PowerShell 腳本功能,以 WDAC 檔案原則來進行封裝和部署。
如需部署PowerShell腳本的詳細資訊,請參閱下列文章:
- 使用 Windows Defender 應用程控自動允許受管理安裝程式部署的應用程式
- AppLocker CSP
- 使用 Windows Defender 應用程控 (WDAC) 來強制執行腳本
- Microsoft Intune 中的 Win32 應用程式管理
- 在 Windows 10/11 裝置上使用PowerShell腳本 Intune
在瞭解選項並做出設計決策后,組織就能夠使用 Windows Defender 應用程控精靈建立第一個審核策略:
開啟 Windows Defender 應用程控精靈 ,然後選取 [原則建立者]。
在 [ 原則建立者] 中,選取 [ 多原則格式 ],然後選取 [基本原則 ],然後選取 [ 下一步]。
在原則 範本中,您會看到三個選項:
- 默認 Windows 模式包括 Windows OS、市集應用程式、企業版 (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 智慧來組織採用 WDAC。
- 根據貴組織的需求,選取 [預設 Windows 模式 ] 或 [ 允許Microsoft模式 ]。 在本檔中,Microsoft使用 允許Microsoft模式。
- 將 [ 原則名稱 ] 和 [位置 ] 修改為您想要的 [ 原則名稱 ] 和 [ 原則檔案位置 ] 以儲存盤案,然後選取 [ 下一步]。
注意
WDAC 的詳細資訊 – 您可以在這裡找到原則規則。
- ISM 1657 和 1658 需要停用設為 「已停用」的腳本強制執行,才能控制腳本、符合規範的 HTML 和 HTML 應用程式。
- ISM 1657、1658 和 1582 需要將 Intelligent Security Graph 設定為 [已停用]。
- 建議將受管理的安裝程式「啟用」,以協助組織使用WDAC原則生命週期。
- WDAC 原則需要使用者模式程式代碼完整性,才能同時套用至核心模式和使用者模式二進位檔。
- 需要允許補充原則 ,才能使用多原則格式來協助組織使用WDAC原則生命週期。
注意
所有其他 WDAC 原則規則都取決於組織內的需求。
- 在 [簽署規則] 中,系統管理員可以看到已新增為 [允許發行者規則] 的所有Microsoft憑證。 本文稍後將討論 新增自定義規則 。
- 選取 [下一步]。
Windows Defender 應用程控精靈會產生:
- 原則 XML
- {GUID}。CIP
WDAC 的詳細資訊 – 您可以在這裡找到原則規則。
注意
使用 Windows Defender 應用程控精靈產生的每個原則都會 (GUID) 取得新的全域唯一標識符。
已成功建立 WDAC 原則。
由於組織已使用 WDAC 精靈建立 WDAC 原則,因此組織能夠在文本編輯器中檢視此檔案的內容。 XML 會分割成數個不同的區段,針對 Essential Eight 的內容,記下 PolicyID 和 BasePolicyID。
注意
雖然可以直接編輯原則 XML。 Microsoft建議使用 Windows Defender 應用程控精靈或 PowerShell 中的可設定程式代碼完整性 Cmdlet,對原則規則或簽署檔案進行所有其他變更。
現在組織已建立審核策略,現在可以使用 Intune 裝置管理來部署它。
- 登入 Intune 系統管理中心。
- 在 Intune 系統管理中心內,移至 [裝置],然後移至 [組態配置檔]。
- 接下來,建立配置檔>平臺 – Windows 10 或更新版本、配置檔類型範本和自定義。
- 建立原則 (的名稱,例如[應用程控 - Microsoft允許 - 稽核 ) ,然後選取 [ 下一步]。
- 在 [OMA-URI 設定] 下,選取 [ 新增]。
注意
此資訊取決於從 Windows >Defender 應用程控精靈針對從上一節的「建立審核策略」建立的原則 XML 所產生的原則標識碼:
- 名稱 = Microsoft允許稽核
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- 資料類型 = Base64 (檔案)
- 當 Windows Defender 應用程控精靈產生原則 XML 時,也會建立 (GUID) 。CIP 檔案。 CIP 檔案必須複製,並將擴展名重新命名為 。BIN 例如 {CB46B243-C19C-4870-B098-A2080923755C}.bin。
- 上傳Base64 (檔案) 下的 BIN。
- 選取 [儲存]。
- 依照提示建立組 態配置檔。
- 將您建立的原則,例如「應用程控 - Microsoft允許 – 稽核」、組態配置檔部署至預定的系統。
在 WDAC 原則生命周期之後,組織必須檢閱從「允許Microsoft稽核」原則產生的事件。 WDAC 審核策略監視可以使用兩種方法來達成:
- 應用程控事件標識碼:應用程控事件標識碼是檢閱 Windows 操作系統上稽核事件的傳統方法。 您可以使用 Windows 事件記錄檔轉送或第三方安全性資訊和事件管理,將這些事件標識碼轉送到集中位置。
如需事件標識碼的相關信息,請 參閱瞭解應用程控事件標識碼 - Windows 安全性。
- 適用於端點的 Microsoft Defender (建議的) :適用於端點的 Windows Defender 和 AppLocker 相關事件會擷取在進階搜捕中 適用於端點的 Microsoft Defender。 事件中包含的資訊包括 Device、FileName、FolderPath、InitiatingProcessFileName、File Hashes 等。 請參閱: 使用 Windows) 進階搜捕 (查詢應用程控事件 - Windows 安全性
Microsoft建議使用 Microsoft Defender 全面偵測回應 (MDE) 整合來 Microsoft Sentinel。 相較於 適用於端點的 Microsoft Defender,MDE和 Sentinel 允許進階搜捕遙測數據儲存超過 30 天。
如需連線和監視的詳細資訊,請參閱下列文章:
- 將數據從 Microsoft Defender 全面偵測回應 連線到 Microsoft Sentinel
- Windows 用戶端裝置上的 Azure 監視器代理程式
- 使用 Azure 監視器代理程式從虛擬機收集事件和性能計數器
下列範例示範用戶有數個應用程式用於組織的日常工作。 此範例包含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 全面偵測回應 的進階搜捕查詢語言
透過使用 KQL 縮小搜尋結果的範圍,下一個步驟是更新 WDAC 基底原則或使用補充原則。 下一個範例會使用補充原則。
開啟 [Windows Defender 應用程控精靈] ,然後選取 [ 原則建立者]。
在 [ 原則建立者] 中,選取 [ 多個原則格式],然後選取 [補充原則],流覽至您的基底原則、更新位置以儲存補充原則,然後選取 [ 下一步]。
在 [原則規則] 中選取 [下一步]。
在 [ 原則簽署規則] 中 ,選取 [ 自定義規則]。
在 自訂規則條件中,有許多選項可供使用:
- 規則範圍使用者模式規則/核心模式規則
- 規則動作:允許/拒絕
- 規則類型
- 發行 者 (建議)
- 檔案
- 檔案屬性
- 已封裝的應用程式
- 散列
- 參考檔案
注意
Microsoft建議在適當時使用以發行者為基礎的規則,並針對未簽署的參考檔案切換回哈希型規則,以實作 Essential Eight 應用程控。
使用 適用於端點的 Microsoft Defender
- 在 [搜尋] 中 搜尋 檔名,並瀏覽至檔案 [資訊] 並下載檔。
- 直接從進階搜捕檢查記錄並下載檔案,然後下載所需的二進位檔。
- 使用必要的二進位檔,接下來繼續為組織的ISV應用程式建立另一個原則。
- 在 Windows Defender 應用程控精靈中,選取所需的 規則類型 ,並流覽至上一個步驟中的參考二進位檔。 下一個範例示範 VLC 符合必要的發行者資訊。
注意
Microsoft建議至少選擇發行 CA、發行 者,以 建立以發行者為基礎的規則。 產品名稱可以包含在內,而且 ACSC 建議用於發行者型規則。
- 按 [下一步] 和 [建立]。
- Deploy this Supplement Policy using the steps previously described in section "Deploy Windows Defender Application Control Audit Policy via Microsoft Intune".
若要切換以強制執行原則:
開啟 [Windows Defender 應用程控精靈],然後選取 [原則 編輯器] 。
流覽至要變更為強制執行的原則 XML。
停用原則規則內的稽核模式切換。
在 [原則規則] 中選取 [下一步]。
更新原則是以修改過的版本號碼建立,並已建立新的 CIP 檔案。
在 Microsoft 端點管理員 管理員 中心內,移至 [裝置],然後移至 [組態配置檔]。
接下來,建立配置檔、平臺 – Windows 10 或更新版本、配置檔類型範本和自定義。
建立原則的名稱,例如應用程控 – 強制執行原則,然後選取 [下一步]。
在 [OMA-URI 設定] 下,選取 [ 新增]。
注意
此資訊取決於從 Windows Defender 應用程控精靈針對上述建立稽核一節所建立之原則 XML 所產生的原則識別碼。
- 名稱 = Microsoft允許強制執行
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- 資料類型 = Base64 (檔案)當 Windows Defender 應用程控精靈產生原則 XML 時,也會建立 (GUID) 。CIP 檔案。 下一個步驟是複製此 CIP 檔案,並將延伸名重新命名為 。BIN 例如 {CB46B243-C19C-4870-B098-A2080923755C}.bin。
上傳Base64 (檔案) 下的 BIN。
選取 [儲存]。
依照提示建立組 態配置檔。
部署 應用程控 – 將原則 組態配置檔強制執行至預定的系統。
注意
系統管理員必須從要切換以強制執行的預定系統中排除先前建立的應用程式 – 審核策略