Intune Security Policies – Which to apply where?

by

One question I’m often asked is around security policies within Intune, where to set them and why can they be set in so many different places?

Before I start on what I prefer, there is no right or wrong answer for this one, ultimately they are all changing the same files/registry keys so it is personal preference. I would also suggest watching the excellent AMA from Microsoft on the subject here

So, what are the options:

  1. Standard policies within Device Configuration (device restrictions, settings catalog etc.)
  2. Security Baselines
  3. Setting policies within their individual security blades

The one thing to note is DO NOT set the same setting in two different policies or they’ll conflict on both policies, even if the setting value is the same.

Let’s look at the Pros and Cons of each one:

Standard Policies

The traditional way of managing settings within Intune, simply hop into Devices – Device Configuration and create a policy. For security settings this will be a mix of a Settings Catalog, Device Restrictions and possibly some Administrative Template based settings if you’re still working with Internet Explorer (for example)

These are what we are all used to and with the recent updates we even get the nice Settings Catalog style view on all of the policies with an overview of how they are working:

It looks nice and works nicely, but does have a couple of drawbacks:

Firstly, if you want to delegate access to your Security team, you’re going to need to start playing with Scope tags (have a read here if you’re not familiar), or give them read-only to everything.

Secondly, they aren’t centrally updated like the Baselines (more to follow)

Thirdly, you don’t have buttons to fix any issues with AV signatures etc. (again, more to follow)

If these don’t bother you and you want to stick to one page for all policies, setting them here is perfectly acceptable.

You will also find yourself using these to fill the gaps which security profiles don’t cover natively.

Security Baselines

Introduced back in 2020, Security Baselines are:

Security baselines are groups of pre-configured Windows settings that help you apply and enforce granular security settings that are recommended by the relevant security teams. You can also customize each baseline you deploy to enforce only those settings and values you require. When you create a security baseline profile in Intune, you're creating a template that consists of multiple device configuration profiles.

Accessible via the Endpoint Security Menu, Windows Security Baselines gives a long list of settings which you can simply switch on or off (and it is a long list)

The one key advantage of these is that Microsoft update them centrally with new settings and to apply the new settings it is as simple as changing the version:

It’s worth noting that when a new version is released, any current policies will switch into Read-Only mode until the version has been updated. They will continue to apply to devices, but you can’t change them.

If you are starting out on your Intune journey, these are an excellent starting point and even now I use a custom baseline to catch some settings not picked up elsewhere.

The drawbacks to a baseline:

  1. It hasn’t received the updated overview yet
  2. There are a LOT of settings, if you get conflicts or errors, make use of the Arrange by buttons on the columns
  3. You can’t remediate issues within the Baseline policies
  4. If a setting has options of Configured or Not Configured, changing a setting which was previously Configured to Not Configured will NOT revert on the devices. It simply stops sending any commands for that setting. If you apply a setting and it causes issues, the only way to revert is to start digging in the registry (or rebuild)
  5. You are at the mercy of Microsoft, as we found when recent updates broke non-English language machines

Security Blade Policies

A relatively new feature within Intune are the specific security policies within the Endpoint Security blade which contains the usual suspects as well as a few newer options:

One of the key advantages here is that you can delegate permissions to this section only via either the Endpoint Security Manager role, or a custom role with access to Security Baselines and Security Tasks which will please a security team, but without having to give them full access to everything.

Some of these newer options include:

Setting local admins on devices by Group:

And blocking devices/device services:

What I like about these is the overview screen where you can quickly spot any issues and remediation actions

You then have options to remediate the issue:

These policies don’t cover all settings though, they are my preferred method of deploying, but I tend to mix and match with Configuration Policies as well.

If you want a copy of my baseline, it is on Github or if you just want to get up and running quickly, check out my deployment tool here

As mentioned at the start, there is no right or wrong way to apply these policies, but hopefully this will help in the decision making.

27 thoughts on “Intune Security Policies – Which to apply where?”

  1. Hi Andrew.

    That looks super helpful (and by the way thanks for pointing to Intune Manager), but whenever I try to import file from the latest link from the comments (https://github.com/andrew-s-taylor/public/blob/main/IntuneConfig/Windows%2010%20Security%20Baseline.json) I’m getting error below. I use the latest version of Intune Manger in GUI mode.

    Failed to invoke MS Graph with URL https://graph.microsoft.com/beta/deviceManagement/configurationPolicies (Request ID: acfefb66-8769-4059-a208-2711023c53d7). Status code: BadRequest. Response message: A type named ‘microsoft.graph.deviceManagementIntent’ could not be resolved by the model. When a model is available, each type name must resolve to a valid type. Exception: The remote server returned an error: (400) Bad Request.

    Reply

  2. Hi Andrew,

    What would you recommend if they are already using Device Configuration profiles and Setting policies within their individual security blades and they want to move to Security Baselines? Is that a good idea at all? Now a Disk Encryption policy (Bitlocker) is configured and active on all Windows devices. So can you switch to Security Baselines to activate Bitlocker there? To me that seems almost impossible, because Bitlocker is already active via the policy.

    I hope you understand what I mean.

    Thanks in advance.

    Best regards,
    Rick

    Reply

    • Hi Rick,
      I would probably avoid baselines, but if you want to switch bitlocker from a config policy to a security config policy (if that makes sense), as long as the settings are the same, it should just detect Bitlocker is already configured and confirm it’s setup ok

      Reply

      • So if the settings in the Disk Encryption policy are the same as in the Security Baseline, then it shouldn’t cause any conflicts?

        Reply

        • As long as they aren’t both assigned at the same time. Assuming the disks are encrypted, I would unassign, wait and then re-assign.
          Unassigning shouldn’t decrypt the drive so you will remain secure in the transition

          Reply

  3. Man, Idk why I keep having issues, but using the new baselines you uploaded to github, I’m getting the same errors. I’m using an importJson script, tried importing manually via Intune, and also used the Management GUI. I keep getting “A type named ‘microsoft.graph.devicemanagementintent’ could not be resolved by the model.’

    https://i.imgur.com/QAzKJoJ.png

    Reply

  5. Hey Andrew! Thanks so much for the article. I’m at MMS Miami right now and someone gave you a shoutout around baseline importing. That being said, when I try to import your basline, it’s giving me the errors in the image below. Would you be able to reupload your basline by chance? https://i.imgur.com/CydnHjW.png

    Reply

  10. Andrew thank you for this great post and I’m loving all content in general.

    I have quick question, hoping you can point us in the right direction. Near the end you mentioned that the blade policies don’t cover all the settings. So I’m curious if you have a resource that shows what is missing from the blade policies that’s covered else where?

    Reply

    • Hi, it’s mostly around the more legacy parts, IE11, RDP, TLS etc. I usually create those in a Security Baseline, but use the security blade where possible. Happy to send a JSON extract of the baseline if it would help

      Reply

  11. Amazing explanations, incredibly practical. Thank you for your expertise and time on this.

    Would there be a section for comparisons between Security Baselines EG. Intune vs M365 Defender for Endpoint?

    Reply

    • Yes, I will get that added on ASAP. My personal opinion is the Defender for Endpoint baselines within Intune Baselines are a quick deployment, but don’t have the same control as setting them individually via each security blade. The main Security Baseline has settings which would otherwise be in Admin Templates around IE and RDP so these have some use, where as the Defender for Endpoint settings are all the same as can be set via individual policies, just without the same level of control and granuality.

      Reply

Leave a Comment