How to streamline the user access management process
The technology landscape is continuously changing making the user access management process a challenge. Twenty years ago, everything was in siloed systems, organizations had a separate financial system, an HR payroll system, a manufacturing system. As time progressed, everything moved into an ERP (Enterprise Resource Planning system) such as Oracle E-Business Suite, SAP, or PeopleSoft. But this trend is changing back again and organizations are looking to best of breed applications to help them solve challenges in the modern, digital world. The cloud is making it more cost-effective to roll out applications because of the ease of connecting to the cloud. However, having so many applications is causing a problem in the user access management process.
Challenges with User Provisioning
•Hundreds of user add, change, deletes requests every day…
•Inconsistent, ad-hoc and manual processes – platform dependent…
•Disparate provisioning tools and workflows…
•Many human touch points: business managers, help desk, IT, etc…Challenges
•No consistent policy enforcement
•No common controls or audit trail
•Very difficult to ensure compliance and assess risk
When access to an ERP is requested, many individuals are involved in reviewing and approving access requests:
the reviewers and approvers
the policy administrators
and the IT administrators who give that person the actual access
As you look at the process, there are hundreds of users, edits, changes, and deletes every day, making it challenging to keep up with those changes. The process is mainly inconsistent, ad hoc, manual, and entirely platform dependent. This is due, in part, because different applications have different means of provisioning users, which creates a challenge in understanding all those means of provisioning and providing all those capabilities.
Disparate provisioning tools and workflows are tied to different applications. Even though Oracle owns EBS, ERP Cloud, PeopleSoft, and JD Edwards, their provisioning solutions are different across all their applications. And there are many human touch points involved in these processes: the Business Manager, Helpdesk, the IT team, and your Policy Administrator. These individuals may not be involved in the provisioning process at all. This approach creates problems because there's no consistent policy enforcement and as mentioned, each application is different.
Policies are also different across the applications, and there are no common controls or audit trail embedded in the process. This means that there are no controls around the process when an individual is given access. An IT administrator may receive an e-mail to add somebody's access and, in most cases, will allow the access. And there's no audit trail detailing who reviewed and approved the access. This lack of documentation around the provisioning process also creates challenges in ensuring compliance and assessing risks to the organization.
Many applications have thousands of forms or functions that give access, but not all of those are reviewed as part of the compliance risk process. This makes it extremely complicated, given the number of access points these applications have. When you look at user provisioning, the most common source of internal abuse is user access which is a top focus for IT Audits.
Orphan accounts - are accounts created for employees and consultants. However, when they leave the organization, their accounts are not de-provisioned properly. This creates a risk to the organization because usernames and passwords can be shared with other individuals. If the account has not been de-provisioned, the account can still be used.
Rogue accounts - are explicitly designed for theft, fraud, or abuse These are fake accounts that the organization is unaware of. Bad actors gain access to applications without any consequences and can do anything they want in the system.
Entitlement creep - is when somebody changes roles in your organization and is given new capabilities within the application. Still, they haven't relinquished their former capabilities due to the transition period. And suddenly, with all these additional capabilities, they're creating policy violations with the level of access they now have. This creates an increased potential risk for fraud.
Privileged users - are super users, usually an IT team member, who has unfettered access to your ERP applications and essentially have the keys to the Kingdom. These users can do almost anything they want, and it's very challenging to monitor and manage their use because of the level of access they are given.
Access Policy Compliance
For access policy compliance, roles are established and decide how the individual can interact with specific data sets. For example, a Procurement Manager, Sales Manager, CFO, Buyer, and HR specialist each have roles uniquely defined to give them a certain level of capabilities within your ERP. A Procurement Manager typically can reassign a purchasing document, manage a procurement agent, and manage purchase order changes. These are the responsibilities that this "role" is granted access to perform and data security, as to what sets of data they can access.
You can add root logic to protect specific data based on the role, on an individual, but also allow them to perform certain functions that are unique to that particular individual. For example, you can have the Procurement Manager view all purchase orders. But they can only update items and purchase orders in Germany because it's one of their business units.
When you start looking at each individual's policy compliance, unique roles give them level capabilities to process data within their applications. Another example is employee salary. You can view your own salary, but you can't change it. Your manager can view their direct reports and update salary information.
User Security Assignment - Example Oracle E-Business Suite
Let's look at an Oracle user security assignment. This is an example of the Oracle E-Business Suite. This diagram will help you understand some of the steps from a system administrator standpoint and how they give access:
When we start looking at high risk, we do it with a segregation of duties (SoD) analysis. This example is from Oracle E-Business Suite. It gives you the navigation structure of the user security model that individuals are allowed based on the role provided.
When building and establishing roles management you need to have visibility into the privileges to understand if the ERP is protected. Additionally, you need to consider: are enough controls in place to ensure the ERP won't be affected? And do the roles conform to access policies? Analysis should be run regularly to see if individuals are out of policy or have too much access.
And lastly, what do we do when we have a risk incident? How do we correct that? The risk doesn't go away until you make a change or remediate the access that person had to cause the risk incident.
When looking at the compliance checklist, it becomes a challenge to translate corporate governance into actual IT policy. Segregation of duties and common controls ensure that users won't have too much access to a single process. For example, the ability to create a vendor and enter invoices against vendors. Those would be a toxic combination of capabilities. Also, you want to make sure you maintain the Data Privacy policies. If you have sensitive access, you want to ensure users have access to only specific pieces of information. When looking at access controls testing, it's generally done through e-mails and spreadsheets. Typically these processes are manual and wrought with human error, and it causes issues with the testing effort. Also, the data you need for complete testing is often hard to find or missing.
There's also the challenge of managing identity through a business lens for the users to understand. When somebody's controls are put in place or done at the IT level, the business doesn't fully understand the terminology used and how that's being established within the ERP application. And in many cases, the business users don't understand some of the terms used to deploy these controls within your ERP.
Access Policy Violations
In this image, we have a user, John Doe for example, (the username will depend on your organization's protocol for establishing users) The user is tied to an HR person, so you know who's responsible for that access and the individual's impact. You establish your password expiration and number of days, and in some cases, it may be none. In most cases, you need to have some changes periodically. Also, you can activate or inactivate a user based on dates. So when they are first given access, you may want to provide them with a start date. And suppose you want to have it work automatically end at a specific date. It may be temporary access, so you can also put the end date in there.
For each user, you assign one or more responsibilities. Those responsibilities dictate what the person has access to. Each responsibility has many menus and sub-menus that they navigate to get to this function or form that they want to execute for a specific transaction.
As you can tell, it's a pretty straightforward process. Give a person access, and then monitor that access. The challenge starts when you look under the covers at what that entails from a security model design standpoint.
Here we've got an example of John Doe that can navigate all the way through different menus and sub-menus down to the invoice, function of invoice batches ability to submit invoices for payment. So let's say we want to remove it because that's not a function that I want that person to have. It's causing violations for that particular user's usage. Other users navigate to the same function of the same responsibilities, that sub-menu, access the same invoice function through the main menu AP invoice Entry, and may have others to other payable users.
Now, that's where you have a challenge, but you can remove that function from John Doe because it's created an access conflict. It could impact other users within the ERP. However, you have to be conscientious about the changes you make to responsibilities in your menus and sub-menus, so you don't affect other people's access to that same functionality. A root cause analysis is required for remediation. It's a challenge to know whether or not to remediate that access.
A risk-based approach for user provisioning can help mitigate risk. During the provisioning process, SoD rules should be in place. These rules can be established individually, or from a catalog (that solution providers can provide) ERP users can come from different sources, for example, Oracle HR, or an IDM tool, etc.
The next step in the process, looking at the next swim lane in the diagram above, is to register these users. Not every employee in your organization will have access to your ERP. You only need to register those who will have access. For example, if we have 5,000 employees, not all 5,000 will have access to your ERP. The employees who need access go through a registration process to request the necessary access. The next step is to request the actual roles and responsibilities they need access to.
From there, you submit for approval. An SoD analysis is performed to report the impact of the access. At this point, access has not been granted. The analysis merely identifies potential violations before access is granted.
The workflow approval then kicks in, and the ERP is automatically updated ERP with the user and their new role.
Our customer is a global household brand. They operate in over 100 countries and use both Oracle ERP Cloud and Oracle E-Business Suite. They also have hundreds of other applications, including ServiceNow for ticketing, and SailPoint for identity management.
The customer was experiencing challenges because they did not have fine-grained SoD capabilities across all their applications. Because the customer was using various applications, they dealt with inconsistent user provisioning policies and processes. Each application was different. They shared no common controls or audit trail, which caused difficulties during audits The customer was also dealing with a lack of integration in their security management systems that created a constant risk of data theft, fraud, and abuse by service accounts.
The customer selected SafePaaS AccessPaaS™ for Policy Monitor, Enterprise Access Certification Monitor, iAccess™ for user provisioning, and MonitorPaaS™ for monitoring transactions, configurations, and master data within their organization. Now they're better able to monitor and enforce SoD controls and sensitive access across the organization. Additionally, they've streamlined and reduced their risk remediation time for access controls. They now have a self-service user audit process for users and service accounts.
Monitor and enforce SoD controls and sensitive access across the enterprise
Streamline and reduce risk remediation time for access controls
Self-service the current user access audit process for users and service accounts
Control risk in IDM (SailPoint) and ITSM (ServiceNow)
Control each provisioning request against access policies
Streamline access certification – automation
Reduce provisioning time by identifying and eliminating 80% of manual steps resulting in annual cost savings in audit and remediation costs
Create access policies to ensure compliance
Lower ERP total cost of ownership
Improve SoD and Access Controls testing time by Accelerate ERP Access approval time by identifying valid Segregation of Duties conflicts before the roles are assigned to users
Listen to our Client Services Director Navinder Kaplish to find out how our customer achieved a converged IAM platform.