A few years back, few companies were talking about zero trust, a concept first teased by the Jericho Forum in the early 2000s and later codified by John Kindervag (then at Forrester) at the end of the decade. By 2018, zero trust had achieved buzzword status. Every security vendor was attaching it to their product offering and it was the main topic in throngs of articles. Zero trust is now moving beyond its marketing term status as organizations are finally infusing “never trust, always verify” in their architectures. “Inside” vs. “outside” is no longer a designation; all traffic must be treated as potentially hostile, lest cybercriminals abuse vulnerabilities in legacy controls and overly permissive access privileges to move laterally on the network and gain unauthorized access to system resources and sensitive data.
All of this being said, zero trust is a principle or framework, meaning, there is no one tool or policy that says, “zero trust is active!” and administrators get to sit back and watch as all unwanted and unauthorized traffic is blocked. Implementing zero trust means that “never trust, always verify” is applied to something. Ideally, zero trust is applied to users, devices, applications, workloads, hosts, and data—everything communicating on networks. The way companies and vendors are applying zero trust today varies, but we at Zscaler maintain that the most effective application of zero trust is centered around identity.
Identity: not just for humans
For many people reading this post, “identity” automatically implies a person’s digital identity or the device they’re using to interact with digital systems. However, hardware, software, and services also have identities that can be used for characterization and upon which network access control decisions can be made. In fact, the identities of hardware/software/services are easier to build and more reliable for control decisions than a person’s digital identity. Why? Typically, users’ digital identities rely on traits like an assigned user name, an assigned password, assigned access permissions, the most likely devices the person will use to access resources, and the location(s) from which they typically work.
This is a very small set of attributes on which to base risk decisions about who can access your company’s most sensitive data and systems. Amplify the risk by ‘X’ number of users accessing your networks multiplied by ‘X’ number of devices each person uses, and ‘X’ number of home offices/coffee shops/hotel rooms/airport lounges/etc., and you’ve got a mountain of user identities to manage. Plus, none of this accounts for how easy it is for attackers to find/steal/guess usernames and passwords online, thereby diminishing the efficacy of a digital identity built on the concept that a person is who they say they are provided they proffer the right information (which can often be found online, if you know where to look).
By contrast, identities for hardware, software, or services can be built from larger collections of attributes that are much harder for an attacker to change or mimic. Characteristics like the SHA256 hash, PE header values, process identifiers, the UUID of the BIOS, operating system, container or image ID, file path, file name, and much more, can be combined to form a system or resource identity. Because this type of identity is built on a larger collection of attributes than a typical user ID, elements of it can change—software can be patched or an application can change containers, for example—without “breaking” the identity.
Identities, therefore, become upgrade-tolerant and adaptable, and do not require an administrator to create or change a rule that compensates for every change (or worse, build rules so overly permissive that security controls don’t recognize when an identity has changed). What’s more, because this type of system identity incorporates cryptographic properties and immutable elements, attackers are much less likely to be able to masquerade as a legitimate piece of software or process, thus the probability of breach decreases.
Applying zero trust using system identity
By creating identities for the hardware, software, and services running on networks, admins can start to implement zero trust policies that control what can talk to what, yet not have to worry about the underlying infrastructure of the network. The control plane moves to the asset level, which, in today’s world, makes much more sense than relying on the network layer. Serverless computing, cloud computing, and containers decrease the value of the network as a control plane since 1) network attributes change constantly, and 2) the infrastructure is not controlled by the user organization responsible for managing/securing the network. With identity tied to assets and abstracted away from network constructs, zero trust becomes more feasible:
- The requirement for continuous, bi-directional validation is easier since:
- Identity is now an aggregation of immutable properties instead of assigned attributes
- Hardware/software/services identities can dictate access control decisions
- Over-permissioned functions and roles can be automatically reset to least privilege access and do not need adjustment when a user changes jobs, device type, location, etc.
- Security control adapts more readily to the environment (because environment is no longer an element of control)
- Network admins no longer need to constantly update rules when the network changes
- Security admins no longer need to rely on network packets (which are only snippets of information, can be obscured by encryption, and are hard to detect in serverless environments) to determine malicious activity.
Shifting toward identity-based security
Legacy security focuses on protecting data, applications, and services by securing the network. In this traditional model, “who” is allowed on the network and what actions they are permitted to perform depend largely on a person’s digital identity. Though there are some excellent user identity-based technologies commercially available (and should be considered as part of a layered security strategy), we at Zscaler posit that a person’s identity is not the only thing organizations should care about.
System identities are equally important, as described above, and provide another control plane—a more reliable control plane—upon which organizations can verify access requests. In addition, when all your software, hardware, and services also have identities that are built on cryptographic and/or immutable properties, security and network teams can apply zero trust-based rules to those assets, not just who is touching them. Doing so ensures stronger, system-wide security that applies ubiquitously across networks.
