Not at SAPPHIRE NOW + ASUG Annual Conference? Get your GRC Fix, Right Here, Right Now.

Let’s talk about risks baby, let’s talk about you and me. (SALT N’ PEPA PEOPLE, C’MON! Live a little!).

If you’re like me, lonely and depressed because you’re missing SAPPHIRE/ASUG 2014, well let’s pull ourselves up from our boot straps and start talking GRC, together (forever!). #postgradsap : Turning frowns upside down since 1989.

Today I will be discussing the steps to take to mitigate risks (both SoD risks and critical actions risks) with the help of GRC. So we’ve implemented GRC Access Control (10.0 or 10.1 respectively) and we have run batch risk analysis against all relevant systems. Now we are left with a slew of information, what to do next? Well my friends, it’s time to clean house.

Steps to Clean Up Your Segregation of Duties (SoD) Risks:

  1. Run batch risk analysis by users and roles at permission level for SoD Access Risks.
  2. Determine the roles that are assigned to users that have inherent SoD violations. Make role changes as necessary to remove one side of the conflict from roles with inherent violations (a task based approach to your role design will work best when trying to do such remediation tasks).
  3. Re-run batch risk analysis by user at permission level for SoD Access Risks.
  4. Determine roles that are assigned to users that have one side (or part) of the SoD conflict. Should these roles actually have this access and are the roles properly defined to indicate as such? Make any role changes as necessary.
  5. Determine users that have SoD violations and remove one or more roles from their user master record if the access is not required.
  6. Create and assign mitigating controls as necessary for the remaining and unavoidable SoD violations.

 

Steps to Clean Up Your Critical Action Risks:

  1. Validate the critical action rule-set… Ensure that risks are appropriately defined and actions/permissions correspond to the risk definition. Make changes to the rule-set as necessary.
  2. Run batch risk analysis at role level and user level for Critical Actions
  3. Determine roles that have critical actions. Should these roles actually have this access and are the roles properly defined to indicate as such? Make any role changes as necessary.
  4. Look at users who still have critical actions. Should these users have this access? Make user master record changes as necessary.
  5. Create and assign mitigating controls as necessary for remaining critical actions.

 

If you are at SAPPHIRE, don’t forget to stop by booth #339 and visit @itelligence_US!

Tuesday Shmoozeday,

@PostGradSAP

Tracy

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s