I've been reading a about SOD but I've never seen an explanation on how to actually do the SoD Matrix. I'm currently on a project with a company who has not performed SOD. And I would like to help them do this.
I've seen the matrix at http://www.*********************/sox_sod/sod_matrix.htm. What I don't understand is how to you know what is on the horizontal vs the vertical column.
For example, in the matrix, it has the AP Voucher Entry on both the horizontal and vertical columns. And that for this entry, there are so-and-so transactions related to it. I currently have a list of transactions, does that mean that I have to group them under similar tasks or functions?
Also, why is it that the entries are the same on both horizontal and vertical columns (i.e AP Voucher Entry, AP Payments, AP Release Blocked Inv, etc)?
What is the best approach to perform SoD?
Thanks in advance!
First of all, that particular matrix is actually the ASAP methodology matrix, but not credited as such on there. It is OK, but very, very basic and you should look to extend it to meet your companies requirements.
You are along the right lines, the matrix has sets of conflicting functions (e.g. AP Voucher Entry) and there is a flag where 2 functions should not be combined or a mitigating control identified. They are on both axes because you can easily see which ones must not be combined rather than a long list.
As implementations can use different tx for different functions, you need to ID all tx that your implementation are using for each function. This will give you a list of which transactions should not be combined as they give belong in incompatible functions.
The next step is the painful manual reconciliation of those tx to identify roles and role combinations which give a segregation of duties conflict according to your matrix. This can take a few days to do each time.
You can automate it with SAP delivered reports such as RSUSR008_009_NEW (use the search for more info) but you will need to configure them.
SoD & approaches have been covered before so use the search & you will get loads of good info.
Some important things to remember are:
Rules need to be drafted by people with good knowledge of your company and their processes. Do not solely rely on a matrix you got off the internet
Automate if possible
SoD is one form of control. Config and reporting are two others which are commonly used
There are plenty of external tools which will do it at a cost. Companies like SAP (GRC Access Control Suite - Compliance Calibrator), Approva, CSI all have products which offer SoD's, as does the report which I mentioned earlier.
Main issue here is that setting up the SoD matrix is NOT the reponsibility of the Security administrator. This should be in the hands of the controller or someone who is assigned the task by the controller. And business consultants must be involved as they know what is causing conflicts beter than anyone else.
Auke Visser wrote:
> Main issue here is that setting up the SoD matrix is NOT the reponsibility of the Security administrator. This should be in the hands of the controller or someone who is assigned the task by the controller. And business consultants must be involved as they know what is causing conflicts beter than anyone else.
Yes and No.
An experienced security administrator should have enough understanding (though we all have to start with zero) of business processes and risk management to co-ordinate the collation of the data from the business, internal audit, risk management etc.
As the security admin is typically the person who will be using it, there is a vested interest for them to be involved in the process - something which the original poster appears keen to do. If the rules are incomplete or there are SoD violations etc, the finger will first be pointed at the security admin so might as well do something positive about it
Just because Its not the 'Responsiblity' of sec admin how can;
1. The SEC admin turn not know or show inteset to get to the bottom of it? or on top of it !!
But the poster's concerns are valid..I recall I myself posted this but did not get an satisfactory answer !
Th eneed is very simple ...We need to create a SoD Matrix..help us to understand various ways to do it ..may be this forum need to get really VOCAL..I mean VOCAL disucssion with JAAWs ( Juluis Alex Auke Wolf..) Lecturing to us !! JAAWs can you please move this idea to SDN board , Please ?
In one of the discussions about SOD in earlier times, there was real good post by Justin Dundas-Smith about an approach he uses. See Virsa CC Implementation Process
What I liked about it is what Alex has also indicated: get out there and find out which requirements really exist for the business and finance processes, where they want a system control to segregate certain tasks as being incompatable with others. The ones which they themselves would like to have analytical information on, and build SOD rules for those from scratch.
I would think that once you have your "foot in the door" and support from the business and finance folks, then expanding the rule sets to include risk management, audit, any possible legal requirements which force a specific SoD (there are a few) should not be hard to add on to the analysis.
SoD within IT might however be a different nut to crack
Julius Bussche wrote:
> In one of the discussions about SOD in earlier times, there was real good post by Justin Dundas-Smith about an approach he uses. See Virsa CC Implementation Process
I had a few beers in Vegas with Justin a while back (GRC2007) and he certainly knows his stuff!