by Sükrü ilkel Birakoglu, Senior Director
The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from major card vendors. Of course, compliance standards such as GDPR cover name, address, and card details within SAP systems, but PCI DSS is the next level of compliance for cards. One of the requirements of this compliance standard is the protection of a cardholder’s data by the processor of this information – Water-tight access control to this information must be implemented in the information systems holding credit card information and access to credit card information must be monitored.
In SAP Systems, the credit card information of customers is also saved and used in further sales transactions. This imposes the risk of credit data theft and monetary risks if an external or internal attacker gains access to credit card information of customers in an SAP System.
The credit card information of customers is saved in different database tables in SAP Systems. VCKUN and VCNUM tables are just two of the most important.
Getting into the intricacies within SAP Systems, you can use the transaction code SE16 and its variants to browse through a database table of contents. If an attacker can compromise an SAP System using privileged users, they can gain access to the content of database tables via production systems too.
The following screenshot shows, how easy it is to display customers’ credit card information using transaction code SE16 with one button click in an SAP System, if you have the privileges in a production system:
Figure 1: Displaying Customers’ Credit Card Information using VCKUN database table contents
Take a look at the screenshot. The customer credit card information is displayed in an encrypted form on the screen. You can ask yourself the question: This information is encrypted, so how can a hacker use the encrypted information to obtain the credit card number? Which is a fair question.
Well, there’s a standard function module named CCARD_DENVELOPE in SAP ERP Systems, which is used to decrypt encrypted credit card information. A hacker can call this function module using transaction code SE37 or inject a simple ABAP Program to decrypt the credit card information.
Credit card information of customers is also shown in a masked format on customer master data transactions (e.g. Transactions XD02 and XD03) in SAP Systems. Even in this case, a hacker who has DEBUG rights can see the unmasked credit card information in debugger.
Figure 2: Displaying Customer’s Masked Credit Card Information in Transaction XD02
In a different scenario, a hacker can download list of credit card information for customers from the SAP System for further use.
These different scenarios should raise several questions in the mind of a security expert, such as:
- Is the correct access control (Segregation of Duties) implemented in an SAP System to protect credit card information from unauthorized access?
- Who is accessing credit card information and can the accesses be logged and displayed in an analytics tool, like a SIEM System?
- Do we know if someone has downloaded Credit Card Information from an SAP System?
- Did someone turn on debugging in a production system while using Customer Master Data transactions and does this person have access to credit card information screens in these transactions?
- Do we know if someone used transaction SE16 in order to display the content of tables VCKUN or VCNUM?
- Do privileged SAP Users (Firefighter accounts, DDIC*) have access to credit card information in SAP Systems?
- Did someone call critical function modules (e.g. CCARD_DENVELOPE function module) or programs that can be used to decrypt credit card information?
This list of questions can be extended and poses some points for critical thinking.
Let’s have a look at how our BCS for SAP solution integrated with the Logpoint Converged SIEM platform can help you to address these questions and eventually detect threats directed to credit card information theft from your SAP Systems.
BCS for SAP can check the SoD Violations in the SAP System based on the configuration within the solution and can then raise alerts in the SIEM if an SoD Violation occurs. That makes it easy to detect SoD Violations related to credit card information access.
Access to credit card information is part of our Read Access Log Configuration Package which is delivered as part of our GDPR Solution. Every access to credit card information using transaction SE16 and its variants or using XD* transactions are logged and passed to Logpoint SIEM Dashboards.
If a user downloads sensitive data from SAP System, like credit card information of customers, this action is logged using our Data Download Monitoring solution for SAP Systems and all related context information is again passed to the SIEM to create an alert.
Likewise, if a critical function module or program is called, these calls are being caught and passed to Logpoint SIEM for displaying on our dashboards.
If a user turns on debugging in SAP Systems for accessing sensitive data or if a privileged user executes suspicious activities, these cases are captured using BCS for SAP and UEBA for SAP Solutions.
In this simple use-case the security risks related to credit card information in SAP Systems have been explained in short and we have detailed how these threats with the orchestration of our BCS for SAP, Converged SIEM and UEBA can be leveraged to detect, mitigate and respond in the best way possible.