How can your organization improve its Systems Applications and Products (SAP) risk posture? Aligning with the key principles of zero trust through tangible and specific measures is one way.

To begin, let’s define the principles of zero trust. We’ve all seen the types and breadth of zero trust out there. Which are most relevant to SAP?

Three principles of zero trust

Principles Focused Concepts
Implement Least Privilege – Provide minimum required entitlements, roles and authorizations to reduce the attack surface Access management, privileged access management, segregation of duties and access risks
Assume a Breach – Proactive and real-time security operations under the assumption that systems have been breached System hardening, threat and vulnerability management, audit logging and forensics
Never Trust, Always Verify – Continuous verification of identity instead of reliance on single point-in-time authentication Identity, authentication and single sign-on
Scroll to view full table

The overall objective of zero trust is to reduce the attack surface. It assumes trust is a form of risk and cannot be completely removed from a business. Using a zero trust framework provides a baseline in which an organization can identify and use the right access controls, risk management and authentication protocols to empower the business.

The principle of least privilege

Anyone familiar with SAP roles and authorizations knows the SAP security structure is complex. Limiting access to only the required authorized business and IT activities can be daunting, especially if you manage it manually. Best practices for using least privilege focus on appropriate access controls. Most organizations have some sort of governance, risk and compliance tooling to support access risk analysis for SAP applications, but not all.

When attempting to address access risks, organizations must have an exhaustive map of risks for segregation of duties (SoD) and sensitive access. Without it, you’ll get false negatives. Access risk reporting is only as powerful as the library of risks used for the analysis. If this does not include items such as custom transaction codes and cross-application considerations, the organization will be left with an unknown number of access risks that could result in critical SoD conflicts. SAP Fiori and non-ABAP-based applications involved in business processes can make it even more complex.

Below are examples of basic access risks. In the first example, the risk belongs to a single user identity, Thomas Watson, and the user only transacts in a single system.

In the second example, the organization has deployed both SAP Fiori and SAP Ariba, which complicate the mapping and reporting of the same access risk. Now, Thomas Watson may transact using different user identities in different systems. This access leads to an SoD risk, which can lead to fraudulent activity and compliance issues.

Even an untrained eye can see the complexity of identifying, reporting and managing access risks has drastically increased.


Organizations should review both access risk analysis and privileged access management processes and technology.

For access risk analysis, the key questions to ask are:

  • Is the ruleset accurate, up-to-date and inclusive of all SoD-relevant applications? Does the ruleset represent the exhaustive set of risks, business functions and underlying entitlements?
  • Do the processes and tooling enable cross-system analysis? Does this account for inconsistent user mapping and customized actions?

For privileged access management, also referred to by SAP as firefighting, emergency and superuser access, the key questions to ask are:

  • Do you use firefighting access correctly for truly elevated business or IT actions that warrant more attention? Or does your team use it as a workaround for granting end-user access?
  • Are the processes and tooling enabled for firefighting across the entire SAP landscape? How do you manage privileged access for SAP applications like SAP Ariba, SAP Concur, SAP Integrated Business Planning and the HANA database?

Assume a breach

Both vulnerability management and threat detection have made major strides for SAP. However, those applications are managed by a different part of IT and not integrated into the enterprise security operations center or SIEM solution. The reasons are two-fold:

  1. SAP programs are often managed apart from the rest of IT with separate initiatives, budgets and resources.
  2. The nuances of SAP architecture and ABAP programming language make it difficult to align with traditional enterprise tooling and processes.

Organizations have come a long way in protecting their SAP assets, however. Many have focused their efforts on SAP native tools and insights from SAP Solution Manager. If configured correctly, Solution Manager is a critical admin and security tool. After all, it provides relevant security data.

Other SAP-native tools such as EarlyWatch reports, Security Optimization Service and SAP Security Baseline provide point-in-time insight on vulnerabilities and misconfigurations. Security audits and system logs are also important. However, these are most often used for troubleshooting after an incident. To improve the overall risk posture, insights must become real-time and empower security analysts with the information to detect, triage and respond.

How to integrate SAP

Organizations need automated tools to aid in real-time threat detection and vulnerability management for their SAP environments. The good news is that many businesses have made major investments in their network security. Whether in-house, outsourced or hybrid, many organizations have the people, processes and technology to support threat management and vulnerability management programs.

However, separate teams often manage the security of the SAP environment, putting it in silos. Weaving SAP into the rest of security operations is key. Find out where you can use existing security investments to secure SAP systems. In other cases, you may need controls and tools that are purpose-built for SAP.

In threat management, many organizations have all of their event logs, including SAP, performed by a single SIEM. Below is the best setup to ensure the SIEM is consuming relevant, actionable events from SAP while reducing false positives. It is critical to deploy an SAP-centric threat management solution in front of the enterprise SIEM to assist with filtering.

Key questions to ask are:

  • Does your patch management process allow for effective and speedy deployment? Evidence shows that new exploits found on SAP Patch Tuesday are being exploited within three days.
  • Do you use data loss prevention and UI masking to further reduce the impact of a breach? SAP native and third-party solutions can assist with data security at the application and database level.

Never trust, always verify

Most businesses still rely on basic username and password credentials for accessing SAP. What you may not realize is that usernames and passwords are stored in a single table (USR02-SAP Logon Data). SAP has developed many advancements to make passwords harder to crack. However, even with the most secure approach deployed by SAP using the SHA-1 hashing algorithm, passwords are still quite crackable.

How crackable? After a couple of hours of playing around with an open-source tool and various blog posts, I was able to crack an SAP password protected by SHA-1 in the PWDSALTEDHASH field of USR02.

The incredible part was how quickly a novice attacker (or threat actor) would be able to go through the same process. In this case, I created an SAP user id and set the password to ‘Basketball1!,’ which has the following password complexity:

  • Character length – 12
  • Capitalized letter – 1
  • Number – 1
  • Special character -1
Plaintext Password Ciphered to à Value from field PWDSALTEDHASH
Basketball1! {x-issha, 15000}DVmjtLY3sbV69+DRHbLLWWWmHE6MvPNzq2T9QAM71k42BxM/
Scroll to view full table

In a matter of 36 seconds, I was able to decipher the password using a basic dictionary attack.


As it relates to the exercise above, you should ensure that you are using PWDSALTEDHASH over BCODE and PASSCODE. This is very important to SAP customers that are on older and unpatched versions of SAP and have not enabled the PWDSALTEDHASH (minimum requirement is SAP NW 7.02 or higher). In addition, on a periodic basis, you should validate that the password complexity aligns with corporate policy and guidelines, such as the National Institute of Standards and Technology’s Password Guidelines (800-63B). However, the best practice is to use single sign-on (SSO) and multi-factor authentication (MFA) with the aim of removing the need for username and password credentials.

Questions to ask include:

  • Have connections between SAP systems, system IDs and interfaces been configured as trusted and encrypted? At a minimum, consider adding secure network communications (SNC) between systems.
  • Has the table for illegal passwords (USR40) been updated with common words to be omitted?
  • Can SSO be used across the SAP landscape? With SSO properly enabled, the hash table entries can be removed altogether, which erases the risk of password attacks.
  • Have there been discussions about database activity monitoring or UI logging solutions for the SAP environment? DAM and UI logging enable you to have more control over monitoring, auditing and validating intent.

Getting started with zero trust

These are just a handful of plans and actions to consider for aligning enterprise zero trust programs with SAP. Not sure where to turn? IBM Zero Trust workshops using design thinking is a great approach to outline your SAP security ‘as-is’ maturity and desired ‘to-be’ state, all within the context of zero trust.

More from Risk Management

Remote access risks on the rise with CVE-2024-1708 and CVE-2024-1709

4 min read - On February 19, ConnectWise reported two vulnerabilities in its ScreenConnect product, CVE-2024-1708 and 1709. The first is an authentication bypass vulnerability, and the second is a path traversal vulnerability. Both made it possible for attackers to bypass authentication processes and execute remote code.While ConnectWise initially reported that the vulnerabilities had proof-of-concept but hadn’t been spotted in the wild, reports from customers quickly made it clear that hackers were actively exploring both flaws. As a result, the company created patches for…

Researchers develop malicious AI ‘worm’ targeting generative AI systems

2 min read - Researchers have created a new, never-seen-before kind of malware they call the "Morris II" worm, which uses popular AI services to spread itself, infect new systems and steal data. The name references the original Morris computer worm that wreaked havoc on the internet in 1988.The worm demonstrates the potential dangers of AI security threats and creates a new urgency around securing AI models.New worm utilizes adversarial self-replicating promptThe researchers from Cornell Tech, the Israel Institute of Technology and Intuit, used what’s…

What should Security Operations teams take away from the IBM X-Force 2024 Threat Intelligence Index?

3 min read - The IBM X-Force 2024 Threat Intelligence Index has been released. The headlines are in and among them are the fact that a global identity crisis is emerging. X-Force noted a 71% increase year-to-year in attacks using valid credentials.In this blog post, I’ll explore three cybersecurity recommendations from the Threat Intelligence Index, and define a checklist your Security Operations Center (SOC) should consider as you help your organization manage identity risk.The report identified six action items:Remove identity silosReduce the risk of…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today