Devices still matter, Part 1: Why you need a device management strategy

The Center for Internet Security (CIS) publishes 20 controls in their cyber-security framework. If you want to understand what good management looks like, then start here. The first six controls are considered the “basics”–the first and most important steps that any organization should be taking as they work to secure their environment.

Now the first and most critical security control spelled out by the CIS framework is Inventory and Control of Hardware Assets. This of course, includes all your workstations and other endpoints. You need to to know the devices you have vs. which devices actually are connecting to your infrastructure and services.

And yet every small business I run into these days seems to think that because they are in the cloud, or because they have so few devices, they can skip control #1 (and several others) and ignore their endpoints as if they don’t matter.

Why is that? Did we all wake up one day and start taking stupid pills?

I think it’s because devices have become invisible to us. In the era of the cloud, devices are all essentially interchangeable, and it can appear as though there is nothing of significance to them. I mean, if the laptop I am typing on were to suddenly die right now, I would simply go get a new one, sign into all my cloud apps, and continue working where I left off, with little or no risk of data loss and minimal downtime.

Therefore, the reasoning goes, the devices aren’t important. And hey, I’ve got 2FA turned on, so I’m good to go, right? I have even come across MSP’s or cloud service providers who host stuff like virtual desktops (VDI) telling their customers that endpoints no longer matter.

But that’s completely stupid and foolish. Let me explain why.

Building good security

There is damn good reason that control #1 comes first and is actually a higher priority than the subsequent controls. We can only build up to secure configurations (control #5) from a solid foundation. Stay with me–let’s break it down.

Control #2 is Inventory and Control of Software Assets: What software packages do you really need vs. which ones are actually being installed? You need to get a handle on this also. You don’t want random software packages showing up on your endpoints; instead you want to deploy the software that people need to do their jobs–no more, no less.

ASIDE: Notice that this straightforward and methodical approach to security also lines up with the first function of the NIST security framework: Identify. Having an inventory (and control of that inventory) is one of the very basic minimum things you need to be doing. How can you properly protect your assets when you don’t even know what you have or what you should have? That’s why Identify comes first in NIST. That’s why Inventory and Control of Hardware and Software Assets is considered basic and primary in CIS.

And these frameworks are really smart, aren’t they? Watch how they continue to build good security from the ground on up.

As we move from Identify into Protect, we have new to-do’s on our checklist. Control #3: Software has vulnerabilities–therefore you need to be managing them–staying on top of your patches and so forth. And now that you have a handle on your devices and the software that you need to maintain for your business, it’s high time you implement Control #4: limit admin privileges–like you should probably rescind the the ability to add any new software packages that you don’t know about and don’t want in your environment.

Finally we come to Control #5, which is particularly interesting because it is all about implementing a secure configuration on your systems. Notice that this is step #5, not step #1. Why?

Well, if you are still allowing any and every user to rule their own machine, and install different things or change their own settings, how in the hell can you lay down a “secure configuration” today and know that it is still in a secure configuration tomorrow?

Good question!

It all makes sense now…

Even with all of your resources in the cloud, the endpoints are still the access gateway that you use to get into those apps, and work with that data. And let me tell you something:

The bad guys absolutely LOVE that you are ignoring your devices!!!

So that’s one secret that they don’t want you to know. By failing to keep proper management of your endpoints, you are basically allowing attackers to “live off the land” and get away with murder. They accomplish this in one of two different ways (broadly speaking):

1. Attackers can use any device
2. Attackers can use your device

Today I will describe how attackers can use any device, anywhere in the world, to gain access to your resources–even if you have MFA enabled. And we’ll talk about how to mitigate that risk with Microsoft 365 and Conditional Access. Then, in the next post, I’ll go into how attackers can leverage your device to do harm–which is a bit trickier of a problem.

Attackers can use any device

Why is the inventory so important? Because you need to have a full and true accounting of what systems are allowed to participate in your infrastructure. Then, you need to have an audit log, that details which systems are in fact participating in your infrastructure. Are these two lists the same, or not?

If not, then you have a problem, and that problem needs to be corrected. But most people can’t even show me one of those two lists. So they have no idea if they are at risk or not.

But wait, wouldn’t a second factor of authentication save me from such a scenario? Look, MFA is great–and today it still prevents the majority of breach attempts that are based on some kind of identity attack.

But note that it cannot stop all phishing attacks–the primary vector used by the bad guys–and as time moves forward we will continue to see even the mighty MFA erode further as new ways of getting around it are invented. And unmanaged devices are one such avenue that leave open the floodgates. (Plus with basic auth left enabled and no MFA then the floodgates are REALLY wide open).

Now let’s look at two different examples of how an attacker can use any device–usually from anywhere in the world–to connect to your cloud-based resources–even if you have Multi-Factor enabled.

Example #1: MFA phishing

It is of course possible to trick users into giving up their security question, their round trip SMS code, or whatever. If it comes from a text message, then we also have the option of grabbing it out of the air with a spoofed number, or exploiting other known vulnerabilities.

In practice these may be infrequent, but there are more and more stories these days of successful breaches using some kind of phishing and/or social engineering tactics to get by MFA. Even just something as simple as:

Bad guy: “Hey I know you don’t know me but I used to have your phone number. My bank wants to send me a text code since I never changed my number on file with them, can you send it back to me when you get it? They won’t let me in without it. I’ll update the number as soon as I get logged in.”

Victim: “Sure…”

Bad guy: “Okay, it will be coming very soon…”

Victim: “917 307”

Bad guy: “Thanks!”

Victim: “No problem.”

Laugh if you want to. The bad guys certainly did. But that’s a real example that worked on one of my clients (who shall go unnamed).

And let’s not forget about app passwords. I have also seen app passwords successfully phished or exflitrated from other places. Usually people do dumb things with app passwords like save them in a text file on their desktop, or in a sticky note or OneNote or something. Like I said: dumb, but another good MFA bypass method if you can get your hands on one.

Example #2: Evilginix

Evilginix is a piece of software that can be used in executing advanced man-in-the-middle attacks, including the ability to bypass MFA. Basically, when a user is sent to a login page, they might actually be interacting with the real thing–Google, Microsoft, or whatever–it is the real login page, but it all happens through an intermediary: the Evilginix server. That means you can even complete a 2FA challenge and thereby grant the bad guys access.

They now have a token that is good to use in other browser tabs that you cannot see from your own device. In fact, your own device never actually registered with the remote server–from the point of view of the website you are signing into, the logon request came from the Evilginix device (you were just proxied through it because you hold the keys).

Enter Conditional Access

In both of these examples, Microsoft 365’s Conditional Access could have stopped the attacker. If you enforce an access control that says a device must be enrolled and compliant with Intune policy, then an outside/unmanaged device would not be successful in obtaining access, even if an MFA challenge were successful. The Evilginix server or that person on the other end of the text thread–they are using an outside/unmanaged device.

So MFA = Successful, but Conditonal Access = Failure.

Also, enforcing this access control–compliant devices–would mean that the list of devices you see in your management portal is the sum total of devices that are your responsibility to manage–the sum total of devices that have access to your apps and data. AND you can control compliance on that device, and decide what software packages and updates get pushed to those devices, further helping you implement the basic security controls.

You just don’t have the same level of confidence with devices that are merely Azure AD registered–you cannot exercise control over those devices until they are either Hybrid joined or enrolled with Intune. And even then you have to remember that the list of “registered devices” isn’t necessarily a complete view of every device that touches your environment, either–until you light up Conditional access. Then only the devices that are compliant are those with access. And that’s huge!

UPDATE: To be clear, I am not suggesting MDM / device compliance needs to be the baseline config for any and every organization. But those that deal with very sensitive data and security is of the highest priority–then certainly. I would not entertain BYOD in those types of circumstances. But also to be clear, you can enable BYOD scenarios in more typical environments or with your average information workers. Conditional access can help you out here as well, and this control still mitigates a lot of risks and protects the company data. As well, devices that are compelled to use an approved client application and apply app protection MUST be registered against Azure AD. Remember: not every device that touches your environment has to register, but those that are participating in an access control (either for MAM or MDM scenarios) must be registered and part of the inventory, and you have the ability to retract the data, too.

Next time we’ll pick this conversation up with how attackers can use your device to get at valuable corporate assets and data.