Hardening the ICM with ACLs – a practical example
Chapters
Share Article
In one of our recent articles, we pointed out the use of Access Control Lists (ACLs) to better manage access control. We will now delve into a practical example focusing on the implementation of ACLs for inbound HTTP communication within the ‘Internet Communication Manager’ (ICM) component of an SAP system.
Note: at the end of this article, you can find an overview of earlier published articles and other links related to this topic.
The ICM – a bit of background
Let’s first look a bit closer at the ICM to better understand the need to manage and secure this component. As the name indicates, the ICM is an SAP component that enables and manages ‘internet communication’. That sounds a bit old-fashioned these days, but looking at the history of SAP systems, it makes total sense. Some 20+ years ago, SAP systems were not able to communicate using protocols like HTTP, SMTP, etc. Integration with users and other systems had to be done differently, for example, by using propriety protocols or intermediary components.
SAP opened its ABAP ecosystem for the Internet by introducing the so-called ‘Internet Transaction Server’ (ITS) first as a stand-alone component. Later, the SAP teams embedded it into the SAP instance, enhanced it and added other protocols. Technically, this was realized with the introduction of the ‘Web Application Server’ (WAS) 6.20 as the technical foundation of an SAP ABAP system (notice the ‘Web’ denomination here). This introduction happened in the early 2000s – many years have passed since then and today, the ICM is a crucial component in any ABAP or Java-based SAP system. Not to forget the SAP Web Dispatcher that is built on the same ICM basis.
Because the ICM is a core component for services like HTTP and SMTP, it is clear why the ICM is relevant from a technical security perspective. It is, in fact, the actual component anyone lands on when trying to reach an SAP system via these protocols. In the context of this article, we highlight the following additional points:
- The ICM is a component that resides on the SAP instance level. This means that SAP systems that run multiple SAP instances likely run as many active ICMs.
- Each ICM can be independently configured in terms of what services to run, what ports to use, etc., and manages communication independently from other ICMs in an SAP system.
Why are the above points important? Because it means that:
- One system can have multiple similar access points (like HTTP) to the system.
- The access points are configured independently and can be directly accessed if no preventive actions are taken. This means that consistent configuration is of vital importance.
The picture below further explains the structure, using an example setup that is quite common for SAP systems. It shows a (simplified) view of the components of an SAP system with multiple SAP instances, where the HTTP load is controlled and balanced using a Web dispatcher. This setup is a proven and preferred SAP architecture to manage inbound HTTP access to an SAP system.
The ´black lines´ show the intended lines of HTTP communication. The Web dispatcher is using the message server to retrieve information about the backend system and using this info, the load is balanced. While this may all work perfectly, what is often overlooked are the ‘red lines’ – the ICM backend services are still directly accessible!
Reduce the ICM Attack Surface!
So, why is this a problem, exactly? It is best explained with the concept of ‘Attack Surface’. The Attack Surface can be described as the total number of options (= Attack Vectors) a malicious actor can try to get access to a system and its data. By reducing the number of Attack Vectors, the risk of success for such an actor is also reduced. You can compare it with securing a house: the more doors and windows it has, the more you need to properly check and secure. While a burglar only needs one insecure door or window to get in… The same applies to the ICM scenario: the web dispatcher HTTP port is the only port that needs to be accessible for HTTP communication. By leaving all the other backend services accessible as well, this simply multiplies the number of Attack Vectors and puts the system at unnecessary risk.
So, what sort of risk are we looking at here? For example, in recent years several vulnerabilities have been found, affecting the ICM for both Web dispatcher installations and ICMs of ABAP or Java-based systems. These vulnerabilities range from possible Denial-of-service (DoS) attacks to Information Disclosure vulnerabilities, and worse. By preventing direct access to the backend ABAP or Java ICM services, systems are significantly less prone to exploitation. Although all relevant components still need to be patched properly, that is reasonable enough to reduce that ICM Attack Surface!
Implementation of the ICM ACL
In this article, we explained how to use SAP ACLs to limit direct access to ICM backend services. But that is not the only option, of course. Depending on the architecture, other measures can achieve the same effect (like applying network segmentation and restrictions, etc.). The advantage of using SAP ACL is that it leaves control at the application level and often with the same team responsible for application security.
Implementing an ICM ACL is pretty straightforward. Below, we describe an example assuming a Web Dispatcher runs on a separate host and all other components of the SAP system are on another host. It can be easily extended to setups with additional hosts. That would simply need additional rules to configure.
In our example setup, we configure the following lines below in an ACL file. Note that the IPs can also be defined with a network mask that may be useful for multiple addresses. See the SAP help files:
Next, we define the ICM services that should use the ACL file. This is done with the parameter ‘icm/server_port_<xx>’ and sub–parameter ‘ACLFILE’. In our hypothetical setup, the rules are put in a file called ‘icm_rules.acl’ that resides in the profile directory of the SAP system. This is a useful setup so that multiple instances can use more easily the same file. It looks as follows:
After restarting the ICM, client access to the HTTPS service is now only possible according to the defined rules, so only from its host and from the host the Web dispatcher is installed on. It can be tested with any active service of the SAP system. In this case, we do a browser test to service /sap/public/ping.
The service can be reached via the Web dispatcher, see below:
A direct connection cannot be established though and leads to an error in the browser. These connection attempts are logged in the ICM trace files (dev_icm and dev_icm_sec), see below. The errors can be used for follow-up and identification:
Conclusion and useful resources
In this article, we have shown a practical example of how ACLs can help reduce the Attack Surface of an SAP system. Find below an overview of referred articles and additional sources:
SecurityBridge blog posts:
- https://securitybridge.com/strengthening-sap-security-with-access-control-lists-acl-managing-access-control-from-the-application-layer/
- https://securitybridge.com/how-to-secure-the-sap-icm/
- https://securitybridge.com/how-do-you-prevent-the-sap-attack-surface-from-outgrowing-control/
SAP Help pages:
- https://help.sap.com/docs/SAP_NETWEAVER_AS_ABAP_752/077f95b579a0474fbef5d520be10b680/0c39b84c3afe4d2d9f9f887a32914ecd.html?version=7.52.8
- https://help.sap.com/docs/SAP_NETWEAVER_AS_ABAP_752/077f95b579a0474fbef5d520be10b680/483ae05299c172d0e10000000a42189c.html?version=7.52.8
Examples of ICM vulnerabilities:
ACLs are only one of many options to improve the security posture of an SAP landscape. The SecurityBridge platform offers various controls to check several components for configuration, parameterization, and much more.
Try SecurityBridge and immediately improve the security of your SAP systems! For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn.
