1. Introduction
Companies, governments and ordinary citizens notice the increasing importance of cybersecurity in daily life. During the first half of 2020, about 9799 new vulnerabilities were reported [1]. This indicates the increase of 34% in comparison with the same time span in 2019. The researchers active in the field of cybersecurity believe that in 2020 the number of detected vulnerabilities will reach another record value. Furthermore, due to the ongoing Covid-19 pandemic [1] and related increased use of internet services, the cybersecurity issues have the potential to affect a much larger, than in previous years, part of the human population. Consequently, the identification and prioritization of vulnerabilities becomes a critical issue for a company that offers internet services [1,2].
Vulnerability Management (VM) and Vulnerability Assessment (VA) are the proactive security layers against threats which commercial companies may face. In addition, they present a challenge for many organizations [3]. The first issue related to vulnerability management is the time passing between vulnerability identification and elimination. As Gartner explains, “most organizations follow a philosophy of gradual risk reduction, with vulnerability and patch management policies focused on mitigating and patching a percentage of vulnerabilities in a given time frame, for example, remediate 90% of high severity vulnerabilities within two weeks of discovery. This reduces vulnerability management to a pure metrics exercise, where risk is expressed as a numerical value that can be reduced.” [4]. The fact is that in 90% of all cases a potential adversary is not going to be focused on the patched or remediated vulnerabilities but on the remaining 10%. Haldar and Mishra discuss in [5] the importance of the time reaction to new threats, stress the importance of quick vulnerability prioritization and patch, and show how short reaction time results in maximization of the effort required to breach the lines of defense. Other important points related to VM are [3]:
there is no successful VM without effective communication,
insufficient resources allocated to remediate the detected vulnerabilities, will cause vulnerability accumulation,
fixing only “high” and “critical” vulnerabilities is not enough.
The above points stem from the fact that all vendors [6,7,8,9] provide their own methods of vulnerability prioritization without informing the end-user about the details of the decision making process. The unfamiliarity with prioritization algorithms may adversely affect the process of fixing the vulnerabilities since the companies that use particular software suite are left relying on unknown prioritization algorithms.
In this contribution authors have developed a distributed system—Vulnerability Management Centre (VMC) [10]—operating in a scalable, containerized environment. VMC allows the CVSS Environmental score to be calculated in an automatic manner. The developed VMC collects automatically information on vulnerabilities from publicly accessible sources. Then, VMC gathers information regarding vulnerabilities present in the system and integrates this data with the data obtained from the inventory database. Thus VMC is able to normalize accrued information and perform environmental calculations taking the relevant variables into consideration, e.g., Target Distribution () or Confidentiality, Integrity and Accessibility (CIA) triad. In addition, due to application of Smart Data algorithms [11,12] the developed VMC is capable of presenting results almost in real time to stakeholders. The small delay depends on computational resources available and the amount of data coming from a vulnerability scan. Thus, the developed VMC is vastly superior to standard systems whereby a monthly report is sent to the stakeholders each month based on previous month’s data. Further, the developed VMC operates on normalized data, which renders the system independent of either the specific vulnerability scanner or asset management solution. A novel contribution of this work consists in performing automatic calculations of the environmental component of CVSS score vector by combining the data obtained from vulnerability scanner with the data retrieved from the inventory database. To the best of the authors’ knowledge, such an approach has not been presented yet in the publicly available literature.
An additional novel aspect of the present paper unfolds in the context of data life cycles presented in [11], which pertains to Smart Data and consists in retrieving knowledge from “the mass of initially unstructured data” [12] collected by VMCs, i.e., the results of vulnerability scanning, vulnerability related classification of data stemming from several publicly accessible databases and integration with information on organization’s assets within the organization-specific context. In this contribution, the initially completely unrelated data, gathered by VMC is structured, normalized and filtered to bring in value and novel knowledge relevant specifically to vulnerability management.
This article is organized as follows:
Background—section describes foundations of this research, introduces the problems, processes and trades off that are present in vulnerability management research.
Related Work—section presents other work related to the present topic. It is a brief description of work related vulnerability management.
System Data Life Cycle and Analysis—section presents data life cycle and analysis of the proposed framework.
VMC Implementation and Experiment Design—section shows an experiment design for conducted research.
Results—section starts the discussion about the results illustrating the advantages of the proposed VMC system, shows a summary of the presented work.
Conclusions—section gives the summary, starts critical discussion about the presented solution, and introduces fields for further research.
2. Background
In order to understand the concept of vulnerability management, one should begin with learning what the vulnerability in a computer system is and how it is marked using the Common Vulnerability Enumeration (CVE) [13] and assessed using Common Vulnerability Scoring System (CVSS) [14].
According to [15], software vulnerabilities “are software bugs that expose weaknesses in software systems”. Consequently, software vulnerabilities are directly linked to the software development process. Authors in [16] point out that discovering bugs, problems, and vulnerabilities during the software development process is time consuming. Moreover, the insights regarding vulnerabilities and defects are frequently not pointed out by the development team but usually come from independent researchers.
The idea for creating a consistent standard for marking the vulnerabilities was presented in [13]. The authors of the CVE concept discovered the need for introducing a consistent way of marking vulnerabilities in order to improve the internal communication within the organization. Each security system that was used and attempted to be integrated, consisted of its public and nonpublic vulnerability database [13,17,18]. The largest problem faced was the lack of common naming convention and vulnerability identification. As a result, the data comparison for different providers and linking this data with other security systems to minimize the risks, was very time consuming [13,17]. The Common Vulnerability Enumeration (CVE) concept was accepted by the industry and literature to such an extent that it has found its usage not only in Intrusion Detection Systems (IDSs) [19] but in every cybersecurity related field [20,21,22]. Further, since 1999 many computer security providers and nonprofit organizations have been developing, promoting, and implementing the diverse systems of vulnerability assessment: X-Force [23], Symantec [24], Microsoft [25], Redhat [26], Mozilla [27], Secunia [28], Vulpen [29], Google [30], VRSS [29], CVSS [31]. Currently [23,24,25,26,27,30], many computer security providers are still maintaining research departments; however, support for many past solutions has been discontinued [31]. For instance, [28] is no longer developed while [29] has not been adopted. The Common Vulnerability Scoring System (CVSS) on the other hand, was introduced for the first time as a research project by the US National Infrastructure Advisory Council (NIAC) in 2005 [31] and adopted subsequently by other organizations. The CVSS 2.0 and CVSS 3.1 versions [32,33] are divided into three categories:
Base
Temporal
Environmental
Base category represents properties of the vulnerability that do not change in time. These properties consist of access complexity, access vector, and assess the degree to which a vulnerability compromises the confidentiality, integrity, and availability of the system. Temporal category describes properties that may change over time. In particular, the temporal category refers to the existence of a public exploit and a patch or fix availability. The temporal characteristics of CVE were studied specifically by Ruohonen in [15] while in [19] researchers aimed to express the value risk, potential loss, and prevalence of affected systems in the considered environment.
Beyond any doubt, the Vulnerability Management (VM), an essential part of maintaining the security of an organization [34,35], is threatened by growing cybercrime [36]. The identification and mitigation of vulnerabilities in specific or critical systems reduces the risk of exploitation impact during a potential attack [37]. Therefore, it is crucial that leading Information Technology (IT) organizations and network administrators aim for zero vulnerabilities in managed systems. The VM process should be implemented practically in every organization that uses IT infrastructure. For instance, current corporate networks consist of thousands of devices and applications, without which business processes cannot function, whilst even a temporary unavailability of services rendered may result in large financial losses and reputation damage [35]. However, the critical importance of VM also applies to other entities ranging from office networks, to financial and personnel systems, to very specialized systems (e.g., industrial/process control, weapons, telecommunications, and environmental control systems) [38]. Thus, due to increasing threats and known vulnerabilities, an organization must have a vulnerability management system or a process that provides the latest security patches and updates to the organization’s network [39]. In general, the purpose of VM is to monitor and identify new threats and vulnerabilities (hardware and software) that may affect the confidentiality, integrity, or availability of an organization’s IT resources. In addition, VM should help system administrators to identify existing and known vulnerabilities and apply appropriate actions to reduce the risk of vulnerability exposure [40]. The undertaken actions may consist of patching vulnerabilities or taking other actions, if a vulnerable system cannot be repaired due to operational constraints, or the patch causes key services to be unavailable. If a vulnerable system cannot be repaired, system/network administrators should create a plan to mitigate every vulnerability that cannot be eliminated [41]. Mitigation plans may consist of blocking rules on Intrusion Prevention system (IPS)/Intrusion Detection System (IDS), moving the system to a separate Virtual Local-Area Network (VLAN), significantly restricting or blocking ports on the firewall, or even removing the system from the publicly available part of the network until appropriate corrective measures are implemented.
Further, from a practical point of view it is important to scan as much of the network as possible (preferably the whole network each time). Using the VM system presented in this contribution, if only a fraction of the network is scanned within the VM process then by viewing the scan results and comparing them with the assets via asset management tool, one can estimate the percentage of scanned devices and determine the overall network status and network hygiene level. Finally, in almost every environment it is presumed that devices will be turned off, disconnected from the network or put in a transient state during the scan, so scans should take place regularly (as often as possible) and maintain a vulnerability history.
3. Related Work
Many authors [42,43] stress the fact that in order to prioritize the vulnerability correctly, organizations should consider an asset value and a vulnerability importance in a standardized way. The problem of vulnerability prioritization has been discussed in available literature for a long time [44,45,46,47]. Most established companies that take cybersecurity seriously into consideration have a vulnerability management process implemented to a greater or lesser extent [3,42,44]. However, as noticed in [3,44,45,46,47] each organization approaches the problem differently. The solutions enlisted in the report [48] F-Secure [6], Qualys [7], Rapid7 [8], or Tenable [9], on the one hand help the organizations to overcome the vulnerability management problem but on the other one, they have two drawbacks. Namely, they are very expensive and they do not inform users on the details of the prioritization procedure. For instance, Qualys uses a 7-point scale [7], Rapid7 performs the prioritization in the range from 1 to 1000 [8], whereas Tenable named its prioritization method VPR and the provided levels range from 1 to 10 [9]. Next to commercial solutions, it is possible to find in literature, other solutions, i.e.,: PatchRank [49], SecureRank [50], VULCON [37], or VEST [51]. The PatchRank solution focuses only on the updates prioritization for SCADA systems [49]. The SecureRank uses the network topology and the potential interaction between servers to calculate their risk [50]. The Vulcon’s software strategy is based on two elementary pointers: the vulnerability appearance time (TVR) and total vulnerability exposure time [37]. VEST, however, focuses on verifying whether the vulnerability is exploited and how quickly it can be used by an attacker [51]. Other solutions, e.g., [37,49,50,51] do not take into consideration the value of assets and are not adjusted to the increasing amount of data in cloud computing environment and therefore they cannot be applied in every network infrastructure. Additionally, none of the presented solutions offer prioritization for CVSS 2.0 and CVSS 3.1 simultaneously. This is due to the fact that not all vulnerabilities were converted from CVSS 2.0 to CVSS 3.1, even though CVSS 3.1 assesses the essence of vulnerability in a better way and estimates threats more efficiently [18].
An important characteristic of the VMC developed in this contribution is solving the problem of scalability. Thus, allowing to adjust the tool easily to the increasing amount of incoming data. In comparison to [37,49,50,51] the developed VMC uses the information collected from the asset database. Unlike [6,7,8,9] the prioritization procedure has been outlined in detail and hence can be analyzed using FIRST standard [14]. Another aspect of the developed VMC’s operational activities is handling the big sets of data. According to results and discussions presented in available literature, a significant element of managing big sets of data is their life cycle. In [52] the authors examined over a dozen different data life cycles and their phases aiming to find the ones that “makes data Smart and thus facilitate their management in the Big Data context”. “Smart” meaning the aforementioned knowledge obtained from the big and initially unstructured data set. According to [11] “the phases which constitute the data life cycle in a Big Data context are very complex. Each phase is considered as one or more complex, operational, and independent processes, but these processes are linked to one another and to make data management more flexible and smart”. Thus, presenting the data life cycle is not a trivial task. The developed VMC as an open source product is characterized by transparency of the used methods and techniques. The developed VMC has been based on, so-called, Smart Data Lifecycle presented in [11]. Its aim is to present the data life cycle as a process, in order to increase its flexibility and ability of adjusting to different cases. The description of the particular life cycle phases is presented in the following sections.
4. System Data Life Cycle and Analysis
In this section, the system data life cycle and analysis of the proposed Vulnerability Managements Centre (VMC) is described. VMC consists of four core modules: Knowledge Collector, Asset Collector, Vulnerability Collector, and Processing Module. The first three modules are responsible for data collection, integration, and filtering while the Processing Module enriches the data with the CVSS environmental results.
All modules work independently [53], communicating asynchronously via a queue system. Consequently, the software is vertically scalable and the system is configured from the administrator panel. VMC also has two administrational modules, i.e., Scheduler—which controls the sequence and the time of data collection from particular sources and Task Monitor—to provide a preview of the current state of the system.
The software has been prepared to operate in the cloud computing environment and is based on Docker container technology [54]. All data is stored in the form of documents in Elasticsearch [55] that enables its processing in full-text mode, while the Kibana tool [56] is used to analyze and present the results. The software was implemented in Python due to its flexibility and ability to process data on the server side efficiently. The whole project includes multi tenancy support allowing for comprehensive data separation between the documents. Additionally, in VMC there are two data life cycles: operational and historical. Due to this fact, an operating engineer is able to see all changes immediately. The developed VMC allows previewing data and historical calculations, facilitating, at the same time, the analysis of the events occurring in the system. The last step, visualization, is done by Kibana (Figure 1). In order to simplify the principle of the data flow and VMC architecture, the Vulnerability Management Center is presented in the form of separate modules.
4.1. Knowledge Collector Module
Knowledge Collector Module is responsible for collecting, integrating, and filtering data from publicly available databases regarding known exploits and Common Vulnerabilities and Exposures (CVE) [14], among others, such as National Vulnerabilities Database (NVD) [57] and Exploits Database [58]. Collecting is done with publicly accessible API, files, and web scraping. Then data has to be integrated, CVE and Exploits are matched, and previous existing data has to be updated. In the filtering phase all rejected [14] CVE or Exports are skipped to remove unnecessary information. The proposed document [55] stores the complete vector for CVSS 2.0 and CVSS 3.1 in the separate fields constituting the vulnerability assessment [14], in order to accelerate the calculations and facilitate easier vulnerability search, taking in that way its characteristic, e.g., remote usage. Using vertical scaling and triggering integration only for new or changed CVEs and Exploits reduces the time gap between the data collection and presentation of information on critical vulnerabilities to stakeholders [39].
4.2. Asset Collector Module
Asset Collector Module is responsible for collecting, integrating, and filtering data that involve detected and defined assets for monitored network. The module collects data from two data sources. The first source is Configuration Management Database (CMDB) [59]. The second source is vulnerability scanner [60,61] that is not only able to scan but also has the functionality of detecting the components. In consequence, it is possible for VMC to inform the operator about data incompatibility between CMDB and scanning results. That is one of the first knowledge enrichment manifestation the VMC can present while analyzing collected data. In order to explicitly determine an asset identifier (id), the universally unique identifier (uuid) generator version 3 [62] was used, based on the asset IP address and id value received from CMDB. The proposed document, except for fields needed by CVSS standards, contains also business and technical owner fields, which hold information about the person responsible for the monitored asset.
4.3. Vulnerability Collector Module
Vulnerability Collector Module collects data via accessible API from a vulnerability scanner [60,61]. During the filtering phase, the vulnerabilities classified as informational, i.e., with base CVSS 2.0 and 3.1 equal to 0, are excluded. This phenomenon is caused by the fact that informational findings do not provide any additional value to the vulnerability assessment and represent considerable volume of data (even 85% of all reported findings per host). In the integration phase, vulnerability collector module updates all existing vulnerabilities and assets received from previous scans. In order to explicitly determine the vulnerability identifier, the uuid was used, based on the IP address of the scanned machine and plugin id received from the corresponding scanner. The prepared document also contains an environmental score vector field that includes an explicit description of CVSS components for the calculated score.
4.4. Processing Module
The Processing Module is responsible for data enrichment when new data occurs. Using the system architecture designed to operate in the cloud computing network, an algorithm was implemented to process large amounts of data that depends on processing module configuration. Firstly, the algorithm downloads the number of vulnerabilities which have not been fixed or have been marked as removed. Then, the algorithm retrieves information stored in the system to assess the amount of available resources which can be used for calculations. The task division subject to available resources is assigned according to Equation (1).
(1)
where:- d
the number of data processed by one processing module
- t
the number of available processing modules
- v
the number of vulnerabilities that are not fixed or removed
Each time before calculations begin, the verification of the Equation (1) allows for vertical scaling without restarting the system. In order to accelerate the target distribution [33] value calculations, every CVE query is stored in the cache that is shared by all counting modules. As a result, only one counting module sends the query to the database at a time and the rest of the modules retrieve this information from cache. The vulnerability scores that have already been calculated are saved in a separate thread by bulk method [63]. As a result, the calculating loop does not require waiting for the result of the save operation.
5. VMC Implementation and Experiment Design
The VMC system was implemented on Microsoft Azure® Free Tier subscription [64]. Due to encountered limitations, the software was launched in two regions: US West and US West 2 that demonstrated the average latency of 22 ms during tests [65]. In region US West 2 the kubernetes cluster (k8s) was launched [66].
The US West 2 cluster consists of 2 servers each with 2× CPU Intel Xeon® E5-2673 v3 (Haswell) 2.4 GHz processors and 7 GB RAM memory and supports the following services:
VMC processing module
PostgreSQL database—storing VMC configurations
MariaDB database—storing CMDB information
Ralph—CMDB administration panel
Rabbitmq—queue system used for communication between VMC modules
Redis—in-memory base used for partial calculations storage and mutex support in VMC modules
VMC monitor—the monitoring of tasks performed by VMC
VMC admin panel—module for VMC management
In the region of US West Elasticsearch cluster was launched that consists of 2 servers with 1× CPU Intel Xeon® E5-2673 v3 (Haswell) 2.4 GHz processor and 3.5 GB RAM memory. Between the regions US West and US West 2, the network type virtual-network to virtual-network (VLan) has been created.
Thus, in summary, all components of the developed VMC run autonomously within a computer cloud environment. This approach allows for performing the vulnerability prioritization in a fully automatic manner. In the following part of this section the numerical experiments are described that show the relevance of each component of the system and the advantage of parallel processing. The application of parallel processing shortens the processing time and allows for an elastic response to increased data processing demand.
Thus, in order to show the relevance of automatic integration of the asset collector module, a network model with the distribution of operating systems was used as described in [67]. In order to investigate the behavior and the execution time of the proposed algorithms in the context of smart data, the network model was created containing 2110 IP addresses and had a simplified distribution of operating systems described in Table 1. The network contained 168,940 vulnerabilities of which 3008 vulnerabilities are unique with the distribution presented in Table 2.
Figure 2 shows CVSS Base histograms for the proposed model. With this set of vulnerabilities, three configurations of the CIA distributions as described in Table 3, Table 4 and Table 5 were studied.
Then, to test the advantages of vertical scaling for the processing module, the time gap between an occurrence of a case (P) and obtaining the final results concerning the CVSS environmental assessment was measured. For this purpose 12 test cases were considered:
—prioritization for the initial state,
—CIA value change for 10% of assets,
—CIA value change for 20% of assets,
—CIA value change for 30% of assets,
—10% of assets marked as DELETED,
—20% of assets marked as DELETED,
—30% of assets marked as DELETED,
—the increase of new vulnerabilities by 10%,
—the increase of new vulnerabilities by 20%,
—the increase of new vulnerabilities by 30%,
—10% of vulnerabilities marked as FIXED (fixing the vulnerability),
—20% of vulnerabilities marked as FIXED (fixing the vulnerability),
—30% of vulnerabilities marked as FIXED (fixing the vulnerability).
The simulations were repeated three times and afterwards the average value of the simulation time was calculated for each P. Each time simulations were repeated the VMC software was restarted in order to exclude the influence of optimizations performed automatically by autonomous VMC components, which are not the subject of the presented research, e.g., each time Elasticsearch handles the same request it uses cache to speed up operation. Such optimization of course influences the measured CPU time and thus distorts the calculated results and hence should be prevented from taking place.
6. Results
In this section, the main purpose is to verify the operation of the proposed software and for this purpose the test cases described in the previous section were used. First, the influence of the asset collector module on the CVSS scores is discussed. Figure 3 presents the CVSS 2.0 scores obtained for all 3 considered configurations (Table 3, Table 4 and Table 5). When compared with Figure 2a, significant difference in calculated CVSS scores is observed for all considered configurations. The highest CVSS 2.0 environmental assessments received for the tested configurations are 7.5 (High) [14]. The next step in analyzing the impact of CVSS factors on the threat assessment generated by the vulnerability is considering the confidentiality, integrity, and availability requirements. Figure 3a shows the result of vulnerability prioritization including CVSS environmental 2.0 vector element for an equal distribution of all CIA components (Table 3). The obtained results indicate that only 0.33% of vulnerabilities have high priority in comparison to 34% obtained for CVSS base 2.0 score (Figure 2a). Figure 3b shows that 1.51% of vulnerabilities receive a high priority score (the scoring higher or equal to 7) (Table 4). For configuration III (Table 5), with 70% of the CIA components having LOW level, the results indicate only 0.11% of vulnerabilities with high CVSS score.
For CVSS environmental 3.1 scoring the observed changes in prioritization in the applied configurations are:
configuration I, the decrease of critical and high vulnerabilities by 30% (Figure 4a) in comparison to CVSS base 3.1 (Figure 2b),
configuration II, the increase of critical and high vulnerabilities by 30% (Figure 4b) in comparison to CVSS base 3.1 (Figure 2b),
configuration 3, the decrease of critical and high vulnerabilities by 50% (Figure 4c) in comparison to CVSS base 3.1 (Figure 2b).
Thus the impact of integrating CVSS base scores with information available from CMDB is large so that a significant reprioritizing after including CVSS environmental information has to take place. It is noted, however, that depending on the nature of the monitored infrastructure, the distribution of CIA values may differ from the one adopted in the research. Nonetheless, results obtained confirm that maintaining an up-to-date CMDB database and its integration with the vulnerability scan results increases the level of security services.
Next, the results concerning vertical scalability of the software are considered. Figure 5 shows the influence of changes on time consuming proposed test cases in section VMC Implementation and Experiment Design. measurements were conducted to relate to changes caused by P to the initial phase of the system. Test cases , , , , , reduce the amount of active vulnerabilities for which calculations must be made. Therefore, the reprioritization time is lower than the one obtained for . For , , the calculation time is similar to and stems from the nature of CVSS 2.0 environmental assessment. The influence of the CIA changes in CMDB is unnoticeable and concerns only the additional overhead related to updating data related to individual IP addresses. A significant time increase compared with case was noticed for , , cases since these latter cases add new vulnerabilities to the modeled network. For all cases considered, the most significant decrease in the calculation time is observed after adding 2 processing module instances (Calculation time reduction circa 45%.) The optimal number of processing module instances of the cloud computational environment described in Experiment Design section totals 5 (the average calculation time reduction by 65%). The highest calculation time reduction of 70% was obtained for and 6 processing module instances.
In comparison to solutions presented in literature [37,49,50,51] the developed VMC software package takes into consideration the value of assets and is adjusted to the increasing amount of data in cloud computing environment. Therefore, the developed VMC can be applied for every network infrastructure. Additionally, none of the presented solutions [37,49,50,51] and [6,7,8,9] offer prioritization for CVSS 2.0 and CVSS 3.1 simultaneously. Thanks to the use of CVSS environmental score, the stakeholders using the developed VMC fully understand the nature of received vulnerability prioritization and can trace back all steps for the all received scores.
7. Conclusions
The obtained results present a fully automated vulnerability management platform. It was demonstrated that the inclusion of an asset collector module has a major impact on the CVSS scores. This fact shows that it is possible to maintain and operate with an open software platform that uses a well known open scoring system presenting reliable results. The vertical scalability of the developed software was also studied and demonstrated that the developed VMC is capable of processing the increasing amount of data. The results obtained show also that the developed VMC supports VM automation by:
calculating CVSS Environmental vector component, reducing thereby the workload for stakeholders,
fully scalable implementation, thus enabling processing large amounts of data in corporate environments [31],
creating the dynamic metrics adjusted to corporate requirements.
In conclusion, comparing to solutions presented in literature [37,49,50,51] the developed VMC software package takes into consideration the value of assets and is adjusted to the increasing amount of data in cloud computing environment. Therefore, the developed VMC can be applied for every network infrastructure. Additionally, none of the presented [37,49,50,51] and [6,7,8,9] offer prioritization for CVSS 2.0 and CVSS 3.1 simultaneously.
The future work will focus on developing machine learning algorithms that predict each CVSS 3.1 vector component derived from public CVE databases. This issue is very important because all the vulnerabilities have not been evaluated using CVSS 3.1 metric and most of the available scores are based on CVSS 2.0 [18] metric only. However, the predicted vector components of CVSS 3.1 allow calculating the environmental score for all vulnerabilities coming from scanning software. This may further reduce time-to-vulnerability-remediation and total-vulnerability-exposure and facilitate the network administration by bringing focus to genuine deficiencies present within the infrastructure.
Author Contributions
All authors have read and agreed to the published version of the manuscript.
Funding
Wrocław University for Science and Technology, grant No CYBERSECIDENT/381690/ II/NCBR/2018 from National Centre for Research and Development within the CyberSecIdent-Cybersecurity and e-Identity program.
Acknowledgments
The authors wish to thank Wroclaw University of Science and Technology (statutory activity) for financial support and Agata Szewczyk for proofreading and translation. This publication was created as a part of the Regional Security Operations Center (RegSOC) project (Regionalne Centrum Bezpieczeństwa Cybernetycznego), cofinanced by the National Centre for Research and Development as part of the CyberSecIdent-Cybersecurity and e-Identity program.
Conflicts of Interest
The authors declare no conflict of interest.
Abbreviations
The following abbreviations are used in this manuscript:
| API | Application Programming Interface |
| CIA | Confidentiality, Integrity and Accessibility |
| CMDB | Configuration Management Database |
| CVE | Common Vulnerabilities and Exposures |
| CVSS | Common Vulnerability Scoring System |
| DCIM | Data Center Infrastructure Management |
| ID | Identification |
| IDS | Intrusion Detection System |
| IoT | Internet of Things |
| IPS | Intrusion Prevention system |
| IT | Information Technology |
| K8S | Kubernetes cluster |
| NVD | National Vulnerabilities Database |
| OVM | Ontology for Vulnerability Management |
| P | Proposed Test cased |
| SOC | Security Operations Center |
| TD | Target Distribution |
| US | United States |
| VA | Vulnerability Assessment |
| VLAN | Virtual Local-Area Network |
| VM | Vulnerability Management |
| VMC | Vulnerability Management Centre |
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Figures and Tables
Enlarge this image.Figure 5. The time consumption in proportion to the number of processing module used and proposed P.
Distribution of operating systems.
| Name | Value | Name | Value |
|---|---|---|---|
| Redhat 5 | 18.48% | IBM AIX 6 | 4.27% |
| Redhat 6 | 19.67% | IBM AIX 5 | 5.69% |
| Redhat 7 | 18.96% | IBM AIX 7 | 4.03% |
| Windows Server 2016 | 7.82% | Debian 8 | 2.13% |
| Windows Server 2019 | 8.06% | Debian 9 | 1.41% |
| Windows Server 2012 | 7.58% | Debian 10 | 1.9% |
Distribution of vulnerabilities with operating systems division.
| Name | Value | Name | Value |
|---|---|---|---|
| Redhat 5 | 6.53% | IBM AIX 6 | 0.8% |
| Redhat 6 | 27.33% | IBM AIX 5 | 1.11% |
| Redhat 7 | 26.46% | IBM AIX 7 | 1.01% |
| Windows Server 2016 | 13.11% | Debian 8 | 2.32% |
| Windows Server 2019 | 8.6% | Debian 9 | 1.8% |
| Windows Server 2012 | 10.03% | Debian 10 | 0.9% |
Distribution of CIA requirements for configuration I.
| Name | Low | Medium | High | N.D. |
|---|---|---|---|---|
| Confidentiality | 25.36% | 22.99% | 23.7% | 27.96% |
| Integrity | 22.99% | 25.12% | 25.12% | 26.78% |
| Availability | 23.93% | 25.83% | 30.33% | 19.90% |
Distribution of CIA requirements for configuration II.
| Name | Low | Medium | High |
|---|---|---|---|
| Confidentiality | 10.19% | 7.82% | 81.99% |
| Integrity | 8.29% | 10.9% | 80.81% |
| Availability | 9.25% | 10.66% | 80.09% |
Distribution of CIA requirements for configuration III.
| Name | Low | Medium | High | N.D. |
|---|---|---|---|---|
| Confidentiality | 76.3% | 9% | 6.88% | 7.82% |
| Integrity | 74.64% | 8.06% | 8.77% | 8.53% |
| Availability | 73.22% | 9.48% | 8.53% | 8.77% |
© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.