The first step of surviving an SAP audit requires doing a little digging and getting your hands dirty. PROCEED WITH CAUTION. You may not like what you are going to see. The State of the Union: Necessary, albeit Messy (if you will).
The State of the Union not only allows for reports on the condition of the nation (SAP Landscape), but also allows the president (key stakeholders) to outline their legislative agenda (key remediation initiative).
Where are we now?
Determining the “current state of affairs” is perhaps the most difficult task of all. Having a clear understanding of all the pieces of the puzzle and how they should fit together, will help dictate the steps needed to put everything in place and the strategy in which one will approach this task. The following is a modified checklist highlighting a few of the key factors that should be monitored, regulated and documented in order to sustain a scalable and stable SAP environment.
- Do documented processes exist for user administration, role administration and transport management?
- Have custom tables and programs been secured?
- Do multiple roles exist with only one transaction assigned? Do transactions repeat across multiple roles? Are many roles assigned to only one or a few users?
- Is critical access and permissions limited to only a few users and are their actions being recorded and audited?
- Have the proper steps been taken to follow industry standards regarding password rules, SAP default users and table maintenance?
- How many Segregation of Duties (SoD) violations occur inherently within individual roles? How many users have SoD violations per the combination of assigned roles?
***The list above is only a small portion of the discovery efforts required in order to determine the current state of an SAP environment. For more information regarding audit efforts for your organization, please feel free to comment below or e-mail me at firstname.lastname@example.org.
How did we get here?
An organization must focus on appropriately designing user access rights to identify an effective balance between the provisions of sufficient end-user privileges to fulfil job responsibilities, and ensuring that business process and system security risks are adequately controlled. As SAP is pre-configured with only a basic level of security and control, organizations are essentially required to define, build and maintain their own requirements into the system which requires a significant investment of resources. Organizations need to ask themselves the following questions:
- Were scalability needs and growth outlook taken into account when the role design was originally conceived?
- What persons and stakeholders are involved when role remediation efforts are performed? How have these changes been tracked? Who owns the roles and determines accuracy in the permissions within each role?
- What persons and stakeholders are involved when users are assigned new roles? Has any effort been taken to perform regular user access reviews across the organization?
- How was the naming convention for the roles determined? Is there an inconsistency between roles descriptions and actual authorizations, potentially leading to unauthorized access?
- Is there an internal audit system in place to determine whether SoD violations exist? Have efforts been made to mitigate SoD risks in some manner?
What challenges do we face?
One of the primary concerns, when preparing for an SAP Audit, is being able to articulate the security landscape in terms of business processes. Auditors are looking for the “owners” of the security environment to be able demonstrate knowledge on potentially risky pain-points and how they are going about monitoring these issues. 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.