2009/2028 15:49 study viewer Designing SAP Application Security — . Leveraging SAP Access Monitoring Solutions During SAP Implementations, Upgrades or Security Redesign Projects protiviti hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap ane2010972028 15:49 study viewer Introduction DEFINING SAP SECURITY REQUIREMENTS IN THE FARLY PHASE OF AN SAP IMPLEMENTATION, UPGRADE (OR RE-IMPLEMENTATION PROJECT SLATE? WITH REGARD ‘TO MITIGATION OF SECURITY RISKS PRIOR TO GO-LIVE." CAN HELP ENSURE EFFICIENCY AND ACHIEVEM 1 OF A‘CLEAN The results of a poorly executed SAP security design process are many: unauthorized access, increased potential for fraud, inefficient access provisioning for end users, and numerous audit issues. All too frequently, companies that have not proactively identified and addressed potential security issues face expensive and challenging redesign projects within one to two years of the initial SAP rollout. This also applies to organizations that have integrated systems due to mergers or acquisitions or otherwise performed SAP integrations without an overall SAP security strategy. The pitfalls of a bad security design not only include frequent projects to mitigate security exposures, but also loss of productivity due to delays in granting access ‘There are two main approaches when building application security in SAP. The first approach is the “top-down” or “proactive” approach described in detail in this white paper. It starts by defining security requirements up front during the blueprint phase. The second approach, the “bottom-up” or “reactive” approach, starts with developing SAP roles based on available transactions and job functions and considering security requirements and restrictions as a subsequent step, after roles have been set up in the system. Organizations that use the second method, the bottom-up approach, do not address security risks or compliance requirements during the initial design of their SAP systems. Instead, they assess security risks and requirements after roles have been built and access has been granted to users, or after go-live. This approach is commonly used by companies implementing SAP for the first time. However, while this method appears time-efficient in the shorter term, it ultimately may prove more time-consuming because security design has to be re-evaluated ~ and very likely rebuilt over time due to excessive access and a large number of segregation of duty (SoD) conflicts. ‘The bottom-up approach is also particularly inefficient when a high number of SoD conflicts must be resolved or SAP roles need to be changed to comply with financial regulations and audit requirements. In addition, this method runs the risk ofallowing-a high and unnecessary number of SAP roles to be built (.c., new roles may be created to solve existing SoD conflicts, which often fails to address the root causes for SoD conflicts). PROTIVI = Designing SAP Application Security | 1 hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap ane2010972028 15:49 study viewer Defining SAP security requirements in the early phase of an SAP implementation, upgrade or re implementation project (*SAP project”) can help ensure efficiency and achievement of a “clean slate” with regard to mitigation of security risks prior to go-live. Iris also important to leverage access management tech- nology, such as SAP Access Control or similar solutions, to monitor whether sccurity design requirements and SoD restrictions are properly maintained throughout the system build, deployment and go-live phases. Top-Down ore or Proactive [AGoeEt Approach = inal SAP Project Phases Cet Bottom-Up or Reactive Approach Repel steps uni Figure 1: Approaches to Building SAP Application Security PROTIVT * Designing SAP Application Security | 2 hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap ane2010972028 15:49 study viewer TOP-DOWN APPROACH FOR SAP SECURITY DESIGN 1, Define SoD Policies and Rule Design ‘The first step in implementing SAP application security using the top-down approach is to work with business process owners (BPOs), SAP functional leads, and compliance organizations to identify business processes and applications in-scope of the SAP project and determine how the different SAP modules (c.g., Financials and Controlling, Materials Management) and SAP applications (e.g., Supply Chain Management, Human Capital Management) would be utilized for each business process. A series of meetings and validation workshops should be conducted to establish an agreed-upon and written SoD management framework, including SoD policies with respective risk descriptions, risk ratings, and compliance and audit requirements. Systems, modules, oF applications where ‘SAP Accounts Payable Module, Supply information related tothe isis entered or Relationship Management (SRM) Application, et, processed Defintion of erat riskthat drives the Soo rule | Faud AES Comite itera or Baral and security contls Soutes, Intentional & Concealed, Causing Loss of Funds, Value, Reputation or Unauthorized Benefit Definition of what a user could do ifalowed cenain acess inte SAP system Job functions that represent or increase risk if ‘nccess to Create or Change Transactions for provides to 4 user without proper monitoring Procure to Pay and Master Data Maintenance Post Payments, et. ‘SAP transactions and respective authorization ‘change Vendor Master. 102) vs, Execite jects related 0 the conflicting job Functions Payment Run (F110) Figure 2: Key Components of an SoD Management Framework PROTIVT + Designing SAP Application Security | 3 hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap ane2010972028 15:49 study viewer AAs part of this framework definition process, SoD policies should be outlined and classified into risk levels such as critical, high, medium, and low risk, as described in the example below. This will help management prioritize areas of focus during role build or security remediation phases: + Critical risk: ~ Represents significant impact to company operations or company value — Risk cannot be mitigated, it requires remediation + High risk: — Represents a direct financial misstatement risk or significant profit and loss (PSL) impact ~ Affeets corporate image — Represents a deviation on standard best-practice processes or noncompliance with laws and regulations = Generates i wconsistencies on master data governance or transactional data — Causes loss or theft ~ May be mitigated with an effeetive management-level report, or may require remediation + Medium risk: — Causes a financial statement reclassification risk — Represents medium PSL impact (c.g., percent of revenue, materiality, potential loss) — Disrupts an operational process (no impact to financial statements) ~ Causes noncompliance with internal policies ~ Can be mitigated with a management-level report * Low risk: — Costs more to mitigate than the cost of the risk to the business ‘These definitions vary from company to company based on the organization and industry-specific criteria. After these SoD policies and risks are defined, SAP standard and custom transactions should be evaluated to identify those that provide the ability to create, modify, post or delete data related to any of the identified risks. Ultimately, these SAP transactions are grouped into job funetions (e.., Create a GL. Account, Post Payments) and should be configured in an automated SAP security monitoring solution (such as SAP Access Control or a similar solution) as “rule sets," which are used to analyze SoD conflicts at the role or user level In addition to SoD policies and risk definitions, companies also should define, group and classify sensitive SAP_ ‘transactions to enable monitoring and reporting on SAP roles and users who have add, modify or even display access to the company’s sensitive information, such as vendor pricing lists, customer lists bills of materials (BOMs), sensitive SAP tables, financial data, and human resources (HR) information. "Mest SAP Accuss Management solutions include a sandard/predofined soc of SoD rules; however, dese rules, along with the risk ranking (critical, high, medium, lw), need tobe adjusted to tele the company's sk profile Instn, fis important wo nots that ‘hose standard rulesets may repre on false pesivs if the security parameters (Le. authorzaion objects) are not adjusted vo relect the ‘company’ sour design. PROTIVT * Designing SAP Application Security | 4 hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap sit22010972028 15:49 study viewer 2, Initial Role and User Design ‘The next step after establishing the SoD policies and rule sets in SAP Access Control, or asi includes the initial design of SAP roles. This step starts hy reviewing “to-be” business processes and conducting preliminary analysis of individual tasks and SAP transactions that will be performed once the new system goes live. At this point, the SAP application security team will group transactions into the beginning stages Of SAP roles. This step could be challenging without predefined role templates due to the lack of available documentation to perform the role design related to transaction functionality. Another approach for defining the set of SAP transactions to include in the updated SAP roles isto review the SAP transaction history. This method is applicable to SAP upgrade or security redesign projects only, since no transactional history will be available for new SAP implementations. In this approach, transaction logs are analyzed to determine the set of monthly, quarterly and year-end transaetions that should be included in the newly designed SAP roles. ‘The next step after the initial transaction grouping isto conduet workshops with BPOs to validate that the respective SAP transaction groups arc aligned with the “to-be” business processes in case of new SAP tations or existing business processcs in case of security redesign projects. At this stage, the “role templates” will be documented. These consist of the role’ technical name and the underlining transaction codes. ‘They also may include key information related to security restrictions, such as company codes, cast centers oF may vary over the course of the SAP project, as “to-be” processes are ny TWansaction Code Description rats Display Customer tne tems rot Create siling Document vroz Chang Bling Document siting Rote eae roa Maincain Biting Due List ven Cancel iling Document vet output rom Biting Documents 1038 Dalvery Related on he Biling Due ‘vo. Create Customer Sales) Sores ‘yoo? Change Customer (Sas) cence ‘yo0s Display Customer (Sales) ‘voos ‘customer changes (0) - voz Change ailing Document Ee vas Release Sales Orde for Biting Figure 3: Example of an SAP Role Template PROTIVT * Designing SAP Application Security | 5 hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap ene2010972028 15:49 study viewer ‘The next key step within the role and user design phase is to define “role owners” for each role template. Role owners are typically part ofthe functional implementation, or business teams, and usually “own” or are responsible for managing and reporting on the data being updated by the SAP transactions and roles they own. For instance, a corporate controller would own finance-related roles. Responsibilities for role owners include review and approval of SAP transaetions to be included in the role and ongoing maintenance of the role (eg. transaction additions, deletions, and approval of mitigating controls if conflicts occur). ‘SAP Security Design Considerations ‘Job-based” vs. “task-based” roles “The fist key decision to make during the actual design of SAP sccurity is whether to use “job-based” or task-basod” roles. The intention of job-based roles is to give cach user one role (ex, Aecounts Payable Manager) that encompasses all ofthat person’ job aetvitis."This approach utilizes fewer roles, bu also gives users acces to transaction eodes they might not need. Also, the roles themselves may have SoD) conflicts due tothe lange number of transactions assign “The intention of task-hased roles isto give cach user multiple role, each representing one job task (a, Release Parchase Requisition)This approach utilizes more roles, but wil limit user access tothe respective tasks performed “The decision around using a job-hased or tak-hased approach will depend on the overall consistency of job positions, and the maturity of HR departments in relation to the integration between SAP access requests and employee hiring, transfer, and termination processes ‘Single vs. composite roles Another decision to make is whether to use composite roles, which area grouping of roles held within another roe. is common for jab-based roles to consist of several task-hased roles (composite roles). The main advantage in ‘composite roles is that they provide a simpler user provisioning process since the user will receive one role. The main disadvantage of composite roles is that users may be granted more access than required due to additional asks oF backup responsibilities heing included in the composite role, Custom or pre-delivered SAP roles Irie also imporeant ro note that cach SAD system comes pre-delivered with out-of-the-box roles, and an organization can decide to implement those instead of tailoring their security design. However, it is not recommended that out-of the-box roles be used as a long-term strategy to maimain SAP security. These roles are designed 2s one-size-fit=-all roles, meaning they have sich a wide range of jab activities combined ina single role that it will be neatly impossible to provision these roles to a user without granting excessive access. Also, out-of-the-box roles may not mec all Fbusiness access requirements and control restrictions. HR or position-based design vs. functional design Another consideration when designing SAP sccurity is the level of integration with HR processes (chi al bral consseare) erat desea ponioas Iwan mee GAD lar cel ate lites, tif HR departments and positions are nor mature or consistent, an independent security design based purely on jab functions may be the best option. For organizations to apply a position-based design, HR jab descriptions would have to he well-defined and consistent across the company. Abo, “hire-to-retire” processes would anced to be in a mature stage to enable integrated provisioning. PROTIVT = Designing SAP Application Security | 6 hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap m22010972028 15:49 study viewer 3, Role Build and User Assignment Once the initial SAP role templates have been designed and approved, the roles can be built in SAP and subsequently assigned to end users. The technical design phase starts with building “master roles” or “template roles” including the grouped transactions. Building master roles requires close coordination with the systems integrator and BPOs so that all standard and custom SAP transactions and objects being used as part of the role design are understood in terms of functionality (e.g, create master data, update financial statements) and are also properly incorporated in the template roles. The second step in designing SAP roles is to create “derived” or “child” roles, which is where security restrictions are applied (e.g., company code and cost center limitations). Designing roles that are frce from SoD conflicts early in the SAP project can lead to increased granularity and more restrictive access as well as inereasedtransparcney related tothe authorizations given to a user. In addition, it ean reduce ongoing security maintenance because it makes it easier to respond to changes in user responsibilities resulting from the implementation of new SAP functionality and/or organizational realignment. 1d user role assignment is a critical step when designing SAP application security, due to the different restrictions that must be applied to uscrs (ex. some users may need access to one, multiple or all company codes or cost centers, in case of shared services departments), During these steps, itis also important to leverage SAP Access Control, or another SAP security monitoring solution, to confirm that roles are So1)-conflict-free before assigning them to end users. If master roles have inherent SoD conflicts, all derived roles and subsequently assigned users also will have conflicts. Design ‘SAP Master Roles, rm co Peed Business Unit “3 ro ‘Company Code ‘Company Code Assessment SAP Derived Roles sid Peed eed (Cost Coners Sr Figure 4: SAP Role Build and User Assignment Process PROTIVT + Designing SAP Application Security | 7 hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap ene2010972028 15:49 study viewer 4, Role and User Access Risk Analysis At this stage, SAP Access Control, or another SAP security monitoring solution, should be leveraged to perform periodic role and user analyses to determine if the newly designed SAP roles are in compliance with SoD policies. This is done by simulating and monitoring changes affecting SAP security design, and providing timely feedback to BPOs in case potential conflicts arise. Risk analyses should be run ona periodic basis, especially after unit and integration testing, which is when the SAP system design will be updated to accommodate process improvements, Its important to note that the defined SAP rule set in SAP ‘Access Control also may change during the course of the SAP project, given that new SAP transactions may be added to “to-be” processes or new custom transactions may be developed. ‘To ensure an SAP environment is “clean” or “conflict-frec” post-go-live, a sound SAP security provisioning process must be designed and implemented. This includes procedures that require SAP security teams to perform a risk simulation in SAP Access Control prior to geanting user access or modifying a role. ‘This simulation will determine if role or user changes are posing SoD) or excessive access security risks. In addition, continuous monitoring procedures must be established and followed as the project go-live date approaches. Detective SAP security monitoring processes also should be established, including generating periodic SoD) violation reports reviewed by POs and role owners to validate security changes. For SAP upgrade or security redesign projects, post-go-live activities may also include additional change ‘management processes to assign and manage new roles and, over time, to discontinue the use of legacy roles. 5, Security Testing and Go-Live Preparation SAP security Unit Testing (UT) and User Acceptance’ Testing (UAT) are critical steps to ensure users experience ‘minimal access issues prior to go-live. SAP security testing includes executing all SAP transactions within role to confirm that the role has required transactions and authorization objects to complete the process (€-$ display, update and post a financial transaction). These steps should be performed in conjunetion with project functional testing (during SAP implementations or upgrades) or before assigning the new roles in the production environment (during security redesign projects). Security testing also should include formal SoD and sensitive access reviews to confirm the newly created or updated SAP roles are as SoD conflict-free as possible, and that aceess to key functions (e.g, update vendor master, update chart of accounts) is properly restricted Involving SAP security teams in early stages of the functional testing phase allows the discovery of potential security issues before itis too late — or costly — to modify roles, It is also very important for the final UAT. process to create test users in the Quality Assurance environment with the SAP roles to be used in the production environment (ic. users with accurate SAP role assignments). This will allow proper identification and remediation of security changes, including verification of “authorized conflicts” and resolution of “unauthorized conflicts” prior to going live with the SAP project. Be sure to work closely with BPOs, role owners and the SAP security team to remediate unauthorized conflicts by regrouping the transaction codes within the conflicting role(s) or reassigning the roles for the conflicting user. For SoD conflicts that cannot be resolved for a business-approved reason, such as limited headcount, mitigating controls should be identified and documented. PROTIVT = Designing SAP Application Secuty | @ hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap ane2010972028 15:49 study viewer 6, Move to Production and Support Once testing is complete, the newly designed SAP roles can be migrated to the production environment ac- cording to the organization's change management policy and users can be assigned. No matter how well UT and UAT are performed, itis very likely that access issues will be encountered during go-live stabilization, and the post-go-live period due to the overall complexity of implementing or changing ERP systems and processes in an organization. It is critical to establish a support team specifically assigned to address any SAP access issues during go-live and stabilization activities. This team not only can help resolve access issues on a timely basis, but also run access risk reports to determine if security changes will result in SoD or other access rsks. Also, a communication plan should be established to ensure affected users are aware of any changes and support protocols related to go-live of the SAP system, ‘Acommon practice during SAP implementation and upgrade projects isto allow for temporary broader access for*power users” during the go-live and stabilization period. ‘This is done to help with stabilization of the new system, to ensure users are capable of performing job functions during and aftcr go-live, and often is performed using SAP Access Control to review transaction and super-user action logs. [tis important to review and remove this temporary broader access after the new implementation is stable. Tris recommended to leverage SAP provisioning solutions to automate user provisioning processes. For instance, SAP Access Control can enable “paperless” SAP security provisioning by automating the assignment and approval of roles. User provisioning and approvals can be accomplished through a few clicks on a webpage. ‘fan issue is detected during the user assignment process, the approval path is automatically redirceted so the appropriate role owner can resolve the SoD conflict before access is granted. CONCLUSION Designing, configuring and implementing SAP security is a complex and resource-intensive endeavor. Com- panies should consider their approach to building SAP Application Security in the early stages of SAP proj- cets, Embedding proper security requirements during the system build process helps to avoid the need for a redesign later. Using automated security monitoring solutions such as SAP Access Control and applying best practices can increase efficiency and acceleration of the security design and the implementation of eonflict-free SAP roles, and dramatically reduce the possibility of having to redesign SAP security in the future. Organizations that mect any of the following criteria should consider assessing their SAP security design and the implementation or optimization of SAP security monitoring solutions in order to “clean” and “maintain” their SAP security environment: * Organization-specific SoD policies have not been defined, approved by the business, or are outdated * Creation of new roles and/or new role assignments gencrates new SoD contficts requiring remediation ormitigation| * A significant number of SoD conflicts exist within roles * The SAP environment consists of more roles than users * SoD checks are performed manually * Automated security monitoring solutions, such as SAP Access Control, are not in place to support provisioning processes or ongoing monitoring of the environment * Lack of business involvement in the SoD risk management process PROTIVT = Designing SAP Application Security | 9 hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap s0n122010972028 15:49 ABOUT PROTIVITI study viewer Protiviti (www.protivitizcom) isa global consulting firm that helps companies solve problems in finance, ‘technology, operations, governance, risk and internal audit, and has served more than 35 percent of FORTUNE. 1000” and FORTUNE Global 500” companies. Protiviti and its independently owned Member Firms serve clients through a network of more than 70 locations in over 20 countries. The firm also works with smaller, growing companics, including those looking to go public, as well as with government agencies. Protiviti is a wholly owned subsidiary of Robert Half (NYSE: RHD. member of the S&P 500 index. ‘ounded in 1948, Robert Half isa ‘About Protiviti’s SAP Application Security and Segregation of Duties Practice Protivitis Application Security and Segregation of Duties professionals provide SAP Access Control and SAP Security guidance and implementation support to ensure organizations better understand and manage risks around their enterprise resource planning (ERP) and supporting systems. Our consultants help companies identify and effectively manage security and application access risks across the organization’s enterprise architecture. Contacts John Harrison $1.713.314.4996 john harrison@protiviti.com Ronan O'Shea +1,650.678.0260 ronan.oshea@protiviti.com Avie Quinones, +1 404.240.8376 atic quinones@prot John Livingood “+1.415.402.3682 john livingood@protiviti.com Carol Raimo +1.212.603.8371 carol.aimo@protiviti.com PROTIVIT Designing SAP Application Secusity hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap 10 wine2010972028 15:49 ‘THE AMERICAS UNITED STATES Alexandria Kansas City Salt Lake City ‘Aanta Los Angeles San Francisco Baltimore Milwaukee San Jose Boston Minneapolis Seattle Charlorte New York Stamford Orlando St Louis Philadelphia “Tampa Phoenix Washington, D.C Pittsburgh Winchester Portland Woodridge Fort Lauderdale Richmond Houston rrament ARGENTINA® come eeu Buenos Aires Santiago Lima saZit* mexico* VENEZUELA* RiodeJanciro Mexico City Caracas Sio Paulo Monterrey CANADA Kirchener- Waterloo “Toronto ASIA-PACIFIC AUSTRALIA INDIA SINGAPORE Brisane Bangalore Singapore Canberra Maras Melbourne New Debi ‘SOUTH KOREA Perth Seoul Sydney INDONESIA™ Jakarta cuINa Beijing saPAN Hong Kong Osa Shanghai Takyo Shenhen protiviti: study viewer EUROPE/MIDDLE EAST/AFRICA FRANCE ay ‘THE NETHERLANDS Paris Milan Amsterdam Rome GERMANY Torin UNITED KINGDOM. Frankfurt London Munich BAHRAIN® ‘aTaR* ‘Manama Doha Kuwarr* UNITED ARAB EMIRATES* Kuwait City Aba Dhabi Dubai oman* Muscat SOUTH AFRICA Johannesburg © 2014 Prot inc An Equa Opponunty Employer W/O). PRO.0314. 203050 Pros not eonsed reine as 3 pubic accounng hm and does not Iss opinions on fran stamens or oe areseon sees, hitpsstuaylib.nefsoct8215614/designing-sap-applicaton-secunty—leveraging-sap vane