Non-Human Identity (NHI) is undergoing a transformation to reduce the attack surface, as the industry has rapidly increased the number of application programming interface (API) connections, both internal and external. Much of this change can be attributed to automation enabled by Artificial Intelligence (AI) and the speed at which work can be completed today.
The initial work to replace vulnerable authentication credentials, including passwords and API keys, is well underway and close to resolution. Several emerging solutions follow the same general pattern but use different underlying data structures to represent identity and different sources for public and private key pairs.
Taking a step back, several issues with passwords and API keys led to their repeated use in successful attacks:
- Passwords and API keys were typically long-lived and required storage in system components that persisted across reboots, such as the file system. They may have been protected through mechanisms such as a key store.
- Passwords and API keys were reused to authenticate identities that could perform functions, creating repeated on-the-wire attack opportunities.
These issues are being addressed through an overarching approach that uses a format describing the properties of an entity, in this case, a workload, which may also include system information. This creates an identifier and a binding to its credentials. The credentials are public and private key pairs that may be issued in several ways. These include issuance by a Certificate Authority (CA) that validates identity through defined policies and procedures, keys generated by hardware with a Trust Anchor (TA) held immutably in a Trusted Platform Module (TPM), or keys generated in software without a structured issuance process. The latter may be considered raw public and private key pairs.
Recognizing that the same pattern underpins these emerging methods can help when analyzing each approach. These methods address the weaknesses of older credential models by enabling rapid key rotation, with lifetimes of as little as five minutes being common. Because issuance occurs on active systems, keys are typically held in memory rather than written to disk, which removes another significant risk.
Several standards efforts are defining these methods and the protocols used to standardize API security. These include work in the Internet Engineering Task Force (IETF) on workload identity, secure shell (SSH), and Web Bot Authentication (Web-BoT-Auth). While these areas are approaching maturity, with further standardization still required, the next set of challenges is only beginning to be discussed. Industry is now turning its attention to the identity of workloads and other NHI functions.
NHI identifiers may be created manually or through automated processes. In some cases, it is critical to ensure the identity, which may require manual involvement and issuance by a CA operating under defined policies aligned to a specific assurance level. At the other end of the spectrum are extremely short-lived processes that handle no critical data, where little or no assurance may be appropriate.
An emerging discussion is whether identity and credential issuance for NHIs should be categorized in a way similar to human identities, as defined in National Institute of Standards and Technology (NIST) Special Publication 800-63-B, which introduces Authenticator Assurance Levels (AALs). The challenge for industry is to determine what such a model should look like and where this work should be done. One option is collaborative exploration within the IETF, aligned with broader identity credential work, potentially through the practical-cybersecurity mailing list.
If aligned with the levels defined in the NIST document, this model might include categories such as:
- AAL3 — Very high confidence: Hardware-assured identities that follow strict naming and assurance processes, with issuance by a CA operating at a defined assurance level.
- AAL2 — High confidence: In-system hardware assurance, such as the use of a TPM to digitally sign evidence that confirms the workload identity.
- AAL1 — Some confidence: Software-generated identities with no assurance of the identity or its associated credentials. For this category, and for hardware-assured identities, industry guidance on which system or workload properties are used to derive identity could be valuable.
The purpose of this article is not to define these levels, but to open the discussion for broader industry input and to consider where this work should take place.
Previous proposals have addressed similar ideas and may have been ahead of industry readiness to engage with the problem.
Kathleen Moriarty is the Founder of SecurityBiaS, a Technology Strategist, CTO, Board Member, Keynote Speaker, Author, CISO, and former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy.
Adapted from the original on SecurityBias blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.