Announcement:
wanna exchange links? contact me at sapchatroom@gmail.com.
Posted by
Admin at
Alex Ayers,
The situation with this client I could say is unique. The lack of confidence with the present service provider is very poor. Probably is also to the fact that the client doesn't understand the whole concept of SOD and it doesn't accept that they cannot have a system completely free of SOD conflicts if they continue doing everything manually.
You are correct this is the client that wants to install an old version of Virsa, but the client has decided not to install it at the moment. The client is mostly interested in resolving their SOD conflicts and to maintain there system free of them.
I explained to the client that resolving their SOD conflicts can be resolve manually, but it will take some time to be completed and there is no warranty that the system will be free of SOD conflicts in the future. I also advised the client that the best solution for them to be free of SOD conflicts is to install the latest version of GRC, but the client insists in continuing with the process they have at the moment (manually updating excel sheets).
You have been very kind in helping me and sharing your experience, the steps you have recommended me is what I am going apply.
Thank you very much again for your support and please wish me luck.
Lord Vader
---------------Original Message---------------
From: Alex Ayers
Sent: Thursday, July 08, 2010 4:40 PM
Subject: How to remediate issues with Segregation of Duties
> Hi,
>
> You could write a book on the below & a few of us earn our living doing this
> exact thing so here are a few tips:
>
> 1. You need a set of rules to run your SOD's against - regardless of whether
> it is manually done or using an external tool. If you client do not have
> confidence in the rule set that is being used then what on earth do they
> think they are doing by placing reliance on it? Any rule set must be tailored
> to the clients key risks and they must focus on this asap before you do
> anything else. If this is linked to your post about implementation of GRC,
> then before you start running any analysis etc, get the rule set out to the
> business and get them to ID what risks are material to them and base your
> reporting on that.
>
> Once the rules are identified (at the most basic level create functions that
> represent sets of activities, map tcodes to those functions. Business then
> ID's which functions are in conflict e.g. AP processing & vendor
> maintenance). You can then analyze your single role contents against these
> conflicting functions (very boring if you are doing it manually) and then ID
> role combinations that should not be grouped together. This is how SOD's
> have traditionally been done and is how the tools work.
>
> 2. Take the matrix that you have done in point 1 and apply that to your new
> roles.
>
> 3. It depends on the company, the situation, the ability of the admin. If
> you have a good understanding of business process risks and understand your
> clients business processes then the security admin could be running most of
> this. If not then sec admin typically performs the analysis and lets people
> from the business choose what they want to do with it.
>
> 4. As above, it depends on the ability/knowledge/experience of the security
> admin. Personally I believe the security admin should be able to take a set
> of business requirements and translate them into the technical restrictions
> built into the roles.
>
> 5. Usually internal audit or an equivalent risk management team
>
> 6. If you are doing it manually, job roles (assuming that they are SOD free)
> can make it easier to assign, especially if you have policy of only 1 job
> mapped to a user at a time. On the flip side, if company combines job roles
> for a user, there are usually lots of SOD's. If the client only have 100
> roles now, then in reality the practical differences between a task based
> design (as much as I dislike them) and job based design are minimal. Task
> based approach + an incompatible role matrix could be easier to manage in
> long term if there is no investment in a tool. If you are going through the
> process then I would seriously recommend looking at a tool to help. CSI
> authorization auditor is an excellent product at a very reasonable price.
>
> 7. SAP are not experts in risk management and SOD's (though they do have a
> few who know their stuff).
> For SME's there needs to be a pragmatic approach that focuses on the really
> important risks to the company. This is an area that you should work with
> the internal and external auditors to agree on the scope. Traditionally,
> generic rule sets provided by vendors are designed for large companies where
> good SOD can be achieved through having lots of people to share activities
> between. In this case it is really important to focus on only the key risks
> to avoid paralyzing the business by coming up with recommendations that
> cannot be realized.
| __.____._ Copyright © 2010 Toolbox.com and message author.
Toolbox.com 4343 N. Scottsdale Road Suite 280, Scottsdale, AZ 85251
| | Related Content White Papers
In the Spotlight  _.____.__ |
Mark as helpful
