28 Feb 19 Part 6: Taking it to the Next Level with Remediation
Taking it to the Next Level with Remediation.
You’ve identified and analyzed your access-related risks and you’ve cleaned up the results.
Now what?
In terms of access-related risks, once identified, you have three 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 you cannot remove the risk, implement some other mitigating control to try and reduce the risk. - Remediate the risks
Physically remove the risk from the system.
In this article, I will discuss remediation in a little more detail.
To remediate a risk 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 several issues…
Complexity
Remediation can be a complicated 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 consider being tasked with remediating all of the risks. In reality, I 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 complicated task.
Time-Consuming
Given the volume of data likely involved, the process of access related risk remediation will probably be very time consuming; there will be a lot of data to wade through and a lot of manual effort needed.
Error-Prone
Since there will likely be so much data to work through and a lot of effort needed, the 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 essential functionality until the problem has been 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 remove them all; there are times when some risks just cannot be eliminated because a user needs the access to allow them to perform their daily duties. Sometimes you might not have enough staff to be able to segregate the duties fully. In any case, great care should be taken when remediating risks.
Ways to Remediate Risk
Remediation can be done in many ways; here is an overview of some of the methods of removing access related risk from Oracle EBS.
- Revoke access to the conflicting responsibility
The simplest method of remediation involves nothing more than revoking access to the responsibility where the risks were 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 menu exclusions for the conflicting responsibility
Functions and entire sub-menus can be excluded. This feature is especially useful when creating similar, less privileged responsibilities that are based on a superuser or manager type responsibility. Care should be taken when creating exclusions because they 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, you usually 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 are found. Care should be taken when choosing this option; a change to a single request group could affect many other responsibilities and users.
Most organizations that are embarking on a access related risk remediation effort will likely use all of the above options depending on precisely 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.
Remediation Toolkit
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
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 significantly help with responsibility and menu design. - Menu Cloning
Menus in Oracle EBS are hierarchical, and some of them are huge; creating new menus can be very time consuming and error prone; the menu cloning feature can significantly 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 dramatically 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 with access related risk remediation 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.
No Comments