Here are few facts and figures:
- Cybercrime is expected to cost the world $10.5 trillion annually by 2025, up from $3 trillion in 2015.
- In 2023, the average cost of a data breach was $4.45 million, an increase of 15% over the last three years.
- Ransomware attacks increased by 105% in 2021, with the average ransom payment rising to over $570,000.
- Over 43% of cyber-attacks are aimed at small businesses, but only 14% are prepared to defend themselves.
- Nearly 25% of all cyber-attacks target public sector organizations, including government entities.
- It takes an average of 287 days to identify and contain a data breach.
- Phishing attacks account for more than 80% of reported security incidents.
These emphases the importance of robust cybersecurity measures for the organizations.
How can these challenges be addressed in SAP systems? Do organizations need to employ additional tools to protect the systems?
Not exactly! SAP Customers can utilize a new layer of Security called as Unified Connectivity (UCON). UCON comes as a free offering from SAP NetWeaver 7.40 and can be configured easily.
As mentioned, SAP UCON is a powerful protection layer that was introduced with SAP NetWeaver version 7.40 used to reduce the attack surface by blocking Remote-Enabled Function Modules (RFMs).
Most of the SAP ERP customers use just a limited number of business scenarios for which they need to expose some RFMs. Only those RFM’s need to be exposed for their business requirements of a customer. The rest of the RFMs should be protected from Attack Surface or from Unauthorized Access.
Here is how it works:
UCON supports multiple scenarios and each of them are outlined in the below section.
SCENARIOS USED IN UCON
Unified Connectivity (UCON) provides the following scenarios to optimize the protection of your RFC communication from unauthorized access:\
- RFC based scenario
- Role Based scenario
- HTTP Whitelist scenario
RFC BASIC SCENARIO
RFC Basic Scenario has three Phases to Achieve UCON Protection:
- Logging Phase
- Evaluation Phase
- Final Phase
Using transaction code UCONCOCKPIT, you can call all the scenarios supported by UCON. Execute the transaction code and select the scenario using the “Scenario” drop down and choose the settings. Refer to the below screen shot:
For evaluation and final phases, UCON must be setup. Respective configuration must be carried out to evaluate the RFMS during logging and final phases. Refer to the below screen that shows the RFMs that are logged and in final phase.
NOTE: Configuration steps are not detailed in this article. Refer to our other articles to know the steps to configure UCON and manage the RFMs.
LOGGING PHASE
In this phase, UCON logs all the RFC calls. It is recommended to give ample time for this phase to capture all the RFMs. SAP and industry recommendation is to at least 90 days (about 3 months) to capture log data. In this phase, no RFMs are blocked. At the end of Logging phase, all the exposed RFMs will be assigned to Communication Assembly (CA).
You can view the RFMs in the logging phase using the option available in the cockpit.
EVALUATION PHASE
In the Evaluation phase, there is a simulated runtime check for each RFC call that will determine if the RFM is on the CA. If the RFM is not on the CA UCON will let us know so we can decide if the RFM should be still added to the CA or not.
FINAL PHASE
Once we activate the final phase, only the RFMs exposed/assigned to CA are accessible from outside. Apart from the RFMs assigned in CA, each attempt to reach an RFM blocked by UCON check and it terminates the session on the server side, leading to a system log entry (SM21).
UCON REJECTION IN FINAL PHASE AND ITS LOG ENTRIES
UCON rejects the unauthorized calls made to RFMs which are not part of Communication Assembly (CA).
The log entries of rejected calls will be stored in SM21
How to monitor UCON?
Using UCON CCMS monitoring is available in CCMS Monitor tool (RZ20) that includes phase expiry after the defined duration and rejected calls list.
More information about setting up UCON monitor is detailed in a separate article.
ROLE BUILDING SCENARIO
Role Building scenario supports you when analyzing the required RFC authorizations and create the appropriate user roles with the authorization object S_RFC.
Using the Role Building Scenario: Follow the below process to use Role Building Scenario to protect the RFMs.
To select the Role Building Scenario, we can call transaction code UCONROLE or UCONCOCKPIT and select the scenario.
The below screen shows the Attributes to select in Role Building Scenario to get the list of called RFMs.
If you select the system by dropdown button in “Use Statistics from System” and click on execute it will show the list of all the called RFMs.
Follow the steps below to create a Communication Assembly.
- Click on Display/Change icon
- Click on the create icon
- Define the Communication Assembly name and give the Description
Navigate and select attributes such as System, Communication Assembly, Destination, Client System, RFC Server User for getting the list of called RFMs.
Steps shown in the above screen are explained below:
- Navigate to “Use Statistics from System”, Click the dropdown and select the system that you want to analyze.
- Select the Communication Assembly (CA).
- Select the Destination System in which we want to protect the RFMs from external calls.
- Select the Client System from which the external calls are made.
- Select the RFC user of the destination system for whom we need to assign the Reference user.
Assigning Communication Assembly to an RFC Role
Create a Role using PFCG exclusively for RFC authorizations and add the communication assembly (CA) to the Role Menu.
You must assign this role to the Reference User, and that reference user must assign for RFC user created in the target system. Then an external system can only call those remote-enabled function modules (RFMs) defined in the Communication Assembly.
HTTP WHITELIST SCENARIO
The HTTP whitelist scenario helps to monitor and allow HTTP(S) calls in your system using several whitelists. You can specify which HTTP(S) calls are to be allowed and blocked. Each whitelist is assigned an HTTP context type that covers a particular type of HTTP call.
- Trusted Network Zone: It logs URL patterns for which a redirect is allowed or blocked.
- Clickjacking Framing Protection: It is used for Clickjacking protection which means interface-based protection for instance if a user clicks on any link on a website believe to be trusted but it is malicious.
- CSS Style Sheet: List of all CSS Style sheets allowed for use in SAP GUI or not allowed for use in SAP GUI.
- Cross-Origin Resource Sharing (CORS): Context type for the management of calls that want to perform specific actions on the server side.
NOTE:Create an Allowlist/Whitelist for every available HTTP Context type to ensure comprehensive protection.
Phases in this Scenario where whitelists are checked and Modified
Logging Phase: In this phase only, logs will be made but they are not checked yet.
Simulation Phase: A simulated check is made to see whether an URL is covered in the Whitelist/Allowlist. Here we need to make a note that No error is raised in simulation phase).
Final Phase: Once the simulation phase completed successfully (After modification of relevant whitelists if necessary), you can activate final phase. Logs will be made only for blocked URLs.
Monitoring Phase: Check the logs periodically and modify the relevant whitelist if necessary.
Note: HTTP whitelist Scenario Configuration steps are not detailed in this article. Check with us to know the steps to configure HTTP Whitelist Scenario and manage the HTTP calls.
Converting called URLs to Whitelist
Then the Called URLs will be added to Whitelist/Allowlist and the Not covered by whitelist will be Blocked from access.
