NHI Security, Part 3: Policy Implications

Recent years have seen a crazy amount of growth in Non-Human Identity (NHI). It’s like middleware grew up, untethered itself from the Enterprise Service Bus, started walking around on its own checking out the rest of the world, and got a taste for procreation.

And boy, does it ever like procreation…

In 2022, Venafi stated the average enterprise managed over 50,000 TLS certificates - each tied to an NHI. Two years ago, CyberArk claimed NHI outnumbered humans by at least 45:1. Gartner is predicting 100:1 this year. Market intelligence for machine identities predicts a 12.5% CAGR for the next decade while Artificial Intelligence agents are popping up everywhere.

From the first cron process to AI agents, this evolution is notable for the breadth of tasks our non-human counterparts have taken on. Entire industries have speculated about the loss of human jobs. It seems few human endeavors are left sacred in the AI revolution.

We have NHI everywhere doing everything, faster and in here-today-gone-tomorrow fashion; and our failure mode is a cliff that drops into the abyss when we encounter a fuzzy edge. This is not the human’s world. This is the don’t-blink digital dystopia of AI agents your parents couldn’t have imagined how to warn you about.

We need a set of policies to help us regain control in the new reality. We need to re-think our expectations for how identities are created and managed, how we authenticate digital actors, and how organizations can assign privileges and permissions to processes and programs without leaving everything wide open or creating a mess no one knows how to clean up.

When messes do happen, we must be able to call in the human cavalry. Because the one domain where humans still have an advantage is figuring out how to handle the unexpected. Ironically, we can and should ask our NHI colleagues to help us sort out the mess and figure out the blast radius. They are in the best position to provide an inventory of connections to impacted processes and data as well as a detailed log of “who” took what action. But after most of the picture is framed, it will be humans that figure out the how to handle the omissions, overlaps, outliers, and most of all, outcomes.

In order for humans to determine desired outcomes in the corporate world, we need governance: documentation and processes that specify who is in charge of and responsible for what, and how we make sure it all gets done.

Governance

For human identity, corporate leaders for each business unit determine the quantity and type of need - that is, how many people we need with what skills and experience. Human Resources and Law dictate the high-level process for hiring, terminating, retiring, etc.. And a designated Identity and Access Management (IAM) team implements the processes and runs the tools. All of this should be captured in corporate policy.

NHI should parallel this structure, but account for the technology-specific role NHI plays. The various functions of IT - AppDev, Data, ITOps, InfoSec… determine how much and what kind of NHI they need as they implement technology to serve the enterprise. Enterprise Architecture (EA) should work with the driving IT function and InfoSec to establish patterns for acceptable creation, use, modification, deletion, and record keeping. And as with human identity, organizations should designate a team within ITOps or InfoSec to implement the patterns and run the tools - possibly the same team as for IAM.

Notably, InfoSec plays multiple roles here. On one hand, InfoSec implements their own technologies to help keep the company secure (e.g., Security Operations Center or SOC). These technologies will include needs for NHI. In this sense, they are a business process owner. The Security Architecture function within InfoSec should then ensure the patterns for NHI established by EA align with InfoSec policies and procedures. And finally, InfoSec may house the team responsible for implementing the patterns and running the tools. InfoSec and IT management should work closely to ensure roles and responsibilities are clear in each of these contexts.

As we move the discussion from governance into policy, the parallels between human identity and NHI get shallower. Many of the same high-level functions exist in both spaces, but the differences in purpose and technological implementation mean we go about things in very different ways.

Scope

Security policies for NHI must start with clarity about scope. Any discrete process, program, function, machine, device, or component that takes action involving another system or data outside of its own internal structure should be considered a NHI. For the purposes of policy, locations such as on-prem or in the cloud do not matter. What matters is ownership and operational responsibility of the environment in which the NHI exists.

NHI may have nested instances where one or more NHIs reside partially or wholly within another. However, this is generally not an issue. In any given context, only one distinct NHI should be requesting access or taking action.

We don’t recommend classifying credentials, keys, passwords, etc. by themselves as NHI. Credentials and other digital secrets are critically important to inventory, track, and manage as part of an NHI program. But the secrets are not what takes action. It is typically a program or process that is the actor using the credentials or secrets to take action. The program or process taking action is what should be captured as NHI.

Discovery

When programs and processes use credentials and secrets like API keys and certificates, we can trigger on that usage and ask questions about the NHI taking the action. This is considered passive discovery. To get a fuller picture of all NHI in the environment, we should compliment this passive discovery with active inventorying of systems known to use NHI, such as code repositories.

Policy should specify both approaches, with passive scanning happening all the time and active scanning happening on a routine, scheduled basis or built into the process pipeline (e.g., Continuous Integration/Continuous Deployment or CI/CD). When NHI are discovered, policy should dictate a core set of actions to take, including notation of the NHI in an intake queue, date and time of observation, and relevant attributes such as the credential or secret used along with source and destination processes or interfaces for passive discovery.

Provisioning

Whether the IT team discovers existing NHI by scanning or determines the need to create new NHI through planning, all NHI should be provisioned in a centralized system for tracking, auditing, and forensics. Provisioning should minimally capture attributes specified in EA patterns and reference documentation for approved types and usage of NHI. This should include corresponding profiles, points of integration with other systems, workflows, and processes, and approval/authorization responsibilities for any workflow or process that automates the creation, modification, or deletion of NHI.

Access Control

Handling and control of credentials and secrets is the most critical aspect of NHI. Policy must specify that credentials and secrets may only be stored in designated and approved repositories. These repositories should be carefully configured according to strict standards for access, with routine or continuous audits to verify effectiveness of controls.

Credentials and secrets must all have expiration dates and times set for minimum windows to facilitate practical business function. Teams should also create automated triggers to rotate or renew secrets prior to expiration and set a cap on the maximum number of times a secret may be rotated or renewed before requiring manual re-approval.

No NHI, credential, or secret can have universal access. All access entitlements must be defined in management-approved specifications or standards, and should follow the principle of least-privilege. Routine audits should seek to identify where entitlements are over-scoped or abused, and continually question if business practicality will support more granular definition.

Logging & Auditing

All NHI use of credentials and secrets must be logged and retained in alignment with broader security policy requirements for records retention. Detailed usage attributes such as the target system, specific request, query result, etc. should be evaluated by appropriate teams against data retention costs according to business need and organizational risk profile. All creation, modification, or deletion of NHI must be logged, regardless.

NHI logs should be integrated into Security Information and Event Management (SIEM), with triggers monitored by the SOC. Avoid defining triggers for bad behavior. Trying to predict all the ways NHI can be abused will not work. We recommend an allow-list approach to NHI behavioral triggers built off the patterns defined by EA. Everything else should be deny-by-default.

Especially on logging, policy should reference applicable regulatory standards, such as payment/banking/finance, healthcare, privacy, or industry-specific requirements. This may mean implementing specific processes or technical actions to produce the required evidence. If that is the case, policy should note the requirement in language covering the relevant processes and actions.

Incident Response

Investigations for NHI related incidents should follow existing InfoSec processes tailored and supplemented by NHI-specific guidance. Policy should minimally require playbooks for revocation of compromised or misused NHI, credentials, and secrets, as well as outages from unplanned or missed expiration of credentials and secrets. Maintain a contact list of knowledgeable and sufficiently authorized personnel for each type of approved NHI to pull in as needed.

Third Party and Supply Chain

Contact lists should include key personnel with escalation paths at all business-impacting suppliers, partners, and customers. Policy should require periodic evaluation of all programatic data interfaces with external entities, including identification of NHI usage. The evaluation should produce an inventory of all references and dependencies on external NHI, as well as internal NHI referenced by external entities or accepting external input.

Any internal NHI accepting external input or responding to external requests must note exposed attributes and approved methods of interaction. The inventory must also include validation of all trust chains referencing external entities (e.g., digital certificates).

Risk Management

Policy should require periodic review of NHI dependencies for third parties and the supply chain, as well as the internal NHI provisioning system. This review should identify and rank potential business impacts from failure, abuse, or compromise of NHIs.

Ranked impacts should be evaluated against business need and effectiveness of controls, enumerating misalignments with corporate risk tolerance and specifying corrective action required. We recommend socializing reports of ranked impact evaluation broadly across IT leadership and providing visibility to upper management as part of InfoSec posture reporting.

Artificial Intelligence

Broader guidance around usage of AI is beyond the scope of this writing. However, AI deserves special mention here as AI agents are NHI, and organizations must evaluate data sharing and licensing implications of the language models used to support them. Companies must carefully review use of public vs private language models, how input is treated and retained, and how proprietary and confidential information is protected. This specifically includes considering how to identify and handle proprietary or confidential information interactively provided to AI agents by humans (i.e., employees or contractors) if the data is used or retained by an external entity.