Pragmatic view of Zero Trust

Traditionally we have taken the approach that we trust everything in the network and everything in the enterprise and put our security models at the edge of that boundary. Pass all of our checks, and you are in the “trusted” group. 

That worked well when the opposition was not sophisticated, most end-user workstations were desktops, the number of remote users was very small, and we had all our servers in a series of data centers that we controlled completely or in part. We were comfortable with our place in the world and the things we built. Of course, we were also asked to do more with less, and this security posture for critical infrastructure was simple and less costly than the alternative.

Starting around the time of Stuxnet, this started to change. Secure access went from a poorly understood, accepted cost and backroom discussion to one being discussed with interest in board rooms and at shareholder meetings. 

Overnight the executive level went from being able to be ignorant of cybersecurity to having to be knowledgeable of the company’s disposition on cyber. Attacks increased, and major news organizations started reporting on ransomware attacks, data breaches, and cyber incidents. Legislation changed to reflect this new world, and more is coming. How do we handle this new world and all of its requirements?

Zero Trust is a change in information security. Zero Trust is a fundamental change in a cybersecurity strategy. Whereas before, we focused on boundary control and built all our security around the idea of inside and outside, now we need to focus on every component and every person potentially being a Trojan Horse. It may look legitimate enough to get through the boundary, but in reality, it could be hosting a threat actor waiting to attack. 

Even better, your applications and infrastructure could be a time bomb waiting to blow, where the code used in those tools is exploited in a “Supply Chain” attack. Where through no fault of the organization, they are vulnerable to attack. 

Zero Trust says – “You are trusted only to take one action, one time, in one place, and the moment that changes, you are no longer trusted and must be validated again, regardless of your location, application, userID, etc.” Zero Trust is exactly what it says, “I do not trust anything, so I validate all the things.”

That is a neat theory, but what does that mean in practice? We need to restrict users to the absolute minimum required access to networks that have a tight series of ACL’s, to applications that can only communicate to those things they must communicate with, to devices segmented to the point they think they are alone on private networks while being dynamic enough to have their sphere of trust changed as the organization evolves, and still enable management of those devices. 

The overall goal is to reduce the “blast radius” any compromise to sensitive data would allow in the organization since it is not a question of “if” but “when” for a cyber attack.

So if my philosophy changes from “I know that and trust it” to “I cannot believe that is what it says it is,” then what can I do? Especially when I consider I did not get a 5x budget to deal with 5x more complexity. I look to the market. Good news! Every security vendor is telling me how they solve Zero Trust with their tool, platform, service, and new shiny thing. So I ask questions. It seems to me they only really solve it according to marketing. Why? 

Because implementing Zero Trust is hard. It is very hard. Complex, it requires change across the organization, not just tools, but the full trifecta of people, process, and technology, and not restricted to my technology team, but the entire organization, not one region, but globally. It is a lot.

All is not lost, though, because Zero Trust isn’t a fixed outcome; it is a philosophy. It is not a tool, an audit, or a process. I cannot buy it, nor can I certify it (no matter what people selling things will say). So that shows hope. Additionally, I always remember the truism; “Perfection is the enemy of Progress,” and I realize I can move the needle.

So I take a pragmatic view of security through the lens of Zero Trust. I don’t aim to do everything all at once. Instead, I look at what I am able to do and where I have existing skills. How is my organization designed? Am I a hub and spoke where I have a core organization with shared services and largely independent business units? 

Maybe I have a mesh where the BU’s are distributed to where we organically integrated and staffed as we went through years of M&A. Maybe we are fully integrated as an organization with one standard for everything. Maybe it is none of those.

I start by considering my capabilities and mapping my current state. Where is my organization on the NIST security framework model? Where do I think I could get with my current staff? Who do I have in my partner organization that can help me? Once I know where I am, I then fork my focus.

One fork is on low-hanging fruit that can be resolved in the short term.  Can I add some firewall rules to better restrict VLAN’s that do not need to communicate? Can I audit user accounts and make sure we are following best practices for organization and permission assignment? Does MFA exist, and can I expand its use or implement it for some critical systems?

My second fork is to develop an ecosystem of talent organized around a security-focused operating model, otherwise known as my long-term plan. DevOps becomes SecDevOps, where security is integrated and first. My partners become more integrated, and I look for, and acquire relationships with new partners that fill my gaps. 

My teams are reorganized to support security by design AND practice. And I develop a training plan that includes the same focus on what we can do today (partner lunch and learns) with long-term strategy (which may be up-skilling my people with certifications).

This is the phase where we begin looking at a tools rationalization project. What do my existing tools not perform as needed in the new Zero Trust world? These will likely need to be replaced in the near term. What tools do I have that work well enough but will need to be replaced at the termination of the contract? What tools do I have that we will retain?

Finally, where do we see the big, hard rocks being placed in our way?  It is a given that our networks will need some redesign and will need to be designed with automation in mind because the rules, ACL’s, and VLAN’s will be far more complex than before, and changes will happen at a far faster pace than before. Automation is the only way this will work. The best part is modern automation is self-documenting.

The wonderful thing about being pragmatic is we get to make positive change, have a long-term goal in mind that we can all align on, and focus on what we can change while developing for the future. All wrapped in a communications layer for executive leadership and an evolving strategy for the board. Eating the elephant one bite at a time.