Zero-Trust Authentication: What It Is and Why It Matters
In the last few years, the nature of online services has changed significantly. It is no longer the case that an online service consists of a small cluster of servers serving content from a single endpoint. Nowadays, even small companies run a multitude of microservices and endpoints for supporting a wide variety of functionality. These microservices often make internal requests between each other, providing a mix of internal and external functionality and utilizing various databases. While these changes have largely improved software development by providing a high level of scalability, there is a downside to this increase in microservices. The wide variety of microservices running within a company has increased the surface available for bad actors to attack and, as the nature of online services have changed, the attacks leveraged against these services have changed as well. Zero Trust Authentication represents the natural evolution of security practices in these new online environments. As software evolves, Zero Trust Authentication will likely become the standard practice for companies whose online services are composed of microservices.
The Traditional Approach To Network Security
To understand what Zero Trust Authentication is we first need to understand the flaws in the current online service defence model, typically known as Castle-and-Moat. Castle-and-Moat refers to a security model where we construct an online service, known as our castle, and build a firewall around it, referred to as the moat. We then build endpoints, in our analogy the drawbridges over our moat, and heavily guard these endpoints against the wrong types of requests. If, for example, we are serving a simple webpage and that webpage makes requests to a database, the Castle-and-Moat approach simply disallows requests from outside the castle that want database access. If you want to view data you need to go through the drawbridge, allowing the service to verify that the request is valid, non-malicious, and made by an authenticated party.
In Castle-and-Moat once requests are past the drawbridge we typically stop checking them for authentication. The assumption is that because we control the services within the castle and because the request has been authenticated before being let across the moat, requests made from inside the castle should be safe. This has some nice benefits. First, it allows us to spin up additional instances of services without worrying about how inter-service requests will be authenticated. Additionally, we can add functionality or endpoints and know that they will have access to all the data they need to run. In general, Castle-and-Moat defence makes it easy for a team to add new features and support existing ones, allowing for a high degree of developmental agility.
Unfortunately, this internal trust between services within the castle walls becomes a liability as the castle expands. If the castle is attacked, and a drawbridge defeated, an attacker will have free rein once inside. Even worse, as services grow many attackers will never have to defeat the drawbridge guards. As development becomes spread between multiple remote teams and as services allow partners and tools more access to their data, the risk of rogue actors operating from within the castle grows as well. The 2020 Cybersecurity Insider Threat Report reports that “68% of organizations confirm insider attacks are becoming more frequent.” Many data leaks start not with an outside hacking group but from a regular employee with access to internal systems. Companies report that “the proliferation of data sharing apps and more data leaving the traditional network perimeter” has led to a situation where “the conditions for successful insider attacks are becoming more difficult to control”. It is clear that Castle-and-Moat defence, while certainly important for stopping some types of attacks, is not sufficient to defend a system against these internal attacks.
Defending Against Internal Attacks With Zero Trust Authentication
To defend against attacks coming from within the castle, we need authentication not just between our castle and the outside world but between the services within the castle. This sort of authentication is known as Zero Trust Authentication. Zero Trust Authentication refers to an authentication scheme where each service verifies that requests it receives are sent from an authenticated source. Rather than trusting all requests implicitly, services maintain internal access control lists that detail which other services or users are allowed to access them. In Zero Trust Authentication services trust no one, to extend the Castle-and-Moat analogy, each service becomes a castle. Every time a service receives a request it uses an internal authentication service to determine if it should process the request or discard it. In turn, these authentication services are typically managed by an authentication manager.
The advantage of such an approach is fairly obvious. Attackers inside the network are now greatly limited in what they can do since microservices will defend themselves even if the attack is coming from within the network. Databases can not be exfiltrated just by gaining access to the network and management services can not be used to bring down services without the proper authentication. In addition, good monitoring can quickly discover internal attacks are taking place. Are services receiving requests from inside the castle and denying them? This is a pretty big red flag that there must be a rogue actor or service somewhere, and knowing that you’ve been compromised is often half the battle in cybersecurity.
Another advantage to zero trust authentication is that integration with third parties becomes much smoother. Does a new partner need access to the database? Grant them access without having to worry about what else they can gain access to while inside the system. A third-party contractor just rolled up a new service? Deploy it with confidence knowing that it will be unable to “go rogue” and attack other pieces of your infrastructure, even if it’s just by accident. Zero trust authentication provides a different type of agility to traditional Castle-and-Moat defence. It makes it easier to trust that there won’t be unexpected interactions or suddenly exposed security holes when making changes or exposing internal features. Hostile, malformed or poorly routed requests can quickly be blocked by the authentication service and service owners can avoid any nasty surprises caused by these types of unexpected requests. In addition, companies can use both Zero Trust Authentication and the Castle-and-Moat defence in conjunction to stop different types of attacks. Castle-and-Moat can still be used to defend against a variety of external attacks such as denial of service while Zero Trust Authentication can be used to defend against internal attacks. This type of combined defence is typically referred to as Defence in Depth.
However, Zero Trust Authentication isn’t all positives. While Zero Trust Authentication certainly improves security and stability it also comes with significant deployment challenges. One of the major advantages of Castle-and-Moat is the ease at which new services can be added to the system and moving to Zero Trust Authentication can make adding new services more difficult. With Zero Trust Authentication every service needs some way to get authentication information for making requests and some way to verify authentication information provided by other services. This means each service must be able to implement the same authentication scheme, regardless of the service’s internal implementation details, and must also provide a way of managing the list of services it is allowed to communicate with. In order to use Zero Trust Authentication, it must be relatively easy to implement authentication, and update these access lists so that new services can be added and can connect to those already running.
Deploying Zero Trust Authentication
Fortunately, modern infrastructure can help us out with these deployment issues. Kubernetes, AWS, and other online service deployment technologies allow us to create bundles of services that are deployed as a single microservice. These bundles consist of a core service as well as a set of supporting services, typically called sidecar services. For Zero Trust Authentication, these supporting services can handle performing the authentication of requests transparently for their main service. One such stack of supporting services is the Envoy – OPA stack. When a service needs to make a request to a remote service it connects to the remote services Envoy instance instead of connecting directly to the remote service. Each Envoy instance is then paired with an OPA service which performs the authentication step. Envoy sends an authentication request to OPA and OPA contains a set of access control policies to describe what services are allowed to access what endpoints. If OPA successfully authenticates the request then Envoy forwards the request to the core service. Once the request has been processed Envoy forwards any response from the core service back to the requesting service. When using the Envoy-OPA stack each service is typically assigned a certificate or JWT token by a central system on startup. These certificates or tokens are then used by OPA for performing authentication. For updating running services policies a management server can either push updated policies to OPA instances or OPA instances can check for updates at predetermined intervals. This way the core service of the microservice bundle does not need to know anything about authentication or manage its own access control lists. The entire stack is relatively simple to deploy, integrates with Kubernetes or AWS well, and provides a strong foundation for a zero trust deployment.
As the deployment and management of online services have changed so have the nature of attacks these services must defend themselves against. Larger attack surfaces, increased numbers of endpoints, and more third-party integrations mean that it is no longer enough to just defend against attackers using the traditional Castle-and-Moat approach. Organizations need to be aware that attacks can also originate from within their own network. Zero Trust Authentication provides security against these types of internal attacks. It consists of a mechanism for authenticating internal requests made between the microservices which make up an online service, preventing bad actors from making unauthorized requests once they are within the network. Besides stopping bad actors it is also useful for managing rogue services, handling accidental misconfiguration, and preventing malformed or poorly routed requests from breaking services. The fine-grained control Zero Trust Authentication gives over what can be accessed internally also makes third-party integrations much easier. While historically Zero Trust Authentication was quite difficult to deploy and manage, new operations technologies such as Kerberos and AWS have reduced this deployment overhead and open source projects like OPA and Envoy can be used to provide Zero Trust Authentication at little cost. As the web grows Zero Trust Authentication is likely to become the standard for internally securing services and having the tools to deploy and manage it easily will become necessary for any company providing online service.
References
2020 Insider Threat Report, Cybersecurity Insiders
OPA Authorization with Envoy and X.509-SVIDs, SPIFFE
Want to talk more? Contact us.
