<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

SAP’s Usual Suspects: Custom Programs and Transactions

The next set of culprits in our series of SAP's Usual Suspects, Custom Programs and Transactions, can introduce a variety of risks in your SAP environment, even though most times they are undetected or even unmonitored. These culprits are often the result of poor coding practices or lack of governance resulting in:

  • Code Vulnerabilities
  • Impact on Overall System Health and Performance
  • Table Maintenance and Data Privacy Issues
  • Missing Authority Checks
  • Excessive or Unintended Access
  • Segregation of Duties (SoD) and Critical Access Violations (often undetected or unmonitored)

Code Vulnerability

The primary focus of this blog will be on the application access risks often introduced by custom code, but it is important to quickly highlight other risks and impacts associated with customizations. Custom programming is often a requirement to perform tasks unique to your business or processes. It can be just as common for your ABAP programmers to overlook certain pitfalls in their code, leaving the code open to exploits, such as SQL injections, loops that can impact system performance, and insert statement vulnerabilities.

blog-sap-usual-suspects-05-customization-01-insert-error-ss

Figure 1 – Example of an INSERT statement where a program is directly inserting in VBRK

In the example, a program is directly inserting into VBRK which is the billing document header. This can result in issues within the workflow and doc flow in SAP. It is imperative to incorporate key design principles and review processes for custom code in your SAP environment. Limiting the use of INSERT, UPDATE, and DELETE statements should be one of those focal points. This can be performed manually utilizing native SAP programs such as RS_ABAP_SOURCE_SCAN via SA38 to scan for defined strings or text such as “INSERT”.

Other examples of risks consist of leveraging SM30 parameter tables and the use of LOOPS. Parameter tables could be leveraged by programmers to store access and bypass security. These tables can be called dynamically and completely undetected. The use of LOOPS may not pose an access risk per se, but the impact to performance could bring your production environment to a screeching halt. Anyone who has programmed with loops has more than likely made a mistake resulting in an endless loop.

Managing Access Risk with Rulesets

The backbone to managing and monitoring access risk within your SAP environment is a defined Segregation of Duties (SoD) and critical access ruleset. To accurately assess this risk, your segregation of duties and critical access ruleset should:

  • be tailored to represent your organization’s risk universe,
  • align with your organization’s risk appetite and strategy,
  • span across multiple applications and interconnected systems along with business processes,
  • consist of custom transactions, applications, and related permissions,
  • follow governance processes for maintenance and periodic reviews, and
  • be reviewed with your audit partners

While we could do entire blog on the ruleset alone, the key focus here is to include customizations.

Continuous Governance and Access Risk Monitoring

Establishing continuous governance and monitoring processes will be key to the success of managing risk with custom code. At a high-level, organizations should:

blog-sap-usual-suspects-05-customization-02-governance-n-monitor

Establish a Framework for custom code, documenting design principles, review processes, migration and testing requirements, as well as ongoing risk monitoring processes.

Identify, Evaluate, and Document the population of custom transactions and applications. Capture metadata related to the customization, authorization checks, process area, the reasons why the customization is required, etc.

Security and Compliance should be considered by ensuring authorization checks are documented and reflected in SU24 tables, functionality is placed in alignment with the security architecture and role design, and the segregation of duties and critical access ruleset(s) are updated accordingly.

Ongoing Risk Management should consist of periodic reviews for customizations and corresponding processes. This is in addition to our normal periodic access reviews and diagnostics.

Tips to Catching the Culprit: Custom Programs and Transactions

  • Establish Governance and Controls
  • Perform Code Reviews Prior to Migrating
  • Define Positive and Negative Testing Requirements
  • Incorporate Customizations into Security Architecture and SU24
  • Ensure SoD and Critical Access Ruleset Includes Customizations
  • Perform Continuous Governance and Risk Monitoring

How Fastpath Can Help Apprehend This Culprit

Fastpath SAP Code Checker – Fastpath can automate the process of reviewing every line of custom code. The SAP Code Checker examines every Z and Y package in the system and based on the coding, will make recommendations on where that should reside in your ruleset. Simply click the + button to approve the recommendations and automatically update your ruleset.