The network is no longer the sacrosanct environment where good and bad guys can be distinctly identified and access restricted to ensure security. Defining the perimeter or zones as part of securing the network does not suffice now. With the advent of cloud, remote working, and mobile, the earlier concept is dissolved. Whether it is cloud SaaS applications or running in IaaS, our workloads and users have escaped that perimeter.

Zero Trust approach to security moves away from the failed perimeter-centric approach to a model that's more data and identity centric. It is about users who are using devices over networks to connect to workloads. The concept of context surfaces in the whole chain --- what is being accessed, where is the request coming from, which device is involved, and how the access is requested – the key considerations before a decision is taken.

This also implies that the network does not hold any specific privilege; the privilege of the trust is no longer rooted in the network. Instead, all access requests whether they are from managed devices or not, come through some kind of an access proxy /gateway supported through single-sign-on, user /group database, and identity provider. Access control decisions are taken using an access control engine, which can infer the trust based on device inventory, device posture, location, certificates and access control tokens.

Instead of just looking at the network perimeter and all the things inside as trusted, we need to view all access requests as initially untrusted, and then make those access control decisions based on full context of the access chain.

The relevance of context in zero trust

At the core of the context in Zero Trust lies the identity of the user or an application process whether it is on-premise, cloud based, or API based. The identities start to melt together because the model combines employees, privileged users , privileged identities, temporary identities of contractors and third parties. The complexity increases with more and more systems being exposed to partners, or strategic partners with specific access requirement than others.

The context of Zero Trust is about gathering those metrics that an organization can leverage to assess the legitimacy of an incoming access request. This varies from organization to organization and the primary factor is the context of risk assessment at a business level and then establishing the relevant metrics applicable to the individual metrics. Every organization should start developing their respective framework to build the appropriate context and move from the perimeter-centric model to the Zero Trust model.

Concept of context varies between scenarios, threat landscape and business domain. Here is a simple example for understanding context.

In any situation, we have network context. However, instead of being the root of all trust and assuming good to go while the user is within the company network, it is worthwhile to authenticate to company Wi-Fi using certificate. The data gathered for orchestrating to device management add to the richness of the context. We can understand the source of the request and other information confirming legitimacy of the incoming access request. Often, it may so happen that this goes outside the boundary of traditional controls and we can simply ask, have I seen you from this IP before. It is possible that the user is logging in from a remote dynamic IP address and the IP address has not changed in at least a few years. It is also possible that the request is coming from an unknown IP address and in such situations, it can be referred from a threat intelligence source. Have we seen any suspicious login attempts from similar sources?

From the example above, we can see that the context can be richer with interesting data leading to a better decision. Organizations can also look at fighting the false positives with enriched context as it helps in gauging the velocity of genuine versus malicious looking attempts.

Risk assessment is key for context

We focus on the technical risk when we look at our cybersecurity designs, but basis the risk assessment, we know that certain resources and certain systems need to be treated with tighter security controls. With that information, we can act on it, implying the orchestration of the underlying infrastructure for a full stack visibility, and how data is handled and stored etc. This also needs to be backed by an integrated program and the use of analytics, automation and orchestration. A useful reference would be NIST Zero Trust Architecture 800-207. If we sum up all the output from risk assessment and create a progressive journey for Zero Trust, we look upwards in ascending order starting from traditional network infrastructure and software defined perimeters, then servers and workload perspective using micro segmentation.

Metrics for context development

Starting with firewalls, zoning and data isolation and eventually turning into a strategic initiative with tools and technologies acting as enablers is the correct way to develop all the metrics required to reach ultimate state of Zero Trust. For every organization, this is a maturity journey achieved through tighter integration of tools and technologies, automation of processes, and revisiting respective user roles to achieve the state of Zero Trust.

For every organization, the metrics are unique and there is no mandatory sequence to develop these metrics. Common metrics to develop the context for legitimate access request are users’ identity, location, device, traffic path/networks, data and workloads. The metrics can be augmented through reference decisions from visibility and analytics tools. Let’s take the example of an identity centric approach to articulate the process of metrics development.

The objective here is to grant the identities and accounts with optimal access rights and verify connections before any explicit trust can be established. In order to make appropriate decisions, we need to know a few parameters such as:

• Source of truth for legitimate users of the system
• User identity
• Groups and memberships
• Requested level of access, implying an authorization decision
• Scope of access implying the level and system the user is requesting access to
• Device and connection information

Level of resistance ( least for a company managed device accessing company SSO portal and most for an unmanaged device from an unexpected location accessing cloud based Jenkins server configuration)

Ability to access all of the above information on a run time to make decision is key to developing metrics and context for Zero Trust.

Shifting paradigms in Zero Trust

The implications when implementing one of these metrics, especially users, groups and the concept of least resistance is analogous to the concept of privilege users. We are familiar with programs where we have selected more sensitive resources, and their users are subjected to prove their identity and authorization through PAM, a system used for managing privilege access with Zero Trust approach.

However, enterprises should consider a radical shift in the approach to privilege users. For example, developing controls within systems where we can elevate the privileges appropriately. We could move away from the concept of privileged users to just users; the users are provided with their actual identity, the right level of access to the resource in the right context at the right time. This also implies that access to those users can be customized based on demand. In essence, we will have a number of systems where there are no more privileged users.

Another fundamental shift is how enterprises can move to context-based, metric-driven and time-bound decision to allow sign in. This will allow organizations to move away from insider threats, disgruntled employees, and operational nightmare related to removing unused RDP, SSH session keys from fleets of servers and applications. This way, we can enforce Zero Trust access control decision even for server admins, and more importantly, the control is now universal because the same control would apply to a browser session when they log in to their end user applications like email, SharePoint, file shares etc.

Similar to the context of user, groups and access, network also plays a fundamental role in enriching the context data. Assume that the network is compromised with threat actors trying to move laterally within the systems. Architectural decisions start to play a critical role to decide how the infrastructure is following macro segregation and allowing system communications. Here, a tool that allows you to do software-defined networking, or server workload-based micro segmentation becomes a critical asset to our arsenal.

In the COVID-19-induced norm of remote working, the wave of unrequested BYOD is far greater than it used to be. This changes our security posture rapidly and the need for context too. Not only are we interested in knowing ease of device management, but also, the device. Can we have something on that device that can give a validation of pattern of access or its current location with respect to time or security state. And, can we verify the application that runs on Mac and Windows and iOS and Android? Metrics like these are driving richer hardware-based context that help us with quick contextual decisions.

Understanding the security state of the device needs an integration with an endpoint management framework, including endpoint security detection and response system. This places the technology controls in right order and ahead of the traditional management framework. Enriching the context with further information on software upgrade update policy of the device operating systems can take us directly to the decision point, and to an extent, improve the data for known device beyond the corporate managed fleet to partner and BYOD scenarios.

There is also a need to move away from point integrations to a central policy and access control. The value of rich context of data and access control decision is better leveraged with central control plane. In a recent attack on FireEye systems, an elite group took advantage of a vulnerability to implant malware, which then found its way into the systems of SolarWinds customers when they updated their software. Such occurrences are frequent, and when they do happen, with a centralized approach to security controls, organizations can take quick decisions to tackle such adversaries, discover vulnerabilities, and apply automatic mitigating controls for access to all systems.

All of this information equips us with necessary data for posing a contextual response, and knowing the exact challenge for the incoming access request. The size or magnitude of challenge depends upon the level of resistance that is applicable in accordance with the business criticality of the applications and nature of access request vis-a-vis the current user role.

Let’s look at the development curve and possible architecture solution to integrate all of these components.

Zero Trust: Maturity curve and reference architecture

Figure 1: Zero Trust maturity curve

Starting from stage zero, we have categorized the journey into four stages. First one was mostly perimeter focused with implicit trust, and fragmented identity, where most data was still on active directory on premise; there was little cloud integration and passwords were everywhere. However, with maturity, we witness single sign on across employees contractors, and partners, supported through modern multi-factor authentication, push authentication, whose policies are mostly unified across applications. Hence, over the journey, certain organizations have a bit more of a control point for authentication and authorization, thus a stepping stone of context build towards Zero Trust.

Since the year 2019 and 2020, this journey has been through contextual access, automation and orchestration with identity lifecycle management, where the access policies are not fixed based on any particular resource, but the context of the user and the devices. The next step will be how organizations will deploy different kinds of authentication factors for different user groups based on the level of resistance that the incoming request faces. This also is the stage where we often see organizations really starting to pay more attention to APIs, especially with API access management via access tokens.

With the disruption caused by COVID-19 and the increase in remote workforce, organizations will have to move toward risk-based access and access policies. This is termed as adaptive workforce in Figure 1. A Zero Trust organization will have to build the context and develop continuous and adaptive authentication, authorization, device security state, resource criticality, application type and network information as part of the key decision making process.

Figure 2: Reference architecture for Zero Trust

In Figure 2, we can see that the identity is no longer only about the user; it is also about the device. Figure 2 is a vendor-agnostic reference architecture /framework providing an idea of basic building blocks for zero trust. Zero trust is not about any particular tool, it is about an integrated approach that combines people, process and technology to combat modern threats.

The devices and users that an organization recognizes by having the right context is the starting point. Rest of the context can also be provided by other systems. For instance, SSO IDP system can provide time, context of the users and devices associated with the requested access method. Further, the network context can provide inventory of the locations including remote versus on-premises. Then comes the application context, method and type of access being requested.

From user context perspective, it is important to draw as much details possible about user’s identity for verification. One of the key things to draw inference is the ability to understand whether the request is coming from a compromised user or bot. For example, integration of email security gateways with authentication system allows us to take advantage of the context of user -- type, identity, location, resource and possibilities of phishing attacks or email attacks on the user.

From a device context perspective, information available from device posturing and location brings a wealth of contextual data for decision making.

From a network context perspective, most organizations are equipped with many tools. For example, existing network edge appliances like load balancers, proxies can provide great context about resource and nature of access. When all the contexts are integrated with identity and device information, an informed decision can be taken before granting access to the resources.

The resource type and access methods play a key role in the architecture. If it's an on premise application that is relying on error-based authentication or using Kerberos tickets, local certificates, we can enforce control through an access gateway and based on the Zero Trust framework to decide the best course for the incoming request. And, if it's a modern cloud application that uses a similar method or identity provider, we can federate based on successful metadata challenge. Similarly, the concept can be applied to any other type of resource, whether it is LDAP or radius based access, SSH, RDP connections or infrastructure components. Next steps are about controlling access to the APIs through the same framework. Organizations should look beyond API gateway to authentication tokens and role definitions for respective APIs.

The architecture is similar to NIST Cybersecurity protect framework, however the cycle of total defense is incomplete without emphasis on detect and response strategies. With all the context information, authorization information, rich identity context as an input to SIEM, analytics and store platforms for correlation, analytics and orchestration, we have the outputs for taking informed decisions.

Despite compelling integrations available for intelligence and analytics, it is often overlooked. Platforms like Demisto, CyCognito, Siemplify can be integrated into the context decision point. Dynamic user group changes similar to the concept of quarantine can be applied till the incoming request is cleared of any suspicion.

The journey to Zero Trust

The Zero Trust reference architecture is a vendor-agnostic high-level framework that provides guidance on where and how to leverage different solution building blocks. From a technology perspective, three fundamental principles or properties would be useful when an organization embarks on a journey of Zero Trust.

Firstly, an organization should take stock of their current inventory for the potential Zero Trust solution and then evaluate what could be reused from the existing stack. Secondly, what are the gaps that could exist after considering re-use. Finally, what products/technology currently exist in the market to fulfil those gaps. The output of this exercise will determine the properties that can measure the tool or the vendor for a successful solution.

Zero Trust is not a single product or solution; it is a combination of people, process and technology applied with the right context considering involved business risks.

Begin your Zero Trust journey

Schedule a discussion with our experts to understand how we can help you become a Zero Trust organization. Contact us @ souvik.khamaru@wipro.com

Souvik Khamaru
Cybersecurity and Risk Services practice partner
Wipro

Souvik Khamaru is Cybersecurity and Risk Services practice partner for UK and EU at Wipro. He is responsible for cybersecurity practice development, leading the GTM for the region, evangelizing and building cybersecurity solution offerings and value propositions. He also actively participates in client events and meetings to share current state of cybersecurity, industry trends and challenges faced by organizations. Souvik can be reached at souvik.khamaru@wipro.com