How to Modernize Your SAP Access Control Ruleset...

Produced by Wellesley Information Services, LLC, publisher of SAPinsider. © 2016 Wellesley Information Services. All rights reserved.

How to Modernize Your SAP Access Control Ruleset and Mitigating Control Library

James E. Roeske Customer Advisory Group

1

In This Session

• Delve into the world of mitigating control standards, processes, and content

requirements that auditors look for

This includes best practices around mitigation documentation, ownership and

accountability, and compensating control monitoring standards that need to exist to

qualify for a “Good Mitigation Control”

• Examine the functionality in SAP GRC 10.0 and 10.1 that can be used to assist in ruleset

and mitigation change control and long-term maintenance

This includes workflow capabilities to manage change control and approvals for risks,

functions, mitigating controls, and mitigating control assignments

• Learn how to establish “proactive” processes to ensure your ruleset and mitigation

controls stay current so you never have to worry about falling behind again when it

comes to the quality of your company’s SoD monitoring standards

2

What We’ll Cover

• Evolution of a compliance program

• GRC ruleset updates from SAP

• How to conduct a ruleset review (real examples)

• Mitigating control review – what makes a good control?

• How to be proactive – keeping your ruleset and mitigations current

• Wrap-up

3

Is Your GRC Program Not Like a VW Beetle or a Porsche 911?

4

Remember When You First Built Your Ruleset?

Risk Recognition

Rule Customization

Analysis and Scoping

Remediation Mitigation Continuous Compliance

RULE CUSTOMIZATION AND VALIDATION

• Reference best practices rules for your environment

• Validate rules

• Customize rules, then test

• Verify against test user/role cases

This was the “Best Practice” that we all preached to

customers First implementing GRC SoD Analysis You Started with a

strong and Accurate

Set of Rules that

covered your most

current compliance

requirements.

5

Indicators That Your Ruleset and Mitigations May Be Out of Date

• When was the last time your conducted a full Ruleset review?

• Have you added SoD-Relevant custom T-codes to your functions since your Ruleset was

built?

• Have you added additional systems or SAP functionality since your Ruleset was built?

• Have you changed business processes or changed SAP Configuration since your Ruleset

was built?

• Have you upgraded your SAP Systems or applied Service or Function Packs since your

Ruleset was built?

• Have you acquired new businesses or split off corporate entities?

If “yes” then you are a candidate for some Ruleset Modernization!

6

What About After 5-10 Years?

If you haven’t been reviewing your

Rules and Mitigations regularly,

they can become weak, ineffective,

and obsolete very quickly. Most customers unfortunately believe

Ruleset building is a one-time thing and

rarely make proactive changes or updates

after the initial implementation project.

Mitigation Continuous Compliance

Remediation

Rather, they just focus

on Running reports and

keep the SoD numbers

low to pass audits.

7

“If you are looking for the wrong things, then you will also get the wrong results”

Completeness and accuracy is critical in the SoD analysis

process. The goal is to eliminate False Positives and False

Negatives in SoD reporting.

Key items to focus on related to accuracy of the RAR ruleset are:

• Custom Transaction Codes created by the customer

• Unique customization and configuration by the customer

• Correct use of “AND,” “OR,” and “NOT” logic in the rules

• Testing, testing, and more testing of the rules to make sure they are

working the way you intend them to operate

Words to Live By!

8

What the Process Should Look Like to Stay Current

Risk Recognition

Rule Customization

Analysis and Scoping

Remediation Mitigation Continuous Compliance

Regularly

Scheduled

Ruleset and

Mitigation

Reviews

9

What We’ll Cover






• Wrap-up

10

Where Did Your Ruleset Originate From?

Before you can put together a plan on how to keep your Ruleset

current, you need to know where the current content came from.

Depending on the original source there may be updates already

available.

• Is your current Ruleset based on the SAP Standard

Delivered Ruleset?

• Did you create your Rules from scratch?

• Was it provided by your implementation partner or

consultants?

• Did you convert an existing Ruleset from a different GRC

application?

11

Example – SAP Standard Rule Updates

The SAP standard delivered rulesets and updates are now delivered in the Support

Packs Via Business Content Sets a.k.a. “BC Sets”

BC Set BC Set Name GRAC_RA_RULESET_COMMON SoD Rules Set

GRAC_RA_RULESET_JDE JDE Rules Set

GRAC_RA_RULESET_ORACLE ORACLE Rules Set

GRAC_RA_RULESET_PSOFT PSOFT Rules Set

GRAC_RA_RULESET_SAP_APO JDE Rules Set

GRAC_RA_RULESET_SAP_BASI

S SAP BASIS Rules Set

GRAC_RA_RULESET_SAP_CRM SAP CRM Rules Set

GRAC_RA_RULESET_SAP_ECC

S SAP ECCS Rules Set

GRAC_RA_RULESET_SAP_HR SAP HR Rules Set

GRAC_RA_RULESET_SAP_NHR SAP R/3 less HR Basis Rules

Set

GRAC_RA_RULESET_SAP_R3 SAP R/3 AC Rules Set

GRAC_RA_RULESET_SAP_SRM SAP SRM Rules Set

Depending on how your GRC

system is configured,

Activating a Rule BC in an

active GRC system can

overwrite your existing rules,

resulting in data and

configuration loss!

Talk to your GRC Implementation partner who should be able to provide the updated

versions of the SAP Standard GRC Rulesets via spreadsheet format as well.

12

Ruleset – File Standardization

• Although the SAP Ruleset is now

delivered to customers via BC

Sets, AC10.x ARA still provides

Ruleset upload download

capabilities using standardized file

formats.

13

SAP Support Is Your Friend!

SAP provides Ruleset update information via SAP Notes as well.

14

Additional SAP Notes

15

Example of an SAP Ruleset Update Note

16

SAP Note Containing “New” SRM Rule Content

17

What We’ll Cover






• Wrap-up

18

Incorrect Rule Configuration Is Always the Top Priority

• The purpose of remediation is to determine alternatives for eliminating SoD violations.

These alternatives should be explored in the following order:

1. Is this SoD violation caused by an incorrect rule? If yes, then modification to the rule is

required to resolve the false positive.

2. Can access be removed from the role or user to resolve the SoD violation?

3. Can this SoD violation be addressed using other alternatives, such as utilizing SAP

Workflow, user exits, configuration modifications, or business process change?

4. Can this access requirement be addressed using GRC Superuser Privilege

Management for SAP functionality?

5. If the SoD violation is not resolved in steps 1-4, then Mitigation is required

19

How to Conduct a Ruleset Review (Customer Examples)

1. Analyze Deltas between current and “new” ruleset sources

2. Review SoD-sensitive Authorization Object values

3. Review current SoD-sensitive SAP configuration

4. Review SoD-relevant Custom Transaction codes with current Ruleset

5. Review Ruleset completeness for coverage of all SoD-pertinent System functionality

and Audit requirements

20

Example of a Real Assessment – Upgrade from 5.3-10.0

• Current 5.3 Ruleset statistics:

Currently 206 Risks for ECC exist

Only 110 Risks are “Active”

96 Risks have been “Deactivated” (need to get documentation as to reason for deactivation)

56 Risks have had their “Criticality Level” modified

3 Custom Risks have been created by Customer

8 Functions have had T-Codes deactivated (AP01, AP02, AR01, AR03, FI06, FI12, GL03, MM05)

Critical T-codes like F.13 (Automatic Clearing) and F-04 (Post with Clearing), F-44 (Clear Vendor), F-07 (Post

Outgoing Payments)

Currently 4 custom T-codes exist in the ruleset

21

SoD Active Rules vs. Deactivated Rules

Enabled Disabled Percent Disabled

Finance 18 20 53%

Basis 24 0 0%

HR 13 10 44%

Materials Mgmt. 8 8 50%

Procure to Pay 27 46 63%

Sales 19 12 39%

Example of a Real Assessment – Upgrade from 5.3-10.0 (cont.)

22


23

Key Auth Values to Customize

ACTVT 01, 02, 05, 06, 77

$KOART

(Account Type)

A-Asset, D-Customer, K-Vendor, M-

Material, S-General ledger

M_MATE_STA

(Material Views)

B-Accounting, G-Costing,

K-Basic

M_MSEG_BWE

(Movement types for GR)

101-106, 122

M_MSEG_BWA

(Movement types for VL trans)

601-602

M_BEST_BSA

(Order type)

EC, FO, NB

ME28 with M_EINK_FRG

(Release strategies)

Not checked – must be added based

on release strategy for each company

VA01

(Sales order document types)

Critical order types can be included by

supplying values for V_VBAK_AAT

object

$KOART has been deactivated in the new GRC 10.x SAP standard Ruleset

24

SAP Ruleset and F_BKPF_KOA

• In the 10.x SAP Standard Ruleset, the Auth Object of F_BKPF_KOA has been removed as being a primary SoD

validation object

• F_BKPF_KOA was formerly used as the primary security separator for Account type access in all Financial

transactions

• Over time, SAP has changed their position of using F_BKPF_KOA in certain transaction codes, resulting in inconsistent

use of this object in the SAP Security Authorization Concept

• Because of these inconsistencies, SAP has removed the use of F_BKPF_KOA from the standard ruleset. But many

customers still rely on it for SoD separation and identification in their rulesets. This causes the potential of “False

Negatives” if F_BKPF_KOA is left in the existing Ruleset and potential increased SoD violations if it is removed.

• There are currently 150 T-codes in the Customers 5.3 Ruleset that leverage this Auth Object to determine and separate

SoD violations

25

F_BKPF_KOA Examples

This customer still has

F_BKPF_KOA as a primary SoD

check for many financial

transactions, even though the SAP

GRC standard Ruleset no longer

relies on it nor is this Auth Object

checked consistently via security in

the later Basis releases.

26

Missing Customer

Values for key SoD-

relevant Authorization

Objects.

This will cause SoD

false Negatives.

Example of a Real Assessment – Upgrade from 5.3-10.0

27

• You OWN your Ruleset and SoD compliance standards

• Therefore you need to identify and analyze the changes. Then

decide if you agree with the changes based on your compliance

requirements, and then add them to “Your Ruleset.”


• There is NO automatic way to incorporate SAP standard Ruleset changes into your

Ruleset. That is a GOOD THING!

28


But be careful with these reports, just because an Action or Permission is

contained in your Security Roles, it does not mean it is SoD-relevant and

should be in your GRC Ruleset!

• GRC also provides some useful

reports to identify Actions and

Permissions absent from your

Ruleset

29


• GRC 10.x Ruleset statistics changes for this customer:

3 additional Risks have been added: B020, B021, BSNA

1 new function has been added (BS20)

23 functions have additional T-Codes added

30


• Customer has a total of 2,203 custom T-Codes

• Analysis findings:

582 – Inadequate T-code Description

901 – Not believed to be SoD-Relevant

574 – Report/Display

50 – Table Maintenance

96 – Investigated for SoD Relevance

58 T-codes recommended to be added to the Customer Ruleset

31

• Only 4 custom t-codes

existed in this

customer’s SoD ruleset

• They are:

ZR08 – Cancel

Invoice Document

ZPA30 – Maintain HR

Master Data

ZPA40 – Personnel

Actions

ZPA61 – Maintain

Time Data


32


So what was the end result for the company?

#1. Overall SoD violations statistics did increase. Thus requiring additional remediation and mitigation activities. But some pre-

existing risk “False Positives” were also eliminated due to misconfigured auth object values resulting in decreased SoD

statistics in some areas.

#2. Customer had a much better insight into their Ruleset and received a training refresher on Ruleset configuration activities

and best practices.

#3. Customer enhanced their SoD change control process to be more proactive in keeping their Ruleset current and accurate

as well as incorporated CTS (correction and Transport process) in GRC 10.

#4. Customer has a significantly increased level of confidence in the results being produced by their GRC applications.

33

What We’ll Cover






• Wrap-up

34

The 3 critical components of a “Proper” or “Good”

Mitigating Control are:

1. Detailed and Clear Documentation

2. Accountability and Ownership

3. Monitoring and Follow-Up

What Makes a Mitigating Control Good vs. Bad?

• After years of GRC implementations, I consistently see Mitigating

Controls being the most misunderstood and misused item

35

The 3 critical components of a “Proper” or “Good”

Mitigating Control are:

1. Detailed and Clear Documentation

2. Accountability and Ownership

3. Monitoring and Follow-Up

What Makes a Mitigating Control Good vs. Bad? (cont.)

• Most companies are good at documenting and assigning ownership

of Mitigating Controls in their organizations. But monitoring is where

the deficiencies usually occur, because companies find monitoring

difficult, time-consuming, and expensive.

36

Putting Mitigating Controls into Perspective

My Mom was an expert at Mitigating controls when I was a kid!

Yours was probably too.

• If little James needed to leave school to go

to the Doctor’s office, my Mom would write

a note to my teacher to excuse me from

school.

• This was to establish a mitigating control so

I wouldn’t skip school for the rest of the day

…

Let’s break it down using common sense!

37

Breaking a Mitigating Control into Common Sense

#3 – Monitoring and Follow-Up:

• My teacher would then monitor that I was only away for the time my Mom

stated in the note. If I was gone longer, she would call my Mom … and

then the enforcement and corrective action would begin.

#1 – Detailed and Clear Documentation: • My Mom would write a note in her own handwriting stating the time I

would be absent and the time my Doctor’s appointment was scheduled

for #2 – Accountability and Ownership:

• My Mom would sign the note and provide her phone number if the

teacher had any questions or concerns

38

Control Common Sense

So would your Mom approve of this company’s

Mitigating Control?

“Per discussion with the Director of Procurement and Materials

Management, Head Buyer, and Stores and Inventory Manager,

the functions of Create/Change Requisition and Automatic

generation of Purchase Order are performed by the Stores’

Managers and Buyers as part of their standard duties. To limit

exposure, the same individual cannot purchase unauthorized

items and hide by not fully receiving order. Also, limit exposure

to requisition an item and create a Purchase Order from that

Requisition. To address the remaining risks identified by SAP

GRC Access Control 5.3 – SoD at the User level, we have created

the following Mitigating Control.”

39

Control Common Sense (cont.)

So would your Mom approve of this company’s

Mitigating Control? (cont.)

“In India, the finance leader has the ability to

approve credit limits for customers in India and

post journal vouchers. At period-end, the

Regional Finance Director must review journal

vouchers. Please refer to document SAP

Corporate Global Journal Entry Review Process

Vs2 for details.”

40

A Quote from a Real GRC Customer

“We just Mitigate everything and our SoD problems go AWAY!”

41

Why Are Mitigations Misunderstood or Misused?

E.g., Frank needs to review reports every 30 days containing all vendor creations and

vendor payments to make sure Sally and the other 250 people assigned his Mitigating

Control are not abusing their access.

Not an easy task for Frank who also needs to do his “regular job” too!

• Mitigations can be very time-consuming and expensive to execute consistently, especially if you rely on

Manual type controls

• Most organizations have been fulfilling audits requirements by only needing to show documentation rather

than monitoring results. But this is gradually changing as Audits become more detailed.

• Building a detailed control can be difficult, requiring multiple people in a company to work together. In some

organizations this can be very challenging without direct ownership and management driving the initiative.

• Some organizations still see Mitigations as an “Easy Way Out” and a tool to avoid needing to permanently

“fix” or remediate problems

42

Mitigation Maintenance – New in 10.1 SP11!

Many companies assign mitigating controls for VERY long periods of time so the don’t need to spend significant amounts of

time renewing or maintaining the assignment information.

This is NOT a good practice. Now SAP provides some additional “Mass Maintenance tools” to help reduce the “Clicky Clicky” of

Proper mitigation assignments.

43

New Mitigation “Clean Up” Functionality

44

What We’ll Cover






• Wrap-up

45

“It takes a village to build a good ruleset for SoD

compliance and appropriate Mitigating Controls”

Many different people need to participate in the rule definition

portion of the project to provide different perspectives,

priorities, and technical detail to the ruleset configuration

Key people that should be involved in the SoD ruleset definition workshops are:

• Business Process Owners

• Audit and Compliance Representatives

• Security Administrators

• Compliance Calibrator Rule Keeper and Administers

Words to Live By

46

Compliance Team

SoD Rule Keeper

Audit

Mitigation Monitors

Mitigation Approvers

Role Owners

Risk Owners

Ownership

“It takes a village to be compliant!”

47

Getting the Right People Involved Roles Responsibilities

Business Process Owners

Identify risks and/or approve risks for monitoring

Approve remediation involving user access

Design controls for mitigating conflicts

Communicate access assignments or role changes

Perform proactive continuous compliance

Senior Officers Approve/Reject risks between business areas

Approve mitigating controls for selected risks

Security Administrator and Technical Liaisons

Ownership of SAP GRC tools and security process

Design and maintain rules to identify risk conditions

Customize SAP GRC roles to enforce roles and responsibilities

Analysis and remediation of SoD conflicts at role level

Auditors and Regulators Perform risk assessment on a regular basis

Provide specific requirements for audit purposes

Perform periodic testing of rules and mitigating controls

Act as liaison between external auditors

SoD Rule Keeper Responsible for SAP GRC tool configuration and administration

Maintain controls over rules to ensure integrity

Act as liaison between basis and SAP GRC Support Center

48

“Check and Revise your Rules and Mitigations Early and Often!”

There are two key processes that need to be established for keeping

your Ruleset and Mitigations up to date:

1. Annual Review of Control content and Assignment

2. Proactive Review for when Business processes, functionality, or

security assignments change

Having a regularly scheduled review timeline set before your annual audit process can help ensure Mitigation and

SoD accuracy to eliminate any obsolete compliance data missed during the Proactive review process.

To be proactive you need to include and “bake in” Compliance considerations to you existing change control

processes. So when business processes change or Ownership changes occur there needs to be a trigger of

“What impact will this have on SoDs and existing Mitigating Controls?”

Words to Live By

49

How Do You Track Your Mitigation Change?

If the Auditors come knocking, asking for your Change documentation for

Mitigation content changes, Mitigation assignments, Risk changes, and

Function content modifications, what do you give them?

The GRC provides change History but what about the

“Reasons” or “Approvals for making the changes”?

Where do you track that?

• Emails?

• Spreadsheets?

There is a BETTER way … Using GRC workflow functionality

50

Workflow-Guided Change Control for Mitigations and Rules

• SAP GRC delivers workflow functionality to be able to track ruleset changes

• GRC will track changes to Functions, Risk, Mitigation Controls, and Mitigating control

approvers

51

Are You Covering All Your Bases?

• Do you have SoD Rules for GRC itself?

• Are you at a minimum checking the Basis Rules in all your SAP systems including BW?

• Do you have Rules for ALL your SAP SoD-relevant systems including Web Dynpro (now

supported in 10.1 SP11)

• Do you use SAP GRC for Non-SAP systems?

• Do you report on Cross-System Risks, not just single-system access?

• Do you report on Critical Access in additions to SoDs?

If you’re not covering all the bases for compliance it is like have

a steel door on the front of the submarine but a screen door in

the back

52

Web Dynpro SoD Analysis Support in 10.1 SP11

53

GRC Now Supports Web Dynpro for SoD

• Function SR000002

54

• Function SR000002 permission list

GRC Now Supports Web Dynpro for SoD (cont.)

55

• Risk Analysis results for Role:

Unfortunately action

usage information is not

available for Web Dynpro

activities.

GRC Now Supports Web Dynpro for SoD (cont.)

56

What We’ll Cover






• Wrap-up

57

Where to Find More Information

• https://service.sap.com/ocs-schedules *

SAP GRC 10 Support Pack Schedule

• https://service.sap.com/sap/support/notes/986996 *

SAP Note 986996 – GRC Access Control – Best Practice for Rules and Risks


SAP Note 1663370 – Download Rule Sets for GRC AC 10.0


SAP Note 1243085 – Available Documentation for GRC Access Control 10

• http://youtu.be/G9N7jwc2M0g

Customer Advisory Group instructional video highlighting the difference between ARA

10 and previous GRC releases

* Requires login credentials to the SAP Service Marketplace

https://service.sap.com/ocs-schedules



https://service.sap.com/sap/support/notes/986996



http://youtu.be/G9N7jwc2M0g

58

7 Key Points to Take Home

• An inaccurate, incomplete, outdated, misconfigured, too lax, or too strict SoD Ruleset can

not only impact the efficiency of your SoD reports from ARA but also negatively impact

the effectiveness of ARM, EAM, and BRM as well

• Being on the “Latest and Greatest” version of the GRC technology does not mean your

GRC Ruleset or Mitigations are current and accurate for your business

• Establishing a regular Ruleset Review and Assessment process will add significant value

in staying one step ahead of the Auditors, and increase the quality and confidence you

will have in the results provided by your GRC system

• A “Good” Mitigating Control requires Documentation, Ownership, and Monitoring

If one of these three components are lacking then the risk of a ineffective control grows

exponentially!

59

7 Key Points to Take Home (cont.)

• There is additional functionality in GRC 10.0 and 10.1 to allow for additional Mitigating

Control documentation recording, and linking to outside sources, and even seeing usage

information of mitigated Actions by users

• This allows you to better leverage SAP GRC as the “one-stop shop” for mitigation

documentation during an Audit and to actually know if people are executing the actions

in the SoD being Mitigated

• If you don’t have confidence in your Ruleset, or the results you are getting out of SAP

GRC, or if you believe your Mitigating control library is not working for “Good” and is

more on the “Bad” side, then it is strongly recommended that a Ruleset and Mitigating

Control assessment and modernization project be started

60

Your Turn!

Please remember to complete your session evaluation

61

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

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

Date post:	30-Jul-2018
Category:	Documents
Upload:	lambao
View:	365 times
Download:	13 times

How to Modernize Your SAP Access Control Ruleset...

Documents