How to approach?
The HTTP protocol is widely used for client-server communication and SAP environments are no exception. Think for example about end-user devices that access web pages or Fiori applications, SAP servers that interconnect or communicate with 3rd party applications or typical PaaS or SaaS solutions, utilizing services like SOAP, REST and OData. It is mostly based on the HTTP protocol!
Nowadays, any IT expert knows that HTTP should no longer be used but only its secure variant: HTTPS. That is still HTTP but secured by TLS encryption (Transport Security Layer). Knowing this is the easy part. But in practice, implementing a proper TLS configuration can turn out to be harder than it may first appear. In this blog, we would like to share some general guidelines on how to successfully approach this in a typical SAP landscape. In future blogs, we will deep-dive into some technical SAP-specific components concerning TLS. Also, see our previous blog concerning TLS security.
TLS policy – configuration
It is strongly advised to have a clear and established TLS policy as a basis for implementation. Ideally, this policy is up-to-date, determined by security specialists in the organisation and approved by corresponding management. From this policy, a concrete SAP TLS configuration can be determined for the different SAP components. Key elements are at least (a) TLS version requirements and (b) allowed cipher suites. Further points to consider:
- Policy differences between server/client connectivity.
- Policy differences between internal/external connectivity.
- Which SAP components are involved in the landscape?
- Which cryptographic components (like CommonCryptoLib/IAIK library/SAP JVM)?
- Which technical restrictions apply? For example, the majority of SAP components do not support TLS version 1.3. <insert link to note https://launchpad.support.sap.com/#/notes/0002765639
The SAP TLS configuration could be implemented following the same best practices as with other changes. A typical approach here is to apply the new SAP TLS configuration from non-production to production systems gradually. However, there are some points to give special attention to:
- Actively involve non-SAP and 3rd party applications for testing.
- Include end-user tests covering applications/devices used.
- Connectivity often (slightly) differs between production and non-production systems. Typical example: interfaces between non-SAP or 3rd party applications.
- It is common to encounter HTTPS connections of applications that cannot comply with the new policy requirements. Typical example: legacy applications.
- Align with the network/security/FW team?
These concerns can cause unexpected failures to occur whenever an SAP TLS configuration is migrated to production. To mitigate these concerns:
- Communicate timely when new SAP TLS configurations are planned to be activated in your production systems. Not only for internal connectivity but especially concerning external parties. Through this communication, discussion can start and corrective actions can be taken.
It is not uncommon to send communication months in advance.
- Plan for exceptions and have a solution strategy. Note that granting exceptions on the same technical component often has the negative side effect that the standard is lowered for all connections on that component.
An alternative is to consider the implementation of separate ‘exception’ components to minimize impact.
For example, an API that is provided to multiple clients where only 1 connection requires an exception. By creating a separate API for the exception connection (possibly with additional access restrictions), the original API can still be configured with the required policy.
- Consider detailed logging of HTTPS connections to build an information base that can be used to identify potential problematic connections. This allows for making a more informed choice on the possible impact that a new TLS configuration will have on the SAP landscape.
How to manage further?
Like with many security topics, implementing a secure TLS configuration is not a 1-time activity. Security standards change and so will requirements and corresponding policies. That is why at Protect4S we underline the importance of a vulnerability management process to get and stay in control. Our Protect4S Vulnerability Management solution is able to scan systems for over 2000 vulnerabilities. Including checking TLS configurations and getting insight into connections which can be used to identify potential risks described above.
For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!
Try out Protect4S for 1 month for free or request a demo!