In technology security, non-human identities (NHIs) are accounts, services and systems that perform automated tasks. These identities pose a unique set of challenges and risks because they often have privileged access and lack the added security of multi-factor authentication (MFA) that can be applied to devices.

However, like any risk, NHIs can be mitigated and there are a few ways to do this.

Dedicated Identities

Contrary to the conventional practice of reusing service accounts across multiple apps and/or services, each NHI should be dedicated to a single process or application. This limits the potential damage if an identity is compromised and can aid greatly in investigation, remediation and eradication efforts if a compromise takes place. It also limits the blast radius of a compromised account to the specific app or service that it’s tied to.

Rightsizing Privileges

Often, NHIs are given more privileges than necessary for their operation. No one and no NHI should be granted privileges to areas they don’t need. Utilizing the zero-trust model of least privilege, NHIs should have the least level of privilege to accomplish the task at hand. Under no circumstances should NHIs simply be clones of existing accounts, with a new name to separate the functionality. They should be created from scratch to perform the task required of them – no more, no less. This minimizes the potential impact of a breach. This is a good practice that should always be applied to anything and anyone.

Regular Rotation of Secrets

While it’s common to set and forget passwords or keys for NHIs or use password creation techniques that are easy to predict, such as mapping a password to the application or service the NHI is performing tasks for, it’s crucial to periodically rotate these secrets to mitigate the risk of unauthorized access and to ensure any identity data leaks from your organization are less likely to cause issues after a breach is discovered. This can be challenging due to the overhead this provides, which scales up with organizational sizing (especially if you follow the first step above – using individual NHIs per app/service), but it’s a critical step in securing NHIs.

Decommissioning Stale Identities

Any unused or stale identities, human or otherwise, are often overlooked. Identities created for certain projects can become unknown entities once project sponsors leave the organization, and each stale identity is a potential attack vector for your organization. These identities should be identified, investigated and decommissioned to prevent them from being exploited and giving attackers a foothold into an organization, allowing them to attempt to move laterally with ease.

Continuous Monitoring and Collaborative Responsibility

This is where there is an overlap of responsibilities between Security Operations Center (SOC) teams and identity management teams. They should be working in lockstep to ensure that identity-sourced issues, like any of the previous points raised here, are worked on with members of both teams. This will ensure the best possible security outcome whilst limiting the potential for downtime to apps and services. This is one of the greatest examples of where adopting identity threat detection and response (ITDR) concepts can pay dividends to an organization.

Vendor vetting

Third-party vendors often introduce NHIs into your environment. Have policies in place to ensure that ANY identity with elevated privileges in the organization is created by internal teams to limit the potential for backdoor access. Monitoring queries can be created to catch any account creations from non-first-party employees to promote proactivity.

These items may seem daunting for an organization with an established footprint in using NHIs, but there is no better time to look at how to retrospectively introduce these measures into the environment, as a compromised NHI is often harder to determine. Proactive management of NHIs is essential in today’s evolving threat landscape.