At Ignite, I had the privilege of presenting “Zero Hype” with my colleagues Nupur Goyal (@nupur_11) who leads our Product Marketing, and Yinon Costica (@c0stica) who directs program management for Azure Security Center, Microsoft Cloud App Security, and Azure ATP for Users, among others. Concepts like Zero Trust are useful only if they are concrete. Despite years of the term being batted around, consistency and clarity on the term is still very poor among the folks I talk to. So, when Nupur asked me to do a talk on Zero Trust, I suggested we do everything we could to clear away the fog on the concept. I hope we achieved that. For those of you who weren’t able to see the session, I wanted to capture the essence here.
Zero Trust, conceptually, asserts that traditional security models based on “the walled garden” are outdated, and that security models should assume that all requests should be treated as though they originate from an uncontrolled (external or compromised) network. Whether you think of this as “assuming breach” and operating as though the enemy is inside your perimeter or you think of this as operating in a perimeter-less environment, it’s all about operating as though you are in a pervasive threat environment. This is a simple concept, we don’t need to complicate it or dress it up because it has powerful implications. Let’s dig in a bit.
In 1990, I started a company that was (among other things) helping people build out networks for their offices. Fundamentally, there was very little in the way of connectivity between these networks. If you had two offices, you used a Wide Area Network – a leased line – to get between them. In this world, you could very safely assume that any access to any resource came from within a building you owned, from a machine you owned, by someone you employed. As a result of these assumptions, file shares were wide open, apps were accessible by anyone with a username/password combo, and almost all of the companies I worked with centered their strategy on “we trust our employees.” Yes, there were outliers, but even advanced security wasn’t very advanced then, and was centered more on building access than network access.
Over the next few years, with the advent of better modem speeds and cheaper PCs, telecommuting became more popular and VPNs (that you dialed in to, remember?) became a thing. By 1994, the Internet was gaining broad traction in academia and corporations were starting to forego leased lines in favor of public infrastructure. Suddenly, all those private networks were connected to the big world outside. Firewall companies took off, trying to keep all the unexpected or malicious traffic out. The walled garden – a network defended at the perimeter, but essentially open once inside – was born. I think of this as us “defending our assumptions.”
The years that followed brought dizzying changes – Netscape became big in 1995; Microsoft went “Internet first” in December of that year. Salesforce launched their SaaS offering in 2000. Starbucks put WiFi in all their stores in 2002. The iPhone Launched in 2007. Office 365 launched in 2011. With each of these changes, the assumptions we’d been making about access to resources – that they were from our network, on devices we owned, to apps we’d deployed, by people we worked with – became less and less valid. IT today looks nothing like the world the walled garden model was intended for. None of the assumptions are valid anymore – attackers have known this for years.
Fortunately, there were thought leaders who saw these changes happening and reacted. In 2003 the Jericho Foundation introduced the concept of de-perimiterization. In 2010 John Kindervag at Forrester wrote “Build Security Into Your Network’s DNA: The Zero Trust Network Architecture” and the term Zero-Trust was born. In 2013, Microsoft coined “Identity Driven Security” and introduced the Enterprise Mobility Suite (EMS) to address the core security and compliance needs of enterprises – Secure Access, Secure Devices, and Secure Data. That same year, Google implemented a no-network trust model in “BeyondCorp”, providing a “demonstrator” which inspired tremendous interest.
This interest fueled a massive surge in hype. By this year’s RSA, virtually all booths were touting their Zero Trust-ness. One analyst told me “the age of Zero-Trust-washing has arrived.” Smart people simultaneously realized there was something there they should be paying attention to, and were completely unable to find a consistent, crisp definition. When I ask folks to raise their hands if they are confident in what Zero Trust means I’m lucky if 5% of folks are willing to venture a guess.
But the essence of Zero Trust remains simple – security models which assume safety based on network location are inadequate. Modern security models must assume all access requests come from uncontrolled networks.
I sometimes use the slang term “FUD” – Fear, Uncertainty, and Doubt. I want to attempt to de-FUD Zero Trust by blowing away some of the fog surrounding the term. Here’s what Zero Trust isn’t:
I believe the most useful thing about Zero Trust is the mindset it creates. The mindset to adopt is that you are operating in a pervasive threat environment. An environment that demands that you continuously assess and re-assess the viability of your security strategy. Here are some key behaviors you might exhibit if you accept that you are operating in a pervasive threat environment:
We can distill all this down to three key principles:
We have seen that successful adoption of a Zero Trust approach benefits from some critical elements. We pulled this together conceptually in a conceptual architecture, pictured below.
The critical elements are as follows. First, the key resources:
Then, the key tools to tie it together:
Here are some next steps and related on demand sessions to help you go deeper on how to get started today:
I really hope this blog has helped make Zero Trust clear and actionable for you – but if you have questions or feedback, please reach out to me on Twitter at @alex_t_weinert
Stay safe out there!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.