Skip to content
Linkedin Twitter Facebook Xing
< Back to Overview

Efficient Patch Management for SAP

Key Takeaways

  • Definition of effective Patch Management for SAP
  • Efficient patch management frequencies

SAP patching is essential but time-consuming, and for it to be done correctly, it should be a manual process. While this might be frustratingly slow, it’s the right approach because applying patches can often have an impact on the entire landscape.

Many organizations I have spoken with, have had poor experiences from deploying patches directly into their production environments. With “direct” I mean, without testing the affected function. So, what can happen is that a (security) patch damages or disables an essential business function, which can lead to disruption. Disruption essentially leads to loss. In many cases, the potential loss by far outweighs the cost of applying security. On a side note; this principle also applies to the preventive measures to secure an environment against cyberattacks.

Definition of “effective”

This brings us back to the topic: Efficient Patch Management for SAP. Applying security updates is a very effective protection against successful cyberattacks. But how can we define whether the patch procedure chosen is “effective”? Let’s look at an actual process requirement as follows: 

  1. The process makes use of available capacities of existing resources because the topic remains a side-task and should ideally not demand additional hires. There may be exceptions to the rule, but the majority of organizations running SAP should be able to backfill silent periods with this security hygiene. 
  2. The process does not frustrate the responsible team members. Humans are good when they are motivated. Repetitive manual work is not exactly motivating for highly educated and skilled IT professionals. Therefore, organizations need to fine balance automation and manual work. One good example of frustrating work is the downloading of SAP security notes to deploy a patch that can’t then be implemented. Solutions such SecurityBridge’s Patch Management is designed to reduce this manual labor and increase cost-effectiveness.
  3. The process considers the staging level and severity and/or impact of security notes. It doesn’t make sense to seek perfection by applying every released Security Note. It would be better to weigh the available patches by their severity and impact, relative to the organization’s overall security posture. This might sound a bit vague, so let’s look at an example:  
    For organizations that pay attention to structuring and segmenting their network by the criticality of a system, it’s less likely that an external attacker could gain direct access to an SAP system. Virtual patching effects and an additional level of protection can be accomplished by using an Intrusion Prevention System such as the one integrated into a FortiGate next-gen firewall.
  4. The process needs to work for small, medium, and large SAP landscapes. We’ve already talked about the aspect of limited resources. This section covers the complexity that arises with the number of SID’s, level of integration, number of users, distribution of responsibilities, etc. The patching team needs to have the power to implement security patches. The individuals involved need to see the value in their efforts and supplement their activity with the support of testing and deployment.
  5. … more. 

Which patching frequency makes sense?

A short, but a bit simple answer would be “when applying a patch the sooner the better”. While this is probably true, it is far away from reality.  

We determined that the Patch Management Process should make use of existing capacities (Ref. to 1) and since it shouldn’t be demotivating or even frustrating (Ref. to 2) we need to find the right frequency that the team can cope with. On the other hand, we shouldn’t neglect frequency, as an unpatched vulnerability is like sending an open invitation to be attacked. 

In defining the best frequency, we should keep the following constraints in mind: 

  • SAP SE releases patches on a monthly basis. This is done during the so-called SAP Patch Day. SAP has chosen to do this every second Tuesday of a month. 
  • Availability and capacity of the patching team.  
  • Release cycles that exist for business development releases within your organization.  
  • Planed upgrades or installation schedule of Support Packages. 
  • Availability or testing resources to ensure full functionality after the patch implementation. Automation of testing, can be helpful but is rarely available on the level that is needed to catch the fish. 
  • Particularly for critical enterprise applications such as SAP, the system availability and planned downtime windows need to considered. Unfortunately, a full or partial downtime is mandatory for many patches.

There may be other parameters for your specific organization and environment. Managed Service Providers or external hosting may also influence the best frequency. 

Concluding this section with a generalized solution is a challenge. Nevertheless, this is my broad recommendation: Check the SAP Security Patch Day release regularly. Create a reminder in your calendar that alerts you to check the corrections made available on the second Tuesday of every month. Use the available patches as your backlog and maybe use a “divide and conquer” strategy to dispatch the workload across your team. Don’t forget that the tracking of progress is a key element in making this a success.

Posted by

Christoph Nagy

Automate patch management processes with SecurityBridge™

Patch Management
Whitepaper - Top SAP security mistake to avoid

Looking into securing your SAP landscape? This white-paper tells you the “Top Mistakes to Avoid in SAP Security“. Download it now.

press-partner

SecurityBridge at the VNSG Event

SecurityBridge will do a presentation together with our customer Achmea and hosting a booth to demonstrate the capabilities of the platform. The event runs all day from 09:00 to 16:00 with drinks and snacks to close the day.
Learn more
Accenture webinar

Webinar: SAP Security Baseline: Surviving an SAP Audit

With the recent increase in attention to SAP security from auditors, we decided to investigate SAP baselines. We took a closer look into what SAP baselines are, how they can help you, and how to survive an audit.
Learn more
SAP security by design

6 Principles for Security-by-design for SAP

SAP Cybersecurity
Security-by-design is a principle that emphasizes the need to build security measures into software systems from the start rather than as an afterthought. SAP projects need to embed security conciseness to respect this principle and gain a cyber-resilient application. Thus, they should prioritize security when designing and implementing their SAP systems rather than attempting to bolt on security measures afterward. This can help to prevent security breaches and minimize the damage caused by cyberattacks.
coding

Remote Code Execution (RCE) Vulnerability in SAP 

SAP Vulnerability
Remote Code Execution (RCE) vulnerability in SAP is a type of security issue that allows an attacker to execute arbitrary code on a target system remotely. has gained control of a user's click, they can execute a range of actions, such as transferring funds, changing user settings, or stealing sensitive data.
Management Dashboard

SecurityBridge Introduces The SAP Management Dashboard – The Real-Time, Customizable Data View and Analysis Solution For SAP Security

Press coverage
SAP security provider SecurityBridge—now operating in the U.S.—today announced the latest addition to the SecurityBridge Platform—the Management Dashboard for SAP security. The SAP Management Dashboard is a no-cost, additional application for the existing SecurityBridge Platform that combines all SAP data aspects and presents the information through a customizable, single pane of glass security dashboard view.
Hacker mining SAPsecurity

How to detect script-based attacks against SAP? 

SAP Cybersecurity- SAP Vulnerability
In recent years, cyberattacks against SAP systems have become more common, with attackers gaining network access and then exploring critical applications through port scanning and script-based exploration. Two examples of such attacks that use the SAP RFC SDK are the password lock attack and the password spray attack. In this article, we will outline how to detect these script-based attacks against SAP.