Data protection in SAP systems is among the most urgent security tasks in the financial sector. However, tests at various financial institutions have uncovered serious vulnerabilities in SAP Basis administration.
BY THOMAS KASTNER, VIRTUAL FORGE
Pressure on financial services providers to also protect their SAP data from unauthorized access continues to grow as a result of the stricter minimum requirements for risk management set out by the German Federal Financial Supervisory Authority (Bundesanstalt für Finanzdienstleistungsaufsicht – BaFin) in its 2016 amendment to the Minimum Requirements for Risk Management (MaRisk) and the EU General Data Protection Regulation (EU-GDPR), which will take effect in 2018. According to a study conducted by the Ponemon Institute, this sector is expected to have to pay the most when it comes to the consequences of data breaches. For example, a breach of customer data could bring costly claims for damages if cyber criminals have accessed something like checking accounts. In one case, the British Tesco bank was forced to reimburse around 2.5 million pounds to its online banking customers after funds were stolen during attacks from hackers. Financial damages are usually compounded by a tarnished reputation.
Hackers with malicious intentions are not the only cause of undesired data leakages: another source is a company's own employees, for example administrators of SAP business applications and SAP systems. While access rights, for example for SAP Basis administrators, should be restricted for data protection and compliance reasons, this is often not what plays out in reality. During SAP security testing at financial institutions, vulnerabilities allowing SAP Basis administrators sweeping opportunities for accessing sensitive customer data were identified.
Loopholes in DBACOCKPIT and DB02
The vulnerabilities were discovered in DBACOCKPIT and DB02, two core transactions used to monitor, control, configure, and manage SAP databases. SAP Basis administrators use these transactions to execute numerous basic functions, such as checking the system status and system processing types, table analyses, or index maintenance and index updates to tables. Both transactions also include the SQL Command Editor, which permits the use of Open SQL commands to directly access functional tables. Specifically, this could allow access to business-critical information, including HR and financial accounting data, or password hashes.
SAP provides a large number of security patches for the SQL Command Editor. Adhering to and importing these patches is crucial. To control access to SAP data, SAP has additionally delivered a new authorization (S_TABU_SQL). Financial institutions can use it to define which employees are allowed to access SAP data. In addition, SQL Command Editor has a tracking function that logs every command, whether authorized or not. If this log data is transferred to an SIEM system (Security Information and Event Management) and then analyzed, companies can obtain an overview of all attempts to access the data. Monitoring and alerts can allow potential misuse to be prevented in time.
Encrypted passwords cracked
However, if the required security updates have not been applied to the SQL Command Editor, the effects may be severe, as shown by SAP Penetration Tests performed by Virtual Forge. After testers successfully read the USR02 table – which contains encrypted passwords – in the database of an SAP system, they were able to crack the passwords with a password cracker tool. The testers then logged on to the SAP system and easily accessed the same functions for which the individual users were authorized. Malicious attacks potentially could have completely compromised the SAP system, which would have far-reaching consequences, particularly for companies in the financial sector.
To prevent this, companies using SAP should regularly import the Security Notes for the SQL Command Editor. In addition, the recommendation is to upgrade at least once a year, making sure to implement the current Support Packages that SAP provides to customers for error correction and legally required software adjustments.
Using expert, specialized service providers
In practice, however, most financial institutions do not have any internal SAP security teams. This is why the recommendation is to give the task of regular security patch updates to a specialized service provider that combines both the necessary security and SAP expertise. In particular, the service provider should be experienced in implementing SAP patches, understand different SAP releases and upgrade procedures, and be skilled in threat detection and threat prevention.
The consulting partner should help customers to evaluate how critical the security patches are and to select the necessary tests to ensure that program and application errors do not arise when patches are imported. Because the selective checks take the place of expensive regression testing, customers save time and money.
Scanning SAP system configurations for errors
To supplement this, preventative tools for detecting and correcting errors can be used in customer-specific SAP system configurations. For example, a tool such as the SystemProfiler from Virtual Forge can determine all users that have comprehensive authorizations for executing the SQL Command Editor (DB02, DBACOCKPIT) and the associated table authorizations(S_TABU_SQL).
If the customer has linked its SAP systems to the SAP Solution Manager, these tools can automatically detect vulnerabilities and weaknesses. This makes it possible to regularly check all SAP systems as to whether all the necessary security patches that fully eliminate the vulnerabilities in the SQL Command Editor have been imported.
This article was originally published in German at it-finanzmagazin.de