Beyond CVSS: A Balanced Approach to SAP Security Patching

SAP security patching is fundamental to running a secure SAP Infrastructure. However, few SAP teams have a documented risk-based process for their timely application. This results in ad-hoc patching, usually based on resource availability at the time, combined with CVSS urgency.

Security application process

Every SAP IT team has a process for managing security patching. Sometimes this is documented, other times not.

Patch Tuesday

The formal patching process begins with SAP releasing an SNote (Security Note). Normally, this is done monthly on Patch Tuesday, but occasionally emergency SNotes will be released during the interim.

Evaluation

Each SNote is analysed to determine if it is relevant to a specific SAP environment. Not all patches are. Those that are not relevant can be moved to the side for no further action.

Prioritisation

Since it is rarely possible for every note to be installed upon release, SNotes are further evaluated to determine priority.

Most SAP teams evaluate solely on CVSS. However, while a good start, CVSS alone doesn’t consider factors like implementation effort, resource availability, or the need to maintain production stability. It also doesn’t consider lower scored notes that can be applied with minimal effort and low risk.

Therefore, something like a CTERIS evaluation balances CVSS with resource availability, risk, system stability, and effort to install. It is a balanced approach.

Application

Following the evaluation, typically one of four outcomes will fall out.

• The SNote can or must be installed ASAP (Priority 1)
• The SNote can be delayed for a set period (Priority 2)
• The SNote can be delayed indefinitely (Priority 3)
• The SNote can be ignored completely

Priority 1 – Emergency change

Notes to be applied as soon as possible using the emergency change process.

• Can be applied without impacting existing priorities.
• Can be applied with minimum risk to production stability.
• Represents a risk level we are unwilling to carry for any length of time.

Priority 2 – Next release cycle

Notes to be applied at a later date using the standard monthly or quarterly release cycle.

• Can’t be applied as an emergency change due to potential production impact.
• Can’t be applied as an emergency change due to resource availability
• Doesn’t represent a high enough security risk for an emergency change

Priority 3 – Next SAP Support Package

SNotes to which there is no urgency to be installed next time the relevant SAP system is updated.,

• Low risk, installation can be delayed indefinitely

Do not install.

Notes that have been deemed a minimal security risk, or far too risky to implement, may not be installed at all.

• Minimal security risk – not worth the effort
• Too complex an installation

Documentation

To protect team members from undue criticism, senior management and boards from potential prosecution, reasons for decisions related to security patch installation must be documented and reported, especially for decisions resulting in a delayed or non-application of an SNote. Reasons should include things like risk to production stability, unavailability of resources, security risk rating, and so on.

Reporting

Senior Management and Boards should have access to reports that document Note application decisions. Apart from Boards receiving assurance of important patching status, it is beneficial for several other reasons.

1. Firstly, it increases the visibility of a critical IT security activity
2. Secondly, it improves IT security accountability
3. Finally, it can highlight resource restrictions that might limit activity

Third-party tool assistance

There are a few third-party tools available outside of the standard tools, such as ST13 and RSECNOTE, to help.

One of these is the smarterSec Patch Impact Analyser, which can significantly accelerate the evaluation and prioritisation process. In short, it will:

• Show which notes apply to your systems
• Show which transactions are impacted in those systems
• Highlight the best users to test the transaction following the application

One can see which Motes can be applied with little to no testing, which might require some testing, and those that may impact systems significantly and thus require extensive testing. This helps with the CTERIS evaluation.

Final Word

Prioritisation of SAP Security Notes by CVSS alone fails to consider a balance of resource, risk, and effort. This may result in fewer notes being applied than is possible or diverting essential resources away from business-critical activities. Utilising a CTERIS-type evaluation that considers a broader range of criteria, enabling a balanced approach to SAP Security Note evaluation, prioritisation, and application.