SAP An Introduction October 2012

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

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

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

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

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 18-20 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.

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.

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

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

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

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

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)

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.

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!

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

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

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

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

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

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)

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

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

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

SOD – Framework – Overview Date SOD – Framework – Overview

SOD – Framework – SOD/SA Rule Date SOD – Framework – SOD/SA Rule

SOD – Framework – SOD Rule Date SOD – Framework – SOD Rule

SOD – Framework – SOD Rule Date SOD – Framework – SOD Rule

SOD – Framework – Object Level

SOD – Framework – Object Level

Relationships Between Layers

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

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.