adding path-based rules

windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md

@@ -23,8 +23,6 @@ Windows Defender Application Control (WDAC) provides control over a computer run
 
 A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. WDAC policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional WDAC policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md).
 
-> **Note**  Each computer can have only **one** WDAC policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to **C:\\Windows\\System32\\CodeIntegrity** and, for UEFI computers, **<EFI System Partition>\\Microsoft\\Boot**. Keep this in mind when you create your WDAC policies.
-
 Optionally, WDAC can align with your software catalog as well as any IT department–approved applications. One straightforward method to implement WDAC is to use existing images to create one master WDAC policy. You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computer’s role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
 
 If you plan to use an internal CA to sign catalog files or WDAC policies, see the steps in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md). 
@@ -104,3 +102,32 @@ To create the WDAC policy, they build a reference server on their standard hardw
 As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they will not need to update their WDAC policy. If they come to a time when the internally-written, unsigned application must be updated, they must also update the WDAC policy so that the hash in the policy matches the hash of the updated internal application.
 
 They could also choose to create a catalog that captures information about the unsigned internal application, then sign and distribute the catalog. Then the internal application could be handled by WDAC policies in the same way as any other signed application. An update to the internal application would only require that the catalog be regenerated, signed, and distributed (no restarts would be required).
+
+## Path-based rules
+
+Beginning with Windows 10 version 1903, WDAC policies can contain path-based rules.
+
+- New-CIPolicy parameters
+o	FilePath: create path rules under path <path to scan> for anything not user-writeable (at the individual file level)
+New-CIPolicy -f .\mypolicy.xml -l FilePath -s <path to scan> -u
+	Optionally, add -UserWriteablePaths to ignore user writeability
+o	FilePathRule: create a rule where filepath string is directly set to value of <any path string>
+New-CIPolicyRule -FilePathRule <any path string>
+•	Useful for wildcards like C:\foo\*
+•	Usage: same flow as per-app rules
+$rules = New-CIPolicyRule …
+$rules += New-CIPolicyRule …
+…
+New-CIPolicy -Rules $rules -f .\mypolicy.xml -u
+•	 Wildcards supported:
+o	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)
+o	Examples:
+	%WINDIR%\...
+	%SYSTEM32%\...
+	%OSDRIVE%\...
+•	Disable default FilePath rule protection of enforcing user-writeability
+Set-RuleOption -o 18 .\policy.xml
+o	Adds “Disabled:Runtime FilePath Rule Protection” to the policy
+