The last couple of years have seen the zero trust concept gain fresh traction. What has driven this new interest, and is this the way that security networks should be built now? Dan Raywood investigates.
Back in September 2010, Forrester researcher John Kindervag published the first of two whitepapers on the concept of the zero trust network. A decade later, the zero trust model has flourished to create concepts for companies to adopt and implement, along with generating a raft of products and deployments based on Kindervag’s original idea.
In the Beginning
The November 2010 whitepaper claimed that zero trust was needed as there was a fundamental problem with trust in information security, and it was the trust model that needed to be changed.
“By changing our trust model we can change our networks and make them easier to build and maintain; we can even make them more efficient, more compliant and more cost-effective,” Kindervag said at the time.
As a result, zero trust has become one of the de facto ways that cybersecurity can operate, based on its three core concepts: 1) there is no longer a trusted and untrusted interface on our security devices; 2) there is no longer a trusted and untrusted network; and 3) there are no longer trusted and untrusted users.
Ultimately, zero trust mandates that information security professionals treat all network traffic as untrusted. This helps with securing concepts like BYOD and IoT, as well as detecting attackers inside your network – if you assume everything and everyone is bad, and that there is no perimeter, you’re making a start on creating a more secure network infrastructure.
Kindervag originally claimed that network professionals “built yesterday’s networks at the edge, with the internet connection, and then built inward” with the starting point of the router and routing protocols. The approach requires starting with system resources and data repositories that need to be protected, as well as the places where compliance is required, and a network is built out from that point.
Kindervag recommended starting with protecting data first and figuring out how to do the networking second.
It is now eight years since the whitepaper was published and 10 since the zero trust idea was conceived, but more recently the concept has been cited as a way of working securely. Speaking to Infosecurity in 2018, Kindervag explains that the zero trust topic has become a ‘buzz word’ term for conferences and vendors.
So is he happy that it has become so popular? “It is gratifying as people said I was insane and some vendors told Forrester to kill it, but it was great for me, and great to have some adversarial reaction and to be considered at multiple levels, and in a unique way it has been a blessing.”
The basic foundation of zero trust is to continue to verify a user’s identity and authenticate access at every resource
Industry Acceptance
The concept has led to several vendors offering strategies and tools to aid zero trust. One is Duo Security, who launched the concept of Duo Beyond to follow Google’s BeyondCorp and Intel’s Beyond the Edge.
Dave Lewis, global advisory CISO for Duo Security at Cisco, tells Infosecurity that he prefers to call it “unified access security,” and says that while he feels Kindervag did a great service in coming up with the term zero trust as it started driving conversations, all it did was confirm “what we should have been doing all along – network segmentation, asset inventory, user management. Every one of these pieces of the puzzle should have been there all along,” he adds.
Lewis says that the conversation is starting to permeate, and is being accepted more now as companies realize that they need to be having discussions around the concept.
Speaking to Infosecurity, Corey Williams, Centrify’s senior director of product marketing, points out that zero trust has been driving conversations over the last year, which shows that “people were looking or grasping for some sort of model to look at.”
Williams comments that the principle of zero trust has not changed, but the guiding principle has. “The basic foundation of zero trust is to continue to verify a user’s identity and authenticate access at every resource,” he says. “The vision is of moving the network closer to the resource and having a limited amount of access to resources.”
However, this drive towards it being about access control irked Kindervag, who argues the concept was designed to be a strategy and to be able to work with business leaders to “solve serious systemic issues that security refused to change.” He stresses the need to also include packet inspection and logging of all traffic, while access control was only on a “need to know” basis.
The Fallow Period for Zero Trust
So why was the concept not really considered as a way of working between its introduction and its resurgence in 2016?
Rodney Joffe, SVP and fellow at Neustar, says that when Kindervag developed the concept in 2010, zero trust “probably sounded like yet another buzz phrase to most CIO/CISOs.” He adds that if they had looked at what was being suggested, they would have agreed with it.
“In the interim, practitioners have recognized that breaches are inevitable, and now they are able to use John’s phrase to describe what they now realize is a must.”
Lewis claims that the reason for the silence around zero trust was “because there was an increase in data breaches which got exponentially larger and we realized we had to do something.” On the other hand Williams believes that the principle of zero trust changed “as so much has gone off the network between mobility and the move to cloud and SaaS.” The concept of zero trust therefore needed to evolve, he adds, and that is why the access management conversation began.
That period saw breaches including Target, where a zero trust network could have prevented the supply chain attack, and Uber, where attackers were able to gain access to servers using credentials collected from a Github account.
Kindervag says that the idea of zero trust is that it is designed to stop breaches, but it is actually about protecting “data apps assets services” and by doing that, “it makes it extraordinarily difficult for data to be exfiltrated and easy for authorized people to analyze in an appropriate way.”
It makes it extraordinarily difficult for data to be exfiltrated and easy for authorized people to analyze in an appropriate way
Just Like Starting Over?
Lewis explains that enabling zero trust doesn’t require networks being built from scratch or even being rebuilt, “as we have all the moving pieces, it’s just about implementing them correctly.” He adds that where those pieces are missing, that’s where tools like multi-factor authentication come in.
Lewis says that the focus has to be on realizing what you’re trying to solve, as no vendor will say “these are your requirements” – you have to identify the requirements of what you are trying to address.
Dinis Cruz is CISO of Photobox. He believes that the best way to adopt zero trust is to start the project small and scale up. “It is not one of those things where you say ‘let’s pick five examples’ as we moved to cloud platforms and explored further, but you want access from everywhere so build an isolated environment and start with one and move to others.”
He likens this to an internal development process, where forms have to be signed in order to gain access, and changes are made in an isolated environment.
Cruz points to the need for better visibility, as one way to create zero trust is to understand what is happening in your environment. “If one app is being attacked I should be able to build a sandbox around it, and why should it talk to other things and allow untrusted access? If we have visibility of that behavior to know what is going on, then that becomes an easy process.”
Ultimately, Kindervag says, zero trust is “still at the baby stages” and in his role as field chief technology officer at Palo Alto Networks he is still trying to get people to take on the idea, as once they grasp it “the idea sells itself.”
Kindervag had previously claimed that zero trust is something “you augment your existing network with, and that you do in incremental stages” and while zero trust is one way of working and enabling access, it is not perfect and not suitable for everyone. Yet in these times of concern about remote access from untrusted and unverified sources, this may be one way of solving a security woe.
Zero Trust at Google, by Max Saltonstall, Technical Director, Information Technology, Office of the CTO
Passwords are terrible. Scratch that: we’re terrible at remembering them, phishing them is easier and password theft and reuse are both on the rise. At Google, we emphasize security keys as a core part of our trust calculation, and that strong authentication has become the core of our zero trust system, BeyondCorp.
The phrase zero trust gets thrown around a lot; at Google, we mean that we put zero inherent trust in any network. We don’t assume access is trustworthy because it came from inside the office. Instead, each connection needs to earn trust by showing strong authentication, authorization to access the requested resource, and a fully encrypted connection. There are three pillars to this.
Authentication
Access to an internal resource can only be granted if we know who is making the request and to help Googlers prove their identity – everyone gets a set of security keys on their first day at work. Following the FIDO Alliance standards, they do an encrypted handshake with the server to ensure that authentication only occurs with a validated server. Using these keys has reduced the success rate of phishing attacks drastically: Google has no reported or confirmed account takeovers since implementing security keys – and we suggest everyone adopts them, especially admins with access to sensitive resources.
In addition to authenticating the person, we want to authenticate the device. Establishing and revoking trust from devices complements the user trust element – if a device is compromised, we can detect that with our inventory metadata tools and revoke trust quickly, flagging that device for remediation.
Authorization
Now that we know who’s asking for a resource, and what device they are asking from, we can test to see if they are actually allowed access. All traffic to internal services flows through a reverse proxy, and the proxy prevents the request from even reaching the back-end if that person does not have the right permissions. We can authorize access according to group memberships, job role, location, employee type and numerous other factors.
Encryption
With a trusted device, a trusted login and a check for the right permissions, we need to secure our connection. By requiring encryption we mitigate man-in-the-middle attacks or other situations where an unknown listener is on our communication channel. Our reverse proxy terminates TLS to understand the request, re-encrypting as necessary to communicate with other internal services as it routes the request properly.
Outcome
The rollout of BeyondCorp, starting in 2010, was not without its challenges, but the ultimate outcome is that our workforce is more mobile, collaborative – and safer – than ever.