Virtual patching – especially attractive to SAP customers?
Chapters
Share Article
SAP keeps releasing corrections in the form of OSS-notes to fix various problems, security flaws, or just to improve functionality. SAP systems belong to the companies’ critical infrastructures, no doubt. This is especially important since the recent Security Patch Day where SAP released multiple corrections for vulnerabilities in SAP NetWeaver AS Java (CVSS 10.0) . Yet, enterprises struggle with the timely implementation of patches.
Let’s first have a look at the procedure and attached difficulties businesses face when applying patches before looking at potential alternative measures.
Procedure
Before we start to deep-dive into the challenges let us remember how patching SAP NetWeaver application works.
SAP production systems won’t permit direct changes. In consequence, an SAP production system will not allow us to install a patch using the SNOTE transaction directly. Instead of directly patching the critical production systems, organizations need to apply the patch on the development stage.
The leading manufacturer of enterprise applications SAP SE publishes many different favors of security patches, code corrections are the majority however.
Program error corrections are typically installed using the transaction SNOTE. The installation is executed by developers or the members of the Basis administration team. Before the installation can be executed, the responsible person has to read and understand the instructions provided within the SAP note. Not seldom an SAP note demands manual pre or post activities that need to be executed before the patch can be installed. Such manual activities significantly increases not only the efforts of implementation but also chances for human error.
The more important is the step: TESTING. Any correction now needs to be deployed to the testing stage of the SAP landscape before the testing can be started. At the latest by this point in time, someone asks: ” What needs to be tested? “. The answer to this question isn’t easy and needs to be worked out based on the content, the type of correction, and the component invoked in the correction. According to my experience, many organizations tend to implicitly test corrections in the course of a general User Acceptance Test (UAT). If no glitch or unwanted side-effect was detected for the core business process, the correction can move to production. Until reaching this point, many weeks have been passed and many people have been involved in the process.
What makes patching difficult for businesses?
Amongst many individual reasons like missing resources, lack of skill, or inadequate prioritization by the management, here are a few general reasons why especially SAP customers experience patching as troublesome.
Let’s face it patching the SAP landscape is no fun but hard work.
Business Continuity: Some companies postpone the activity while others avoid it altogether due to operational downtime. It is a good practice to keep your SAP systems updated, but many find this process too disruptive or time-consuming especially when business demands 24/7 and 99% availability.
Complex Infrastructure: Many corporate infrastructures are too confusing and complex. The responsible managers have lost track of interdependencies across the SAP instances and the potential impact of patches. Analyzing the dependencies and a potential impact in the event the patch installation fails, or causes disruption, results in hard work.
Patch Cycle Frequency: SAP releases security patches every second Tuesday of a month in the course of the official SAP Patch Day. The monthly frequency of patch releases is often not in line with the patch cycle SAP customers can adhere to.
To make matters worse, SAP administrators often don’t know where to start. These circumstances are caused by missing transparency of which patches apply to a particular customer environment. SAP systems exist in many flavors and make use of many different components for which customers need to maintain an inventory (CMDB) to not lose the overview. SAP Solution Manager holds many functions and features that may help out in this area.
Acknowledge the situation to find mitigation?
Once you have realized that you or your organization suffers from the problems described above you need to acknowledge the facts; those constraints will not allow you to patch known vulnerabilities as fast as you wish to.
Acknowledging the situation is equally important than accepting the fact that any enterprise software may additionally contain unknown, so called zero-day, vulnerabilities for which no solution is available.
With a clear understanding of the situation, you will be able to find adequate mitigation. Although there is certainly no better fix for a known vulnerability than to installing the corresponding correction, the zero-day vulnerabilities remain as a risk. In this moment, Virtual Patching comes into the game.
What is virtual patching?
The internet provides many complex and very complex definitions for what hides behind the term “Virtual Patching“. It also surfaces under the expressions “External Patching” and “Just-in-time Patching” or “vulnerability shielding”. In my opinion one of the best definitions is the one below:
A security policy enforcement layer which prevents the exploitation of a known vulnerability.
This is a rather good definition, which however still demands explanation. Let us look at an example, the recent remote code exploitation (RECON) vulnerability for SAP AS Java (CVE-2020-6287 and CVE-2020-6286). SAP has provided the patch for multiple vulnerabilities in NetWeaver AS Java during the July’20 Patch Day. Before the patch was released this critical vulnerability existed for many years, unnoticed (?). Customers that have carefully read the SNote or the corresponding ABEX Security Advisory, realized, they have two options. The obvious and preferable first option is to install the service pack version to fix the flaw. Alternatively, customers may choose to deactivate the vulnerable service as described in the security note.
The “virtual patch” can be applied by deactivating the vulnerable service and by enforcing that no one enables the service unnoticed. To a great extent, this example describes what a good SAP Security Solution should deliver. Wouldn’t there still be the zero-days, for which we all know, they exist. A best of breed solution would provide a comprehensive security portfolio allowing customers to:
- Enforce security policies for known vulnerabilities that shield the environment from exploitation.
- Easily update policies and detection signatures.
- Detect exploitation of unknown vulnerabilities by highlighting anomalies and critical system actions.
- Provide a transparent and actionable insight on existing and applicable security patches.
Virtual patching is helpful in mitigating vulnerabilities in your system without the need to change the code base, which also eliminates the extensive testing exercise.
SecurityBridge is a comprehensive SAP security platform to monitor your SAP NetWeaver systems in real-time, to reveal vulnerabilities hidden in your SAP systems and identify potential exploitation.
Benefits of Virtual Patching
The obvious first, virtual patching is helpful in mitigating vulnerabilities in your system, without the need to change your code. Another term used for virtual patching is “vulnerability shielding” because it gives you an additional layer adding safety against internal- and external threats impacting your SAP systems.
Virtual patching can be beneficial in many different ways. Here are the main pillars:
Provides Additional Time: Every vulnerability takes time to fix, and virtual patching helps you buy that extra time. Your security teams can find the vulnerability and take the necessary steps for patching it.
Avoids Downtime: Downtime is an inconvenient and often costly activity, but the virtual patching approach, complemented by a solution, enables insight without the need for downtime.
Additional Security Layer: Virtual patching adds an extra security layer, especially in environments where new patches cannot be applied timely.
Flexibility: Virtual patching eliminates the need for emergency patching. It provides enough flexibility so you can apply patches according to your schedule.
Strengthen the Security Posture: Virtual patching not only helps enterprises to survive the time until a fix was installed, without the exponential risk of financial- or reputation loss caused by exploitation, but it also helps to enforce security policies and provide transparency across the board, which all results in an overall improved security posture.