Protect SAP Systems With Unified Connectivity Framework (UCON)
Introduction
SAP systems intended for development, quality assurance, or training are usually less protected than production systems. Since these systems are usually not completely isolated from the production environment, they are still exposed to risk. One critical example of this risk is Remote Function Call (RFC) connections between systems on different protection levels. Even worse, unauthorized RFC connections can also be set up by bad actors from the outside if the SAP landscape is not properly shielded on the network level by defense-in-depth security layers such as firewalls, proxies, etc. Since RFC connections are the bridge between an environment that is relatively open to malicious activities and production systems, their protection is critical.
As of SAP NetWeaver 7.40, SAP has introduced a powerful protection layer against malicious RFC calls, the Unified Connectivity Framework (UCON). This blog post will explain the main aspects of UCON and how it can be used to decrease the attack surface for malicious RFC calls by 95% .
An Overview of Unified Connectivity Framework (UCON)
A standard SAP S/4HANA system contains almost 50,000 remote-enabled function modules of which only several hundreds are really called from outside the system environment. There are two main reasons for this:
- Although SAP provides many application modules, each with numerous processes, most SAP customers only use a small amount of the available business scenarios.
- Function modules used in parallel processing must also be remote-enabled even if they are supposed to only be called locally in the same system and client
Prior to the introduction of UCON, external access to individual function modules could only be controlled by authorizations via the authorization object S_RFC. The disadvantages of this are:
- High maintenance effort for these authorizations
- For the sake of simplicity, authorizations are often assigned on a function group level and thus they provide access to a wider range of function modules
- Some super users often have S_RFC *
UCON introduces an additional layer of protection on top of the authorization based control, using an allow list approach:
The main challenges for SAP administrators are the initial setup of the UCON allow list and the continuous maintenance of the list whenever new remote-enabled function modules (RFMs) are introduced into the system. The UCON framework supports both activities technically.
The Three Phases of an Remote-Enabled Function Module (RFM) in UCON
Before a final decision is made for a specific RFM to be made permanently accessible from outside the system or not, it passes three different phases in UCON:
Phase 1: The Logging Phase
After the initial setup of UCON, all existing RFMs are assigned to the Logging Phase. During this phase, the framework collects statistical data about all external RFC calls. By default, this phase takes 90 days and at its end, administrators have very detailed insights into what RFMs are really used in their business scenarios.
After analyzing the statistical data, all required RFMs are then assigned to the default communication assembly(default CA) which represents the allow list in UCON. RFMs assigned to the Logging Phase are accessible from outside the system, eliminating any impact on running business processes.
Phase 2: The Evaluation Phase
The Evaluation Phase is used to simulate UCON runtime checks and to verify if there are RFMs missing in the default CA. Missing RFMs can be added at any time. RFMs assigned to the Evaluation Phase are still accessible from outside the system.
Phase 3: Final (Check-Active) Phase
RFMs in the Final Phase are only accessible from outside the system if they are assigned to the default CA.
Note: Each RFM has its individual phase cycle and the current phase can therefore be changed separately for each RFM. However, the default duration of each phase is defined globally in the UCON customization. The phase of an RFM is never changed automatically. Administrators can use transaction UCONCOCKPIT(transaction UCONPHTL for systems on SAP NW 7.40 SP6 or lower) to filter for RFMs whose current phase is expired:
All RFMs can be marked in the result list and assigned to the next phase.
Initial Setup of UCON
To activate UCON in a system, system profile parameter ucon/rfc/active must be set to 1.
Afterwards, the central UCON administration transaction UCONCOCKPIT/UCONPHTL is used for the initial setup. UCON is usually set up in the RFC Basic Scenario Landscape. In this scenario, the development system is used to change the phase of an RFM and to maintain the default communication assembly. The production system is used to collect the statistical data about RFM calls from outside of the system. This statistical data can be transferred to the development system and used as a decision criteria for phase and CA changes.
UCON RFC Basic Scenario Landscape
The following detailed step-by-step list is from the document UCON RFC Basic Scenario – Guide to Setup and Operations for SAP NetWeaver 740 SP5 (and higher) with only a few adjustments.
Managing New RFMs
Once all RFMs have passed the defined phases (after setting up UCON they all reside in phase Final) only these RFMs that are assigned to the default CA are accessible from outside the system. But what about new RFMs that were created after this initial period? Well, they run through the same process. They are initially assigned to the Logging phase on the development system and after import into production, any call of them from outside is recorded.
The RFM phase can be set to Evaluation or Final, based on the production system statistics’ results. They can also be assigned to the default CA if they need to be externally accessible. The production system statistics should be periodically transferred from production into development. The phase status change is tracked in a separate transport object R3TR RFST and can be transported separately without transporting the entire RFM again. This is important as the RFM source code may already include changes that are not ready for production.
The UCON cockpit also provides a customizing option, Secure by Default, for new RFMs:
Activating the option is not recommended as it only sets the Active(Final) phase status for the new RFM. It does not add it to the default CA. SAP does not recommend the activation and says:
“Therefore, in general, selecting “Secure by default” might be risky, because it is hard to rule out the possibility that an RFM that is needed for one of your RFC scenarios arrives in your system.”
Monitoring UCON
RFMs can be added or removed from the default CA at any point in time. RFMs that did not pass the UCON runtime checks when called from outside the system can be identified by system log entries (SM21), CCMS entries, and the UCON cockpit:
The UCON cockpit also allows filtering for RFMs that are on the default CA but are not called from outside within a given period of time. Such RFMs should be analyzed too, as they could eventually be removed from the CA.
UCON can also be helpful as a workaround in case vulnerable RFMs are reported by SAP during SAP Patch Day since it enables a quick disabling of the vulnerable RFMs. An example is SAP Security Note #3089831.
Conclusion
With the Unified Connectivity framework (UCON), SAP provides a powerful tool to easily protect SAP systems against unauthorized external RFC access. Its main benefits are:
- It reduces the attack surface for malicious RFC calls by 95% in average
- It is activated within minutes
- Its phase model ensures that daily business is not negatively impacted by disabling the access to RFMs that are needed
- It provides options to protect the initial set of RFMs as well as all newly introduced RFMs