Coming June 11th

Why Identity is Critical for Zero Trust

Two years ago, 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 vendor company was attaching it to their product offering, throngs of articles were written about it, and the term even earned recognition as one of the most-submitted topics for RSA Conference 2019. Now, in early 2019, zero trust has finally left behind its cachet as a marketing term. Organizations are finally re-architecting existing networks and/or building new networks from a “never trust, always verify” point of view. “Inside” vs. “outside” is no longer a designation; all traffic on a network must be treated as potentially hostile, lest cyber criminals 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 networking principle or framework, meaning, there is no one tool or policy that says, “zero trust is turned on!” and administrators get to sit back and watch as the network blocks all the unwanted and unauthorized traffic. Implementing zero trust means that “never trust, always verify” is applied to something. Ideally, zero trust is applied to users, devices, applications, hosts, and data...everything communicating on networks. The ways companies and vendors are applying zero trust today varies, but we at Edgewise 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).

Subscribe to our newsletter:

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, and
    • 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 towards 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 people’s digital identities. Though there are some excellent user identity-based technologies commercially available (and should be considered as part of a layered security strategy), we at Edgewise 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.


Katherine Teitler, Director of Content

Written by Katherine Teitler, Director of Content

Katherine Teitler leads content strategy and development for Edgewise Networks. In her role as Director of Content she is a storyteller; a translator; and liaison between sales, marketing, and the customer. Prior to Edgewise, Katherine was the Director of Content for MISTI, a global training and events company, where she was in charge of digital content strategy and programming for the company's cybersecurity events, and the Director of Content at IANS, where she built, managed, and contributed to the company's research portal.