This post has been republished via RSS; it originally appeared at: Device Management in Microsoft articles.

Security is always a key topic, but also one that can be difficult to discuss w/o giving too much away and losing that layer of security that obscurity can provide.  With that in mind the goal here is to share with customers the general steps that we take within Microsoft to keep the activities we have around MEM (SCCM and Intune) secure and safe for the company and its employees.  While details will be missing, the hope is that others will consider these measures when deciding how best to secure their own MEM environments.

The security we have in place for managing MEM happens at several levels.  A mantra here at Microsoft is that every security decision should be made under the assumption that all other security measures have failed to keep the "bad people” out. That means there are a lot of levels of security and thought.  Being users of MEMCM and MEM Intune just like the rest of the customers out there we won’t try to cover all the product specific security implementations here.  Those we will leave to the product documentation itself.  Instead we will look at this from the administration process viewpoint.

Read-Only Access

Through normal daily activities we need to see various things in our services.  Elevating or going through the steps necessary below to have read-only access granted becomes too complicated for these common access reasons.  For that we maintain several different groups which provide access to various resources.  Each of those is managed by an internal system where people can request to join a group and that group membership is either approved through a process or auto-approved, depending on what it is focused on.  That membership, once granted, has a renewal timeline and will remove membership when someone leaves the group/company.

Multiple Accounts

A basis of what we do is to have two separate accounts.  The idea is to have one account for normal operations (email, TEAMS meetings, etc).  The other account is used ONLY for administrative activities.  We refer to this as our “Alternative Account” or, “ALT account” for short.  The ALT account is backed by a smart card and certificate login requirement making the compromise of the account a little more difficult. Both accounts require multi-factor authentication.

Secure Workstations

While much of our read only access can be done from our normal desktops and laptops, anything that requires an admin level of access is locked down to only allow access from Secure Access Workstations (SAW). These are special laptops which work on a basis of whitelisting what they are allowed to access and what apps they can run.  We do not have admin rights on these machines like we do on our normal machines, we can’t go off to malicious websites, and we can’t get email on them.  Their exposure to risk is more limited. The SAW run a separate VM which some people use for those “normal” activities, while others will remote back to other machines when that “normal” activity is needed.

Azure Portal

Our Microsoft Endpoint Manager Configuration Manager (SMS to you old school folks, SCCM to you “not as old, but not your first rodeo” folks) is Azure hosted, so protecting that Azure access is the first layer we need to keep secure.  We do this using normal methods which allow our normal accounts a level of read access, but no standing administrative rights.  Admin access requires Azure Privileged Identity Management (PIM).  It will elevate our account, on a temporary basis, to have the needed admin permissions in Azure.  This is audited, requires a second person approval, and is time limited to reduce the attack concerns.

Server Access

If we need to get into a server for looking at logs or other simple things we have some read-only share access setup for our team.  Beyond that we have a system that is similar in concept to PIM that requires that we request the level of access we need and then grants that access for a limited time.  We refer to it as “Just in Time” access, or JIT for short.  Things like which server, is it OS level or SQL level or SCCM level, etc. are all separated to require different escalations, and it is all audited, of course.  This allows us to request the minimal access necessary for the job at hand.

Intune Access

Admin access to Intune is, essentially, through the normal Azure portal like above.  There is a separate PIM role for Intune administrative .  This is also designed around the “nuclear launch” concept where a second person is required to agree and authorize the rights elevation.  For those that need a lower level of rights, but still have the ability to read or interact with the environment in a limited capacity we make use of the RBAC roles within Intune and some self-cleaning security groups to grant that access.  We also have a few different Intune environments (we are running beta versions of things) so we have some separation around those things as well.

Configuration Manager Access

Similar to server access we have JIT groups for accessing MEMCM itself.  They tie back into the RBAC roles of the product so different people have different groups for different activities, but anything that can make any kind of change is controlled in this fashion.  We have also enabled multi-factor authentication (MFA) in the product to help us ensure that people are coming in as securely as we can.

Summary

Anytime we have a new hire we always must go through an orientation of what to use when and how.  But, once you do things a few times it gets to be second nature.  A few things have some time delays that can be frustrating at times, but overall it seems to work well and we take the security of our operations very seriously.  Does it add complexity and occasional frustration... yes.  Is it worth it to keep our environment safe... totally.

Hopefully this gives you an idea of how we securely control access to our MEM environments.  We have also done work within the features of the products to increase our security stance, such as removing the Network Access Account and using token authentication, getting rid of traditional service accounts where possible, and auditing activity.  All that we will save for other blog posts.