Understanding zero trust model

The term architecture in recent days has evolved so much to the extent that the architect is not only taking care of the application architecture but also the components involved in the successful implementation of the architecture. Security is important as we start integrating multiple offerings from different platforms. Platforms here include the likes of on-prem services, multiple cloud offerings in the form of IaaS, PaaS, and FaaS. Also, a single application can spread its information and services across all platforms. In this context, it is not just the north-south network traffic that has to be authenticated and authorized but also the east-west traffic that has to be monitored for security.

What is the traditional trust model that is mostly followed?

Let us see this in 2 different ways –

  1. North – south traffic – Traffic that is coming from open internet space to the server instances where the application is hosted crossing your firewall, routers and the load balancers. The most common industry-standard to trust a request is by validating a JWT token issued by an Identity Provider(IdP) following oAuth 2.0 using the JWKS way of authentication. The other way to access the servers for privileged users is through a secure VPN tunnel.
  2. East – west traffic – Traffic that is internal to the network that doesn’t leave. Once when the request reaches the internal servers, in this case, the traffic within the internal components within the same network are simply trusted. As there is a huge rise in the multi-cloud way of horizontal scaling, the east-west traffic extends to the hub and spoke or site-to-site VPN model of traffic distributions across clouds.

Either way, in both scenarios, trust is guaranteed by preset parameters. Once when the trust is compromised the intruders get unlimited access and control over the secured systems. Our preset parameters will not be able to differentiate a request coming from a genuine user or a malicious intruder.

Traditional security infrastructure

The need for zero trusts at the user and service level

Even-though the zero trust model was primarily focused on addressing the fundamental flaw of traditional security strategies, it gives a new way of thinking into application architecture (BeyondCorp) and the deployment architecture (BeyondProd).

As high-security standards are emerging, the same way the hackers are also getting smart day by day. It is not sufficient to just trust the tokens that every request carries, rather we should find a way to derive at the trust score for the incoming request and based on that eliminate many of the requests.

Zero trust is inevitable because of some of the following instances –

  1. Multiple form factors (Web apps, Mobile apps, Voice assistants, AR, VR, etc) using the same API to utilize the data – It is necessary to understand the context of the request and then share the data.
  2. Multi-cloud environment means there is a flow of traffic from multiple applications to multiple cloud environments – It is necessary for the services to trust each other and know how much level of data can be shared between the services.

From Google’s blog on BeyondCorp and BeyondProd

Where BeyondCorp states that “user trust should be dependent on characteristics like the context-aware state of devices and not the ability to connect to the corp network”, BeyondProd states that “service trust should be dependent on characteristics like code provenance and service identity, not the location in the production network, such as IP or hostname identity”

Who should know about the new security paradigms?

Unlike older days where security is treated as a separate entity, in the modern-day application development, even the developers should be aware of the security standards like zero trust. Understanding how zero trust model works will help in determining the right architecture of the application.

Guiding principles of zero trust model –

Below are the guiding principles for any zero trust model as suggested by BeyondCorp

  1. Perimeterless design – Connecting from a particular network must not determine which services you can access.
  2. Context-Aware – Access to services is granted based on what we know about you and your device.
  3. Dynamic Access Controls – All access to services must be authenticated, authorized and encrypted.
BeyondCorp – Zero trust guiding principles

How to achieve a zero trust model?

Zero trust does not replace any of the existing architecture. Rather it is an enhancement or add-on to the existing security architectures. So, is zero trust an overkill to your application architecture? It depends on the way the application architecture has arrived. It is really an engineering challenge to come out with a good user experience without adding too much of security challenge in the existing flow.

Zero trust is not just a software that can be installed overnight. Zero trust involves 2 main things –

  1. Architecture design – Knowing the context and origin of the request is core to the zero trust architecture. We have to determine the parameters to be considered to eliminate the trust on the request. Consider only the meaningful parameters that adds context about the user or the device.
  2. Implementation engineering – AI/ML-driven policy enforcement engine helps determining the trust of the request that comes through. A trust score can be derived and the data to be shared can be determined based on the trust score. The different enforcement policies should be reviewed over a time.

Products like Apigee sense helps to identify anomalies by building algorithms based on the metadata captured in the Apigee API management platform. The intelligent behavior detection algorithms can be tweaked as per the needs and requirements of our application.

Below is an illustration of BeyondCorp implementation in Google Cloud Platform –

GCP – Context-Aware Access

Examples of user experience in a zero trust model –

Zero trust doesn’t refer to a specific technology or product, however, it is achieved by the application of several technologies.

1. An account activity alert sent in your smartphone when trying to access Gmail from some other location or a new device. In this case, there is no real blockage for the user, however, an alert is sent to the closest form factor that the user may currently use. The context is not just used to determine the trust of the request but also in pushing the alert to the most trusted device the user may be in possession of now.

2. Challenging with security questions even-though the right password is used. Some times Captcha’s are misunderstood for zero trust. However, Captcha’s help in preventing the bots from submitting the forms multiple times or with unwanted content.

Share your thoughts on the different mechanism that you would implement to achieve zero trust model in network and application architecture.

Happy learning!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.