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:
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.
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:

As mentioned above, many of us are not aware of the backdoors. Apart from the SE16 and its variant tcodes, there are also programs and functions associated with the SE16 transactions such as RK_SE16N, RK_SE16D (a quick search will fetch 10+ ABAP programs) that should be delimited. Remember, users who have the SA38 authorization and the relevant table authorizations (S_TABU_DIS and S_TABU_NAM) have access to view data without having access to SE16 transaction codes:

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.

Have you heard about the SE16N_EMERGENCY transaction code? This powerful transaction code is introduced by SAP in the latest NetWeaver releases. If you don’t see it in your SAP system, refer to SAP Note – 2911103 – SE16N: Alternative edit mode SE16N_EMERGENCY and implement the corrections. This is a great transaction code (even for those who don’t have SAP GRC implemented) and brings one level of protection.

By default, the transaction is locked on first use. This is by design. It should be unlocked using the SM01_CUS transaction. When executed, it will provide SE16N in edit mode where your users can edit the table data.

Good thing is that it will prompt the user to enter a detailed explanation of the change and records the same for future review. This information can be found in table SE16N_CD_KEY. Look at the REASON field to determine the reason for the usage.

Some users still need to be able to access specific tables. It is okay to provide access directly to the users, especially when the risk is low. SAP allows you to create custom Z or Y parametric transaction codes and provide access to them to their regular IDs. However, ensure these tables are not included in &NC& table group. Assign them to the respective table groups and maintain them with S_TABU_DIS and S_TABU_NAM. Never limit the authorizations at S_TABU_DIS.

It is further advised to activate the security audit log for specific events. With this, you will be able to see who used a critical transaction and on which tables. I strictly recommend activating the logs for the below events:

DU9 – Generic table access using transactions es. SE16, SE16N, SM30, SM31, SM34, or SQV (Refer to OSS note 2041892)
CUZ – Generic table access by RFC to & A with activity & B

These logs can help you to evaluate the audit requirements further and restrict the authorizations based on the inputs.

Have you heard about SQVI and SQ01 queries? The main difference is that SQVI queries are user-based (i.e., queries created with this tool can’t be shared with other users) while SQ01 is based on user group based (i.e., group of users can access them using SQ03).

Both are considered as security-critical transaction codes. Further, SQVI requires S_TABU_DIS on every table that is used in SQVI. Just remember, if you have more than one company code, and multiple plants, and other entities, you will no longer be able to prevent your user from reading data from other organizational structures. It might further need access to SE16(N). Hence, limit this access.

ToggleNow’s UserSentry application has a unique feature that allows you to monitor the critical downloads from tables, transaction codes, or ABAP programs. It captures critical information such as the username, date, time, and terminal ID along with a copy of the file that has been downloaded by the user.
ToggleNow’s UserSentry application has a unique feature that allows you to monitor the critical downloads from tables, transaction codes, or ABAP programs. It captures critical information such as the username, date, time, and terminal ID along with a copy of the file that has been downloaded by the user.

Find out more about ToggleNow

ToggleNow’s FourEdge service is a unique service offering where our Subject Matter Experts will carry out a comprehensive Security (Risk) Assessment. Our experts will check for over 70 potential security risks that can be identified within your SAP systems including the ones identified in this blog. We go beyond the checks that a typical external auditor would examine with our automated tools.

With our tools, it is possible to find out the transaction code usage, tables that the users are accessing, the data that is being downloaded (a copy can also be maintained for further investigation), terminal from which it has been downloaded, providing insights required by security and audit teams to enable them to complete the audit successfully. If you would like to find out more about how we can help in this area, then please do contact us.
Leave a Reply

Your email address will not be published. Required fields are marked *

Receive updates on upcoming webinars, the latest case studies, and more directly in your inbox. Stay informed and connected by subscribing to our newsletter.

Raghu Boddu

Meet Raghu Boddu an expert in SAP Security and Governance, Risk, and Compliance (GRC). With over 20+ years of experience in the field, Raghu has a deep understanding of the nuances and complexities of SAP systems and how to keep them secure. Raghu has worked with various clients across different industries, helping them implement effective security and GRC strategies to protect their sensitive data and meet regulatory compliance requirements. Raghu is a respected thought leader in the SAP security and GRC community, regularly sharing insights and best practices through presentations and publications. Whether you’re looking to improve the security of your SAP system or ensure compliance with relevant regulations, Raghu can provide the guidance and expertise you need to succeed.

Explore our success stories

A case study on analyzing Custom Transaction codes and updating the Risk Ruleset

In today’s dynamic business landscape, many SAP customers leverage custom transaction codes to streamline operations and enhance efficiency. However, with customization comes responsibility, as it introduces risks such as segregation…

How we helped businesses succeed by providing them with innovative and effective solutions to manage risks

In today’s business landscape, managing SAP systems can be challenging. Many companies struggle with Segregation of Duties (SoD) conflicts and irrelevant transaction codes, making audits cumbersome and increasing the risk…

Case study on SAP Licensing Optimization

Today’s business environment requires the efficient management of SAP licensing, though it can be challenging. This problem can be resolved by Optimus for SAP Applications, developed by ToggleNow, by offering…

Learn how we can help you and your enterprise through the GRC transformation journey. Choose the appropriate option and fill out the form. Let’s get started!

Product demo

Explore our range of SAP Access Governance products.

Detailed Discussion

Engage with our SMEs regarding any challenges in Access Governance.

Partnership Discussions

Interested to be part of ToggleNow partner network? Let’s discuss!