deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-14 14:27:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

added Q&A

Browse Source
This commit is contained in:
Justin Hall 2019-05-06 17:32:02 -07:00
parent 7bb830d8e3
commit fd96a3d538
1 changed files with 49 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

82
windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-improvements-in-windows-10-version-1903.md
View File

@ -237,20 +237,23 @@ then grab packagefamilyname and replace the one in the xml you got in step 4 wit
## FAQs
Misc
a. Questions:
• What uniquely identifies a “file”? SHA1, SHA256, either, both?
o What is the “Flat hash” vs. normal?
Either hash works as a unique identifier, would recommend sha256 though just because lower collision chance.
**Q:** What uniquely identifies a “file”? SHA1, SHA256, either, both? What is the “Flat hash” vs. normal?
**A:** Either hash works as a unique identifier, would recommend sha256 though just because lower collision chance.
“Authenticode Hash” is the hash we use, it is calculated in a way that does not change even if the file is embed signed, whereas “flat hash” is just a direct hash on the bytes of the file and changes with signature.
For Scripts/MSIs an embedded hash would use the SIP of the particular script type, while a catalog hash would use the flat hash (since catalogs are only aware of a few select SIPs, particularly the PE exe/dll one), so the 8028/8029 events log the “CatalogHash” as well, in case it differs from the hash used to evaluate against an embedded sig
• What property of a file is used to map out to a publisher?
Files are tied to publishers via their signature (either embed signed or catalog signed via a signed catalog containing that files hash), correlate 3089 events in order to get publisher data
**Q:** What property of a file is used to map out to a publisher?
**A:** Files are tied to publishers via their signature (either embed signed or catalog signed via a signed catalog containing that files hash), correlate 3089 events in order to get publisher data
• Can you give a description/enumeration of values for “signing level”?
**Q:** Can you give a description/enumeration of values for “signing level”?
Base signing levels are:
**A:** Base signing levels are:
```xml
#define SE_SIGNING_LEVEL_UNCHECKED 0x00000000
#define SE_SIGNING_LEVEL_UNSIGNED 0x00000001
#define SE_SIGNING_LEVEL_ENTERPRISE 0x00000002
@ -269,40 +272,53 @@ Base signing levels are:
#define SE_SIGNING_LEVEL_CUSTOM_7 0x0000000D
#define SE_SIGNING_LEVEL_WINDOWS_TCB 0x0000000E
#define SE_SIGNING_LEVEL_CUSTOM_6 0x0000000F
```
The TL;DR on signing levels is we have collections of certificates+EKUs that we use to define broad “security levels” based on signer, for example SE_SIGNING_LEVEL_WINDOWS generally maps to “signed as part of a production windows build)
Some also inherit from others (e.g. signing level windows is a subset of microsoft)
The TL;DR on signing levels is we have collections of certificates+EKUs that we use to define broad “security levels” based on signer, for example SE_SIGNING_LEVEL_WINDOWS generally maps to “signed as part of a production Windows build)
Some also inherit from others (e.g. signing level Windows is a subset of Microsoft)
See minkernel\published\base\ntseapi_x.w and ntseapi.w, and/or poke around in onecore\base\ci\dll\cipolicy.c searching for references to se_signing_level* for more on signing levels and how they are used with CIPolicy
**Q:** What is the “SI Signing Scenario”?
This maps to either kernel or user mode (0 or 1 respectively). CIPolicy lets you configure whitelists for each separately.
• What is the “SI Signing Scenario”?
Pretty sure this one maps to either kernel or user mode (0 or 1 respectively), CIPolicy lets you configure whitelists for each separately, e.g. you probably wouldn’t want some random user mode app, say notepad++ to run as a kernel driver 😊
• Can you also provide the “description” for the events? I know audit/block are each one of two values next to each other, but do they audit/block a specific file type only? Script? Exe?
3076 Audit for exe/dll generated by CI in the createprocess stack
3077 enforced version
3089 Signing information event correlated with either a 3076/3077 event, contains # of signatures and an index as to which signature it is, one 3089 is generated for each signature of a file (so many 3089 map to one 3076/77). Unsigned files will generate a single 3089 with TotalSignatureCount 0
8028 Audit for scripts/msis generated by WLDP being called by the scripthosts themselves (scripthosts opt in to enforcement, so we don’t enforce on 3rd party scripthosts like python/ruby)
8029 Enforce for scripts
**Q:** Can you also provide the “description” for the events?
I know audit/block are each one of two values next to each other, but do they audit/block a specific file type only? Script? Exe?
|-------|--------------------------|
|Event ID| Description |
|3076 |Audit for exe/dll generated by CI in the createprocess stack|
|3077 |Enforced version |
|3089 |Signing information event correlated with either a 3076/3077 event, contains # of signatures and an index as to which signature it is, one 3089 is generated for each signature of a file (so many 3089 map to one 3076/77). Unsigned files will generate a single 3089 with TotalSignatureCount 0 |
|8028 |Audit for scripts/msis generated by WLDP being called by the scripthosts themselves (scripthosts opt in to enforcement, so we don’t enforce on 3rd party scripthosts like python/ruby)|
|8029 |Enforce for scripts|
We don’t currently have signer information in the script events
• I don’t understand what the “Policy” fields are.
Code Integrity Policy is at its core an enterprise whitelisting solution. For these events to be generated, customers would have had to generate a policy xml, compile it, and deploy it. PolicyName/PolicyID fields are optional fields customers can add to the policy to get propagated into the events, policy hash is literally the hash of the policy (and policy hash matching guarantees that two events were blocked by the same policy). Since you can have multiple concurrent policies on one system supplementing each other, knowing what policy actually blocked the binary from running is useful
**Q:** I don’t understand what the “Policy” fields are.
**A:** Code Integrity Policy is at its core an enterprise whitelisting solution. For these events to be generated, customers would have had to generate a policy xml, compile it, and deploy it. PolicyName/PolicyID fields are optional fields customers can add to the policy to get propagated into the events, policy hash is literally the hash of the policy (and policy hash matching guarantees that two events were blocked by the same policy). Since you can have multiple concurrent policies on one system supplementing each other, knowing what policy actually blocked the binary from running is useful
• Is this purely file based or do I need to worry about the “PackageName” grouping?
o Eg… do I need the packagename to get back to a publisher or are individual files from the package all mapped up directly?
An event is generated for each individual binary that failed policy. The PackageFamilyName is put in the process token of all binaries loading under an appx and is can be used in rules in policy to attempt to allow an entire package to run rather than whitelisting each individual binary, but we will still generate an individual event for each binary that fails
I can’t currently remember if the PackageFamilyName field is even calculated or just zeroed out if there aren’t PFN rules in a policy
**Q:** Is this purely file based or do I need to worry about the “PackageName” grouping? For example, do I need the packagename to get back to a publisher or are individual files from the package all mapped up directly?
**A:** An event is generated for each individual binary that failed policy. The PackageFamilyName is put in the process token of all binaries loading under an appx and is can be used in rules in policy to attempt to allow an entire package to run rather than whitelisting each individual binary, but we will still generate an individual event for each binary that fails.
• What field in 3089 am I able to join on to map from File to Publisher?
CorrelationID is actually not in the event templates I sent you and is actually an optional field in the metadata of every eventviewer event. In the XML of the event the correlationID’s path is:
**Q:** What field in 3089 am I able to join on to map from File to Publisher?
**A:** CorrelationID is actually not in the event templates I sent you and is actually an optional field in the metadata of every eventviewer event. In the XML of the event the correlationID’s path is:
```xml
<Event><System><Correlation ActivityID=”{GUID}” />
```
For comparison, the rest of the fields look like:
```xml
<Event><EventData><Data Name=”FileNameLength”>value</Data><Data Name=”FileName”>value2</Data>…
```
• 3076/77 don’t seem to include ‘File Path’. Can this be deduced from ‘File Name’?
• 8028/8029 don’t seem to include ‘File Name’. Can this be deduced from ‘File Path’?
“File Name” in 3076/77 is actually the path in NT form (\Device\HarddiskVolume3\Windows\System32\myfile.dll), and the “originalfilename” field maps to what would be “File Name” in a file rule in policy XML
For 8028/8029 File Path is the C:\ path to the file and you’ll notice a trend where we didn’t bother to include all the same fields we do for the PE files so there is no “originalFileName”
**Q:** 3076/77 don’t seem to include ‘File Path’. Can this be deduced from ‘File Name’? 8028/8029 don’t seem to include ‘File Name’. Can this be deduced from ‘File Path’?
**A:** “File Name” in 3076/77 is actually the path in NT form (\Device\HarddiskVolume3\Windows\System32\myfile.dll), and the “originalfilename” field maps to what would be “File Name” in a file rule in policy XML.
For 8028/8029, File Path is the C:\ path to the file and you’ll notice a trend where we didn’t bother to include all the same fields we do for the PE files so there is no “originalFileName”.