Manage Machine Identity Lifecycle
In order to manage machine identities, you must first discover and inventory the. Then you need to assign a unique identifier to each machine identity so that you can provision access and enforce policies as part of your lifecycle management process. Putting governance around the identity and being able to track it becomes a critical step in securing your data.
Define Machine Identity Access
Machine identities fundamentally behave as privileged users. The type of tasks they do may seem mundane, but their privileged access can represent a security threat to your company. Organizations must elevate privilege on a just-in-time basis and deactivate the privilege when the machine identity is not active. They need to review what access these identities have and what resources they access to ensure they have the least privilege necessary. Organizations should also create a catalog of the types of access that machine identities have in terms of risk levels so they can be mapped to specific security controls (i.e. SOX, HIPAA, PCI, etc). You need visibility into whether access is revoked or otherwise changed to ensure compliance with internal policies.
Associate Owner or Responsible Party with Machine Identity
Associating a responsible party or ownership helps protect organizational data. Machine identities, once set, often stay in place longer than employees. Organizations must align users to individual machine identities or families/groups of machine identities so they have a human user tied back to the activities. Organizations also need to create succession policies in case the responsible party leaves the company or moves to another role. The responsible party fulfills attestation needs while succession management ensures that someone is always able to be in that role.
Continuously Monitor for New Risks
In the same way organizations develop intelligence around human users, they need to monitor for new risks from machine identities. Security and privacy regulations and standards are constantly changing and evolving. A common thread among these compliance mandates is the need to continuously monitor for new risks. The velocity and volume of the cloud mean that new risks can surface rapidly. While periodic access reviews are still needed, it is also true that point-in-time compliance no longer equates to security. Peer and usage data can help surface new threats by alerting you to outliers. For example, assume you set a rule that your APIs make calls to the application every fifteen minutes. Taking an “identity-centric” approach requires you to create time-bound account elevation requests that are automatically approved every time the API makes the call. If you suddenly get a notification of the API requesting access every ten minutes, the request is an outlier that signals a potential new risk. Organizations need a way to engage in continuous control monitoring to protect themselves from compliance violations.
Identify “Rogue” Machine Identities
While applicable to both APIs and RPAs, rogue machine identification is the easiest to understand when thinking about bots. Many times, DevOps users re-use code from one RPA to another. However, if the new bot engages with a more sensitive data type, such as PII, then the old code may leave you open to risk. By taking an “identity-centric” approach, you can monitor what information the machine identities interact with so that you can better control whether they need that access or need the access in the way provisioned.
Deactivate or Disable the Machine Identity
If you detect a new risk, such as a rogue bot, especially one that doesn’t have the proper stewardship – controls must be in place to disable it or deactivate it through the use of a next-generation IGA solution.