WHAT IS ZERO TRUST (ZT)? This is perhaps the most egregiously co-opted term in IT marketing today, leaving a lot of us dazed and confused by the hype. But I am going to define ZT as a framework upon which we can build more effective IT security. It is based upon flipping the paradigm of blocking potential threats to allowing only the known good. True zero trust requires attention to remote and wireless access, data flow, device control, and more. Here we will focus on four components: whitelisting, ringfencing, privilege elevation, and storage.
We all have firewalls at the edge, managed detection and response solutions on endpoints, protections for our M365 “endpoints,” and more. But each of these is focused on reacting to threats, and no matter how carefully we craft our stack, a penetration is possible. But what if instead of blocking unknown threats we whitelist good applications and behaviors? What if we move from unfettered access to application ringfencing, from local admins to on-demand privilege elevations, and from full access to storage to controlling storage access?
These sophisticated capabilities are finally within our reach. Of course, the first concern is going to be the “noise” this may create. Labor is our most precious resource, and it cannot be squandered. Soft costs matter too; nothing can sour a client relationship like inconveniencing them too much. Nothing, that is, but downtime or a data breach and its potentially catastrophic costs.
That is the line we walk. Anyone who has enabled universal multifactor authentication (MFA), deep packet inspection of SSL (DPI-SSL) in the firewall understands this trade-off.
Most of us feel that enough layers of protection at the edge, the endpoints, and the mailboxes, as well as artificial intelligence and human eyes reading logs, will protect our sites. But the reality is that our every effort can and does get beaten; what then? That is where allowing only “known good” applications comes in, aka application whitelisting (AW). Simply put, AW blocks anything we have not previously approved. Period.
Of course, this sort of lockdown can lead to some real challenges, and many of us fear the storm and fury that this may cause amongst our clients. The answer to this is to initially implement AW in “monitor only” mode, gathering intel on the baseline of each of our sites before we turn it on and lock it down.
The next step beyond whitelisting is the ability to control what resources these whitelisted actions have access to. This allows even previously whitelisted applications from “going rogue” and accessing files, folders, and capabilities that they have no need for. For example, why allow every application access to PowerShell, or allow every application internet access to everything by default? File systems, permissions, and access control lists are neither smart nor granular enough to discern access at this level of detail. But ringfencing brings that level of intelligence to your security stack. Of course, setting up ringfencing brings the same worries that whitelisting does, so you must go through the same testing process discussed above.
We must also address privilege elevation. We all know we should never have users running with local admin privileges. But we also all know that every business has a vertical application or two, not to mention such commonplace nightmares as QuickBooks, that require local admin privileges to launch or apply patches. Most of us bite the bullet and react to support calls for elevation, or worse, provide local admin rights to users who should never have it.
There is a better way. Privilege elevation allows you to run as standard users (not local admins) without elevated privileges but with no productivity loss. When the need arises, you can respond promptly to elevation requests as needed through a console or a phone app.