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