Limiting privilege is a process, not an event

In some past blogs I have highlighted the importance of devices in your security, management and compliance journey. Why do I harp on that? Because it is the starting point.

The mantra takes various forms, but basically you cannot protect what you cannot see. This applies to devices of course, but also to applications. However, it is difficult to progress to managing applications if you don’t have inventory and control of devices. Without the complete picture of devices, you lack the complete picture of apps in use on those devices. That’s why devices come first.

But applications are second. You have to establish a good inventory AND control of your software so that you can move closer to your ultimate goal: removing administrative privileges so that your users DO NOT install their own software and cannot elevate their session to allow apps to change anything about their device.

Why limit privilege?

Truthfully, I have waffled a bit on this point. Yes, there are modern tools available that can help us to reduce attack surface (e.g. Exploit Guard) and do some other things like isolate web browser sessions in Hyper-V containers (Application Guard). And yes–these things would allow you to minimize certain types of common risks without necessarily removing admin rights… but the very best way to mitigate your risks to the highest extent possible still boils down to removing admin privilege on end-user devices. It’s difficult to argue on this point.

Now that doesn’t make the endpoint bulletproof, but man it really makes life for attackers more difficult. If they get onto an endpoint and find out they have full control and admin privilege, they just get so many more degrees of flexibility and options for moving around–so why let them live off the land like that? If you settle for less than this, you are accepting a higher level of risk, even if you have an EDR and all the other fanciness that I mentioned above.

But the number one reason IT admins don’t take away privileges is that they simply do not know what the users need or might need in order to be productive. What if they take away privilege and then the user gets stuck, what if they can’t can’t get the software they need when they need it?

Two problems: technical and non-technical

There are really two issues at play here.

1. Admins and the primary stakeholders in the business don’t even know what’s out there and why (Shadow IT), and therefore have no control over the software in their environment
2. There is no corporate guidance around what apps to use (approved) and what apps to avoid (non-approved), as well as no approval process for new apps that are wanting to come into the fold

And so the solution here really needs to address both aspects. We can help the business implement some tools from a technical perspective–and that’s what I’m going to discuss in my next article–but ultimately the business must develop a written policy and procedure that is communicated out to the org: what is our standard, approved tool-set, and how do we deal with outliers or new requests? It doesn’t have to be highly complicated but you need management buy-in to deploy and enforce the policy effectively.

3,2,1, Lockdown

The other big thing to understand here is that you cannot jump from zero visibility all the way into lock down mode. Generally that is going to be begging for headaches and chaos on your support desk and bad user experiences; not to mention your efforts won’t be effective anyway if you don’t have an accurate inventory up front. In short: try to be smart about how you move folks up the security maturity chain.

This is why my (recently updated) Windows 10 Business guide includes a spectrum of security profiles, from Standard/Low to Enhanced/Medium and finally High. But note that you can (and probably should) put very high risk or highly privileged users, including your tenant administrators, on the highest security profile quickly. So called lower-risk or standard-risk users can start out at a lower tier. Your goal, ultimately, should be to remove local admin privilege everywhere that you can. But build to it.

You and other admins should “go first” and feel the full effects and experience of running without admin locally, and having more controls placed against the device. This means turning up the Defender settings to the max–all the attack surface reduction rules and other features.

Besides limiting the “local” attack surface for users who have the broadest amount of privilege at a “global” scale, this will also give you a chance to appreciate the impacts on end-user experience. Now you will understand the controls fully before asking your co-workers and/or customers to wear the same yoke, as it were.

Alternative solution?

Another solution that I’ve seen gaining popularity is the idea that endpoints are kept as ephemeral as possible, and you just burn them to the ground as frequently as you can (even daily) and start over again.

Maybe this gives users a bit more flexibility on the devices throughout any given day or session, but the effect on attackers is that they cannot establish footholds or persistence on the device, which is a frustrating experience to say the least.

That’s cool–if you can make that kind of strategy work using your corporate endpoint management tools then go for it. But the pre-requisites for achieving this kind of result are still exactly the same–even if the device is more static, and less ephemeral:

1. Inventory and control of hardware devices
2. Inventory and control of software / applications
3. Patching/continuous vulnerability management

You would have no way of wiping and reloading frequently, or removing session data and starting each day out fresh, without first having control of those endpoints and without a complete list of software that is needed on the endpoint for productivity.

That’s enough for today

I believe that I have probably already beat the idea of device compliance to a pulp on this site–in short: Conditional Access in Microsoft 365 helps to ensure that if your device has access, it is in the inventory and under control by Intune a.k.a. Microsoft Endpoint Manager. And that takes care of that first step we talked about: devices.

In another post, I’ll show you some of the many ways we can get a handle on the apps in our environment using various tools in Microsoft 365. In this regard, I don’t think I’ve done an adequate job of covering the breadth and depth that we have available to us yet. But note: not all of these capabilities are available right out of the gate with the Business SKU; nevertheless add-ons from the Enterprise space are available to help you fill in gaps as needed with some important recent announcements that make this even more attractive.