Managing SoD’s: preventive and detective controls with MARC
A while ago, our partner XS Control (Asia) posted an article on their website about preventative versus detective controls. It provides an interesting view on how you can manage the impact of risks in your organizations. Here we want to pick up the conclusions from that article and analyze how this works for the authorizations and access controls and how software like the MARC4GRC suite can help with this.
Preventative versus detective
Main advantage of preventative controls is that the related risk should not occur, or at least the impact should be minimized. It is like the Dutch saying: Prevention is better than cure! This phrase is apparently attributed to the Dutch philosopher Desiderius Erasmus in around 1500. Commonly used within health and social care strategies. More general is: ‘Better Safe than Sorry!’
That is linked to the main disadvantage of detective controls: a risk violation can be detected only after it has occurred and then you are left with trying to reduce the impact as much as possible.
But effective detective controls help discover an incident instantly, so that appropriate action can be taken to eliminate or at least limit the impact.
Preventive control: Authorizations monitoring (SoD analysis)
Having a solid framework for roles and authorizations in place (with clear naming conventions, SoD-free roles, etc.), is a good start. It is important to properly maintain this framework: transports of incorrect role changes to production and/or wrong role assignments to users can undermine the preventive protection. In our post last October (here), you can read more on the change management of roles.
When monitoring compliance of actual user access with SoD rules mitigations may be allowed. Mitigations weaken the effectiveness of preventive control. Many mitigation controls are in fact ‘detective’ in nature, and then the granted authorizations do not prevent anything. It is recommended to fine-tune SoD risks and authorization roles to a maximum extent so that occurrence of true and false SoD violations can be minimized. Then detective mitigation controls can be reduced as well.
It is quite a challenge to completely manage your user access and authorizations within a solid control framework. However, this does not justify taking short cuts. Keep in mind that you need roles and authorizations for operational reasons anyway, so it pays off to deal with it as effectively as possible.
Most important is to perform frequent checks on production for SoD issues and address the output of these checks properly.
Detective control: Access Violation monitoring
As mentioned before: mitigations will need to be allowed when user access needs to be granted, despite this access potentially violating the SoD rules. Mitigations, mostly being detective controls, trigger the need for access violations monitoring. How often these detective controls must be executed (frequency) depends on the response time necessary to address any observed output.
Also, the definitions should be as accurate as possible since you do not want to have many issues reported and certainly not too many false positives since action is required on each incident.
Detecting violations is one thing, but it is also important how quickly the business representative can respond to them and if the impact of a real issue can be reduced. It really depends on the nature of the violation reported and the issue found.
For example :
What about MARC?
MARC offers several options for reducing the risks.
First of course there is the Access Conflict Monitor (ACM) which offers in-depth, automated analysis of the user authorizations in comparison to the SoD rules defined in MARC rulebook. By scheduling this analysis to be performed, e.g. every month-end, authorizations can be monitored throughout the year.
If this ACM reporting is processed with the Risk Execution Monitor (REM) you can reduce the number of reported hits by excluding the ones where the transactions related to the risks were not executed.
Thirdly, the Internal Control Monitor (ICM) module includes pre-defined SoD risks definitions for checking on SAP document/transaction level. Based on this, SoD violations can be detected on document level by the same user (like in the example of user X posting the invoice for the PO approved by himself).
As mentioned in the article from XS Control, the preventive and detective controls should be balanced.
Only using the ICM controls in MARC looks like an attractive short cut, but it gives false positives since definitions may not be completely accurate. A short response time is required on reported issues. And without proper understanding of underlying authorizations that made the issue possible to occur, the issue may occur again in the future. The Dutch would call this ‘mopping with the tap open’…
Having a proper setup of the authorizations prevents those issues from happening. As part of the role provisioning process, it is simple to implement SoD-compliant user access without too much additional effort.
With an easy to implement and cost-effective solution as MARC is, SAP SoD’s can be well managed using a balanced mix of preventive and detective controls.