The Convergence, Part 3: IGA and Machine Identities

Written by Dave Culbertson | Jan 7, 2020 2:33:00 AM

As we approached Saviynt’s third-annual conference, Converge ‘19, I began thinking about the different digital transformation conversations I’ve had with customers in the last year. One of the most prevalent topics this year was how to manage machine identities and extend governance to include them. Machine identities, such as Application Programming Interfaces (APIs) and Robotic Process Automation (RPAs or “bots”), often do the background jobs such as connecting services across the cloud ecosystem or managing repetitive administrative tasks. These silicon-based “users” interact with sensitive company and personally identifiable information (PII) just as your carbon-based, human users do. Our customers’ cloud-first or cloud-only strategies all required an important integration, or a point of convergence, between Identity Governance and Administration (IGA) and machine identities.

How Did We Become So Reliant On Machine Identities?

The rise of the cloud brought with it multiple new business opportunities. People could connect more easily with one another through collaborative tools. Companies need fewer humans to engage in repetitive tasks. Applications can connect to one another to share data across departments and other organizations, more readily. RPAs are code-driven, robotic processes that “mimic” human user repetitive activities and are easy to use, often with a low-code or no-code implementation. Bots can effectively manage high-volume, repeatable tasks such as queries, calculation, and record/transaction maintenance. Some RPAs log in to applications and enter data automatically, making employees more productive by reducing the number of mundane tasks they need to do their jobs. APIs are pervasive, often providing access to public cloud and Software-as-a-Service applications. More often than not, companies seeking to update a legacy application use APIs to create modernized versions of their technology. In fact, I’d bet that nearly any modern application built within the last five years leverages a private or public API stack to simplify enterprise data access and integrations. Companies rely on these machine identities to transmit and collect data. To secure this data, most organizations start by implementing common security tools, such as gateways, encryption, or key management solutions. However, these tools provide only one protection level. Managing machine identities means treating them as identities by ensuring that they have the right access to the right resources at the right time.

What do our customers say about managing machine identities?

The problem we see companies face is that they have no way to continuously monitor the risk of their machine identities’ access to data. When we talk with customers, we hear them discuss the value of RPAs to increase operational efficiency while simultaneously looking for a way to limit the access bots have to their environments. AWS Lambda and Azure Functions offer examples of this challenge. These serverless technologies build security into the functions and offer varying monitoring and alerting capabilities. Those protect how the functions access information. However, these capabilities don’t provide visibility into the users who manage and change these functions. Customers also come to us looking to solve the problem of API access risk. Gateways generally regulate API access, acting as an entry point. Many times, customers have already integrated their API oversight with multi-factor authentication (MFA), single sign-on (SSO), and Identity-as-a-Service (IDaaS) solutions. Most customers even have Access Control List (ACL) or role-based rule sets to control authorization. These controls facilitate authentication and, often, authorization. However, they don’t extend governance over who controls the APIs themselves. When I have conversations with customers about their controls, they worry about who controls and codes these machine identities. They come to us to answer questions such as:

Who (or more likely what) can access and use my machine identities?
How can I monitor and control access requested, granted, or updated?
Who has the ability to modify/update/delete machine identities?
Who is the machine identity owner or “steward”?
How do I transfer machine identity ownership?
What privileged access are my machine identities invoking (keys and credentials)?
How can I review and maintain all of the documentation necessary (including implementing compensating controls and mitigating controls) to comply with regulatory and industry standards’ mandates?

I came across a recent survey, which even further elaborates on the issues, especially around API keys and mandatory key strength and the fact that so few organizations recognize the inherent risk here.

The Convergence: IGA for Machine Identities

My response to these questions is almost always, “create an identity-centric approach.” Organizations need to establish and enforce access management over their machine identities, similar to the way they govern human users, while also allowing for the differences between the two.

Manage Machine Identity Lifecycle

First and foremost, you need to assign a unique user name 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 makes them a security or privacy threat to your company. You need to elevate privilege on a just-in-time basis and deactivate the privilege when the machine identity is not active. You also need to review what access these identities have and what resources they access to ensure they have the least privilege necessary. 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 also helps protect your organizational data. Machine identities, once set, often stay in place longer than employees. You need to be able to align users to individual machine identities or families/groups of machine identities so that you have a human user tied back to the activities. You also need to create succession policies in case that 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 job.

Continuously Monitor for New Risks

Much in the same we develop intelligence around carbon-based users, we need to monitor for new risks from machine identities. Every day, the news highlights new security and privacy regulations and standards. A common thread among these compliance mandates is the need to continuously monitor for new risks. The velocity and volume of the cloud means that new risks can surface in the blink of an eye. While we still need to do periodic access reviews, we also know 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 ten minutes. Taking an identity-centric approach means that you would create time-bound account elevation requests that are automatically approved every time the API makes the call. If you suddenly get notification of the API requesting access every five 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 important for monitoring both APIs and RPAs, rogue machine identification is 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 a new 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 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.

Why Saviynt? The Convergence of IGA and Machine Identity

At Converge ‘19, we bring together customers, organizational leadership, technical professionals, and domain experts to discuss the top-of-mind problems they faced using Saviynt’s Gartner-recognized IGA cloud platform. Our panels present stories about and insight into the most pressing points of convergence coming out of their digital transformation journeys. Saviynt’s solution protects your digital assets because we built our innovative platform to meet customers where they work – in the cloud.

Highly Scalable, Cloud Architected

Saviynt’s cloud-native platform uses Big Data technologies like ElasticSearch and Hadoop architecturally. We designed our IGA platform to provide tremendous amounts of scale to meet the demand of the number of objects. Organizations need a cloud solution that allows them to manage their machine identities in an efficient way.

Elastic, Extensible Data Model

We designed our platform as an elastic, extensible data model because we found that a lot of machine identities were simplistic while others were more complex. We wanted to offer our customers something that didn’t require code level customization so that they could create definitions of new objects. Combined with our scalability, Saviynt’s platform provides organizations with the solution to their machine identity risk problems.

Rich Analytics, Peer Insights, and Usage

Saviynt’s analytics allow you to track controls and risk. With peer-to-peer analysis, we can compare whether one machine identity, such as a bot or API, looks like the other machine identities in that same category. If our analytics detect an outlier, they alert your IT administrator to the risky access so that they can review the access and extend governance.

Extensible Process & Workflow Controls

We built a Universal Controls Framework that comes with 200 out of the box policies to help meet compliance mandates, including segregation of duties. The Universal Controls Framework aligns with major regulatory compliance standards such as PCI DSS and HIPAA. Customers leverage these controls to create access policies and extend governance over their machine identities.

Full Lifecycle Management Capabilities

Our platform streamlines the onboarding process offering the ability to manage machine identity access using our fine-grained entitlements. Our platform also enables organizations to create temporary or time-based privilege elevation to limit the scope and time for the machine identity’s access.

Access Review & Certifications

As with all other identity types, customers need to periodically review their inventory for anomalous access, such as whether the RPAs have executed. In some cases, an RPA may not have executed or an API may not have made a call in quite some time. If the machine identity is no longer needed, you may need to determine whether it should continue to exist in your IT environment. With Saviynt’s platform, you gain visibility into these machine identities and can review whether they should be temporarily deactivated, disabled, or even removed from the inventory. The future of IT is no longer a “landscape” but a “cloudscape” that will continue to drive a need for better identity and access governance over machine identities. To learn more about Saviynt’s IGA platform and how it can help protect your organization, contact us today or request a demo.

View full post