In part one, I shared some thoughts on how identities for machines, such as devices and workloads, differ from human identities, and why it is critical to secure them.

Both identity and security can be vague concepts at the best of times. Indeed, countless hours have likely been spent at conferences, on online forums, on social media, at watercoolers, and in meeting rooms, debating how to properly define them!

Instead of attempting to define secure machine identity, I am going to focus on the desired outcome, which is to ensure that the right machine (device or workload) has access to the right information, at the right time, for the right reasons. The degree to which we can have confidence in this outcome depends on the quality of the machine identity management system and how well it is operated.

Identity management systems are not monoliths, but instead depend on several technical building blocks that build on each other. These need to be combined, integrated, and operated to provide a secure machine identity management solution. Figure 1 below shows a layered framework of the core technical building blocks needed to support such a system.

Figure 1: Framework for Machine Identity Building Blocks

Let’s take a closer look at some of these building blocks and how they relate to one another:

• Identifiers:
  • Identifiers are the basic building blocks of any identity system. It is only possible to manage identities if there is a way to identify them uniquely within and across trust domains.
• Attestation:
  • Attestation includes the presentation of proof to establish the provenance of the machine identity. This assertion may include a cryptographic binding (use of a cryptographic key or shared secret), but may also include the collection of other information to assert the provenance of the identity. This may include collecting information about the environment in which a workload is deployed or the configuration of a device or datacentre where a workload is running.
• Secrets Management:
  • Some machine identities use long-lived secrets such as cryptographic keys (symmetric and asymmetric) as part of the attestation process. In some cases, no additional attestation is needed, while in other cases, such as SPIFFE, no long-lived secrets are used and all secrets used by workloads are short-lived and provisioned just-in-time to avoid the need for long-lived secrets. In the case of asymmetric cryptographic keys, the public key may be included as an attribute in a credential. Whenever secrets are used, they should be managed, but the nature of the management may vary based on the lifetime of the secret.
• Credential Formats:
  • Identifiers are often shared with other machines and with humans by encapsulating them in a credential with a specific format. The credential may include additional information or attributes to identify the device or workload, such as its location, trust relationships, manufacturer, or public key associated with the identifier, amongst others. The credential is often bound to this additional information using cryptographic techniques (e.g. digital signatures). Examples of credential formats include X.509 certificates, JSON Web Tokens, and Verifiable Credentials. These credential types are often profiled for use with machine identity systems, as is the case with X.509 and JWT SPIFFE Verified IDs (SVIDs).
• Provisioning:
  • Machine identities need to go through the normal create, read, update, and delete motions for human identities. However, these operations must also take into account that the join-move-leave motions for machines differ from that of humans, in important ways, as we discussed previously. Among the most notable of these scenarios is change of ownership, as software and hardware is acquired, deprecated, or disposed of over time.
• Authentication:
  • Once a machine has an identity and it is provisioned, it has to prove its identity to other participants in the system. This is often done by presenting a credential which may include attributes that the recipient can verify, including proof of possession of a private key matching the public key included as an attribute in the credential.
• Authorization:
  • The question of “does this entity have access to that resource, at this time, under these conditions?” is equally valid for machines as it is for humans. Machines are often “over-authorized” or “over-permissioned”, but as we move towards a least privilege or zero-trust architecture, the ability to provide fine-grained authorization and have that extend across trust boundaries is critical. To make fine-grained authorization decisions, multiple attributes may be taken into account and combined, including machine and user identity information. Authorization is a key intersection point between machine and human identity.
• Federation:
  • Maintaining trust boundaries within a system is a common part of controlling access to resources. Yet, it is not uncommon for machines in one trust domain to need access to specific information in another trust domain. As machines, and workloads in particular, cross trust boundaries, whether in on-prem, hybrid, or cloud environments, they need to be able to establish trust relationships to both accept credentials from other domains as well as have their own credentials accepted. Federation defines the rules and mechanisms through which this trust is managed across trust boundaries.
• Monitoring and Remediation:
  • Once machine identities are authenticated and authorization decisions are made, it is necessary to monitor their activity to detect anomalies that may indicate compromise. If a compromise is detected or suspected, it should trigger remediation to mitigate the impact of a compromise (e.g. isolation, revocation, incident response etc).
• Policy and Configuration:
  • Policy and configuration is required for each of the machine identity building blocks. Policy defines the specific rules that should be applied, ranging from credential format through to authentication method and authorization rules. Policy and configuration languages can be very rich, flexible, and complex, requiring additional tooling and workflow management systems.
• Compliance:
  • Compliance for each building block needs to be proven against the policies for that building block. Compliance often takes the form of reports and the process is simplified through the use of structured data in both the policy and the event logging.

Standardising these building blocks increases interoperability and security while creating common adoption and deployment patterns. Combining them, and creating robust operational processes around them, allows us to confidently answer the question, “does this machine have access to this resource, at this time, for the right reason?”.

In the next blog post, we will take a look at some of the standards that are already in place, as well as some of the gaps and how we might address them.