Skip to Content
author's profile photo Former Member
Former Member

GRC Risk Mitigation: B009

I am working with some of the business units to mitigate GRC risk B009. However, the risk stem from the System Administrator role here at our organization. How have other managed to mitigate the risk that is probably commonly held by systems administrator (since they need a wide array of access). Comments and tips appreciated!

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Oct 05, 2009 at 05:09 PM

    Our security team severly limits the actions of the System Admins in production. For example, table maintenance is not allowed in production. This is only needed by the System admin once in a while, so we have Firefighter ID's they can use when they need to update tables. At first, they argued that they would be in as firefighters all the time, but in reality, it isn't so. So we get around most of the mitigations by having the security team make sure that access in production is "Display" only and we use Firefighter ID's with a process around it when needed. Just as long as the System Admins aren't limited in "doing their job", they are okay with it.

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member

      I have also approached it in a similar way to Peggy.

      Trying to convince basis and system administrators that they actually don't need that access in production very often is a difficult task but it is achievable.

      I would look carefully at the rules which you have stipulated and try to understand the key ones for consideration. Try to remove any unneccessary triggers in the first instance. You may wish to use ST03 to try to find evidence of how frequently they access the key transactions.

      Consider using SPM to give back the access which you are removing from them in a more controlled way as that may increase the buy in of the team members.

      Don't give up!!

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.