For connectivity und integration purposes from on-premise installations to the (SAP) Cloud, SAP developed a small piece of software called SAP Cloud Connector (SCC).
The SCC is the preferred method in customer (hybrid) environments to connect from on-premise to the SAP Public Cloud Applications or SAP Private Cloud Applications.
Looking at the Image 1, you will immediately realize that SCC becomes a center piece in regards of your (SAP) security posture.
Security Considerations for SAP Cloud Connector
There are several security areas we have seen during audits and when hardening the SAP Cloud Connector at our customers. Here are the most important areas to look out for:
Patch-Management
In 100% of all customer environments we have seen that the SCC itself or the related environments are not thoroughly patched. Recent research shows that 80% of cyberattacks happen due to unpatched software vulnerabilities.
We advise checking your implemented SCC version regularly and if it is not up to date you should consider upgrading your SCC to the latest version / patch-level as soon as possible.
Between 2013 and today many versions of SCC were released and a lot of security patches related to SCC have been published by SAP as well. Now ask yourself: When was SCC initially implemented and how often have you implemented a new version or security patches since?
On top of that, please keep in mind that the underlying Operating System (OS) must be patched as well. Because SCC uses Java, it’s mandatory that the JVM or the SDK is regularly patched, too. The effort to keep your SCC and its environment up to date is not very high, but you will increase your security posture significantly!
Please check SAP note 3302250 for details about the support strategy of the SAP Cloud Connector. It is worth mentioning because many customers do not know that security patches for SCC always apply exclusively to the latest available SCC version. Therefore, our strong recommendation is that customers always need to install the latest SCC version and patch to the latest patch-level.
Watch out for the SAP Security Patch Day, every second Tuesday per month on SAP´s blog!
No High-Availability
Even though some think it is not a security feature, the SCC can be configured to make use of a High-Availability (HA) architecture.
Regarding the recommendation that the SCC needs new versions and regular patching, it is vital to configure High-Availability to minimize the downtime and to avoid outages. It is not particular for the SCC itself but for all applications sitting in the (SAP) Cloud that will be accessed by users through the SCC.
SCC location and setup in the network
We have seen SAP Cloud Connectors that are not located in the DMZ of the customers infrastructure. Even worse, we have seen SCC installations that were clearly test installations on client PCs for test purposes, for example. Obviously, those test installations are not maintained properly and have been used aside without implemented security measures from the network team.
We have seen game accounts on UNIX servers
We also strongly recommend using a dedicated server especially for the SCC to avoid that other administrators for other applications on the same server can access the SCC, too.
Last but not least, delete all unnecessary applications from the dedicated SCC server. We have seen game accounts on UNIX servers that must not be installed on an SCC environment. Make use of hard-drive encryption to make sure the configuration and Audit Logs cannot be read by unauthorized users. In over 90% of all audits the hard-drive encryptions were not used.
SCC built-in security features not used
The SCC has a built-in security feature that allows customers to regularly check the security status of their SCC. In 93% of all SCC installations we have audited, the SCC security feature was either not known or not used by the customer. The built-in security feature is the simplest way to raise your security posture to a mature level following the recommendations made. In the latest versions of SCC, the SCC can be connected and monitored through a standard API provided by SAP connecting to the solution manager.
93% did not use SCC’s built-in security feature
If you have a SIEM system in place the API can also be used to integrate SCC.
Usage of outdated Cypher Suites
In the past some Cypher Suites used by customers became obsolete or in some cases their encryption is not secure anymore. SAP only allows a bit length of minimum 256 – all others are deemed to be insecure.
We recommend using a bit length of 1024 minimum. Together with your security officer you should check the existing security policy to configure the cipher suite and bit length appropriately.
SCC Audit log not enabled or not monitored
The SCC has its own audit log that can be enabled for monitoring purposes. SAP lets you configure the audit level (subaccount or cross-sub-account). The default value is “Security” but can be extended to “All”. You must never use or configure “Off”.
There is also the option to choose the period of days how long you want to keep these logs using configuration field <automatic cleanup>. As of SCC version 2.14 there is the possibility to change the location of the audit log files. These files can be used to be imported into a SIEM system.
integrate SAP Cloud Connector into your software lifecycle management
Conclusion
The security topics for SAP Cloud Connector outlined in this article are meant for orientation and a first guidance. There are many more topics to look out for to make SAP Cloud Connector properly secure.
The most important message is that you cannot just implement a central SAP component like SAP Cloud Connector and keep it at a low maintenance level. It is essential that you integrate SAP Cloud Connector into your software lifecycle management and keep high attention like it would be your main SAP ERP system, especially when it comes to security.
