deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-19 04:13:41 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Update windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md

Browse Source 
Co-authored-by: Jordan Geurten <jjgeurte@edu.uwaterloo.ca>
This commit is contained in:
jsuther1974
2023-03-02 09:43:19 -08:00
committed by GitHub
parent 7a127ee5df
commit 272a4eb85a
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md
View File

@ -35,7 +35,7 @@ This article for IT professionals describes concepts and lists procedures to hel
The biggest challenge in adopting application control is the lack of a strong app identity for classic Windows apps, also known as win32 apps. A typical win32 app consists of multiple components, including the installer that is used to install the app, and one or more exes, dlls, or scripts. An app can consist of hundreds or even thousands of individual binaries that work together to deliver the functionality that your users understand as the app. Some of that code may be signed by the software publisher, some may be signed by other companies, and some of it may not be signed at all. Much of the code may be written to disk by a common set of installers, but some may already be installed and some downloaded on demand. Some of the binaries have common resource header metadata, such as product name and product version, but other files won't share that information. So while you want to be able to express rules like "allow app Foo", that isn't something Windows inherently understands for classic Windows apps. Instead, you may have to create many WDAC rules to allow all the files that comprise the app. The biggest challenge in adopting application control is the lack of a strong app identity for classic Windows apps, also known as win32 apps. A typical win32 app consists of multiple components, including the installer that is used to install the app, and one or more exes, dlls, or scripts. An app can consist of hundreds or even thousands of individual binaries that work together to deliver the functionality that your users understand as the app. Some of that code may be signed by the software publisher, some may be signed by other companies, and some of it may not be signed at all. Much of the code may be written to disk by a common set of installers, but some may already be installed and some downloaded on demand. Some of the binaries have common resource header metadata, such as product name and product version, but other files won't share that information. So while you want to be able to express rules like "allow app Foo", that isn't something Windows inherently understands for classic Windows apps. Instead, you may have to create many WDAC rules to allow all the files that comprise the app.
Packaged apps on the other hand, also known as [MSIX](/windows/msix/overview), ensure that all the files that make up an app share the same identity and have a common signature. Therefore, With packaged apps, it's possible to control the entire app with a single WDAC rule. Packaged apps on the other hand, also known as [MSIX](/windows/msix/overview), ensure that all the files that make up an app share the same identity and have a common signature. Therefore, with packaged apps, it's possible to control the entire app with a single WDAC rule.
## Using WDAC to Manage Packaged Apps ## Using WDAC to Manage Packaged Apps