Stay on the cutting edge. Subscribe to our blog.
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.