Data protection vs SAP Direct Table Access! Are you exposed?

Data Protection

In October 2018, Morrisons was forced to pay compensation to an employee when the employee’s personal data was published illegally.

In April 2019, Facebook mentioned that two datasets from Facebook apps had been exposed to the public internet and 533 million users’ data was exposed.

In November 2019, the Alibaba Chinese shopping website mentioned that a developer working for an affiliate marketer scraped customer data from the website, including usernames and mobile numbers.

In 2021, LinkedIn was the victim of a data breach, and the information of 700 million people was leaked on the dark web.

These are just a few! According to a recent survey, 88% of organizations do not have a sustainable governance program to enable effective cybersecurity and compliance management for their business-critical applications, processes, data, and people.

The annual cost of cybercrime has risen by 72% over the past five years and the average cost of a breach now stands at $3.62 million.

Companies that run SAP systems are vulnerable to attacks, and the potential damage could be devastating.

In this blog, I’m going to focus exclusively on data protection in SAP systems. I’ll cover other topics, such as implementing GDPR and data protection controls across the organization in my subsequent articles.

Before I start with the detailing of the topic, let me ask a question.

Do your users have access to data via transaction codes SE16 (or its variants such as SE16N), SE17, or SM30 transaction codes? How are you restricting the access?

Direct Table Access via SE16, SE17, or SM30 (either directly or via custom transaction codes), remains the quickest and easiest way to access table data, and most business users prefer it to have. The key authorization objects to restrict the data are S_TABU_DIS and S_TABU_NAM which have only two activities i.e., 02 (Maintain) and 03 (Display). Users with access to S_GUI authorization (which is assigned in the common/general role) will allow users to export the data out of SAP and download it into something more familiar, such as Excel. Once data is exported out of your system, then you will no longer have any visibility or control over it.

So, what is the best way to handle this risk?

There are a lot of ways to secure your data, and here are 10 of the recommendations that we recommend you take as a first step:

Recommendation #1 - Remove wider access in roles

The first step is to identify the existing roles that give authorization to transaction codes such as SE16 (and other variants), SE17, and SM30. Replace them with a tightly governed process such as Emergency Access and provide the access for the short term only for authorized emergencies, coupled with post-access audit trail reports. Even if you have implemented such a tightly governed process, remember there are still chances that your data can be exported by the users. You should be especially aware that SAP does not log the tables that users have accessed (maybe not all of them unless the table logging is enabled) using these transaction codes and won’t even have an audit trail of which data was taken in the first place! As mentioned, transaction code SM30 is even more dangerous as it could give users access to maintain any tables directly, such as adding, deleting, or changing the data. So, go through and implement the other recommendations too.

Recommendation #2 - Deactivated Edit functions

With SE16N transaction code, SAP included an option called as &SAP_EDIT using which users will be able to edit the table contents. By default, this option is activated. It is highly recommended to deactivate this functionality that will stop users from changing the table entries. To disable, execute the program- RKSE16N_EDIT and select “Deactivate Editing Functions” as shown below:

Recommendation #4 - Remove Debug access from the regular access

Furthermore, if the user has debug permissions (S_DEVELOP authorization object being edited) it is possible to make changes during run-time. Hence, DEBUG access should be limited only through Emergency Access. Authorization object S_DEVELOP with Object Type DEBUG and Activity “*” should be completely removed from the users. Please note, activity “02” is for the replace function in debug mode and “01” is just about the most powerful authority in the whole system, i.e., system debugging. Removing this access will ensure your users can’t make any changes during the debugging or explore ways to extract data from the SAP system.

Read more: https://togglenow.com/blog/data-protection-in-sap-systems/

#sap role design best practices

#sap security role design best practices

#sap security role design document

#role design in sap security

#sap role redesign

#sap role design

#sap security role redesigning

#redesign of sap authorizations