{"id":15686,"date":"2019-07-01T09:00:38","date_gmt":"2019-07-01T17:00:38","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2019\/07\/01\/news-9434\/"},"modified":"2019-07-01T09:00:38","modified_gmt":"2019-07-01T17:00:38","slug":"news-9434","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2019\/07\/01\/news-9434\/","title":{"rendered":"Delivering major enhancements in Windows Defender Application Control with the Windows 10 May 2019 Update"},"content":{"rendered":"

Credit to Author: Eric Avena| Date: Mon, 01 Jul 2019 16:25:25 +0000<\/strong><\/p>\n

With the Windows 10 May 2019 Update we delivered several important features for Windows Defender Application Control<\/a> (WDAC), which was originally introduced to Windows as part of a scenario called Device Guard. WDAC works in conjunction with features like Windows Defender Application Guard<\/a>, which provides hardware-based isolation of Microsoft Edge for enterprise-defined untrusted sites, to strengthen the security posture of Windows 10 systems.<\/p>\n

Our focus for this release was responding to some longstanding feedback on manageability improvements. We\u2019re excited to introduce the following new capabilities in Windows Defender Application Control:<\/p>\n

    \n
  1. File path rules, including optional runtime admin protection checks<\/li>\n
  2. Multiple policy file support with composability<\/li>\n
  3. Application Control CSP to provide a new, richer MDM policy management capability<\/li>\n
  4. COM object registration support in policy<\/li>\n
  5. Disabling script enforcement rule option<\/li>\n<\/ol>\n

    Application control is frequently identified as one of the most effective mitigations against modern security threats, because anything that\u2019s not allowed by policy is blocked from running. Even striving towards a simple policy like mandating that only signed code is allowed to execute can be incredibly impactful: in a recent analysis of Windows Defender ATP data, we saw that 96% of malware encountered is unsigned. Systems like Windows 10 in S mode, which uses WDAC technology to enforce that all code must be signed by Windows and Microsoft Store code signing certificates, have no malware infection issues.<\/p>\n

    The new capabilities are designed to ease the journey for customers adopting application control in real-world environments with large numbers of applications, users, and devices.<\/p>\n

    File path rules, including optional runtime admin protection checks<\/h3>\n

    For many customers looking to adopt application execution control while balancing IT overhead, rules based on file paths on managed client systems provide a useful model. The Windows 10 May 2019 Update introduces support for both allow and deny rules based on file path in Windows Defender Application Control.<\/p>\n

    File path rules had been one of the few features available in AppLocker<\/a>, the older native application control technology, that were not available to WDAC; deployment tools and methodologies built on top of AppLocker like AaronLocker<\/a> have relied on these rules as an important simplifying option for policy management. As we sought to close that gap, we wanted to preserve the stronger security posture available with WDAC that customers have come to expect. To this end, WDAC applies, by default, an option to check at runtime that apps and executables allowed based on file path rules must come from a file path that\u2019s only writable by administrator or higher privileged accounts. This runtime check provides an additional safeguard for file path rules that are otherwise inherently weaker than other identifiers like hash or signer rules, which rely on cryptographically verifiable attributes.<\/p>\n

    This runtime capability can be controlled with the \u201cDisabled:Runtime FilePath Rule Protection\u201d rule option.<\/p>\n

    The following example shows how to easily create rules for anything allowed under \u201cProgram Files\u201d and \u201cProgram Files (x86)\u201d, and then merge them with the sample policy that allows all Windows signed code (available under C:WindowsschemasCodeIntegrityExamplePolicies<\/em>). The resulting merged policy file allows all Windows signed code and applications installed under \u201cProgram Files\u201d and \u201cProgram Files (x86)\u201d with the runtime protection that checks that anything executing under those paths is coming from a location only writable by administrator or higher privileged accounts.<\/p>\n

    \"Sample<\/p>\n

    Multiple policy file support with composability<\/h3>\n

    Limiting support to a single policy file means that a variety of app control scenarios from potentially different stakeholders or business groups need to be maintained in one place. This comes with an associated overhead: the coordination required to converge on the appropriate rules encapsulated in a single policy file.<\/p>\n

    With the Windows 10 May 2019 Update multiple policy files are supported for WDAC. To facilitate composing behavior from multiple policy files, we have introduced the concept of base and supplemental policies:<\/p>\n