The purpose of security is to protect an organization’s data and information by restricting access to authorized individuals based on the need-to-know principle. Therefore, carefully determining the business transactions that users can access, view, or execute based on their job functions is critical when designing security roles within an SAP solution. This reduces the risk of unauthorized transaction execution, fraud, and collusion. Other considerations include ensuring that appropriate controls are in place to address business process risks. These risks can be mitigated through a number of controls including proper security within SAP and, where appropriate, through third-party applications that interface with SAP to enable processes. Orchestrating these aspects of security management increasingly requires specialized resources.
Don’t leave it to chance
There is a need for creating a control framework that contemplates how key business risks are being addressed in the context of an SAP implementation including SAP R/3, SAP Business Information Warehouse (SAP BW), SAP Strategic Enterprise Management (SAP SEM), SAP NetWeaver Portal, mySAP Customer Relationship Management (mySAP CRM) or mySAP Supplier Relationship Management (mySAP SRM). A comprehensive information security and controls design and its implementation is a vital component of this control framework. SAP Security Implementation is not something that will simply “work itself out” as the project progresses. Instead, it requires a dedicated team with specialized skills to develop and deliver a customized security and controls solution that meets the organization’s information integrity requirements and that is compliant with Sarbanes-Oxley Act, Health Insurance Portability and Accountability Act (HIPAA), and various other legislations.
Project Management – meeting stakeholders’ expectations
Effective project management in relation to security and controls begins by placing yourself in the stakeholders’ shoes. The security lead must thoroughly understand what the stakeholders deem to be important as it relates to SAP security and controls. One of the best ways to reach this understanding is to interview key stakeholders in the context of internal business process controls to determine, for example, what the organization is trying to achieve in relation to safeguarding information. The security team needs to ensure that the security strategy and approach accounts for the changes to the current IT and business landscape. Furthermore, the security and controls team need to communicate and cooperate closely with the business process implementation team.
Many times, expectations will vary greatly among stakeholders as each will have differing priorities and an understanding of SAP security or lack thereof. Gaining insight into what business requirements they need and expect also helps the security and controls team to better determine the scope and complexity of the project. This in turn, assists in the estimation of effort of the security build process. Understanding business processes plays a key role in determining how user security will be designed because security will be the representation of business controls. For example, in order to prevent fraud, the business may decide that one user should not have the ability to create a purchase order, approve it, issue a goods receipt acknowledgement, and pay the invoice while also having access to maintaining the vendor master file. In order to implement this restriction in SAP, transaction – and if needed, field level security configuration needs to be performed in order to achieve this segregation of duty.
Of course, there are legitimate cases in which segregation may not always be achieved. The design should ensure that adequate compensating controls in order to mitigate the risks posed by allowing that segregation of duty conflict to exist. For example, one can implement a compensating control based on business risk, by having a certain threshold which, once reached or exceeded, will require approval from management before processing. The concept of segregation of duties is a key focus point for management and auditors alike in the context of regulatory compliance, especially the Sarbanes-Oxley Act.
Another key aspect of security project management is obtaining sponsorship and acceptance from business owners. This is important and differs from other project areas because security and business process controls are enablers of a sustainable and compliant business. Discussing the security strategy and approach with executive management and obtaining their approval for it is important for establishing acceptance, ownership, and accountability.
Technical Management – benefits from team work
Having the right technical specialists who not only understand the regulatory environment but also how controls within and related to SAP can aide compliance, is paramount. Nevertheless, most security departments, especially SAP Security teams, are usually understaffed as work efforts are usually underestimated. It is often helpful to involve internal audit and control teams during initial discussions about security strategy and design. In most cases, these teams have already conducted significant work documenting and testing controls throughout the organization.
When speaking with stakeholders regarding how SAP authorization works and the security options available to them, the security and controls team must confirm that they not only understand the consequences of proposed restrictions but also the risks of not restricting access and how it could affect the organization. In addition, an SAP Segregation of Duties (SoD) analysis should be conducted on the roles created. An SoD analysis helps to determine, analyze and catalogue the activities of users with access to sensitive areas, such as Basis, providing some level of confirmation that conflicting activities can be identified. Many SoD tools are now available to automate this process to help achieve efficiencies and reduce costs. Most SoD tools take a risk based approach to elevate and monitor risks. Depending upon the tool being used, administrators can run simulations on potential conflicts in seconds without making any configuration changes to security roles. Some tools have modules that assist in automating the role development and configuration process. Some tools also offer an SoD analysis to be conducted cross application – for example between SAP and Non-SAP applications. Most SAP-based SoD tools are provided by third-party vendors, but other proprietary tools, such as Deloitte’s eQSmart, can also be used to conduct SoD analysis.
Stakeholder Management – communication leads to success
Managing the stakeholders and, in particular, the business users is usually the most important and complex aspect of an effective SAP security implementation. If the security and controls team is unable to effectively communicate with the business teams, technical resources, and management, then they may not have acquired all the business requirements in order to translate this information into an appropriate security design and implementation. This may result in not delivering on time, not meeting expectations, and in a poorly designed security strategy.
Although beneficial for the organization as a whole, security restrictions are often seen as a hindrance by users as opposed to a helpful way to mitigate risks. Two causes may account for this perception. First, users are already undergoing changes due to redesign of business processes and consequently experience increasingly limited access to business functions in SAP, for example performing their job function. Secondly, users are initially not aware of SAP’s highly integrated process flows and their related complex security restrictions.
Get in the “trenches” immediately
One strategy that has been used effectively in correcting this misconception is to get in the “trenches” with the stakeholders immediately, probing to identify and address any concerns they may have upfront before their resistance has a chance to gain traction. For instance, an organization wants to have restrictions on certain HR master data, but technically HR security does not allow for this specific restriction without customization/modification.
It is important to be mindful of who the audience is and what their expectations are. Most people have not had much exposure to how security operates and how it is configured within SAP. This may cause end-users to be cautious in expressing concerns and issues because they do not want to seem unsure and most likely do not understand the risks involved. One suggestion for overcoming this barrier is to use everyday language and analogies to help people understand technical security concepts. Furthermore, it is often helpful to “keep the educator hat on” and to make it a part of the daily function. This approach can help reduce miscommunication and, ultimately, project delays.