Why debugging in production is an infinite and permanent source of SAP Security Threats
Debugging in critical SAP systems is one of the easiest ways to get complete control of an SAP System. A user with debug and change permission should be considered as a permanent risk of SAP Security Threats. But what is debugging, and how can it be exploited and become a Threat?
What is debugging?
More than one will remember that stage in which Neo learned to move at the speed of the bullets, to control and later even stop events and manipulate the environment arbitrarily.
There are many ways to define debugging, but this one has worked for my children. We could say that debugging is related to identifying and correcting software errors, defects, or bugs, executing the code line by line. It is a fundamental development activity and is also used in test environments when the origin of a bug is not obvious. The software operates like a sequence of variables interchanging their values. Debugging occurs in controlled execution, step by step, command by command so that developers can analyze the control flows and values dynamically. To debug a program, users require specific permissions. These permissions belong to the development domain, and while they are widely granted and used in development and test environments, assigning debugging permissions in the production systems must be done carefully. The following blog covers critical considerations and recommendations when allowing debugging activities in production (a.k.a. live debugging).
How does this translate to the SAP world?
The world of SAP software may not be as spectacular as the Matrix, but it is still a series of events and flows: employee hires, purchase orders, invoicing, marketing campaigns, online sales, maternity leave, merchandise movements, etc. In fact, it is pretty hard to think of any real-world transaction that can’t be recorded in an SAP system (At this point, one might wonder if world events happen in the world and are only registered in SAP, or if they happen in the software and we behave accordingly. But certainly, this is not a question for this blog).
But it is appropriate to ask ourselves about the risk of allowing live debugging of productive systems and what risk it could represent to permit debugging in production systems. Let us consider the following cases.
- Service interruption: system resources are not unlimited, and it is easy to make debugging errors. If not handled correctly, debugging in production can interrupt service and make the system unavailable to other users. For instance, you can easily block multiple tables, transactions, work processes, etc.
- Security vulnerability: Debugging in production gives you access to the control and data flow, including validation and verification of permissions. A simple change of a variable can mean the difference between a display and edit mode, so consider that you are accessing your user permissions “screen.”
- Arbitrary manipulation of data: live debugging in production may also imply runtime changes just before interacting with the database. So, suppose you are free to manipulate all interactions with the database for read and write actions.
- Impact on company reputation: even if the organization is not interested in any of the mentioned risks, this lack of interest could affect the confidence of your partners, ending by suspending all interaction with the organization. It is true, most of the time live debugging means users simply trying to finish their work, but in the role of security officers it is to allow the development of business processes minimizing the risk. And the risks associated with debugging activities in production are always critical.
Does this mean live debugging in the production system should be strictly prohibited? Not necessarily. There are situations where debugging in production could be acceptable, for instance, when it´s simply not possible or extremely expensive to reproduce an issue that only occurs in a production environment.
But while these kinds of reasons would justify assigning debugging permissions in production, the solution will always be oversized. Giving complete control permissions over data and control flow for an indeterminate group of transactions as an answer to the need to reproduce a specific sequence will always be an oversized measure. In other words, live debugging in production always involves critical risk.
How to minimize risk?
It is possible to accept the risk of temporarily or permanently assigning these permissions in production, but if you do, consider this almost a full control permission assignment. In such cases, intensive control of any interaction is necessary. In any case, debugging in production must be strictly observed; this is not possible with an access control or permissions evaluation tool. Therefore, an automatic alert mechanism, ideally mobile-friendly, should be set to inform us when users start debugging in a productive environment. And this is precisely one of the use cases implemented in our Threat Detection solution.
The detection of debugging in production systems is one of the use cases of Protect4S Threat Detection solution. If you want to discover other threat risk cases, don’t hesitate to contact us.
For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn and our YouTube channel!
