Essential Eight 应用程序控制
本文详细介绍了使用 Microsoft 应用保险箱和 Windows Defender 应用程序控制实现澳大利亚网络安全中心 (ACSC) Essential8 Maturity Model for Application Control 的方法。
应用程序控制是一种安全方法,旨在防止恶意代码在系统上执行。 实现此安全方法时,它可确保仅授权执行已批准的代码,例如可执行文件、软件库、脚本、安装程序和驱动程序。 由于其有效性,应用程序控制是 ACSC 缓解网络安全事件策略的八大基本策略之一。
应用程序控制是一种安全方法,旨在防止恶意代码在系统上执行。 实现此安全方法时,它可确保仅授权执行已批准的代码,例如可执行文件、软件库、脚本、安装程序和驱动程序。
虽然应用程序控制主要用于防止在系统上执行和传播恶意代码,但它也可以阻止安装和使用未经批准的应用程序。
- 成熟度级别 1 (ML1) :可以使用 Microsoft AppLocker 来实现
- 成熟度级别 2 和 3 (ML2 & ML3) :可以使用 Microsoft Windows Defender 应用程序控制来实现
实现应用程序控制涉及组织的以下高级步骤:
- 标识已批准的应用程序
- 开发应用程序控制规则以确保只能执行已批准的应用程序
- 使用更改管理过程维护应用程序控制规则
- 经常验证应用程序控制规则
确定如何在组织内强制实施应用程序授权时,澳大利亚网络安全中心会考虑以下正确实现的方法:
- 加密哈希规则
- 发布者认证规则
- 配置文件系统权限以防止未经授权修改文件夹和文件权限、文件夹内容和单个文件) 时,路径规则 (
应用程序控制可以防止未经授权执行未经批准的应用程序。 应用程序控制还有助于识别威胁参与者在系统上执行恶意代码的尝试。 将 WDAC 配置为为授权和未经授权的执行生成事件日志可以为组织的安全运营中心提供有价值的信息。
请务必注意,应用程序控制解决方案不会取代防病毒和其他已到位的安全软件解决方案。 WDAC 始终与防病毒解决方案(例如Defender 防病毒)协同工作。 结合使用Microsoft安全解决方案有助于采用有效的深层防御方法来防止系统遭到入侵。
澳大利亚网络安全中心对于构成“基本八项”的缓解策略有三个成熟度级别。 成熟度级别基于威胁参与者使用的日益提高的贸易技术级别。 在应用程序控制范围内,澳大利亚网络安全中心确定满足 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 | 应用程序控制在面向 Internet 的服务器上实现。 |
ISM-1656 | 3 | 应用程序控制在非面向 Internet 的服务器上实现。 |
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 | 应用程序控制应用于操作系统、Web 浏览器和电子邮件客户端使用的用户配置文件和临时文件夹。 |
ISM-1871 | 2、3 | 应用程序控制应用于操作系统、Web 浏览器和电子邮件客户端使用的用户配置文件和临时文件夹以外的所有位置。 |
ISM-1228 | 2、3 | 及时分析网络安全事件,以识别网络安全事件。 |
ISM-1906 | 2、3 | 将及时分析来自面向 Internet 的服务器的事件日志,以检测网络安全事件。 |
ISM-1907 | 3 | 将及时分析来自非 Internet 服务器的事件日志,以检测网络安全事件。 |
ISM 2024 年 9 月控制 | 成熟度级别 | Control | Measure |
---|---|---|---|
ISM-0109 | 3 | 及时分析工作站中的事件日志,以检测网络安全事件。 | 使用 Defender for Endpoint P2。 Windows 事件日志通过 AMA 或 Windows 转发事件解决方案使用Windows 安全中心事件在 Microsoft Sentinel 和 Microsoft Defender XDR内捕获。 |
ISM-0140 | 2、3 | 发生或发现网络安全事件后,将尽快报告给 ASD。 | 不在本文档的范围内。 请参阅此表后面的注释。 3 |
ISM-0123 | 2、3 | 网络安全事件发生或被发现后,将尽快报告给首席信息安全官或其一名代表。 | 不在本文档的范围内。 请参阅此表后面的注释。 3 |
ISM-0843 | 1, 2, 3 | 应用程序控制在工作站上实现。 | 根据组织的成熟度级别要求配置和使用 Windows Defender 应用程序控制/AppLocker。 |
ISM-1490 | 2、3 | 应用程序控制在面向 Internet 的服务器上实现。 | 配置和使用 Windows Defender 应用程序控制 |
ISM-1656 | 3 | 应用程序控制在非面向 Internet 的服务器上实现。 | 配置和使用 Windows Defender 应用程序控制 |
ISM-1544 | 2、3 | Microsoft建议的应用程序阻止列表已实现。 | Microsoft的“建议的块规则”已实现 |
ISM-1657 | 1, 2, 3 | 应用程序控制将可执行文件、软件库、脚本、安装程序、编译的 HTML、HTML 应用程序和控制面板小程序的执行限制为组织批准的集。 | Microsoft建议在应用程序控制策略中创建文件发布者规则或文件哈希的定义列表。 1 |
ISM-1658 | 3 | 应用程序控制将驱动程序的执行限制为组织批准的集。 | 虚拟机监控程序保护的代码完整性已启用,并且默认为 Windows 11 2022+ |
ISM-1582 | 2、3 | 每年或更频繁地验证应用程序控制规则集。 | 不在本文档的范围内。 请参阅此表下面的说明。 3 |
ISM-1659 | 3 | Microsoft的易受攻击的驱动程序阻止列表已实现。 | Microsoft的“建议的驱动程序阻止规则”已实现 |
ISM-1660 | 2、3 | 允许和阻止的应用程序控制事件将集中记录。 | 使用 Defender for Endpoint P2。 Windows 事件日志在 Microsoft Sentinel 内捕获,Microsoft Defender XDR通过 AMA 或“Windows 转发事件”解决方案使用“Windows 安全中心事件”。 |
ISM-1815 | 2、3 | 事件日志受到保护,防止未经授权的修改和删除。 | 强制执行Microsoft Defender XDR和Microsoft Sentinel Role-Based 访问控制。 |
ISM-1819 | 2、3 | 在确定网络安全事件后,将制定网络安全事件响应计划。 | 不在本文档的范围内。 请参阅此表下面的说明。 3 |
ISM-1870 | 1, 2, 3 | 应用程序控制应用于操作系统、Web 浏览器和电子邮件客户端使用的用户配置文件和临时文件夹。 | Microsoft建议在应用程序控制策略中创建文件发布者规则或文件哈希的定义列表。 可以使用 Microsoft AppLocker 实现成熟度级别 1。 成熟度级别 2 和 3 需要 Windows Defender 应用程序控制。 2 |
ISM-1871 | 2、3 | 应用程序控制应用于操作系统、Web 浏览器和电子邮件客户端使用的用户配置文件和临时文件夹以外的所有位置。 | Windows Defender 应用程序控制的实现和配置 |
ISM-1228 | 2、3 | 及时分析网络安全事件,以识别网络安全事件。 | 不在本文档的范围内。 请参阅此表后面的注释。 3 |
ISM-1906 | 2、3 | 将及时分析来自面向 Internet 的服务器的事件日志,以检测网络安全事件。 | 使用 Defender for Endpoint P2。 Windows 事件日志通过 AMA 或 Windows 转发事件解决方案使用Windows 安全中心事件在 Microsoft Sentinel 和 Microsoft Defender XDR内捕获。 |
ISM-1907 | 3 | 将及时分析来自非 Internet 服务器的事件日志,以检测网络安全事件。 | 使用 Defender for Endpoint P2。 Windows 事件日志通过 AMA 或 Windows 转发事件解决方案使用Windows 安全中心事件在 Microsoft Sentinel 和 Microsoft Defender XDR内捕获。 |
重要
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 策略可以应用于系统上的所有用户,也可以应用于具有可基于以下规则定义的单个用户和组:
- 加密哈希规则
- 发布者认证规则
- 路径规则
可以在 Windows 操作系统的任何受支持的版本和添加版本上创建 AppLocker 策略,并且可以使用 组策略、PowerShell 或移动设备管理解决方案进行部署。
Windows 10引入了 Windows Defender 应用程序控制 (WDAC) 。 它允许组织控制哪些用户模式 (应用程序) 和内核模式 (驱动程序) 进程在其 Windows 操作系统上运行。 WDAC 策略作为一个整体应用于托管系统,并影响设备的所有用户,其规则可基于以下条件定义:
- 加密哈希规则
- 发布者认证规则
- 路径规则
- 应用程序的信誉(由Microsoft的智能安全图确定)
- 由托管安装程序启动应用程序安装的进程标识
可以在任何受支持的客户端版本的 Windows 10、Windows 11 或 Windows Server 2016 及更高版本上创建 WDAC 策略。 可以使用 组策略、移动设备管理解决方案、Configuration Manager或 PowerShell 部署 WDAC 策略。
由于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 Intune、组策略 或 PowerShell 部署Microsoft AppLocker。 部署方法将取决于组织的当前管理解决方案。
有关部署应用保险箱的详细信息,请参阅以下文章:
Microsoft AppLocker 相关事件由安全信息和事件管理解决方案(例如Microsoft Sentinel)监视。 还可以使用Microsoft Defender for Endpoint的高级搜寻信息监视事件。
Microsoft Defender for Endpoint:AppLocker 参考
Microsoft Defender for Endpoint捕获与 Microsoft AppLocker 相关的以下事件。
ActionType 名称 | 事件源 ID |
---|---|
AppControlExecutableAudited | 8003 |
AppControlExecutableBlocked | 8004 |
AppControlPackagedAppAudited | 8021 |
AppControlPackagedAppBlocked | 8022 |
AppControlPackagedAppBlocked | 8006 |
AppControlScriptBlocked | 8007 |
AppControlCIScriptAudited | 8001 |
有关事件查看器和高级搜寻的详细信息,请参阅以下文章:
Microsoft概述了使用 WDAC 满足 Essential Eight 应用程序控制 ML2 和 ML3 的设计过程、生命周期管理、部署和操作指南。
使用 Microsoft AppLocker 可以实现对 Essential Eight 应用程序控制 ML1 的要求的客户。
使用本指南的先决条件是必需的:
- Windows 11 22H2 企业版
- 将 Intune 用于管理解决方案
- Defender for Endpoint,用于终结点安全解决方案
- 安全信息和事件管理的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 支持两种策略格式:
单策略格式:随 RTM 和 Windows Server 2016 Windows 10 发布的原始策略格式。 单策略格式在任何给定时间仅支持系统上的单个活动策略
建议) (多种策略格式: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:使用 PowerShell 中的可配置代码完整性 Cmdlet 创建 WDAC 策略。 PowerShell 允许 IT 专业人员自动执行 WDAC 策略系统扫描,这将生成策略 XML。 PowerShell 可用于合并策略 XRL、设置策略规则并在必要时添加其他策略文件规则 可配置代码完整性 Cmdlet 还可用于修改 WDAC 示例策略以满足组织的要求。
- Windows Defender 应用程序控制向导 (建议) :WDAC 策略向导是一个开源 Windows 桌面应用程序,以 C# 编写并捆绑为 MSIX 包。 它旨在为安全架构师提供安全性,系统管理员使用更用户友好的方法来创建、编辑和合并应用程序控制策略。 此工具在后端使用 Config CI PowerShell cmdlet,因此该工具和 PowerShell cmdlet 的输出策略相同
有关策略创建的详细信息,请参阅以下文章:
Microsoft建议使用 Windows Defender 应用程序控制向导来实现 Essential Eight for Application Control。 或者,使用示例策略作为基础的 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) 当前不支持托管安装程序规则集合类型,因此必须使用 PowerShell Microsoft Intune 的 AppLocker 策略入口。
由于需要 Windows Defender 应用程序控制功能“脚本强制”才能满足 ISM-1657 要求,因此需要执行脚本来控制 PowerShell、VBscript、cscript、Cscript、HSMTA 和 MSXML。 配置“托管安装程序”的 PowerShell 脚本需要使用哈希或发布服务器在 WDAC 文件策略规则中。
Microsoft建议为Microsoft Intune配置托管安装程序。 Intune允许对使用 Microsoft Intune 打包的应用程序进行可靠的管理,而无需频繁更新 Windows Defender 应用程序控制策略。
可以使用 Microsoft Intune,通过两种方式为托管安装程序部署此配置脚本,具体取决于方案:
- 哈希:需要在 WDAC 文件策略中知道脚本的哈希,并使用 Microsoft Intune 中的 Microsoft Win32 内容准备工具或 PowerShell 脚本功能进行打包和部署。
- 代码签名 (发布者) :PowerShell 脚本已由受信任的颁发机构签名,并且已使用 WDAC 文件策略进行签名,并在 Microsoft Intune 中使用 Microsoft Win32 内容准备工具或 PowerShell 脚本功能进行打包和部署。
有关部署 PowerShell 脚本的详细信息,请参阅以下文章:
- 使用 Windows Defender 应用程序控制自动允许托管安装程序部署的应用
- AppLocker CSP
- 使用 Windows Defender 应用程序控制 (WDAC) 执行脚本
- Microsoft Intune 中的 Win32 应用管理
- 在 Intune 中的 Windows 10/11 设备上使用 PowerShell 脚本
通过了解选项并做出设计决策,组织可以使用 Windows Defender 应用控制向导创建第一个审核策略:
打开 Windows Defender 应用控制向导并选择“策略创建者”。
在 “策略创建者”中,选择“ 多个策略格式 ”和“ 基本策略 ”,然后选择“ 下一步”。
在 策略模板中,会显示三个选项:
- 默认 Windows 模式包括 Windows OS、应用商店应用、企业版 (Office 365 Pro Plus Microsoft 365 应用版) 和 WHQL 签名的内核驱动程序。
- 允许Microsoft模式 包括默认 Windows 模式和所有Microsoft签名的应用程序中的所有部分。
- 签名和信誉模式 包括前面所有部分和 Reputation-Based 智能。
重要
由于 ISM 1657) 和“应用程序控制规则集每年或更频繁地验证” ( (ISM 1582) 要求“组织批准的集”,Reputation-Based 应用程序控制智能不符合基本 8 个应用程序控制。WDAC 中的此功能不符合 ML2 或 ML3 的要求。 Microsoft建议使用 Reputation-Based 智能,以便组织在基本八个应用程序控制上下文之外采用 WDAC。
- 根据组织的要求,选择“ 默认 Windows 模式 ”或“ 允许Microsoft模式 ”。 对于本文档,Microsoft使用的是 允许Microsoft模式。
- 将“策略名称和位置”修改为所需的“策略名称”和“策略文件位置”以存储文件,然后选择“下一步”。
备注
可在此处找到 WDAC - 策略规则的详细信息。
- ISM 1657 和 1658 需要禁用脚本强制设置为“已禁用”,以控制脚本、符合 HTML 和 HTML 应用程序。
- ISM 1657、1658 和 1582 需要将智能安全图设置为“已禁用”。
- 建议“启用”托管安装程序,以协助组织实现 WDAC 策略生命周期。
- WDAC 策略需要用户模式代码完整性才能同时应用于内核模式和用户模式二进制文件。
- 允许补充策略 需要使用多策略格式来帮助组织使用 WDAC 策略生命周期。
备注
所有其他 WDAC 策略规则都依赖于组织中的要求。
- 在 “签名规则”中,管理员能够看到已添加为“允许发布者规则”的所有Microsoft证书。 本文稍后将介绍 “添加自定义规则 ”。
- 选择 下一步。
Windows Defender 应用控制向导生成:
- 策略 XML
- {GUID}。CIP
可在此处找到 WDAC - 策略规则的详细信息。
备注
使用 Windows Defender 应用控制向导生成的每个策略都会采购新的全局唯一标识符 (GUID) 。
已成功创建 WDAC 策略。
由于组织已使用 WDAC 向导创建了 WDAC 策略,因此组织可以在文本编辑器中查看此文件的上下文。 XML 分为几个不同的部分,对于 Essential Eight 的上下文,请记下 PolicyID 和 BasePolicyID。
备注
虽然可以直接编辑策略 XML。 Microsoft建议使用 PowerShell 中的 Windows Defender 应用控制向导或可配置代码完整性 Cmdlet 对策略规则或签名文件进行所有其他更改。
现在,组织已创建审核策略,现在可以使用Intune设备管理来部署它。
- 登录到Intune管理中心。
- 在Intune管理中心内,依次转到“设备”和“配置文件”。
- 接下来,创建配置文件>平台 - Windows 10或更高版本、配置文件类型模板和自定义。
- 创建策略的名称 (例如“应用程序控制 - Microsoft允许 - 审核”) 并选择“ 下一步”。
- 在 “OMA-URI 设置”下,选择“ 添加”。
备注
此信息依赖于从 Windows >Defender 应用控制向导生成的策略 ID,该策略 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 审核策略监视:
- 应用程序控制事件 ID:应用程序控制事件 ID 是查看 Windows 操作系统上审核事件的传统方法。 可以使用 Windows 事件日志转发或第三方安全信息和事件管理将这些事件 ID 转发到集中位置。
有关事件 ID 的信息,请参阅 了解应用程序控制事件 ID - Windows 安全性。
- Microsoft Defender for Endpoint (建议) :Windows Defender for Endpoint 和 AppLocker 相关事件在高级搜寻Microsoft Defender for Endpoint中捕获。 事件中包含的信息包括 Device、FileName、FolderPath、InitiatingProcessFileName、文件哈希等。 请参阅: 使用高级搜寻 (Windows) 查询应用程序控制事件 - Windows 安全性
Microsoft建议使用Microsoft Defender XDR (MDE) 集成来Microsoft Sentinel。 与Microsoft Defender for Endpoint相比,MDE和Sentinel允许高级搜寻遥测数据的存储时间超过 30 天。
有关连接和监视的详细信息,请参阅以下文章:
- 将数据从Microsoft Defender XDR连接到Microsoft Sentinel
- Windows 客户端设备上的 Azure Monitor 代理
- 使用 Azure Monitor 代理从虚拟机收集事件和性能计数器
以下示例演示用户具有多个用于组织日常任务的应用程序。 该示例包含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 XDR中的高级搜寻查询语言
使用 KQL 缩小搜索结果范围后,下一步是更新 WDAC 基本策略或使用补充策略。 下一个示例使用补充策略。
打开 Windows Defender 应用控制向导 ,然后选择 “策略创建者”。
在 “策略创建者”中,选择“ 多个策略格式”,然后选择 “补充策略”,导航到基本策略,更新位置以保存补充策略,然后选择“ 下一步”。
在策略规则中选择“下一步”。
在 “策略签名规则 ”中,选择“ 自定义规则”。
在 自定义规则条件中,有许多可用选项:
- 规则范围用户模式规则/内核模式规则
- 规则操作:允许/拒绝
- 规则类型
- 发布者 (推荐)
- 文件
- File Attribute
- 打包的应用
- 散 列
- 参考文件
备注
Microsoft建议在适当情况下使用基于发布服务器的规则,并回退到未签名引用文件的基于哈希的规则,以实现 Essential Eight 应用程序控制。
使用 Microsoft Defender for Endpoint
- 在“搜索”中 搜索 文件名,导航到文件“信息”并下载该文件。
- 直接从高级搜寻中检查记录,并下载文件,然后下载所需的二进制文件。
- 使用所需的二进制文件,接下来继续为组织的 ISV 应用程序创建另一个策略。
- 在 Windows Defender 应用控件向导中,选择所需的 规则类型 并导航到上一步中的引用二进制文件。 下一个示例演示 VLC 满足所需的发布者信息。
备注
Microsoft建议颁发 CA,发布服务器在创建基于发布服务器的规则时 至少 要有选择性。 可以包含产品名称,ACSC 建议针对基于发布者的规则使用产品名称。
- 按 “下一步 ”和 “创建”。
- 使用前面“通过Microsoft Intune部署 Windows Defender 应用程序控制审核策略”一节中所述的步骤部署此补充策略。
若要切换以强制实施策略,请执行以下操作:
打开 Windows Defender 应用控制向导,然后选择“策略编辑器”。
导航到要更改为强制实施的策略 XML。
在策略规则中禁用审核模式开关。
在策略规则中选择“下一步”。
使用修改后的版本号创建 更新策略 ,并创建了一个新的 CIP 文件。
在 Microsoft Endpoint Manager 管理员 Center 中,依次转到“设备”和“配置文件”。
接下来,创建配置文件、平台 - Windows 10或更高版本、配置文件类型模板和自定义。
为策略创建名称,例如“应用程序控制 – 强制实施策略”,然后选择“ 下一步”。
在 “OMA-URI 设置”下,选择“ 添加”。
备注
此信息依赖于从 Windows Defender 应用控制向导为从上述创建审核部分创建的策略 XML 生成的策略 ID。
- Name = Microsoft Allow Enforce
- 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。
选择“保存”。
按照提示创建 配置文件。
部署 应用程序控制 - 将策略配置文件强制 实施到预期系统。
备注
管理员需要从要切换以强制实施的预期系统中排除以前创建的应用程序 - 审核策略