Are SAP Developers Defense Chiefs?

SAP developers work in integrated business-critical environments and create software that processes data with specific security features and regulatory requirements.

Key role of the developers

SAP developers play a key role in shaping the security landscape of SAP environments. Developing code for changes to existing SAP functions or new applications and interfaces can be an IT development project of any complexity. These customizations are often necessary, but can contain vulnerabilities and reduce the security level of the overall system.

Many security vulnerabilities in the SAP environment are due to missing requirements, wrong decisions in software design and tool selection and a lack of knowledge about secure programming practices with the programming languages and frameworks used. Developers unknowingly create multiple vulnerabilities such as directory traversals, cross-site scripting vulnerabilities or access control errors. A single vulnerability can expose sensitive business data or allow the system to be compromised by an attacker. As it stands today, developers create new security risks in addition to the benefits of their work. Developers have extensive permissions. With extensive access rights, developers can inadvertently or maliciously introduce backdoors, manipulate critical data or bypass security controls. To this day, checklists for checking transport releases often do not include a check for security defects or malware.

If no segregation of duties is enforced and developers have unrestricted access to development, test and production environments, it is particularly interesting for attackers to exploit these accesses. Outside of the SAP world, the profile of an SAP developer would be described as a full-stack developer. In contrast to frontend and backend, this refers to programmers who independently implement an application from the user interface to integrations and business logic using the available technology stack.

In combination with their process knowledge, SAP developers use the SAP toolbox to deliver thousands of enhancements and customizations every day, providing SAP customers with enormous innovation potential and competitive advantages. SAP's toolbox is growing and SAP developers are often expected to master the gamut from maintaining a legacy SAP GUI application to using Fiori elements and everything in between. Each of these keyboards has individual security features that the SAP developer should take into account when using them in order to avoid vulnerabilities and implement security requirements correctly.

Fatal learning by doing

Rarely can you take the time and resources to do this - there is usually a "learning by doing" mentality with consequences. "I would never have thought of a software delivery format when I heard the term 'transport'," says the software security architect at a bank. Often, the rest of IT operations and information security are completely unaware of the frequency and scope of software development using SAP technologies as an application platform. A software architect at a customer once described this as the "hidden elephant" of his software development practice.

However, it also happens that initiatives to control software development processes or improve quality and security do not include SAP development and that processes and tools defined for this purpose are not or only partially applicable to SAP development. Errors in customer-specific developments and add-ons can cause considerable security problems. Like every programming language, Abap and co. also have specific characteristics that developers must take into account.

Abap error pattern

From the dozens of code reviews I have conducted over the past ten years, the following error patterns stand out:

• Insufficient validation of input leading to directory traversal, SQL injection or code injection vulnerabilities. This directly or indirectly results in the possibility of a complete compromise of an SAP system. This is often due to a lack of knowledge about the security features of the framework or API used.

• Errors in the design and implementation of access controls such as missing or logically incorrect authorization checks and insufficient segregation of duties in the design of data storage or processing and display. This can result in the leakage of confidential information or its compromise at transaction level.
• Insecure integration designs that ultimately result in opportunities to compromise productive SAP systems from, for example, test and development environments or enable other forms of server-side request forgery attacks.
• Failure to clean up outdated and usually no longer relevant tools or copies of standard SAP applications in which security functions have been removed or SAP vulnerability fixes have never been implemented.

Only use "call transaction" with the option "with authority-check" (excerpt from a typically bad development guideline).

Clean-core paradigm

Even in the SAP world, software security needs clear guidelines in combination with appropriate support for developers in order to fulfill them. Code quality and security initiatives often fail because of the latter. Neither the introduction of improved source code analysis compared to standard tools nor prohibitions in development guidelines will make SAP developers aware of security and the necessary solution competence.

The right training and sensible handouts in the form of how-tos are the basis for the necessary cultural change so that other measures and tools also take effect. But can an SAP developer using the "Clean Core" paradigm and tools such as SAP Build and Joule still cause serious security problems in the future? "Clean Core" propagates the separation of enhancements and core functionality. In addition to the self-serving goal of being able to better migrate existing customers to SAP cloud services and get them used to them, operational risks during updates and migrations are significantly reduced when used correctly.

Close safety defects

The use of the SAP Business Technology Platform (BTP) results in a stricter separation of the customer's own extension from the SAP standard. If implemented well, the potential impact of the typical vulnerabilities mentioned above can be reduced or greatly mitigated, or certain security defects such as directory traversal vulnerabilities can be eliminated. The demands on the developer's ability to implement security correctly and to convert originally transaction-oriented designs into a microservice architecture are considerable. SAP developers are now also responsible for further security tasks, such as building roles, applying new concepts for application logging and checking dependent software components and libraries for malware and vulnerabilities.

The truth is in the code

In the classic SAP operating model, these are the tasks of the authorization and basic administrator. With cloud-native programming, there are also new threat scenarios that the SAP developer has to deal with. For example, an economic denial of service (EDoS), in which the application is misused to use cloud services and resources to such an extent that the costs cannot be borne or services are deactivated by reaching maximum consumption values.

They must understand the available SAP toolbox with its security features and should be able to master concepts for the security analysis of software applications as well as create threat modeling and implement countermeasures. This makes the SAP developer a central and controlling player in the IT security of your SAP environment.

In summary, it can be said that both cloud-native and classic SAP applications, whether developed by the customer or by third parties, must be carefully checked for vulnerabilities and security compliance. The role of the SAP developer is changing more and more from the implementer of functional requirements to a consultant who finds innovative solutions, considers data security and protection as well as security requirements for the operation and provision of their application from the outset and scrutinizes their adequate implementation.

Understanding the SAP toolbox

They must understand the available SAP toolbox with its security features and should be able to master concepts for the security analysis of software applications as well as create threat modeling and implement countermeasures. This makes the SAP developer a central and controlling player in the IT security of your SAP environment.