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?

Image

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:

1 - Remove wider access in roles

2 - Deactivated Edit functions

3 -Delimits authoriization to RK_SE16* programs

4 - Remove Debug access from the regular access

5 - User SE16_EMERGENCY

6 - Use parametric transaction codes

7 - Enable audit logs for critical events

8 - Control SQVI transaction access

9- Use ToggleNow's application to monitor critical tables

10- Use ToggleNow's Easy Access solutions to restrict authorizations

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

#SAPAuthorizationredesign

#SAPAuthorizationReview

#SAPAuthorizationDesign

#SAPRoleDesign

#SAPsecurityroledesign

#SAPsecurityaudit

#Audit Management

#SAPAuditServices

#SAPAuditManagement

#SAPSODAnalysistool

#SAPSODAnalyzer