Case Study: How Mars Successfully Completed a …wpc.0b0c.edgecastcdn.net/000B0C/Presentations/GRC2016_Kowalick...a Global SAP Security Redesign with SAP ... Ability to support IdM

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

Case Study: How Mars Successfully Completed a Global SAP Security Redesign with SAP Access Control and Built a Security “Playbook” to Guide the Project

Donna Kowalick Mars

1

In This Session

• In 2013, Mars, Incorporated (Mars) embarked on an effort to revamp its SAP security,

reduce segregation of duties (SoD) risk, and increase efficiencies around user access

provisioning. This session will provide insight to our redesign approach including:

Key focus areas for a SAP security redesign

Security and Access Foundations

GRC Access Control

Deployment approach and considerations in a large, complex SAP environment

• Your learnings from this session will include:

Phases and structure of a security redesign and deployment project

Foundations to establish for the project and the future steady state

Deployment tools and activities which support a large scalable rollout

2

What We’ll Cover

• Examining the company background

• Understanding the project background

• Designing the SAP Access Control roadmap

• Describing the SAP security redesign approach

• Taking a look at the “playbook”

• Discussing the lessons learned and success stories

• Exploring the next steps in the SAP security roadmap

• Wrap-up

3

Company Background

• The 6th largest private company in the U.S.,

founded in 1911

75,000 employees in 73 countries

Over $33B in net sales

Six Segments

Mars Chocolate

Mars Petcare

Mars Food

Mars Drinks

Mars Symbioscience

Wrigley

4

What We’ll Cover








• Wrap-up

5

Project Background

Key Concern: Excessive Access and Financial Risk Exposure

Over assignment of roles led to users with more access than required for their day-to-day job

responsibilities

Excessive number of roles created without consideration of job responsibility or SoD restrictions

No formal role naming convention or policy was established which led to roles which were not

easy to identify or understand

User provisioning process was inconsistent globally, manual and inefficient

Outdated GRC tool was being utilized with a segregation of duties ruleset which was not aligned

with business risks and analyzed SoD violations only at the transaction code level

Decentralized business culture with different security and business processes being followed

across the globe which eliminated “big bang” roll-out approach

6

Project Background (cont.)

Solution: A Phased Project Approach

SAP Security Assessment – understand current environment, define future state and evaluate

implementation options

Enablement Phase – establish Governance processes, define policies/procedures, identify

project team, redesign global template roles and upgrade Virsa tool to GRC

Pilot Rollout – identify pilot location, finalize redesign of SoD free roles and implement automated

GRC user provisioning

Global Rollout – apply lessons learned from pilot, perform rapid deployment of redesigned roles

and new GRC tool to all remaining sites

SECURITY

ASSESSMENT

(2012)

ENABLEMENT

PHASE

(2013)

PILOT

ROLLOUT

(Q4 2013 – Q1 2014)

GLOBAL

ROLLOUT

(2014 – 2016)

7

What We’ll Cover








• Wrap-up

8

SAP Access Control Roadmap

Upgraded Virsa 4.0 to GRC 10.0 – Access Risk Analysis (ARA) & Emergency Access

Management (EAM)

SoD ruleset was reviewed and updated to address risks specific to Mars

A full cleanup of inappropriate Firefighter (FF) assignments was performed

VIRSA 4.0 UPGRADE

TO GRC 10.0

(2013)

IMPLEMENT GRC

ARM & BRM

(2013 – 2014)

ROLL OUT GRC

GLOBALLY

(2014 – 2016)

UPDATE &

MAINTAIN GRC

(Ongoing)

Implemented GRC Access Request Management (ARM) and Business Role Management (BRM)

Determined an approval workflow appropriate for Mars that would apply globally

Selected a pilot location and performed in-depth training and roll out

Roll out of GRC globally

As redesigned security is deployed, sites are also trained to use GRC going forward

Update and maintain GRC system on an ongoing basis

9

SAP Access Control Implementation Plan – Phase 1: ARA & EAM

Note: A key driving factor in the length of the project was the complexity of the Mars SAP environment.

• Keep your auditors involved and informed throughout each phase of the project. This will

avoid any issues or rework at the end of the project.

10

SAP Access Control Implementation Plan – Phase 2: ARM & BRM

Note: A key driving factor in the length of the project was the complexity of the Mars SAP environment.

11

Firefighter Remediation Effort

Another pain point that needed to be addressed was the heavy usage/reliance on Firefighter (FF)

and therefore a separate remediation effort was initiated in parallel

Prep Phase – Cleaned up GRC setup issues

Removed 62% of FF assignments and 24% of FF IDs

Removed instances where the FF user and controller were the same

Phase 1 – Redesigned FF roles and established a 3-day limit on access

Phase 2 – Reduced reliance on FF by transitioning access from FF roles to day-to-day roles

(as appropriate), including display transactions

Phase 3 (in progress) – Remove FF troubleshooting IDs and enforce use of Production

“mirror” systems to recreate issues

12

Firefighter Remediation Effort – Reporting Examples

• On an ongoing basis, we are continuing to monitor Firefighter usage in a number of ways

to identify areas where usage can be reduced further

13

What We’ll Cover








• Wrap-up

14

SAP Security Redesign Approach – Key Considerations

“Task-based” template roles were created by functional area and then derived for each unit by the

required organizational level (i.e., company code)

Tier 1: General, Tier 2: Display, Tier 3: Update, Tier 4: Critical Access

A 4-tiered role architecture was employed to designate access within roles

A naming convention was established so that all roles would be easy to identify and to understand

the access that was granted within each role

A major challenge in the legacy environment was determining proper ownership for roles since

roles were not being maintained appropriately

By establishing task based roles which were easy to interpret and also creating the proper

supporting documentation for each role, individuals felt more comfortable taking ownership of

the roles

These role owners could then be included as approvers for role assignments within the access

request process in SAP Access Control

15

SAP Security Redesign Approach – Key Considerations (cont.)

This will help reduce the overall SoDs in your environment by restricting them at the role level

Since SoD risks are created by two or more conflicting functions, the “task-based” security

approach inherently avoids SoD risks at the role level since each role contains just the access

needed for that task or function

A policy was established that all template roles should be kept SoD-free

Compiled and built a Global Compensating Controls repository

This enabled designated controls managers to have the ability to mitigate user-level SoD risks

for their unit by following pre-determined compensating controls

To monitor and confirm that compensating controls were being followed by each unit, a

quarterly certification process was established

16

Understand the various SAP security architecture design concepts, such as job-based vs. task-

based roles, to make the best possible choice for your organization

Selecting the SAP Role Type

Criteria Advantage

Job-Based Task-Based

Restrictive security

Scalability / Ability to sustain organization change

Ability to maintain compliant (SoD-free) environment

Limited number of roles per user

Limited time to analyze and create roles

Ease of creation / design of roles initially

Ability to support IdM tools user provisioning

Ability to support role mgmt. / ownership process

Avoid functionality duplicated in roles

Transparency of security in role

Imp

ort

ance

Identify key metrics to monitor the success of your design architecture

17

Naming Convention

Work with the business to create a naming convention everyone would understand as they go

through the provisioning process

• Be sure to keep the appropriate role owners involved on an ongoing basis for alignment

purposes to promote ownership of the roles

ZS3:SPM-PM_Plan-Admin_121_CA01

Role Identifier Functional Area Company Code

Global BP Task Plant

Role Identifier Abbreviation Role Tier Designation M = Master (or Template) 1 = User General

C = Composite 2 = Display/Reporting

D = Derived 3 = Update Activity

S = Single 4 = Critical/Tech Access

18

New Security Model – Analysis of an Example User

Transactional Analysis summary:

4 months captured for production instances, 12 months captured for pilot users

9,866 unique users with execution history

~5,000 unique transactions executed, ~ 170MM transactions processed

Current State – Example User

• 86 active roles assigned

• 1494 transactions assigned (784

transactions are executable)

• 710 (of 1494 transactions ) are

duplicate (assigned in multiple roles)

Future State – Example User

• Will have ~21 assigned roles

• 229 executable transactions to be

assigned

• 2 duplicate transactions to be

assigned (third-party display)

19

What We’ll Cover








• Wrap-up

20

The “Playbook” – Background

Once the pilot rollout was completed, time was dedicated to prepare

for the global deployment.

Lessons learned from the pilot were discussed, including the need

for a “template” package of documents, emails and deliverables

which should stay consistent as we roll out from site to site. This

package is now referred to as our “playbook”.

A major pain point for the legacy security environment was the fact

that security had become decentralized and several different

processes were being followed across the globe – the playbook was

a way to establish a consistent approach and message throughout

the project.

21

The “Playbook” – Deployment Plan

The first step was to build a SAP Security Deployment Plan

22

The “Playbook” – Development

Email communications to be sent to the business unit – both for informational purposes

and for information gathering

PowerPoint documents to be used for kick-off meetings during each phase of the rollout

(e.g., initial, user acceptance testing) and training sessions

Excel documents leveraged for most activities (e.g., execution history, user mapping

files, user acceptance testing scripts)

“Instructions” included for all files to detail step-by-step guide on assembling files for

each business unit

Utilized Deployment Plan as the starting point and built template documents needed for

each task within the plan

23

The “Playbook” – Examples

Pre-Rollout Questionnaire – Excel file sent to business units prior to project kick-off to

confirm user population, provide unit’s associated company codes/ plants, provide list of

local project contacts, etc.

UAT Kick-Off Presentation – PowerPoint file which outlines steps and approach for UAT,

walkthrough of test scripts, and enforces project timeline

Day-in-the-Life Testing Tracker – Excel file which builds a dashboard of charts which

shows the testing progress for each functional area

Some examples include:

An instructions tab is included in this file which gives step-by-step instructions to

the project team lead on how to build the dashboard

Go-Live Communication – Email template which details information regarding the unit’s

go-live including steps to follow during hyper care and necessary contact information

24

The “Playbook” – Lessons Learned

Playbook needs to be “living” repository which continues to be expanded and updated

during global deployment

Be flexible with your users but be careful not to compromise any of your

established policies. In order to maintain our policy of an environment with all SoD-

free roles, the use of composite roles was not explored.

Ex. Larger sites requested use of “model roles” (grouping of task-based roles via GRC

template-based request) and therefore a step to determine role mapping approach

was added to the deployment plan and necessary files added to the playbook.

Utilized a centralized SharePoint location with access restricted to the Project Team

members

As new team leads and members joined the project team, instructions were updated

to be clearer

25

The “Playbook” – Recognized Benefits

Deploy a consistent approach (security policies and procedures) and deliver a consistent

message at a global scale

Huge win for a SAP security environment which was previously decentralized and

inconsistent globally

Ability to easily incorporate multiple objectives (security redesign and SAP Access Control)

into one plan and modify as needed

E.g., Adding model role approach for large sites

Easy to bring new team members onto the project

Training/transition is simplified as all necessary files are linked to the deployment plan

and step-by-step instructions included

Roll out at a rapid pace to multiple sites concurrently

E.g., Currently 10 sites are in progress

26

What We’ll Cover








• Wrap-up

27

Overall Lessons Learned

Allocate enough time for proper planning prior to starting the project

Planning workshops are key to align on project requirements, timelines, etc.

Ensure you build a project team with representation from key areas

Governance, IS, Business, as appropriate

Build appropriate resource needs into plan

Determine contingency plan if additional resources are needed

Create a Steering Committee with key executives across functional areas

Important to gain their trust and support for when challenges arise

28

Overall Lessons Learned (cont.)

Be ready for unexpected changes to your project team

Keep all project documentation (i.e., playbook) organized and in a centralized location

to simplify training/transition

Prepare for resistance

People do not like change, so be ready to explain why this initiative is important, the

short/long-term benefits, etc.

Keep key stakeholders informed throughout the project

Updates on project progress and success stories (i.e., newsletters) can go a long way

in building credibility and relevance for your project

Individual communication from global management acknowledging the efforts of each

rollout site provides recognition of the hard work required and achievements

29

Success Stories – Summary

Over 20 business units and several units in the IS organization, with over 8,000 users, have

gone live with redesigned SAP security and are now using SAP Access Control to provision

access to their users

Manual, inefficient process reduced and users able to receive access faster

Virsa 4.0 system was upgraded to SAP Access Control 10.0

User-level segregation of duties risks and violations reduced by 90%

Number of local compensating controls needed to be performed reduced by 80%

Huge win since this reduces work load for the business!

30

Success Stories – Business Units Completed/In Progress

3,000

470

4,550

750

3,000

2,000

600 530

820

Completed

In Progress

225

60

31

Risk Violations

Success Stories – Key Performance Indicators (KPIs)

1,374,439

92,844

Before After

Risks

1,337

160

Before After

Controls

543

98

Before After

93% 88% 82%

32

What We’ll Cover








• Wrap-up

33

Next Steps in the SAP Security Roadmap

Complete global rollout to entire user population (15,000 users) on primary SAP financial

system Currently on track to complete roll outs by November 2016

Perform final cleanup activities

Remove all legacy roles from entire environment

Analyze all users in system to find any unclassified users

Remove system link to legacy tool so all access requests performed through Access Control

Complete all open items with business units and transition to steady state team

Formulate plan to perform similar SAP security redesign on other SAP systems

34

What We’ll Cover








• Wrap-up

35

Where to Find More Information

• www.protiviti.com/en-US/Pages/PodcastDetail.aspx?AssetId=97

“Understanding SAP Security Architecture and Redesign” (Protiviti Podcast).

• www.protiviti.com/en-US/Documents/White-Papers/Risk-Solutions/Designing-SAP-

Application-Security-Protiviti.pdf

“Designing SAP Application Security – Leveraging SAP Access Monitoring Solutions

During SAP Implementations, Upgrades or Security Redesign Projects” (Protiviti,

2014).

• www.protiviti.com/en-US/Documents/White-Papers/Risk-Solutions/SAP-Access-Mgmt-

Governance-Getting-It-Right-Protiviti.pdf

“SAP Access Management Governance: Getting It Right, Making It Sustainable”

(Protiviti, 2013).

http://www.protiviti.com/en-US/Pages/PodcastDetail.aspx?AssetId=97



http://www.protiviti.com/en-US/Documents/White-Papers/Risk-Solutions/Designing-SAP-Application-Security-Protiviti.pdf















http://www.protiviti.com/en-US/Documents/White-Papers/Risk-Solutions/SAP-Access-Mgmt-Governance-Getting-It-Right-Protiviti.pdf





















36

7 Key Points to Take Home

• Perform a thorough assessment of your SAP environment to identify key areas of

improvement

• Assemble the right team that consists of management from key areas and consult the

experts to leverage best practices, lessons learned, and SAP security knowledge

• Allow ample time in the beginning of the project for planning workshops and discussions

to align on the “to-be” processes that make sense for your business

• Build a SAP security roadmap which includes SAP Access Control to gain the benefits of

automation and proactive SoD monitoring

• Create a playbook that can assist you in delivering a consistent product in an efficient

manner with a rapid deployment to your various business units

• Take time to train your key users who will sustain the process going forward

• Involve your Governance team to develop and implement the right policies and

procedures for your steady state processes

37

Your Turn!

How to contact me:

Donna Kowalick

[email protected]

Please remember to complete your session evaluation

38

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.