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.
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.
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:
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.
Find out more about ToggleNow
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.