skip to Main Content

Your business runs on data, and your SAP implementation is critical to keeping your business running. Consequently, you want to lock it down and make it impervious to attacks. The problem is that you also need it to be open and usable by the people who need to enter data, read the data, and make decisions based on the data.

The key to success is knowing what to lock down and what to open up to whom. After all, the biggest attack vector for most organizations is internal. According to the 2016 Cyber Security Intelligence Index, IBM found that 60 percent of all attacks were carried out by insiders, with a quarter of those being inadvertent or mistakes.1

Three Steps to Understanding Your SAP Security Risks

At Symmetry, we developed a three-step series of best practices for understanding your organization’s SAP Security basics so that you can deploy the right security to protect your business.

Step 1: Establish Baseline Risks

The first phase is to establish the baseline risks for your organization. This begins by reviewing sensitive roles. You need to understand the most powerful roles in your system because these are the most vulnerable spots in your SAP armor. Understanding the power that these roles hold and who has access to these roles will go a long way toward mitigating your risks.

Next you want to review custom transactions. Anything that breaks from normal protocol needs to be scrutinized. Start by looking for transactions that begin with Z or Y, as these are the most common non-standard transactions in your system. Next look for deltas on a quarterly and annual basis, as these often indicate activities that are outside the norm.

The third phase in establishing your baseline is to run a Segregation of Duties (SoD) risk analysis. During this phase, you want to look at how your organization distributes risk analysis to system owners and to business owners. The system owners will be responsible for assigning sensitive roles and profiles, while the business owners control assigning roles to users. If your system owners and business owners are not in sync on which employees need what access, data can easily fall into the wrong hands. As you perform your SoD analysis, look at the risk changes on a monthly basis. Any significant changes in roles and responsibilities can be a liability.

Step 2: Define Controls

You need to know who has control over which aspects of the business. Having a role that can create a new supplier and also issue payments is a very risky situation that is easily compromised. Create an audit list of who has access to what, when they have access, where, and why. Then assign mitigating controls with expiration dates to offset the risks. People change roles often, so creating expiration dates for each role minimizes the risks inherent with having people move around within your organization.

SAP-SecurityOnce you have defined the compensating controls, then you want to reaffirm control. This entails verifying that controls are still active by owners. This is a good time to reaffirm the extension of control assignments to users to make sure that everybody only has access to what they need for their role. We recommend defining and reaffirming your controls at least once a year.

Step 3: Perform a System Risk Assessment

Believe it or not, weak passwords are still in use worldwide. According to Gizmodo2, the most common passwords are still “123456” and “password” with “qwerty” – the first six letters on the left side of the keyboard – right behind. People also still scribble their password onto a Post-It note that they hide in plain sight. Every risk assessment needs to begin with a review of password strength for SAP users.

When your SAP landscape grows across multiple systems, servers, and architectures (such as cloud deployments and on-site), it becomes increasingly important to verify that profile parameters remain consistent across your landscape. This is particularly important when different databases and user interfaces (such as HANA and Fiori respectively) are involved. In this case, consistency equals strength.

You also want to lock your production systems to prevent unauthorized or accidental changes to systems, permissions, and roles. Changes at the system level can be very hard to track, so the safest thing to do is lock production systems to prevent this from happening.

Once a system moves into production you want to remove all developer keys. These keys can accidentally or maliciously change the code to allow users to bypass SoD restrictions or gain access to data that is restricted.

We also recommend limiting the number of developer keys during development to prevent unauthorized access before the system gets into production. A simple change during development can provide a backdoor into the system or allow unauthorized access to data. Restricting developer keys is an easy way to minimize this risk. You also want to clean up your developer keys to ensure that everybody with one is an active developer, and not a former employee and somebody who took on a new role. Again, expiration dates for developer keys is highly recommended.

Make sure that all instances of Debug/Replace are removed in production systems going forward, but for production systems that are already deployed you need to find and remove any debug/replace usage in those systems. Make sure that all system owners have proper SAP Security training and are aware of the importance of finding and removing these instances to ensure system security.

Get Focused Help

We understand that this level of review and security implementation could dramatically impact your department, so Symmetry offers an SAP Security Risk Analysis to help you understand the risks your organization faces and how best to remediate them. Talk to your Symmetry representative or contact us today.


1 Harvard Business Review article referencing the 2016 Cyber Security Intelligence Index, The Biggest Cybersecurity Threats Are Inside Your Company, September 19, 2016,

2 Gizmodo, The 25 Most Popular Passwords of 2017: You Sweet, Misguided Fools, December 19, 2017, 

Ben Uher, Client Manager of Security & Controls

Ben Uher, Client Manager of Security & Controls

Ben Uher manages the SAP Security and Controls Practice at Symmetry where he leads a team of permanent Consultants in delivering SAP Security and GRC offerings to global organizations. His deep knowledge in everything SAP Security and GRC related has come from the opportunity to work with over 150 Organizations running SAP throughout various cycles of their implementations. Variation in industry, sector and size has provided a breadth of opportunity and experience in almost every facet of SAP technology spanning HANA, Fiori, ERP, BW/BI, HCM and SCM amongst others. Most importantly, Ben is driven based on results and continually strives to provide exceptional support for the organizations that rely on him and his team as trusted advisers for SAP Security and GRC support.