In our last article a few weeks ago, we covered some core concepts around Windows 11 Security.

Check out our previous articles:

• Onboarding Best Practices
• Security Best Practices
• User Experience Best Practices

This week, we are going to get a bit more in depth by discussing some of the more complex technologies around security:

• Endpoint Privilege Management (EPM)
• App Control
• App Patch Management
• Device Control

These are areas that are not particularly simple, but with a strong approach we can do some great things. The key is to remember to not be too heavy handed because it can be an adventure in security. Let’s get started with EPM.

Microsoft Intune Endpoint Privilege Management

Not too long ago, Microsoft released the Microsoft Intune Suite with several capabilities. One of those that basically every MVP has been doing some work on is EPM. I want to preface by saying that I won’t be teaching you how to configure it (that will be covered in a separate article soon).

EPM enables your users to complete specific tasks that require elevated rights, like app installs, updating device drivers, and running certain Windows tools. We couple this with LAPS to help achieve the Zero Trust journey for an organization. Let’s discuss requirements.

Requirements:

• Windows 10/11 (21H2+)
• Intune Suite license or standalone EPM license
• Entra joined or Hybrid joined
• Enrolled in Intune or ConfigMgr
• Connectivity to the EPM endpoints (DO NOT SSL INSPECT!)
  • *.dm.microsoft.com – The cloud service endpoints used for enrollment, check-in, and reporting, and which can change as the service scales
  • *.events.data.microsoft.com – Used by Intune-managed devices to send reporting data to Intune

The beauty of EPM is that it all runs inside of Intune. Overall, it has some nice simplicity. It’s a 3-step process overall:

• License EPM
• Deploy elevation settings policies (this will activate EPM on the target device)
• Deploy elevation rule policies (links an app or task to an elevated action)

EPM has a few capabilities overall. We start with an “automatic elevation”, which seamlessly will let someone run an app as administrator:

User-confirmed elevations will let users run IT-trusted apps as admin after providing justifications like this below:

Most importantly, they provide nice reporting capabilities to give you an audit trail, which is vital to a successful Zero Trust strategy:

One thing to point out, they do not currently support elevating MSIs and PS1s at this point, but that is currently in development. I like to point that out considering how important those two use cases are for many companies. In general, I could go much deeper on EPM, but I am going to save that for my article on EPM.

Windows Defender Application Control (WDAC)

WDAC is one of the harder things to deploy in general. With that being said, WDAC is a gold standard in security. Let’s talk more about what WDAC is. One of the common misnomers is that with antivirus and anti-malware you’re good to go.

WDAC focuses on ensuring Windows processes (which has the same level of access as the user) are not deleting or transmitting crucial organizational information. WDAC mitigates these threats by restricting the apps users can run and the code that runs in the kernel. WDAC policies will also block unsigned scripts and MSIs along with restricting PowerShell to run in Constrained Language Mode.

Constrained Language Mode blocks access to PowerShell, .Net, or COM APIs that could be potentially abused by a malicious actor. Scripts and script-based modules in the session will run in that mode. Any scripts or modules allowed by the policy will run in FullLanguage mode (permits all language elements in the session).

Overall, WDAC is an enhancement over your AV/EDR solutions as it moves away from a standard application trust model to a true Zero Trust capability. Two things often used for these use cases are WDAC, which we are discussing today and AppLocker (which we are not going to cover as it’s no longer being developed).

WDAC Lifecycle Policy Management

When we look at using WDAC, we think about how policies will be managed. This graphic below shows the best practice for managing policies. The steps are:

1. Defining the intent of the policy, which is description in human words of what it’s supposed to do. It’s commonly known as the “circle of trust.” You can find the default Windows Policy at “%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml” which lets Windows, 3rd-party hardware and software kernel drivers, and apps from the Microsoft Store.
2. Deploy a policy in audit mode to your targeted devices.
3. Monitor the policy for audit block events so you can refine and tweak the policy.
4. Iterate through steps 2-3 until you are getting your desired result.
5. Build your enforced version of the policy.
6. Deploy the enforced version of the policy.
7. Rinse and repeat when your circle or trust changes.

The most important aspect of your lifecycle is to manage your production policies in something like SharePoint or GitHub that has version control and tracks changes. You can also leverage Set-CIPolicyIDInfo to set policy descriptions and IDs to help organize things.

As it’s Lifecyle Management, you will likely need frequent policy rule updates, so you should be monitoring/testing regularly. You can access the events in Event Viewer at CodeIntegrity\Operational. Shipping Event Logs to centralized solution will help keep your policy up-to-date and avoid user disruption (which is one of the hardest things about WDAC).

Policy Considerations in WDAC

Every step of the way in WDAC is about mindfulness. You have to consider every decision and the potential ripple effects of them. From 1903+, you can now create multiple simultaneous policies, which provides more flexibility. We discussed the “circle of trust” in the previous section. So, the question is how do you move beyond that policy? Design considerations come into play. Some of the questions we ask ourselves are:

• How are apps managed and deployed?
• Are we signing apps?
• Do some groups need custom policies?
• Do you have limited administrator resources?

How are Apps Managed and Deployed in your Organization?

If you have a strong app management strategy, you can create stronger policies. This basic table should help:

Are Internal Apps and Apps Developed by 3rd Parties Signed?

Unsigned apps can be a major security risk with rampant malicious/tampered code. Your device posture and integrity really improve by adopting a code-signing strategy. Let’s look at a few examples:

Do Some Groups Need Customized App Control Policies?

In many companies, certain areas have unique requirements. You may need to consider if you need team-specific policies in addition to your org policies. WDAC policies can be unique to the team or team-specific supplemental policies can be created on top of your “circle of trust.” If you don’t need custom policies, you can use a single global WDAC policy. Sometimes a global policy can spiral out of control quickly.

Are IT department resources an issue?

Your ability to manage WDAC is a major problem. It’s relatively simple. If you have the resources, you can invest the time to analyze your org’s requirements and plan a complete deployment that leverages possible rules. If resources are an issue, keep it super simple and don’t make it unmanageable. Things need to be scalable.

In addition, the help desk can run into significant issues if you create a policy that is too complex. Exceptions and policy changes create a ton of work. You will want to make sure you have processes and documentation in place to make sure you can be successful.

WDAC Policies and Rules

The last thing I want to cover on WDAC as it’s getting long are the different policy options. Let’s cover the items configurable via policy. We have a few options:

WDAC Policy Rule Options:

Another aspect is the file rule level that you want to trust an application. You can trust files at:

• Hash (the has value of the binary)
• FileName
• FilePath (only applies to user mode binaries)
• SignedVersion (enforces at the version number level)
• Publisher (combines the PcaCertificate level (usually one level below root and the CN of the certificate)
• FilePublisher (combines the FileName and Publisher file rule levels, a note that this is my preferred option)
• LeafCertificate (adds trusted signers of the certificate)
• PcaCertificate (adds the highest cert available in the chain to signers)
• WHQL (only trusts binaries submitted to MSFT and signed by the Windows Hardware Qualification Lab)
• WHQLPublisher (combines WHQL and Publisher)
• WHQLFilePublisher (combines WHQL and FilePublisher)

The nice thing when you use FileName, FilePublisher, or WHQLFilePublisher is you can leverage “-SpecificFileNameLevel” to create easier rules leveraging:

• File Description (the description provided by the developer of the library)
• InternalName (the internal name of the library)
• OriginalFileName (specify the name of the file when it was first created)
• PackageFamilyName (specify the package family name of the binary e.g. the name of the file and the publisher ID).
• ProductName (name of the product that the binary ships with)
• Filepath

You can even use wildcards like these examples to make life even easier:

##This typical pattern of wildcards should be familiar to many##
C:\Windows\*
D:\EnterpriseApps\MyApp\*
%OSDRIVE%\Windows\*
##Wildcards used in the middle of the path allow all files that match the pattern##
C:\*\CCMCACHE\*\7z????-x64.exe
%OSDRIVE%\*\CCMCACHE\*\7z????-x64.exe

There is a ton more complexity inside of WDAC, but overall, this should give you a good idea to get started. Check out the video below for getting started on setting up WDAC inside of Microsoft Intune

Windows Application Patch Management

As I featured in my article awhile back,

You can leverage the new Enterprise App Catalog in Intune for managing your Windows Apps and their automated patching if it’s part of their catalog. This on the backend is powered by Liquit and the hope is they will continue to grow the catalog. They have around 100 apps today, but I expect that number to keep on climbing.

All of the apps that come down are either EXE or MSI depending on the application. A few other notes:

• Graph API support is coming soon
• They support licensed apps
• Only supported by Intune (no SCCM support)
• Leverages the Intune Management Extension (Not WinGET)
• Delivers automatic app upgrades
• No current SLA

We also have other options we can look into for developing this strategy. A newer solution on the scene now is ControlUp’s new flavor of DEX called “Secure DX”, which I wrote about a few months ago.

ControlUp Secure DX is a new module with ControlUp Edge DX to help identify and address security issues on your devices. It focuses on items that are misconfigured, compliance issues, application patching, and security vulnerabilities.

You create a policy called a “template” to tell Secure DX what behaviors to look for and what items to automatically remediate. You will also see Secure DX calculate secure scores for devices based on the number of issues that currently exist.

You can leverage Secure DX to automatically the apps that are supported in their catalog:

The 3rd option, which is one of the most popular ones is leveraging PatchMyPC. PatchMyPC directly integrates with Microsoft Intune to simplify the deployment of new applications and automatically updates existing ones that are being managed by PatchMyPC.

PatchMyPC is a nice platform that is very user friendly and easy to use. Admins can get themselves up and running very quickly while making their patching lives significantly easier.

The overall sentiment is however you achieve it, it’s important to deliver an application delivery and patching strategy that can shift right on updating applications otherwise it becomes whack-a-mole and is just not attainable over the long run.

Device Control in Microsoft Defender for Endpoint (MDE)

Device control is the final part of our security discussion. Device control lets you control how users can install and use peripheral devices. Examples are USB thumb drives, disks, printers, Bluetooth, etc. You can build device control policies to do things like:

• Block external hard drives
• Only allow BitLocker-encrypted devices

By extending the basics of device control to MDE you get some advanced capabilities like:

• Granular access control policies to control access by device type, operation, group, and more
• Store file info and contents to audit files copied or accessed on devices
• Reporting and advanced hunting capabilities

In addition, you can do a few other things like preventing specific types of USB drives, and Endpoint DLP solutions. We will finish things up by showing you how to configure a few basic settings for device control inside of Microsoft Intune.

Final Thoughts

We have now come to the end of our security best practices for Windows 11. The overall sentiment is that you should only implement the capabilities that make sense for your organization. People tend to overthink “some” aspects of security at the OS level. Like with WDAC, if you don’t have the team to manage it full-time, keep it simple and manageable.

Security the entire landscape of your organization is important, but it’s irrelevant if you turn it into a lose-lose situation. We must continue to refine that strategy, but it’s only a valid strategy if you can build it and keep it in sync with your organizational security requirements.