1. SAP An Introduction
October 2012

2. Personal Introductions
Marc Trevino, PwC Senior Associate
6 years with PwC
6 years working with SAP clients
6 years of ISACA membership
CISA, CPA, CIA
Michael Baker, PwC Senior Associate
2 years with PwC
2 years working with SAP clients
CPA
Currently pursuing CISA

3. Agenda What We Will Do… Provide a high level overview of what SAP is
SAP Authorization Concept
Provide an introduction to Auditing ITGC’s in SAP
Segregation of Duties in SAP

4. What is SAP?
Talk through the agenda and sessions at a high level.

5. What does SAP stand for?
Systeme, Anwendungen, Produkte in der Datenverarbeitung
Systems,
Applications and
Products in Data Processing

6. What is SAP?
An order in SAP can automatically generate an inventory movement and a posting in the GL without any “human” intervention.
SAP can track financial results, procurement, sales, manufacturing, human resources and payroll.
SAP integrates all business processing through one application.
Links operational results and the financial aspects of those results.
SAP comprises of modules in finance, logistics and HR.
One or more SAP modules can be implemented.
SAP is typically accessible by the entire business organisation.
Most company information and transactions originate from SAP.
Integrated
Multifunctional
Modular
Enterprise Wide
“Real Time”
Real time – There is batch processing as well… but then it is mainly for interface of data.

7. Overview of an SAP Environment
Business process
Controls
(incl. automated,
manual, BPR)
IT General
Management reporting
and end-user controls
SAP configurable controls
SAP Authorisations/User profiles
SAP Basis Module
Database
Operating System and other Infrastructure controls
Infrastructure
Layer
Application Layer
Presentation Layer
On this slide, start bottom up from ITGC.
> Link OS and DB to data centres and infrastructure
> Refer SAP Authorisation to Segregation of Duties. Further mention that SAP Authorisation is split because
- SOD is within business (create and approve PO) and IT process (making and transporting the changes)
- sign off is done by business and execution is done by IT
> Basis = technical system settings. Distinguish it from configuration controls. Mention that Basis would be covered in detail later
> End user controls = manual controls
The most important message on this slide is that all the layers are inter-related. We need to get comfort from bottom to top across all the elements.
A good starting point when understanding what an SAP system looks like is to break it down into some basic components. By doing this you will be able to better structure what could be areas of audit focus.
If we look at the triangle, the lower elements are what would typically be considered to be the underlying IT control environment, the bedrock if you like that ensures the integrity of the overall SAP system. Unlike many business IT systems SAP has a core module referred to as ‘BASIS’ that sits at the centre of this control environment. We will cover this module in more detail later but at this point it is worth noting that it is the key to ensuring that user access and the way the system has been set up to operate is maintained in a controlled manner. The SAP Basis module also underpins the overall application’s interaction with the Operating system (for example UNIX) on which SAP resides and with the database (for example Oracle).
The diagram shows the SAP authorization layer spanning the IT control environment layer and the Business process layer. This represents a key message and links to one of the key audit challenges that we spoke of earlier. As an integrated system, access to all functionality within the application, from support functions used by application administrators to access to review a report is controlled by the application.
The business process control layers that sit within the upper end of this triangle will typically sit within the modules And the way in which they are customized and configured discussed earlier in this session. As an integrated solution, an SAP business process will often make use of a mix of user access, configuration, and reporting functionality.
A good example of the sort of thing that we are talking about here would be where part of a process has been turned into a workflow; in this case, the SAP application may be configured to require a user to key in certain key information into say, an order that being routed to an approver (defined by access profile) before the system will automatically process the order to the next stage. An exception report could be set up to identify any transactions that are not authorized in a timely manner.
Now, for that workflow to be effective, adequate control must exist to ensure that the configuration is not changed inappropriately, that the approver is the correct individual and that the report contains all the transactions it should. We will come back to some of the key considerations around the IT control environment later in the course.

8. SAP Instances PR1 SAP R/3 or ECC 6.0 PH1 SAP Human Resources PC3
PE1
PA1
SAP R/3 or ECC 6.0
APO Planning
SAP Human Resources
SAP Customer Relationship Management
SAP Procurement
PS1
Solution Manager
PB1
Business Warehouse
Real time – There is batch processing as well… but then it is mainly for interface of data.
PH1 – the key thing to note here is this is where employees view the workbench that includes benefit information etc. Managers will view the manager workbench here. They do this through the net weaver portal (manager workbench)
PC3 – has to do with Customers and rebates
PA1 – has to do with Budgeting and forecasting (Sheri Bassett Preston) look into PA1 for forecasting and budgeting
PS1 – this is where the rev track system sits, change management and global production planning

9. SAP Authorization Concept
Talk through the agenda and sessions at a high level.

10. Overview What is the SAP authorization concept?
Security within SAP is achieved through the authorization concept
The authorization is designed to ensure :
Maximum security
Sufficient privileges for end users to fulfil their job duties
Powerful user maintenance
Security strategy between business and IT: Lack of efficient communication between business and IT, which leads to gaps between business requirements and actual security implementation
SAP security is inherently complex and is often seen as one of the most cumbersome and time-consuming parts of an SAP implementation. Our experience shows that, unfortunately, during an SAP implementation, the importance of logical access security is usually underestimated.
Security strategy should support the implementation of a security model that supports the business, reduce financial risks to the organization and provides flexibility for change. As business requirements provide the basis for the design and implementation of a sound security model, it is important that business and IT are tightly integrated. An inefficient security design will lead to users with too many authorizations and increased exposure to risk.
In short, the security strategy provides a roadmap for the design and implementation of a sustainable process for managing security of your SAP environment. Security strategy and design will be discussed in detail tomorrow, as part of the “SAP Security Administration” training class.
Most restrictive: roles/profiles are designed with a minimum set of permissions
Least restrictive: roles/profiles are designed with a wide range of permissions

11. Overview Three levels of security in SAP
User master record
User requires valid user-ID and password
T-code check
User requires an authorization for transactions 1 2 3
User logs onto SAP
User authorizations loaded into the user buffer
User executes the transaction directly or via the menu tree
SAP checks if the transaction exists (all transactions have an entry in table TSTC)
SAP checks if the transaction is locked (transactions are locked via transaction SM01)
SAP verifies access to the transaction code in the user buffer (checks S_TCODE)
Authorizations required read from ABAP program. SAP verifies that authorizations are available in the user buffer (checks additional authorization objects)
If any of the above verifications fail – Access is denied
Table TSTC links transaction codes to SAP programs
Transactions in TSTC can be locked to prevent use by all users (using T-Code SM01)
Customised transactions can be developed (using T-Code SE93)
- New transactions should follow SAP naming convention (e.g. prefixed with a ‘Z’)
The same SAP program can be used by multiple transactions using different sets of parameters
Authority check
User requires an authorization for underlying authorization objects and field values

12. SAP Authorization Concept The components
SAP User Master Record (UMR)
Master data for SAP users
Transaction Code (t-code)
Provides access to specific functions within SAP
ME21 – Create
Purchase Order
Authorization Object:
Template for security that contains fields with blank values (uncut key)
Can we ensure they talk about the risk of “inheritance” when discussing the auth concept?
Transaction codes provide access to a specific function within SAP, for example create purchase orders. Transaction codes are derived from the German language (since SAP is a German application). Most transactions related to Finance start with an “F”, Materials Management start with an “M” and Sales & Distribution start with a “V”.
Authorization Object
An authorization object is a template for security and controls what a user can do related to a particular transaction code. Defines what activities (e.g., create, change, display), document types (e.g., debit memo, vendor documents, customer documents) or organization components (e.g., plant, company code, credit control area) a user can access. Examples:
S_TABU_DIS – controls what activities a user can perform (display, change) on which table groups (security tables, finance tables, etc.)
S_PROGRAM – controls which activities a user can perform (run programs, schedule in background, change variants) for which types of programs.
V_VBAK_AAT – controls which activities a user can perform (create, change, display, delete, release) for which document types (sales order, debit memo, rebate, etc)
Authorization
An authorization determines exactly what a user can do related to a particular transaction code.
Authorization (Field Values):
Authorization object with completed fields (cut key)

13. SAP Authorization Concept The components
Profiles
“Key ring” that contains authorizations (cut keys)
Authority Check
Performed by SAP to ensure that a user ID has the correct authorization object and field value combination (cut key) to execute a particular task
Roles
Collection of transaction codes, authorizations and user assignments
R: Display PO
R: Create PO
Buyer
Role: bucket containing t-codes, authorization data (authorization objects and field values) and user assignments. Technically, the role is a grouping of the authorizations required to perform specific abilities (e.g., A/P payments, rebate processing, contract display)
Composite Role: logical grouping of two or more single roles that includes all system related activities an individual requires to perform their job function, such as Customer Support Specialist or Accounts Receivable Manager. For IT support roles, examples include Basis Administrator, Security Administrator, Developer, etc. Most users will be assigned to one composite role. Examples:
Cash Applications Manager
Customer/Contract Analyst
Basis Admin
Authority checks: An authority check is performed when users try to process a transaction. The initial authority-check is when users enter a transaction code, which may be requested directly or by menu tree. SAP then verifies access to the transaction code in user master record (UMR).
This process is performed by SAP to ensure that a user ID has the correct authorization. Authority checks are normally written into the program (ABAP code behind the transaction). There may be multiple authority checks in one program; there is typically one at the start of the program as well as throughout the program when entering data/processing.

14. SAP Authorization Concept Bringing it all together
Let’s make an analogy…
… the Lock and the Key
To open the lock, you need the right key!

15. SAP Authorization Concept Bringing it all together
Profile
SAP Security Check
Authorizations
User Master Record
R: Display Purchasing document
R: Create Purchase Order (e.g., ME21)
Buyer

16. Auditing ITGC’s in SAP
Talk through the agenda and sessions at a high level.

17. Risk based approach in a SAP environment
SAP is not a typical application / environment split
Many traditional environment functions are provided within the application including:
development environment
change control
system administration and job scheduling
These functions are collectively known as SAP Basis
Combined with SAP integration, this serves to complicate access security

18. Risk based approach in a SAP environment
SAP allows more comprehensive functionality and control, however, the following needs to be considered:
Financial transactions are executed throughout the business making segregation of duties control key
The SAP access mechanism is complex making security and segregation of duties a key risk
Configuration has a large impact to the overall business process and controls

19. Key IT General Control Domains
Consider tests for controls around:
Access to programs and data
Changes made to the system (Change management)
Computer operations
Weaknesses identified within the IT general controls can potentially undermine confirmed and tested automated controls and access controls at the business process level

20. Key Areas within the SAP environment Access to Programs and Data
Key areas to consider include:
SAP system settings including password parameters
Access to user administration functions including defining and assigning profiles to users (Profile Generator)
Access to run programs/ transaction codes
Assignment of SAP_ALL, SAP_NEW, other sensitive profiles
Default passwords of SAP supplied accounts (SAP*, DDIC, Earlywatch, SAPCPIC etc.)
Management and review of User IDs and generic User IDs
Use of audit logs (SAP Table Logging)

21. Key Areas within the SAP environment Change Management
Key areas to consider include:
Customised programs and tables should be assigned to appropriate authorisation groups.
Ability to unlock production environment to make direct changes to production is restricted and monitored
Segregation of duties within the change management process including developer, customizer and approver of the program change/transport
Changes to SAP tables and data dictionary in the production environment is minimized

22. Key Areas within the SAP environment Computer Operations
Key areas to consider include:
Batch jobs and interface processing should be regularly monitored, with access to amend them restricted
Batch jobs run under ANOTHER user should be restricted to appropriate personnel
Batch jobs run under ANY user should be completely restricted
Operating and database system administrator access should be restricted

23. Auditing SAP Segregation of Duties Example
Talk through the agenda and sessions at a high level.

24. SOD – Framework – Overview
Date
SOD – Framework – Overview

25. SOD – Framework – SOD/SA Rule
Date
SOD – Framework – SOD/SA Rule

26. SOD – Framework – SOD Rule
Date
SOD – Framework – SOD Rule

27. SOD – Framework – SOD Rule
Date
SOD – Framework – SOD Rule

28. SOD – Framework – Object Level

29. SOD – Framework – Object Level

30. Relationships Between Layers

31. SAP SOD Example Ability A Ability B Create Maintain Purchase Order
t-code: ME21
Auth Object: M_BEST_BSA
ACTVT: 01
Create Maintain Vendor Master Records
t-code: FK01
Auth Object: F_LFA1_APP

32. Questions?
False
© 2012 PricewaterhouseCoopers LLP. All rights reserved. In this document, “PwC” refers to PricewaterhouseCoopers LLP, which is a member firm of PricewaterhouseCoopers International Limited, each member firm of which is a separate legal entity.