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

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.

Solution

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

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

Solution

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.