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.
Every SAP IT team has a process for managing security patching. Sometimes this is documented, other times not.
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.
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.
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.
Following the evaluation, typically one of four outcomes will fall out.
Notes to be applied as soon as possible using the emergency change process.
Notes to be applied at a later date using the standard monthly or quarterly release cycle.
SNotes to which there is no urgency to be installed next time the relevant SAP system is updated.,
Notes that have been deemed a minimal security risk, or far too risky to implement, may not be installed at all.
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.
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.
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:
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.
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.