Rethinking on Zero Trust Architecture Solutions

There is a lot of news about massive data breaches. Look at the list of data breaches in Aug 2021 alone here: https://www.itgovernance.co.uk/blog/list-of-data-breaches-and-cyber-attacks-in-august-2021-61-million-records-breached

And some breaches seem to be via lateral attacks. Zero trust security is supposed to treat every system and user untrusted until verification. If that is the case, why were these lateral attacks so successful? Answer may lie in the following.

• ZTA solutions are not working as expected.
• ZTA solutions are not deployed for all kinds of E-W traffic
• ZTA solutions are not configured well.
• ZTA solutions don't work well with middle threat security functions

Let us dig further

Many organizations went with perimeter security by deploying this security at the edge of their private clouds or VPCs of public clouds. Intention was that if the entire private cloud/VPC is protected from threats coming from the Internet, it is good enough.

The way this N-S security works is as follows:

• User connections from the Internet are terminated at the N-S security system.
• Since, the security system is configured with certificate & private keys of the applications, the security system decrypts the data.
• The security system runs the data (HTTP URL/Request/Response) through a set of security functions (such as WAF, NGFW etc..) to find if there are any known exploit patterns or find out if there are any anomalies. If it finds any threat, it drops the connection. If not, the data from the user is passed to the intended front-end microservice of the application.
• Application authenticates the user, authorizes what that user can perform and provides access accordingly.

Application is not one monolith. It consists of multiple services. Traditionally, one used to think of an application consisting of three tiers - Front end tier (that terminates the user sessions), backend tier (that does most of the business logic) and database tier. Even within these tiers, it may not be one entity. In the microservice architecture pattern, there could be multiple microservices in each tier. Due to this, there is a lot of E-W traffic, that is, one single N-S user request may result in multiple E-W transactions across microservices.

I think E-W traffic is not addressed well in ZTA solutions today. Good number of breaches have this sequence.

1. Attackers find vulnerabilities in frontend application services. They exploit them and gain access to that application and then to the system. (Or) Attackers via phishing or via password cracking get access to the frontend application.
2. Attackers then launch attacks on other microservices and steal data.

ZTA solutions are supposed to stop even if attackers get control of the frontend system, they shall not be able to attack other services. Based on few examples of massive data breaches, it appears that backend services are trusting the frontend services for all types of connections/traffic. One would imagine that each service via ZTA authenticates each client microservice and authorizes specific resources to be accessed based on the type of client microservice. But, it does not seem so. Possible causes (Repeating here).

• ZTA solutions are failing organizations, that is, they are not comprehensive.
• ZTA solutions are not configured well with right authentication and granular authorization policies.
• ZTA solutions are complex to use.
• ZTA solutions are not working with middle threat security solutions
• ZTA solutions are not providing visibility for organizations to understand the topology of microservices of applications.
• ZTA solutions are not helping organizations even to know that a breach happened.

My understanding, good number of ZTA solutions are deployed in this fashion:

Some important points to note from above picture are:

• Perimeter security is used for both N-S and E-W traffic.
• Authentication and Policy enforcement is normally done for users by application frontend microservice. Frontend microservice authenticates the user with the help of OAUTH2, gets hold of role/scope and corresponding ABAC policies and enforce those policies to ensure that users access the resources as allowed by ABAC policies.

Let us see a few challenges with this model.

As shown above, there are few challenges in the current model.

1. Organizations need to depend on application developers (application capabilities) to authenticate, authorize users. If an application does not do a good job, then organizations need to talk to application vendors to get the gaps fixed. There are some solutions, where API Gateways are used to take this job away from applications. There is a new kind of SaaS Services, called 'Entitlement services', but these are limited to specific cloud applications.
2. Perimeter security is used for E-W traffic too. Some challenges include 'Reduced performance', and 'increased attack surface'. Another challenge is that perimeter security is not one function. It consists of multiple security functions coming from different vendors. It reduces the performance even more and that performance degradation stops administrators from using this method and a few cases it is observed that they (admins) bypass security altogether.
3. Backend services are not implementing authentication & authorization very well. Some challenges include 'ignoring certificate verification of peer', 'peer identity hidden by middle security functions which hinders backend service to do any meaningful authentication/authorization'.

One solution that addresses the above challenges is shown below. This solution treats every entity as suspicious and does not trust anybody until verified. It avoids any middle security functions. It does not depend on application developers to implement any security logic. It provides superb control to DevSecOps and that control is uniform across all applications.

In this model, there is a N-S proxy for protecting frontend services from the external users. Also there is a sidecar proxy associated with each microservice to protect services from others. All the security functionality is taken care of by the proxies. Service Mesh is already becoming popular in Microservice architecture patterns by taking care of Mutual TLS, Authentication, Authorization and traffic management. We believe that by enhancing service mesh with threat security & contextual RBAC based authorization, this can truly become ZTA for modern applications. Some of the enhancements we believe are required are shown in dark color in the below picture.

This solution, with its comprehensive security (ZTA, threat security, communication security) along with the application microservice (yet outside of the business logic) provides following benefits

• Comprehensive ZTA, not only for N-S traffic, but also for E-W traffic
• Reduced attack surface
• An uniform interface irrespective of applications
• Support for ABAC policies.
• Application independent policies - One time learning curve.
• In the case of 5G and Edge, usage of subscriber and subscriber location information to decide on access can help in identifying cases where credentials are stolen.

In summary, I believe that the service mesh technology such as ISTIO/Envoy with few enhancements can be a comprehensive ZTA solution.