Business Risks / Rule Set

April 22, 2014 | 8,423 Views |

Alessandro Banzer

more by this author

Retagging required
business riskGovernance Risk And Compliancegovernance risk and compliance sap grcgrc 10ruleset

 share 0
 share
 tweet
 share

Follow RSS
To get a better understanding how a business risk occur, we have to understand the process how GRC
identifies a risk and its key terms which are used. One or more business risks can be covered in a rule set
which is also shown below. Let’s start with the key terms which are used by specialist to talk about GRC.

Key Terms

Business Process – used to classify risk, rules and rule sets by business functions. E.g. Order to Cash, Purchase
to Pay, etc. are all types of Business Processes. All risks and functions are assigned to business processes.

Business Risk – identify potential problems your enterprise may encounter, which could cause error or
irregularities within the system.

Business Function – identifies the tasks an employee performs to accomplish a specific portion of their job
responsibilities. This can be analogous to a role, but more often a role comprises multiple functions.
Actions – known as transactions in SAP. To perform a function, more than one transaction may be required to
be performed.

Permissions – authorization object in SAP, which form as part of transactions.

Risk Rule – possible combinations of transactions and permissions for a business risk. More about risk rules
and types of rules can be found here.
Rule set – categorize and aggregate the rules generated from a risk. When you define a risk, you attribute one
or more rule sets to that risk. Similar to business processes.

Belows graphic shows the architecture of a Business Risk. Basically two business functions, for example
accounts payable payments and vendor master maintenance, are defined as a business risk. The business risk is
called “SOD required between accounts payable payments and vendor master maintenance” and says that this
two functions should be segregated properly. The business risk, technically named XGPR0005 in my example,
is assigned to a rule set. While analyzing the user, GRC compares the rule set with the actual authorization in
SAP. Technically GRC compares the given authorization by the rule set and the actual authorization in SAP on
permission level and reports if there is a match which should be segregated.
To make it more clear another graphic specifically designed for the above mentioned SOD
conflict „SOD required between accounts payable payments and vendor master data
maintenance“.
As seen above business risks are a combination of two business functions which shouldn’t be performed by
one single person. One or more business risks can be categorized in a rule set which is required to run the risk
analysis. Another example, based on the architecture shown above, shows a typicall example of a rule set.
This example also shows that a business function (here Business Function 2) can conflict with one or more
other business functions. Let’s say Business Function 2 is “Accounts payable payments” which is conflicting
with “Vendor masterdata maintenance” (shown as Business Function 1) and as well with “Bank Reconciliation”
(shown as Business Function 3). Hence it might be possible to have a business function assigned in two or
more business risks.

I hope this document helps to understand the concept of a rule set and how a rule set works from its
architectural point of view.

Please do not hesitate to collaborate and share your knowledge.

Best regards,

Alessandro
Rule set – Rules & Rule Types
April 28, 2014 | 18,853 Views |

Alessandro Banzer

more by this author

SAP Access Control
Governance Risk And Compliancegovernance risk and compliance sap grcgrc 10rule setrule structure

 share 0
 share
 tweet
 share

Follow RSS
In regard to my document about Rule Set / Business Risks I would like to give some detailed information
about rules and rule types. As we learned rules (or risk rules) are possible combinations of transactions and
permissions for a business risk.
Rules must be generated when ever risk contents change. This can be done in SPRO (GRC > Access Control >
Access Risk Analysis > SOD Rules > Generate SoD Rules). Generally rules are combinations of actions and
aren’t maintained manually (done automatically by the program).

The number of rules defined from a risk is determined by

 the number of action combinations, and

 permission/field value combinations contained in each function of the risk.

The following graphic shows the rule structure in more detail:

Now let me give you a short overview of the different types of rules considered by GRC.

Transaction Rules
Rule components are as follows:

 System
 Conflicting Actions
 Rule ID
 Risk Level
 Status

Example (from the graphic above):

F001001: Maintain fictitious GL account & hide activitiy via postings

F001001 – Risk ID

F001001 – Action code combination number (represents Conflicting Actions)

Permission Rules
Rule components are as follows:

 System
 Object
 Field
 Rule ID
 Risk Level
 Status

Example (from the grapic above):

F00100101: Maintain fictitious GL account & hide activity via postings

F00100101 – Risk ID

F00100101 – Action code combination number

F00100101 – Object combination number

Critical Action
List of actions considered critical. Option to run at both Action and/or Permission level. Critical Actions are
created same way as Segregation of Duty risks, exept Risk Type = Critical Action, and can contain only 1
function (as shown above with SCC4).

Critical Permission
List of objects/permission considered critical. Created same way as Segregation of Duty Risks, exept Risk
Type = Critical Permission, can contain only 1 function, and function cannot contain actions.

Critical Roles and Profiles

Roles and profiles considered critical. Critical roles and profiles will be excluded from analysis if the
configuration parameter 1031 (Ignore Critical Roles & Profiles) is set to YES.

Organizational
Used to eliminate false positive SOD reporting based on organizational level restrictions for users.
Organziational rules should not be created for mass org level reporting as it should only be enabled for
functions that you specifically need to segregate. Most companies are controlling what data a user has access
to via role assignment. There are only very few companies who have a business need to create org rules. Please
find more detailed information in Organizational Rules in GRC Access Control.

Supplementary
Additional security parameters other than authorizations a user must have to enable access. First checks to see
if the user exists in the supplementary table, then checks if conditions are met. Based on exclusion setting, it
will include or exclude the user in the risk analysis.

Please share and contribute in this document to make it better.

Looking forward to hear from you.

Best regards,

Alessandro
ARA – For the new kid on the block
August 27, 2014 | 6,679 Views |

Former Member

Retagging required
acaccess controlara;Governance Risk And Compliancegovernance risk and compliance sap grcrisk and compliance

 share 0
 share
 tweet
 share

Follow RSS
G’Day All,

Considering the fact that so many people out here, have so selflessly shared their expertise through blogs,
answers etc. So its only fair that I do my bit to balance the scales. Now if what I contribute is worth it or not,
that’s a different story and I shall leave it to the moderators to judge for themselves.

The topic I would like to present to you is ARA. Just a heads up that whatever is presented here is just an
overview of my understanding of what ARA is and how it works. I’ll leave it to the experts here to make
corrections/suggestions if the need be for the benefit of everyone reading this document and myself included.

A lot of the key terminology has been explained rather brilliantly by Alessandro in the following two
documents, so there is no point in me trying to reinvent the wheel.

http://scn.sap.com/docs/DOC-54434
http://scn.sap.com/docs/DOC-54530
So here we go.

Access Risk Analysis – ARA

Analyzing Risks associated with Access

Risk: when an Employee in a Company is assigned with Task/Tasks that could provide him/her with an
opportunity to commit fraud
 Access Risk Analysis – ARA

Analyzing Risks associated with Access

Employee -> Company -> Task/Tasks -> Opportunity -> Fraud

Tasks are assigned to the employee in form of Roles, which are made up of Actions/Tcodes, which in turn are
made up Permissions/Authorizations

Workshops with BP Owners and other relevant personnel would have to be conducted to gather information
about the Risks associated with the following:

Roles -> Actions/Transaction Codes -> Permissions/Authorizations

Role1 Action1 Action2 Permission1 Permission2

Role2 Action3 Action4 Permission3 Permission4

Based on the information gathered we need to define the Risks

. Action1= Conflicting Action .Action2= Conflicting Action. Action3= Critical Action .Permission1= Critical
Permission

Function1= Action1 .Function2= Action2 .Function3=Action3 .Function4= Permission1

Risk 1= Function1+Function2 . Risk 2= Function3

Rule is a condition: If Function1+Function2 is given to a user Then it is a Risk

Therefore Rule1 is generated against Function1, Function2 and Risk1

*Example: Action1= XK99: Vendor Mass Maintenance .Action2= ME2L: Maintain Purchase Order – Purchasing

Risk= Create a fictitious vendor and initiate purchases to that vendor

Run a Risk Analysis against all the Risks defined

 Access Risk Analysis – ARA

Analyzing Risks associated with Access

Based on the Analysis, Remediate the Risks by executing cleanup process by Re-designing/defining the roles.

This can be done through Simulation to check if the defined Risks will be eliminated if the cleanup is
executed.

In certain unavoidable circumstances Remediation isn’t an option, so the solution is to Mitigate the Risk

Mitigation

Prevention Detection

Mitigation Control

Audits

Super User Access Alerts

So when you create a Mitigation Control:

You specify the Risk Ids and the OU they are associated with-> The Risk Ids will look up the Function they are
associated with->

Functions will look up the Actions (T-codes) they are associated with. Assign an Owner and Controller to the
MC and

tie all of this up to an end user/role/profile who is assigned with a role/roles, which could pose a threat.

To Ensure all the hard work done so far does not go for a waste, run
 Access Risk Analysis – ARA

Analyzing Risks associated with Access

SOD review, Audit Trails and Risk Analysis on a periodic basis

SOD Management Process

The entire process described above is termed as ‘SOD Management Process’.

Segregation of Duties (SoD) is an internal control within a Company implemented to prevent or decrease the
risk of errors or regulatory irregularities and ensure corrective action is taken. Ideally, no one individual must
have the authority of:

Creation .Modification .Reviewing .Deletion

SoD ensures no single user has access to separate phases of these business transactions. This is done by
Dividing, Distributing and Allocating key tasks amongst various individuals thereby eliminating or at least
reducing the possibility of errors and fraud. All of this is carried out in three separate phases:

Phase 1

Risk Recognition

Rule Building & Validation

Phase 2

Risk Analysis

Remediation
 SOD Management Process

Mitigation

Phase 3

Continuous Compliance

*Credit for the following SOD Management Process flow goes to: Alessandro & Colleen

Steps Description

Gather a list of applicable SOD conflicts that allow fraud or

generate significant errors. The outcome of this step is that
your business has determined what is an unacceptable risk
that they want to report on and manage via remediation or
mitigation.

Helpful documents:

Risk Lifecycle
Build the rule set based on the recognized risks from step 1.
The outcome of this step is the technical rule set to analyze
the user and/or role assignments.

Helpful documents:

Business Risks / Rule Set

Rule set – Rules & Rule Types
Analyze the SoD output. This can be performed with the help
of SAP GRC Access Control. In case of manual analysis, for
each user, analyze if he/she has the access to perform any of
the conflicting functions defined in step 1. The outcome is
basically to provide the business insight to alternatives for
correcting or eliminating discovered risks.

Helpful documents:

Online vs. Offline Risk Analysis

 Steps Description

In this step, evaluate if the conflicting tasks can be performed

by an alternate person. If so, role changes and/or user
reassignments can be performed to segregate duties properly.
The outcome must be a very low number of remaining risks
that need mitigation.

Helpful documents:

Remediating Access Control SoD Risks

If it would not be possible to remediate the existing conflicts,
consider formulating an appropriate control to mitigate the
risk. This would typically entail working with the business to
setup additional monitoring procedures that ensure to
compensate the risk. The outcome must be no remaining
risks.

Helpful documents:

Internal Controls – a step towards strong controls

Defining Mitigating Controls / Compensating Controls
Creation of Mitigation Controls in GRC 10.0
Mitigating Control Lifecycle
Finally, establish a new continuous process wherein every
access request is reviewed against the SoD conflict matrix
prior to provisioning on the system. Also make sure that all
role changes must be analyzed and remediated before
implementing. The outcome, and also final result, your
system remains clean.

Helpful documents:

Approve/Reject Own Requests

Risk Terminator on SAP Wiki
Configuration in a Nutshell

Now that we’ve covered the what and the why part we have to get our hands dirty and physically create
them. If you have access to a Server, after following SAP documentation for ‘From Post-Installation to First
Risk Analysis’ and ‘Enhanced Access Risk Analysis’, try executing the following tasks:

1. Create test users using SU01

2. Create test roles with Critical/Conflicting Actions using PFCG
 Steps Description

3. Assign role/roles to test users including roles for Risk Owner , Mitigation Controller
4. Create Access Control Owners in NWBC
5. Activate/Check following BC Sets using ‘SCPR20’
o GRAC_RA_RULESET_COMMON
o GRAC_RA_RULESET_SAP_R3
o GRAC_RA_RULESET_SAP_HR (Optional)
6. Check Configuration Parameters of Risk Analysis: SPRO -> IMG -> GRC -> Access Control ->
Maintain Configuration Settings
o Risk Analysis
o Function Maintenance
o Mitigation Maintenance
o Change Log
7. Create/Check Business Process and Sub Process: SPRO -> IMG -> GRC -> Access Control ->
Maintain Business Process and Sub processes
o This will come in handy when creating Functions and Risks
8. Create Organizations: SPRO -> IMG -> GRC -> Shared Master Data -> create a Root
Organization Hierarchy
o You cannot create a Mitigation Control without this
9. Add Owners to the created Organization in NWBC: Setup -> Organizations
10. Run following Sync Jobs: SPRO -> IMG -> GRC -> Access Control -> Synchronization Jobs
o Authorization Sync
o Repository Object Sync
11. Create the following in NWBC
o Functions
o Access Risks
o Mitigation Control
12. Run a Risk Analysis against the Risks at Role level and after the cleanup at User level
13. Remediate using Simulation and see if it works
14. Mitigate Risks against User/Role/Profile
15. Create Alerts: SPRO -> IMG -> GRC -> Access Control -> ARA -> Generate Alerts
16. Setup Batch Risk Analysis on a periodic basis: SPRO -> IMG -> GRC -> Access Control -> ARA -
> Batch Risk Analysis
17. Setup SOD/UAR Review

I sincerely hope this document will help you in your pursuit to get a grasp on what ARA is all about.For a more
comprehensive understanding/configuration and other bits and pieces on this topic, please check out the
links in the following document put together by Alessandro, which covers everything in detail. Please check
under Access Risk Analysis (ARA).
http://scn.sap.com/docs/DOC-57438
Regards,

Leo..