Editor’s note: Element #2 of the Seven Elements of Highly Successful Zero Trust Architecture considers the context surrounding the access request.
Confirmation of the initiator (consumed in Element 1) is the first step initially verifying “who” requires access. Identity gives the Zero Trust Exchange an idea of who is connecting, their role and responsibilities, but lacks context around the connection.
Identity is initially considered the ability to deliver a “yes” or “no” binary output based on the initiating entity being authenticated or not. Now we must associate the details of who is connecting with the context of that connection, which allows for additional control of least privilege zero trust. This is made possible by leveraging various identity and profile values at a granular level.
Context in the identity space reveals various insights about the initiator. Continuing the example from Element 1, an employee may identify as Jane Doe. This can be validated by the enterprise IdP. Additional context, however, can be used to further verify their intent, their abilities, and ultimately allow for greater definition of identity.
To demonstrate this context, this time using a workload, the identity may be as simple as two RESTful API processes, let’s call them “device-tickle” and “receive-name.” The context in which these APIs are enabled and employed is what differentiates them from other API calls and processes. Let’s compare these two APIs with contextual differences bolded and underlined:
- device-tickle: Calls a remote device and uses an HTTP PUT function to tell the remote device “hello.” Note: This is through json (JavaScript Object Notation). This could be used to confirm the remote device is still online.
versus:
- receive-name: A service that asks the remote device (through an HTTP GET) to share its name. Note: This is in the format xml (eXtensible Markup Language). This call can be used to receive information about remote services.
In these access examples, while both are similar in that they are using the HTTP protocol to execute their function, there are fundamental differences beyond simply the initial identity (name). Given one’s ability to prove the variable context, access should be different.
- Context passes verification:
- device-tickle: called at 9:00 a.m. on Monday, from a trusted DC, through a secure path
- Context fails verification:
- device-tickle: called at midnight on Sunday, from a remote site
Zero trust controls must allow an enterprise to set granular rules around the context in which device-tickle and receive-name can communicate and access services. This level of contextual granularity can be expanded to many aspects within an enterprise and are not solely related to workloads. The contextual values need to be considered for each enterprise’s requirements and included in the Verification of Identity.
Enforcement of control in zero trust architecture cannot be enabled simply based on who you are. There must be additional applicable understanding and control to set boundaries for access. For example, you may be an authenticated user, but to get access to necessary services you would need verified context to prove several additional aspects:
- The location you are accessing from (country, site, etc.)
- When you requested access (within or outside timeframes)
- How you are accessing (normal patterns vs. exceptions)
- Which device you are connecting from (personal vs. enterprise)
Technology and architecture considerations
Each enterprise will have differing requirements to ensure the correct context is applied within their ecosystem. As such, enterprises should consider the following high-level categories of context:
Trusted versus untrusted locations
A trusted location should be governed by enterprise-defined conditions that reduce its risk profile. An example would be an R&D lab where all resources are local, isolated, protected, and where an enterprise can ascertain which functional controls can and cannot exist. On the other hand, an untrusted location would be campus-wide guest network where users connect to the internet with zero access controls.
Note: A location doesn’t need to be specific to a site, it can be as broadly defined as a country.
Defined versus undefined locations
A defined location would be an enterprise office space where users are more trusted than on the open internet. Defined locations may have specific policies applied to them, e.g., user office networks can access the internet, but office server networks cannot. These sorts of network divisions were historically managed by VLANs. An undefined location, on the other hand, would be anywhere not specifically defined, such as a user’s home network.
Geographic considerations
Defining geographic controls is important not only for security but also for functionality. From a security perspective, user access from specific sanctioned countries should be controlled. From a functional perspective, users should be able to access global resources like google.com in their native language, for instance. Geographic controls can also be used to stop the “impossible traveler” who accesses one service from their device in Sydney followed by an additional service from a location in São Paulo in quick succession.
Timing bands
The time that a user requests a connection to an application is another contextual attribute zero trust architecture can base policy on. Users accessing certain sites outside of working hours would constitute a different contextual posture versus during business hours.
Device type
Access to services should vary depending on the device requesting access. For users, the following context should ultimately define various levels of access:
- Personal vs. enterprise device
- Operating system
- Installed antivirus
- EDR presence
Consider two examples, where the context is very different:
- Jane: On her personal device with an unpatched operating system and no antivirus
- John: On an enterprise device with an up-to-date operating system and EDR running
Similarly, when defining IoT/OT and workload access context, the requesting device plays a larger role in determining access context:
- IoT process on a manufacturing sensor
- OT human-machine interface (HMI)
In both of these examples, contextual details differentiate the access granted. Of course, additional contextual mapping is possible as an enterprise builds granularity. That said, it’s important to maintain the initial idea of zero trust, which states that the underlying network must be considered breached and therefore untrusted. An enterprise will need to operate as though all networks cannot be trusted, with all traffic passing through secure mechanisms over the network
Zero trust progress report
Download the Seven Elements of Highly Successful Zero Trust Architecture eBook and stay tuned for more installments of our accompanying commentary.