Top Challenges with Identity Access Management (IAM)
This five-part blog series discusses why IDM is not enough to protect your ERP. This series explores the following topics:
The four threats to your ERP posed by user access request management
Top Challenges with IAM
Risk-based approach for application access governance
Fine-grained identity governance and administration
Access control capabilities & access governance options
Are you wondering what the top Identity Access Management (IAM) challenges are and how to avoid them? Securing data in your ERP system is essential for the survival and success of your business. But, with such large volumes of data stored in your systems, it is a target for bad actors. ERP data is precious, but if it ends up in the wrong hands or breached by a bad actor, it could have long-lasting consequences that damage your business and reputation.
Traditional IAM technologies control user access to enterprise systems by provisioning roles from a catalog of high-level privileges. However, these predesigned roles do not prevent a user's ability to access sensitive data, privileges, and functions within your system. Giving a user this access level can result in significant audit findings, increased risk of regulatory penalties, and costly remediation efforts. Unrestricted, widespread, or poorly monitored user access to sensitive data and transaction processing in your enterprise applications violates the basic security policies for data protection and segregation of duties. It also severely limits the ability to establish individual accountability for privileged actions performed in the system.
IAM can be a helpful tool in protecting your ERP. However, IAM does have its limitations. Here we outline some of the drawbacks of solely relying on IAM to protect your business-critical systems.
Inability to configure access rules in terms of fine-grained privileges in the enterprise application security model
A significant challenge with IAM is the lack of visibility into fine-grained privileges. IAM tools only allow you to request access at a role level. For example, suppose a manager wants to request or approve access for their employee. In that case, it doesn't necessarily provide visibility into what that underlying access actually entails. That becomes a challenge in making sure that you as a manager know what you're consenting to or when it comes to segregation of duties, that you know what the conflicts are. Often, ‘GRC’ tools can be beneficial to complement the functionality of IAM tools to provide fine-grained detail and visibility into the access being given to the user.
IAM focuses on "birthright" access for all user rights. In contrast, IGA (identity governance administration) requires risk management for enterprise access users with hundreds of privileges to sensitive data, transactions, and functions
IAM focuses primarily on birthrights - the more automation, the better. A birthright is when a new employee joins the organization and is automatically given access to self-service functionality, which is great, but in addition to that, many users may need access to an ERP system or CRM, to carry out their job duties. Figuring out a process for requestable access can be a challenge with IAM tools.
Lack of support for short-lived, just-in-time elevated access required for emergency support – privileged access management (PAM)
Most IAM tools allow you to request privileged access and route it to someone to approve it. But what happens once the user is granted approval? IAM tools lack the ability to monitor what users are doing once they’re in the system. This means that control owners and managers can’t confirm that the privileged access was appropriate for a user to have at that time. Nor does IAM track when privileged access was taken away or give insight into what the user did in the system while they had privileged access. In short IAM tools do not provide enough visibility around Privileged Access Management (PAM).
Single Sign-on to business applications for "birthright" users does not control the provisioning of fined-grained privileges that violate company policies such as Segregation-of-Duties or Data Privacy
Single sign-on helps to provide an extra layer of protection and an ideal user experience for users. But once they're inside, that's where the level of protection ends. There is no way of knowing what users are doing, have access to, and if the access they see is appropriate.
IAM tools do not monitor or manage user activity in enterprise applications required for "lookback" analysis when risk is materialized
Lookback analysis has a little bit of crossover with PAM. Still, many organizations struggle with lookback analysis when it comes to external audits. For example, suppose there was a control breakdown in some of the mitigating controls. In the case of a terminated employee who retained access for a year after their departure date, the organization must determine if the employee logged into the system, and if they did log in, what they did while they were inside. This becomes a huge burden on the organization, both in time and audit fees, to provide evidence that the terminated employee didn't do something malicious. An IAM tool simply doesn't provide insight into what a user did once they were in the application.
IAM is unable to support the business process owner, and the control owner needs to certify user access or activity log to support periodic access certification
Business process and control owners are accountable for enterprise security and access controls. These leaders should take a risk-based approach based on special considerations, processes, and tools to ensure that all user access requests are processed in compliance in a way that IAM simply cannot provide. IAM cannot route control violations to the requesters, approvers, and reviewers in the closed-loop workflow or provide a log report. Leaders accountable for enterprise IAM should consider integrating fine-grained application access controls to the IDM and ITSM systems used to provision users in enterprise applications. Fine-grained identity governance is required to prevent security threats and streamline operations to mitigate inherent risks in thousands of available privileges in enterprise applications.
7. IAM tools do not support security, and application administrators needs to maintain role design and update entitlement to remediate inherent risks in thousands of privileges available in enterprise applications.
IAM tools only know what you define in the IAM tool. Suppose you define a specific role and map that to something in your ERP application. In that case, the IAM tool doesn't know whether the underlying nature of that role has changed, or whether someone has intentionally changed it. This is a blind spot in terms of knowing what the composition of those roles are because ERP systems give you a lot of flexibility in your roles and your responsibilities. As an organization to take a risk-based approach, you need to peel it back a layer and not just say, “Oh, this role says AP inquiry, work done.” Organizations need to understand what's underneath that AP inquiry role and be assured that there's no transactional access involved. IAM can be very helpful in maintaining provisioning and de-provisioning. Still, you need an extra layer of protection to make sure that you're comfortable with what's happening in your system, especially once people can get into the system.
A specialized Identity Governance and Administration (IGA) platform such as SafePaaS enables organizations to mitigate threats that can attack the heart of the enterprise. CISOs can deploy advanced application access controls that prevent threats and ensure that user access to enterprise data and processes complies with company policies and regulatory mandates. Advanced application access controls can manage user access requests, role design, and entitlement configurations by detecting and preventing access risks based on fine-grained rules logic. These fine-grained access rules can be configured in the IGA platform that supports meta-data for the enterprise-wide application security model.
To learn more about why you should take a risk-based approach for application access governance read part 3 of our 5-part blog series.