Tips and Tricks to Customize Your SoD Ruleset and Post-SoD...

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

http://www.irs.gov/uac/Examples-of-Corporate-Fraud-Investigations-Fiscal-Year-2016















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





• 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


• 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


• 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





• 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





• 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





• 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

http://www.youtube.com/watch?v=2Qar7FyMOHo





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

[email protected]

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.

Tips and Tricks to Customize Your SoD Ruleset and Post-SoD...

Documents

Transcript of Tips and Tricks to Customize Your SoD Ruleset and Post-SoD...