Zero Trust in Administration

CrowdStrike, Windows domain administration, SolarWinds — our implicit trust in admin software is a recipe for repeated disasters.

The most unsafe part of our technology ecosystem isn’t the number of unpatched systems we have. Nor is it shadow IT, whether it’s homegrown software or the burgeoning bring-your-own-SaaS ecosystem. The shared responsibility model, and the impossible complexity of safely configuring systems isn’t even in the running. It’s not even the insider threat, whether we mean the extremely rare hostile insider, the compromised end-point with too many permissions, or the well-meaning user and the unsafe software they’re forced to use every day.

The most unsafe part of every company is our administrative software. Whether it’s the Windows domain administration setup, often hijacked by ransomware to move laterally, or applications such as SolarWinds or CrowdStrike, which can be used to remotely infect — or simply crash — entire fleets of systems, the software that makes us most unsafe is, ironically, the software installed by the very teams responsible for safety and security.

Is it time for a Zero Trust model … applied against our IT teams?

Zero Trust had its heyday, but was remarkably hypocritical in its execution. Organizations implemented Zero Trust network access, which (rightfully) refused to trust end-user machines simply for connecting to a VPN, instead requiring continuous, strong authentication to engage with any application, and often pushing permissions up to the application instead of merely defaulting to “all employees can access everything.”

Most companies, however, didn’t extend this to its natural next step. Why do we trust our administrative users and software implicitly? Endpoints — whether laptops held by users, servers in the cloud, or embedded devices powering airport displays — are often heavily laden with remote administrator tools in the unified endpoint management (UEM) space. Asset management to inventory and track the contents of the devices. Mobile device managers to deploy software, configure policies and keys. Remote server administration tools (RSAT) to let authorized administrators log in (not to be confused with remote access trojans (RATs), which adversaries use to do the exact same thing). Even enterprise browsers to monitor employee access to the internet. Endpoint detection and response (EDR) to identify when someone has compromised the machine, often by compromising one of the other administrative tools on the device.   

Imagine, instead, an endpoint that didn’t trust all these tools. It doesn’t permit remote administration, disallows remote login, and isn’t loaded down with a dozen different agents solving disparate security and IT tasks. Instead, it focuses on its one job: whether that’s enabling its user to safely interact with the internet, running an application server, or putting a display up on a kiosk. It doesn’t trust the employer’s ecosystem, except as a source of email and files, and only then just barely. It certainly doesn’t trust any other clients on the same network; to it, a Starbucks is just as secure as a corporate network — which is to say, not at all. It’s locked down from as many third parties as possible, and it auto-updates using vendor updates (let’s ignore, for a brief moment, the rare risk of auto-updating, highlighted by Crowdstrike’s incident).

In that world, the number of vendors in our ecosystem that can cause us really bad days drops significantly. We still rely on Apple, Microsoft, and Google for our endpoint operations, but those three are far more trustworthy around safety than the collection of IT and security software deployed across the modern enterprise. Instead of worrying about a few dozen vendors whose bad days can kneecap our economy, we’re down to three — three who’ve demonstrated a focus on safety that we sorely need (and that regulators could focus their safety attention on, instead of chasing CrowdStrike while missing all the other risky administrative toolkits out there).

But we still might need an EDR … just a Zero Trust EDR

In that world, ironically, we still might need an EDR protocol and application. End users should have one platform to make sure their device is actually locked down, and to report that (but only report) to their employer(s).

Perhaps that’s a product of the operating system vendor, or it could be a third party, but one that focuses on minimalism, focusing on protecting the device proactively by preventing adversaries from even getting toeholds, rather than reactivelyby trying to detect adversaries after they’re already on board, and certainly not requiring such deep administrative privilege as to cripple the device when it stops working.

A Zero Trust EDR, whose principal user is the end user, might also see incentive to focus on security usability for end-users; perhaps integrating multiple password managers (as any Apple user who also uses Chrome and 1Password would love), spearphishing detection, enterprise browsing, and any number of other capabilities.

CrowdStrike, entertainingly, might be uniquely positioned to pivot into this world, and use the reaction to their own failure to displace other solutions in adjacent markets. Wouldn’t that be making lemonade out of lemons?

This piece originally appeared in CSO Online.