In October 2018, Morrisons plc was held ‘vicariously liable’ for the illegal publication of the personal data of around 100,000 of their employees. The case goes back to 2014 when a senior internal auditor, Andrew Skelton, posted exported payroll data which included their names, addresses, bank account details and salaries. Andrew Skelton was jailed in 2015 for eight years, on top of which 5,818 of the affected employees won a subsequent court case seeking compensation for the distress caused direct from Morrisons, exposing the firm to ‘vast’ financial claims.

Since the introduction of GDPR all CIOs must perform a privacy impact assessment to show how personally identifiable information ( known as PII ) is collected, used and shared. Such a report cannot be created without examining access to, and use of, SAP Direct Table Access.

So what checks and monitors can we put in place within our SAP systems to mitigate us from similar breaches and fullfill the privacy impact assessment?

Direct Table Access via transaction codes SE17, SE16, or it’s more “enjoyable” version SE16N, remains the quickest and easiest way to export the information you need out of SAP and download it into something more familiar, such as Excel. Unfortunately we all know that once data is exported out of our systems then we no longer have any visibility or control over it. So why are we still granting so many users direct access to SAP tables?

Unfortunately we all know that once data is exported out of our systems then we no longer have any visibility or control over it. So why are we still granting so many users direct access to SAP tables?

Well, as every SAP user knows, reporting information out of SAP using ‘official’ business processes is often a challenge; writing queries is fraught with danger around potential performance issues; the oxymoronic “Quick Viewer” can be anything but; and getting ABAPs defined, written and transported into production by the busy technical team will often take too long. Against this backdrop you will have the pressures of ‘the business’ always having a compelling argument for some ‘urgent’ data requirement due to their monthly deadlines and/or important internal customers. This is why so many organisations take the path of least resistance and provide many of their users with the authorisations required to directly access SAP data tables.

Users with access to SE17, SE16 and SE16N can not only extract any data they like from any table, it also provides them with a window of opportunity to exploit back door access to those tables. This includes Human Resources, Payroll, Sensitive financials and Project information including salary based costings. The table PA0002 for example contains the employee’s full name along with their date of birth. Accounts Payable is often used for paying employee expenses which means an employee’s bank details would be available by looking directly at the vendor tables LFA1 for the employee’s name and LFBK for their bank details.

You should be especially aware of employees using SE16N to extract data as some levels of SAP do not even log what tables have been accessed using it so you won't even have an audit trail of which data was taken in the first place! 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.

You should be especially aware of employees using SE16N to extract data as some levels of SAP do not even log what tables have been accessed using it so you won't even have an audit trail which data was taken in the first place!

Best practice would therefore dictate that access to these transactions is removed immediately and replaced with a tightly governed Emergency Access process that provides short term ’power-user’ access only for authorised emergencies and that post-access audit trail reports are examined to verify that all activity was in line with the Emergency Access request.

Even if you cannot implement such a best practice in the near future then at the very least you should have real-time monitoring in place to alert you to the actual use, and ability to use, these transaction codes.

Grey Monarch

To find out more...

We can provide your organisation with a fixed-price Risk Assessment Consultancy Package where we will check for over 500 potential data and security risks including all of the risks indentified in this article. With our particular expertise in SAP then this is way beyond the checks that a typical external audit would examine within your SAP systems.

With ProfileTailor Dynamics it is possible to find out very quickly who is using any of these transaction codes, which tables they are accessing,and with what frequency, providing the insight required by the security team to enable them to remove this access completely.

If you would like find out more about how we can help in this area then please do contact us.

You can also share this page via the following buttons: