Zero-trust methodology's popularity a double-edged sword
The authors of 'Zero Trust Networks' discuss how the zero-trust methodology's popularity produces both vendor hype and renewed attention to critical areas of security weakness.
Zero trust's popularity has given way to an enormous variety of products and services. This can unfortunately detract from the methodology's original appeal as a threat model equipped to handle emerging threats, changing IT environments and the growth of remote working.
"Zero trust is not a destination, despite how many vendors may spin it," said Evan Gilman, engineer at VMware and co-author of Zero Trust Networks, published by O'Reilly. "That spin can undermine what we're trying to accomplish, which is a change of processes and philosophy around security."
Zero trust is an alternative to traditional perimeter security, which became untenable due to insider threats and the widespread transitions to hybrid environments and remote work. It's not a matter of if, but when a malicious actor gets beyond the perimeter -- and organizations need to anticipate that.
Most high-profile attacks start with someone gaining access into the network and then persisting and rooting around to find the next move, said co-author Doug Barth, site reliability engineer at Stripe. Such attacks point to why organizations need to adopt zero trust instead of a perimeter strategy, he said.
Here, Gilman and Barth draw on their backgrounds in engineering OSes and network security to discuss why zero trust is suited for today's varied threat landscape and how security awareness can benefit from its adoption.
Editor's note: This transcript has been edited for length and clarity.
What characteristics determine an organization's zero-trust readiness?
Doug Barth: The first aspect of zero-trust readiness is the culture. Board members and employees across all areas of the organization need to understand how security impacts the business. Once the cultural aspect is in place you need to determine the process for enumerating your network and managing it over time. In my work, I'm watching an organization put up security control systems -- even behind traditional network perimeter-type patterns -- but with an eye toward the future. Eventually, they may take away the traditional VPN approach and get to the internet-facing tech conductivity.
What aspects of today's enterprise or cyberthreat landscape make the zero-trust network approach so critical?
Evan Gilman: There are three concrete changes to the landscape over the last five to 10 years that pushed us in the direction of zero trust. The first is remote work, which changed where and how people connect. The second is bring your own device [BYOD]. Organizations have historically built perimeter defenses with tight security controls, but BYOD devices don't enjoy those protections that have been meticulously built up. The third change is data center infrastructure, which has been trending toward dynamic environments where things move around quickly. The traditional approaches to perimeter security and network control do not scale very well, so that dynamism is another reason to adopt the zero-trust methodology.
Would you say zero-trust vendor hype is affecting how the methodology is perceived? What precautions would you give to organizations considering products marketed as zero trust?
Gilman: Despite its overuse as a marketing term, zero trust's popularity raises awareness about problems with how we've been approaching security and draws attention to areas of weakness, which is valuable. Its prominence is a double-edged sword, but that shouldn't detract from the substance and philosophy of zero trust.
Barth: My advice is to remember that the most significant aspects of the zero-trust methodology are its increased security hygiene and awareness, as well as its function as a threat model that better reflects reality. People shouldn't lose sight of that. Zero trust is not something you buy from a vendor and slap on top of your existing architecture. The industry needs to level up any assumptions about how they manage security of private -- or supposedly private -- networks. Zero trust declares that they are not as private as you think they are.
Do you think zero trust will become a distinct infosec discipline in the future?
Barth: My crystal ball says it is likely to skew the way, say, DevOps did. For context, the title 'DevOps engineer' relabeled a system administrator who is now cognizant of how larger corporate systems operate together. Originally, DevOps was supposed to mean a developer and operation team coming together. I'd argue zero trust will be similar, where you have security engineers become zero-trust engineers, who think from the perspective of 'How do I drive out trust in the network?' Though the term changes, the job doesn't fundamentally change.
Gilman: Zero-trust security is, over time, just going to be security. There will probably be new titles out there -- zero-trust engineers or zero-trust architect. But, eventually, those will trend back toward security engineer or security architect.
Evan GilmanCo-author of 'Zero Trust Networks'
Zero-trust implementation has been described as an 'additive' process since it increases the amount of security layers or controls. Is there anything that gets subtracted?
Gilman: That's a tricky one. I see different organizations have differing perspectives here. Some people say, 'Yes, you should design for a zero-trust model, but keep the traditional approaches as a second layer defense.' But other organizations we work with might say, 'No, our goal should be to take away this layer once we feel confident because it's causing us more toil and frustration than it is adding any sort of value.'
In terms of subtraction, VPN is certainly one part of that. Large, expensive stateful firewalls placed around the perimeter can be massively simplified. There are so many middleboxes -- things put in the network to do security enforcement and inspection tasks -- which won't go away entirely. But this is an opportunity to reduce spending, maintenance, overhead and feeding of those things that are normally required.
Can implementing the zero-trust methodology be helped by a healthy security culture? What's the best way to foster a security-aware workforce?
Gilman: If you have a workforce that understands the importance of security and is motivated to be doing the right things, security-wise, that will help greatly in implementing zero trust. But creating a security-aware culture is a difficult and time-consuming process. Security awareness training needs to be genuine and interactive and convince the workforce why it is important to the business.
Barth: For organizations to understand your security worldview, they need to know about opportunities, learn and demonstrate proficiency. It's much easier to drive a culture where someone pointing out a security vulnerability is encouraged and celebrated as improving the organization. Figuring out ways to automatically provide feedback and actionable advice to teams can also help. It's critical to meet them at the development stage, as opposed to late in the delivery process, when they're least likely to be receptive to security feedback. Getting involved with them to help build and design in a better way is crucial too.
Any other takeaways for the readers of Zero Trust Networks?
Barth: Some people may associate this book with security and think that only security teams should read it. But I imagine this book being useful to a peer software engineer who doesn't think about security all the time. If that engineer reads this book, they'll have a better understanding of how security practitioners think about these problems, thus getting everyone onto the same page.
About the authors
Evan Gilman is an engineer at VMware with a background in computer networks. With roots in academia and currently working in the public internet, he has been building and operating systems in hostile environments throughout his professional career. An open source contributor, speaker and author, Gilman is passionate about designing systems that strike a balance with the networks they run on.
Doug Barth is a site reliability engineer at Stripe who loves to learn and share his knowledge with others. He has worked on systems of various sizes at companies including Orbitz and PagerDuty. Barth has built and spoken about monitoring systems, mesh networks and failure injection practices.