case study: how mars successfully completed a...
TRANSCRIPT
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
• 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
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
• 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
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
• 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
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
• 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
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
• 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
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
• 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
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
• 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
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).
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
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.