Skip to content
efficient patch management

Efficient Patch Management for SAP

08f4ab4c66997156c778169c9fc04205?s=96&d=mm&r=g
Christoph Nagy
Managing director
June 8, 2021
5 min read
Chapters

Share Article

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.