28 Feb 19 Part 6: Taking it to the Next Level with Remediation
You’ve identified and analysed your access-related risks and you’ve cleaned up the results.
In terms of access-related risks, once identified you basically have 3 choices of what to do next…
- Do nothing
Perhaps just having visibility of the risk is enough and so no further action is needed.
- Mitigate the risks
When risk cannot be removed, implement some other mitigating control to try and reduce the risk.
- Remediate the risks
This is where you physically remove the risk from the system.
In this article, I will discuss remediation in a little more detail.
To remediate a risk simply means to remove it; once remediated, the risk no longer exists, problem solved.
However, remediating risk is not as easy as it sounds and comes with a number of issues…
Remediation can be a complex task.
Consider a system with…
- Thousands of users
- Hundreds of responsibilities
- Thousands of menus
- 10’s of thousands of functions and concurrent programs
- Millions of individual access points
- You have identified 100’s of thousands of conflicts
Now imagine you have been given the task of remediating all of the risks. In reality, we doubt all risks could ever be fully remediated, but the chances are a lot of them can. Reviewing the security configuration of your system to make it as risk-free as possible is inevitably going to be a complex task.
Given the volume of data likely involved, the process of remediating the risk will likely be very time consuming; there will be a lot of data to wade through and a lot of manual effort needed.
Since there will likely be so much data to work through and a lot of effort needed, chances are that errors can creep in. You may find that the wrong access has been revoked which will ultimately mean a user is missing key functionality until the problem is resolved.
Not All Risk Can be Remediated
Remediation should be used with caution; it is not a case of here is a list of risks, now just remove them all; there are times when some risks just cannot be removed because a user needs the access to allow them to perform their daily duties. Sometimes you might just not have enough staff to be able to fully segregate the duties. In any case, great care should be taken when remediating risks.
Ways to Remediate Risk
Remediation can be done in a number of ways; here is an overview of some of the methods of removing access related risk from Oracle EBS.
- Revoke access to the conflicting responsibility
This is the simplest method of remediation and involves nothing more than revoking access to the responsibility where the risks have been found; it may be the easiest way to remediate but of course, revoking access to an entire responsibility will prevent the user from being able to access anything in the responsibility.
- Add function and/or menu exclusions for the conflicting responsibility
Functions and entire sub-menus can be excluded from the responsibility. This feature is especially useful when creating similar, less privileged responsibility that is based on a super user or manager type responsibility. Care should be taken when creating exclusions because it will apply to all users who have access to the responsibility.
- Amend the conflicting menu
Modify a menu to remove risk. Care should be taken because a change to a single menu could affect many other menus and responsibilities that share the same menu structure.
- Revoke access to the conflicting responsibility and replace with one less privileged
There may be several similar responsibilities that are all related to a job role or area of business; for example, normally you would expect to find multiple payables responsibilities, each with progressively fewer privileges and so sometimes remediation may involve the “swapping out” of one responsibility for another with fewer privileges.
- Create a new responsibility with the risks removed
This is essentially the same as the previous option but the less privileged responsibility does not already exist. You will need to create it either by sharing the same menu as the original responsibility and excluding the risks or by creating an entirely new responsibility.
- Amend the problematic request group
Modify the request group where the risks were found (when the risk is related to a concurrent program rather than a function). Care should be taken when choosing this option; a change to a single request group could affect many other responsibilities and user.
Most organizations that are embarking on a remediation effort will likely use all of the above options depending on exactly what the remediation requirements are. Often the amount of remediation that is needed is so much that the remediation effort can turn into more of a role/responsibility re-design project.
Our SoD solution, CS*Comply includes a whole host of functionality that can help you with your remediation efforts; we’ve bundled these features together into what we call the Remediation Toolkit and this includes…
- What-If Analysis
A tool that allows you to ask the question, “what risks will be introduced if we assign this responsibility to this user?”; this is a great tool to have when remediating risk because it can greatly help with responsibility and menu design.
- Menu Cloning
Menus in Oracle EBS are hierarchical in nature and some of them are huge; creating new menus can be very time consuming and error prone; the menu cloning feature can greatly speed up the process of creating new multi-level menus and help reduce errors.
- Request Group Cloning
Like menus, request groups can be huge and so creating new request groups can be time-consuming and error-prone. The cloning feature greatly simplifies the process.
- Responsibility Assignment Toolkit
We include several tools to streamline the process of assigning and revoking multiple responsibilities to multiple users very quickly.
- Remediation Reports
Several reports are included that are geared toward remediation.
Want to find out how we can help you remediate access related risk in Oracle EBS? Get in touch today and ask us about CS*Comply.
Next Week & Early Access
The next article in this series is “Concurrent Programs are a risky business too“.
If you want to get access to these articles before anyone else, please subscribe to our newsletter.