In her blog post, “How to Survive an SAP Security Audit,” Tracy Levine, an SAP application consultant at itelligence, writes about three stages of an SAP security audit and uses political terms to describe them: state of the union, political reform, and ongoing legislation. Using her model, I asked Tracy to respond to a few questions related to preparing for an SAP audit.

In the first stage, the state of the union, an organization asks itself the following questions: “Where are we now? How did we get here? What challenges do we face?” Could you cite some examples of challenges organizations may face when preparing for an SAP security audit?

The primary concern when preparing for an SAP audit is gaining a clear understanding of client-specific security requirements and being able to articulate these requirements in terms of business processes. Oftentimes, SAP security requirements remain undocumented, what we refer to as “tribal knowledge,” as in there is no central repository that clearly defines the SAP landscape and tracks and monitors changes. As the SAP landscape matures, scalability efforts prove more difficult with increased requirements and a lack of correspondence between functional silos. Changes done by one functional team may override requirements that were purposely implemented for another, driven by a lack of visibility with regard to change management. Furthermore, clients may be concerned with underlying segregation of duties (SoD) violations and the need for a Sarbanes-Oxley (SOX)-compliant deployable role design.

In his video from GRC 2013, Steve Biskie refers to thinking about risk in terms of “what can go wrong.” He uses an example of “inadequate mapping of business processes to role design” as an example of something that can go wrong. Can you cite some other examples of what can go wrong in relation to managing the security of an SAP environment?

To piggyback on Steve Biskie, suboptimal role designs, which are not task based, may lead to the provisioning of roles with too much access or inherent SoD violations. By utilizing a task-based role design, organizations are more inclined to adhere to the principle of least privilege, defined as a system in which users are only able to access the information and resources that are necessary for legitimate business purposes. Position-based or user-based role designs do not take into account scalability for business solutions and the opportunity for avoidable SoD conflicts.

Another example of mismanagement of security in the SAP environment involves inefficiencies surrounding the user provisioning process. A lack of automation with workflow capabilities and an embedded risk analysis can decrease visibility, and increase the risk of SoD conflicts. Furthermore, manual provisioning processes can lead to long cycle times from the time of request to the time access is granted or denied.

How has the emergence of mobile and cloud technologies posed new challenges to organizations that are preparing for an SAP security audit?

With the expansion of mobile and cloud technologies comes an increased risk for cyber attacks to SAP systems. This leads us to the question, how secure is the cloud and is there a way to mitigate any associated risks? One of the benefits of the SAP HANA Cloud Platform, as highlighted at the 2013 SAPPHIRE Now conference, is the ability to leverage multiple deployment options — whether in a customer’s data center, the public cloud, the managed cloud, or a hybrid environment — to help meet the changing needs of any organization. SAP has also released SAP Mobile Secure, an enterprise mobility management tool that provides organizations with increased security for apps and mobile devices. Furthermore, the cloud edition of SAP Afaria addresses the need for a convenient, reliable, and low-cost solution that provides a way to manage security risk with or without any prior SAP infrastructure.

In the second stage, political reform, one of the questions you cite that an organization asks is “How will this change the way we do business?” Could you provide an example of a business-changing issue pertaining to security of an SAP environment?

Political reform refers to the need to make modifications to the current role design, role management methodologies, or user provisioning process. This can lead to a need for clearer definition of jobs and responsibilities in the SAP landscape. Additionally, it may require previously grouped tasks to be separated across individuals within an organization to avoid inherent SoD conflicts. For some companies, the greatest challenge in prioritizing SAP security is the need for increased collaboration between the business and IT. This collaboration can lead to more defined requirements regarding ownership of SAP roles and critical permissions across functional areas within the organization.

In the third stage, ongoing legislation, one of your questions is “What risks do we still have and how are we going to monitor them?” Could you provide an example of changes an organization has made to the methods it uses to monitor risk?

There are many automated and manual options when it comes to monitoring and assessing risks. SAP Access Control and Risk Management offer tools to meet this demand. The Risk Management tool enables organizations to quantify risks based on impact and probability. Owners can be assigned to risks, and notifications can be activated to bring awareness to controls that have or have not been performed. Those who are fearful of an upcoming SAP audit need not worry. Most organizations have unavoidable risks associated with some aspect of their security design. However, it is essential that companies are able to demonstrate the steps they have taken to mitigate these risks. Leveraging automated or manual mitigating controls as part of SAP Access Control is one method for taking a proactive approach to known risks.

For organizations that do not deploy GRC, it is essential to have a central repository to manage approvals and changes that have been executed in the SAP landscape. A repository can be used as an in-house audit tool to track change logs or actions that have been taken against mitigating controls. However, risk-monitoring methods are only valuable if companies have been able to appropriately assess not only risk priority levels but also the effectiveness of controls that are in place.

When you speak with clients about preparing for an SAP security audit, what do they seem most concerned about? What’s turning them into insomniacs?

First of all, no one should be losing sleep over an SAP security audit, but a lack of transparency can lead to uncertainties surrounding the business. The greatest concern, understandably, is a need for increased visibility into the cumulative nature of a user’s access in business terms. This lack of visibility also leads to risks with regard to critical access and permissions. Many organizations are concerned that they aren’t following industry standards and best practices when it comes to SAP security, which will evoke wariness in auditors. Has everything been secured as it should be? Are we following a streamlined process when it comes to making critical program and configuration changes and have the necessary authorization checks been implemented and tested? Who requested the change, who approved it, and who tested it? This again is where the need for a central repository or GRC landscape comes to fruition. It is not enough to have the processes in place. Monitoring efforts need to be performed to ensure that controls have been executed.

Another growing concern for savvy organizations is the need for information in real time. Many companies have employed detective controls, which do not allow for a proactive approach to SAP security risks. Detective controls are valuable with regard to reporting and analytics, but with the onset of competition in the environment via cloud and mobility comes an increased need for preventive measures and risk-monitoring efforts. By gaining a better understanding of the organization’s SAP landscape, organizations often see decreased administrative and testing efforts to maintain the security environment, an increased ease of scalability, and a minimization of SoD conflicts as well as data integrity issues due to a misuse of users’ authorizations.

Tracy Levine is an SAP application consultant at itelligence. She has functional SAP experience across multiple industry verticals and SAP applications, including SAP security, SAP Access Control, and production planning. Tracy is also the voice behind the blog “Diary of a Post Grad SAP Consultant.” https://postgradsap.wordpress.com/

If you work in the Asia-Pacific area and want to learn more about SAP security and audit issues attend these sessions at GRC 2013 in Singapore. To register for this conference click here.

Gary Byrne

Gary is the managing editor of Financials Expert and SCM Expert. Before joining WIS in March 2011, Gary was an editor at Elsevier. In this role he managed the development of manuscripts for Elsevier’s imprint responsible for books on computer security. Gary also has held positions as a copy editor at Aberdeen Group, a Boston-based IT market research company, and as an editor at Internet.com, a publisher of content for the IT community. He also gleaned experience working as a copy editor for International Data Corp., a Framingham, MA-based IT market research company. He earned a bachelor of science degree in journalism from Suffolk University in Boston. He enjoys traveling, sailing as a passenger onboard schooners, and helping his wife, Valerie, with gardening during summer weekends. He’s a fan of all the Boston sports teams and once stood behind Robert Parish in a line at BayBank. He felt small and didn’t ask for an autograph. You can follow him on Twitter at @FI_SCM_Expert. His online footsteps can also be found in the SAP Experts group on LinkedIn.

You may contact the author at gary.byrne@wispubs.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.