Setting an individual Attack Surface Reduction (ASR) rule in Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

The next recommended setting to implement is Attack Surface Reduction (ASR) rules. I’ve detailed how you can set this on individual devices using PowerShell here:

Show ASR settings for device with PowerShell

I’ve also detailed how to do this with Intune previously:

Attack surface reduction for Windows 10

In a nutshell, ASR is going to prevent child processes from launching, which is typically how a malware infection starts.

To create a stand alone ASR rule navigate to Endpoint security, Attack surface reduction in the Intune portal and select Create policy, as shown above.

Select the platform as Windows 10, Windows 11 and Windows Server and the profile as Attack Surface Reduction Rules.

Then Create the policy

As always, give the policy a meaningful name.

You should then see a list of the 16 standard ASR rule types as well as a rule called Block Webshell creation for Severs.

The best practice is to set all of these to Block. However, you will also see options for Audit and Warn if you want to take a more cautious approach.

The good thing about an individual ASR policy like this is that you get a lot more options that can be configured, unlike other policies in Intune that also include ASR. An example if the above, where you can provide enter a directory or file which will prevent ASR rules from matching. As an example, a path might be defined as: C:\Windows to exclude all files in this directory. A fully qualified resource name might be defined as: C:\Windows\App.exe.

Best practice is not to have any exclusions.

A little further down you’ll see a setting for Enable Controlled Folder Access as shown above. The controlled folder access feature removes modify and delete permissions from untrusted applications to certain folders such as My Documents.

Best Practice is to set this to Enabled.

Under this you can set Controlled Folder Access Protected Folders and Controlled Folder Access Allowed Applications. Controlled Folder Access Protected Folder allows adding user-specified folder locations to the controlled folder access feature. These folders will complement the system defined folders such as My Documents and My Pictures. The Controlled Folder Access Allowed Applications allows user-specified applications to the controlled folder access feature. Adding an allowed application means the controlled folder access feature will allow the application to modify or delete content in certain folders such as My Documents. In most cases it will not be necessary to add entries. Windows Defender Antivirus will automatically detect and dynamically add applications that are friendly.

Best practice is to not have any settings here and to have these both set to Not configured.

When you configure an individual rule you’ll also see the ability to set exceptions for just this rule. As an example, a path might be defined as: c:\Windows to exclude all files in this directory. A fully qualified resource name might be defined as: C:\Windows\App.exe.

Once you have determined your settings you then apply the policy to an audience in your environment. You can use multiple policies if needed for different audiences.

If you want to monitor ASR actions in your environment you can use the following KQL query:

DeviceEvents
| where ActionType startswith ‘Asr’

This going to help you identify which devices and processes ASR is impacting, making troubleshooting much easier.

If you want to read more about ASR then visit:

Understand and use attack surface reduction capabilities

I believe ASR is something that should be enabled fully on all Windows devices, withou any exceptions or exclusions. It is an ability included with Windows for free and just needs to be enabled, either by policy or PowerShell. I would recommend setting an individual ASR policy as I have shown above as it provides the greatest flexibility when configuring as well as the greatest number of exclusions if required. Many other Intune policies include the ability to configure ASR but if you have a stand alone policy you should not configure it elsewhere or you may end up with configuration clashes and errors.

The next recommended policy will be for Defender for Endpoint.

Setting an Edge Security Baseline with Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

The next step in the process is to assign a security baseline to the Microsoft Edge environment. Security baseline policies differ from all other policies in Intune because they already have best practice settings enabled. This compares to other Intune policies where you need to go into each policy item and set them to the desired setting. Another benefit of using Security baselines is that they are easily upgradable when updated policies become available. These two factors save a lot of time and effort securing your environment.

In the Intune console, navigate to Endpoint security | Security baselines and select Security Baseline for Microsoft Edge as shown.

Select the option to Create profile and then give the profile a meaningful name.

You’ll then see a list of the individual settings with values already selected.

You can adjust any of the individual settings if you need to customise the policy. Generally, I find there is no need to make any changes here as I have found no conflicts.

Here we also find an example of one of the challenging things with implementing any policy, duplicate settings. If you remember back to the previous article on

Managing browser extensions in Edge with Intune

you’ll note that extension restrictions was configured there, but now it is also in this Security baseline policy. A best practice recommendation is to only have one place in your policies where a setting is made. This will avoid conflicts and aid troubleshooting. If you do choose to retain the same settings in multiple policies, ensure they are set identically or otherwise you will get conflicts. In this case I’ll leave the setting in place for both policies as they are the same and it is bit challenging to disable just this option in the original ‘Edge configuration’ policy created in the previous post.

With any changes made, continue with the Security baseline policy configuration and assign it to your environment.

When complete you should see the policy you just created, as shown above. Remember, you can create as many policies as you need to accommodate your environment targeted to different audiences, however the aim should be to get to a single Security baseline policy for Edge to keep things simple.

You’ll see that the policy created has a version number. You’ll also note a Change version button on the menu at the top (currently greyed out) as shown above. This is the beauty of a Security baseline policy, when an update is available you’ll be able to use this option to update the policy. You can read more about this here:

Update a profile to the latest version

We are now at a point in our roll out where we have policies to provide a secure Microsoft Edge configuration in our environment. Those already using Microsoft Edge will benefit immediately, users on other browsers still need to ‘encouraged’ to make the shift as soon as possible, but are still not being forced to use Microsoft Edge just yet (they will be eventually, so keep encouraging them to make the shift with your communications because they day when they have no other option but to switch is coming!).

for more information about the:

Microsoft Edge security baseline settings reference for Microsoft Intune

visit the above link and remember the benefit of Security baselines is that they have best practice settings already enabled, so typically all that is needed to apply the policy with these default settings .

It is now time to look at securing the Windows devices against ransomware. Stay tuned.

Controlling local user group membership with Intune

I recently outlined how to

Control local admin on a device with LAPS and Intune

Once you have LAPS in place I suggested that you want to eliminate any local device administrators as a best practice. You can achieve this via a policy in Intune.

The first step in the process is going to be to determine any local administrator accounts and what they are doing in your environment. A good starting point is this KQL query to look for local admin activity in your device fleet:

DeviceLogonEvents
| where TimeGenerated >= ago(7d)
| where IsLocalAdmin == true
| summarize count() by DeviceName, AccountName,LogonType
| sort by AccountName

That will, of course, only show you logon activity by an account that is a local administrator. For dormant local admin accounts you are going to need to do more work to flush them out. However, the query will at least show you active local admin accounts that maybe impacted by any changes made using something like LAPS.

To set a policy to control local groups on Windows devices, login to the Intune management portal and select Endpoint security and Account protection, as shown above. Create a new policy for Windows 10 and later and select Local user group membership as the Profile.

Give your policy a meaningful name and continue.

Select the local group (here Administrators), select the action (here Remove) and Manual for the User selection type.

When you select the Add users hyperlink in the Selected users/groups field you will see the above blade appear. In here, you’ll find a number of different methods of identifying users. If you have a list of local device admins then you can add them here.

Once you have entered all the users you wish to remove from the local device administrators group, complete the policy and assign it to the audience you wish.

The policy will then roll out to your environment and the changes will be made to the local group membership. In this case, it will remove local users from the local device administrator group so they can no longer administrate the device.

Remember, there are lots of options here. You could different policies for different users and/or devices. You could create policies to not only remove but also add. An example maybe where you wish an Entra ID user to be a local administrator of box. In that case, simply select the option to Add the user from Entra ID to the local administrators group. There is a lot of flexibility here with this policy.

Typically, once your policy has completed and there are no more local administrators you can remove the policy, as hopefully no more local accounts will be created with devices being joined directly to Entra ID. However, you may wish to retain it for if new devices are joined to your environment, especially if you don’t use Autopilot.

In summary then, the process so far, is:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

Typically, these steps will have no impact on users working with their devices and it commences the process of implementing a consistent environment and making it more secure.

You can read more about this particular policy here:

Manage local groups on Windows devices

Run on demand PowerShell scripts from Intune

Microsoft Intune now has the ability to run ‘on demand’ PowerShell scripts on devices. My video above takes you through the basics of uploading your scripts to Intune and then executing them on a device.

The direct video URL is:

https://www.youtube.com/watch?v=9YKN5dq1HxA

Basic Windows Application Control using Intune policies

Application control is a great way to make your Windows devices more secure. However, it can be challenging to create and roll out policies. The good news is that you can apply Application Control using Intune policies. I made this video:

https://www.youtube.com/watch?v=gh0wRZGjnd4

in which I run through the whole process from end to end. I also cover off some of the challenges using this approach as well as some handy troubleshoot tips, especially how to successfully remove the Application Control settings if needed.

Follow along for an easy way to deploy Application Control across your Windows devices using Intune.

An overview of Winget

I thought I’d break out the session I did on Winget from my last podcast as an easier direct reference to the technology I think people should be paying attention to in Windows to manage applications.

The direct link to the session is here:

https://www.youtube.com/watch?v=2nDpgoOIS6s

Need to Know podcast–Episode 301

News and updates from the Microsoft Cloud and then a deep dive into Compliance policies in Intune. Have a listen and let me know what you think.

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-301-compliance-policies/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send me any feedback or suggestions you may have for the show

This episode was recorded using Microsoft Teams and produced with Camtasia 2023.

Brought to you by www.ciaopspatron.com

Resources

@directorcia

@directorcia@twit.social

Join my shared channel

CIAOPS merch store

Become a CIAOPS Patron

CIAOPS Blog

YouTube edition of this podcast

Windows 365 Frontline available in public preview

OneNote: Your Digital Notebook, Reimagined with Copilot

Quick Wins to Strengthen Your Azure AD Security

Automating and Streamlining Vulnerability Management for Your Clients

Phone Link for iOS is now rolling out to all Windows 11 customers

Introducing cloud.microsoft: a unified domain for Microsoft 365 apps and service

Centrally manage multiple Microsoft Sentinel workspaces with workspace manager

Announcing Windows LAPS management through Microsoft Intune

Practice Assessments for Microsoft Certifications

Profanity filtering control for live captions in Teams meetings

Getting Endpoint Privilege Management rule policies working

In a recent article:

Getting Endpoint Privilege Management working

I detailed how to get the basics of Endpoint Privilege Management working using settings policies.

The next step in the process is to get the rules policies working in conjunction with this. The scenario will be that we want to only allow a single application to be run with elevated privileges on a device. Here, that application will be Adobe Acrobat installer.

As before, we’ll need to go back into https://intune.microsoft.com under the Endpoint Security menu option as shown above.

We’ll firstly need to edit the original Settings policy from the previous article and change the Default elevation response to Deny all requests as shown above. This will block any request to elevate by default.

Next, we’ll need to create a new policy with the Profile set to Elevation rules policy as shown above.

As always, we need to give this new policy a name.

On the following screen select Edit instance on the right as shown above.

On the blade that appears from the right, you’ll need to give the Rule a name and then a description if you wish.

For the Elevate type I have selected User confirmed rather than automatic as well as requiring Validation to be a Business justification as shown.

Next is the actual file name for the Acrobat Reader installer which is acrordr2300120064_en_US.exe in the File name field.

To get the file hash I used the PowerShell command get-filehash as shown above.

The remaining details were obtained from the properties of the file, as shown above.

I then saved this Rule and completed the creation of the policy using the standard process, ensuring I applied it to teh appropriate group in my environment.

Once again, you need to wait until the policies have been pushed out to all devices.

With the policies deployed, if I now right mouse click on the Acrobat Reader installation file and select Run with elevated privileges I see,

that the configured app is identified in the dialog and I need to provide a business justification for the installation as was configured in the rules policy.

Once that has been completed the application installs as normal.

The Adobe Reader application runs on the device once the installation is completed as shown above.

If I try and install another application by using the run with elevated privileges option (here, on the file officesetup.exe), it is blocked as shown above because the default setting policy is deny all. To allow this, another rule for that specific file would need to be created in the policy.

This means that you can now create a default Privilege Management settings policy to deny all requests to elevate and then have specific rules to only allow pre-defined applications to be run as administrator on the device. Remember, all this can be done without needing to have a local administrator on the device.