How Zero Trust Inverts the Traditional Security Paradigm

Government agencies face increasingly complex threats from nation-states and independent actors seeking to exploit vulnerabilities. For John Dvorak, Chief Architect at Red Hat, to effectively combat these threats, agencies need strong identity, credential and access management tools. 

Dvorak’s experience is informed by his over 20 years focused on securing public sector networks, both as a government senior executive and as a CIO and CTO at federally-focused systems integrators. Now, at Red Hat, he’s championing the benefits of zero trust.

And luckily, he isn’t alone in his quest to do so. Last May, the Biden administration released Executive Order 14028 on improving the nation’s cybersecurity. At the heart of it is the call for agencies to strengthen their cybersecurity through actions like improving data encryption and the adoption of zero trust architectures. For Dvorak, cyber threats have outpaced legacy security architectures and adopting a zero trust mindset is mission No. 1 for security and identity architects.

The following interview was conducted by GovExec’s Studio 2G via phone with Dvorak. The interview has been edited for length and clarity.

S2G: How has the global threat landscape evolved over the last 2-3 years? What do agencies need to know about the shift to zero trust?

Dvorak: Over the last 2-3 years, the broad availability of tools and managed services that have appeared, like hacking-as-a-service, ransomware-as-a-service and crimeware-as-a-service, have provided an easy onramp for cybercriminals. Cybercriminals no longer need training or knowledge about computer exploitation. They don’t need to be hackers by trade anymore. Criminals have tool sets that can do a lot of work for them. They can tap into managed services that provide payment processing and technical support for criminal actors. So, if you have a problem making your bitcoin payment, there’s a number you can call. These are enterprises that have been set up around hacking and exploiting, and they’re highly monetized operations.

That’s not to say that you’re no longer dealing with traditional, highly sophisticated hackers. We continue to have state actors that continue to improve the sophistication of their attacks and are often using slow burn, indirect techniques to infiltrate. For example, some state actors have been found to inject malicious code into software supply chains and exploit the implicit trust between systems and people.

Zero trust forces us to think about implicit trust and the security enforcement points within our existing systems. Whether it’s networks or application programming interfaces, we have to think about how to stop these actors from exploiting the weaknesses in those systems. 

S2G: John Kindervag famously said networks are like “M&Ms.” What does this analogy mean and how does zero trust flip the script on this type of security design?

Dvorak: The analogy refers to the soft center of an M&M. You’ve got this hard shell, and inside, it’s just wonderful chocolate. There’s no other resistance after your crack the shell. Another analogy we often use is the castle and moat design, which I think is a little bit easier to build on. First off, you’ve got the security perimeter, which is the thick wall around your town, then inside that wall, you have the gates to get into the environment. The gates are the firewall rules and the intrusion detection and intrusion prevention systems validating users, and once you get inside, you can "go wherever you want." Everything inside the walls is inherently trusted to a greater degree.

We’ve known this is poor design for at least 25 years. The Jericho Forum that got together in the mid-2000s explained why this was a bad design. For the most part, we’ve tried to mitigate this with defense-in-depth and tripwires that detect bad behavior, but we’ve failed to break free of the castle-and-moat design. For the most part, most enterprises still believe that if users connect inside the firewall, they’re more trusted. That’s a bad idea — it’s reliant on this idea that the device or IP address you’re connecting from is trusted. It doesn’t do anything to validate that person or system that’s asking for access.

With zero trust, just because you’re inside the wall doesn’t mean I have any greater trust for you. Inside John Kindervags’ M&M are more and more little shells, and around each transaction is another shell; it’s not just this nice, yummy chocolate anymore.

S2G: Could you provide a good example of zero trust architecture within the public sector? 

Dvorak: The Department of Defense and the intelligence community are great models to follow regarding zero trust. They practice many of the tenets from zero trust. In fact, for years, when the term zero trust was just a concept, the intelligence community and the DoD were already starting to implement some of the principles that would become zero trust.

In the intelligence community, there was this idea, “Tag the data, tag the people,” as one intelligence community leader said. We then used what is called attributes to label data and people, which allowed us to say that for you to see within that one box, to see that one value, you have to meet specific criteria. I’m going to compare your attributes to the attributes of that piece of data, and I’m going to say you can have access to only under certain conditions.

It’s a great example because to protect assets in the intelligence community, you have to identify the attributes around all assets. How secure should they be? Who should have access and under what conditions? Once you answer those questions, you can build models to restrict access.

S2G: What are the challenges of implementing a zero trust architecture? How can government agencies overcome these challenges?

Dvorak: There’s a lot of what we call friction within legacy IT and business systems that need to modernize. To get it done at the level we need, in many cases, requires rebuilding and redeploying new systems. The problem is that there’s a lack of business or budgetary capacity. There’s enough money to keep systems going but not to replace them. In some of these systems, agencies use technology like ADABAS that’s not even taught in school anymore.

Developers aren’t off the hook, either. They have these older systems built off proofs of concept. Initially, they wanted to get these systems out the door. They weren’t designed with security in mind. We’ve seen this happen many times, where proofs of concept become production systems, and then you have to go back and rebuild from scratch because they didn’t choose an adequate security architecture.

Another big impediment is the nontechnical challenges that make zero trust a daunting task. Zero trust is not just the chief information security officer’s job or IT guy’s job. There are business people who have to be involved, and there are all of these other individuals who have to get trained on understanding the problem and the risks involved in not doing anything. There’s this tension between what we need them to know, the time it takes to get there, and their own priorities.

S2G: How is Red Hat supporting cybersecurity mandates like the Cybersecurity Executive Order?

Dvorak: Our mission at Red Hat is to provide enterprise-ready, open-source software. And for us, enterprise-ready means that we take seriously the cybersecurity of our products, our internal processes and the software supply chain. We’re always taking the best advice and practices from government, industry and cybersecurity experts. We then incorporate those into how we build and deliver software.

Since the founding of Red Hat, we’ve had early and continued commitment to other government standards along the way — like the government’s Federal Information Processing Standards , Common Criteria, and Security Technical Implementation Guides . We’ve been proponents of these standards, supporting their development and leveraging co-developed and managed solutions like Security-Enhanced Linux (SELinux) that was originally developed by the National Security Agency.

As the cybersecurity environment continues to evolve and as threats multiply, we’re working with leaders in the open-source community, like the Linux Foundation and the Cloud Native Computing Foundation, and the software industry to implement practical and helpful tools to achieve the goals expressed in the executive order.

S2G: What advice would you give to public sector CISOs looking to implement zero trust?

Dvorak: Start somewhere. Identify the protect surface of your environment and determine what is most important data to safeguard. Sure, there are things you can quickly implement to help you along the journey, there are things you can do on the network like improved microsegmentation, but you need to get somebody started on the data problem.

You’ve got to be able to identify who owns data or who is responsible for determining who has access to it . . . don’t leave it to the IT guys to do on their own. For a CISO, you can’t secure what you don’t understand, so getting people to help you recognize what’s important and how you’re going to protect it is crucial. It may take months to figure out who owns the data in the organization and get an agreement on it before you start making determinations of the value and access requirements.

I would also say be careful of the shiny object. The salesperson who comes to you and tells you to buy this one piece of software and that it will solve all things zero-trust — don’t trust them. Zero Trust requires architects to think about solutions that involve multiple products and process changes. Zero trust is just as technical as it is cultural, and it takes time.