A Guide to Securing Your SAP ECC Systemdocshare04.docshare.tips/files/25054/250545123.pdf · A...

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






• Case Study

• Wrap-up

Basics SAP ECC Security Concepts

1

User master record

User requires valid user ID and password

Authority check

User requires an authorization for business objects

T-code check

User requires an authorization for transactions

2

3

Authorization Analogy

The proper key must be cut specifically for a certain lock

Authorization Analogy

Profile

Authorization

Authorization Object

Authorization Field values

Authorization Object Fields

User

The proper authorization is needed to unlock the SAP program

SAP Program

SAP Security Key Components

• Authorization (fields and values)

• Profiles

• Users

• Roles

Authorizations and Profiles

Authorization Authorization Object



Profile

SAP Authorization Structure

SAP Program Access Element

There are also composite profiles that can have other assigned single or composite profiles. For example, SAP_ALL or SAP_NEW are composite profiles.

Users

Profile






User

Profile Generator

Profile






SAP Profile Generator

Menu Items

Authorization Data

USOBT_C USOBX_C

(SU24)

Roles

User

•Security Admin creates role and assigns T-code menu item(s)

•SAP generates Authorization Data based on the menu items and corresponding USOBT_C tables

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






• Case Study

• Wrap-up

Leading Practice Security Designs

Job Based Methodology Task Based Methodology

User General

FI Common Display

FI Document Reversal FI

Document Processing

AP Clerk

AP Manager

AP Processor

Redundant Access

What is Job Based?

AP Supervisor

AP Clerk

AP Manager

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

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

User General

SU53

SBWP

FBV3

FB03

F.81

F.80

FB02

FB01

FI Document Reversing

FI Document Processing

FI Common Display

Job vs. Task

1-3

25-40

Significant

Role Content Change

Limited

High number of roles with SOD’s and SOD

remediation is difficult

8-10

6-10

Minimal

Role Assignment Change

Highly Scalable

Low or no roles with SOD’s and remediation is easy

Job Based Task Based

Number of roles assigned to users

Tcodes per Role

T- code Duplication

On-going change management

Scalability

SOD

Common Challenges with ECC Security

• Introduction






• 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

S_TABU_DIS

S_PROGRAM

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

Controls the ability to view or change tables in SAP. Star values should be avoided.

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






• 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.

A Guide to Securing Your SAP ECC Systemdocshare04.docshare.tips/files/25054/250545123.pdf · A...

Documents

Transcript of A Guide to Securing Your SAP ECC Systemdocshare04.docshare.tips/files/25054/250545123.pdf · A...