Scribd Logo
Upload

Welcome to Scribd!

  • 108 views

    SOD

    Uploaded by

    Anonymous dQ6ohSOLR
    The document asks for help remediating segregation of duties (SOD) violations identified by auditors across 100 roles in a client's SAP system, outlines a process for analyzing existing roles for conflicts and ensuring new roles do not introduce new conflicts, and provides best practices for a security administrator to implement an SOD policy and role design approach.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOCX, PDF, TXT or read online from Scribd

    SOD

    Uploaded by

    Anonymous dQ6ohSOLR
    108 views2 pages
    The document asks for help remediating segregation of duties (SOD) violations identified by auditors across 100 roles in a client's SAP system, outlines a process for analyzing existing roles for conflicts and ensuring new roles do not introduce new conflicts, and provides best practices for a security administrator to implement an SOD policy and role design approach.

    Original Description:

    Segregation of duties risk remediation

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document asks for help remediating segregation of duties (SOD) violations identified by auditors across 100 roles in a client's SAP system, outlines a process for analyzing existing roles for conflicts and ensuring new roles do not introduce new conflicts, and provides best practices for a security administrator to implement an SOD policy and role design approach.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    108 views2 pages

    SOD

    Uploaded by

    Anonymous dQ6ohSOLR
    The document asks for help remediating segregation of duties (SOD) violations identified by auditors across 100 roles in a client's SAP system, outlines a process for analyzing existing roles for conflicts and ensuring new roles do not introduce new conflicts, and provides best practices for a security administrator to implement an SOD policy and role design approach.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 2

    How to remediate issues with Segregation of Duties

    LordVader asked Jul 8, 2010 | Replies (6)

    Hello Security Experts, I have been assigned to a project in where the client needs help on SOD remediation. The client has approximately 100 roles in the production environment and many of them have been pointed out by the auditors that they have SOD violation. The client also wants to create 10 new roles, but they wanted to be sure that these new 10 roles will not have SOD conflict with the roles already in place. The client also wanted to know how a Security Admin can tell which roles have SOD conflicts. 1. What is the process to follow to find out which roles have SOD conflict? The SOD matrices that the client have were done by a outsource Security Admin working and at the moment the client does not trust these matrices. 2. What is the process to follow for creating new roles and make sure that they do not have SOD conflict with the roles already in place? 3. What is the Security Admin responsibilities regarding SOD violations? 4. Is the Security Admin the one to decide what authorization should be in each role? 5. Who is in charge of the SOD policies? 6. What role design should I apply ( I was thinking on Job based role)? 7. - Is there an SAP best-practices approach for Small and medium sized businesses for Segregation of Duties? If yes, please let me know where I can get that.

    I know they are many questions, but honestly I need your help on this matter, please help me. Lord Vader
    Join this group

    Popular White Paper On This Topic

    Unified Communications: Features & Business Value

    6 Replies

    Alex Ayers replied Jan 1, 0001 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.

    You might also like