This is a statement that I often hear: "SAP traces everything". 

But is it actually like that? Can I really ensure an activity tracing and find out who did what in the system? Or are there any methods to bypass these logs?

What are logs in SAP and why are they so important?

We could metaphorically refer to our fingerprints. In fact, every object or surface we touch we unintentionally leave traces behind.

These traces can be analyzed to obtain a specific identity. Here, while a fingerprint is difficult, if not impossible, probably at the moment, to disguise, in computer systems, this aspect may not be so robust.

Logs are actually traces of all (we will see later what actually) actions that a person (in technical jargon a user) has performed within the system. If we are talking about a management system, for example SAP ERP, a purchase order, an invoice, an accounting document, and so on.

The degree of logging and the types of these logs, are defined by the system itself. If a given system does not provide a logging mechanism, clearly it is not possible to have these traces. For example, for detective or forensic analysis.

SAP has an excellent logging mechanism. Be careful, however, it does not mean that it tracks everything. So this statement is not technically correct. But I consider it nonetheless, colloquially valid.

Why doesn't it track everything? For several reasons, such as the following:

• There isn't always a necessity to have these traces
  • Does it make sense to trace changes that happen when a user modifies its own personal settings (for example printing on a device or on another?) maybe not. While if a user edits an accounting document, obviously yes. But also in this case it doesn't necessarily mean that any edit should be traced, maybe some informations of an accounting document are not so relevant.
• Why is it a cost to track everything anyway?
  
  • For the system that has to trace (performance)
  • For data that need to be archived (storage). The two opposites. If I trace everything I will have to manage a very large archive, if I do not trace anything I will not have this problem (but obviously I will have other problems in cases of retrospective verifications, having nothing available)

Mind you, in SAP systems there is, to ensure business continuity, separation between environments. That is, there is a system called the development system, a test system and finally the production system.

This is because clearly in the production system, changes should be made only if they are tested (it is the mechanism of SAP transports that allows a change made in development to be moved across systems, without having to replicate it manually). Especially changes to the configuration of the system itself.

So in this case in fact there are two different types of logs.

• Logs of actions that occur directly in the production system, and here are many families of example logs:
  
  • SAP Audit Log (must be activated)
  • SAP Change Log (active by default, on specific tables)
  • Table change Log (must be activated)
  • Application Log (active, in some cases it must be explicitly activated)
  • System Log (active by default)
• Logs of actions that have been done in the development system and then transported in the production system
  • Transport Management System

SAP and the security by default (Security By Design or Security By Default)

SAP is gradually adopting this approach, i.e., releasing its software, which is installed at customers' premises already properly configured from a security standpoint (thus including the trace and logging aspects of the system).

However, the process is still a long one, as many functions (including many related to activity tracking), in the past were not  active by default (in some cases they still aren't).

This implies that among all the possible log mechanisms that can be activated, some are not, from the outset. This aspect clearly needs to be, during installation or management of the system, defined with the customer himself.

A provider can clearly propose to activate some of these services that are turned off by default, but there has to be a willingness and ability to be able/need to manage them afterwards in the correct way.

But then if I activate all logs can I rest "assured"?

Here is one more aspect that deserves some consideration. If you read our contents, you know that the term SAP Security, a niche of all aspects related to SAP systems, is actually a small world. Formed of many facets.

Being "assured," then, is not so easy to achieve. Granted, in computer security in general, it is difficult to be sure that a system (especially a complex one) is totally free of weaknesses.

There are many aspects to consider. If you have fixed the data protection and tracking part in the application part, you can't forget about the database aspects (i.e., what "lies underneath" the application part) as well as you have to protect the information communication aspects and so on.

Last but not least is the aspect of customizations. In fact, these can often represent gaps. That is, the development of customer-specific functionality (outside the SAP standard) that nevertheless does not cover tracking mechanisms. Thus any actions performed through these functionalities would not inherit the standard tracking mechanisms (unless explicitly included).

But what about the super user or administrators?

Are they included in what said above or are they "exonerated"?

In this article "System Administrator" we addressed this topic. That is, how can I track "all" actions performed by these types of users. Mind you, once again, I have to figure out which logs are active (otherwise no tracking will take place)

Just as it is important to know that those who have administrative access to the system can in fact also delete the traces. Unfortunately, it is possible; in fact, there are (entirely lawful) tools that can be used specifically to erase logs (clearly for retention purposes, so having reached the archiving time limits these can be destroyed).

Hence an administrator could clearly misuse these tools, it might be all the more reason to implement segregation of duties policies even among system administrators (Segregation Of Duties)

Potentially, in some cases, erasing log traces (as we saw in this further article related to an administrative feature of the system called SE16).

How could I partially protect myself? For example, by activating additional log and event correlation mechanisms/systems called SIEM.

In this case selected logs (usually the most critical ones) would not only be recorded in the SAP system (where they could be deleted lawfully or even unlawfully) but also sent to a third-party event correlation system.

In this case, the eventual administrator would not only have to lose his tracks in one system but act on different systems. Thus more complex.

In other words, we must try to make it more complex to be able to "erase" one's tracks. But this still requires considerable investment, not only in technological aspects but also in process and organizational ones. These in my view determined through thoughtful risk assessment.

Are there additional devious cases?

What do I mean. A bad habit, fortunately not very common, of sharing users or having a user shared by several people.

In these situations, clearly, many of the active logs in the system may be less effective. If a user in my name were shared with other people, in this case the system changes would still appear to be in my user's name, but in reality not performed by my person.

Here, unfortunately, the organizational and accountability model aspect of the company is even more important than the purely technological aspects.

Technology, in fact, cannot be decoupled from the organizational and staff training aspects. Although there are ways to (in some cases) notice these types of behaviors it may not be so easy and immediate.