Day14-Day15

Shared Mitigation Controls

Create Mitigation Controls





PFCG ROLES

Rule Set & Hierarchy

Risk Terminology

Configuration Settings





Remediating Risks



Organization Rules • Organization rules are used to eliminate false positive SOD reporting based on organization level restriction for users. • Role A contains transaction FB60 (posting of vendor invoices) for company code 1000 • Role B contains transaction FK02 (changing vendor master data) for company code 2000 • The combination of FK02 and FB60 is a SOD risk, as posting of vendor invoices and changing of vendor master data shouldn’t be performed by the same person • If user assigned with these two roles, then it is a false positive risk as combination of transactions are risk, but they are for different org values.

False Positive • False positives (conflicts that show up in risk analysis reports but are not risks) - These can be resolved by implementing Organizational rules • False negatives: Users are not showing in the report in which you think they should show. In this case you need to check your ruleset rules to find out the issue.

Supplementary Rules • SAP Invoice management ( VIM) has functionality in which user can release the order if he/ she is maintained in COA tables. Therefore, if user have authorization access to release, then also, he / she cannot release the same. • IF user have access to release & change then it is a SOD but if he/she is not maintained in the COA table then he/she can release the same. Therefore, system show the SOD ( false positive) as it can only check the authorization but to check his/her id maintained in COA table we need to use supplementary rule. Reference link: shett-ppso:s/i/tbivloesg-sw.siathp-.csaopm-g/2rc0-1su6/p0p5le/1m8e/nintaclruyd-reu-laepsp/ roval-levels-and-prevent-fal

Scope Analysis for Function ID SAP NOTE : 1178372

Offline Risk Analysis Parameter : 1027  Yes • Offline analysis is not real-time data but is dependent on the date of the last Batch Risk Analysis.  • The benefits using offline analysis is mostly in response time. By using offline analysis, Risk Analysis and Remediation does not have to make as many calls into the connected systems so the analysis will return much faster than using online analysis • Using offline analysis, you can obtain both summary and detail reports. The one exception is that if you run Report types Critical Action or Critical Permission, you will not be able to see the detail report, only the summary report. •  In Configuration under Risk Analysis,  you have the option “Exclude Locked Users”. If this is set to YES, when running the batch risk analysis, it will not evaluate locked users which means the tables holding the conflicts will not include any data for locked users.

• The Batch Risk Analysis is run as background job in GRC by using transaction GRAC_BATCH_RA (program Batch Risk GRAC_BATCH_RISK_ANALYSIS). Analysis • This is the same batch risk analysis that is run to update the management reports and companies should be running this on a frequent basis to ensure their management reports are accurate.

Mitigation Risks

Mitigation • A risk mitigation strategy is a strategy Control developed by enterprise risk managers to minimize the effects of a known risk on the organization. • They are different type of mitigation in GRC  User Based Mitigation Control  Role Based Mitigation Control  Profile Based Mitigation Control  Rule ID Based Mitigation Control  System Based Mitigation Control

1542565- Mitigations at Action versus Permission level

• Transaction Rules ( TABLE: GRACACTRULE) FI01001: Maintain fictitious GL account & hide activity via postings FI01001 – Risk ID FI01001 – Action code combination number (represents Conflicting Actions) • Permission Rules FI0100101: Maintain fictitious GL account & hide activity via postings FI0100101 – Risk ID FI0100101 – Action code combination number FI0100101 – 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, except 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.

Roles for Mitigation control / Owner Parameter for Mitigation Control Parameter Group Parameter ID Description Mitigation 1011 Default expiration time for mitigation control assignment Mitigation 1012 Consider rule id also for mitigation assignment Mitigation 1013 Consider system for mitigation assignment Risk Analysis 1021 Consider org rules for mitigation assignment Risk Analysis 1033 Include Role / Profile mitigation control in risk analysis

Mitigation Control Table SAP NOTE: 2247806- Mitigation Control tables

Mitigating Control Vs. Risk/Monitor/Approver Details • Retrieve OBJID from table HRP5354 by inputting the Mitigating Control ID in SHORT_KEY1 field • Retrieve KEY 1 and KEY 2 from HRT5320 by passing OBJID retrieved above into T_OBJID field which will give Risk/MC Monitor/MC Owner Details dhtintpgs-t:/a/bblelosg/s.sap.com/2015/11/17/grc-access-requests-and-correspon

Mass Mitigation

SOD ( Segregation Of Duties) Below are the transactions for SOD’s & Batch Risk Analysis • GRAC_UPLOAD_RULES • GRAC_GENERATE_RULES • GRAC_RULE_DELETE • GRAC_RULE_TRANSPORT

Batch Risk • It is required for Offline Risk Analysis and Management Analysis reports • By default, the application perform batch risk analysis on all objects in the specified system and we can choose to exclude specific objects Path  SPRO-> Governance Risk & Compliance -> Access Control -> Access Risk Analysis -> Batch Risk Analysis Transactions: GRAC_BATCH_RA ( Batch Risk Analysis) GRACRABATCH_MONITOR ( Monitor Batch Risk Analysis)





1602186- GRC Access Risk Analysis tables











Day15

Connector Setting for BRM





Role Provisioning Status Role Exist  YES ( if it is ‘NO’ then we need to run the ROLE SYNC JOB ( SAP NOTE: 2451599, Attribute AC_REF_ROLE_ID is not in sync with GRACROLE & GRACRLCONN) Role Status  PRD ( Then only it visible in Access Request and connector environment has no relation with it)

Business The Business Role Management component of the Role GRC solution that automates role definition and Management management of roles. ( BRM) • Ensure consistency in naming convention • Track the status of the role during maintenance • Be the central repository for role management • Identify duplicate roles • Identify roles that may no longer needed.



Role • Role Type Attributes • Role Type Labels • Role Name • Project and Product Release Name • Role Sensitivity • Role Status • Criticality Level • Companies • Functional Areas • Organizational Level Mapping • Prerequisite type and Role Prerequisites • Business Processes • Business Subprocesses • Custom fields

Business Roles • Each Business role represents a Job role or function, and is associated to one or more related Technical roles which the business can easily understand. • Business roles are system independent • An example is, when customer creates a Business role that has assigned two Technical roles, one for system A, and one for system B. When this Business role is assigned to the user (having two Technical roles from two different systems) it is not necessary to select the system for the Business role it-self. The request will automatically take both the Technical role's systems. • Parameter 4011: Delete the technical roles if it is part of the Business roles (When setting this parameter to “Yes”, shared Technical roles will get removed when a Business role is removed via Access Request.) • SAP Note 1696320: Business roles are not getting search in Role level report SAP Note 696647: Business Role not getting searched with blank system failed, SAP Note 1736960: Shared Technical Roles not retained when Business Role is removed via Access Request SAP Note 1692561: UAM: Business Role as default role is working

Searching for • Business roles search should not rely on “System” search Business Roles criteria, as Business roles usually consist of more than one Technical role, where each Technical role is possibly tied to a different System. There could be different Technical roles from different systems assigned to a Business role.  • So it is recommended to not combine System and Business roles in search criteria.  Search for Business roles only and leave the system ID field blank

Updating existing Business roles • In BRM, when opening the Business role, in step “Provisioning” of the role methodology there is a button called \"Initiate update to users\", this will do all the deletion/insertion to all the users. The change will be pushed to those users who have that Business role.  

SPRO • Under transaction SPRO>SAP Reference IMG>Governance, Risk & Parameters Compliance>Access Control>Maintain Configuration Settings, there is a group related parameter group called “Access Request Business role”, which comprises to Business the following parameter: roles • Parameter 4011: Delete the technical roles if it is part of the Business roles • When setting this parameter to “Yes”, shared Technical roles will get removed when a Business role is removed via Access Request.

Role • Role Certification is a concept similar to “User Access Review”. It allows the Certification Business role owner to review and certify the role content on a periodic basis. • Role certification attributes are defined in the role properties, and the certification period is defined in days. After the defined days have passed, an email reminder is sent to Role Owner to notify that the role needs to be certified. The next certification date is calculated based on the period and the last certification date. The reminder template can be customized in IMG.