Last Updated on December 5, 2022 by rudyooms

I guess after all the blogs I have written about Endpoint Security, I need to go talk about PAW/SAW not to be mixed up with PAW patrol or the SAW movies.

Also, note… I am writing the second part of the TPM Happyness… and it will show you the not documented flow with the Intel Tiger Lake chipset

I will divide this blog into multiple parts

1. Background information about PAW
2. Compliance Policies and Conditional Access
3. Hardening your Workstation
4. Removing Local Admin Rights
5. Application Execution Control AKA Applocker
6. URLS restricted to an approved list
7. Microsoft Defender for Endpoint
8. What About the Office Apps?
9. What did we forgot?

1. Background Information about PAW

So what means PAW? PAW stands for Privileged Access Workstation. The PAW concept describes the requirement of IT Operators/Administrators to have a totally locked down workstation dedicated and only to be used for an administrative activity. The PAW level is the most restrictive one!

It’s a part of your Privileged Access strategy. With this strategy, you are making sure you are lowering the risks of an attack on your privileged users.

You will need to protect your sensitive users from attackers who want to compromise your devices!

So what are sensitive users? These users are your superusers, your it operators. They have all the power in the world. I guess the best way to describe it, is being Groot.. uhhh Root in Linux.

You really want to make sure your sensitive users/It operators can only login into the most secure device possible. Configuring a secured workstation is the way to go. There are 3 levels of security you can choose from.

Looking at the picture above, you will have noticed the “dollar signs” the higher you get the more defenses are in place and the more it will cost the attacker to breach your security. And it’s all about return on investment (ROI). When you become a difficult target to breach, the attacker must spend more time and money to achieve their objectives.

The security Model starts with the Enterprise Security level, which fits almost all Enterprise users. From there on, you can put up more Security fences and improve your level of security and reach the Specialized Security level for your normal users.

As mentioned earlier, you really want to have a totally locked-down device (PAW) for your IT operators. You really don’t want an IT operator logging into a nonsecured device and logging in to Azure as a global admin.

So how are we going to do this? I will try to guide you through the whole setup, step by step.

2. Compliance Policies and Conditional Access

The first thing we need to do to start securing your Tenant is configure your Conditional Access (CA) rules and create some nice compliance policies.

• 1. Compliance

First, let’s take a look at some compliance policies. I am combining Microsoft their PAW Compliance rules with mine. (Take A look at my Github page for these compliance policies)

Looking at the compliance policies above, you will have noticed the “Require Minimum ATP”

If you have Microsoft Defender for Endpoints configured (I truly recommend this!), you could also require the device to be under the machine risk score “Clear”. With this compliance policy, you can be very sure, your devices are not infected when accessing company data

But you must not forget the other compliance policies, because you want to make sure your devices are encrypted, have the latest OS version, have the latest AV update installed etc.

Also, this a kind reminder to please check if this setting is configured to “Not Compliant”

• 2. Conditional Access Rules

But by only configuring the compliance policies we are not going to save the world. We need something to check if your devices are compliant before they could access your org data. If they aren’t compliant, they may not enter.

I have created a blog about this process (and the next one about this topic is almost ready!)

If you want to deploy Conditional Access on the go with PowerShell there are 2 possible options. Like always I also wrote a blog about how to do this with some background information in it. (Please beware it does not contain the PAW ca policy)

So making sure your CA rules are in place and requiring your devices need to be compliant to access your data is of course good practice because attackers will always choose the path of the least resistance when trying to get in.

Please note !!! You need to Configure Conditional Access rules to make sure your It Operators need to login into their PAW device when they need to administer Intune/Azure. Let’s take a look at an example of how we could accomplish this

PAW Conditional Access Rule

1. Users And Groups

Let’s start by creating a new Conditional Access Rule and target the proper user role. It’s obvious I am selecting the “Global Administrator” role. Don’t forget to exclude those “Break Glass accounts”(but make sure you apply logging and notification to those!!!)

• Apps

In this section, we need to select which apps we need to target

In the example above I am targeting

Microsoft Intune PowerShell aka d1ddf0e4-d672-4dae-b554-9d5bdfd93547

Graph Explorer aka de8bc8b5-d9f9-48b1-a8ad-b748da725064

Microsoft Azure Management aka de8bc8b5-d9f9-48b1-a8ad-b748da725064

Please note: When targeting Microsoft Azure management you are also targeting these services

• Conditions

And now the most important part… we need to make sure we are excluding our already configured PAW devices. Because when we are excluding our PAW devices we are forced to use these devices when we need to manage our MS365 Tenant. We can do this by making use of the Filter for devices preview option and using it with a conditional access rule

So please make sure you have enabled the Filter for devices option!

• Access Controls

Of course, we need to make sure we configure this policy to Block Access

Also, make sure you are always and I mean always require a Compliant device and MFA for your normal end-users when they need to have access to your organization’s data.

3. Hardening your Workstation

When you made sure your CA rules and compliance policies are up and running, you still have some work to do. You still need to make sure your workstations are secured because they now become one of the important points of entry. The ATP compliance policy I mentioned earlier is one important one but we also need to take a look at what else Microsoft is recommending us to do.

So to resume, when you really want to harden your workstation you need to make sure you apply some device security controls to secure your device. Only applying 1 of them is not the best practice, you will need to make sure you have implemented them all.

But beware, as I told you many times… you need to make sure you doing your best to secure your devices, but still, make sure your users can do their job without having any issues. So sometimes we need to choose a happy medium for Enterprise/Specialized devices.

4. Removing Local Admin Rights

This element is the most important one (in my opinion)… Just like Sami Laiho is mentioning a lot… “When you are local admin, there is no security!”

Before we can make sure the end-users are never local admin we need to configure some requirements. We are going to start to make sure, only a selected group of users can join their device to Azure Ad.

Now we configured that group, let’s step it up a notch and block “personal owned” devices to be enrolled into Intune. When this policy is configured, only corporate-owned/autopilot devices may be joined to Intune and with this get their compliance status tested.

When using PAW, block all personally owned devices to be able to enroll!

Now, let’s make sure your users are not local admins when your device is enrolled with Autopilot. Configure the User Account Type to “standard” in your autopilot profile.

But is this enough to meet Microsoft’s Requirements? I am not sure if you ask me… That’s why I created (yet another) blog about this topic, to show you my ideas on how you could manage Local Admins

But still, sometimes you will need to keep a local admin on the device when you need to manage the local device. But keeping that password always the same is totally not the best practice. When you are using an on-premise environment you could LAPS to do so. It’s a shame there is still not an official Microsoft solution to deal with this issue, luckily you could make your own Laps solution

The LAPS: Reloaded / Revolutions – Call4Cloud and Intune Proactive Remediations

5. Application Execution Control AKA Applocker

Okay, great your users are no longer local admins, if we want to meet the Microsoft standards for a privileged workstation we need to deploy Application Execution Control. I was under the understanding that Microsoft was recommending MDAC to do this… but let’s go further and take a look at Applocker and make sure the rules are always enforced.

When you want to know how you could start deploying Applocker to your devices please read my blog about this.

While you are restricting application execution you are also making sure your users can’t install apps on their own that aren’t approved by the Company

At this point you will need to choose the happy medium… totally locking it down is sometimes very hard. So why not choose a solution to make sure your end-users on your secured device could still install an app? They could easily install approved apps by opening the Company Portal app and installing the approved app on their own

Of course, please make sure your PAW devices don’t have the full application list available as they really don’t need it when they only need to administer Intune or Azure. Maybe they only need to have permission to install VSCode?

6. URL restricted to approved list

This one is quite funny, when looking at their own baseline (Github page from 2020) they are deploying a Device Configuration policy to configure a Proxy server for everything except some URLs

It was a great idea at first sight, but a lot of Microsoft Portals weren’t working when using this policy. Of course, you could add them to this policy, so you can use them but why not use MCAS and Defender for Endpoints?

As I showed you some time ago, you could easily block all apps by unsanctioned them. SO why not do so for your whole company?

Intune App Protection Policies explained and how does encryption work? (call4cloud.nl)

7. Microsoft Defender for Endpoint

I guess this one everyone felt coming… When you want to have a totally secured device, you will need to have Microsoft Defender for Endpoint implemented. There is no other option!

When you have enabled Defender for Endpoints and enrolled all of your devices you are way more protected. With Defender, you could enable ASR like Device Control, ASR Rules, Exploit Protection, web Protection, and Application Control (MDAC). Of course, we don’t need to forget about Firewall Rules, Account Protection (Credential Guard), which can also be configured when using Microsoft Defender.

Please visit my blog with links to all of my other Endpoint Security blogs

https://call4cloud.nl/category/endpoint-security-series/

When you have read these blogs, you will know now how important it is to configure additional security methods to make sure your PAW devices are safe!

8. What about the Office Apps?

Of course, you need to make sure your Office apps are secured on your NOT PAW devices.

But what to do with the Office Apps on your PAW devices? Can you tell which apps are 99% of the time responsible for getting infected with malware or ransomware??? Outlook! So why would you want to have Outlook installed on the same device you are administering your whole Microsoft 365 Tenant with?

9. What did we forget?

I guess we are still not done because there is still much left that I didn’t address yet. Of course, your PAW device needs to use the Edge browser. Even while we configured an URL restriction list etc, deploying a baseline policy to secure Edge is done within a few seconds. So why not do so?

Securing Edge:

Enrollment/DU at main · Call4cloud/Enrollment (github.com)

With each step, we take we are closing the gaps in our defenses because just like Microsoft is telling us: Attacker is like water and will always find the path of least resistance

I guess we are configuring a lot to make sure your PAW devices are safe. Did you happen to read my blog about the forgotten fruits of securing your Windows 10 endpoints?

It’s mentioning a lot of stuff, but the most important thing I want to point out is the Baseline PowerShell policy to make sure some stuff is configured like you wanted it to be. When you are an IT operator, you will need to have access to PowerShell but do they need PowerShell 2.0?

In the PowerShell script I showed you in the Forgotten Fruits blog I am enabling some PowerShell monitoring and I am making sure PowerShell 2.0 is removed

To finish it off we don’t need to forget we always need to make sure our Devices and Apps are being kept up to date with the latest security updates. Don’t forget to configure WU4B and choose a proper third-party apps deployment tool like Winget or chocolatey to keep your apps up to date

Conclusion

When you want to deploy PAW for your IT admins and they are normally working on a specialized level device please don’t install hyper-v and run a PAW VM on it. Because it is the same device on which you are normally working and the host device could always comprise the VM!

A better solution would be to get yourself a nice Azure Virtual Desktop and make sure that the device becomes your PAW. So let’s begin the game and get yourself a PAW