Exploring Zero Trust
“Zero Trust” – this is a phrase that has exploded in recent years partially due to the uptick in the notoriety of information breaches. It has come to be interpreted as a lot of things, depending on who you’re talking to (and unfortunately, in more cases than not, what they also happen to be selling). Some of the circulating information and products are new to the market and fit nicely under the Zero Trust umbrella, but also be aware that there is a significant amount of marketing spin and repackaging of existing technologies to capitalize on the hype train. This isn’t inherently bad by itself but be sure that you perform the due diligence to fully understand your organization’s security gaps before paying for a front-to-back Zero Trust solution when a better move could be to augment your existing security posture with what you may already own.
A brief history for geeks
As the saying goes, there is nothing new under the sun… Doing some research before writing this article, I found that the roots of Zero Trust can be traced all the way back to the summer of 2003 when a loosely affiliated group of CISOs in the UK came together and formed The Jericho Forum – to help solve the problem of (what they referred to at the time as) “de-perimeterisation”. I discovered that many of the pillars that are relied upon in the Information Security industry today (Identity, Entitlement, Access Management, etc) have DNA that can be traced back to this forum.
In 2010, an analyst at Forrester is credited to have first coined the term “Zero Trust” to encapsulate many of the concepts developed by the Jericho Forum and defined them in an objective way that could easily security providers. The term caught on, and the rest, as they say, is history. Gartner (CARTA) and Google (BeyondCorp) now have also created and currently maintain similar frameworks with a few differences, although I won’t be covering those today.
What is Zero Trust?
The core of Zero Trust is the concept that the traditional fortress wall between internal (and trusted) and external (untrusted) is no longer viable in the current multi-cloud infrastructure and BYOD (Bring Your Own Device) landscape. For example:
A “Traditional” perimeter usually consists of things like:
- On-Site/VPN Users
A perimeter today can also now also include:
- Remote Employees
- Cloud Infrastructure
- Cloud Applications
- Personal Mobile Devices (BYOD)
This presents a significant issue with the concept of a “trusted device/network/user” that has been the standard procedure for decades.
Trust is an integral part of human nature. Our natural inclination is to either trust our senses or our experience. Since we cannot always touch or see every device or transaction in our organization, how do we establish trust in this context? Our experience in the past would tell us that if we can just establish a baseline that we deem “trusted”, everything else will work within that boundary.
Unfortunately, this has proven to be an unachievable goal. Lost or stolen devices, compromised credentials, and a host of other challenges has presented the need for a new way of establishing trust. So if we can’t natively trust our devices, users, endpoints, network… what do we do?
So is Zero Trust just a complete lack of trust as the name would imply?
In short, no. There are still areas where trust is critical, but the concept itself reaffirms that I need to be asking questions like:
- Is this user who they say they are?
- Do they have access to only what’s required for their role?
- Is the device they’re using secured?
- Even if that device is secured, is it trusted to access my data?
To allow me to answer yes to those questions, traditional wisdom would say that I just need tools and functionality to enforce those security requirements. Unfortunately, we must assume that a breach is not a matter of “if”, but “when”. As such, it’s equally or even more important that I have visibility to see when I am breached and subsequent policies, controls, and automation to shut it down.
To fully secure my environment with a Zero Trust model, I need to be able to perform the following steps prior to allowing a user to access data:
Establish trust into the identity of my user (Multi-Factor Auth)
- Creating a login system that relies on more than just a password is critical. Password spray attacks using information stolen in other breaches is at an all-time high.
Have visibility and reporting on device health
- Device software vulnerabilities are prevalent with the thousands of combinations of hardware and operating systems. Make sure that you can verify if a mobile device is up-to-date, if it has been compromised via rooting/jailbreaking, if a laptop is behind in OS security patches, etc
Establish a level of trust in the device they are using
- Prevent data access on a device that does not meet the security requirements I have defined.
Enforce contextual policies (user role, device location, device type, etc)
- Verify that the user can only get to the essential data for their role, and even prevent that data from being stored on the device if I dictate, also making sure that the device and/or location for that user isn’t suspicious. If it is, flag for additional verification or prevent access entirely.
Securely provide access to my apps and data
- Seamlessly provide an experience for my user that allows them to be productive without compromising my security posture.
In conclusion, you can see that there are many of these steps that just seem like common sense and “Zero Trust” is just a fancy name for a lot of functionality I may already own and implement. It’s how I implement these technologies so that they’re complementary to each other, and as invisible to my users as they can be that makes the difference.