Over time, identity & access management (IAM) has become, not only a complicated subject, but also the core to information security. When we think of InfoSec, we generally think of cybersecurity to detect or thwart distributed denial of service (DDoS) or brute force attacks. However, once a bad actor breaches the perimeter defense, what do they intend to do? Typically, cashing out with stolen data (or stolen money, in case of financial systems) is the intent, whether it’s the short or the long con. There are instances in which just the sheer interest of seeing one could breach a well-protected system, but the motivation for most breaches is some sort of financial payout.
The following infographic depicts how an account with certain privileges can be leveraged by a bad actor in gaining access to intellectual property, trade secrets or a financial account.
So how is IAM divided? Today, we tend to view IAM with respect to authentication and authorization – essentially, logging or signing into a resource of some type – disk, network, operating system or application (and by extension, the various “as-a-Service”, whether infrastructure, platform or software).
More and more, the authentication and authorization, respectively, entail such complexities that services and applications offer much configurability, but not for both in the same implementation. Take, for example, Microsoft Azure. You can define the sign-in policies for users or OAuth client applications and configure the policies and MFA for those to a good degree, or you can configure similar policies in Okta. In both cases, authorization may not represent the privileges required or enforced within the application to which either Azure or Okta provides risk-based authentication as a security measure.
IGA offers this capability, with complexities of its own. Why? For one, there is a notion of “need to know,” to which approvals can be configured to gather and record prior to granting roles or permissions to the resource. Consider this example: let’s say a data scientist wants to access customer purchase histories in a data warehouse or data lake to determine purchase habits or build a ML model to produce relevant or foreseeable suggestions, she may request access to the data warehouse through Saviynt. Our first reaction as her manager may be to just approve her request, but what type of permissions is she requesting? Would she modify the DW schema, or add allow another port for her PowerBi or Tableau application to connect? Will she connect over VPN only or not?
IGA tools make it possible to focus on the authorization that would be associated to a user, service or robotics account within the resource or application. Typically, the groups within Okta or Azure don’t reflect the application permissions. Rather, they are an abstraction with respect to the application as a whole.
PAM offers capabilities to further restrict not only the elevated privileges in a resource, but with the slant of limited use – namely shorter sessions and more frequent password changes on the resource. In addition, PAM tools offer session recording and other audit history to allow detection and prevention of misuse. Yet, there are solutions that specifically address PAM needs.
Is a great convergence imminent?
Okta seems to think so, to a degree.
Why? Well, take Azure as the greatest example. While each of these concepts in IAM – SSO, IGA and PAM – all have differing implementation and intents, they all have one thing in common – the identity. We typically think of an identity representing the human – at least Aveksa (now SecurID Governance & Lifecycle, formerly an RSA brand) and Saviynt term it as such, where an account is the ability to access the protected resource.
However, today, the identity represents the human, service or robotics with respect to the actor with the intent to access the system. We can see this in practice with respect to SSO. Okta and Azure do not manage accounts in the application in the context of IAM – they both offer federated SSO using SAML2 or OAuth or OIDC as the means to share authentication status and minimal identity information to allow the user or service or robotics process to sign into the 3rd party resource.
Unlike pure IGA products, such as Aveksa or SailPoint, Azure offers their own IGA module, in which the identity can be associated with access to the resource in proper context. The practice of IGA, however, still differs from IAM in that IGA functions would provision or attach the resource permissions to the user, service or robotics account in the resource. Because Azure already manages the identity, the IGA module simply extends the resource privileges approved to the identity as part of the provisioning process (and the, maintaining the identity-to-account relationship), just as the aforementioned IGA products do.
What about PAM? Azure, being a Microsoft solution, makes if very convenient to integrate remote access abilities, such as RDP. Therefore, allowing administrators to define PAM policies becomes simply another set of configurations.
Azure is the first to offer the full-breadth of IAM because Microsoft foresaw this eventuality.
Okta sees it as possibility, which is why they are extending their IAM platform from IDM and SSO to IGA and PAM.
What does this mean for the IGA and PAM solutions out there today? Will they converge as well? Both CyberArk and Thycotic made acquisitions to offer their customers the convenience of the traditional IAM capabilities, extending their PAM solution. Saviynt and SailPoint both see PAM as the next offering to overlap with IGA (not to mention, both, along with Aveksa, offered data access governance).
It will be interesting to see if IAM vendors become more like telecom companies, acquiring missing capabilities to compete with Azure head on as the all-in-one IDaaS, or if the trend will shift as integration continues as the mainstay to provide a comprehensive solution.
Here at iVision, we offer our clients the expertise in implementing these solutions, whether an all-in-one platform like Azure, or integrating the best of breed, such as Okta, SailPoint and CyberArk. If you would like to know more about this trend, or how we may assist you in your IAM needs, we are a call, email or click away.