Hi,
This situation is not as uncommon as you may think.
It would appear that the right stakeholders are not involved or have enough
influence to raise the agenda of SOD's to a level that people actually do
something about them. If the service provider is doing the SOD checking
then I assume that they are doing it as part of a contractual agreement and
that they are required to remediate issues found internally or by external
audit. If that is the case then your client needs to take them to account
and stop paying for that service unless they are happy with the quality.
There is no disagreement that SOD tools make the identification, remediation
and monitoring of SOD's much easier. Much more importantly than that is
that the companies key SOD risks are identified and there is a process to
manage them. The SAP GRC Access Controls suite is one tool to manage them
but not the "default" best option as it depends on a number of factors.
Don't forget that there is inbuilt SOD checking functionality in SAP
(program RSUSR008_009_NEW) that can be set up to perform rudimentary
checking based on a ruleset that you need to define.
Have fun & good luck.
On 10 July 2010 08:01, LordVader via sap-security <
sap-security@groups.ittoolbox.com> wrote:
>
> Posted by LordVader (Basis/Security)
> on Jul 10 at 9:16 AM 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
| |  Alex Ayers
SAP Security Helper
Posted helpful replies on 5 threads in a group to earn a Bronze Achievement Related Content White Papers
In the Spotlight  _.____.__ |
Mark as helpful
