Implementing SAP Vulnerability Management Process. Part 1
This series of articles describes an approach to increase ERP security by leveraging proactive vulnerability management process and ERP security control solutions.
The provided information will come in handy for:
- preparing a business case for ERP security control solutions;
- developing requirements to the project;
- selecting the best product;
- designing the ERP Vulnerability Management (ERP VM) processes.
The first article contains introductory material, business requirements to ERP VM process, and its basic structure.
Reading time is about 5 min.
Securing ERP systems is extremely challenging and complex task. The reasons here are quite clear. Sure thing you should ensure security of common components like OS, Web stack and Database. However, on top of that, there is a good pile of applications in ERP systems, which have their own specific vulnerabilities and weaknesses.
In recent years, the number and severity of ERP vulnerabilities have skyrocketed. So, what have driven the interest of hackers, competitive intelligent services to the subject? There are several factors:
- growing exposure of EPR systems to outer world due to extensive integration;
- decreasing difficulty of conducting an attack due to availability of advanced security tools;
- high perceived value of espionage, sabotage and fraud techniques implemented in IT environment.
Figure 1 illustrates the growing number of detected vulnerabilities in SAP solutions. The graph depicts the total number of SAP Security Notes. Every of them may include a patch for far more than one vulnerability. Just imagine how much work it takes to perform hundreds of checks for all of these vulnerabilities!
ERP vulnerabilities could be roughly divided into the following categories:
- ERP application vulnerabilities;
- custom code (ABAP, PeopleCode, X++, PL/SQL) vulnerabilities;
- misconfigurations (insecure configuration settings);
- business logic flaws (Segregation of Duties violations, access to critical business transactions, suspicious user behavior and collusion).
The need for addressing the vulnerabilities led to emergence of ERP security scanners and then to integrated ERP VM platforms. They implement all spectrum of functions from basic inventorying assets and policies, scanning, managing tasks, and making reports to advanced ones: calculating correlations, monitoring user behavior, supporting advanced analytics, providing instant reaction, implementing automatic corrections, and ability to integrate with SIEM, IDS, and firewalls.
However, before deciding on investing in any product, you need to precisely define business value and role of the ERP VM solution in ensuring enterprise security.
You need to clearly envision communication flows between involved parties:
- security priorities and importance of assets from Asset Owners;
- notifications about found security issues from Security Team to Patching Group;
- information about applied remediations from Patching Group to Security Team;
- reports about state of ERP security and security of business assets for Asset Owners and board.
Thus, the aim of this series of articles is to describe a vendor-neutral approach to implementation of ERP security control platforms in terms of vulnerability management. The provided considerations will be useful in preparation of business case for implementing ERP security control systems, collecting requirements to the projects, and designing the processes of ERP VM.
2. ERP Vulnerability Management
The very concept of managing vulnerabilities is a result of inability of Security Team to remove a vulnerability at once.
The reasons are all well-known and lie in the nature of ERP system patching process:
- resource and time consuming;
- conducted by dedicated Patching Group consisting of SAP BASIS team and SAP Developers;
- requires recheck from Security Team;
- could lead to SAP systems outages and as a consequence slow business process.
Vulnerability scanning creates massive amounts of data. However, there is just no way to prioritize work, while it is not business-context specific. Therefore, Patching Groups are directed to fix everything and struggle to keep up. Additionally, with little connection to configuration management processes, a vulnerability occurs over and over because the root causes (patching and secure configurations) are disconnected from vulnerability management.
2.1 Recommended Process
The solution lies within establishing of the continuous cycle of monitoring and assessing ERP security quality. Detected issues and weaknesses should be prioritized and remediated by implementing proper ERP security controls. This way, we will be able to make our enterprise security architecture adaptive.
The design requirements to the process of ERP VM are:
1. Business context awareness. Prioritizing of remediation activities should be conducted in accordance to business value of assets, existence of connections with other systems, and compliance requirements.
2. Prioritization. Every single run of the process should resolve the most critical security issues.
3. Threat Intelligence. Vulnerability databases should be updated in due time so that the scanners can identify the latest security issues.
4. Scalability. Scope of control should be able to be changed in number of assets, types of weaknesses and vulnerability monitoring techniques.
5. Comprehensive Workflow. The process should streamline efforts of several teams (network, application developers, application administrators, DB administrators, and so on).
The main goal of vulnerability management is to efficiently reduce the number of attacks through remediation of vulnerabilities.
This will lessen ERP operational risks by affecting vulnerability term of risk equation:
- reduce sabotage risks of interrupting business processes by identifying threatening components;
- decrease fraud risks by identifying dangerous redundant authorizations and suspicious activity of users;
- lower espionage risks by hardening system configuration and removing weaknesses in protection mechanisms.
Progress towards the goal of effective reducing exposure is measured in several dimensions: the exposure of ERP system, response (mitigation) time, labor and monetary costs, and the state of compliance.
We advise the following general series of business activities to achieve the main goal:
1. Identify assets and schedule vulnerability assessment.
2. Scan for vulnerabilities.
3. Analyze and prioritize vulnerability remediations.
4. Test and deploy vulnerability remediations.
5. Verify remediations and produce Executive Report.
As a result, the process provides assurance to stakeholders that the ERP systems in scope meet the target security level. This target security level is a description of the desired state of security, expressed in terms of overall vulnerability risk, limits on remediation efforts, and a level of technical compliance to related standards. That means the most severe vulnerabilities were discovered and remediated within given limitations on time and effort.
The assurance that process meets its goal is supported by vulnerability analysis reports that contain information about change in number, distribution, and characteristics of vulnerabilities, advances of compliance indicators, and developments in performance (identification time, response time, etc.).
The scheme for ERP VM is depicted in figure 2. ERP VM is a cyclic process that delivers improvements in security of ERP system on the process every cycle.
We’ll review each of the business activities in depth in the next article of the series.
If you are interested in the topic, join us in the upcoming webinar about SAP Vulnerability Management, where we will describe the process on the example of managing vulnerabilities in SAP and show use cases of all the vulnerability management activities.