What’s the risk of giving someone too much access to too many capabilities to perform functions that maybe risky for the organization? What happens when we give someone access to key configurations that can affect how the application operates? What happens if we give access to sensitive information?

Access risk is all about giving access to certain individuals that shouldn’t have that level of access.

The challenges:

Technology changes – from on-premise to the cloud, mobile devices – there are now many ways that people can get access to technology.

The provisioning process is still very manual in many organizations. It’s performed in an ad-hoc fashion that is fragmented and exposes organizations to unnecessary risk. Each application has its own way of provisioning user access, many people are involved, requesters, users, reviewers, approvers for policy violations, compliance requirements – a lot of touch points. It’s a challenge.

There are so many people that touch multiple applications, multiple roles, there are different processes for provisioning. It’s a cumbersome process.

When we think about the process, the challenges include:

• Hundreds of adds and changes, deletes, requests every day
• Inconsistent and ad hoc with manual processes
• Platform dependent – all applications are different
• Disparate provisioning tools and workflows
• Many human touch points, help desk, IT…
• No consistent policy enforcement
• No common controls or audit trail
• Difficult to ensure compliance and access risk

It’s difficult to see where access policy violations occur if done manually.

A lot of organizations perform segregation of duties validation but it’s often done at a very high level – the responsibility/ role level whereas it needs to be done the form/function level to ensure policy violations are not happening.

When it comes to IT audits, user access is a common source of internal abuse.

How does giving people the wrong access occur?

• Orphan accounts – poor de-provisioning
• Rogue accounts – false accounts for fraud
• Privileged users – “super user”
• Entitlement creep – with role changes

A solid provisioning process is needed to mitigate this risk.

Access Policy Compliance

When you set up a role, the role decides a lot of privileges that are available to that role and the users that are granted that role. The role itself controls who has access from a function and data standpoint.

Users are given a role that comes with privileges. When you decide a role, you determine what data is available to that user. The role definition is a controlling factor into who can do what on which set of data.

Complicated Security Model in Oracle EBS

Most organisations, when they start evaluating user access, it's important for them to review what that level of access is, and ensure it’s in compliance with policies. Instead of looking at the user itself - the user will have certain roles and responsibilities, roles and responsibilities have menus, and submenus. Under those menus and sub menus, you have functions, then under functions, are forms that allow you to execute those functions. It's a very straightforward process. From a risk view point many organisations only view users’ responsibilities as to what they have access to. Many times, responsibilities are poorly defined, and because they're poorly defined, they get access they shouldn't necessarily have. From an actual risk management standpoint, you want to look at the user but you want to go all the way down to the form level.

It’s important to not only review the policy at the responsibility level but also at the form level, to make sure that the function and form is appropriate for the individual that has access to those functions and forms.

This is about managing segregation of duties where you can identify incompatible privileges and capabilities. That way, you need to manage any policy violations which is the key thing you want to manage from an access standpoint.

The provisioning process is sophisticated when we start looking at actual compliance. Every organisation needs to address certain control requirements:

• Is your ERP system access protected?
• Are you aware of any potential access violations that may exist within the ERP if I’m the person responsible for access within the application?

Most organisations have access policies that they use to determine if a person has appropriate access which is an important consideration when a person is given access.

What do you do when you identify a policy violation? What's your approach to addressing that violation? The ideal situation is to fix it in the ERP. Whatever you can, either take away user access, redesign the responsibilities, redesign the roles. Those are what have the biggest impact when it comes to policy monitoring from an SoD standpoint.

Many times it's much more complex as you're actually going through the provisioning process.

• The inability to translate corporate governance into IT policy, segregation of duties but also data privacy. Certain information is regulated as far as who should have access. You want to make sure that you’re not giving access that violates an SoD policy but also, not violating a privacy policy either.
• It’s a good idea to do control testing on a regular basis and make sure whatever controls you have in place are effective. But the challenge many times is that it’s still manual. You're faced with emails and spreadsheets, doing the testing of certain controls, obviously human error wherever you have the individuals involved is always a concern. It leads to inconsistencies when it comes to actually reviewing testing. Data is sometimes hard to obtain. Many times, when you're trying to pull out data for control testing out of the ERP it takes a lot more technical knowledge than most people have. You can leverage your current staff to do that but it's important to get the information.
• It's also difficult to help the business understand some of the issues around compliance and access - lack of transparency. As a business user, I have access to the application, but I may not understand some of the technical nuances of the access that myself or somebody else might have. It's hard to visualise what that means to the organisation. Many times, the IT terminology or processes that they go through in provisioning are not fully understood by the business.

It becomes a challenge when you're managing access to ensure that you're complying compliance requirements.

Example: User security assignment with Oracle 

When you give a user access in Oracle E-Business Suite, the user is assigned to an HR record so we know if it's an actual individual that is recognised by HR.  That individual has a password and an expiration policy. You can activate or inactivate a user with this form, a very common task for provisioning and deprovisioing process. An individual can be assigned one or more responsibilities that would give that user access into different parts of the application. When you look at the responsibilities assigned, you’ve got many menus and submenus. Each menu determines what functions and forms are available to that user for each of those responsibilities. The challenge is what it looks like underneath. It's a lot more complex than the screens that we just showed you. When someone is given user access, the different responsibilities, there’s obviously a web of capabilities underneath the technical perspective.

In this case, we see John Doe has access all the way down to the ability to initiate invoice batches. That maybe a problem for John Doe. Maybe John Doe shouldn't have the ability to enter an invoice and submit invoice batches. The recommendation might be first to take it away, remove that function. But when you do that, you could be impacting somebody else’s access, because the menus and sub menus can be shared with other responsibilities. In the image above, we can also see Mike Jones, who has access to the same end function of entering invoice batches, but he has a different responsibility, but shares one of the submenus, the AP invoice entry that gives you that access to that function. If you take it away from John Doe, it also impacts Mike Jones, so it really makes you think about making that change. You may have another payable user that has a different responsibility that can also perform a function that also shares some of the menus than the other responsibilities. As you can see, the remediation to address a person's access isn't so simple. You want to make sure when you make any changes, you're not impacting the business and their ability to operate based on the activities. The remediation process is very important and it’s a lot more involved that just taking away functions from certain individuals. This is where the root cause analysis is required for remediation. What are those responsibilities? What do I do with those responsibilities? That’s where a lot of the remediation work occurs – it’s very time consuming as you have to evolve the business process review each one of those areas.

Self-service user provisioning 

How do we improve the process so it's a consistent structure and it's auditable with validated results?

A policy-based access governance solution can help in this situation. A solution that supports multiple applications, ERP systems (Oracle, SAP, Microsoft, PeopleSoft, JD Edwards, Workday), and cloud infrastructure to bring all your identities together.

User Provisioning

Those who are involved with user provisioning, it's important understand that this is an ongoing process, the request to get access policy violations, tracking and reporting and regulatory reporting. The Provisioning lifecycle is an ongoing, continuous process that occurs between, obviously, the users of the application and the IT department. But also, whoever else might be involved in the processes such as the business owners that request to review the process. You have your help desk that initiates the effort, the actual user that's going to be given access to the application, but also your security team that's going to validate to make sure that a person shouldn't have access to what they shouldn’t have.

For self-service access management, a policy-based automated solution helps you put structure around the process. It helps you move from a fragmented approach to centralised visibility and control. In some cases, from manual to an automated solution that provides a structure around the process. You identify controls in the business process, automated process. Whatever control violations you have, when you go through the provisioning process, it does a validation as part of the process. The value is that you want to catch the violations at the beginning of the process when giving access instead of finding out when afterwards.

A solution like SafePaaS gives you the possibility to identify risk at the beginning of the process and make the determination if this is the access you want to allow. It’s user friendly, easy to use, removes a lot of the complexity of technology away from users that are reviewing the provisioning process, and helps both business and technical users. It actively measures and monitors risk associated with users and resources so you'll know where risks are coming from.

Case Study

A large auto manufacturer that had five different ERPs where they were managing not only user provisioning, but also segregation of duties requirements. Their challenge was with 5 different applications, 1000s of users initially became much more onerous task to provision users but also you want to monitor their policy impact when you get in that access. They deployed SafePaaS. They could eliminate 80% of manual steps resulting in over $50,000 in cost in audit and remediation costs, and that doesn't include the individuals involved in provisioning process. SafePaaS automated a very manual activity. We created access policies to ensure compliance goals again catching the violations at the front end of the provisioning process and not after a person has been given access. We lowered ERP, total cost of ownership, reducing the head count that had to manage the provisioning process given all the different systems that had. They've improved SoD and access controls testing time and the auditors have good access to all the information. iAccess™ tracks all the workflow approvals and can generate a report to validate who approved what. It also accelerates the ERP access approval time to identify the SoD violations at the very beginning of the provisioning process.

User Provisioning Challenges

• Do ERP roles meet requirements for all users?
• Does user provisioning prevent security policy violation?
• How do you monitor superuser activities that are mandatory in most organisations?
• How do you protect sensitive data?
• What are you doing to maintain audit trail of your configuration controls? Master data changes?
• How do you determine and ensure that the terminated employee can't access ERP?

This infographic shows a flow that helps you understand the tasks and activities that occur as part of deploying and using iAccess™. You need to start with your SoD rules. Those rules can come from our catalog or include custom rules. You need to add your active employee users, to certify those users that are allowed access in ERP. Not all employees are going to be accessing ERP so it’s a limited group of individuals that have to be certified and registered before they can get access using iAccess™. Once you register an individual, then you can request the roles and submit it for the review process, which initiates an SoD review. Any SoD rules that are violated will be identified before that person is approved access via the workflow. It can take any new responsibility or roles that are assigned to it and leverage it against any existing roles and responsibilities that are assigned. Once again it identifies what those policy violations might be – the key is before it's deployed in the ERP, then it routes round to the workflow. Let's say the workflow once the rules are finished, it does a workflow to up to five reviewers and approvers. Each one of those has the opportunity to reject, accept or add that request. Upon final approval, it can automatically update the ERP with that user. As you go through the process, you may see roles that need to be redesigned. SafePaaS Roles Manager can help with addressing and monitoring or changing any roles that are causing intra role SoD violations. You can monitor application access on a regular basis.

Before the process, you need to identify your SoD rules, what rules are important to you on the access you want to validate user access against. These roles are totally user defined, you can leverage them off our catalog or you can enter your own rules. As I previously mentioned, you have to have a user registration and a user registration can be done in mass or individually. The important point here is that you don't want to give people access that shouldn't have access. The user registration process eliminates those individuals who should never have access in the ERP. If they’re not registered, they won’t even appear to give access to. Then you receive an email notification that an individual has been registered and will be notified if there's any questions from their Manager. The workflow for user registration will dictate who the individuals are that determine who should have access.

The application has a form that you use to give an individual access. There's a username, manager name, you can also end date a user’s access here. You can also de provision individuals through iAccess™. Then you can pick and choose the roles or responsibilities and assign it to this individual for review.

We also support firefighter which is designed for managing superusers. As you go through the requesting process, we use email to notify the end user who’s going to be receiving the access, but also the workflow approvers. Segregation of duties violations can be looked at and based on results, they can approve or reject it. If they approve it, it moves on to the next step in the workflow but if rejected, it automatically stops the workflow and they are required to put a comment in as to why it was rejected. It then sends it back to the originator. Upon final approval, the ERP can be updated with that user’s access.

SafePaaS automates the entire process from requesting access, all the way through the actual provisioning of user access, and then sending emails and notifications throughout the process to keep everybody aware and eventually, as the user gets access they get a username, and a temporary password to the email they use to access the application.

SafePaaS provides sophisticated risk analytics. Once you provision the user’s access, you do the regular SoD monitoring to identify a violation of an end user in the application. The dashboards help you define a remediation strategy. If you have violations, you need to fix those violations. Our recommendation is to fix it in the ERP.  If you can fix it in the ERP it could have a significant impact on the end result of SoD. Just changing one responsibility can potentially remove 1000 violations. The dashboards provide an easy way to understand instead of looking at rows and rows of data that makes it very difficult to understand.

With Roles Manager you can build SoD compliant roles and responsibilities. Non-technical users can simply change a role outside of ERP so any changes made don’t impact day to day operations. You can identify any SoD violations that are caused by the design of that role and eliminate those.

Common questions around iAccess™

Is there a way to prevent providing role or responsibility inadvertently to a user?

Yes, we have access groups in iAccess™. You can define certain responsibilities according to their access group, and then assign users to that same access group. When you do that, the only thing that will appear is when you have matching access group. If you have a user that has the same access group, you will only see responsibilities that are associated with that. That eliminates the potential for inadvertently providing access a user shouldn’t have.

Can you manage access by privilege or superusers?

Yes, with FirefighterID capabilities. One of the things that we're seeing in the market, a lot of auditors are focusing on superuser access, because in most organisations, it's perpetual – there are no real tight controls around it. Firefighter allows you to limit a super user access for a certain period of time. When you make a request to iAccess™, it'll only give you those responsibilities that are designated as firefighter or super user. Once you get that access, it automatically shuts off based on whatever your configuration is, but then using MonitorPaaS™ you can interrogate what that person had done while they had access to those specific roles and responsibilities, so that it limits that unlimited access that they currently have, but also does a certification of what transactions and forms they touched so you can validate anything unexpected.