Case Study: How Sempra Energy Implemented SAP GRC 10.1 …wpc.0b0c.edgecastcdn.net/000B0C/Presentations/GRC2016_Malin_C… · 1 In This Session • Walk through the journey Sempra

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

Case Study: How Sempra Energy Implemented SAP GRC 10.1 and Remediated More Than 500K SoD Conflicts

Paul Malin San Diego Gas & Electric

1

In This Session

• Walk through the journey Sempra Energy and its California utilities — including San

Diego Gas & Electric — went through during the upgrade from SAP GRC 5.3 (using only 2

GRC modules, CUP and SPM) to SAP GRC 10.1 (using all five SAP Access Control

modules)

• See how the company successfully remediated or mitigated over 500,000 SoD conflicts in

the process and learn how the company:

Prepared its role master data (such as business process, sub-process, owners, and

backup owners) for SAP security role provisioning in advance of initial testing and UAT

and, in the process, enabled a thorough understanding of the effect on the business

Completed regression testing of all GRC modules after the upgrade

2

In This Session (cont.)

• See how the company successfully remediated or mitigated over 500,000 SoD conflicts in

the process and learn how the company: (cont.)

Deconstructed composite roles back to single roles for provisioning

Used role redesign to address document-type security configuration changes and

enable SoD conflict remediation

Handled the post-go-live management of SoD, from validating mitigating controls and

defining mitigating control strategy to tying mitigating controls with SoD remediation

3

What We’ll Cover

• Background on Sempra Energy

• Why Sempra upgraded from SAP GRC 5.3 to 10.1

• Preparing for upgrade

• SAP security design changes

• Importance of training

• Post-go-live management of SoD conflicts

• Pros and cons of upgrade

• Wrap-up

4

Background on Sempra Energy

• Sempra Energy, based in San Diego, is a Fortune 500 energy services holding company

with 2014 revenues of more than $11 billion. The Sempra Energy companies’ 17,000

employees serve more than 32 million consumers worldwide.

Sempra Energy’s two California-based Public Utilities are:

San Diego Gas & Electric

4,100 sq. mile service territory

3.5 million consumers served

4,300 employees

Southern California Gas

20,000 sq. mile service territory

21.4 million consumers served

8,300 employees

SDG&E

5

Background on Sempra Energy – SAP Landscape

• One SAP instance used by Sempra Energy parent entity, SDG&E, and SoCalGas

8,000+ users

• Systems connected to SAP Access Control 10.1

Enterprise Central Component (ECC)

Business Warehouse on HANA (BW)

Customer Relationship Management (CRM)

Solution Manager Production (SMP)

Business Planning and Consolidation on HANA (BPC)

PowerPlan – replaced SAP Asset Module

Used for access request workflows only

6

What We’ll Cover








• Wrap-up

7

System Prior to Upgrade

• SAP GRC 5.3 installed in 2009 using the following modules:

Compliant User Provisioning (CUP)

Superuser Privilege Management (SPM)

Risk Analysis and Remediation (RAR)

Module only partially set up and was not utilized for SoD monitoring

Did not fully customize ruleset to match roles and tcodes used

Selected one small department to pilot process

Isolated a few tcodes that could lead to SoD risks in new roles

8

System After Upgrade

• SAP GRC 10.1

Go-live date of 6/4/2015, for the following modules with Service Pack (SP) 6:

Access Request Management (ARM)

Emergency Access Management (EAM)

Business Role Management (BRM)

Access Risk Analysis (ARA)

Go-live date of 10/26/2015 for:

User Access Review (UAR)

Multiple errors encountered during testing that required notes to be applied manually

SAP ultimately recommended upgrade to SP10

9

Why Upgrade

• SoD monitoring had consisted of select areas conducting SOX controls testing

• External Auditors asked for SoD analysis in 2013

Related to the Accounting Close and Fixed Assets SoD risks

Many false positives were included in the scan run through the external auditors’ tool

At least 900 man hours were spent manually analyzing the SoD scan data

• In 2014 estimated 400 man hours to manually analyze Accounts Payable and Revenue

SoD risks

• Upper management wanted preventative control and real-time SoD monitoring

• Upgrade enabled us to become compliant with SOX SoD requirements for our SAP

systems

10

Timeline from >500k to Zero SoD Conflicts

SoD Design

Workshops

Sep ’14 Nov ’14 Dec ’14

Upgrade to

GRC 10.1

SoD Scan of

SAP ECC

Prod: 500,000+

SoD conflicts

identified =

4,500+ user-risk

combinations

Jan ’15

Role SoD

Remediation

Mar ’15

Composite Role

Deconstruction

Doc Type

Redesign

May ’15 Jul ’15

Free of

unmitigated

SoD conflicts

June ’15

Go-Live

Jan ’16

User SoD

Remediation

11

What We’ll Cover








• Wrap-up

12

Preparing for Upgrade

• Review of Role Master Data for over 4,500 roles

Updated and expanded Business Processes to be more descriptive

Updated and expanded Sub-Processes to be more descriptive

Confirmed or updated Role Owners

Added backup Role Owners for all roles

• Crucial to have this completed and roles loaded into test systems prior to starting testing

13

Preparing for Upgrade (cont.)

• Ensure Security Roles are free of inherent conflicts and are not in a composite role

structure

• Allocate enough time for training, full regression testing, and UAT

• Make sure to have proper representative testers from Security, Basis, Business, Support

• Set up proper representative testing scenarios and exceptions

14

During Upgrade

• User Acceptance Testing (UAT)

Performed detailed UAT for each module being implemented

Confirmed that all needed functionality was present and working as desired

• Regression Testing

Post-go-live upgrade from SP6 to SP10 to enable UAR module

Performed additional extensive testing of all modules to ensure that existing defects

were fixed and new defects were not introduced

• Allow for ample time to complete SP upgrades

One seemingly simple fix can introduce new issues

15

What We’ll Cover








• Wrap-up

16

SAP Security Design Changes – Composite Roles

• Composite Role Deconstruction

Composite Roles were used extensively in SAP (530 composite roles)

Set up this way to simplify access request approvals

Composite roles can lead to issues with sustainability and enforceability of SoD

environment

On average users had 5 composite roles giving access to 63 single roles

Users were only actively using 12 single roles on average

Risk: User role cleanup may delay user SoD remediation for conflicts not related to

unused roles.

Solution: Get an additional SAP system set up where you can simulate role removals

ahead of phased cutover schedule. Use this environment to complete user SoD analysis

for any additional remediation actions.

17

SAP Security Design Changes – Composite Roles (cont.)

• Composite Role Deconstruction Example

John Smith has composite role ABC123 and composite role DEF456. An SoD violation is caused by 2

single roles which conflict across the two composite roles. John Smith also has another single role

contained within composite role ABC123 which is not used.

Jane Doe also has composite role ABC123 and is actively using all access in that role

Without composite roles, remediation would be as simple as removing the unused single roles from

John Smith’s user record to remove the SoD violation. With composite roles, this cannot be done without

modifying the composite role, but this cannot be done without impacting users like Jane Doe, who also

have the composite and need all access granted.

User: John Smith

Composite Role ABC123

Single Role X – Role Not Used by User

Single Role Y – Role Not Used by User

Single Role Z – Role Used by User

Composite Role DEF456

Single Role 1 – Role Used by User



User: Jane Doe

Composite Role ABC123

Single Role X – Role Used by User

Single Role Y – Role Used by User

Single Role Z – Role Used by User

18


• Replaced access to most composite roles with only the single roles the users needed

Done in two waves to minimize risk and impact to users during month-end closing

processes

Wave 1: 2,500+ users, 326 composite roles

Wave 2: 4,000+ users, 171 composite roles

17 composite roles were the exception and were kept

General Access Display roles (7)

General Travel and Expense (T&E) access roles (6)

Vendor access roles (4)

• 2,197 SoD user-risk conflicts removed by this change

19


• Downside of Composite Role Deconstruction

At go-live had a large number of new role owners

Many role owners complained about

Volume of roles they owned

Volume of requests they were receiving

Large backlog of requests built up

Some role owners requested that someone else be assigned as role owner

To mitigate some of the backlash set up new composite roles

9 “Exceptional” composite roles for display type access

69 “Shell” composite roles created

Roles are requested at the composite role level

Approved and provisioned at the single role level

20

SAP Security Design Changes – Document Type Authorizations

• Document Type Authorization Redesign

Issue – existing Document Type configuration inherently caused SoD conflicts

44% of High-Risk SoD conflicts could not be remediated

Document type configuration was initially configured using Authorization Groups that

combined many different document types grouped by major category

Example Authorization Groups – Vendor, General Ledger, Assets, Customers

Vendor (VNDR) contained document types supporting both vendor payments and

vendor invoice processing, a High-Risk SoD in our ruleset

Could not remediate these conflicts without significant process re-design to change

responsibilities of affected users

21

SAP Security Design Changes – Document Type Authorizations (cont.)

• There are two approaches to re-designing the configuration and provisioning of

document types:

Note: Sempra had a hybrid of the above options. Some of the document types followed

option 1 and others followed option 2.

Option 1: 1-to-1 mapping of document types to authorization groups

Under this option, every document type would be in one authorization group which matches the document type itself –

i.e., Document Type “SA” would be placed in the authorization group “SA” and no other document types would be

included in this authorization group.

Option 2: New authorization groups to group like document types

Under this option, all like document types would be grouped together into logical groupings – i.e., All document types

which process vendor payments (KZ, ZH, ZP, etc.) would be grouped together into a new authorization group “AP01.”

22


• Implementation Options – Pros and Cons

Option #1: 1-to-1 mapping of document types to authorization groups

Pros Cons

Simplicity – it will be obvious to Role Owners when

looking at their roles what document types they will be

granting access to since the document type names are

listed in security build.

Maintenance – Whenever a new document type is

created/changed, the following activities will be required:

• Update system configuration

• Update build of all roles which will require the new

document type

• Update the GRC ruleset to reflect the new document

type

Deliberate – roles are deliberately granted access to

individual document types and roles will not inherit

additional document types they may not need.

23


• Implementation Options – Pros and Cons (cont.)

Option #2: New authorization groups to group like document types

Pros Cons

Ease of Maintenance – whenever a new document type

is created/changed, only a system configuration will

need to be updated to reflect the new authorization

group. Roles will be automatically updated and GRC

ruleset will continue to be accurate.

Education and Training – It will be critical to keep

authorization groups accurate and up to date. Role/data

owners will need to understand how document types are

grouped. If a new document type is placed into the

wrong grouping, it could result in an SoD conflict that will

not be detected by GRC. Simplicity with respect to SoD impact – we would

propose new authorization groups which would match

GRC functions. Therefore, the risks associated with

document types would be clear to GRC owners and

compliance personnel.

24


• Decided on Option #1: 1-to-1 mapping of document types to authorization groups

121 authorization groups created

• Required configuration changes, roles changes, and rule set changes to be implemented

simultaneously

• Only granted access to appropriate Document Types for each role

Did not give all A/P document types that were in the VNDR authorization to all A/P roles

• 5,000+ users and 150+ roles affected

Used two rounds of unit and user acceptance testing

Be sure to get business users involved

Eliminated 129 SoD user-risk document type conflicts

Created an Emergency All Document Type role to use during storm period

25


• Not quite all document type conflicts were eliminated

Performed additional configuration changes to limit the use of the AB document type

This document type was the default value for document reversals for A/R, A/P, and G/L

postings

Also used for T&E reimbursements

Created three new document types and authorization groups for reversals

Changed configuration, roles, and rule set to only allow AB documents for T&E

This eliminated 11 additional SoD user-risk conflicts

26

SAP Security Design Changes – BRM

• Even though we owned the predecessor to BRM, we never fully utilized it

It was not fully implemented before the upgrade to 10.1

Had started to use new role naming convention that is required for the automatic role

creation process

• During UAT and regression testing, validated functionality was working as expected

• Due to security changes implemented in 2015 for this project, have not been utilizing all

of the functionality of BRM

• Intend to more fully utilize this module now that the GRC environment is more stable

27

What We’ll Cover








• Wrap-up

28

Importance of Training

• GRC 10.1 introduced many changes in look and operation when compared to 5.3

Having clear, complete, and concise training materials became essential

• Due to the implementation of additional modules of GRC and the new layout and

processes, extensive training was needed for

GRC administrators

SoD Compliance team

Manager approvers

Role owner approvers

EAM Controllers

Requestors

• Training materials included Quick-Steps for each activity and responsibility

29

Importance of Training (cont.)

30


31


• Developed mandatory live training for role owners to introduce them to:

New SAP GRC tool features

SoD concepts and requirements

Role Owner responsibilities

SAP Access request and approval lifecycle

32


• Changes introduced for ARM – Access Request Workflows

The upgrade added real-time SoD conflict assessment

Role Owners required to run SoD Risk Analysis before approval

If an SoD risk exists on a request is it routed to the SoD Compliance team for final

assessment before provisioning

33

Importance of Training – ARM – Access Request Workflow

34

What We’ll Cover








• Wrap-up

35

Post-Go-Live Management of SoD Conflicts

• SoD Risk Management Lifecycle

• Validating Mitigating Controls

• Defining Mitigating Control Strategy

• Tying Mitigating Controls with SoD Remediation

• Ongoing Monitoring

• Established Governance Committees

36

SoD Risk Management Lifecycle

Continuous

Monitoring and

Compliance

Define

Risk

Build

Ruleset

Perform

Analysis Remediate Mitigate

• Identify risks

• Determine

impact and

likelihood

levels

• Rank each risk

as High,

Medium, or

Low in terms

of financial

impact to the

organization

• Translate

business risk

definitions

into SAP

access

authorization

• Build

customized

Ruleset and

configure in

GRC

• Check for risk

violations at

role and user

levels

• Analyze risk

violation

results

• If needed

modify Ruleset

as appropriate

• First stage of

eliminating

risk violations

• Remediate

through

modifying

roles, users’

access, or

combination of

both

• Enforce

Principle of

Least

Privileges

• If remediation

is not

possible,

determine

appropriate

mitigating

controls

37

Validating Mitigating Controls

• During initial workshops defined all risks as one of the following:

Risk Definition Risk Management Strategy

LOW

Limited financial

exposure and/or

minor negative

impact.

Access allowed without remediation or mitigation.

Access will be permitted for these SoD violations.

Low-risk SoD violations will be evaluated on an as-needed basis.

Procedures will be put in place to periodically re-evaluate Low risks and determine if rating is still appropriate.

Guidance: Blanket mitigating control will be automatically applied to low-risk SoD violations.

MEDIUM

Moderate to

significant financial

exposure and/or

negative impact.

Remediate or mitigate.

Access will be permitted as long as a strong SOX mitigating control is in place.

Mitigating control must be tested at least annually to ensure ongoing operating effectiveness in accordance with SOX requirements.

Exceptions and mitigating control(s) are monitored periodically for compliance.

Guidance: Business Control and Compliance team will apply mitigating control when remediation is not possible for medium-risk SoD

violations. Remediate through the removal of access, through the replacement of production access with firefighter access, or mitigate by

applying mitigating control.

HIGH

Highly significant

physical or

monetary loss,

major or

catastrophic

negative impact.

Remediate only.

Access with High SoD violation is not permitted. All high-risk violations are to be remediated only.

Guidance: Remediate conflict. Remediate through the removal of access or through the replacement of production access with firefighter

access.

38

Validating Mitigating Controls (cont.)

• During ramp-up for go-live

Held User SoD Remediation workshops with managers of business areas that had

users with Medium or High SoD conflicts

For Medium risks gathered information for existing mitigating controls

We have defined that all SoD mitigating controls must be SOX controls

For High risks worked with them to find best way to remediate

• Not all SoD user-risk conflicts were cleared once we went live

Had to work with process owners and SOX coordinators to

Identify existing SOX controls or

Create new SOX controls that were then added as mitigating controls in ARA

• Currently have 34 mitigating controls defined

15 Finance, 12 Order-to-Cash, 7 Procure-to-Pay

Be sure to stress that

the SoD risk exists not

because the user has

done or would do

something wrong, but

because they could

based on their

existing SAP access.

39

Defining Mitigating Control Strategy

• Design business-driven controls

• Mitigating controls can be preventative and/or detective

• Define granular and SAP-specific mitigating control first, use higher-level entity controls

second

• Establish official control standard ID through existing SOX control change management

process to finalize and approve control for mitigation

• Ensure governance by having compliance team configure controls in SAP GRC

• Reference SOX control ID in the mitigating control description within SAP GRC tool

40

Tying Mitigating Controls with SoD Remediation

• SoD Compliance Team receives ARM requests with SoD violations and applies

appropriate mitigating controls to users with Medium Risks

No High Risks are allowed to be provisioned

Roles causing High-Risk conflicting access are removed prior to provisioning

41

Ongoing Monitoring

• Run weekly scan every Monday (5:30 am) to make sure no new SoD conflicts appear

Watch for users appearing on user scan unexpectedly

(User SoD conflicts appeared without having first gone through SoD Compliance

Team review)

Could be a system glitch or indicate a problem

Can happen if allow multiple open requests per user per system

Can happen if security makes manual changes to access in back-end system

Could be due to an existing user having their name and login ID change

Assigned mitigating controls are tied to user ID

42

Established Governance Committees

• To provide ownership and accountability to sustain SoD free environment established the

following governance committees

Oversees other

SoD committees,

meets quarterly.

Oversees maintenance and

effective change management of

SAP user provisioning activities

in Access Control system,

meets monthly.

Oversees rule set responses to

business process and system

changes that could otherwise

create gaps in functioning

Ruleset, meets monthly.

Governance Operating Committee

SoD Ruleset Management Committee

User Provisioning and SoD Tool Management Committee

43

What We’ll Cover








• Wrap-up

44

Pros and Cons of Upgrade – What Was Successful

• Implemented a customized SoD ruleset that is free of false positives and inclusive of best

practices

• Increased understanding, awareness, and ownership of SoD issues

• Automated preventative control to manage SoD

• Identified and remediated or mitigated all known SoD issues

• Implemented workflow to confirm that all Firefighter logs are reviewed

45

Pros and Cons of Upgrade – What Could Have Gone Better

• Increased number of roles that have to be approved

• Learning curve for new role owners

• Not all functionality that our SAP Security team had relied on carried over from GRC 5.3

to GRC 10.1

• UAR did not work properly with our security design without having to upgrade to SP10

46

Pros and Cons of Upgrade – Opportunities for Improvement

• Eliminate duplicate transactions across roles, tcode ranges

• Eliminate unused tcodes from roles

• Remove unused roles from users

• Define process for managing “Critical Access”

• Utilize GRC to automate the request and provisioning to GRC system

• Integrate Process Control

47

What We’ll Cover








• Wrap-up

48

Where to Find More Information

• Alessandro Banzer, “SAP Access Control – Useful Documents, Blogs, Resources (SCN,

September 2015).

http://scn.sap.com/docs/DOC-57438

• Michael Adolphson and Justin Greis, “A Risk-based Approach to SoD” (ISACA Journal,

Volume 5, 2009).

• Kevin Kobelsky, “Enhancing IT Governance With a Simplified Approach to Segregation of

Duties” (ISACA Journal, Volume 4, 2014).

• “The New Necessity: Finding ROI from GRC” (KPMG, 2014).

https://advisory.kpmg.us/content/dam/kpmg-advisory/PDFs/RiskConsulting/new-

necessity-finding-roi-from-grc.pdf






https://advisory.kpmg.us/content/dam/kpmg-advisory/PDFs/RiskConsulting/new-necessity-finding-roi-from-grc.pdf













49

7 Key Points to Take Home

• Important to have complete and up-to-date role master data for SAP Security role

provisioning early in the process

• Make sure to regression test all GRC modules when upgrading

• Open and frequent communication with SAP support staff is key when resolving software

bugs via OSS notes

• Pitfalls of having to deconstruct composite roles back to single/derived roles for

provisioning

• Impact of document type configuration changes on access roles and SoD conflicts

• Make sure to thoroughly train your approvers (managers and role owners)

• Important steps for maintaining an SoD free environment

50

Your Turn!

How to contact me:

Paul Malin

[email protected]

Please remember to complete your session evaluation

51

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.