RE:[sap-security] SAP SOD AUDIT REMEDIATION
Posted by
Admin at
|
Share this post:
|
|
0 Comments
 | Posted by chris_van_schijndel (SAP Security Manager) on Apr 25 at 12:59 PM |  Mark as helpful |
Hi Richard,
OK no easy answer to this one in that case. As Lee suggests, going forward an investment in GRC, Approva or something that gives better functionality is going to be the way forward but here are a few suggestions for a workaround short to medium term...
1)I'm not sure how the Deloitte tool works but my guess is that it will basically pull data out of SAP and will compare it to a client-side ruleset in MS Access, ACL or similar. If this ruleset works by defining critical processes in isolation, e.g. PO create, post vendor invoice, GR, etc. then if you can get this data rather than conflicts, you can then map critical processes to composite roles and then load the mapping of composite roles to critical processes and roles to users in MS Access and work out from there which critical processes conflict with each other and thus determine conflicts at user level or at least across combinations of composites. Of couse you'll miss instances where the combination of roles together gives an additional critical process but 80/20 it would get the job done.
As an aside, to my way of thinking, if you really want to nail excessive access, this critical process view is really essential. SOD conflicts are just a sub set of this and while they represent risk, if every user in your environment can create vendors or post journals you can?t really say your access is clean or that 1000 users with one of these is less risky than one user with a conflict. Furthermore if you don't have this nailed you'll be for ever remediating conflicts that shouldn't be there rather than looking to compensate ones that you can't segregate. Net, if you get a handle on critical processes in isolation you?ll deal with many conflicts in the process so it?s probably a worthwhile investment.
2) If the ruleset does not define individual critical processes then compare them to find conflicts in this way and rather looks for all authorisations needed for both sides of a given conflict in one hit, then you could try to update the rule set to create an alternative version where you basically split out each side of the conflict to achieve the data set I suggest above which you can then analyse in MS Access. Again, I think this would be a worthwhile exercise for the reasons given in (1). This would also be transferable to other future tool such as GRC or Approva.
3) If you can't get the data out of the tool, another option would be to look at this rule set and run the same individual process level queries manually in SUIM for user or composite role and then once more do additional crunching in MS Access. You might be able to restrict this only to the most high risk conflicts and only to the composite roles which are assigned in combination to lighten the load.
4) Finally, as a last resort cludge, depending on how many users have more than one composite you could just create a dummy composite (Z_J_SMITH) for each user with more than one composite which would contain all of the single roles assigned to that user. This would be purely for the sake of reporting in this tool (roles would not be assigned real users). Potentially a lot of dead effort but it would get the job done within the confines of the tool. If you?re stuck with this thing for a while you could even get a relatively simple abap built to do this on a regular basis.
Hope this helps!
Chris v S.
---------------Original Message---------------
From: Richard Cunnings
Sent: Saturday, April 24, 2010 7:23 PM
Subject: SAP SOD AUDIT REMEDIATION
> Hi Guys
>
> A big thanks to Donn,Alex,Lee, bpoulos,& Chris , i really appreciate excellent input .
>
> This is how the Audit was run by Deloitte they basically had a test user per Composite role, so our report has SOD's for each Composite,unfortunately they can not run it via a combination of Composite roles as this is some thing their tool can not do:-)
>
> What would you guys advise regarding this matter? We need to know the risks via a combination of Composites as we do assign more than 1 Composite to some users.
>
> Once again thanks Guys.
> Richard
__.____._ OK no easy answer to this one in that case. As Lee suggests, going forward an investment in GRC, Approva or something that gives better functionality is going to be the way forward but here are a few suggestions for a workaround short to medium term...
1)I'm not sure how the Deloitte tool works but my guess is that it will basically pull data out of SAP and will compare it to a client-side ruleset in MS Access, ACL or similar. If this ruleset works by defining critical processes in isolation, e.g. PO create, post vendor invoice, GR, etc. then if you can get this data rather than conflicts, you can then map critical processes to composite roles and then load the mapping of composite roles to critical processes and roles to users in MS Access and work out from there which critical processes conflict with each other and thus determine conflicts at user level or at least across combinations of composites. Of couse you'll miss instances where the combination of roles together gives an additional critical process but 80/20 it would get the job done.
As an aside, to my way of thinking, if you really want to nail excessive access, this critical process view is really essential. SOD conflicts are just a sub set of this and while they represent risk, if every user in your environment can create vendors or post journals you can?t really say your access is clean or that 1000 users with one of these is less risky than one user with a conflict. Furthermore if you don't have this nailed you'll be for ever remediating conflicts that shouldn't be there rather than looking to compensate ones that you can't segregate. Net, if you get a handle on critical processes in isolation you?ll deal with many conflicts in the process so it?s probably a worthwhile investment.
2) If the ruleset does not define individual critical processes then compare them to find conflicts in this way and rather looks for all authorisations needed for both sides of a given conflict in one hit, then you could try to update the rule set to create an alternative version where you basically split out each side of the conflict to achieve the data set I suggest above which you can then analyse in MS Access. Again, I think this would be a worthwhile exercise for the reasons given in (1). This would also be transferable to other future tool such as GRC or Approva.
3) If you can't get the data out of the tool, another option would be to look at this rule set and run the same individual process level queries manually in SUIM for user or composite role and then once more do additional crunching in MS Access. You might be able to restrict this only to the most high risk conflicts and only to the composite roles which are assigned in combination to lighten the load.
4) Finally, as a last resort cludge, depending on how many users have more than one composite you could just create a dummy composite (Z_J_SMITH) for each user with more than one composite which would contain all of the single roles assigned to that user. This would be purely for the sake of reporting in this tool (roles would not be assigned real users). Potentially a lot of dead effort but it would get the job done within the confines of the tool. If you?re stuck with this thing for a while you could even get a relatively simple abap built to do this on a regular basis.
Hope this helps!
Chris v S.
---------------Original Message---------------
From: Richard Cunnings
Sent: Saturday, April 24, 2010 7:23 PM
Subject: SAP SOD AUDIT REMEDIATION
> Hi Guys
>
> A big thanks to Donn,Alex,Lee, bpoulos,& Chris , i really appreciate excellent input .
>
> This is how the Audit was run by Deloitte they basically had a test user per Composite role, so our report has SOD's for each Composite,unfortunately they can not run it via a combination of Composite roles as this is some thing their tool can not do:-)
>
> What would you guys advise regarding this matter? We need to know the risks via a combination of Composites as we do assign more than 1 Composite to some users.
>
> Once again thanks Guys.
> Richard
Copyright © 2010 Toolbox.com and message author.
Toolbox.com 4343 N. Scottsdale Road Suite 280, Scottsdale, AZ 85251
Toolbox.com 4343 N. Scottsdale Road Suite 280, Scottsdale, AZ 85251
Related Content
In the Spotlight
White Papers
In the Spotlight
Earn Recognition for Your Contributions at Toolbox for IT. Gain Points for Community Achievements
View this thread online
Manage group e-mails
Create an FAQ on this topic
Tell us what you think
Unsubscribe from discussion
Manage group e-mails
Create an FAQ on this topic
Tell us what you think
Unsubscribe from discussion
_.____.__ 
