Gratitude:
Thanks to the people of SAP who contribute their effort towards compliance to deliver readymade Global SoD Ruleset for SAP and Non-SAP products in the form of BC-set.
Storyline:
Building SoD Rules for SAP ABAP stack applications are known framework including SAP PI/PO ABAP stack. What about SAP PO Java stack?
Saying:
Sincerely, I would like to dedicate this blog to the people who helped me in my professional journey.
Start:
SAP delivers the standard SoD ruleset for SOX listed SAP products. There are some products may or may not be SOX listed, depends on customer’s practice such are “SAP PO, Solution Manager, GRC so on...” aren’t covered in standard SoD ruleset.
The purpose of this blog is to address the fundamentals and considerations while working on SoD Ruleset setup and possibility of SAP GRC AC ARA for SAP PO Java.
Note: ARM and BRM are already proved services for SAP PO Java.
High level possible SoD Rules for non-covered SAP products:
Why risk should be defined?
You have the freedom to design the definition from pictorial presentation below.
What is SoD and Sensitive risk in SAP ERP?
Combination of duties or functions form SoD risk, whereas Sensitive risk represents the individual duty or function.
Universal example of SoD: Creation vs Approval/Release.
Example of Sensitive: Period open and close or Client open and close.
What is function?
Function represents the task in LOB, technically it is the placeholder or container to load the Action and Permission values to the respective task in SAP GRC Access Control.
E.g., PO creation or PO approval
What is Action?
Action is the technical attribute represents the security framework such are Tcode, webdynpro, Fiori, Groups & UME Unique IDs.
What is Permission?
Permission represents authorization object and values, adds additional layer of security for the data in security concept. Whereas in risk, addresses false positive and negative.
What is False positive and negative, and how to tackle in Ruleset?
False Positive: Reporting a risk which isn’t potential enough to happen the actual risk.
There could be multiple scenarios fall for this and I am writing one among.
E.g., Risk analysis result shows a user has access to create and approve po. Although, user does not have enough access (Auth object & values) to approve the po in ERP.
Cause: lack of permission & value selection in Function permission.
Solution: Function permission file needs to be corrected with sufficient Permission values to report actual risk.
False Negative: Not reporting a risk which is potential enough to happen the actual risk.
E.g., Risk analysis result doesn’t show a user has access to create and approve po. Although, user has access to both the tasks in ERP.
Cause: Excessive permission & value selection in Function permission.
Solution: Function permission file needs to be corrected with sufficient Permission values to report actual risk.
Additional info: We usually say prevention is better than cure. Similarly, having false positive is better than false negative, since it gives an opportunity to correct.
Why does Ruleset customization need for some customers?
SAP designs the SoD ruleset for Global practice across industries, but the line of business always varies industry by industry, locations, regulations etc.
However, Global SoD ruleset stays foundation for all the roots of customization till today and future.
Why some customers implement more than 2-sided risk?
Aforesaid, line of business always varies industry by industry, locations, regulations etc. In addition, the execution of the LOB by number of users or departments also matters the source to configure the risk.
E.g.,
Risk in Industry A: PO creation vs PO approval, PO creation/approval vs Invoice posting, PO creation/approval vs Payment etc. (Very high process oriented and targets minor and major area of financial reporting disruption).
Risk in Industry B: PO creation vs PO approval vs Invoice Posting vs Payment (Process oriented and targets major area of financial reporting disruption).
Note: SAP doesn’t recommend more than 2-sided risk, since it increases the count of Rule combinations which then impacts the performance of Risk reporting.
SoD Ruleset tables in GRC:
GRACSODRISK*, GRACSODRISKRS – Risk to Ruleset, GRACSODRISK – Risk details, GRACFUNC – Function details, GRACSODRISKFUNC -Risk to Function, GRACFUNCACT – Function action, GRACFUNCPRM – Function Permission.
Probability of one of crazy mistakes in SoD ruleset process:
An eye for an eye makes the world blind. Similarly, uploading the ruleset without 0 prefix number in function permission values pretends the organization risk free.
E.g., 01 to 09 or 0001 to 0009 or 0100 so on...
By now you would have understood the functional and considerations to build a ruleset. let's look at the
“The technical setup isn’t facilitated in sequence”.
Sensitive risk analysis result for SAP PO in SAP GRC Access Control. We can configure SoD risk too. 
Insertion of UME unique ID in Function Action below. 
Navigate to SAP PO Identity management, select ‘Role’ from search criteria drop down, I have chosen ‘NWA_SUPERADMIN’ role for facilitation. 
Navigate to ‘Assigned Actions’ tab. Below are the actions of Role mentioned above. Retrieve entry from ‘Service/Application’ or ‘Name’ column. I have chosen 3rd row Name ‘NWA_SUPERADMIN_SOA_CFGMNT’
Navigate back to search criteria dropdown, select ‘Action’. Insert the retrieved name or service/Application to retrieve Unique ID, is the action attribute to add in SoD Function Action in Fig 2.
Is there a readymade security framework of SAP PO?
Fortunately, SAP GRC Authorization sync is designed to fetch the security framework of SAP PO.
GRACACTION table is the source for all possible actions which can fit in Functions. 
Conclusion:
SAP PO Java application can also take part of Organization’s compliance KPI for Access risk reporting.
Please do provide feedback and inputs in “comments” section below. I, Indhumathi Murugesan and Abhishek Verma so on... are passionate to bring more content across SAP GRC Portfolio and Cyber Risk/Data protection.
My previous blog: How to perform Cross SOD Risk Analysis for different user naming conventions in multiple SAP Applica...
Thanks,
Srikanth Thavidaboina
Thanks to the people of SAP who contribute their effort towards compliance to deliver readymade Global SoD Ruleset for SAP and Non-SAP products in the form of BC-set.
Storyline:
Building SoD Rules for SAP ABAP stack applications are known framework including SAP PI/PO ABAP stack. What about SAP PO Java stack?
Saying:
To develop SoD rules for any application, one should understand the security framework of the application - Ajit Nadkarni
Sincerely, I would like to dedicate this blog to the people who helped me in my professional journey.
Start:
SAP delivers the standard SoD ruleset for SOX listed SAP products. There are some products may or may not be SOX listed, depends on customer’s practice such are “SAP PO, Solution Manager, GRC so on...” aren’t covered in standard SoD ruleset.
The purpose of this blog is to address the fundamentals and considerations while working on SoD Ruleset setup and possibility of SAP GRC AC ARA for SAP PO Java.
Note: ARM and BRM are already proved services for SAP PO Java.
High level possible SoD Rules for non-covered SAP products:
- PO functional vs Basis and vice versa.
- PO functional vs Security and vice versa.
- Solman functional vs Basis and vice versa.
- GRC functional vs Basis and vice versa
- so on…
Let us understand the functional behind the technical followed by PO ARA
Why risk should be defined?
You have the freedom to design the definition from pictorial presentation below.
Pictorial Presentation
What is SoD and Sensitive risk in SAP ERP?
Combination of duties or functions form SoD risk, whereas Sensitive risk represents the individual duty or function.
Universal example of SoD: Creation vs Approval/Release.
Example of Sensitive: Period open and close or Client open and close.
What is function?
Function represents the task in LOB, technically it is the placeholder or container to load the Action and Permission values to the respective task in SAP GRC Access Control.
E.g., PO creation or PO approval
What is Action?
Action is the technical attribute represents the security framework such are Tcode, webdynpro, Fiori, Groups & UME Unique IDs.
What is Permission?
Permission represents authorization object and values, adds additional layer of security for the data in security concept. Whereas in risk, addresses false positive and negative.
What is False positive and negative, and how to tackle in Ruleset?
False Positive: Reporting a risk which isn’t potential enough to happen the actual risk.
There could be multiple scenarios fall for this and I am writing one among.
E.g., Risk analysis result shows a user has access to create and approve po. Although, user does not have enough access (Auth object & values) to approve the po in ERP.
Cause: lack of permission & value selection in Function permission.
Solution: Function permission file needs to be corrected with sufficient Permission values to report actual risk.
False Negative: Not reporting a risk which is potential enough to happen the actual risk.
E.g., Risk analysis result doesn’t show a user has access to create and approve po. Although, user has access to both the tasks in ERP.
Cause: Excessive permission & value selection in Function permission.
Solution: Function permission file needs to be corrected with sufficient Permission values to report actual risk.
Additional info: We usually say prevention is better than cure. Similarly, having false positive is better than false negative, since it gives an opportunity to correct.
Why does Ruleset customization need for some customers?
SAP designs the SoD ruleset for Global practice across industries, but the line of business always varies industry by industry, locations, regulations etc.
However, Global SoD ruleset stays foundation for all the roots of customization till today and future.
Why some customers implement more than 2-sided risk?
Aforesaid, line of business always varies industry by industry, locations, regulations etc. In addition, the execution of the LOB by number of users or departments also matters the source to configure the risk.
E.g.,
Risk in Industry A: PO creation vs PO approval, PO creation/approval vs Invoice posting, PO creation/approval vs Payment etc. (Very high process oriented and targets minor and major area of financial reporting disruption).
Risk in Industry B: PO creation vs PO approval vs Invoice Posting vs Payment (Process oriented and targets major area of financial reporting disruption).
Note: SAP doesn’t recommend more than 2-sided risk, since it increases the count of Rule combinations which then impacts the performance of Risk reporting.
SoD Ruleset tables in GRC:
GRACSODRISK*, GRACSODRISKRS – Risk to Ruleset, GRACSODRISK – Risk details, GRACFUNC – Function details, GRACSODRISKFUNC -Risk to Function, GRACFUNCACT – Function action, GRACFUNCPRM – Function Permission.
Probability of one of crazy mistakes in SoD ruleset process:
An eye for an eye makes the world blind. Similarly, uploading the ruleset without 0 prefix number in function permission values pretends the organization risk free.
E.g., 01 to 09 or 0001 to 0009 or 0100 so on...
By now you would have understood the functional and considerations to build a ruleset. let's look at the
Possibility of Access Risk analysis for SAP PO java
“The technical setup isn’t facilitated in sequence”.
Sensitive risk analysis result for SAP PO in SAP GRC Access Control. We can configure SoD risk too. 
Fig 1
Insertion of UME unique ID in Function Action below. 
Fig 2
Breakdown of SAP PO UME Security framework relation to Function Action
Navigate to SAP PO Identity management, select ‘Role’ from search criteria drop down, I have chosen ‘NWA_SUPERADMIN’ role for facilitation. 
Fig 3
Navigate to ‘Assigned Actions’ tab. Below are the actions of Role mentioned above. Retrieve entry from ‘Service/Application’ or ‘Name’ column. I have chosen 3rd row Name ‘NWA_SUPERADMIN_SOA_CFGMNT’
Fig 4
Navigate back to search criteria dropdown, select ‘Action’. Insert the retrieved name or service/Application to retrieve Unique ID, is the action attribute to add in SoD Function Action in Fig 2.
Fig 5
Is there a readymade security framework of SAP PO?
Fortunately, SAP GRC Authorization sync is designed to fetch the security framework of SAP PO.
GRACACTION table is the source for all possible actions which can fit in Functions. 
Fig 6
Conclusion:
SAP PO Java application can also take part of Organization’s compliance KPI for Access risk reporting.
----END----
Please do provide feedback and inputs in “comments” section below. I, Indhumathi Murugesan and Abhishek Verma so on... are passionate to bring more content across SAP GRC Portfolio and Cyber Risk/Data protection.
My previous blog: How to perform Cross SOD Risk Analysis for different user naming conventions in multiple SAP Applica...
Thanks,
Srikanth Thavidaboina
- SAP Managed Tags:
2 Comments
