The pragmatic view of Zero Trust | Blog

Posted on

Traditionally we’ve taken the approach that we trust everyone on the network, everyone in the company, and put our security on the edge of that line. Pass all our checks and you are in the “trusted” group. It worked well when the Oppo was unsophisticated, most end-user workstations were desktops, the number of remote users was very small, and we had all of our servers in a series of data centers that we fully or partially controlled. We are comfortable with our place in the world, and the things we build. Of course, we are also being asked to do more with less and this security posture is simple and less expensive than the alternative.

Starting around this time Stuxnet started to change. Security went from poorly understood discussions, accepted fees, and backrooms to discussions with interest in the boardroom and at shareholder meetings. Overnight the executive level went from not knowing cybersecurity to being knowledgeable about a company’s disposition in cyberspace. Attacks escalated, and major news organizations began reporting cyber incidents. The laws were changed to reflect this new world, and more to come. How do we handle this new world and all its requirements?

Zero Trust is a change in security. Zero Trust is a fundamental change in cybersecurity strategy. Whereas previously we focused on boundary control and building all of our security around inside and outside ideas, now we need to focus on every component and every person who has the potential to be a Trojan Horse. It may look legit enough to cross the line, but in reality it can host threat actors waiting to strike. Better yet, your applications and infrastructure can become a ticking time bomb waiting to explode, where the code used in the tool is exploited in “Supply Chain” attacks. Where through no fault of the organization they are vulnerable to attack. Zero Trust says – “You are only trusted to perform one action, once, in one place, and when that changes you are no longer trusted and must be validated again, regardless of your location, application, user ID, etc”. Zero Trust is exactly what it says, “I don’t trust anything, so I validate everything”.

That’s neat theory, but what does that mean in practice? We need to limit users to the absolute minimum required access to networks that have a strict set of ACLs, to applications that can only communicate with the things they have to communicate with, to devices that are segmented until they think they are alone on a private network, while being quite dynamic to have the scope of their trust change as the organization evolves, and still allow the management of these devices. The overall goal is to reduce the “blast radius” of any possible compromise within the organization, as this is not an “if” but a “when” question for cyberattacks.

So if my philosophy changes from “I know it and believe it” to “I don’t believe that’s what it says” then what can I do? Especially when I consider I’m not getting 5x the budget to handle 5x more complexity. I looked at the market. I’m well! Every security vendor now tells me how they accomplished Zero Trust with shiny new tools, platforms, services, stuff. So I asked a question. It seems to me they just really got it done according to marketing. Why? Because Zero Trust is hard. It is very difficult. Complex, requires organization-wide change, not just tools, but a full trifecta of people, processes, and technology, and not limited to my technology team, but the entire organization, not one region, but globally. This is a lot.

All is not lost, because Zero Trust is not a fixed result, it is a philosophy. This is not a tool, or an audit, or a process. I can’t buy it, nor can I certify it (no matter what the person selling the stuff says). So it shows hope. Besides, I always remember the truth; “Perfection is the enemy of Progress”, and I realized I could move the needle.

So I take a pragmatic view of security, through the lens of Zero Trust. I don’t aim to do everything at once. Instead, I look at what I can do and where I have existing skills. How is my organization designed, do I hub and talk where do I have a core organization with shared services and most independent business units? Maybe I have a network where BUs are distributed to where we are organically integrated and staffed as we go through M&A over the years, maybe we are fully integrated as an organization with one standard for all. Maybe it’s not one of them.

I started by considering my abilities and mapping out my current state. Where is my organization on the NIST security framework model? Where do I think I can get with my current staff? Who do I have in my partner organization who can help me? Once I know where I am, I then shift my focus.

One fork is on a low hanging fruit that can be completed in the short term. Can I add some firewall rules to further restrict VLANs that don’t need to communicate? Can I audit user accounts and make sure we’re following best practices for organization and permission assignments? Does MFA exist, and can I extend its use, or implement it for some critical systems?

My second fork is to develop a talent ecosystem, 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 became more integrated and I sought, and gained relationships with, new partners who filled my void. My team reorganized to support security by design AND practice. And I developed a training plan that includes a similar focus on what we can do today (lunch and partner learning) with a long-term strategy (which might improve the skills of my employees with certification).

This is the phase where we start to look at the tool rationalization project. What my existing tools don’t do as required in the new Zero Trust world, this will likely need to be replaced in the near future. What tool do I have that works pretty well, but needs to be replaced upon termination of the contract. What tools do I have that we will keep.

Finally where do we see the big, hard stones placed in our path? This is given that our network will require some redesign, and will need to be designed with automation in mind, as rules, ACLs, and VLANs will be much more complex than before, and changes will occur at a much faster pace than before. . Automation is the only way this will work. The best part is that modern automation is self-documenting.

The great thing about being pragmatic is that we can make positive changes, have long-term goals that we can align with, focus on what we can change, while growing for the future. All wrapped up in layers of communication for executive leadership, and developing strategy for the board. Eat the elephant one bite at a time.

Leave a Reply

Your email address will not be published. Required fields are marked *