We continue to describe the implementation of Vulnerability Management in SAP environment and turn to the very specific topic – vulnerability analysis. Vulnerability Management has two goals: reducing attack vectors and providing assurance in SAP systems. Both of these objectives require assessing of the existing vulnerabilities in terms of risk and remediation effort. This will be today’s topic – how to analyze vulnerability reports and develop remediation plans.
If you are new to the series, please address the previous articles:
1. Part 1 – Motivation. What is an SAP Vulnerability Management?
2. Part 2 – Inventory and Scanning. How to organize inventorying and scanning of assets in scope of Vulnerability Management.
After these steps, we have Inventory of Assets and set of Vulnerability Reports. Now we need to select a subset of the most critical issues, which is feasible to patch, and develop a Remediation Plan considering the limits of the available workforce, time, and remediation technics.
Developing of Remediation Plan is performed in the following order:
1. Collecting remediation requirements and constraints
2. Prioritizing vulnerabilities
3. Filtering vulnerabilities
4. Preparing the document
Remediation Requirements and Constraints
In real life, we are always limited in time and effort to put patching of SAP systems into practice. Therefore, from the very beginning, we advise gathering the following information:
- What is your time frame? For example, you may be restricted in overall amount of effort so that all remediation processes should be done in 3 months by 2 employees with 50% workload.
- Do you have the limitation on remediation technics? You might be told you are not allowed to install any kernel patches.
- Are any types of vulnerabilities being of your special interest? For instance, you may start with misconfigurations and then shift to application and code vulnerabilities.
All the above-mentioned will govern your actual analysis and the remediation plan development. An example of documenting these requirements provided in Figure 1.
In the last column, you can see the result of applying these constraints. During the filtration, we will minimize a list of all vulnerabilities to meet these requirements and reduce the workload.
First, you should gather all scan results and assign them to the assets from a common Inventory of Assets. If you employ more than one tool to manage assets, it could be a challenging task, since vulnerability scanners have their own unique representation of SAP assets, vulnerabilities, and supplemental information. Once everything is accomplished, you can assign a priority to each vulnerability.
We advise you to use a risk-based approach to estimate its priority.
The priority of a vulnerability is high if it:
- is easy to exploit;
- being successfully exploited, leads to severe consequences to SAP system;
- occurs in SAP systems with the high level of criticality.
Vulnerability scanners include a knowledge base with vulnerability descriptions and enrich vulnerability reports with this information.
Vulnerability reports provide us with vulnerability probability (characterizes ease of exploitation) and vulnerability criticality (describes impacts on SAP system in case of successful exploitation). The third term (i.e. SAP system criticality) comes from the Inventory of Assets and defines the business impact of breaching security on those particular SAP systems.
In this way, to estimate a priority of a vulnerability, one should:
1. Calculate the vulnerability risk by multiplying vulnerability probability and criticality provided by scanning tools.
2. Count the vulnerability occurrences on assets with different criticality levels.
3. Calculate vulnerability priority, considering distribution and criticality of affected systems. For example, you can use the formula:
Vulnerability Priority = Vulnerability Risk * (3 * cntHighCriticalSystem + 2 * cntMediumCriticalSystem + cntLowCiriticalSystem)
Figure 2 illustrates an example of the prioritization of vulnerabilities.
Right away, you see the top vulnerabilities that are both severe and occurring in the SAP systems with high levels of criticality.
Now you have a global prioritized list of all vulnerabilities and requirements to remediation.
For each SAP system, you need to filter out the vulnerabilities with low priority to fulfill remediation requirements.
Scanning tools basically give you the information about the ways to remediate a vulnerability. Usually, the information is provided in the form of a short description and links to guidelines.
Based on your experience and information delivered by scanning tool for each SAP system, you need to filter out vulnerabilities that can’t be remediated within established timeframe, allowed set of remediation techniques, and maximum period of downtime of that particular SAP system.
Thereafter, you should cut the remaining list to fit into the labor limits. You will get an action plan for each of the SAP systems.
Figure 3 provides an example of a remediation plan for the sample system DM0.
As you can see, for each vulnerability in the DM0 system, we give short description and remediation, which in that particular case is of update configuration type. Administrators should add a column to the right of the table and provide their feedback, whether they succeed with these recommendations or not.
Preparing the document
Remediation Plan is a document that contains all information required to communicate the desired way of actions to enhance SAP security, namely:
1. Description of assets in scope of vulnerability assessment.
2. Assumptions and constraints for vulnerability analysis.
3. Prioritized list of all vulnerabilities in SAP systems.
4. Filtered list of relevant vulnerabilities and remediations for each of SAP systems.
5. Description of vulnerability risk assessment methodology.
The bottom line is that we should do our best to ensure BASIS administrators will succeed to remediate appropriate vulnerabilities. We should clarify why the work is important and why we want them to be engaged. If you throw a vulnerability report over the wall to BASIS team, they will just pay no attention to it. If you don’t care about analysis, why should they do?
My final takeaway: keep action plans short. It’s better to scan more frequently and address just a dozen of critical vulnerabilities than do a full scan once again, become horrified by the scale of the problem and give up.
The reliable operation of SAP systems is achievable. It’s just a matter of experience and diligence. That’s why we are here to share experiences and support each other.