Close

HAVE QUESTIONS?

Contact us today.

Subscribe me to your mailing list

GDPR for SAP: How to find personal data and assess privacy risks?

Numerous organizations, which implemented SAP products, have a large backlog of measures needed to establish secure information processing. SAP systems are so complicated and mission-critical that many IT professionals consider unsafe but functioning SAP systems as an upbeat state of affairs.

The forthcoming GDPR will disrupt the status quo and force CISOs to implement data privacy controls in SAP systems. This article is intended to contribute to the improvement of security of existing SAP systems and data handling to meet GDPR requirements.

In the article ‘GDPR Explained: What are the Security Requirements?’ we have identified the three groups of security requirements:

  1. Assessing existing data processes and systems.
  2. Restricting personal data processing.
  3. Monitoring data breaches.
GDPR Security TasksGDPR Security Tasks

The first group of tasks is related to the understanding of your SAP systems, data, and processes.

According to the regulation, we have to identify personal data in our SAP systems, find users that have access to it, evaluate the effectiveness of implemented security controls, and assess risks to data subjects on the basis of the information received.

Legitimate users gain access to the information and functions of SAP systems via SAP tables, or transactions, RFC functions, web services, and other methods that work with corresponding SAP tables. Therefore, we have to find personal data related at least to the SAP tables.

Identify data items in SAP

The most straightforward way to find SAP tables storing personal data is to consider standard global master tables:

  1. External entities:
    • Customers: KNA1, KNBK, KNVK
    • Vendors: LFA1, LFBK
    • Addresses: ADRC, ADR2, ADR3, ARD6
    • Business partners: BP000, BP030
    • Users: USR03
    • Credit cards: VCNUM
  2. Internal entities (HCM infotypes):
    • 0002 Personal Data
    • 0004 Challenge
    • 0006 Addresses
    • 0009 Bank Details
    • 0021 Family
    • 0028 Internal Medical Services
    • 0094 Residence Status

Beside these typical SAP tables, there are plenty of others with personal data, let alone custom SAP tables. To find them all and prepare a list of personal data items, run reports Where-Used List for domains related to the personal data.

You can try searching for key words like “person”, “name”, “customer”, etc. Finally, you will see which tables in your SAP system contain personally identifiable information and prepare a complete list of such tables.

Find SAP users having access to personal data

Once we have found the locations of the personal data, we need to understand who has access to it. Legitimate SAP users access information storing in tables with help of transactions and reports. How to find them?

First, there are well-known transactions that are used for maintaining customers (FD02), vendors (FK02, M-01), addresses (VCUST), business partners (BP), users (SU01, SU10, SUGR, PA30) and credit cards (PRCCD). So, we can simply filter users having the S_TCODE authorization to run transactions of our interest.

Second, there is a way to detect transactions working with tables identified in the last step:

  1. Search for the programs that use tables containing personal data (SE80\Repository Information System\ABAP Dictionary\Database Tables)
  2. Find the transactions related to the program (SE80, or table TSTC)
  3. Find the users having S_TCODE authorizations to run the transactions

Then we’ll identify users with legitimate access to the personal data storing in SAP tables.

Evaluate SAP security controls for GDPR

This task is necessary for two reasons. First, Article 32 of GDPR requires regular testing and evaluating security measures. Second, evaluation of security controls is a step of Data Protection Impact Assessment (DPIA). The effectiveness of security controls influences the possibility of data breaches in the SAP systems and the magnitude of the harm resulting from events.

Below are the main categories and examples of technical checks we use to assess SAP systems.

Authentication

  • Password policy
  • Privileged users
  • SSO checks

Monitoring

  • Log settings: security audit log, system log, gateway, HTTP, SQL logs, etc.
  • CCMS settings

Access control

  • Assignment of authorization groups to tables and ABAP programs
  • RFC authorization checks
  • Unblocked critical transactions (SM59, SCC5, SM32, etc.)

Encryption

  • SSL options
  • SNC options

Insecure configuration

  • Gateway, RFC, ICF, MMC, GUI, Web Dispatcher, etc.

List of connected systems

  • RFC, DBCON, HANA, XI, etc.

It’s completely impossible to recognize and investigate the personal data breach if the logging is not configured. Fraud and sabotage are an issue of “when” if all users have the SAP_ALL profile assigned. Similarly, the loss and destruction of personal data are likely to happen in SAP systems without the latest patches and Security Notes implemented.

Thus, the assessment of all SAP security controls, not just users with access to critical transactions, allows us to understand the weak points of the system.

Assess risks to data subjects

Assessing risks to data subjects is used for the prioritization of security controls.

The regulation requires assessing the possible consequences for data subjects if their personal data is disclosed, modified, or destructed and lost in your SAP system. The crucial point is that we assess the consequences for data subjects, not a company processing data. However, penalties for non-compliance resulted in a data breach, reputational damages, and sanctions against officials can engender fallouts by themselves, from an organizational point of view.

Assessing risks to data subjectsAssessing risks to data subjects

An extent to which data subjects are threatened by a potential data breach is typically a function of:

  • the adverse impacts that would arise if the personal data loses confidentiality, integrity, and availability in SAP systems,
  • the likelihood of the events.

Impacts

First and foremost, assess impacts to data subject on the assumptions that personal data:

  • would be disclosed (lose confidentiality)
  • would be altered (lose integrity)
  • would be destructed (lose availability)

Considering these impacts requires joint efforts with departments such as HR, legal, financial, etc. Usually, the risk identification procedure is performed in the following way:

1) understanding sequences of events (scenarios), given the breach is occurred using questionnaires
2) assessing consequences of the scenarios using standard scales (e.g. health, legal, financial, reputation)

As a result, we understand consequences of the anticipated data breach.

Likelihood

The second task is to recognize possible catalysts for a data breach and estimate its probability. The major causes of breaches are weaknesses in security controls, vulnerabilities, predisposing conditions, and perceived fraud opportunity.

Therefore, to likelihood is usually estimated as a combination of the following factors:

  • a list of vulnerabilities: misconfigurations, code weaknesses, SoD conflicts, etc.;
  • the effectiveness of security controls measured at the previous step;
  • the predisposing conditions: connectivity, use of legacy technologies, deficiencies in system backup and other mechanisms;
  • the perceived fraud opportunity: a number and type of assets (e.g. personal data, financial information, R&D insights, market plans) in SAP systems.

In order to understand SAP operational risks, we have to thoroughly examine this information and infer the possibility of data disclosure, alteration, and loss.

To make things simple: if the security logs are disabled, the data is transmitted on the unencrypted channels, all users work with SAP_ALL roles, and an SAP system is connected to the banking system, risks for data subjects are extremely high. That is due to the high value of payment information for potential adversaries, the attack might be inconspicuous and it does not require great deal of expertise.

Conclusion

Assessing data processes provides a basis for the GDPR security implementation in SAP. This is the most important step, letting you evaluate risks of personal data processing and develop a range of option for their mitigation.

We offer the special solution for assessing risks and processes for GDPR compliance. During the service provision, we examine SAP systems, assess the effectiveness of security controls, provide remediation guidelines, and recommend security measures to protect the personal data.

In the next article, you will learn how to prevent a data breach and restrict access to the personal data and also grasp the data processing in SAP systems.

Do you want more?

Subscribe me to your mailing list