Produced by Wellesley Information Services, LLC, publisher of SAPinsider. © 2016 Wellesley Information Services. All rights reserved.
Tips and Tricks to Customize Your SoD Ruleset and Post-SoD Implementation Considerations
Nathan Cummins PwC
1
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
2
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
3
Protecting Your Organization – The Need for Controls
Insights from the global state of Information Security® Survey 2016.
• 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!
www.irs.gov/uac/Examples-of-Corporate-Fraud-Investigations-Fiscal-Year-
2016
5 ex-employees of Xerox sentenced for stealing
>$4MM via false vendor invoice payments
4
The SAP GRC Ruleset – The “Heart” of the Application
• The SAP GRC ruleset is the heart of the
application impacting activities across all
GRC modules
• Effective customization of the ruleset: Accurate and meaningful reports reducing costs of
compliance and appropriately managing risk
Lowering SLAs of access request via focus on right
risks
Elimination of audit surprises via proper use of
mitigating controls
Reduce administrative costs as new users and roles
are introduced in a compliant manner from the start
Ruleset
Access Request
Workflows and
Approvals
SoD and
Sensitive
Access
Reporting
Mitigating
Controls
Critical
Transactions via
Firefighter
Role Design
guidelines
Audit tests
and reliance
5
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
6
Ruleset
The Ruleset Structure
Risk
Function 2 Function 1
Tcode A Tcode B Tcode X Tcode Y Tcode Z
Object 1 Object 2
Object 3
Field A
Field B
AND
AND
AND
OR
Field Value
1
Field Value
2
OR OR
AND AND
Customizable: AND/OR/NOT
Risk
AND
• The ruleset is a container of risks Risk: Maintain fictitious vendor
and direct payment towards it
Function: Vendor Master
Maintenance
Tcode: XK01
Object: F_LFA1_BUK
• A risk is made up of one-too-
many functions containing the
action (tcode) and permission
(object/field) settings
• Evaluation logic is inherent to
GRC at all levels, but the
individual field values
7
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)
8
Risk Types Within SAP GRC
Grouping of one to many
functions that, when combined,
create a segregation of duties
conflict Segregation
of Duties
01
Single function risk containing
tcode and authorization groupings
that will report a critical action
violation when reported Critical
Action
02
Single function risk containing
authorizations that will report a
critical permission violation
when reported Critical
Permission
03
Use permission groupings in
functions for critical permission
9
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.
10
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
11
• The logic between permission objects for a specific action is always AND relationship
• The logic between fields within a specific permission object is always AND relationship
How Do Permission Settings Work?
It is not possible to change the
logic between permission
objects or permission fields
Both M_BEST_BSA and
M_BEST_EKO is required
Both ACTVT and BSART is
required for M_BEST_BSA
12
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
13
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
14
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
15
Connector Group Guidance
• 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
RFC Name only. No
active connection info.
16
Rules – Making It All Work
• GRC generates individual
rules by creating conflicting
tcode combinations from
each possible action in
opposing functions
• A unique rule ID represents
each combination with a
nomenclature built on the risk
ID and combination number
P002001 – Risk ID
P001001 – Action code #
(F.13 vs. XK01)
Risk: P002
Maintain a fictitious vendor and direct disbursements
Function: AP01
AP Payments
Function: PR01
Vendor Master Maintenance
XK01 Create vendor (centrally)
MK01 Create vendor (Purchasing)
M-07 Create one-time vendor
XK02 Change vendor (centrally)
FK06 Mark Vendor for Deletion (Acctng)
XK06 Mark vendor for deletion (centrally)
XK99 Mass maintenance, vendor master
F.13 Automatic Clearing without Currency
F-18 Payment with Printout
F110 Parameters for Automatic Payment
F-58 Payment with Printout
F-07 Post Outgoing Payments
F-31 Post Outgoing Payments
17
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
18
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
19
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
Function ID: SR07
SRM PO Approval
Function ID: MM05
Goods Receipts
BBP_POC_WF_APP Approval Transaction for the PO
BBP_POC_WF_REV Approval PO for Reviewer
BBP_SC_DARKAPP_IAC Approve Shopping Cart in Background
MB01 Post Goods Receipt for PO
MB0A Post Goods Receipt for PO
MIGO Goods Movement
SRM
Function
- VS -
ECC
Function
Risk: E019
Approve SRM PO and Receive Goods in ECC
20
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
21
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
22
Cross-System Rules – Managing Risk Across Applications (cont.)
• Create cross-system rules:
Generate rules
Run the “Rule Detail
Report” to ensure rules
generated correctly
23
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
Table must contain a user ID Ability to include or exclude
users from violation based
upon supplementary rule
Explicit values are best utilized
OSS 1685874 fixes
Configuration parameter must
be activated to evaluate
supplementary rules table
24
Organization Level Rules – Eliminating False Positives
• Allows you to eliminate specific false positives where conflicting transaction codes are
assigned, but for differing organization values
• Organizational rules require additional maintenance, potentially require a large # of
additional rules generated impacting performance, and increase risk for missing actual
violations
XK01 – Create Vendor
Company Code 1000
F-53 – Post Outgoing Payment
Company Code 9000
Organizational rules should be utilized for very specific,
limited scenarios – only where there is wide-ranging
conflicting access separated by organizational values.
25
Select org rule in risk
analysis to filter
results based upon
org values defined in
rule.
The $BUKRS in the
function will be
evaluated with the
field values defined
in the rules.
Organization Level Rules – Eliminating False Positives (cont.)
Scenario
Identification Function
Setup
Organizational
Rule Build
Org Mapping
Background Job Org Rule Risk
Analysis
Enable Org field(s)
in functions
$OrgValue settings mean
Org reporting should be
used going forward
26
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
27
Introduction to Fiori
• Fiori provides new user interface for system interaction, an alternative to
traditional SAP GUI, capable of working across multiple devices
SAP Gateway (ABAP)
Identity Store Authorization
Transactional
Apps
SAP ECC or S/4HANA ERP
(ABAP)
Identity Store Authorization
SU01: User ID
SU01: User ID
PFCG Role Fiori Launchpad
SAP_FIN_GLDOCMANAGE_APP
PFCG Role Functional F_BKPF_BUK, F_BKPF_KOA
PFCG Role
GW/Fiori Connection S_RFCACL, S_SERVICE
FIORI UI
Source: SAP
28
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]
29
Introduction to HANA Security
A user ID is required for any
individual working within HANA
(admin, modeler, etc.) or end
user reading data directly from
HANA or through the XS engine
Standard users
By default they can create
objects in their own schema
and read data in system via
PUBLIC role inherent to all
standard users
Restricted users
Initially have no privileges.
Can only connect to HANA
via HTTP (no Studio login).
HANA is a role-based system.
Roles can be containers for
HANA privileges or other HANA
roles (composite structure).
HANA privileges can be
assigned directly to user IDs,
but is not recommended.
System Privileges
Object/SQL Privileges
Package Privileges
Analytic Privileges
Application Privileges
The number of users with
direct database access will
increase significantly in HANA
and S/4HANA scenarios.
This includes both system
administrators and end users.
30
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:
• 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
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>
31
GRC Reporting Example with HANA Risks
• Example of HANA critical action risk to measure security administration access on
HANA DB
32
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.
33
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
34
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
35
Ruleset Customization Project Overview
• Although every business and system is unique, each implementation follows a similar
risk-based methodology to customizing the GRC ruleset
• What makes a ruleset successful?
• Completeness/Accuracy
• Relevant Risks Only
PHASE ONE PHASE THREE
Risk Recognition Rule Building and
Validation Analysis Remediation Mitigation
Continuous
Compliance
1 2 3 4 6
PHASE TWO
5
• Clear view of who has what access
• Business understands the risks and results – willing
to act
36
Ruleset Customization – The People Aspect
“If auditors can rely on
our reports, we can
reduce audit costs.
I want to ensure the
main risks are covered
and the ruleset is
standardized.”
“The tools need to
show us a clear view of
who poses a risk to the
financial statements.”
“What are SoDs?
They don’t help me
achieve my goals.”
“How can this tool help
us to provide only the
access that is
necessary?”
Internal/External
Audit Compliance The Business IT/Security
Obtain clear view of system access
Move Ownership of risk from IT to business
Provide access to only access needed
Understand risk and controls
Ensure risks and controls add value to business
Trust IT that access to systems is correct
Standardize rules across organization
Ensure compliance and regulatory risk is managed
Leverage tool to minimize audit costs
Complete and accurate reporting
Financial statement risk is managed
Review of rules for reliance
37
Risk Recognition
Objective:
Assess risk and controls landscape to identify risks and threats specific to your business and application
environment
Key tasks:
• Compile your sources
• Assess existing Risk and Control matrix and mitigating controls
• Assess existing audit assessments, findings, or recommendations
• Assess business process flows for SoD relevance
• Involve the right people – IT, business, compliance, and internal/external audit
• Define risk classification criteria. Assess and rank each (critical, high, medium, low, no risk).
• For those that present little or no risk, drop at this stage to avoid over-reporting
• 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
Key deliverables
• Documented business risks and
supporting descriptions
• Risk classification of business
risks and supporting rationale
for classification
Focus on the inherent
business risk and potential
impact – not who has
access to what
38
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
• Common functions transaction codes permission settings
• Evaluate your custom transaction codes
• Utilize documentation, parameter, and change documents
• Define permission settings to minimum standard to eliminate false positives
• Load rules, perform risk analysis, tune settings
Outcomes:
• Technical ruleset build aligning to business risk requirements
• Complete and accurate risk reporting
Key deliverables
• SoD ruleset defined at transaction
code and permission level
• Generated rules in GRC
39
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
• Remediation roadmap: Single roles Business Roles Users
• Leverage SAP usage information
• The right role design helps!
• Mitigation – design to cover residual risk that can not be remediated
• Generally detective in nature when automated controls do not eliminate or minimize risk
• Align controls to enterprise controls framework
• 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
Key deliverables
• Documented SoD results and
baseline
• Mitigating controls and mitigating
control assignments
• Remediation actions and results
40
Getting Clean – Monitor Your Progress and Plan
Mitigations
deployed
41
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
• Establish control points within IT processes to assess security and developmental changes
• Could include: Role changes, new functionality/projects, SAP standard rules release, etc.
• Determine if they constitute a risk to the environment
• If so, then a change to the ruleset is initiated to capture the risk
Outcomes:
• Automated processes to enforce risk evaluation
• Ruleset change management processes and procedures
Key deliverables
• Documented business risks and
supporting descriptions
• Risk classification of business
risks and supporting rationale
for classification
42
• 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
Reports to Help – Actions in Roles, but Not Rules
Utilize role owners to
decentralize the review of
tcodes not in rules
43
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
44
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
45
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.
46
Your Turn!
Please remember to complete your session evaluation
How to contact me:
Nathan Cummins
47
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.
Disclaimer
©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.
Wellesley Information Services, 20 Carematrix Drive, Dedham, MA 02026 Copyright © 2016 Wellesley Information Services. All rights reserved.
Top Related