SAP Security Concepts, Segregation Of Duties, Sensitive .

SAP Security Concepts,Segregation of Duties,Sensitive Access &Mitigating ControlsJonathan LevittMarch 2015

Agenda1. Introduction2. SAP Security Design Overview3. The SAP Authorization Concept4. Approaches to SAP Security5. Segregation of Duties & Sensitive Access6. Mitigating Controls7. QuestionsPwCMarch 20152

ObjectivesAt the end of the session, the participant will: Gain an understanding of the SAP security environment and why security is importantto the audit; Define and understand what a segregation of duties conflict in SAP is, and how tomonitor/address it; and Define and understand mitigating controls.PwCMarch 20153

SAP Security Design OverviewPwCMarch 20154

SAP Security Design OverviewIntroductionWhat is SAP Security Design?At its most fundamental level, SAP Security Design refers to the architectural structure ofSAP security roles. However, effective security design is achieved via the convergence ofrole architecture:1.SAP Security Organizational Structure & Governance- Ownership, Policies, and Accountability2.SAP Security Processes- User Provisioning, Role Change Management, Emergency Access3.Ongoing Management & Monitoring of the Security Environment- KPIs, Recertification, “Get Clean & Stay Clean”PwCMarch 20155

SAP Security Design OverviewIntroductionSecurity &ProvisioningProcessesOrgStructure &GovernanceSAP SecurityArchitectureMonitoringMEffective SAPSecurity DesignManagementPwCMarch 20156

SAP Security Design OverviewSAP Security Design Challenges User provisioning process withinsufficient automation &information Role Change Mgmt lacks risk andquality controls Inefficient emergency support processSecurity &ProvisioningProcessesOrgStructure &GovernanceSAP SecurityArchitecture Management KPIs for Security Designare not established Lack of automation for ongoingmonitoring & recertificationprocedures Insufficient SoD and/or Mitigatingcontrol frameworksM Misalignment of IT vs BusinessObjectives Lack of Strategic Security DesignDecisions No Role or Security DesignOwnership Overly Complex Security Design Lacks flexibility to respond toongoing changes Lacks scalability to grow withorganization Inefficient Role Build Approach No Documentation of SecurityMonitoringControl Points Inherent Segregation of DutiesRiskEffective SAPSecurity DesignManagementPwCMarch 20157

SAP Security Design OverviewAudit Issues & Complexity Poor security can lead to audit issues‒ When access controls are not in place, it impact the amount of reliance audit canplace on reports coming from SAP‒ Segregation of Duties is a key underlying principle of internal controls, and is theconcept of having more than one person required to complete a task. Security canhave a detrimental impact on this control (to be discussed in greater detail later inpresentation). It is sometimes difficult for auditors to dig deep into SAP because security is complex:‒ In SAP ERP 6.0o 108,000 transaction codeso 2,600 authorization objects‒ Several transaction codes can perform similar tasksPwCMarch 20158

The SAP Authorization ConceptPwCMarch 20159

The SAP Authorization ConceptIntroductionSecurity &ProvisioningProcessesOrgStructure &GovernanceSAP SecurityArchitectureMonitoringMEffective SAPSecurity DesignManagementPwCMarch 201510

The SAP Authorization ConceptIntroduction (continued)SAP SecurityArchitectureSecurity within the SAP application is achieved through theauthorization concept.The authorization concept is to help establish maximum security, sufficient privileges forend users to fulfil their job duties, and easy user maintenance.PwCMarch 201511

The SAP Authorization ConceptThree levels of security in SAPUser masterrecordUser requires validuser-ID and password1T-code checkUser requires anauthorization fortransactions2Authority checkUser requires anauthorization forunderlyingauthorization objectsand field valuesPwC3March 201512

The SAP Authorization ConceptThe ComponentsSAP User Master RecordMaster data for SAP usersProfilesContainer of authorizationsRolesContains transaction codes, authorizations(mapped to one profile) and user assignmentsAuthority CheckPerformed by SAP to help establish that a userhas the correct authorization to execute aparticular task.Authorization Object:Template for security that contains fields withblank valuesAuthorization (Field Values):Authorization object with completed fieldsPwCMarch 201513

The SAP Authorization ConceptBringing it togetherLet’s make an analogy the Lock and the KeyTo open the lock, the proper key must be cut specifically fora certain lockPwCMarch 201514

The SAP Authorization ConceptUser TypesSAP AuthorizationStructureUser UserRoleProfileAuthorizationPwCMarch 201515

The SAP Authorization ConceptAuthorization StructureSAP AuthorizationStructureUserRoleAuthorization is not the same astransaction. Why?ProfileAuthorizationIn SAP, you can perform the samefunction with different transactions.PwCMarch 201516

The SAP Authorization ConceptAuthorization Structure (continued)SAP AuthorizationStructureUserSAP Program AccessElements RoleSAP is delivered withabout 1500 authorizationobjectsAn object is a structureprovided by SAP to grantaccess to a data elementor a task in aspecific AuthorizationField ValuesAuthorizationObject FieldsMarch 201517

The SAP Authorization ConceptAuthorization Structure (continued)SAP AuthorizationStructureSAP AuthorizationStructureSAP Program AccessElementsUserRoleMenu ItemsUSOBT CUSOBX horizationObjectAuthorizationField ValuesAuthorizationObject FieldsMarch 201518

The SAP Authorization ConceptWhy are authorization objects required?In SAP, you can perform the same function with different transactions:Transaction CodeMK01FK01XK01Conventional approachprotection via menu/functionCreate VendorPwCSAP approach protectiononce via authorizationMarch 201519

The SAP Authorization ConceptThe Authority CheckTransaction Code check:ObjectS TCODEStart T CodeField 1TCDStart T CodeFB03Authorization check:PwCObjectF BKPF BUKDisplay postingField 1ACTVTDisplayField 2BUKRSCompany Code031000March 201520

Approaches to SAP SecurityPwCMarch 201521

SAP Security ApproachesTask Based vs. Job Based Security DesignJob Based: Security is built based on positions/jobs withinthe organization, such as AR credit associate. PwCTask Based: Provisioning access is based on jobresponsibilities.Security is built based on small, definable tasks,executed by the user, such as process cashreceipts. Smaller number of roles per user – increased riskfor granting functionality more than once.Larger number of roles per user – decreased riskof duplicate access. Transaction codes and authorizations typicallyduplicated in many roles.Transaction codes in one roles with minimalexceptions User assignment flexibility – simple to grantadditional access to only the tasks necessary. Supports future growth and sustainability – rolemodification decreased as a result offunctionality improvements and rollouts. Appropriate for dynamic organizations.Users may be granted more access than necessaryas a result of “additional job” or backupresponsibilities.Appropriate for static organizations.March 201522

SAP Security ApproachesJob Based Security Design Security roles are built based on positions/jobs for a group of users (e.g. AccountsPayable Clerk). A single role contains the access to perform a job. Transaction codes and authorizations typically duplicated in many roles.APSupervisorAPClerkAP ManagerPwCMarch 201523

SAP Security ApproachesTask Based Security DesignA task-based design begins by bucketing transactions into one of 4 access tiers: General, Display,Functional and Control Point. Task-based roles contain access to only one of these tiers.USER PROFILETIER 1: GENERAL ACCESSGeneral access is provisioned via one single rolemade up of tasks common to users such asprinting, inbox, SU53, etc.TIER 2: DISPLAY ACCESSDisplay access is provisioned via a set of rolesdefined by functional area that allow displayand reporting access intended to complimentthe functional roles of the users.WhatUser GeneralAR Common DisplayDisplayAPContract MaintenanceWherePwCFI Common DisplayProcess BillingOrganizationalGrouping - AVendor MasterMaintenanceOrganizationalGrouping - BTIER 3: FUNCTIONAL ACCESSFunctional access is provisioned via multiplesingle task based roles. Role grouping ofactivities that are the lowest commondenominator of tasks and permissioncomponents to suit the needs of the end-users.These groupings usually are SoD free and partof a sub-process such as Invoice Processing orMaterial Master Maintenance.TIER 4: CONTROL POINTSRoles that provide additional control pointaccess or granularity needed by Tiers 1-3 suchas Company Code, Plant, etc.March 201524

SAP Security ApproachesTask Based Security Design (continued) Security roles are built based on positions/jobs for a group of users (e.g. AccountsPayable Clerk). User assigned to the tasks needed to perform his/her job (not a job-based role) User receives multiple single roles Flexibility to each individual user’s role assignmentsAP ClerkUser GeneralPwCAP Common DisplayProcess BillingOrganizationalGrouping - AMarch 201525

Segregation of Duties & SensitiveAccessPwCMarch 201526

Segregation of Duties & Sensitive AccessIntroductionSegregation of DutiesSensitive or Critical AccessA segregation of duties risk is when acombination of abilities that whenassigned to a backend user constitutes arisk.A sensitive or critical access risk iswhere the direct assignment of anability to a backend user constitutes arisk.Objective of this risk is to facilitate theappropriate division of responsibilities.Objective of this risk is to help establishthat access is restricted to theappropriate individuals.PwCMarch 201527

Segregation of Duties & Sensitive AccessIntroduction (continued)Segregation of DutiesSensitive or Critical AccessExample risk:Example risk:Maintain Accounting Periods vs. PostAccounting Document in GLAllow a user to inappropriately openaccounting periods previously closedand fraudulently post documents tothat period after month end.PwCPost Accounting Document in GLShould be restricted to authorized usersto thereby decrease the risk offraudulent, malicious of erroneousjournal entries being posted.March 201528

Segregation of Duties & Sensitive AccessExamples Finance: Maintenance of accounting periods should be segregated from the posting offinancial transactions in the wrong period. Inventory: The receipt/maintenance of inventory should be segregated from orderand invoicing activities. Accounts Payable: Reconciling and releasing blocked vendor invoices should besegregated from daily processing and posting activities. Procurement: Maintenance of contracts and terms should be segregated frompayment and billing document changes.PwCMarch 201529

Segregation of Duties WalkthroughPwCMarch 201530

Segregation of Duties WalkthroughPwCMarch 201531

Segregation of Duties & Sensitive AccessHow to monitor? Companies have many different ways to monitor segregation of duties and sensitiveaccess:‒ SAP GRC Access Control‒ Other access control systems (Approva, ControlPannel, SecurityWeaver, ACL,etc.) or “homegrown” monitoring tools‒ Reporting transaction code “SUIM”.PwCMarch 201532

Mitigating ControlsPwCMarch 201533