Basis survival guide to a SAP audit

SAP audits: the necessary evil of today’s business world. Most public companies, and now more and more privately held companies, typically run one ‘formal’ audit done by an outside organization every year, and may even run a handful more ‘internal audits’ as well. For a SAP technical admin, audits can be stressful. There’s a lot of different components to a SAP technical audit and keeping them all under wraps throughout the course of a year can be difficult. So let’s review what a technical basis engineer should consider during an audit starting at the top of the technical stack, the application layer, then working our way down the stack, hitting on every component along the way.

SAP Application Layer - Users

To begin, one of the most widely talked about areas of a SAP audit is user administration. Each user in a SAP system has different authorizations within the system based on roles and profiles that can be assigned to those users. These roles are granted by employee job responsibilities to keep segregation of duties, or in other words keep people from being able to, for example, create, submit and approve a bonus check for themselves. The roles and profiles are customizable and next to impossible to easily manage, especially in large organizations. Typically there is a team of people, the SAP Security team, that manages the roles, profiles and users, often through a GRC solution. Even more, there are different ‘administrator’ users that are in each SAP client that come with ‘out-of-the-box passwords that need to be locked and changed prior to system use. Locking these users down during a SAP installation is a simple step that can easily be overlooked yet is a huge gaping hole into nearly full access to all the data in a system. 

Download our Basis Engineer's daily checklist >>

SAP Application Layer - Architecture

Users are not the only thing that will be audited at the application layer. Each SAP ABAP system consists of different clients that each have their own set of security settings such as being able to modify components, etc… Depending on the system role (Dev/QA/PRD) these settings may vary significantly. The tricky part with system and client settings is there may be exceptions to when a client may need to be opened. For example, project work such as client copies, migrations, or an emergency change request, will result in temporarily opening up or unlocking these settings. Remembering to lock these settings back down can easily be overlooked and is an easy way to get a ‘ding’ on your yearly audit, or worse - an open hole that can be exploited.

Database Layer

SAP is a database-centric system. Unlike most applications, everything in SAP is held at the database layer, even things such as system support packs, etc…  The database is the heart of a SAP system and can even be considered the heart of an organization - especially true in today’s world where data is everything. SAP systems hold HR data, finance data, manufacturing data, supplier/contractor data, the list goes on... and all of this very important company information is held within the database, which should be impenetrable.  Really there should be very few users with access to the SAP database and any request for this access should be refused. With that being said, it’s not uncommon to come across a SAP system with various users that should not be on the system. This is extremely dangerous and can lead to major data breaches, and why it is such a crucial part of the SAP audit

Operating System Layer

Similar to the database, there should only be a select few who have access to the operating system(s) of a SAP system. There are some base administrator users that are generated during installation and similar to those at the SAP application layer, these should be locked down with only the necessary authorizations. It is best practice to have few O.S. level users and only should be granted to those who administer the systems. Beyond user-level access, there are also SAP settings that are held within what is called “profile parameters”. Many SAP technical administrators would argue these settings should be discussed up in the SAP application layer as they can be adjusted within the application layer and modify/manage that layer. However, it’s important to note that SAP profile parameters are one of the few things in a SAP system that can be managed outside of the SAP application and database layers and can be accessed directly from the operating system. These profile parameters manage things such as memory settings of the system to an organization's security policies (such as password length, etc…) to further system security settings. It’s important to understand the importance of these settings and that they can be accessed via the operating system and is best practice, from a security standpoint, to keep an eye on these profile parameters from the OS, as malicious activity can ‘unlock’ administrator type user accounts and nobody would notice until it’s too late.

Download our Basis Engineer's daily checklist >>

Network Layer

Depending on your audit, the network layer may not come into play. In fact, for many technical SAP engineers, the network layer may not even be part of their responsibilities; however, it’s important to have a basic understanding of the damage that can be done to an open network.  Luckily there are teams of network engineers, using all sorts of solutions to help monitor, manage and control those environments and keep them restricted to the correct levels of access.

It’s clear to see how complex it is to keep an SAP system secure. And if you add in complex architectures over hybrid environments, with worldwide users, it just gets more and more convoluted. It can not be stressed enough how important it is to have a monitoring solution, like Avantra, in place that not only monitors standard health KPIs, but also these security/audit based checks at each layer independently, 24/7, for reporting and notification based purposes