A Guide to Securing Your SAP ECC System

A Guide to Securing Your SAP
ECC System
Raymond Mastre, CISA, CRISC
Director SAP Security/GRC
PwC
Agenda
• Introduction
• Basic SAP ECC Security Concepts
• Securing your SAP ECC System
• Choosing Your Role Design Methodology
• Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
• Case Study
• Wrap-up
Introduction
• Over 10 years of SAP Security
and SAP GRC Experience
• Completed 10-15 Global SAP
Security Design/Redesigns
• Experience working in Beauty,
Pharma, Public, Defense and
Chemicals Industries
• CRISC and CISA certified
Raymond Mastre,
Director SAP Security/GRC
PwC
Agenda
• Introduction
• Basic SAP ECC Security Concepts
• Securing your SAP ECC System
• Choosing Your Role Design Methodology
• Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
• Case Study
• Wrap-up
Basics SAP ECC Security Concepts
User master record
User requires valid user
ID and password
1
T-code check
User requires an
authorization
for transactions
2
Authority check
User requires an
authorization for
business objects
3
Authorization Analogy
The proper key must be cut specifically for a certain lock
Authorization Analogy
The proper authorization is needed to unlock the SAP program
User
SAP Program
Profile
Authorization
Authorization
Object
Authorization
Field values
Authorization
Object Fields
SAP Security Key Components
•
•
•
•
Authorization (fields and values)
Profiles
Users
Roles
Authorizations and Profiles
SAP Authorization
Structure
There are also
composite profiles that
can have other assigned
single or composite
profiles. For example,
SAP_ALL or SAP_NEW
are composite profiles.
SAP Program
Access Element
Profile
Authorization
Authorization
Object
Authorization
Field values
Authorization
Object Fields
Users
SAP Authorization
Structure
SAP Program
Access Element
User
Profile
Authorization
Authorization
Object
Authorization
Field values
Authorization
Object Fields
Profile Generator
•Security
Admin
creates role and
assigns T-code
menu item(s)
generates
Authorization Data
based on the menu
items and
corresponding
USOBT_C tables
SAP Profile
Generator
SAP Authorization
Structure
SAP Program
Access Element
User
•SAP
USOBT_C
USOBX_C
(SU24)
Roles
Menu
Items
Authorization
Data
Profile
Authorization
Authorization
Object
Authorization
Field values
Authorization
Object Fields
Relevant Security Tables
•
•
•
•
•
•
•
T-code to Role Mapping
Role to User Mapping
Role to Role Name
Roles Within a Composite
Authorizations in a Role
Organization Values in a
Role
Fields Within an Object
•
AGR_TCODES
AGR_USER
AGR_DEFINE
AGR_AGRS
AGR_1251
AGR_1252
•
TOBJ
•
•
•
•
•
Agenda
• Introduction
• Basic SAP ECC Security Concepts
• Securing your SAP ECC System
• Choosing Your Role Design Methodology
• Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
• Case Study
• Wrap-up
Leading Practice Security Designs
Job Based Methodology
Task Based Methodology
User General
AP Clerk
FI Common
Display
AP
Processor
Redundant
Access
AP
Manager
FI
Document
Reversal
FI
Document
Processing
What is Job Based?
 Security roles are built based on positions/jobs for a group of users (e.g.
Accounts Receivable Manager)
 A single role contains all of the access to perform a job
 Transaction codes and authorizations typically duplicated in many roles
AP
Supervisor
AP
Clerk
AP Manager
What is Task Based?
 Security is built based on small, definable tasks executed by a user (e.g. Process
Cash Receipts)
 Multiple roles are assigned to the user for them to perform their day to day tasks
 Transaction codes exist in a single role, with minimal exceptions
FI Document
Reversing
F.80
F.81
SBWP
SU53
FI Document
Processing
FB03
FBV3
User General
FI Common
Display
FB01
FB02
Job vs. Task
Job Based
Task Based
1-3
Number of roles
assigned to users
8-10
25-40
Tcodes per Role
6-10
Significant
T- code
Duplication
Minimal
Role Content Change
On-going change
management
Role Assignment Change
Limited
Scalability
Highly Scalable
High number of roles with SOD’s and SOD
remediation is difficult
SOD
Low or no roles with SOD’s and remediation is
easy
Common Challenges with ECC Security
• Introduction
• Basic SAP ECC Security Concepts
• Securing your SAP ECC System
• Choosing Your Role Design Methodology
• Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
• Case Study
• Wrap-up
Key Areas to Review
The following are key areas to consider when reviewing SAP
security:
– SoD and sensitive access
– Monitoring of sensitive objects
– Security strategy assessment
What are SoD’s and SAs?
•
Segregation of Duties (SoD)
 Helps to establish adequate division of responsibilities
between those that create master data and perform
transactional data
 Example: “Create G/L Account” and “Post to G/L”
•
Sensitive Access (SA)
 Helps to establish that critical functions in a system are
restricted to authorized individuals
 Example: “Post to G/L”
How to Monitor SoDs/SAs
Companies have many different ways to monitor SoDs/SAs
– SAP GRC Access Control
– Other access control systems (Bizrights, ControlPanel, etc.) or
“homegrown” monitoring tools
– Transaction “SUIM”
SUIM
Use transaction SUIM to check for users with sensitive
transactions, objects, or SoDs
Monitor Sensitive Security Objects
S_DEVELOP
S_RFC
Controls “debug” access in
SAP. Value 01 and 02 should
generally not be given in
production.
Allows a user to potentially
perform remote calls to other
systems
S_TABU_DIS
Controls the ability to view or
change tables in SAP. Star
values should be avoided.
S_PROGRAM
Controls program calls in SAP.
As with S_TABU_DIS, avoid
stars.
Security Design Assessment
 A security design assessment benchmarks several key
performance indicators against a successful security design
 Is less concerned with the access a user has and more
concerned with how they got it
 Is completed by performing a statistical analysis of the SAP
Security Environment
Statistical Analysis of SAP Security
Environment
Below are example benchmarks for examining an SAP
security design:
 Number of duplicated transaction codes in roles
 Number of authorization objects in assigned roles
 Number of changed and manually-inserted authorization objects
 Number of roles
 Number of roles with transaction code ranges or wildcards
 Number of changed authorizations
Example: Duplicated Transaction
Duplication of transaction codes complicates the provisioning
process
 Example: User needs access to transaction code VD01. If this
transaction code sits in seven different roles, which one can
we assign?
SAP tables to query
 AGR_1251
 AGR_TEXTS
 TSTCT
Expected query result: 5%-8% transaction codes should be
duplicated
 Exceptions are transaction codes with different functionality; for
example, F110 (create payment proposal, run payment proposal)
Assessing SAP Security Design
Agenda
• Introduction
• Basic SAP ECC Security Concepts
• Securing your SAP ECC System
• Choosing Your Role Design Methodology
• Audit Compliance Topics (SoD and SA) and
Security Design Monitoring
• Case Study
• Wrap-up
Case Study Profile
Company Profile
 Consumer Products (Beauty)
 Original SAP Implementation: Completed in early 2000’s
 Total User Count: ~5,000 SAP User IDs
 SAP GRC 5.3 Installed at time of project start
Before
Prior to Project
 Role Count:
18,000+
 Users:
5,000 (3,000 user with more than just T&E)
 Firefighter Usage:
3,000,000 transactions in first six months
 Business ownership: Limited
 SAP GRC Version:
5.3
After
Prior to Project
 Role Count:
300 task roles (350 enabler roles)
 Users:
5,000 (3,000 user with more than just T&E)
 Firefighter Usage:
150,000 transactions in first six months
 Business ownership: Significant
 SAP GRC version 10
Wrap Up
Top Points to Remember:
 Core elements of SAP security are authorizations, profiles,
users, and roles
 There are two main methodologies for designing SAP security:
Job and task
 Transaction “SUIM” and/or SAP GRC can be used to test for
Segregation of Duties and Sensitive Access
 Sensitive SAP security objects should be restricted
appropriately
 An assessment of SAP security design is one indicator on how
successful your security will be long term
Questions?
Contact me:
[email protected]
This content is for general information purposes only, and should not be used as a substitute for consultation with professional advisors.
© 2014 PricewaterhouseCoopers LLP, a Delaware limited liability partnership. All rights reserved. PwC refers to the US member firm, 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.

Download Report