ABAP code scanning and risk analysis of custom code
Many SAP customers develop applications by writing custom ABAP code. That’s a risk if you don’t have proper ABAP code scanning procedures in place. In this article, I will explain how to analyze and mitigate the risk in custom code using the Xiting ABAP Alchemist.
Business processes are constantly evolving, and businesses must adapt to these changes to stay up-to-date. System administrators implement new functionalities and the system design changes frequently. SAP customers often have individual requirements and develop custom code that meets their needs.
Table of Contents
The problem with custom code
Customers implement custom ABAP code to add functionality to their SAP system that is not available out of the box. At the same time, SAP continuously enhances its software and introduces new functions with enhancements packages (EHP). Below is an overview of the impressive number of changes that SAP introduced with the latest EHP version 8:
- 500,000 new ABAP programs
- 35 million new code lines
- 8000 new SAP OSS notes
- 1330 + (accumulative) business functions, with approx. 240 new functions specific to EHP8
- 32 new business processes
What does that mean for a customer?
When new functionality gets introduced, previously developed custom functionality might become obsolete but often remains in the system. This causes a potential risk to a company, and proper risk assessment can’t be performed. On the other hand, new functionality brings new risks and requires an update of applicable SoD rule sets. So how does that process look like?
The Segregation of Duties (SoD) management process always starts with identifying the risks on a business level, building technical rules and analyzing the current situation.
The SoD management process is a well-approved best-practice approach that must be followed. The process of the risk identification must take place in the business and requires business process owners and auditors to build the framework of risks. In this step, custom developments must be identified. In the next step, building rules require optimized SU24 values and proper authorization checks in the custom code. When leveraging SAP Access Control (GRC), enhanced SU24 value proposals are essential to building rules properly. Let’s look how we can achieve that.
Best-practice Approach
Xiting follows a five-step approach to analyze custom developments properly:
Identification
First, it’s important to identify custom code to understand the scope. To identify customer code, we can leverage transactions SE37, SE38, SE80, etc. as well as table TSTCT.
Then we analyze statistical trace data (ST03N) to find out if any of it has been used. As part of the trace analysis, we can categorize it based on its functionality (e.g. display, change, delete, update, etc.), and identify the code ownership. In case the custom code is still in use, we have to understand what the program in question does, based on a technical and functional analysis. As initially mentioned, very often custom developments were introduced before standard functionality was available and we can, therefore, replace it with the newly added functions.
Classification
Classification of the custom code decides whether the program or transaction shall be in scope for risk analysis. In many cases, we have seen transactions and programs like Z_MIG, ZME21, ZFKO1, etc. which are a copy of the standard program but got either extended or restricted in some way. But there are other risks to pay close attention to, such as copies of standard functions that have no authorization checks. Developers and administrators usually also have an arsenal of tools and programs that allow them to perform tasks they might not be allowed to, like Z_RESET_USER_PWD, Z_OPEN_CLIENT, Z_SET_USR_PASSWORD, etc.
Define Rules
Establishing general development standards and guidelines enable continuous quality assurance and are crucial for developing custom code sustainably. We highly recommend developing security standards for any developments, such as:
- ABAP code must have an authority-check
- Dialog programs are only allowed to be used via Z-Transactions
- SU24 optimization to properly maintain authorization via the profile generator (PFCG)
- Naming conventions (e.g. Z_CRE for “create” actions, Z_DSP for “display” actions, etc.)
- Automated ABAP source code scanning
- We recommend the use of a tool to ensure the quality of the coding. The Xiting ABAP Alchemist, which is part of the Xiting Authorizations Management Suite (XAMS). The ABAP Alchemist suggests missing authorization checks and enables you to update SU24 values automatically. Other tools like SAP’s standard tool, the SAP Code Inspector (transaction SCI), or the SAP Vulnerability Scanner, can, to some extent, automate source code scanning, but are neither able to propose SU24 values nor to recommend missing authorization checks.
- Implementing a security gate for transports
Also, we highly recommend defining guidelines for authorization administrators, such as:
- No authorization for transactions like SE38, SA38, SE80, etc.
- Only assigning transactions via the profile generator
- No manual maintenance of S_TCODE authorization object
Once these guidelines are in place, a security gate must be installed to ensure that each line of code and each role that gets transported follows the standards.
Remediation
Transactions and programs that are no longer in use must be de-authorized and hidden from end users. We recommend to remove all authorizations, but not to delete custom programs. To properly remediate and enable custom developments for risk analysis, SU24 proposal values must be updated. Code that does not belong to a program, but is still implemented, shall be removed to reduce complexity and allow easier debugging. Also, it is important to correctly authorize direct table access with authority checks and the use of reusable functionality, such as BAPIs, APIs, etc.
What’s next?
Once you have cleaned up your custom code, the SoD management process can continue, and you can introduce the custom code to the rule set. When you establish the rules, SAP Access Control (GRC) can run the risk analysis on the user, role, or profile level. For more information on How to remediate SOD risks in SAP Access Control, check out my other blog article.
The effort to remediate custom code
Remediation is an ongoing process, and cleaning up existing programs depends on the security requirements of your company. If the requirements are manageable, we recommend the Pareto principle (80/20 rule) by first taking care of critical programs:
- Implement standards like authority checks in all programs,
- Properly secure direct table access,
- Optimize SU24, and
- Consider critical programs for the risk analysis.
If you require the highest level of security, we recommend executing a detailed analysis of your source code. Especially watch out for bypassed authority checks, native SQL statements, macros, directory traversal, and code injection. Also, we strongly recommend the use of tools like the ABAP Alchemist to automate active code scanning.
ABAP code scanning: How to analyze the risk in custom code
Remediating and improving custom code is an on-going process and requires state of the art security programming and the use of automation tools. When taking custom code into consideration for risk analysis, it is necessary to leverage the use of onboard tools such as SU24. To ensure continuous compliance, it’s necessary to create an awareness of security guidelines in each step included in the process. Developers have to follow coding standards, authorization administrators must maintain roles properly using onboard tools, and security administrators have to set the scope of the risk analysis.
