What is PIM, PAM, IAM, IGA and SCIM?

The terms privileged identity management, privileged access management, and identity and access management are frequently confused. In addition, they frequently believe that privileged access management (PAM) and privileged account management (also PAM) are synonymous, which is not accurate. To cast some light on this topic, this article will compare and contrast PIM, PAM, and IAM, and explain how and why you should integrate them into your environment.

First, I will define PIM, PAM, and IAM and explain why they are essential to the security of your organisation. All of these ideas are based on the principle of granting specific permissions to user categories. According to the policy to which a user has been assigned, he or she may be granted specific privileges and access to information and systems. To configure a secure environment, you must define the data, applications, and users who require privileged access and maintain strict control over permissions.

Now, let’s attempt to comprehend each of these access management concepts in greater detail.

“Privileged Identity Management (PIM) is a capability within identity management that focuses on managing highly privileged access.” PIM is an information security and governance instrument that enables businesses to comply with regulations and prevent system and data breaches caused by the misuse of privileged accounts.

Additionally, PIM refers to the monitoring and security of superuser accounts. A superuser is an account with significantly greater privileges than ordinary user accounts. This network identity is typically assigned to system or database administrators and is used for platform administration. As superuser accounts have elevated privileges, those with access can circumvent the internal restrictions of a network. Therefore, users may intentionally or unintentionally disclose sensitive information, alter transactions, or delete data. Consequently, these accounts must be meticulously managed and monitored, and PIM procedures and systems must be implemented to safeguard an enterprise’s networks from exploitation.

Here are the most important considerations to keep in mind when implementing Privileged Identity Management in your organisation:

• Recognize and monitor all superuser accounts.
• Define how superuser accounts will be administered and the capabilities of their respective users.
• Establish procedures and implement tools for managing superuser accounts.

Privileged Identity Management is the most effective method for managing superuser accounts across an entire organisation. Members of the company’s C-suite and senior management may also have administrative privileges and access to sensitive data. Certain privileges and access require close supervision and appropriate controls to prevent compromise. PIM ensures a specific allocation of identity and privileges for each user, ensuring that they can only access data within the limits of their privileges and perform specific actions.

Privileged Account Management or Privileged Access Management? This is the acronym for both terms, but bear in mind that they are not identical. Privileged Account Management is a subset of Identity and Access Management that focuses on protecting the privileged accounts of an organisation. My colleague Elena has written extensively on Privileged Account Management and privileged accounts, so you should also read her article. Privileged Access Management, on the other hand, encompasses all security strategies and tools that allow organizations to manage elevated access and approvals for users, accounts, applications, and networks. In an essence, PAM enables organizations to limit their attack surface by granting a certain level of privileged access, thereby enabling them to avoid and minimize the potential damage caused by external or internal threats.

“Privileged access management (PAM) is the combination of tools and technology used to secure, control, and monitor access to the critical information and resources of an organisation. PAM includes the subcategories of shared access password management, privileged session management, vendor privileged access management, and application access management.

PAM IS CONSIDERED A MAJOR SECURITY PROJECT THAT ALL ORGANISATIONS MUST IMPLEMENT.

The primary objective of Privileged Access Management is to uphold the Principle of Least Privilege, which is defined as limiting access rights and permissions to the bare minimum required for normal, daily operations of users, programmes, systems, endpoints, and computational operations. The discipline of PAM falls under IAM. PAM and IAM allow organizations to obtain absolute control and manage all user privileges with ease.

One of the primary concerns in the PAM domain that affects organizations is the struggle to fulfil all requests from users who wish to have their permissions increased in order to complete specific duties. PAMTM has developed a cutting-edge PAM solution – Privileged Access Management – that enables organizations to simply manage user rights and improve endpoint security. As the only tool to automatically deny/de-escalate admin privileges on infected machines (when used in conjunction with the Threat Prevention or Endpoint Detection suite), it significantly improves your organization’s security.

Identity and Access Management acknowledges the necessity of enabling adequate access to services and meeting stringent regulatory requirements. IAM is a crucial endeavor for all organizations, necessitating technological expertise and a comprehensive comprehension of the business. Gartner defines Identity and Access Management as follows:

In Gartner term, “Identity and access management (IAM) is the discipline that enables the right individuals to access the right resources at the right times and for the right reasons.”

Most organizations affirm that IAM is very to extremely important to their cybersecurity and risk management posture, up four percent from last year. This affirmation of IAM as a strategic imperative necessitates a cross-functional perspective from all stakeholders, including business leaders, IT and security teams, consumers, auditors, employees, contractors, and non-employees, vendors, and partners.

Methods for Identity and Access Management implementation:

• Make identity one of your primary safeguards.
• Label access permissions and identify extraneous privileges, accounts, and user groups.
• Conduct a risk assessment of corporate applications and networks to establish a firm foundation for your IAM project.
• Utilize MFA and Single Sign-On (SSO).
• Implement a robust password policy.
• Apply the Principle of Least Privilege and the Model of Zero Trust.

Identity and Access Management is an essential component of IT security that manages digital identities and user access to an organization’s data, systems, and resources. IAM security consists of the policies, programmes, and technologies that mitigate identity-related access hazards within an organisation.

A sound approach to IAM enables organizations to mitigate risks, enhance compliance, and boost enterprise-wide efficiencies. This is why overseeing appropriate access through the correct IAM framework has a significant impact on risk management within the organisation and closing the IAM risk gap.

Identity Governance and Administration:

IGA is a combination of security solutions and a policy framework that enables organizations to more successfully reduce identity-related access risks in their operations. The creation, management, and certification of user accounts, roles, and access privileges for specific individuals inside an organisation are all automated by IGA. Thus, businesses can streamline the provisioning of users, the administration of passwords, the control of policies, the management of access, and the review of access.

The ‘policy-based centralized orchestration of user identity management and access control,’ according to Tech Target, is another definition of identity governance. This term indicates the function ‘helps promote enterprise IT security and regulatory compliance. IGA, to put it simply, refers to utilizing the most intelligent and effective strategy for reducing identity risk in your company.

Identity Governance and Administration, which is a component of Identity and Access Management, gives organizations greater visibility into the identities and access rights of users so they can better control who has access to what systems and when. Identity governance enables organizations to scale for growth, achieve more with less, improve their security posture, and satisfy escalating auditor demands.

The automation of the creation and management of user accounts, roles, and access privileges for specific individuals within organizations is made possible by Identity Governance and Administration. With IGA, organizations can quickly take advantage of a more secure, strategic, and streamlined strategy for user lifecycle management, compliance and governance, password management, access certifications, and risk intelligence. Additionally, identity governance enables businesses to:

• Boost organizational security and lower risk associated to identities.
• Utilize role-based access for thoughtful, obvious role management.
• Streamline certification procedures to satisfy rising auditor requirements.
• Make sure that you are adhering to all applicable laws and industry standards.
• Increasing operational efficiency will enable the company to accomplish more with less.

Even though IAM and IGA may sound extremely similar, Gartner takes care to differentiate between the role, scope, and objectives of IGA and IAM. IGA, according to the statement, “differ[s] from IAM in that it permits organizations to] not only define and enforce IAM policy, but also connect IAM functions to meet audit and compliance requirements.” This indicates that the primary goal of identity governance and administration is to guarantee that IAM policies are connected and applied.

We can’t move on without understanding SCIM, so let’s have a look at what it is and what it accomplishes.

The current superstar of Identity Governance and Administration (IGA) is the System for Cross-domain Identity Management, or SCIM. It’s a simple data model that makes use of JSON and REST and appears to address any SaaS identity management scenario. But how widespread is it, and does it meet all IGA data requirements? and how it addresses various IGA use cases.

SCIM was formerly known as Simplified Cloud Identity Management before being renamed System for Cross-domain Identity Management. Several attempts have been made throughout the years to offer a uniform identity management data model and interchange mechanism. The Directory Services Markup Language (DSML) and the Service Provisioning Markup Language (SPML) have both been seen. Both failed to gain traction in the market, owing to their complexity and bloated implementation. A simple and lightweight model was required by the market.

SCIM makes use of both JavaScript Object Notation (JSON) and Representational State Transfer (REST), two popular cloud-friendly HTTP protocols. It has an expandable data model with the fundamental data objects User (person + account) and Group (user groups). This is depicted in the figure below from the SCIM website.

The SCIM User and Group objects, like LDAP’s inetOrgPerson and group/groupOfNames, are generic representations. The User object represents a person generically, having attributes such as name, userName, phoneNumbers, and emails. The SCIM website provides an example of a User object. The Group object is nothing more than a collection of members. The SCIM website provides an example of a Group object.

The SCIM User and Group objects are appropriate for systems that use simple access models, such as basic user (or account) access and access via groups, with groups representing a collection of users. Many contemporary SaaS services, for example, require simply that level of access restriction.

However, this does not address the need for sophisticated account types or access models (such as those found in Microsoft Active Directory, IBM z/OS RACF, and some SaaS services). A draught SCIM Password Management Extension is also available (https://tools.ietf.org/id/draft-hunt-scim-password-mgmt-00.txt).

SCIM is designed to be extendable, allowing for the addition of new types of resources. Because this is data transmitted between two components (e.g., an IGA system and a target system), any changes to the standard objects or the addition of new resource types necessitate the update of the endpoints at either end (changing REST URLs, data generation/consumption).

SCIM is used by various IGA/IAM systems, with many of them expanding the standard for their own purposes.

How widespread is SCIM?

While the use of SCIM in on-premise systems is limited, it is substantial and expanding in SaaS applications such as G Suite, Microsoft Office365, and salesforce.com.

According to an analysis of Microsoft Azure Active Directory connectors (https://docs.microsoft.com/en-au/azure/active-directory/saas-apps/tutorial-list), around two-thirds (40/60) employ either regular SCIM (v1 or v2) or a version of SCIM. A small number of the remaining (5) implement their own REST-based API, while others (15) have their own APIs (which may be Web Services based). Many non-SCIM APIs deal with more than simply Users and Groups.

The majority of SCIM implementations will manage Users and Groups. Some will just handle Users (due to system constraints), while others will manage more than just Users and Groups.

So, while the use of SCIM is not universal, it is widespread in the cloud.

Can SCIM meet all IGA integration requirements?

As previously stated, the standard SCIM resources are User and Group. The User resource, like inetOrgPerson in LDAP, represents a generic user object. The Group resource, like group or groupOfNames in LDAP, is a collection of users. SCIM is an excellent choice if the destination system (such as an on-premises or SaaS system) merely requires a simple user representation or user groups to manage access.

However, it will not meet all IGA requirements, such as the need for access data other than group membership, complex account types, or when the destination system does not have a SCIM interface.

To begin, many systems’ typical access model consists of users (accounts), users mapped to groups, and groups mapped to permissions/rights/resources. This enables a simple management delineation: system owners/administrators can manage the group to permissions/rights/resources (i.e. the system’s fine-grained access), while security admins or help desk can handle user accounts and group memberships. However, this is not the model utilised by many systems; some systems connect people directly to permissions/rights/resources, while others have numerous tiers of access (e.g., groups and roles). You may need to manage these relationships for identity management. From a governance standpoint, simply seeing accounts and group memberships may not provide a whole picture of a user’s access, especially when group naming/descriptions have no meaningful influence on the access they provide.

SCIM must be expanded in this scenario to support custom resource types, including data objects (such as permissions) and memberships. Extending SCIM entails extending both the schemas and the endpoints on both ends.

Side note: There was an article in this regard by Garner named IAM Hype Cycle for last year, the link is here if you have account, just spend some time with it, it’s really a good read.

The standard User resource, on the other hand, does not support the account complexity required by many applications. Microsoft Active Directory and IBM z/OS RACF accounts, for example, have dozens of distinct characteristics. The IBM AD Identity adapter, for example, manages about 200 attributes on AD accounts (including Lync and Exchange attributes), whereas the IBM z/OS RACF Identity adapter manages around 120 attributes across various segments.

You might expand the standard SCIM User schema to include the extra properties required for each target system, but this does not scale and could be quite time-consuming. Alternatively, you might create a separate account resource type for each account type, and then create REST endpoints and the code to handle them for each. For example, for AD and RACF, you would need https://example.com/v/ADAccount and https://example.com/v/RACFAccount endpoints, as well as the underlying code to execute each Create/Read/Replace/Delete/Update/Search/Bulk operation.

Finally, many systems simply do not have a SCIM interface. If you were to install SCIM across all of your systems, you would need to create some sort of adaptor layer to connect SCIM to the target system. This could be an extraneous transformation layer (adding another point of potential failure between the IGA system and the destination, not to mention extraneous processing).

While SCIM adheres to its initial mantra of being lightweight and simple, it comes at a cost. It is becoming more popular in SaaS apps (2/3 of which are managed by Microsoft Azure AD), where these applications require simply simple users or users and groups.

However, there are times when ordinary SCIM is insufficient, such as when sophisticated access models, complex accounts, or systems lack a SCIM interface. SCIM would need to be enhanced in these circumstances with custom resource definitions and custom endpoints.

SCIM is well-suited to most SaaS applications. It is possible that the industry will shift to more conventional access arrangements. It is unlikely, however, that all legacy on-premises systems will be reduced enough to use standard SCIM or expose SCIM interfaces.