Tips and Tricks to Customize Your SoD Ruleset

and Post-SoD Implementation Considerations

Nathan Cummins
PwC
Produced by Wellesley Information Services, LLC, publisher of SAPinsider. © 2016 Wellesley Information Services. All rights reserved.
In This Session

The ruleset is the heart of the GRC Access Control application. In this session, we will
explore basic to emerging ruleset functionality and the options available to you to enhance
your risk reporting.

Designed for both functional and technical stakeholders, this session guides you through
the ruleset design process and shows you what you need to consider – and what you
should expect – during each stage of your SoD ruleset design project

We will take a simple and practical approach to examining ruleset customization, leaving
you with actionable techniques to improve risk management activities via the GRC tool

1
What We’ll Cover

• SAP GRC Ruleset – the basics

• Advanced GRC ruleset topics – improving specificity
• Emerging GRC ruleset topics – preparing for S/4HANA
• Ruleset design methodology – your path to customization
• Wrap-up

2
Protecting Your Organization – The Need for Controls

• Estimated $3.7 trillion lost to fraud annually

(2014 Global Fraud Survey)

• 22% of fraud cases exceed $1MM in loss

• Fraud is the most common source of

security incident loss – it happens
everyday!

5 ex-employees of Xerox sentenced for stealing

>$4MM via false vendor invoice payments

www.irs.gov/uac/Examples-of-Corporate-Fraud-Investigations-Fiscal-Year-
2016 Insights from the global state of Information Security® Survey 2016.

3
The SAP GRC Ruleset – The “Heart” of the Application

• The SAP GRC ruleset is the heart of the

application impacting activities across all Mitigating
SoD and
GRC modules Sensitive Controls
Access
Reporting

• Effective customization of the ruleset:

 Accurate and meaningful reports reducing costs of Access Request Audit tests
Workflows and and reliance
compliance and appropriately managing risk Approvals Ruleset
 Lowering SLAs of access request via focus on right
risks
 Elimination of audit surprises via proper use of Critical
Transactions via
Role Design
guidelines
mitigating controls Firefighter

 Reduce administrative costs as new users and roles

are introduced in a compliant manner from the start

4
Ruleset Definitions – Let’s Level Set
Term Definition
Ruleset A collection of risks used for SoD or sensitive access reporting
Function A grouping of one or more related actions and/or permissions for a specific business area
Risk A grouping of one or more conflicting functions that presents an opportunity for physical loss, fraud, process disruption, or
productivity loss
Rule Two or more conflicting actions and/or permissions that create a risk
Action An activity that is performed in the system in order to fulfill a specific function, for example, Create Purchase Order. This is
equivalent to a transaction code in SAP.
Permission Authorizations that allow a user to perform a particular activity in a system. This is equivalent to an authorization object
in SAP.
Role Roles are not equitable to the ruleset! A role exists on an application as a container of capabilities and user membership
according to the system’s security concept.
System/Connector An application connected to GRC for purposes of risk analysis, user provisioning, or firefighter

5
The Ruleset Structure
Ruleset

The ruleset is a container of risks Risk Risk: Maintain fictitious vendor

• Risk and direct payment towards it

• A risk is made up of one-too- Function: Vendor Master

Function1 AND Function2
many functions containing the Maintenance

action (tcode) and permission

(object/field) settings Tcode A
OR Tcode B Tcode X ORTcode YORTcode Z Tcode: XK01

AND
AND Object: F_LFA1_BUK
• Evaluation logic is inherent to Object 3
Object 1 AND Object 2
GRC at all levels, but the
individual field values AND
Field A

AND
Field B

Field Value
1
Field Value
2 Customizable: AND/OR/NOT

6
Risks

• A grouping of one or more conflicting functions that presents an opportunity for

physical loss, fraud, process disruption, or productivity loss

 Risk ID – Description(s);
 Risk Level;
 Business Process;
 Risk Owner(s);
 Control Objective;
 Ruleset(s)

7
Risk Types Within SAP GRC

01 Grouping of one to many

functions that, when combined,
Segregation create a segregation of duties
conflict
of Duties

02 Single function risk containing

tcode and authorization groupings
Use permission groupings in
Critical that will report a critical action
violation when reported functions for critical permission
Action

03 Single function risk containing

authorizations that will report a
critical permission violation
Critical when reported
Permission

8
Functions – The Foundation of Your Ruleset

• Functions are a grouping of one or more related actions and permissions for a specific
business activity
• Functions are made up of:
 Actions (Tcodes)
 Permissions (Authorization Object/Field/Values)
 Business Process
 Can be – single or cross-system

Cross-System setting must be used

in at least 1 of the functions when an
SoD risk is evaluated across
different systems.

9
Functions – Permission Settings

• The permissions for newly added actions default from SU24 values pulled in from GRC’s
authorization synchronization job
• Permission settings should focus on defining the minimum level of authorizations
required to execute a transaction code in context of the ruleset function

Not enough permission

settings – false positives

Too many permissions

settings – under-reporting

10
How Do Permission Settings Work?

• The logic between permission objects for a specific action is always AND relationship
Both M_BEST_BSA and
M_BEST_EKO is required

• The logic between fields within a specific permission object is always AND relationship
Both ACTVT and BSART is
required for M_BEST_BSA

It is not possible to change the

logic between permission
objects or permission fields

11
How Do Permission Settings Work? And, Or, Not

• An AND/OR/NOT condition setting is available for values within a single Object-Field

 AND = Each field value is required (Activity 01 and Activity 02)

 OR = Any one of the field values is required (Document type FO or NB)

 NOT = Any field value, but the setting (confusing with multiple NOTs)

Use OR ranges
excluding value(s)
rather than NOT

12
Connectors – Associating the Functions with System(s)

• Connector – A system connected to GRC

(e.g., SM59 RFC)

• Connector Groups – Used to simplify maintenance of data linked to connectors in GRC

 “Landscapes” in the BRM and ARM modules to load roles against
 Can be mapped as system values in ARA functions to ease ruleset maintenance

It is almost always preferred to load your

ruleset functions against connector
groups vs. the actual physical connector

13
Connector Groups

• Logical system – two or more physical systems grouped together to allow you to
maintain rules against one system grouping instead of each physical system
• Cross system – two or more physical systems grouped together so you can perform user
analysis operations across multiple systems

14
Connector Group Guidance
RFC Name only. No
active connection info.
• System-specific (LG_ECC; LG_SRM; LG_CRM)
• Ensure the groups are transportable (not ECC_DEV;
ECC_QA; ECC_PRD)
• Use “dummy” RFCs in development to transport
connector-specific configuration for production
systems
• Use a Logical System Basis Connector Group to
evaluate IT risks across all systems

15
Rules – Making It All Work
Risk: P002
• GRC generates individual Maintain a fictitious vendor and direct disbursements

rules by creating conflicting

tcode combinations from
each possible action in
opposing functions Function: AP01 Function: PR01
Vendor Master
AP Payments Maintenance

• A unique rule ID represents F.13 Automatic Clearing without Currency XK01 Create vendor (centrally)

each combination with a F-18 Payment with Printout MK01 Create vendor (Purchasing)

nomenclature built on the risk F110 Parameters for Automatic Payment M-07 Create one-time vendor

ID and combination number F-58 Payment with Printout XK02 Change vendor (centrally)

F-07 Post Outgoing Payments FK06 Mark Vendor for Deletion (Acctng)

 P002001 – Risk ID F-31 Post Outgoing Payments XK06 Mark vendor for deletion (centrally)

 P001001 – Action code # XK99 Mass maintenance, vendor master

(F.13 vs. XK01)

16
Transports and Workflow Considerations

• Transport Ruleset = viewpoint of configuration

 Remember to generate after transport

 Eliminates need to copy back production ruleset to dev and QA

 Likely testing ruleset changes in development system anyway

 Logical systems are a must with transport

• Workflow Approvals with production maintenance = viewpoint of master data

 Risk/Function change triggers workflow request before it takes effect

 Auto ruleset generation when approved

 Risk Owners/Single Function Owner

 Relies on comments; not detailed view of actual changes

17
What We’ll Cover

• SAP GRC Ruleset – the basics

• Advanced GRC ruleset topics – improving specificity
• Emerging GRC ruleset topics – preparing for S/4HANA
• Ruleset design methodology – your path to customization
• Wrap-up

18
Cross-System Rules – Managing Risk Across Applications

• In today’s increasingly complex SAP landscapes business processes are often carried
out across multiple systems creating the need to separate functions across systems

• Cross-system rules are created from risk(s) that contain functions with actions mapped
to multiple systems
Risk: E019
Approve SRM PO and Receive Goods in ECC
SRM ECC
Function Function
Function ID: SR07 Function ID: MM05
SRM PO Approval - VS - Goods Receipts

BBP_POC_WF_APP Approval Transaction for the PO MB01 Post Goods Receipt for PO

BBP_POC_WF_REV Approval PO for Reviewer MB0A Post Goods Receipt for PO

BBP_SC_DARKAPP_IAC Approve Shopping Cart in Background MIGO Goods Movement

19
Cross-System Rules – Managing Risk Across Applications (cont.)

• Create cross-system rules:

 Assign tcodes and authorizations to
appropriate SAP logical system
 Define the cross-system functions
“Analysis Scope” as Cross System
 A function specified as “Cross System”
can also be used as a single system
function

20
Cross-System Rules – Managing Risk Across Applications (cont.)

• Create cross-system
connector groups:
 Set up a cross-system
connector group that
contains each of the SAP
systems, which will be used
to run the cross-system risk
analysis

21
Cross-System Rules – Managing Risk Across Applications (cont.)

• Create cross-system rules:

 Generate rules

 Run the “Rule Detail

Report” to ensure rules
generated correctly

22
Supplementary Rules – Enhancing Specificity

• Allows for additional criteria, beyond authorizations, to be evaluated which must be met
before an apparent conflict is reported as a violation
 Extends specificity of an existing function and its associated risks
 Valuable for workflow or approval limits controlled outside of authorizations

Configuration parameter must

be activated to evaluate
supplementary rules table

Ability to include or exclude Table must contain a user ID

users from violation based
upon supplementary rule

Explicit values are best utilized

OSS 1685874 fixes

23
Organization Level Rules – Eliminating False Positives

• Allows you to eliminate specific false positives where conflicting transaction codes are
assigned, but for differing organization values

XK01 – Create Vendor F-53 – Post Outgoing Payment

Company Code 1000 Company Code 9000

• Organizational rules require additional maintenance, potentially require a large # of

additional rules generated impacting performance, and increase risk for missing actual
violations
Organizational rules should be utilized for very specific,
limited scenarios – only where there is wide-ranging
conflicting access separated by organizational values.

24
Organization Level Rules – Eliminating False Positives (cont.)
$OrgValue settings mean
Org reporting should be
used going forward

Enable Org field(s)

in functions

Select org rule in risk

Scenario Org Mapping Function Organizational analysis to filter
Org Rule Risk
Identification Background Job Rule Build results based upon
Setup Analysis
org values defined in
rule.

The $BUKRS in the

function will be
evaluated with the
field values defined
in the rules.

25
What We’ll Cover

• SAP GRC Ruleset – the basics

• Advanced GRC ruleset topics – improving specificity
• Emerging GRC ruleset topics – preparing for S/4HANA
• Ruleset design methodology – your path to customization
• Wrap-up

26
Introduction to Fiori

• Fiori provides new user interface for system interaction, an alternative to

traditional SAP GUI, capable of working across multiple devices

Transactional FIORI UI
Apps

PFCG Role SAP Gateway (ABAP)

Fiori Launchpad SU01: User ID
SAP_FIN_GLDOCMANAGE_APP Authorization Identity Store

SAP ECC or S/4HANA ERP Source: SAP

PFCG Role Functional (ABAP) SU01: User ID
F_BKPF_BUK, F_BKPF_KOA
Authorization Identity Store
PFCG Role
GW/Fiori Connection
S_RFCACL, S_SERVICE

27
Fiori Integration with GRC Ruleset

• Access Risk Monitoring – The Challenge

 Fiori app provides front end to SoD-relevant or sensitive function. User no longer
needs access to transaction codes in all cases which today’s rulesets are based upon.
• Access Risk Monitoring – Solutions when Fiori doesn’t use S_TCODE
 Leverage Permission Groupings in GRC hinged upon the ECC or S/4HANA S_SERVICE
value generated for the Fiori App(s) [USOBHASH table]

28
Introduction to HANA Security

A user ID is required for any Standard users Restricted users

individual working within HANA
(admin, modeler, etc.) or end
user reading data directly from By default they can create Initially have no privileges.
HANA or through the XS engine objects in their own schema Can only connect to HANA
and read data in system via via HTTP (no Studio login).
PUBLIC role inherent to all
standard users The number of users with
direct database access will
HANA is a role-based system. System Privileges increase significantly in HANA
Roles can be containers for Object/SQL Privileges
and S/4HANA scenarios.
HANA privileges or other HANA This includes both system
roles (composite structure). Package Privileges
administrators and end users.
HANA privileges can be Analytic Privileges
assigned directly to user IDs,
but is not recommended. Application Privileges

29
HANA Integration with GRC Ruleset

• SAP HANA can be integrated with GRC 10.1 for SoD Reporting and Mitigation and User
Provisioning activities
• HANA rules can be defined for System, Object, Package, and Analytic privileges. See
format:
Privilege Permission Field Value
Object/SQL <Schema:SQL Object.Value> SQLPRIVILEGE SELECT, INSERT, UPDATE, etc.

System <System Privilege> GRANTABLE YES/NO

Package <Package Name. Package Privilege> PackagePrivilege <PackagePrivilege>

Analytic [AP]<Structured Privilege> ActivityRestriction, DimenstionRestriction, etc. <Operand>

• The GRC ruleset should be used to monitor:

 Administrators – Critical access measuring high-risk sensitive functionality (similar to basis rules in ERP)

 End Users – Sensitive data in HANA can be monitored with rules focusing on Analytic Privileges

30
GRC Reporting Example with HANA Risks

• Example of HANA critical action risk to measure security administration access on

HANA DB

31
Web Dynpros and the GRC Ruleset

• Complementing the push to Fiori interface, SAP continues to release new UI using Web
Dynpro applications
• SAP has extended scope of running risk analysis to analyze Web Dynpro Applications
with SP06 of GRC 10.1. Refer to SAP Note 2048207 and 2171822 for more details.
 Authorization Synchronization Job – Extended to synchronize Web Dynpro master data and SU24 material. Prefixed
with [WDY] in the repository to differentiate from tcodes.
 Risk Analysis – In the Analysis Results screen, the Resource column reflects S_START for the Web Dynpro material
 Action Usage is not possible for Web Dynpro applications

Adding a Web Dynpro

application to a ruleset
function.

32
Web Dynpros Rules for SRM 7.x

• The SAP standard ruleset released the first Web Dynpros content for SRM7.x
 BC Set GRAC_RA_RULESET_SAP_SRM is updated in SP11 of GRC 10.1. This BC Set will have SRM 4.0
ABAP-based rules plus new action/permission data of SRM Web Dynpro application.
 All the Web Dynpro application actions start from [WDY] to differentiate it from the transaction codes

33
What We’ll Cover

• SAP GRC Ruleset – the basics

• Advanced GRC ruleset topics – improving specificity
• Emerging GRC ruleset topics – preparing for S/4HANA
• Ruleset design methodology – your path to customization
• Wrap-up

34
Ruleset Customization Project Overview

• Although every business and system is unique, each implementation follows a similar
risk-based methodology to customizing the GRC ruleset

1 2 3 4 5 6
Rule Building and Continuous
Risk Recognition Analysis Remediation Mitigation
Validation Compliance

PHASE ONE PHASE TWO PHASE THREE

• What makes a ruleset successful?

• Completeness/Accuracy • Clear view of who has what access
• Relevant Risks Only • Business understands the risks and results – willing
to act
35
Ruleset Customization – The People Aspect

IT/Security The Business Compliance Internal/External

Audit

“How can this tool help “What are SoDs? “If auditors can rely on “The tools need to
us to provide only the They don’t help me our reports, we can show us a clear view of
access that is achieve my goals.” reduce audit costs. who poses a risk to the
necessary?” I want to ensure the financial statements.”
main risks are covered
and the ruleset is
standardized.”

Obtain clear view of system accessUnderstand risk and controls Standardize rules across organization
Complete and accurate reporting
Move Ownership of risk from Ensure
IT to business
risks and controls add value
Ensure
to business
compliance and regulatory risk is Financial
managed statement risk is managed
Provide access to only accessTrust
needed
IT that access to systems is correct
Leverage tool to minimize audit costs Review of rules for reliance

36
Risk Recognition

Objective: Focus on the inherent

Assess risk and controls landscape to identify risks and threats specific to your business and application business risk and potential
environment impact – not who has
access to what

Key tasks:
• Compile your sources
Key deliverables
• Assess existing Risk and Control matrix and mitigating controls
• Assess existing audit assessments, findings, or recommendations • Documented business risks and
• Assess business process flows for SoD relevance supporting descriptions
• Involve the right people – IT, business, compliance, and internal/external audit • Risk classification of business
• Define risk classification criteria. Assess and rank each (critical, high, medium, low, no risk). risks and supporting rationale
• For those that present little or no risk, drop at this stage to avoid over-reporting for classification
• Identify, engage, and conduct workshops with key business stakeholders
Outcomes:
• Set of risks in line with your customized processes to efficiently decrease audit exposure
• Agreed upon risk rating approach that identifies risks as unacceptable to the business vs. requiring
mitigation/remediation vs. operational/reporting risks

37
Rule Building and Validation

Objective:
For the risks that have been identified, a common language is defined to specify the functions within the system.
Business requirements around risk are translated into transactions and authorizations. Validation confirms
completeness and accuracy.
Key tasks:
• Start with your sources
• The standard GRC ruleset is a starting point, but will need to be supplemented Key deliverables
• Common functions  transaction codes  permission settings • SoD ruleset defined at transaction
• Evaluate your custom transaction codes code and permission level
• Utilize documentation, parameter, and change documents
• Define permission settings to minimum standard to eliminate false positives
• Generated rules in GRC
• Load rules, perform risk analysis, tune settings

Outcomes:
• Technical ruleset build aligning to business risk requirements
• Complete and accurate risk reporting

38
Analyze, Remediate, and Mitigate

Objective:
Get Clean! Production SoD reports are actively monitoring environment. Remediation and mitigating control activity
eliminates and/or minimizes risk in the environment.

Key tasks:
• Baseline risk report and results Key deliverables
• Remediation roadmap: Single roles  Business Roles  Users • Documented SoD results and
• Leverage SAP usage information baseline
• The right role design helps!
• Mitigating controls and mitigating
• Mitigation – design to cover residual risk that can not be remediated
• Generally detective in nature when automated controls do not eliminate or minimize risk control assignments
• Align controls to enterprise controls framework • Remediation actions and results
• Ensure they pass controls testing and meet evidence retention policy
Outcomes:
• SoD and SA violation analysis and recommendations
• Dynamic violation dashboards to support future analysis
• Incorporation of usage data to assess appropriateness of access
• Remediation and mitigation activity

39
Getting Clean – Monitor Your Progress and Plan

Mitigations
deployed

40
Continuous Compliance

Objective:
Stay Clean! Production SoD ruleset is proactively enforced during user provisioning and role change processes. Ruleset
change management processes continually update rules as environment evolves.

Key tasks:
• Automating risk analysis in provisioning and role maintenance process
Key deliverables
• Establish control points within IT processes to assess security and developmental changes
• Could include: Role changes, new functionality/projects, SAP standard rules release, etc. • Documented business risks and
• Determine if they constitute a risk to the environment supporting descriptions
• If so, then a change to the ruleset is initiated to capture the risk • Risk classification of business
risks and supporting rationale
for classification

Outcomes:
• Automated processes to enforce risk evaluation
• Ruleset change management processes and procedures

41
Reports to Help – Actions in Roles, but Not Rules

• Evaluates transaction codes in roles, not active in ruleset for selected criteria
• Mark an action as “analyzed” to denote it has been reviewed and is not relevant for
ruleset – allows comments for detail
• Keep in an in-system list of analyzed transaction codes – table GRACANALYZEDOBJ

Utilize role owners to

decentralize the review of
tcodes not in rules

42
What We’ll Cover

• SAP GRC Ruleset – the basics

• Advanced GRC ruleset topics – improving specificity
• Emerging GRC ruleset topics – preparing for S/4HANA
• Ruleset design methodology – your path to customization
• Wrap-up

43
Where to Find More Information

• Scott Osterman, Jamie Draper, and Jonathan Levitt, “Closing the Access Loop: Effective
techniques to manage your segregation of duties and sensitive access” (PwC, 2014).
 www.youtube.com/watch?v=2Qar7FyMOHo

• SAP GRC-AC10.1 Configuration Guide:

 http://help.sap.com/grc-ac

 Follow Configuration and Deployment Information  Customizing (English)

• Luis Bustamante, “AC 10.0 Enhanced Access Risk Analysis” (SAP, June 2011).
 http://bit.ly/1QxuGm1

44
7 Key Points to Take Home

• The ruleset is the heart of the tool – it will drive risk management across modules
• The ruleset must be customized to create real value from the application
• Cross-system, organization-level rules, and supplementary rules can all be utilized to
improve specificity of reporting
• SAP GRC can be utilized to manage risk of emerging technologies such as Fiori and
HANA, which traditional transaction code level reporting cannot
• The ruleset design process is a top-down approach identifying and classifying risks
before building out the technical rules
• Ruleset management is an ongoing activity – integrate this activity within your security
and upgrade processes
• Customizing your ruleset is not the last step! Expect to use this information to remediate
risks, develop and use mitigating controls, and/or redesign your security roles.
45
Your Turn!

How to contact me:

Nathan Cummins
[email protected]

Please remember to complete your session evaluation

46
 Disclaimer
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP SE.

©2016 PwC. All rights reserved. PwC refers to the US member firm or one of its subsidiaries or affiliates, and may sometimes refer to the PwC network.
Each member firm is a separate legal entity. Please see www.pwc.com/structure for further details. This content is for general information purposes only,
and should not be used as a substitute for consultation with professional advisors.

47
Wellesley Information Services, 20 Carematrix Drive, Dedham, MA 02026
Copyright © 2016 Wellesley Information Services. All rights reserved.