The baseline has been developed to provide a balance between security and usability, as well as having gone through multiple iterations in live environments. Some settings have been adjusted because the reality is that they are not feasible in a production environment, or have been found to cause issues with usability or supportability.
I have not documented the rationale for every setting discrepancy, but if you have a specific question please either raise an issue or post in discussions and I will try to answer it.
This is a wider issue with security tooling, and is not specific to the baseline or even Intune. Many security tools are hard-coded to check for traditional GPO registry key locations and many (but not all) CSP's use different locations to apply a setting. This is not an issue with the baseline or Intune, and is only something that can be fixed by Microsoft or third-party security tooling vendors!
I highly suggest you reach out to your vendor and make noise about this problem.
The baseline does not provide a 1:1 mapping against any single of the security frameworks, and is not intended to. It is a starting point for a secure device configuration, and should be used as such. Additional settings can be layered on top of the baseline to provide additional security, or to meet specific requirements.
If you feel a setting should be included, please raise an issue and I will review it.
Policies that have a (Device) or (User) suffix on them are configured at the respective areas of the registry (HKLM or HKCU). On a device with multiple users, the (Device) policies will be applied to all users, and as such the policy setting in HKLM will take precedence even if the user has something else configured.
I have tried to make the baseline as functional as possible, including grouping policies into logical categories, so you should be able to easily identify which policy is causing the conflict. Sometimes policies have strange interactions with others, and this is not always obvious. If you are unable to resolve the conflict, please raise an issue and I will try to assist.
There could be many reasons to this, but most issues end up being related to licensing. Some policies are only valid on Windows Enterprise SKUs. Check the associated CSP documentation for the policy you are trying to implement to ensure you have the correct licensing.
If you are trying to apply the baseline onto a Hybrid-Joined device, GPO is likely taking precedence. You should be using GPO to manage Hybrid devices, and/or moving to cloud-native devices.
At a basic level, all policies are just adding or amending registry keys in exactly the same way as GPO, and while most CSPs clean up after themselves, some do not. If you have removed a policy from the baseline, but it is still applying, it is likely that the registry key is still present on the device. You can either remove the registry key manually, or use a custom script to remove it.
All policies follow the same naming convention, and as such should be applied to Devices if the policy is denoted by D, or Users if denoted by U, however there are a several reasons for this:
- Some policies are set to User to resolve specific issues, such as Credential/System/Device Guard and HVCI which require a reboot to apply. When these are applied to a device, they happen automatically causing a mid-Autopilot reboot between the Device and User ESP which while not a major issue, can cause confusion for end-users as it will require them to re-enter their credentials.
- Extensibility & Managability - You may want to have base Edge security settings applied to every device, but have multiple policies for Extensions based on user groups, or allow certain actions or behaviours on IT-owned devices. From experience it's a lot easier to manage user groups for this. You also don't want to be in a position where policy is applied via a manually-managed device group. While this can be helpful for testing, the last thing you want is a device to be re-purposed but not removed from a group causing the incorrect security policies being applied.
- Some policies just feel like they should be applied to a device, or vice-versa, such as BitLocker.
You can just import what you want, and change/delete whatever settings you need to. The baseline is just a starting point, and is not intended to be a "one size fits all" solution. It is intended to be a foundation for you to build upon.
The baseline is provided as-is, and is not intended to be used in a production environment without thorough testing first.
Have your Security team even read the CIS L2 documentation? It's not possible to meet CIS L2 without impacting usability and functionality. CIS/NCSC/MSFT recommendations are just that - recommendations, not a box-ticking excercise.
If you have to meet CIS L2, you'd be best starting your own policies from scratch.
No. Intune is in constant development, and new settings and functionality are added all the time. You should be reviewing your policies regularly to ensure they are still valid and meeting your requirements.
The settings included in the baseline will stop actions that require elevation, but will not stop apps that do not require elevation or install to a user's AppData folder. To achieve this you will need to look at AppLocker or Windows Defender Application Control (WDAC).
The baseline is designed for and tested on Azure AD/Entra Joined devices, and as such some settings may not work on Hybrid devices. If you are using Hybrid devices, you should be using GPO to manage them and/or moving to cloud-native devices.
To stop someone doing something really stupid in their production tenant. Unless you're working in a Dev/CDX/Greenfield tenant, you're likely to have existing devices or policies in place. I didn't want someone to get fired because they imported something from the internet into their production tenant without any change control or testing (even though I put a warning in the README).
Please raise an issue, post in discussions, or reach out on Twitter.
I'm always open to reasonable suggestions and improvements, and this is supposed to be a community-driven project so your feedback is incredibly important :)