Skip to content

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™

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

Meet us at SAPINSIDER 2022 – in Las Vegas

June 19-21, 2022 the US team of SecurityBridge will be at the SAPinsider Event in Las Vegas. You will find our booth in the Cybersecurity area.

How to implement and enforce a security baseline for SAP ?

Join and listen to our webinar, to learn how you can use the SecurityBridge platform to define and apply one or multiple baselines, receive alerts whenever the system again deviates…
SAP Security Services
SAP Cybersecurity- Security News
Many companies have recognized the need for SAP cybersecurity, but many have also realized that they cannot accomplish this alone. There are many reasons for this. It can be due to the internal teams' workload or due to the employee's level of knowledge. However, there is a solution that neither burdens your internal staff nor demands additional knowledge. A specialized managed SAP Security Service allows you to harden mission-critical systems, detect and promptly counteract non-compliance, and implement monitoring with accurate anomaly detection.
Patch Management
SAP security provider SecurityBridge—now operating in the U.S.—today announced the full integration of its SAP Security Platform with the Microsoft Sentinel cloud-native Security Information and Event Manager (SIEM) platform and its membership to MISA. SecurityBridge was nominated to MISA because of the integration of its SAP Controller to the Microsoft Sentinel dashboard. SecurityBridge is a Smart Data Adapter that significantly simplifies security monitoring of critical and highly specific business applications.
Angriffserkennung für SAP
SAP Cybersecurity- SAP Identity and Authorization- SAP Threat Monitoring- Security News
Viele unserer Leserinnen und Leser erinnern sich noch an den 25. Mai 2018, Stichtag der bindenden Einführung der Datenschutzgrundverordnung, kurz DSGVO. Verstöße gegen die neue Regelung können seitdem zu drakonischen Strafen führen. Nun steht, zumindest für diejenigen Unternehmen, die zur kritischen Infrastruktur (KRITIS) von Deutschland zählen, ein ähnlicher Termin ins Haus. Am 1. Mai 2023 müssen betroffene Unternehmen ein System zur Angriffserkennung eingeführt haben.
SAP Cybersecurity Risks
SAP Cybersecurity- SAP Security Framework- Security News
Recently, we gave an insight into the known SAP attackers in our blog. Of course, it can already be deduced from this that there are internal and external SAP attackers. That is why today, we want to look at this from an SAP cybersecurity risk perspective.