Moving from implicit trust to zero trust - why it matters.
July 22, 2019
The basic promise of the early internet was to provide a way for different groups to easily connect and share information.
Early networking concepts gave little or no thought to security as all the connecting parties were known entities. That care-free era had one simple goal: to connect different working groups together. Plug one cable into a switch, have one service connect to another over TCP/IP, all without a need for encryption or explicit authorization.
The modern internet is a different place, far less innocent and carefree, though the core networking primitives in many cases have remained unchanged.
It’s a situation that represents risk, and often trust is simply given or implied.
In this post, learn why the age of implicit trust is coming to an end, what zero trust is all about and why it matters.
The unfortunate reality of the modern internet is that attacks can come from any place at any time.
The first era of network security was all about the firewall, with a hardware device that was intended to act as a barrier against the external world. Next-Generation Firewall (NGFW) technology goes a step further looking at applications for packet inspection in an attempt to limit known bad items from getting into a network.
But what happens inside a network? Inside the perimeter of the network firewall?
With modern networks and organizations relying on mobile and cloud technology alongside remote workers, the concept of a perimeter itself is largely no longer valid as the perimeter is always changing.
Simply attempting to block bad actors at some arbitrary point of entry is no longer an effective approach for security, or ensuring trust within a network.
In a flat network, everyone and everything can have access to each other. That’s not a model that works, which is why various trust, identity and access control mechanisms have been developed and deployed.
Trust is all about giving an identified user or entity (where an entity can be a service account, API or remote procedure call), access to a resource or service as well as potentially providing authorization to perform various actions.
Granting known users and entities trust has its own set of challenges. In many environments, Active Directory or another similar type of LDAP based system is used to setup users and entities with access authorizations. In essence, what is happening is that organizations are trusting that the directory solution in place is a source of truth about who and what is trustworthy.
Directory systems can easily be misconfigured and there is no shortage of known attacks that can be used to elevate and bypass privilege restrictions.
Many directories and user identity systems are simply username and password-based. Among the most common forms of attack, today is one known as credential stuffing. With the endless barrage of breached websites and databases, there is a massive volume of user credentials available to would-be hackers. The unfortunate reality is that some of those credentials will still work on the original sites they were stolen from. Even worse though, is that many users re-use credentials across sites. With credential stuffing, attackers ‘stuff’ credentials from other breaches into new attacks, in an attempt to gain access.
The reality is that even if a given network service or application has granted trust to a specific known user or entity, it’s possible and even likely that at some point that trust will be misplaced – either through misconfiguration, malicious attack or otherwise.
In a world where trust mechanisms cannot be trusted, the concept known as Zero Trust has emerged.
The basic idea behind zero trust is the assumption that all devices and entities are untrustworthy until proven otherwise.
Going a step further, even after a user or entity is proven to be trustworthy once, zero trust models do not by default trust the same user or entity the next time they are seen by the system.
Zero trust is an active approach and model that integrates continuous analysis and verification of trust, in an effort to help ensure that assets on a network are not doing anything malicious.
Zero trust isn’t a meaningless buzzword.
Trust in the zero-trust model is never taken for granted, but is based on observation and regular authentication to help limit risks.
Zero trust is sometimes linked with another concept known as least privilege, though the two are not always directly technically integrated. In a least-privilege model, users and entities are only given the least privilege that is required in order to perform the function that is needed.
Least privilege models exist to deal with another challenging issue in many networks and cloud deployments today – that is the issue of over-provisioned accounts.
Often accounts are given far more access than what is needed, which increases risk and presents a larger attack surface. With least privilege, there is still trust – but what is happening is the degree of trust is very specific.
Zero trust models, start with the premise that nothing should be trusted, but when properly configured can still be set up to only grant trust on a least privilege basis, further minimizing the risk profile.
The concept of micro-segmentation, slicing up a network into very specific segments is also often aligned with least privilege and zero trust models.
Instead of a flat network where all nodes can reach each other, micro-segmentation provides isolated network nodes for different services and areas, limiting the privileges of given resources to only a specific area of the network.
The zero trust model doesn’t rely on a simple username and password, or a token in order to grant access. Instead, zero trust relies on contextual data about the device, the environment and the request, in order to make a decision.
One of the most well-known examples of a zero trust framework is Google’s BeyondCorp model which is used within Google for its own employees and services.
The challenge for Google was with its large distributed workforce the idea of simply granting access to resources to internal employees was anything but simple. Using a VPN (Virtual Private Network) approach on its own didn’t scale or provide the needed security assurances.
In 2011, Google defined its BeyondCorp vision, “To have every Google employee work successfully from untrusted networks without the use of a VPN.”
With BeyondCorp zero trust model access decisions are based on continuously collected data about the user, their job and the security status of the devices seeking access. It’s a context-aware approach that has helped to keep Google and its’ employees safe.
Zero trust isn’t just the domain of hyperscale internet companies, it’s also an approach that can work for organizations of all sizes.
There are a few key principles and models that help to enable zero trust model. One of them is the Software Defined Perimeter (SDP) which originally began development under the auspices of the Cloud Security Alliance (CSA), back in 2013.
In the SDP model, there is a controller which defines the policies by which clients can connect and get access to different resources. The gateway component helps to direct traffic to the right data center or cloud resources. Finally, devices and services make use of an SDP client which connects and requests access from the controller to resources.
Along the way, device health checks, user profiling including behavioral data and multi-factor authentication mechanisms are engaged to validate security posture.
To learn more about how zero trust can help your organization:
July 24, 2019
Zero trust helps organizations reduce the attack surface and mitigate risks, but it is not without its complexity and implementation challenges.
September 02, 2019
Part II of our two-part series on implementing zero trust takes a deeper dive into what organizations should consider, with a checklist to help you evaluated various zero-trust solutions
IT has a reputation of always saying "no". Black Hat 2019 challenged attendees and innovators to turn IT into the "department of yes".