SAP Vulnerability Management. Part 4: Reporting
Vulnerability Management is the most fundamental security practice that provides discovery and security assessments of SAP systems. An approach to recognizing weak points drives security patching, incident management, security event monitoring and all other security capabilities.
Communication is a key success factor in streamlining the efforts of different teams engaged in patching, incident recovery, and the rest processes. The proper communication of found security issues and concerns is a must for motivating Patching Group, ABAP Administrators, Network Team, HR Team, and others in order to deal with the security problems collectively.
This article describes our experience in presenting vulnerability management results to various groups of stakeholders.
This is the final article in the series devoted to the implementation of vulnerability management in SAP environment. As you may remember, it covers the following parts including:
- Motivation aspects
- Identification of assets (systems) and requirements (compliance, security, etc.);
- Analysis of scan results and remediation (patching) planning
The reporting is probably the most important stage because it is the moment of truth, when the Security Team has to demonstrate the business value of its activities. The number of vulnerabilities, exploits, and misconfigurations usually leave the Board cold.
The following questions are the most popular among its members:
- “How protected are we from partners having connections to our systems?”
- “Do we comply with GDPR requirements?”
- “How fast will we respond if a new security flaw is found the next day?”
- “We’ve heard hackers buy MacBooks for 1 dollar using SAP vulnerability. Can they change the prices in our stores?”
All the questions are focused on business benefits and risks and can be roughly divided into 3 general categories:
- Systems exposure
- State of compliance
- Mitigation capabilities
Let’s consider them.
One of the key goals of vulnerability management is reducing attack vectors to SAP systems, and this is measured by SAP systems exposure.
Exposure-related questions are formulated in following ways:
Is it easy to hack our IT systems? Obviously, the absolute security doesn’t exist, and easiness is a very subjective notion. So this question can be reformulated as follows:
- Who can hack us? This question is more appropriate. Externals, partners, employees and trusted insiders have different capabilities to adversely impact on the systems. So, the answer could be: “We are protected from external attackers, but partners communicate with vulnerable module (SAP FI), which may result in compromising all accounting data”.
- In case of a compromise, what would adversaries gain? On the level of IT systems, we can experience the following range of consequences:
- full access to the SAP system, servers and data;
- considerable data leakage or unauthorized access;
- partial information disclosure;
- technical information revealing.
Based on the data we can determine the possible business impacts in case the information in SAP system will be compromised, destroyed or tempered.
The picture below helps to answer this kind of questions based on vulnerability assessment reports:
This picture illustrates that the SRM system has vulnerabilities, which could be exploited by anyone from the outside of the company and might result in a privilege escalation. So, the answer to the question “Are we secured?” is “No! Anyone can do with our systems whatever they want”.
If we look at more critical system that is SCM, we’ll realize that the system is protected from externals, but partners (users having access to system’s external interfaces) can obtain root level access to servers because of vulnerabilities in SCM components.
Security is often driven by legislative statutory, regulatory or contractual requirements (we had an article about leveraging GDPR hype to improve the state of company’s security).
Therefore, it’s not surprising , that Security Teams are often asked about the state of compliance with security standards and estimation of work to meet these requirements. How to respond?
We usually recommend beginning compliance report with the overview figure as follows:
This figure characterizes achievements in each of the authority documents applicable to the company. As you can see, we have 35% improvement in meeting requirements of Critical Security Controls, 50% improvement in fulfilling requirements of ISO27001, and 40% improvement in PCI DSS requirements. However, we failed in NIST 53-800 requirements.
To provide more details we can drill down into technical checks related to one standard:
Further refinement could be provided in a form of a spreadsheet containing information about SAP systems with failed technical checks. This allows us to prepare action plans for addressing found issues.
Once we’ve presented the results of running a vulnerability management cycle, we should develop priorities for the next term and describe mitigation capabilities.
This will provide answers to the questions: “What work related to remediation of cyber risk is in progress?”, “How quickly are we able to implement PCI DSS requirements in all affected systems?”, “What are our priorities for the next period?”
Mitigation capabilities characterize Security Team’s ability to fix security issues emerging in SAP systems. The figure provided below depicts an example of SAP-related security issues and estimation of time required to fix them. This information was obtained from the results of several consecutive scans of SAP systems during the 6-month period.
This data enables us to answer “How quickly will we meet the requirements of GLBA?” since now we know how quickly we mitigate security questions. Combining this with the information about issues that are related to specific standards, we’ll estimate the required effort.
Wrapping all points up, we might come with the following summary statements:
- Technical compliance increased in average by 10%. The weak points are NIST 53-800 and PCI DSS compliance.
- We are vulnerable to employees’ and partners’ malicious actions.
- Vulnerability ratio decreased in average by 30%.
- Overall efforts amounted to 400 man-hours
- There are still 100 vulnerabilities in high critical SAP systems, 50 in medium and 15 in low.
- Future goals are to increase technical compliance by 10% for every standard and remediate all vulnerabilities with high risks.
- Maintaining the current productivity, it will take 7 months for 2 employees to do.
This information is understandable by the Board, easily catches attention and justifies proposals for new security projects, hiring staff and investments in a way of advancing corporate objectives, meeting compliance requirements and measuring risks.