The Earliest Webpage, and the Latest Zero-Trust
It is Tim Berners-Lee’s fault. No, really. The first website went live in August 1991. When the web began twenty-eight years ago, it was wide open and without any access control. World readable. And as the web spread, we would double down on that decision. It was a conscious decision, too. Berners-Lee clearly laid out in the original project proposal that the project would not aim to include a sophisticated authorization system. Our starting point was deliberately out of control.
You may wonder, what was a sophisticated authorization system for the 1990s? Those were early days. Mostly, it was system-level permissions. The first paper on Role Based Access Control (RBAC) would be published in 1992. RBAC was a solution to scaling beyond setting file permissions. Define the work performed by a given role in an organization. Identify the access to technology needed for that work. Then setup the permissions such that people in those roles have what they need to do their jobs. It’s a seemingly simple concept, but frankly, a month doesn’t go by without me having discussion with CISOs on how best to do RBAC at scale.
Tim Berners-Lee was familiar with role-based access. His early work on ENQUIRE, the predecessor to the web, was setup on a departmental level. If you were in one department, you could view that department’s information on ENQUIRE. Adoption wasn’t all that great. Turns out, people don’t like security.
The same thing that trips up enterprises with RBAC tripped up CERN with ENQUIRE: people work across lines in wonderfully messy and unpredictable ways. The web had to be accessible to everyone, Berners-Lee realized, solving the adoption problem while creating the security problem.
With zero-trust, we’re working to solve this problem. But to look at it, zero-trust is a number of things we’ve done already. De-perimeterization is about moving thing over the internet and over the web. Sophisticated authentication and authorization is about using roles and permissions to ensure people have the access they need, when they need it. We’ve done both for decades. But the been-there-done-that mindset misses a crucial piece that zero-trust brings.
Suppose the security perimeter is where access control decisions are made and enforced. In traditional RBAC, we made those decisions when a person joined a role. We enforced those decisions by file-system ACLs and firewall ACLs. We relied upon the person remaining trustworthy the next day, the next month, even the next year. This is one form of excessive trust which zero-trust approaches seek to minimize. Is the person still trustworthy? Let’s look at user behavior, device hygiene, indicators of compromise, and make a judgement call. Let’s ensure that untrusted people are identified and access restricted, while trusted people continue working without friction. Let’s do this automatically and continuously. That’s the evolutionary step we’re taking with zero-trust.
It is not exactly Tim Berners-Lee’s fault. Not really. True, authorization was never a goal. But look back at the original project proposal and you also won’t see applications mentioned. No one envisioned the web would be used for financial transactions, medical records, or manufacturing resource planning. The world took WWW and the world ran with it. The security industry has been running behind wrapping controls around the web ever since. By leveraging where we’ve been with RBAC and where we’re going with zero-trust, security teams can finally pull ahead with sophisticated authorization. Let’s roll.
Zero Trust: Moving Beyond the Perimeter (Part 1)
Read this primer on Google’s BeyondCorp model, a robust framework developed to ensure “zero-trust” - to assume that no traffic within an enterprise’s network is any more trustworthy than traffic coming from outside the network.Free Guide