Throughout 2019, HTG saw a rapid rise in customers who adhered to a cloud-first strategy, thus having little to no on-premise services. As such, they ask us how they should be configuring and protecting their end-user computer devices in situations where a) they don’t have the use of traditional on-premise services such as Active Directory, Group Policy and SCCM, and b) where they have all of their corporate data in Office 365 but their staff are using poorly managed Windows 10 devices. More commonly than not, our answer is Microsoft Intune, or to use its newly rebranded moniker, Endpoint Manager.
What is Microsoft Endpoint Manager?
Put simply, Microsoft Endpoint Manager is a product born from the marriage of Microsoft Intune and Config Manager (SCCM) – in brief, up until recently Microsoft had made it clear that SCCM, its long standing stalwart of on-premise device management was on-notice, that is to say, it would no longer be developing it. Instead, it would be slowly migrating all the functionality into Intune, its fully cloud-based sister product. However, at the yearly Ignite conference in November 2019, Microsoft announced somewhat of a u-turn in that they would no longer be retiring SCCM in favour of Intune and instead would amalgamate the two products into what we now know as Endpoint Manager.
Endpoint Manager provides a vast array of services, protects not only Windows devices but MacOS, iOS and Android as well and is closely integrated with Azure AD as you would expect. However, rather than provide an overview of the product, this article will address, and hopefully clarify, one of the common questions we get from our customers (especially those who have attempted to deploy the product themselves)! The questions being, what are the differences between Configuration, Compliance and Security Policies and which one should they be using to secure their devices?
So, let’s dig into it. I’ll cover each policy type in turn and in an order that should hopefully help tie together the relationship between the policies.
What are Configuration Policies?
The best way to think of a Configuration Policy is as Endpoint Managers’ implementation of Group Policy. In fact, Microsoft has engineered Configuration Policies in such a way as to allow you to import and utilise ADMX files in the same way you would in on-premise Group Policy.
Configuration Policies are therefore what you would use to apply predefined settings to a user or device, such as homepage and other browser settings in IE and Edge (and even Chrome and other browsers, but that’s for another blog!) or set a custom wallpaper on the Windows 10 lock screen. Like Group Policy, Configuration Policies can be applied to a targeted set of users or devices using groups within Azure AD.
What are Security Policies?
Put simply, Security Policies or Security Baselines as they are interchangeably referred to, are pre-configured Windows settings that help you apply a known group of settings and default values that are recommended by Microsoft. When you create a security baseline, you’re creating a template that consists of multiple Configuration Policies.
Microsoft routinely released a new Security Baseline which is a thorough pre-defined set of policies that can be quickly and easily deployed to secure your environment. That is not to say you shouldn’t apply standard test and release management processes.
What are Compliance Policies?
Compliance Policies somewhat tie both Configuration and Security Policies together and then apply an additional layer of protection over not only the device or user, but other company resources such as SharePoint sites.
Compliance Policies are used to evaluate a devices compliance against a pre-defined baseline, such as the requirement for a device to be encrypted or to be within a defined minimum OS version which is especially useful with Windows 10 to stop devices falling too far behind with major updates.
Compliance Policies are often deployed alongside Conditional Access Policies, which control what a device can and cannot access should it be deemed as non-compliant, for example, non-compliant devices can be blocked from accessing corporately owned data.
Summary
The key take-aways to conclude this article are that each policy type when individually configured and deployed correctly can add great value in securing a plethora of OS and device types. However, when configured and deployed together, they can not only enforce an entire collection of settings championed by Microsoft but also provide the assurance that should a device fall foul of the required compliance baseline, that device and the user using it would not be able to access and potentially but inadvertently open the company up to malicious exploit.
The post How to configure and protect your end-user devices using Microsoft Endpoint Manager appeared first on HTG.