Why debugging in productive SAP systems is an endless source of security risk
Debugging in critical SAP systems is one of the easiest ways to gain full control over an #SAP system. A user with debugging and modification authorisations should be treated as a permanent threat to SAP security. But what exactly is debugging, and how can it become a threat?
What is debugging?
Many of us remember the scene in which Neo learns to move at bullet speed, to control and halt events, and to manipulate his surroundings at will - this is a fairly accessible way of describing what debugging is: identifying and fixing bugs, defects or faults in software by executing code line by line. This is a fundamental programming activity, also used in test environments when the source of an error is not obvious. Software operates as a sequence of variables that change their values. Debugging involves controlled, step-by-step, command-by-command execution, allowing developers to analyse control flow and values dynamically. To debug a program, users need the appropriate authorisations. These authorisations belong to the development domain and, although commonly granted and used in development and test environments, granting debugging authorisations in production systems must be treated with due caution. In this article, we discuss the key considerations and recommendations regarding permitting live debugging in production systems.
What does this look like in the SAP world?
The world of SAP software may not be as spectacular as the Matrix, but it too consists of a series of events and flows: hiring employees, orders, invoices, marketing campaigns, online sales, maternity leave, goods movements and so on. In fact, it is hard to find a real-world transaction that could not be recorded in an SAP system (at this point one might wonder whether real-world events actually happen in the world and are merely recorded in SAP, or whether they happen in the software and we act accordingly. But that is certainly not a question for this article 😎).
It is worth asking what risk is associated with permitting live debugging in production systems, and what threat this can pose. Consider the following cases:
-
Service availability disruption: system resources are not unlimited, and debugging errors are easy to make. Poorly managed debugging in a production system can cause a service outage, making the system unavailable to other users. For example, it is easy to lock numerous tables, transactions, work processes and so on.
-
Vulnerability to attack: debugging in a production system provides access to control flow and data, including authorisation checks. A simple change to a variable’s value can mean the difference between display mode and edit mode, so bear in mind that you are accessing a screen with your own user’s authorisations.
-
Arbitrary data manipulation: live debugging in a production system can also involve real-time changes made immediately before interaction with the database. If you can freely manipulate all read and write interactions with the database, the possibilities are almost unlimited.
-
Impact on company reputation: even if an organisation is not concerned about any of the risks listed above, that lack of concern can affect partner trust, ultimately leading to the suspension of all cooperation with the organisation. Admittedly, most cases of live debugging are simply users trying to complete their work, but the role of security officers is to enable business processes to develop while minimising risk. And the risk associated with live debugging in production systems will always be critical.
Does this mean live debugging in a production system should be strictly prohibited? Not necessarily. There are situations where debugging in a production system may be acceptable - for example, when it is impossible, or very costly, to reproduce a problem that occurs only in the production environment.
Although such reasons can justify granting debugging authorisations in a production system, the solution will always be disproportionately broad. Granting full control over data and control flow for an unspecified group of transactions, in response to the need to reproduce one particular sequence, will always be an excessive measure. In other words, live debugging in a production system always carries critical risk.
How to minimise the risk
It is possible to accept the risk of granting these authorisations in a production system, whether temporarily or permanently, but if you decide to do so, treat it almost as though you were granting full control authorisations. In such cases, intensive monitoring of all interactions is essential. In any case, debugging in a production system must be strictly controlled; this cannot be achieved through an access-control tool or authorisation review alone. It is therefore necessary to establish an automatic alerting mechanism, ideally compatible with mobile devices, that notifies you when users begin debugging in the production environment. This is exactly one of the use cases implemented in the SecurityBridge threat detection solution.
In summary, live debugging in production SAP systems can be a source of serious security risk. Although there are situations in which debugging in a production system may be necessary, appropriate precautions should always be taken and such activity should always be controlled. Implementing an automatic alerting system is one way to monitor live debugging and minimise the associated risk.
What comes next?
If you do not have control over debugging in your SAP environment, or are unsure how to approach this, SNOK’s specialists can help. We will review your current configuration, procedures and assigned authorisations, and ultimately implement software that notifies you in real time whenever SAP security standards have been breached.
Be like Neo - control your environment 😎 and get in touch: office@snok.ai