So what are the key lifecycle processes required to manage NHIs? Based on my original white paper, below I describe the key lifecycle processes involved in managing and securing NHI risks.
1. NHI Provisioning and Decommissioning
JML processes are typically quite weak in most organisations when it comes to NHIs. Static NHIs are created through many different and disparate provisioning processes, and in many cases, the credentials (e.g., passwords) are shared directly with the requestor of the NHI (i.e., a human), leading to broader issues around the inappropriate use of NHIs by humans.
- Provisioning:– You will need to think about provisioning NHIs in a secure way:
- For static NHIs, these should ideally be fed directly into a secrets vault, without any human intervention or visibility.
- For dynamic NHIs, these are typically secure by design as they are provisioned just in time.
- Decommissioning:– For static secrets, it’s important to have clear decommissioning/offboarding processes. For example, if the account is no longer used or when people have left/transferred, they may still know the credentials (passwords, keys, tokens), which could be compromised either in their new role or externally in Cloud/SaaS environments.
- Recertification:– In particular for static secrets, recertification processes are also critical to ensure NHIs are still valid and required. This is further covered in the Hygiene – Posture management section.
2. NHI Discovery & Inventory
This is probably the most important thing to focus on, especially when you are starting out a NHI program, as it allows you to understand the size of the problem and then help drive remediation activities.
This can, however, be one of the biggest challenges, as NHIs typically don’t exist in a centralised Identity Management system with a full inventory of identities/accounts. You will typically need to deal with multiple identity providers, directory services, and local accounts across Hybrid-Cloud, SaaS, and On-Prem environments.
NHIs defined in a Directory Service like Active Directory are much easier to inventory and manage compared to local accounts defined directly on a platform (e.g., on an operating system or database). Locally defined NHIs will typically require custom feeds to be built, which can take a significant amount of time and effort to develop.
Scanning:- Another important aspect is to scan for plain-text/unencrypted credentials in source code repositories as well as other repositories like SharePoint, Confluence, file systems, etc. Any credentials exposed in these repositories can be easily discovered by both external and internal threat actors.
While you may be able to identify plain-text/unencrypted credentials, understanding their content can be challenging. Typically, scanning solutions will let you know a credential has been found, but it won’t tell you the context of that credential, such as what is the identity of that account (name) and where it is used (e.g., a local account on a database).
3. NHI Classification
Another key step is to fully classify NHIs in terms of key attributes and metadata. Once you have this metadata, you can understand the overall risk associated with the NHI based on the level of privilege and breadth of access.
- Ownership:- Assigning an owner is critical to ensure there is clear accountability for the NHIs, especially when driving risk reduction and remediation activities. An organisation should not underestimate the effort associated with claiming ownership for NHIs. Many accounts may not be known to the current incumbents or could be used by other teams (e.g., upstream and downstream components). We have seen many global programs where it has taken multiple years to fully claim ownership for NHIs.Note:- I see many folks in the industry talk about mapping a human owner to an NHI, but I would argue you need to map an NHI to an application/service (which indirectly has owners) as this ensures ownership of the NHI does not need to change due to personnel changes in a team.
- Levels of Privilege:– Understanding the level of privileges granted to an NHI is very important, i.e., does it have full admin, write, or read access, etc. Understanding the levels of privilege can be very challenging as you may need to understand the entitlement model.
- Breadth of Access:– What is the breadth of access for the account? Is the account entitled to just one asset/component, or is it entitled to hundreds/thousands of assets/components? Clearly, the more assets it has access to, the higher the risk of the account.
- Account Usage:– If an organisation can determine whether the account is in use, this can drive hygiene activities to remove legacy/inactive accounts and achieve quick wins in driving down the surface area of risk. For some platforms/account types, this is straightforward as account usage data is readily available (but needs to be extracted), but for others, it is quite complex (needs to be extracted from endpoints) or does not exist.
4. NHI Posture Management (Hygiene)
A key part of any NHI program is to drive hygiene activities, known in the industry as Posture Management.
- Excessive Permissions:- While NHIs are often highly privileged, many end up being over-privileged and should follow the principles of least privilege.
- Inactive Accounts:– NHIs in their inventories were either outdated, redundant, or no longer in use. By identifying and removing these inactive NHIs, organizations can enhance security, streamline operations, and mitigate potential risks associated with unmanaged or obsolete assets.
- Shared Accounts:– Another big issue is NHIs being shared across applications, which breaks principles of Segregation of Duties (SoD) and least privilege. Sharing causes many issues when NHIs need to be secured and cycled or hygiene activities are being performed, as you could cause operational impact by not fully understanding all the dependencies.
- Environment Segregation:– Another key issue we see across organisations is the same NHI being used across production and non-production environments, leading to lateral movement risks, etc.
5. Securing NHI Credentials
Remediation of NHI risks can take a number of forms.
- Encryption:- Migrating away from plain-text credentials to encrypted credentials with encryption keys being securely managed.
- Passwordless Credentials:–Moving away from password authentication to passwordless credentials like certificates can be another way to address security risks.
By far the most common method to secure credential risks is to migrate plain-text/unencrypted passwords to a secrets vault.
- Vaulting:- A critical strategy for securing credentials is to migrate any plain-text/unencrypted credentials from source code repositories into a secrets vault. This is no small undertaking and will need to handle global scale, high volumes, and provide a resilient/fault-tolerant capability.There are various integration patterns that need to be supported given an organisation will have both strategic and legacy applications, i.e., Runtime, Agent-Based, Build/Deploy Time patterns, etc., each with pros and cons from a control effectiveness and cost/effort standpoint. Other key considerations include how credentials are onboarded onto the vault, i.e., via centralised account inventory feeds or manually by application teams.Account namespace definitions will need to be established to appropriately describe the credential type/instance being onboarded, to support future processes like managed password cycling, reporting, etc.
- Cycling / Rotation:–There are many benefits to passwords being cycled as it reduces risks around transfers, leavers, mitigates/removes credential exposure in legacy code/scripts (including version history), helps uncover unknown dependencies and sharing of credentials, etc.Password cycling is incredibly challenging given the above risks—if the dependencies are not known in advance, i.e., all scripts/code that use the credential (including sharing of the credentials by other applications), there is an elevated risk of operational impact of applications breaking when a password is cycled.Cycling cannot be considered in isolation—there needs to be a sustainable solution for automating the cycling activities (manual cycling does not scale or is repeatable) and tightly coupled to an organisation’s Secrets Vault capability that needs to support cycling.
6. NHI Monitoring Controls – ITDR
This is one of the most challenging areas to deliver a strong and effective control, but one of the most critical, given an external/internal threat actor will always find a way to discover and misuse an NHI credential.
Unfortunately, there is no one-size-fits-all product that you can just onboard and deploy to your environment. There are challenges around the sheer volume of events, the multitude of platforms/NHIs you need to monitor, each with their own maturity/availability of metadata, and the biggest challenge by far is “seeing the wood from the trees” and dealing with false positives.
Organisations should consider Intelligence and Behaviour Analytics capabilities (i.e., UEBA tools) to develop a scalable and sustainable solution, as it is not possible or practical to look at every single event that could be a violation and instead look at outliers/anomalies as a more effective way to manage the risk.
There will be more fundamental challenges an organisation will need to deal with around why humans are using NHIs, e.g., cases deemed by teams to be valid/BAU which need to be understood, rooted out/stopped; otherwise, it becomes an impossible task to see the wood from the trees.
7. NHI Prevent Controls
As you mature your capabilities and controls around managing NHIs, you need to target more strategic preventative controls, including moving towards a zero-trust model. Note that many of these areas are in the early stages of maturity, but are areas you should consider as part of your overall strategy to “stop the bleeding”.
- Stop Check-In of NHIs :– A key preventative control as part of a DevSecOps shift-left strategy is to ensure at code check-in time, the code is scanned for secrets and if found, the check-in is blocked.
- JIT-Ephemeral Secrets:– Migrating away from static to dynamic secrets, e.g., Just-In-Time (Ephemeral Secrets) as part of workload identity management, will stop threat actors from taking advantage of NHIs.
- Real-Time Threat Protection:– While many Detect and Response solutions are more reactive in nature (i.e., post-event), there is a clear direction in the industry to move towards a real-time threat protection model. Using a combination of anomaly detection and policy enforcement rules against, for example, a control plane or transport layer, they can in real-time detect and block inappropriate access. Some examples include:
- Identity Control Plane:- Monitoring, controlling, and preventing policy violations on a Domain Controller in Active Directory – as used in the Silverfort platform.
- Workload Attack Surface Protection:- Another emerging technique that can be considered is to leverage Mutual TLS (mTLS), a security protocol typically used to authenticate between processes/workloads. This combined with actual NHI tracking/usage/discovery, anomaly detection techniques, and policy enforcement rules can help detect and block unknown or inappropriate access – as used in the TrustFour platform
