The ideal security stack - part four


In the final part of this series on security, find out why Zero Trust Network Architecture should be baked into the core design of your networks.

In parts one and two of this series, we looked at how to conceptualize the design of a security stack, whether to “tier” that stack or build a “one size fits all” solution, and some of its components.  But what if all fails?

That is where Zero Trust Network Architecture (ZTNA) comes in. ZTNA must actually be baked into the core design of your networks, from network segmentation to multi-factor authentication, to securing wireless traffic, and more. The next level of ZTNA design is whitelisting, ring fencing, and on-demand privilege elevation.

Related reading: The ideal security stack - part three

Flip the paradigm

We have firewalls at the edge to prevent hacking, Managed Detection and Response (MDR)  on the end points for anti-malware, and other protections on the M365 “endpoints.” But these tools are all focused on reacting to threats. Yet no matter how carefully we craft our stack, a penetration is always going to be possible. But what if we could invert this paradigm and go from blocking these threats to whitelisting good applications and behaviors? What if we move from unfettered access to application ring fencing, and from local admins to on-demand privilege elevations?

These sophisticated capabilities are finally within our reach in the MSP space. Of course, the first concern is going to be the noise this may create. Labor is our biggest cost and it cannot be squandered. And soft costs matter too; nothing can sour a client relationship faster than inconveniencing them. Nothing but downtime or worse, a data breach and its potentially catastrophic costs. That is the line we walk, between ease of use and securing client operations. Anyone that has enabled universal MFA, or DPISSL in the firewall understands this trade-off.


At some point, all of us will have to accept the fact that whitelisting will be a crucial component of our stack. To this point, most of us believe that we can educate our users and “harden” them against social engineering. We know that enough overlapping layers at the edge, the endpoints, and the mailboxes, as well as both AI and human eyes reading logs will prevent small mistakes from becoming big issues. With luck, skill, and vigilance, we have been succeeding this way. But that won’t be enough in the future. Whitelisting of applications is the next logical step in our security evolution.

Ring fencing

The next step beyond whitelisting is the ability to control what resources these whitelisted actions have access to. Think of it as “ring fencing” access, so that you can prevent even approved applications from accessing files, folders, and capabilities that they have no need for. For example, why allow every application access to PowerShell, or allow Internet access to every process by default? File systems, permissions, and access controls lists are neither smart nor granular enough to address this at this level of detail. But ringfencing can bring that intelligence to your security stack. Of course, this brings the same worries that whitelisting does, so you must go through the same learning and gradual deployment process we discussed above.

Privilege elevation

Finally, we must address privilege management and elevation. We all know that we should never have users running with local admin privileges. And we all know that nearly every business has a vertical or two, not to mention such commonplace nightmares as Quickbooks, that require local admin privileges just to launch or apply patches. Most of us bite that bullet by reactively intervening to support calls, or worse, providing local admin rights to users that should never have it. But there is a better way. You can withhold these elevated privileges from your users with no productivity loss, managing this with alerts that allow you to promptly evaluate and then respond appropriately to elevation requests without compromise.

How do we get there?

The first step is to choose a solution with a “learning mode” that can baseline your networks. Use this to learn about the product and your sites. But don’t jump the gun and move to production too quickly. Next, make sure the solution you select is capable of learning about new (but normal) behaviors such as OS and application updates, and that it manages them transparently. And select a solution with excellent, responsive implementation and support. Be sure to work through this process with each aspect of your ZTNA solution, from whitelisting to ring fencing, to privilege elevation. Consider phased deployment of each capability at each site, and start with smaller, simpler, and preferably, more forgiving clients.

The bottom line

Over the past 20 years, we have come to accept that even the smallest businesses cannot be secured without a firewall. More recently, we have made the move from traditional antivirus to managed solutions such as MDR. And Multi-Factor Authentication (MFA) is the new normal. But each of these solutions addresses a “point” problem. We need broader, more proactive defense against as yet unknown threats. That’s why we’re moving to add Zero Trust solutions such as whitelisting, ring fencing, and privilege elevation into our baseline security package.

read moreicon


Mapping Your Calendar: 24 MSP Events to Attend in 2024

Discover key events for 2024, to unlock success in the MSP world! Mark your calendars to power your MSP journey with expert insights and networking.

7 minutes