# Vulnerability Management Models Using a Common Vulnerability Scoring System
## 4 Methods  
In order to evaluate the vulnerability management models presented here, the newly developed VMC software was used [12]. The VMC consists of four core modules: a Knowledge Collector, Asset Collector, Vulnerability Collector, and Processing Module. Figure 3 depicts the architecture of the VMC. The first three modules are responsible for downloading data from different parts of a corporate network. The fourth module, which is also known as the calculative module, provides results as they become available. All modules work independently, communicating asynchronously by using a queue system. Due to this, the VMC is vertically scalable, leaving no damage for the remaining components. The system is configured from the administrator panel. The Module Scheduler controls the sequence and the time of synchronization of the data download from the particular sources. The Task Monitor, on the other hand, gives the opportunity to preview the current state of the system. The entire solution was prepared with the aim of cooperation in the cloud computing environment and is based on the Docker Container technology [19; 44]. All data are stored in Elasticsearch [45], which enables processing of the data in full-text mode, while the Kibana tool [46] is used to  
Figure 3: Simplified architecture of the newly developed VMC software. Figure 2: Model of the flow of information in the vulnerability management process with the CVSS 2.0 environmental score. present the results. In order to implement the components described below, Python was used due to its flexibility and efficient data processing ability on the server side. The whole project includes multitenancy support, which allows for comprehensive separation of data between the documents. Additionally, the VMC functions in two modes: operational and historical. Due to this, the analyst is able to see all changes on an ongoing basis. In addition, this enables one to preview data and historical calculations, thus facilitating, at the same time, the analysis of the events in system. Detailed descriptions of each of the module were presented in [9, 41]. In order to quantitatively assess the performance of the models proposed above, the number of work hours required to remove a vulnerability within a cycle of the vulnerability management process [33] is estimated. In order to obtain the number of work hours, the vulnerabilities are divided into one of three possible categories:  
* From 1 to 3 h (vulnerabilities such as weak encryption methods, default password change, or configuration change);
* From 3 to 6 h (vulnerabilities such as software updates);
* From 6 to 9 h (vulnerabilities such as operating system updates). Using the work hour ranges mentioned above, the vulnerability repair time (\(T_{FIX}\)) was divided into three subcategories in consideration of the number of hours required for repair: \(T_{FIX_{MAX}}\) represents the maximum number of work hours required to fix one vulnerability and was assumed to be equal to 9 h; \(T_{FIX_{AVERAGE}}\) is the average number of work hours required to fix one vulnerability and was assumed equal to 4.5 h; \(T_{FIX_{MIN}}\) is the minimum number of work hours and is assumed equal to 1 h. Then, the equations that were used to estimate the number of work hours required to improve the security of ICT infrastructure were derived by implementing the models discussed in the Related Work section. Assuming that all vulnerabilities of a critical (\(X_{C}\)), high (\(X_{H}\)), and medium (\(X_{M}\)) severity must be fixed by administrators, the number of work hours required to improve security with the suggested models can be expressed as the sum of the constituent time spans required to fix each type of vulnerability complemented by the time needed for information processing and other operations, e.g., scan duration (\(T_{5}\)) [43, 47].