Securing your SAP environment is essential to protecting sensitive business data, ensuring regulatory compliance, and maintaining operational continuity. As security practitioners, we understand this and the importance of protecting the perimeter against external attacks. But it's equally crucial to secure and harden our systems against threats within the SAP environment, especially when migrating from ECC to S/4HANA.
With SAP ECC support terminating in 2027 and businesses now actively transitioning to S/4HANA, it is crucial to thoroughly grasp, secure, and transfer your customizations to the new platform with minimal disruption. While SAP’s standard functionality is efficient and simple, relying solely on these standards is often impractical. Organizations inevitably need to customize their SAP landscapes to support their unique business functions and processes. But with these customizations come potential security weaknesses. Whether it's granting access to functionality unintended for use or allowing attackers to exploit gaps in code to inject malicious activities, it’s important to be aware and proactive in addressing these vulnerabilities.
In this article, we’ll outline a strategic approach to securing the custom elements, transaction codes (tcodes), and tables within your SAP environment. Read on to learn how implementing these robust security measures can enhance your operational efficiencies and foster trust among stakeholders, all while fortifying your organization’s defenses and preparing to upgrade your environment to S/4HANA.
The identification and categorization process is a crucial first step in securing custom SAP elements. It involves three key steps:
As a first step, you’ll need to pinpoint your customizations using the following tables: TRDIR (custom programs), TDDAT (custom tables), TSTCT (tcodes with descriptions) and TSTC (custom tcodes).
Next, identify programs that have associated executable tcodes with the TRDIR table. Any programs not executed by tcodes should be flagged to discuss with the relevant stakeholders. The aim here is to avoid the direct execution of programs designed for business processes. Instead, best practice is to ensure that all custom elements in your production environment are associated with a corresponding tcode. This tcode should be used to trigger the execution of the program. Business users should never be able to execute a program directly using SE38, SA38, SE80, SM37, SE24, or SM49.
The final step is documentation of the program, tcode and/or table purposes, uses, business process, sensitivity, associated code, authorization calls, corresponding standard programs, and SOD Rule Set ramifications. This is a crucial stage, as it will serve as history for change controls, audit purposes, upgrades, and much more. Taking the initiative to document your programs not only ensures clarity and understanding but will also yield significant time savings for your business in the future.
After identifying and categorizing your custom SAP components, the next crucial step is implementing robust security measures. This section outlines essential best practices and guidelines for securing all kinds of SAP customization. Adhering to these guidelines will significantly reduce your risk of security vulnerabilities and ensure that custom SAP elements are as secure as their standard counterparts.
Make sure your naming conventions for customization within the business process are simple and uniform. For example, all custom elements for the Finance AP team may start with “AP_*”. This same naming convention would then be used for custom tcodes and tables, and can also be used for background job processing, parameters, etc.
Program: Start by adding appropriate authority calls within the code, which will serve as the foundation to secure the program. Next, include a program functionality description in the program header to enable users to quickly understand the purpose of the program and its functionality when reviewing the code or debugging. Lastly, ensure developers have not hidden ok codes in the code or any other potential weaknesses which can be exploited. This can be done quickly through tools such as Onapsis, Security Bridge, or SAP’s Code Vulnerability Analyzer (CVA).
Tcode: Update SU24 with the appropriate authorization checks from the program and transport them up to production when the program is ready to be moved. This practice ensures the correct authorization objects are included in new roles when they’re assigned, during system upgrades, and when moving to S/4HANA. It also facilitates smooth testing processes.
Tables: Ensure the table has been associated with an authorization group (this can be viewed through the TDDAT table), as lacking the appropriate group can lead to unintended user access to these tables. Tables without authorization groups are automatically placed into the authorization group labeled: “NC&” and any users with this authorization group in S_TABU_DIS can see this table.
Additionally, if access is granted to this table through a specific tcode, it’s good to ensure SU24 is updated with the proper table name through S_TABU_NAM or the proper authorization group through S_TABU_DIS.
Key consideration: As best practice, lean on S_TABU_NAM authorizations first when granting access to tables. This authorization is more granular and limits who has access to which tables. It’s best to be extra cautious when using S_TABU_DIS, so we recommend you only use it when necessary. If required, first run an authorization check using SUIM to understand who you may already be granting access to before adding an authorization group to a table. For example, if you create a custom table for AP and put that new table into the “APGRP” table authorization group, any user that has a role with the authorization of S_TABU_DIS, DICBERLS=APGRP will automatically be granted that table.
To confirm that the appropriate checks are being completed, create a procedure around them for your change control procedures. This ensures that no program, tcode, or table is being moved without securing the code. Your checks should include the following:
Make full use of custom code checking tools such as Onapsis, Security Bridge, or SAP’s own Code Vulnerability Analyzer (CVA) to perform code reviews and assist with validating code to prevent injection attacks and zero day threats. These tools can assist with your change control processes to scan customization quickly within the development environments before being deployed into higher environments. These tools allow for high-quality threat intelligence, not only for initial analysis of your custom code, but also for on-going logging and monitoring while integrating seamlessly into DevOps programs.
Securing custom SAP elements is a critical aspect of maintaining a robust and resilient IT infrastructure and preparing your landscape to move with your customizations to S/4HANA. By following the strategic approach outlined above – identifying and categorizing customization and implementing best practices – organizations can significantly mitigate the risks associated with SAP customization. These steps are the building blocks to creating a foundation of trust and operational excellence that can transform an organization’s SAP customization from potential vulnerabilities into secure, efficient assets for the enterprise.
Turnkey stands ready to help you fortify your SAP system against potential threats and prepare for your S/4HANA journey. Contact us today at info@turnkeyconsulting.com.