Automated Context-Aware Vulnerability Risk Management for Patch Prioritization

Abstract

The information-security landscape continuously evolves by discovering new vulnerabilities daily and sophisticated exploit tools. Vulnerability risk management (VRM) is the most crucial cyber defense to eliminate attack surfaces in IT environments. VRM is a cyclical practice of identifying, classifying, evaluating, and remediating vulnerabilities. The evaluation stage of VRM is neither automated nor cost-effective, as it demands great manual administrative efforts to prioritize the patch. Therefore, there is an urgent need to improve the VRM procedure by automating the entire VRM cycle in the context of a given organization. The authors propose automated context-aware VRM (ACVRM), to address the above challenges. This study defines the criteria to consider in the evaluation stage of ACVRM to prioritize the patching. Moreover, patch prioritization is customized in an organization’s context by allowing the organization to select the vulnerability management mode and weigh the selected criteria. Specifically, this study considers four vulnerability evaluation cases: (i) evaluation criteria are weighted homogeneously; (ii) attack complexity and availability are not considered important criteria; (iii) the security score is the only important criteria considered; and (iv) criteria are weighted based on the organization’s risk appetite. The result verifies the proposed solution’s efficiency compared with the Rudder vulnerability management tool (CVE-plugin). While Rudder produces a ranking independent from the scenario, ACVRM can sort vulnerabilities according to the organization’s criteria and context. Moreover, while Rudder randomly sorts vulnerabilities with the same patch score, ACVRM sorts them according to their age, giving a higher security score to older publicly known vulnerabilities.

Automated Patch Management: An Empirical Evaluation Study

“…• Case 1: PM based on the patch prioritization list in our previous work [5], where the PS determines the patch order. In this case, there is no automated review of the patch prioritization.…”

“…In our previous work [5], we designed and implemented phase 2 of ACVRM, patch prioritization without a feedback loop from the patch verification task in phase 3. Moreover, the review prioritization block (cf.…”

“…Figure 2) used only the patch score (i.e., the score is calculated by weighting the selected criteria in the context of the organization for each vulnerability) to determine the patch order. We discovered our method in [5] needs improvement because historical data and practical experience are the inevitable factors to increase the success rate of patch [28]. We also learned from the practical experience shared in the patch management community of experts 3 , some patch failures could be avoided by prioritization (e.g., patching a microcode vulnerability in Ubuntu requires the kernel to be patched in advance; otherwise, the mitigation failed).…”

“…Each module represents the implementation of each stage and the output of each module is the input for the next one. Phase 2 PoC implementation was described in [5]; hence is omitted in this paper. The output of phase 2 is a patch prioritization list (patch_prioritization.json) for each host in the organization, and it is the input to phase 3.…”

“…The collected data identifies existing vulnerabilities in the organization's assets. In phase 2 described in [5], we automatically scan the organization's asset inventory against the collected data to detect the vulnerabilities that affect the organization. We defined the criteria to be considered in patch prioritization via literature study and experts interview.…”