Cybersecurity—Malware Protection at Application Level with SAP VSI

The number of attacks on SAP applications is steadily increasing. Although SAP is not explicitly mentioned in the relevant press and social media articles on security incidents, anyone who can read between the lines will quickly realize that the "ERP application" that was compromised or the "HR system" that was attacked was most likely an SAP application. It was to be expected that the frequency and success rate of attacks on enterprise ERP applications would increase. After all, these represent the "data crown jewels" of many companies and the expected "loot" justifies the investment in the development of specialist SAP knowledge from the attackers' point of view. It is therefore not surprising that "SAP cybersecurity", as a discipline that deliberately sets itself apart from the classic SoD, role and GRC-focused "SAP security", now has a permanent place in the programs of all relevant SAP events and publications.

SAP cybersecurity is a complex topic with numerous components that have interfaces with classic infrastructure security (OS, network), but also with the aforementioned security of business logic and GRC aspects. One of these facets is protection against malware and other dangerous content in files that are processed as attachments in SAP applications. In the following, we will look at five reasons why this protection is essential if your application processes files and attachments:

Reason No. 1: SAP recommends the use of VSI

Since its first publication in 2016, the "Security Guide for S/4 HANA" has included an entire chapter dedicated to the topic of virus scanning. It explicitly states that the use of a VSI 2.x-capable virus scanner is recommended. SAP S/4 HANA code calls the scanner via a dedicated interface (VSI, the SAP Virus Scanning Interface) at various points during processing, e.g. during upload, download or when passing through the gateway. 

Although SAP still refers to the interface in question as the "Virus Scan Interface", the current version 2.1 of the interface has been expanded into a comprehensive "Content Scanning" interface. SAP recommends three types of scan in the Security Guide:

1. Signature-based malware detection: For the detection of malware that is not executed, signature-based detection is still the preferred technique, with high detection rates and very high performance.
2. MIME type recognitiong: This refers to the filtering of file transfers on the basis of the content of the transferred files and not - as is usual in the SAP standard - solely on the basis of the extension of the file name.
3. Detection and blocking of active contentActive content is content that is embedded in files and is executed when the files are displayed or processed. This includes, for example, macros in Office documents, but also JavaScript in PDF, XML and image files, scripts, MS Silverlight, XSLT, OLE, DDE, etc.

Reason no. 2: Audit-relevant warnings in the security audit log

In the past, file transfers in SAP applications were often implemented without the knowledge of those responsible for security. Current ABAP kernels (from release 757) therefore generate warnings (SAL event FU9) in the security audit log if files are transferred that have not been scanned due to missing or inactive VSI virus protection. Such warnings are generally assessed as a business risk during an audit and mitigation must be verified.

Reason no. 3: Red team or penetration test findings

It is standard procedure in penetration tests to find out whether malware can be uploaded to the application via file upload functionalities. Pen testers or red teamers usually use the EICAR test file for this purpose. Although this file is not real malware, it is blocked by every virus scanner. If the EICAR test file can be loaded into the application, this represents a so-called "Unrestricted File Upload" vulnerability (MITRE CWE-434). This vulnerability has been rising year on year in the MITRE ranking of the most dangerous vulnerabilities since 2019 and made it into the top 10 of this ranking in 2023.

To check whether the application's file type filters can also be easily bypassed, pen testers also load files with "wrong" file extensions into the application ("notepad.pdf"). If this is successful, penetration testers certify a vulnerability finding of type CWE-636. The category "Insecure Design", to which this vulnerability belongs, can be found in the top 10 vulnerabilities of the Open Web Application Security Project (OWASP).

Reason No. 4: Server-level anti-malware does not protect SAP

It is a widespread misconception that a server security solution installed at OS level on an SAP server also protects file transfers in the SAP application. First of all, SAP recommends excluding all directories of the SAP instance and the database from the real-time scan by the virus scanner at OS level for performance reasons (see SAP Note 106267). 

But even if this note is ignored, file transfers at application level remain invisible to the virus scanner without a VSI connection. This is due to the fact that virus scanners always scan files when they are written to or read from the file system. In the context of an SAP application, however, such file system access does not take place. Usually, a front-end application server - or the gateway in the case of FIORI applications - accepts the file transfer and keeps the file in memory before forwarding it to a back-end server (usually via SAP RFC). This server does not write the file to the file system, but stores it in the database or a DMS, e.g. the SAP Content Server. No file system access takes place at any point along this processing chain. The file is transferred to the innermost data storage of the SAP application without ever having been scanned.

Attempts to address the file upload threat vector at network level also deliver partial results at best. Although it is now possible to scan uploads for malware via HTTP/HTTPS in a NextGen firewall or a reverse proxy, these solutions usually fail with transfers from FIORI apps because the file is transferred as a BASE64-encoded string in the OData channel via HTTP/S. This nesting is not resolved by NextGen firewalls and reverse proxies. This nesting is not resolved by NextGen firewalls and reverse proxies. The file contained in the OData is also not scanned. Attempts to scan transfers via SAP-proprietary protocols such as DIAG (used by the SAP GUI) or SAP RFC fail because these protocols cannot be decoded, especially when using SNC to encrypt the connection. 

Reason No. 5: Compliance and liability

Almost every organization is subject to compliance frameworks that explicitly require the implementation of up-to-date, state-of-the-art protection against malware. First and foremost, of course, NIS2, but also ISO 27002:2022 - Control 8.7, PCI DSS, HIPAA and the BSI's Cloud Computing Catalogue.

SAP introduced the Virus Scan Interface on NetWeaver04 in 2005 and has since implemented it in almost all applications, including HANA XS/XSA, Business Objects, etc. In fact, the use of VSI corresponds to the state of the art.

As a result, companies that do not implement malware protection via SAP VSI can be held liable if non-company users of the application suffer damage as a result, for example because they download a file from the SAP application that is infected with malware or even ransomware.

Conclusion

File transfers or attachments in SAP applications pose a considerable risk potential. This affects both the security and integrity of the application itself and that of the user. Checking files for malware and other dangerous content during upload and download must therefore be an integral part of the SAP cybersecurity strategy. Malware protection solutions at operating system and network level are not able to secure file transfers in SAP applications. 

For this reason, SAP provides a Virus Scan Interface (VSI) in all current products, with which file transfers can and should be scanned at application level.

An advertorial by: