diff --git a/windows/security/threat-protection/windows-defender-application-control/TOC.md b/windows/security/threat-protection/windows-defender-application-control/TOC.md index bdaf9c0a68..5644387f36 100644 --- a/windows/security/threat-protection/windows-defender-application-control/TOC.md +++ b/windows/security/threat-protection/windows-defender-application-control/TOC.md @@ -13,11 +13,13 @@ ### [Types of devices](types-of-devices.md) ###Use WDAC with custom policies #### [Create an initial default policy](create-initial-default-policy.md) +#### [Create path-based rules](create-path-based-rules.md) #### [Microsoft recommended block rules](microsoft-recommended-block-rules.md) ### [Audit WDAC policies](audit-windows-defender-application-control-policies.md) ### [Merge WDAC policies](merge-windows-defender-application-control-policies.md) ### [Deploy multiple WDAC policies](deploy-multiple-windows-defender-application-control-policies.md) ### [Enforce WDAC policies](enforce-windows-defender-application-control-policies.md) +### [COM whitelisting](com-whitelisting.md) ### [Deploy WDAC with a managed installer](use-windows-defender-application-control-with-managed-installer.md) ### [Deploy WDAC with Intelligent Security Graph (ISG)](use-windows-defender-application-control-with-intelligent-security-graph.md) ### [Deploy WDAC policies using Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md) diff --git a/windows/security/threat-protection/windows-defender-application-control/com-whitelisting.md b/windows/security/threat-protection/windows-defender-application-control/com-whitelisting.md new file mode 100644 index 0000000000..9cd8ba8357 --- /dev/null +++ b/windows/security/threat-protection/windows-defender-application-control/com-whitelisting.md @@ -0,0 +1,60 @@ +--- +title: Windows Defender Application Control path-based rules (Windows 10) +description: Windows Defender Application Control restricts which applications users are allowed to run and the code that runs in the system core. +ms.prod: w10 +ms.mktglfcycl: deploy +ms.sitesec: library +ms.pagetype: security +ms.localizationpriority: medium +author: jsuther1974 +ms.date: 05/14/2019 +--- + +# COM Whitelisting + +**Applies to:** + +- Windows 10 +- Windows Server 2016 + +>[!IMPORTANT] +>Some information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. + +The [Microsoft Component Object Model (COM)](https://docs.microsoft.com/windows/desktop/com/the-component-object-model) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM specifies an object model and programming requirements that enable COM objects to interact with other objects. + +Get GUID of application to allow by either: +- Finding block event in Event Viewer (Application and Service Logs > Microsoft > Windows > AppLocker > MSI and Script) and extracting GUID +- Creating audit policy (using New-CIPolicy –Audit), potentially with specific provider, and use info from block events to get GUID + +### Author setting + +Three elements: +- Provider: platform on which code is running (values are Powershell, WSH, IE, VBA, MSI, or a wildcard “AllHostIds”) +- Key: GUID for the program you with to run, in the format Key="{33333333-4444-4444-1616-161616161616}" +- ValueName: needs to be set to "EnterpriseDefinedClsId" +One attribute: +- Value: needs to be “true” for allow and “false” for deny + Note: without quotation marks + Note: deny only works in base policies +- The setting needs to be placed in the order of ASCII values, first by Provider, then Key, then ValueName + +### Examples + +```xml + + + true + + + + + false + + + + + true + + +``` + diff --git a/windows/security/threat-protection/windows-defender-application-control/create-path-based-rules.md b/windows/security/threat-protection/windows-defender-application-control/create-path-based-rules.md new file mode 100644 index 0000000000..852c003dc0 --- /dev/null +++ b/windows/security/threat-protection/windows-defender-application-control/create-path-based-rules.md @@ -0,0 +1,59 @@ +--- +title: Windows Defender Application Control path-based rules (Windows 10) +description: Beginning with Windows 10 version 1903, Windows Defender Application Control (WDAC) policies can contain path-based rules. +ms.prod: w10 +ms.mktglfcycl: deploy +ms.sitesec: library +ms.pagetype: security +ms.localizationpriority: medium +author: jsuther1974 +ms.date: 05/14/2019 +--- + +# Create Windows Defender Application Control path-based rules + +**Applies to:** + +- Windows 10 +- Windows Server 2016 + +>[!IMPORTANT] +>Some information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. + +Beginning with Windows 10 version 1903, Windows Defender Application Control (WDAC) policies can contain path-based rules. + +- New-CIPolicy parameters + - FilePath: create path rules under path \ for anything not user-writeable (at the individual file level) + ```powershell + New-CIPolicy -f .\mypolicy.xml -l FilePath -s -u + ``` + Optionally, add -UserWriteablePaths to ignore user writeability + + - FilePathRule: create a rule where filepath string is directly set to value of \ + ```powershell + New-CIPolicyRule -FilePathRule + ``` + Useful for wildcards like C:\foo\\* + +- Usage follows the same flow as per-app rules: + ```powershell + $rules = New-CIPolicyRule … + $rules += New-CIPolicyRule … + … + New-CIPolicyRule -f .\mypolicy.xml -u + ``` + +- Wildcards supported + - Suffix (ex. C:\foo\\*) OR Prefix (ex. *\foo\bar.exe) + - One or the other, not both at the same time + - Does not support wildcard in the middle (ex. C:\\*\foo.exe) + - Examples: + - %WINDIR%\\... + - %SYSTEM32%\\... + - %OSDRIVE%\\... + +- Disable default FilePath rule protection of enforcing user-writeability. For example, to add “Disabled:Runtime FilePath Rule Protection” to the policy: + ```powershell + Set-RuleOption -o 18 .\policy.xml + ``` + diff --git a/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md b/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md index a542e82236..7408abf167 100644 --- a/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md +++ b/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md @@ -29,9 +29,9 @@ Beginning with Windows 10 version 1903, WDAC supports multiple code integrity po - Base + supplemental policy: union - Files that are allowed by the base policy or the supplemental policy are not blocked -## Newly Supported Scenarios +## Newly supported scenarios -WDAC brings you the ability to support multiple CI policies. Three scenarios are now supported: +With the ability to support multiple CI policies, three new scenarios are supported: 1. Enforce and Audit Side-by-Side (Intersection) - To validate policy changes before deploying in enforcement mode, deploy an audit-mode base policy side-by-side with an existing enforcement-mode base policy @@ -41,3 +41,69 @@ WDAC brings you the ability to support multiple CI policies. Three scenarios are 3. Supplemental Policies (Union) - Deploy a supplemental policy (or policies) to expand a base policy - Ex. The Azure host base policy restricts tightly to just allow Windows and hardware drivers. Can add a supplemental policy to allow just the additional signer rules needed to support signed code from the Exchange team. + +## PowerShell parameters + +New-CIPolicy +- MultiplePolicyFormat: allows for multiple policies + +```powershell +New-CIPolicy [-FilePath] -Level {None | Hash | FileName | SignedVersion | Publisher | FilePublisher | LeafCertificate | PcaCertificate | RootCertificate | WHQL | WHQLPublisher | WHQLFilePublisher | PFN | FilePath} + [-DriverFiles ] [-Fallback {None | Hash | FileName | SignedVersion | Publisher | FilePublisher | LeafCertificate | PcaCertificate | RootCertificate | WHQL | WHQLPublisher | WHQLFilePublisher | PFN | FilePath}] + [-Audit] [-ScanPath ] [-ScriptFileNames] [-AllowFileNameFallbacks] [-SpecificFileNameLevel {None | OriginalFileName | InternalName | FileDescription | ProductName | PackageFamilyName | FilePath}] [-UserPEs] [-NoScript] + [-Deny] [-NoShadowCopy] [-MultiplePolicyFormat] [-OmitPaths ] [-PathToCatroot ] [] – to generate new policy format(base policy and policy type and policy guid) +``` + +Set-CIPolicyIdInfo +- **SupplementsBasePolicyID**: guid of new supplemental policy +- **BasePolicyToSupplementPath**: base policy that the supplemental policy applies to +- **ResetPolicyID**: reset the policy guids back to a random guid + +```powershell +Set-CIPolicyIdInfo [-FilePath] [-PolicyName ] [-SupplementsBasePolicyID ] [-BasePolicyToSupplementPath ] [-ResetPolicyID] [-PolicyId ] [] +``` + +Add-SignerRule +- **Supplemental**: provides supplemental signers + +```powershell +Add-SignerRule -FilePath -CertificatePath [-Kernel] [-User] [-Update] [-Supplemental] [-Deny] [] +``` + +Set-RuleOption +- **Enabled:Allow Supplemental Policies**: makes base policy able to be supplemented + +### Examples + +**Scenario #1: Creating a new base policy** + +```powershell +New-CiPolicy -MulitplePolicyFormat -foo –bar +``` + +- **MultiplePolicyFormat** switch results in 1) random GUIDs being generated for the policy ID and 2) the policy type being specified as base. + Can optionally choose to make it supplementable: + - Set-RuleOption has a new option **Enabled:Allow Supplemental Policies** to set for base policy +- For signed policies that are being made supplementable, need to ensure that supplemental signers are defined. Use “Add-SignerRule” to provide supplemental signers. + ```powershell + Add-SignerRule -FilePath -CertificatePath [-Kernel] [-User] [-Update] [-Supplemental] [-Deny] [] + ``` + +**Scenario #2: Creating a new supplemental policy** + +1. Scan using `New-CiPolicy –MuliplePolicyFormat` to generate a base policy: + ```powershell + New-CIPolicy -Level PcaCertificate -UserPEs -ScanPath -MultiplePolicyFormat 3> -FilePath + ``` +2. Change this new base policy to a supplemental policy + - Provide path of base in `Set-CIPolicyIdInfo –BasePolicytoSupplementPath` + - Provide GUID of base in `Set-CIPolicyIdInfo –SupplementsBasePolicyID` + ```powershell + Set-CIPolicyIdInfo -BasePolicyToSupplementPath -SupplementsBasePolicyID -FilePath + ``` + - Can revert the policy back to being a base policy using `-ResetPolicyID` + +**Scenario #3: Merging policies** + +- When merging, the policy type and ID of the leftmost/first policy specified is used + - If the leftmost is a base policy with ID , then regardless of what the GUIDS and types are for any subsequent policies, the merged policy will be a base policy with ID diff --git a/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md b/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md index 718fc4a51c..0cac5a2d54 100644 --- a/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md +++ b/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md @@ -8,7 +8,7 @@ ms.sitesec: library ms.pagetype: security ms.localizationpriority: medium author: jsuther1974 -ms.date: 05/03/2018 +ms.date: 05/14/2019 --- # Manage packaged apps with Windows Defender Application Control @@ -48,3 +48,46 @@ Just as there are differences in managing each rule collection, you need to mana 3. Continue to update the WDAC policies as new package apps are introduced into your environment. To do this, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md). +## Blocking packaged apps + +You can use `New-CIPolicyRule -Package $Package -Deny` to block packaged apps: + +1. Get the info about an installed package. + ```powershell + $package = Get-AppxPackage -name + ``` + Dependencies field in output is full Package object, can be accessed and passed directly to New-CIPolicyRule. +2. Make a rule. + ```powershell + $Rule = New-CIPolicyRule -Package $package -deny + ``` +3. Repeat for other packages you want to block using $rule +=…. +4. Make a policy for just the blocks you created for packages. + ```powershell + New-CIpolicy -rules $rule -f .\policy.xml -u + ``` +5. Merge with allow windows policy, or you could also use examplepolicies\AllowAll.xml. + ```powershell + Merge-CIPolicy -PolicyPaths .\policy.xml,C:\windows\Schemas\codeintegrity\examplepolicies\DefaultWindows_Audit.xml -o allowWindowsDenyPackages.xml + ``` +6. Disable audit mode. + ```powershell + Set-RuleOption -o 3 -Delete .\allowWindowsDenyPackages.xml + ``` +7. Enable invalidate EAs on reboot. + ```powershell + Set-RuleOption -o 15 .\allowWindowsDenyPackages.xml + ``` +8. Compile the policy + ```powershell + ConvertFrom-CIPolicy .\AllowWindowsDenyPackages.xml C:\compiledpolicy.bin + ``` +9. Install the policy withwout restarting. + ```powershell + Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = "C:\compiledpolicy.bin"} + ``` + +After doing this on the next build of Dev3, for the apps that you blocked, already installed apps should fail to launch, and should you put this policy on another machine that hasn’t yet installed the apps, store should block them from being purchased/installed. +If you wanted to make a rule for an app that isn’t already installed, first make a rule for an app that is. Then for the app you want to actually block take the store URL (from store page click … then share, then copy link to get something like: https://www.microsoft.com/store/productId/9WZDNCRFJ3TJ) and grab the hash code at the end (in bold) then replace the bolded bit below: +https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfj3tj/applockerdata +then grab packagefamilyname and replace the one in the xml you got in step 4 with the PFN from the link above, then run through 5-9 again. diff --git a/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-improvements-in-windows-10-version-1903.md b/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-improvements-in-windows-10-version-1903.md index 95d58415d4..810e645612 100644 --- a/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-improvements-in-windows-10-version-1903.md +++ b/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-improvements-in-windows-10-version-1903.md @@ -1,16 +1,16 @@ --- -title: Windows Defender Application Control improvements in Windows 10 version 1903 (Windows 10) -description: Windows Defender Application Control restricts which applications users are allowed to run and the code that runs in the system core. +title: Windows Defender Application Control Frequently asked questions (Windows 10) +description: Frequently asked questions. ms.prod: w10 ms.mktglfcycl: deploy ms.sitesec: library ms.pagetype: security ms.localizationpriority: medium author: jsuther1974 -ms.date: 05/06/2019 +ms.date: 05/14/2019 --- -# Windows Defender Application Control improvements in Windows 10 version 1903 +# Frequently asked questions **Applies to:** @@ -20,199 +20,6 @@ ms.date: 05/06/2019 >[!IMPORTANT] >Some information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. -This topic covers improvements introduced in Windows 10, version 1903. - -## Path-based rules - -Beginning with Windows 10 version 1903, Windows Defender Application Control (WDAC) policies can contain path-based rules. - -- New-CIPolicy parameters - - FilePath: create path rules under path \ for anything not user-writeable (at the individual file level) - ```powershell - New-CIPolicy -f .\mypolicy.xml -l FilePath -s -u - ``` - Optionally, add -UserWriteablePaths to ignore user writeability - - - FilePathRule: create a rule where filepath string is directly set to value of \ - ```powershell - New-CIPolicyRule -FilePathRule - ``` - Useful for wildcards like C:\foo\\* - -- Usage follows the same flow as per-app rules: - ```powershell - $rules = New-CIPolicyRule … - $rules += New-CIPolicyRule … - … - New-CIPolicyRule -f .\mypolicy.xml -u - ``` - -- Wildcards supported - - Suffix (ex. C:\foo\\*) OR Prefix (ex. *\foo\bar.exe) - - One or the other, not both at the same time - - Does not support wildcard in the middle (ex. C:\\*\foo.exe) - - Examples: - - %WINDIR%\\... - - %SYSTEM32%\\... - - %OSDRIVE%\\... - -- Disable default FilePath rule protection of enforcing user-writeability. For example, to add “Disabled:Runtime FilePath Rule Protection” to the policy: - ```powershell - Set-RuleOption -o 18 .\policy.xml - ``` - - -## COM Whitelisting - -• https://docs.microsoft.com/en-us/windows/desktop/com/the-component-object-model - -Get GUID of application to allow by either: -- Finding block event in Event Viewer (Application and Service Logs > Microsoft > Windows > AppLocker > MSI and Script) and extracting GUID -- Creating audit policy (using New-CIPolicy –Audit), potentially with specific provider, and use info from block events to get GUID - -### Author setting - -Three elements: -- Provider: platform on which code is running (values are Powershell, WSH, IE, VBA, MSI, or a wildcard “AllHostIds”) -- Key: GUID for the program you with to run, in the format Key="{33333333-4444-4444-1616-161616161616}" -- ValueName: needs to be set to "EnterpriseDefinedClsId" -One attribute: -- Value: needs to be “true” for allow and “false” for deny - Note: without quotation marks - Note: deny only works in base policies -- The setting needs to be placed in the order of ASCII values, first by Provider, then Key, then ValueName - -### Examples - -```xml - - - true - - - - - false - - - - - true - - -``` - -## New PowerShell parameters - -New-CIPolicy -- MultiplePolicyFormat: allows for multiple policies - -```powershell -New-CIPolicy [-FilePath] -Level {None | Hash | FileName | SignedVersion | Publisher | FilePublisher | LeafCertificate | PcaCertificate | RootCertificate | WHQL | WHQLPublisher | WHQLFilePublisher | PFN | FilePath} - [-DriverFiles ] [-Fallback {None | Hash | FileName | SignedVersion | Publisher | FilePublisher | LeafCertificate | PcaCertificate | RootCertificate | WHQL | WHQLPublisher | WHQLFilePublisher | PFN | FilePath}] - [-Audit] [-ScanPath ] [-ScriptFileNames] [-AllowFileNameFallbacks] [-SpecificFileNameLevel {None | OriginalFileName | InternalName | FileDescription | ProductName | PackageFamilyName | FilePath}] [-UserPEs] [-NoScript] - [-Deny] [-NoShadowCopy] [-MultiplePolicyFormat] [-OmitPaths ] [-PathToCatroot ] [] – to generate new policy format(base policy and policy type and policy guid) -``` - -Set-CIPolicyIdInfo -- **SupplementsBasePolicyID**: guid of new supplemental policy -- **BasePolicyToSupplementPath**: base policy that the supplemental policy applies to -- **ResetPolicyID**: reset the policy guids back to a random guid - -```powershell -Set-CIPolicyIdInfo [-FilePath] [-PolicyName ] [-SupplementsBasePolicyID ] [-BasePolicyToSupplementPath ] [-ResetPolicyID] [-PolicyId ] [] -``` - -Add-SignerRule -- **Supplemental**: provides supplemental signers - -```powershell -Add-SignerRule -FilePath -CertificatePath [-Kernel] [-User] [-Update] [-Supplemental] [-Deny] [] -``` - -Set-RuleOption -- **Enabled:Allow Supplemental Policies**: makes base policy able to be supplemented - -### Examples - -**Scenario #1: Creating a new base policy** - -```powershell -New-CiPolicy -MulitplePolicyFormat -foo –bar -``` - -- **MultiplePolicyFormat** switch results in 1) random GUIDs being generated for the policy ID and 2) the policy type being specified as base. - Can optionally choose to make it supplementable: - - Set-RuleOption has a new option **Enabled:Allow Supplemental Policies** to set for base policy -- For signed policies that are being made supplementable, need to ensure that supplemental signers are defined. Use “Add-SignerRule” to provide supplemental signers. - ```powershell - Add-SignerRule -FilePath -CertificatePath [-Kernel] [-User] [-Update] [-Supplemental] [-Deny] [] - ``` - -**Scenario #2: Creating a new supplemental policy** - -1. Scan using `New-CiPolicy –MuliplePolicyFormat` to generate a base policy: - ```powershell - New-CIPolicy -Level PcaCertificate -UserPEs -ScanPath -MultiplePolicyFormat 3> -FilePath - ``` -2. Change this new base policy to a supplemental policy - - Provide path of base in `Set-CIPolicyIdInfo –BasePolicytoSupplementPath` - - Provide GUID of base in `Set-CIPolicyIdInfo –SupplementsBasePolicyID` - ```powershell - Set-CIPolicyIdInfo -BasePolicyToSupplementPath -SupplementsBasePolicyID -FilePath - ``` - - Can revert the policy back to being a base policy using `-ResetPolicyID` - -**Scenario #3: Merging policies** - -- When merging, the policy type and ID of the leftmost/first policy specified is used - - If the leftmost is a base policy with ID , then regardless of what the GUIDS and types are for any subsequent policies, the merged policy will be a base policy with ID - -## Packaged App Rules - -`New-CIPolicyRule -Package $Package -Deny` to block apps is your best use case, so something like: - -1. Get the info about an installed package. - ```powershell - $package = Get-AppxPackage -name - ``` - Dependencies field in output is full Package object, can be accessed and passed directly to New-CIPolicyRule. -2. Make a rule. - ```powershell - $Rule = New-CIPolicyRule -Package $package -deny - ``` -3. Repeat for other packages you want to block using $rule +=…. -4. Make a policy for just the blocks you created for packages. - ```powershell - New-CIpolicy -rules $rule -f .\policy.xml -u - ``` -5. Merge with allow windows policy, or you could also use examplepolicies\AllowAll.xml. - ```powershell - Merge-CIPolicy -PolicyPaths .\policy.xml,C:\windows\Schemas\codeintegrity\examplepolicies\DefaultWindows_Audit.xml -o allowWindowsDenyPackages.xml - ``` -6. Disable audit mode. - ```powershell - Set-RuleOption -o 3 -Delete .\allowWindowsDenyPackages.xml - ``` -7. Enable invalidate EAs on reboot. - ```powershell - Set-RuleOption -o 15 .\allowWindowsDenyPackages.xml - ``` -8. Compile the policy - ```powershell - ConvertFrom-CIPolicy .\AllowWindowsDenyPackages.xml C:\compiledpolicy.bin - ``` -9. Install the policy withwout restarting. - ```powershell - Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = "C:\compiledpolicy.bin"} - ``` - -After doing this on the next build of Dev3, for the apps that you blocked, already installed apps should fail to launch, and should you put this policy on another machine that hasn’t yet installed the apps, store should block them from being purchased/installed. -If you wanted to make a rule for an app that isn’t already installed, first make a rule for an app that is. Then for the app you want to actually block take the store URL (from store page click … then share, then copy link to get something like: https://www.microsoft.com/store/productId/9WZDNCRFJ3TJ) and grab the hash code at the end (in bold) then replace the bolded bit below: -https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfj3tj/applockerdata -then grab packagefamilyname and replace the one in the xml you got in step 4 with the PFN from the link above, then run through 5-9 again. - -## FAQs **Q:** What uniquely identifies a “file”? SHA1, SHA256, either, both? What is the “Flat hash” vs. normal?