0% found this document useful (0 votes)
121 views

A Contextual Approach To Vulnerability Prioritization

Today's computing devices comprise thousands of vulnerabilities, leading to a data breach via hacking and interrupting its services, coursing collateral damages to organizations. Information security practitioners strongly believe that vulnerability management's best practice is to prioritize vulnerabilities by identifying the critical vulnerabilities that could have a crucial impact on the organization and thereby applying patches or workarounds to mitigate those vulnerabilities.

Uploaded by

Indika Jayaweera
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
121 views

A Contextual Approach To Vulnerability Prioritization

Today's computing devices comprise thousands of vulnerabilities, leading to a data breach via hacking and interrupting its services, coursing collateral damages to organizations. Information security practitioners strongly believe that vulnerability management's best practice is to prioritize vulnerabilities by identifying the critical vulnerabilities that could have a crucial impact on the organization and thereby applying patches or workarounds to mitigate those vulnerabilities.

Uploaded by

Indika Jayaweera
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 57

FACULTY OF ENGINEERING AND COMPUTING

School of Computing
MSc. Network & Information Security

Indika Jayaweera

A Contextual Approach to Vulnerability


Prioritization
Sep 2020
WARRANTY STATEMENT
This project is considered as a student project. Therefore, neither the student nor University makes
any warranty, express or implied, as to the accuracy of the data or conclusion of the work
performed in the project and will not be held responsible for any consequences arising out of any
inaccuracies or omissions therein.

i
Acknowledgement

MSc is a once-in-a lifetime opportunity and experience. My sincere gratitude to the Kingston
University for extending MSc program for international students and ESOFT Metro campus to be a
part of this valuable endeavors. Also, my sincere gratitude to my family and batch mates for
encouraging me throughout the studies.

ii
Abstract

Today's computing devices comprise thousands of vulnerabilities, leading to a data breach via hacking and
interrupting its services, coursing collateral damages to organizations. Information security practitioners
strongly believe that vulnerability management's best practice is to prioritize vulnerabilities by identifying
the critical vulnerabilities that could have a crucial impact on the organization and thereby applying patches
or workarounds to mitigate those vulnerabilities. Because that would provide a reasonable time to fix the
rest of the vulnerabilities with regular planning and testing approaches; however, with an overwhelmed
amount of vulnerabilities, security teams do not have a real clue of what vulnerability should be fixed
immediately in their environment. The Common Vulnerability Scoring System (CVSS) by the National
Vulnerability Database (NVD), which defines the vulnerability's severity, helps in such prioritization. Still,
it does not provide accurate results all the time. Many researchers have highlighted that the seriousness of
vulnerabilities varies significantly as per different organizational contexts, and organizations should not
depend on the CVSS scoring when it comes to prioritization.

The major dilemma here is the absence of a simple way to bring together vulnerability scan data and
organizational contextual data such as publicly available exploits, Asset criticality, exposure, Indicators of
compromise (IOCs), threat intelligence details of the vulnerability, existing controls in the organization. To
analyze the factors requires a significant amount of work to analyze, integrate, and prioritize the data.

Vulnerability prioritization, according to the organizational context, is an increasingly challenging task


which requires a smarter approach based on the contextual information of the individual organization. The
proposed methodology entails associating those contextual data into the existing CVSS score and creating
a high accuracy level vulnerability prioritization score. This analysis model results show that vulnerabilities
can be prioritized based on the contextual data related to each exposure, and the application of these
contextual data added more meaningful insights to the security vulnerabilities.

iii
Contents
Chapter 1: - Introduction & Background.......................................................................................... 1
1.1 Prolegomena ....................................................................................................................... 1
1.2 Background and Motivation .................................................................................................. 3
1.3 Structure of the Thesis.......................................................................................................... 4
1.4 Measuring what matters in the vulnerability remediation .......................................................... 4
1.5 Proposed Solution -Contextual Methodology for Vulnerability Prioritization .............................. 7
Chapter 2: - Aim and Objectives..................................................................................................... 9
2.1 Aim ................................................................................................................................ 9
2.2 Objectives ....................................................................................................................... 9
Chapter 3. Related Works – Vulnerability Prioritization .................................................................11
Base....................................................................................................................................19
Temporal .............................................................................................................................19
Environmental .....................................................................................................................20
Chapter 4. Contextual model of vulnerability prioritization ..............................................................24
3. Technology .............................................................................................................................24
4. Design ................................................................................................................................26
5. Implementation ....................................................................................................................29
6. Evaluation ...........................................................................................................................32
7. Conclusion and Future Work .................................................................................................33
References ..................................................................................................................................34
Appendices .................................................................................................................................. 1

iv
List of Figures/Tables

Figures
Figure 01: Aim to identify prioritized vulnerabilities with contextual vulnerability
prioritization model
Figure 02: Attack Complexity
Figure 03: Privileges required
Figure 04: Availability metric
Figure 05: Maturity of Exploit
Figure 06: Environmental Metric
Figure 07: CVSS2 vs CVSS3
Figure 8: system Diagram, high level
Figure 9: Relational data model
Figure 10: Application logic diagram
Figure 11: Vulnerability Priority and CVSS score – Heat map

Tables
Table: 01 CVSS V3 Calculation
Table2: Contextual data utilization to the vulnerability prioritization – mapped with CVSS
Scoring
Table 3: vulnerability prioritization score calculation chart

v
Glossary of Terms

Vulnerability - A weakness of an asset or group of assets that can be exploited by one or more
threats
CVSS – Common Vulnerability Scoring system
NVD – National Vulnerability Database
CVE – Common Vulnerability Exposure
NIAC - National Infrastructure Advisory Council
PCI-DSS – Payment Card Industry Data Security Standard
NIST- National Institute of Standardization and Technology
VPS -Vulnerability prioritization Score
POC – Proof of Concept
IPS - Intrusion Prevention Systems

vi
Chapter 1: - Introduction & Background

1.1 Prolegomena

Vulnerability prioritization is a tedious and time-consuming task for the organizations. Analyzing and
resolving vulnerabilities are core tasks of security teams and one of the most complex activities in
organizational security management. [1]

A vulnerability is defined in the ISO 27002 standard as “A weakness of an asset or group of assets that
can be exploited by one or more threats” [International Organization for Standardization, 2005]. The
process of identifying vulnerabilities and evaluate the risks consisted with these vulnerabilities can be
identified as vulnerability analysis. In order to support this process, various vulnerability scan and analysis
systems are available in the industry and many companies are adhered to use one or more solutions to
manage their vulnerabilities in the organization.

Vulnerability management vendors such as Tripwire, Tenable, Qualys usually rely on the standard
vulnerability scoring system (CVSS)introduced by the National (U.S) vulnerability Database (NVD) for
their assessments. Many organizations use CVSS scores as a metric for risk, even though CVSS is invented
to measure severity. The organization "First.org" has been drafted the CVSS framework to evaluate
computer information security vulnerability's different security levels. And NVD describes various
qualities of these vulnerabilities, which can be seen in common. These qualities called "vectors" and these
vectors get an individual score as per the severity that brings to the vulnerability. By defining the severity
of vulnerabilities, organizations were able to define vulnerability management policies. Certain standards,
such as PCI-DSS, described that vulnerabilities with CVSS scores 5 and above should be mitigated to be
complaint to the standard. [PCI Council 2010]."Generally, to be considered compliant, a component must
not contain any vulnerability that has been assigned a CVSS base score equal to or higher than 4.0."
However, with overwhelming vulnerabilities challenges, this methodology since vulnerabilities with
lesser CVSS Score gets exploited and weaponized in the cybersecurity world.

1
Security consultants have gradually identified certain other factors required to consider vulnerability
analysis, such as exploitation, active exploits, and Threat intelligence feeds about vulnerability
weaponization. With the recent increase of ''zero-day attack'' vulnerability identification and classification
have become more challenging, specific vulnerabilities are being exploited even before it is registered in
the CVE / NVD database.

The Common Vulnerability Scoring System (CVSS) is widely misused for vulnerability prioritization and
risk assessment, despite being designed to measure technical severity. Furthermore, the CVSS scoring
algorithm is not justified, either formally or empirically. First.org and NVD have collectively issued the
latest CVSS V3 scoring methodology adding temporal and Environmental scores to the vulnerability
severity to address some of the concerns raised by the information security communities. However, the
CVSS base score is the primary vector string used by NVD to calculate the CVSS score since the limitation
of data unavailability at the time of releasing the vulnerability rating. Hence, the NVD changes to the
CVSS calculation methodologies do not resolve the burning issue of prioritization.

Information security teams are continually struggling to fix these vulnerabilities using patching, upgrading
firmware, registry key value fixing, software bug fixing, application workarounds and applying additional
infrastructure controls to the environment. With an overwhelmed amount of vulnerabilities, security teams
do not have a real clue of what vulnerability should be fixed immediately in their environment, instead
follows the relative severity scores as stated by the Common Vulnerability Scoring System (CVSS).
However, CVSS score does not reflect the important contextual data in the organization such as;

• Asset value and exposures


• Existing controls of the environment
• IOCs (Indicators of Compromise)
• Threat Intelligence data

The methodology discusses in this paper open a new thought process to vulnerability prioritization and
critically evaluates the drawbacks of existing scoring methodologies. The solution provides in this paper
associate above information also to the basic CVSS Score to achieve an accurate vulnerability
prioritization results so that organizations can easily set up their task towards fixing these vulnerabilities.

2
1.2 Background and Motivation

As an information security professional responsible for fixing security vulnerabilities in my organization,


I realized that number of vulnerabilities added to the CVE database is increasingly high and many of them
can be exploited in corporate IT infrastructure irrespective of the operating systems and firmware versions
of IT assets. After identifying a huge amount of vulnerabilities, prioritizing the vulnerabilities to apply
fixes is a challenge. Because, organizations need to identify the vulnerabilities which could exploit in the
organization and the prioritize the actions taken by the organization to fix those vulnerabilities. In fact, as
at 2020, more than 40000 vulnerabilities have been added to the National vulnerability database (NVD).
However, more than 50% of exploits available in public are exploiting the vulnerabilities which has been
identified and severity score 6 and below by the NVD. More than 30% of the reported exploits were
references or traded in the dark web and only 130 vulnerabilities reported last year (2019) were
weaponized into malware as per the cyber research papers. When considering all these facts, the primary
dilemma that security specialists face daily is overwhelmed vulnerabilities to be fixed in the technical
environment, yet neither adequate resources can achieve these goals of zero vulnerability. Hence,
maintaining the number of vulnerabilities to an acceptable level has become an unrealistic goal for many
companies in the world. Many organizations tend to use organizational policies and procedures to manage
the vulnerability fixing efforts, such as defining risk-based criteria and CVSS score-based measures such
as ex:- fix vulnerabilities higher than CVSS 5.0. However, these approaches could contain certain risks,
such as not fixing the exploitable vulnerabilities with CVSS sore value, which is less than 5.0. Hence, to
address these complexities, I was motivated to evaluate the contextual data of the vulnerability and create
a score for prioritization.

3
1.3 Structure of the Thesis
This thesis has been structured with three chapters. Chapter 1 has been allocated to introduce the project.
This chapter discusses the problem of vulnerability prioritization. Moreover, what motivates to research
this issue. Problem identification and the solution are also discussed in brief in chapter one. Chapter two
describes the aim and objective of the project. Chapter three dedicated for related work to gain an
understanding of the vulnerability prioritization issue and find out what methodologies and critically
evaluate the methodologies based on the previous researches been carried out on this topic. Chapter four
in this paper discuss about the contextual model created for vulnerability prioritizations and its technology,
design and implementation. Further, the evaluation of results of this model and conclusion suggesting
areas of development.

1.4 Measuring what matters in the vulnerability remediation


Millions of organizations attempt to proactively identify and apply patches and workarounds to every
potential cybersecurity vulnerability to be protected from all known vectors of attack. However, with
numerous vulnerabilities emerging daily, this goal is not realistic for medium and large organizations. One
of the biggest problems is accurately determining which vulnerabilities present the most significant risk
so that remediation efforts can be prioritized.
The severity of the vulnerability defined by the CVSS score is primarily based on the "Base" score only,
without considering the "temporal" and "Environmental" attributes taken into consideration for in the
Score. The severity of the vulnerabilities listed in the NVD, the most common reference point for CVSS
scores, leverage "Base" scores only.
Common Vulnerability Scoring System (CVSS) v3:
CVSS is a commonly accepted standard for describing and communicating software vulnerabilities'
characteristics and their severity. CVSS Score was founded by the National Infrastructure Advisory
Council (NIAC) and use in the National Vulnerability Database (NVD) of the National Institute of
Standards and Technology (NIST). However, these scores do not reflect each organization's vulnerability
exposure since this typically looks at the common characteristics of vulnerabilities. [1]

4
Limitations of the CVSS -
The existing Common Vulnerability Scoring System (CVSS) scores provide the baseline standard for
identifying and recording the severity of vulnerabilities. The CVSS Base matric, which is used for defining
the severity of the vulnerability at the time of registering the vulnerability to the National Vulnerability
Database (NVD), omits information about a vulnerability's context. Authors like Rieke acknowledge that
problem and advise that "prioritizing of vulnerabilities based on such measures should be used with
caution" [3]

CVSS has the following limitations:

• CVSS framework does not consider the individual, organizational context.


• It lacks the granularity needed to provide a precise measure of criticality of the vulnerability. For
example, to generate a score, CVSS only looks at if the vulnerability could be exploited in future-
not if it is being exploited.
• CVSS is a rather static number and does not change in response to changes in the threat landscape
as vulnerabilities are weaponized.
• Most vulnerabilities are scored through CVSS as 'high' or 'critical', thus creating an overload of
vulnerabilities to remediate.
• There are vulnerabilities that rank as "low risk," but those vulnerabilities are easily exploitable in
specific organizations.

For example, a vulnerability X with a high CVSS score may not be exploitable in company A because the
network architecture and security policies provide enough defence. In contrast, company B would have
weak infrastructure controls, which is easy to exploit X's vulnerability. Besides, a high- severity
vulnerability that has been identified in a low-value asset (according to the risk-based asset classification
or general importance of the asset) is less important to fix, and the security team should be analysed
potential attack vectors against the mitigating controls already in place when prioritizing the
vulnerabilities for remediations. Moreover, threat intelligence information plays a significant role in
identifying available exploit kits for each vulnerability and potential impact on the organization assets if
exploitation is successful.

5
When a new vulnerability is identified, this contextual analysis is essential to prioritize the efforts towards
fixing the vulnerability and other mitigation strategies such as changing firewall rules or intrusion
prevention system (IPS) policies. However, Vulnerability prioritization, according to the organizational
context, is an increasingly challenging task that requires a smarter approach based on the contextual
information of the individual organization.

The existing Common Vulnerability Scoring System (CVSS) scores. CVSS has the following significant
limitations:

1. It lacks the granularity needed to provide a precise measure of criticality. For example, to generate
a score, CVSS only looks at if the vulnerability could be exploited as per the vectors such as
network, adjacent, physical- not if it is being exploited.
2. CVSS score can be identified as a relatively static number that does not change when the threat
landscape as vulnerabilities are weaponized.
3. Most vulnerabilities are scored through CVSS as 'high' or 'critical,' thus creating an overload of
vulnerabilities to remediate.
4. Some vulnerabilities rank as "low risk," but those vulnerabilities are easily exploitable in specific
organizations.

Because the Base- Metric is oblivious of an organization's context, usage of NVD scoring solely for
vulnerability prioritization is not a recommended practice. although the CVSS scores are an essential
aspect of getting un understanding about the risk a vulnerability poses to the organization, knowing the
likelihood of its exploitability should also be given adequate consideration.

Certain number of vulnerabilities which does have a most pressing requirement for remediation have a
possibility to be hiding in the large sum of vulnerability scan reports: for example, a vulnerability with
medium severity CVSS may be have active exploits in the cyber world while a vulnerability with critical
-severity score, yet no exploit code is available. in this scenario, an attention to remediate the medium
severity vulnerability is important than the vulnerability with critical CVSS score.

6
In order to concentrate on remediation efforts on the miniature subset of vulnerabilities possible to be used
in an attack, organizations need to use a context-based approach, which anticipates vulnerability risk based
on:

• Exploit activity in the world


• Exploit use in packaged crimeware (e.g., ransomware, exploit kits)
• Exploitation availability and potential impact
• Asset value
• Asset exposure

These last two factors such as asset value, and exposure are, of course, specific to each unique
organization. That is the reason why it is significantly important to stay informed of changes both in the
threat landscape and within the own infrastructure and correlate this contextual information to prioritize
remediation strategy correctly. the value of these insight will also help organizations to consider the
compensatory controls security controls such as firewalls and intrusion prevention systems (IPS).

1.5 Proposed Solution -Contextual Methodology for Vulnerability


Prioritization
In the proposed solution, a new vulnerability scoring methodology will be developed adding contextual
scoring criteria to the existing Common Vulnerability Scoring System (CVSS) and this new vulnerability
scores will be assessed against the CVSS scoring to compare the effectiveness and accuracy using sample
set of real-world vulnerabilities.

Input: Gathering vulnerability data and contextual data in each organization

In the proposed solution vulnerability scan data will be gathered from multiple sources such as various
industries and various firmware, software technologies. Basic vulnerability data will be associated with
the contextual data such as asset value and asset exposure in the organization current exploit data from
threat Exploitation availability and potential impact of exploitation, existing controls that can prevent the
vulnerability and total coast of resolving vulnerability.

7
Process: Changes in vulnerability scores and prioritization:
After gathering vulnerability data and context data, the data of all analyzed associating context data criteria
and re calculate the vulnerability score.

Output: Modified equation to calculate vulnerability scoring thus its ranking in a


prioritization

The addition of context information into the CVSS score of each vulnerability changes the overall score
of a vulnerability and thus its ranking in a prioritization.

There are numerus vulnerability scan and integration solutions available and some of them are open source
and free solutions. The proposed project will use multiple scan outputs as input data to the prioritization
model coupled with the organizations contextual data as we discussed in section 01 & 03. The expected
sample size of the vulnerability scan is 100 hosts including multiple Operating systems and firmware
versions including mobile devices and web applications since it is important to select a sample with
different platforms to check the accuracy over the final vulnerability priority score.

The developed methodology will be assessed against the initial CVSS score to compare the results to
identify which method is more accurate for vulnerability prioritization. This model will be distributed
among a selected information security professional to re-validate the accuracy and identify the areas of
enhancement. The model will be developed using open source tools and published to the open source
DevOps platform such as ‘GitHub’.

The objective of this project is to create a method as an artifact that can be used by security analysts &
information security professionals to estimate the vulnerability response improvements, they can achieve
within their organization’s information systems by investing in better vulnerability scoring.

8
Chapter 2: - Aim and Objectives
2.1 Aim
Aim of the project is to develop a contextual methodology to prioritize vulnerabilities which can be used
by any organization and make available as an open source tool.

Figure 01: Aim to identify prioritized vulnerabilities with contextual vulnerability prioritization
model

2.2 Objectives
a) To critically review NVD – CVSS vulnerability scoring methodology and limitations of usage to
prioritize vulnerabilities.
b) To critically review the contextual data that can be used to prioritize vulnerabilities.
c) To gather vulnerability data and by applying contextual information
d) To design a methodology and an open source tool
e) To evaluate the solution and further improvement points.

Conduct an in-depth review of NVD vulnerability scoring methodology as well as other scoring methods
of industry-leading vulnerability management platform would be the first step. It also important to gather
data of factors considering by security analysis to prioritize the vulnerabilities and challenges they face
when prioritizing vulnerabilities. Next step is to analyze sample vulnerability data by applying contextual
information and interpretation of results. After designing an open source tool to community usage, it is

9
important to Identify the Impact of improving the quality of vulnerability scoring methodology (by
comparing changes in the CVSS scores after applying the contextual scores) and effectiveness of the
response process.

10
Chapter 3. Related Works – Vulnerability
Prioritization

This section describes related literature in software vulnerability identification, scoring, categorization,
analysis, and vulnerability mitigation, often referred to as vulnerability management. Primarily, a review
of recent research was conducted in CVSS scoring and identified deficiencies of the scoring matrices.
Secondly, recent work related to different approaches to vulnerability severity scoring and data-driven
solutions for vulnerability prioritization. Literature and concepts from the foundational areas of
vulnerability prioritization are reviewed.

The requirement of developing a standard for ever-increasing vulnerabilities identified by security


researchers and the National Institute of Standard and Technology (NIST) established the Common
Vulnerability Scoring System (CVSS). CVSS is an open framework to recognize and communicate the
characteristics of a software vulnerability. As a standard measure of the vulnerability's severity, the vector
score is scaled in 0 to 10 range, and the highest severity is defined as 10. The National Vulnerability
Database (NVD) provides CVSS scores for reasonably all known vulnerabilities, and CVSS scores as a
factor in the prioritization of vulnerability remediation activities have become an industry measure.

A significant restriction for this type of study is the nature of the data at hand. Vulnerability information
is widespread, and exploitation data is usually difficult to find.
A common presumption made in academy and enterprise is that proof-of-concept exploits data to measure
the state of security of software. Whereas proof-of-concept exploits data is hugely more accessible to
obtain than data on actual attacks, a proof-of-concept exploit is merely a byproduct of the ‘responsible
vulnerability disclosure’ process, whereby a researcher that finds a vulnerability exposes it to the vendor
alongside a proof-of-concept exploitation code that proves the presence of the vulnerability. [7]

11
3.1 The CVSS approach for Vulnerability Scoring

The Base metric has developed Considering the characteristics of the vulnerability which will remain
constant over the time it’s been identified and modified based on the deep dive analysis results of the
vulnerability. Two major areas of consideration are exploitability and impact of the exploit. When it comes
to the exploitability of the vulnerability CVSS has further drill down to Attack vector, Attack Complexity,
privileges and if any user interaction is required or not. Moreover, the impact to the confidentiality,
availability and integrity of the asset contains the vulnerable component. [4]

3.1.1 Base Metric

Attack Vector
The attack vector describes how an attacker can reach the vulnerable component. An attacker can reach a
vulnerable component that is bound to the network stack via the internet, which is often defined as
remotely exploitable or 'Remote.'

If the attack is restricted at the protocol level to a logically adjacent topology irrespective of the fact that
vulnerable component is bound to the network, this will be defined as an 'adjacent' vector. (e.g., a
vulnerability which is possible to exploit through Bluetooth or IEEE 802.11) or logical (e.g., local IP
subnet)

Although the vulnerable component is not connected to the network, if there is a possibility to exploit the
vulnerability via methods such as using social engineering techniques to trick a legitimate user into
opening a malicious document, those properties are defined as 'Local.' If an attacker needs physical access
to the vulnerable component to exploit it, such as peripheral attacks via FireWire/USB Direct Memory
Access (DMA), the attack vector is defined as 'physical.' With the assumption of a number of potential
attackers for a vulnerability that could be exploited from across a network, it is larger than the number of
potential attackers that could exploit a vulnerability requiring physical access to a device and, therefore,
warrants a higher Base Score. [5]

12
Figure 02: Attack Complexity
Attack Complexity
Attack complexity provides information on the difficulty the attacker may encounter when recreating the
conditions for exploiting the vulnerability. This assessment can assume three values:- High (H), Medium
(M), or Low (L).

Privileges required
The necessity of privileges represents the number of steps of authentication an attacker has to pass in
order to trigger the vulnerability. The levels of the assessment can be None (N), Single (S), Multiple
(M). Since this metric measures the number of attempts required an attacker to authenticate in order to
exploit a vulnerability, the fewer authentication instances that are required, the higher the score.

Figure 03: Privileges required

13
Impact Metrics
The effects to the assets as a result of successfully exploiting the vulnerability can be measured as impacts
and of those elements categorized as High, Medium and Low. Whenever a new vulnerability identified,
the severity of that vulnerability will be defined using the base matric.

Confidentiality Metric
The impact on data confidentiality measures as per the possibility of the information that can be disclosed
as a result of a successful attack. if the attacker can obtain all information from the impacted component
or critical information disclosed with the exploitation, the confidentiality impact scored as 'High.' whereas
if an attacker can obtain some information without control over the degree of confidentiality, the score
defined as 'Low.'

Integrity Metric
The impact on data integrity measures as per the possibility of the information that can be modified as a
result of a successful attack. if the be attacker can modify all information from the impacted component
or the modified information is critical; the integrity impact score value would be 'High,' and if an attacker
can modify some information without control over the degree, the score defined as 'Low.'

Availability Metric
The availability score defines based on the impact on the availability of the asset as a result of
compromising the vulnerable component. The score will mark as None if there is no availability impact.
The score will mark as Low if the affected resources are non-critical. The affected resource is entirely
unavailable or critical and interrupted the service/ asset that would consider as a High availability impact.

The scoring process first calculates the base metrics according to the base equation, which delivers a
score ranging from) to 10, and create a scored vector. These defined scores further refined by combining
the values which will be calculated for the temporal and environmental metrics.

14
Figure 04: - Availability metric

3.1.2 Temporal Metric

The characteristics that can be change over time as a result of new patch release or any technology
change, will be categorized as temporal metric and characteristics such as the maturity of the exploit
code, level of remediation.

Exploit code maturity


This matric describes and measures the availability of exploit code for the identified vulnerability using
its characteristics such as active or proof of Concept (POC) status, availability in public, and easiness to
exploit the vulnerability using that exploit code. Moreover, the availability of POC shows that exploiting
the vulnerability is possible. In severe cases, it may be delivered as the payload of a network-based worm
or virus or other automated attack tools.

Figure 05: Maturity of Exploit

15
Remediation Level
Vulnerabilities require remediation, and that could take a specific time and effort to produce by the
respective vendor or community. at the stage of vulnerability publish, the status of the remediation is
unpatched. However, there are workarounds and hotfixes for temporary remediation until an official patch
or upgrade is issued. Hence, these respective stages represent the value of the temporal score remediation
level. If the official and permanent a fix is less, the higher the vulnerability score.

Report Confidence
This metric measures the degree of confidence in the existence of the the degree of confidence and
technical details of the vulnerability, this metric provides value to the temporal score. Often, the
vulnerability goes through multiple types of research and tests to identify the root course, and finally, the
vulnerability may or may not be confirmed by the vendor of the affected technology or asset. The urgency
of the vulnerability eventually becomes high when a vulnerability is certain at the stage of identification.
The score will be high base on the number of sources that will validate the vulnerability.

3.1.3 Environmental Metric

Environmental metrics measure those vulnerability characteristics that are relevant and unique to a user’s
environment. CVSS environmental metrics address the technical shortcomings of CVSS version 2. It
provides the freedom to security analysts to customize the CVSS score depending on the IT asset to the
individual organization based on the given characteristics such as alternative security controls in place,
confidentiality, integrity, and availability of the vulnerable asset. Hence, the modifications to the CVSS
base score allowed, and security analysts received more freedom form the aspects of severity identification
of the vulnerable components.
The outcome of the environmental score still be based on the base metrics since the base metric values get
override by the environmental score after applying the Environmental Security Requirements. For

16
example, the default configuration for a vulnerable component may be to run a listening service with
administrator privileges, allows an attacker to compromise.
Confidentiality, Integrity, and Availability impacts, which can be considered as the impact is High.
However, in the analyst’s environment, that same service might be running with degraded privileges;
resulting in the Modified Confidentiality, Modified Integrity, and Modified Availability might be set to
Low. [6]

Figure 06: - Environmental Metric

As discussed above, Exploitability metrics represent the characteristics of the vulnerability in different
dimensions and their properties that could lead to a successful exploit. As an assumption when building
the CVSS score, it has been determined that attacker has advanced knowledge of the weakness of the
target system and Specific configurations should not impact any property producing the CVSS Base Score,
i.e., if a specific configuration is required for an attack to succeed, the vulnerable component should be
scored assuming it is in that configuration. [6]

However, in real-world attacks, attacker knowledge about the target could be varied and, configurations
of the vulnerable component could be unique to each organization generating different results for the same
vulnerability.

17
A research conducted by Allodi and Massacci (2014) discusses the relationship of the network
vulnerabilities, and it found that the actual severity of the Vulnerabilities shows statistically significant
indicates when integrated with the dark web exploit data.

3.1.4 CVSS V3 Calculation

Metric Numerical Value Metric Value


Attack Vector / Modified Attack Vector 0.85 Network
0.62 Adjacent
0.55 Local
0.2 Physical
Attack Complexity / Modified Attack 0.77 Low
Complexity
0.44 High
Privileges Required / Modified Privileges 0.85 None
Required
0.62 (or 0.68 if Scope / Low
Modified Scope is
Changed)
0.27 (or 0.5 if Scope / High
Modified Scope is
Changed)
User Interaction / Modified User 0.85 None
Interaction
0.62 Required
Confidentiality / Integrity / Availability / 0.56 High
Modified Confidentiality / Modified
Integrity / Modified Availability
0.22 Low
0 None
Exploit Code Maturity 1 Not Defined
1 High
0.97 Functional
0.x Proof of Concept
0.91 Unproven
Remediation Level 1 Not Defined
1 Unavailable
0.97 Workaround
0.96 Temporary Fix
0.95 Official Fix
Report Confidence 1 Not Defined

18
1 Confirmed
0.96 Reasonable
0.92 Unknown
Confidentiality Requirement / Integrity 1 Not Defined
Requirement / Availability Requirement
1.5 High
1 Medium
0.5 Low

Table: 01 CVSS V3 Calculation

3.1.1 CVSS v3 Equation

The CVSS v3.0 equations are defined below.

Base

The Base Score is a function of the Impact and Exploitability sub score equations. Where the Base score is
defined as,

If (Impact sub score <= 0) 0 else,


Scope Unchanged4 𝑅𝑜𝑢𝑛𝑑𝑢𝑝(𝑀𝑖𝑛𝑖𝑚𝑢𝑚[(𝐼𝑚𝑝𝑎𝑐𝑡 + 𝐸𝑥𝑝𝑙𝑜𝑖𝑡𝑎𝑏𝑖𝑙𝑖𝑡𝑦), 10])
Scope Changed 𝑅𝑜𝑢𝑛𝑑𝑢𝑝(𝑀𝑖𝑛𝑖𝑚𝑢𝑚[1.08 × (𝐼𝑚𝑝𝑎𝑐𝑡 + 𝐸𝑥𝑝𝑙𝑜𝑖𝑡𝑎𝑏𝑖𝑙𝑖𝑡𝑦), 10])

and the Impact sub score (ISC) is defined as,

Scope Unchanged 6.42 × 𝐼𝑆𝐶Base


Scope Changed 7.52 × [𝐼𝑆𝐶𝐵𝑎𝑠𝑒 − 0.029] − 3.25 × [𝐼𝑆𝐶𝐵𝑎𝑠𝑒 − 0.02]15

Where,

𝐼𝑆𝐶𝐵𝑎𝑠𝑒 = 1 − [(1 − 𝐼𝑚𝑝𝑎𝑐𝑡𝐶𝑜𝑛𝑓) × (1 − 𝐼𝑚𝑝𝑎𝑐𝑡𝐼𝑛𝑡𝑒𝑔) × (1 − 𝐼𝑚𝑝𝑎𝑐𝑡𝐴𝑣𝑎𝑖𝑙)]

And the Exploitability sub score is,

8.22 × 𝐴𝑡𝑡𝑎𝑐𝑘𝑉𝑒𝑐𝑡𝑜𝑟 × 𝐴𝑡𝑡𝑎𝑐𝑘𝐶𝑜𝑚𝑝𝑙𝑒𝑥𝑖𝑡𝑦 × 𝑃𝑟𝑖𝑣𝑖𝑙𝑒𝑔𝑒𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 × 𝑈𝑠𝑒𝑟𝐼𝑛𝑡𝑒𝑟𝑎𝑐𝑡𝑖𝑜𝑛

Temporal
The Temporal score is defined as,

𝑅𝑜𝑢𝑛𝑑𝑢𝑝 (𝐵𝑎𝑠𝑒𝑆𝑐𝑜𝑟𝑒 × 𝐸𝑥𝑝𝑙𝑜𝑖𝑡𝐶𝑜𝑑𝑒𝑀𝑎𝑡𝑢𝑟𝑖𝑡𝑦 × 𝑅𝑒𝑚𝑒𝑑𝑖𝑎𝑡𝑖𝑜𝑛𝐿𝑒𝑣𝑒𝑙 × 𝑅𝑒𝑝𝑜𝑟𝑡𝐶𝑜𝑛𝑓𝑖𝑑𝑒𝑛𝑐𝑒)

19
Environmental
The environmental score is defined as,

If (Modified Impact Sub score <= 0) 0 else,

If Modified Scope is Unchanged Round up(Round up (Minimum [ (M.Impact + M.Exploitability) ,10]) × Exploit
Code Maturity × Remediation Level × Report Confidence)

If Modified Scope is Changed Round up(Round up (Minimum [1.08 × (M.Impact + M.Exploitability) ,10]) ×
Exploit Code Maturity × Remediation Level × Report Confidence)

And the modified Impact sub score is defined as,

If Modified Scope is Unchanged 6.42 × [𝐼𝑆𝐶𝑀𝑜𝑑𝑖𝑓𝑖𝑒𝑑]

If Modified Scope is Changed 7.52 × [𝐼𝑆𝐶𝑀𝑜𝑑𝑖𝑓𝑖𝑒𝑑 − 0.029]-3.25× [𝐼𝑆𝐶𝑀𝑜𝑑𝑖𝑓𝑖𝑒𝑑 − 0.02] 15

Where,
𝐼𝑆𝐶𝑀𝑜𝑑𝑖𝑓𝑖𝑒𝑑 = 𝑀𝑖𝑛𝑖𝑚𝑢𝑚 [[1 − (1 − 𝑀. 𝐼𝐶𝑜𝑛𝑓 × 𝐶𝑅) × (1 − 𝑀. 𝐼𝐼𝑛𝑡𝑒𝑔 × 𝐼𝑅) × (1 − 𝑀. 𝐼𝐴𝑣𝑎𝑖𝑙 × 𝐴𝑅)], 0.915]

The Modified Exploitability sub score is,

8.22 × 𝑀. 𝐴𝑡𝑡𝑎𝑐𝑘𝑉𝑒𝑐𝑡𝑜𝑟 × 𝑀. 𝐴𝑡𝑡𝑎𝑐𝑘𝐶𝑜𝑚𝑝𝑙𝑒𝑥𝑖𝑡𝑦 × 𝑀. 𝑃𝑟𝑖𝑣𝑖𝑙𝑒𝑔𝑒𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 × 𝑀. 𝑈𝑠𝑒𝑟𝐼𝑛𝑡𝑒𝑟𝑎𝑐𝑡𝑖𝑜n

4 Where “Round up” is defined as the smallest number, specified to one decimal place, that is equal to or higher
than its input. For example, Round up (4.02) is 4.1; and Round up (4.00) is 4.0.

3.2 Approaches to vulnerability prioritization.

This paper talks about various ways to deal with weakness prioritization in the business and the difficulties
of those methodologies.

3.2.1 CVSS score-based Prioritization

The CVSS based methodology is the generally utilized technique of weakness prioritization paying little
heed to its shortcomings, as talked about in the above parts. Nonappearance of an all-around perceived
strategy to organize the weaknesses as opposed to organizing according to the weakness seriousness score,

20
security examination groups need to cling to the merchant prescribed or an individual best practice to
manage this issue. CVSS standard association has recognized this issue and further built up the CVSS
score delivering CVSS v3.0 in June 2019. Be that as it may, with the arrival of CVSS v3, the quantity of
basic and high weaknesses surpassed 15000, expanding the weight of weakness prioritization. The move
from CVSSv2 to CVSSv3 has significantly affected the circulation of seriousness: -

a. CVSSv2 scores 31% of CVEs as High severity (7.0–10.0), versus 60% with High (7.0–8.9) or
Critical severity (9.0–10.0) under CVSSv3
b. CVSSv3 scores the majority of vulnerabilities as High (7.0–8.9) and Critical (9.0–10.0

Figure 07: - CVSS2 vs CVSS3

Allodi andMassacci (2014) find that joining outer factors, for example, dark web information into the
CVSS base score gives a more measurably critical sign of genuine weakness seriousness. Holm et al.
(2012) show in their exploration that security demonstrating with CVSS information alone doesn't
precisely depict an opportunity to-bargain of a framework. They found that security models that base
choices on just the most extreme CVSS information are less solid than those that think about all
weaknesses, paying little heed to their CVSS seriousness.

3.2.2 Asset criticality-based prioritization

21
Numerous industry-driving weakness the board arrangement organizations acknowledge that when
allotting remediation needs, it is basic to analyze the seriousness of the weaknesses with regards to every
advantage. For instance, there could be a basic weakness with CVSS score 10.0 in a basic resource of the
association, for example, a web-confronting server. The remediation of this weakness is critical to the
association. Notwithstanding, remediating that equivalent weakness may not be a first concern when it's
present in a benefit of medium or low significance, for example, a disconnected PC that is utilized to take
printouts.

The advantage criticality is interesting to the association with the goal that it is a risky factor to apply by
and large over the business. Notwithstanding, an adaptable boundary can be permitted to the association's
security investigator since resource criticality is fundamental to the weakness prioritization.

3.2.3 Threat intelligence-based prioritization (Also known as productive


prioritization, threat centric prioritization)

In vulnerability management, it is also helpful to use threat intelligence to detect threats and to patch using
threat landscape trends as a guide pre-emptively. Prioritizing the patch or workaround to fix the
vulnerability using intelligence data such as current exploitation in the industry is vital since this approach
can protect assets from the vulnerabilities that are already weaponized in the cyber or weaponized shortly
on the threat intelligence information. Establishing this approach's accuracy, there are specific properties
such as Exploit code Maturity and threat recency to identify the age of the exploit after it becomes
available for attackers.

3.2.4 Contextual criteria to vulnerability prioritization

Analysis of different methodologies have been used by different researches about vulnerability
periodization and proven contextual information identified by security researches, it is possible to
incorporate certain contextual data for each vulnerability. Below table describes what contextual data can
be incorporated to the existing CVSS score in a summarised format.

22
Criteria for Contextual prioritization model
Metrics group Metrics name CVSS Metric description Contextual Data
Include Mapping
Base Access Vector Yes This is to describe Whether the vulnerability
exploit can occur only locally or from adjacent
networks, or from any network connection
("such as exploitable").
Access Complexity Yes Means the difficulty involved in exploiting the
vulnerability.
Authentication Yes The number of attempts that an attacker should
authenticate to exploit the vulnerability.
Confidentiality Yes If this vulnerability is successfully exploited,
Impact what would be the impact.
Integrity Impact Yes The degree to which system integrity (the
accuracy of the information that is supplied by
the application) is jeopardized if this
vulnerability is exploited.
Availability Impact Yes The influence on the availability of information
resources if this vulnerability is exploited.
Temporal Exploitability No* The present techniques or code availability for Exploit Platforms
the vulnerability.
Remediation Level No* Org. Input
The degree of availability of remediation
Report Confidence No* The number of technical details and confidence Org. Input
of the vulnerability
Environmental Collateral Damage No* The possible damage or theft if the application Org. Input
Potential happens to be vulnerable.
Contextual Target Distribution No* The probability of systems in the targets that’s Org. Input
are vulnerable
Availability No* The importance of availability of information. Org. Input
Requirement
Confidentiality No* The importance of confidentiality of user data. Org. Input
Requirement
Integrity Requirement No* The importance of integrity, or accuracy, of Org. Input
information of the target
Risk Value Risk value calculated of the Asset Org. Input
Threat Intelligence Feeds about threats and Vulnerability (PoC, Threat Intelligence
Feeds Proof of Concept Data) data
Asset Auto Update No* Auto Update of assets Org. Input
Enabled Enabled
Network is not Accessible
DMZ Assets No* Whether the Asset is a DMZ asset or Internal Org. Input
Network asset
Remediation Time No* Avg. Time to Remediate the Vulnerability Org. Input

Table2: Contextual data utilization to the vulnerability prioritization – mapped with CVSS Scoring

23
Chapter 4. Contextual model of vulnerability
prioritization

3. Technology

Input: Gathering vulnerability data and contextual data in each organization

In the proposed solution vulnerability scan data will be gathered from multiple sources such as various
industries and various firmware, software technologies.
Basic vulnerability data will be associated with the contextual data such as asset value and asset exposure
in the organization, current exploit data from threat intelligence sources, Exploitation availability and
potential impact of exploitation and total coast of resolving vulnerability will be taken in to consideration
when developing the contextual module.

Process: Changes in vulnerability scores and prioritization:


After gathering vulnerability data and context data, the data of all analyzed vulnerabilities are first laid
out in a spreadsheet. Next step is to re define the vulnerability score associating context data criteria and
re calculate the vulnerability score. We will define the missing context information (e.g., the availability
of patches or exploits) as dependent variables that can be explained by independent variables, for example
the age of a vulnerability. Authors like Frei et al have done this before to investigate trends in the
relationship between the availability of vulnerability patches, exploits and their age.

Assumption; initially we will use the CVSS base score as the primary metrics for associating the
contextual data of the organization.

24
Output: Modified equation to calculate vulnerability scoring thus its ranking in a prioritization

The addition of context information into the CVSS score of each vulnerability changes the overall score
of a vulnerability and thus its ranking in a prioritization. We use the number of score changes as a metric
of how much the prioritization is affected by the context information.

Below table describes the Propose data collection about the contextual data that can be used to calculate
the modified vulnerability score thereby prioritizing the vulnerabilities as per the security posture of the
organization.
The incorporation of contextual characteristics to the vulnerabilities there by identify the top important
vulnerabilities to be fixed in the organization is a novel approach to vulnerability mitigation. The model
prepared by using real-world vulnerability data, threat intelligence data such as exploits for each
vulnerabilities and actively exploiting vulnerabilities in the world. Moreover, the asset criticality to the
organization and exposure factor of each asset and existing controls in the environment such as IPS
signatures for each CVE IDs have been taken into consideration when preparing the vulnerability
prioritization score.

The vulnerability prioritization score development starts with identifying CVEs via vulnerability scans.
There are many commercial and open source tools to carryout vulnerability scans. As the inputs to this
specific prioritization tool, we have used CVE ID, IP address or host name and open ports of each assesses
which can be identified as vulnerability scan results. These vulnerability scan reports have been used as
data input via data import section to the prioritization tool as the data input. Contextual data also use as
data inputs to the prioritization tool and these data collected from various sources such as Threat
intelligence sources, (active exploitations, age of the vulnerability, maturity of the exploit code etc.) Asset
exposure information of the target organization and organization current controls such as IPSs signatures
(optional)

These inputs data will be stored to the database for further analysis based on defined contextual criteria.
Initial criteria defined as below;

a. Threat Intelligence based data

25
b. Availability of Vulnerability exploit code
c. Maturity of the exploit (Age of the Exploit)
d. Active exploitation

e. Asset Based data


Criticality of the Asset
Exposure of the Asset

f. Existing Controls
IPS signatures, EDR and other preventions for the CEV

In the analysis of each CVE as per the vulnerability prioritization criteria, the matching context data adds
a new prioritization score to the existing CVE score defined by the NVD and the vulnerabilities with high
prioritization score becomes the vulnerabilities which requires to attend as prioritized vulnerabilities.
System administrations and software engineers can focus on the priority list and act upon to fix the
prioritized vulnerabilities now making their tasks easier.

This tool designed using MySQL database and Hypertext Processor PHP language as an open source
development initiative and this tool to be available in open source development platforms expecting other
collaborative developers also to further develop the prioritization model.

4. Design
The calculation of prioritization score is a enhancement to the existing CVSS Base score sine this research
has identified that the CVSS Base score matric is a fundamental severity score and industry known severity
measure for the vu The design of the vulnerability prioritization module has designed with most commonly
considered contextual data elements of vulnerability analysis. The decision matrix / algorithm used to
calculate the vulnerability prioritization score to identify the most critical vulnerability which require an
immediate attention.

26
The availability or level of the criticality of each contextual element, a numerical value has been added to
the existing CVSS Base score and at end of checking each contextual element and adding / deducting the
contextual numerical value, the tool gives the prioritization score of each CVE/IT asset. These
prioritization reports can be used by the security analysis teams to identify that which vulnerabilities
require an immediate attention and they can generate reports in different formats such as HTML, CSV
and PDF.

Figure 8: system Diagram, high level

The relational database architecture developed by crating multiple databases such as;
Scan Database – The scan reports which can be imported to the vulnerability prioritization tool.
CVE Database – CVE search API which automatically fetches the latest vulnerability data
Active exploit database (Exploit database developed by offensive security team)
Zero Day vulnerability Database

27
Asset criticality and Current Controls - Asset criticality and exposure criteria vary as per the organization.
Moreover, the organization's existing controls also cannot use as a common criterion when creating a
model for vulnerability prioritization. However, these two criteria can make a significant impact on the
overall result. Hence this tool provides the freedom to incorporate these data as input criteria.

Figure 9: Relational data model

28
5. Implementation

Initial prototype of the vulnerability prioritizations developed by using large number of vulnerability scan
reports and identifying the contextual information around those vulnerabilities. I have conducted scans on
multiple devices includes different Operating systems with large number of vulnerabilities in those
devices. These data I have use as a source data inputs to the model. As a second data source, I have used
vulnerability exploitation data and threat intelligence data from difference sources which is freely
available. The prioritization tool logic created such a way to calculate the prioritization score based on the
existing score of the CVSS by NVD which is provided as a input data source. The calculation methodology
is simple yet empirical which adds a numerical vale to the existing score whereas existing controls area
deducts an average of the controls in place. Because, there are certain level of controls to the vulnerabilities
in every organization and security analysis are free to apply those controls in this model to customize the
tool as per their technical environment. In general, “Vulnerability Risk Score” is a collection of contextual
data to the CVSSS where as “Safeguard score” represents an existing control score to the asset. The sum
of these scores create the vulnerability prioritization score (VPS) as the output of the tool. Once this tool
gets executed to generate the prioritization report, its logically evaluate the criteria in bellow table
alongside with the data available in the system.

Matrix Condition Numerical Calculated Prioritization Score


Value
CVSS Score / Base Score Default (Input) CVSS
(NVD) Severity value Base Score
Contextual Vectors
Availability of Vulnerability Yes 1.0
exploit code No -1.0
Maturity of the exploit (Age Not Defined 0.0
of the Exploit) POC 0.1
Functional 0.2
High 0.3
Active exploitation Yes 1.0
No 0.0
Criticality of the Asset High 1.0
Medium 0.0

29
Low - 0.5
Exposure of the Asset High 1.0
Medium 0.5
Low 0.1
Vulnerability Risk Score CVSS Score +
Sum of Contextual Vector score

Existing Controls
IPS_Signature Yes /No 1.0/0.0
EDR_Prevention Yes /No 1.0/0.0
XDR_Prevention Yes /No 1.0/0.0
SandBox_prevention Yes /No 1.0/0.0
Anti_Malware_prevention Yes /No 1.0/0.0
Multi_factor_Authentication Yes /No 1.0/0.0
Virtual_patching Yes /No 1.0/0.0
Zero_Day_prevention Yes /No 1.0/0.0
EXPLOIT_PREVENTION Yes /No 1.0/0.0
OTHER Yes /No 1.0/0.0
Safeguard score Vulnerability Risk Score + (Sum of
Existing Control score/ Count of
applicable Existing Control score)
Vulnerability Prioritization (Vulnerability Risk Score -
Score Safeguard score)

Table 3: vulnerability prioritization score calculation chart

30
Figure 10: Application logic diagram

31
6. Evaluation
This paper details about the effectiveness of the vulnerability prioritization model and how most critical
vulnerabilities derived out of large sum of vulnerabilities in a vulnerability scan cycle. Vulnerability scan
data and exploit data have been used as Source data (Annexure 01 & 02) to the prioritization tool and we
have used the asset classification and exposure factor as per the network architecture and service level
data in the sample organization. (IP address have masked in the annexures to maintain the data
confidentiality) All possible contextual metrics are simulated to develop the prioritization methodology
and after running this model in the learning mode, prioritized vulnerabilities identified out significant
amount of vulnerabilities. (Annexure 04)

Further analysis of these critical vulnerabilities, it was identified that exploit codes or POCs are available
for those prioritized vulnerabilities and controls such IPS signatures are not available for these
vulnerabilities in the organizational context. Analysis results shows that vulnerabilities with less CVSS
value also contains high prioritization rate so that disregarding the vulnerabilities just by looking at the
CVSS score creates a risk to the secure posture of the organizations since certain exploits are available
for the vulnerability which have less CVSS score.

Figure 11: Vulnerability Priority and CVSS score – Heat map

32
7. Conclusion and Future Work

In this article, we have proposed the contextual methodology for vulnerability prioritization framework
for security vulnerability mitigation.
The purpose is to identify whether some risk factors (in our scenario, a high CVSS score, or the existence
of a proof of concept exploit) is a good explanation of the cases and therefore represents a decision variable
upon which the system administrator must act. To illustrate the methodology, we first analyzed how the
CVSS score expresses the Impact and the Likelihood of exploitation to happen. We showed that the Base
score is the primary score of the CVSS calculation, and proper characterization of the ‘likelihood of
exploit’ is not present in the CVSS score. We have identified specific vulnerabilities scored as medium or
high in CVSS scores are critical and require immediate attention as per the VPS score.
Finally, we showed how the methodology could evaluate the vulnerability mitigation process's
effectiveness and consider different risk factors. Our results show that the importance of consideration of
contextual criteria of each vulnerability for the better analysis without limiting to the CVSS score and
introduce a methodology with any organization can patronize as a free tool in this study, we considered
the existence of a proof-of-concept exploit and of an exploit traded in the black markets. As future work,
more APIs can be used as data sourcing methods, and this model can be further developed with a machine
learning approach with additional evaluation factors that can be designed and use by security specialists.

33
References
[1] C. Fruhwirth and T. Mannisto, "Improving CVSS-based vulnerability prioritization and response with
context information," 2009 3rd International Symposium on Empirical Software Engineering and
Measurement, Lake Buena Vista, FL, 2009, pp. 535-544, doi: 10.1109/ESEM.2009.5314230.

[2] Allodi, Luca, and Fabio Massacci. “Comparing Vulnerability Severity and Exploits Using Case-Control
Studies.” ACM Transactions on Information and System Security, vol. 17, no. 1, Aug. 2014, pp. 1–20,
10.1145/2630069. Accessed 18 Sept. 2020.

[3] “Kernel Hardening by Recovering Kernel Stack Frame in Linux Operating System.” International
Journal of Advancements in Computing Technology, vol. 1, no. 1, 30 Sept. 2009, pp. 64–69,
10.4156/ijact.vol1.issue1.9.

[4] Common Vulnerabilities and Exposures (CVE). https:-//cve.mitre.org/.

[5] Common Vulnerability Scoring System (CVSS). http:-//nvd.nist.gov/cvss.cfm.

[6] Common Vulnerability Scoring System v3.0 (CVSS3.0). https:-//www.first.org/cvss/ specification-


document.

[7] A. Manion, FABIO MASSACCI, L., 2014. Comparing Vulnerability Severity and Exploits Using Case-
Control Studies. 1. Canada: University of Trento.

[8] [ G. Ridley, J. Young, and P. Carroll, “COBIT and its utilization: a framework from the literature,”
System Sciences, 2004. Proceedings of the 37th Annual Hawaii International Conference on, 2004, p. 8 pp.]

[9] Open Vulnerability and Assessment (OVAL). http:-//oval.mitre.org/.

[10] OSVDB. The Open Source Vulnerability Database. http:-//osvdb.org/

[10] Wikipedia. 2019. Common_Vulnerability_Scoring_System. [Online]. [8 January 2020]. Available


from:- https:-//en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System

[11] G. Ridley, J. Young, and P. Carroll, “COBIT and itsutilization:- a framework from the literature,”
System Sciences, 2004. Proceedings of the 37th Annual Hawaii

[12] International Conference on, 2004, p. 8 pp. [4] S. Frei, M. May, U. Fiedler, and B. Plattner, “Largescale
vulnerability analysis,” Proceedings of the 2006 SIGCOMM workshop on Large-scale attack defense, Pisa,
Italy:- ACM, 2006, pp. 131-138.

34
35
Appendices
Annexure 01 Sample set of Scan data used for the Vulnerability prioritization tool

CVSS V3
IP Address Family Severity Protocol Port CVE
Base Score
1.x.x.2 Windows Medium TCP 445 6.8 CVE-2018-12238
1.x.x.2 Windows Medium TCP 445 7.8 CVE-2018-12245
1.x.x.2 Windows Medium TCP 445 7.8 CVE-2018-20250
1.x.x.2 Windows Low TCP 445 6.5 CVE-2018-18366
1.x.x.2 Windows High TCP 445 7.8 CVE-2019-12756
1.x.x.2 Windows Medium TCP 445 6.4 CVE-2017-5715
1.x.x.2 Windows High TCP 445 8.8 CVE-2019-18197
1.x.x.2 Windows High TCP 445 8.8 CVE-2019-20503
1.x.x.4 Windows Medium TCP 445 6.8 CVE-2018-12238
1.x.x.4 Windows Medium TCP 445 7.8 CVE-2018-12245
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-0590
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-0613
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-0609
1.x.x.4 Windows Critical TCP 445 9.8 CVE-2019-7096
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-0685
1.x.x.4 Windows Critical TCP 445 9.8 CVE-2019-7096
1.x.x.4 Windows Medium TCP 0 7.3 CVE-2018-5927
1.x.x.4 Windows Low TCP 445 6.5 CVE-2018-18366
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-7837
1.x.x.4 Windows High TCP 445 8.8 CVE-2018-12126
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-7837
1.x.x.4 Windows Medium TCP 445 7.5 CVE-2019-0820
1.x.x.4 Windows Medium TCP 445 8.8 CVE-2019-7845
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-0620
1.x.x.4 Windows Medium TCP 445 8.8 CVE-2019-7845
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-0865
1.x.x.4 Windows Medium TCP 445 8.8 CVE-2019-1006
1.x.x.4 Windows High TCP 0 7.8 CVE-2019-6328
1.x.x.4 Windows Critical TCP 445 9.8 CVE-2019-0714
1.x.x.4 Windows Critical TCP 445 9.8 CVE-2019-8069
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-0787
1.x.x.4 Windows Critical TCP 445 9.8 CVE-2019-8069
1.x.x.4 Windows Low TCP 445 5.5 CVE-2019-1142
1
1.x.x.4 Windows High TCP 445 7.5 CVE-2019-1367
1.x.x.4 Windows High TCP 445 7.8 CVE-2019-0608
1.x.x.4 Windows High TCP 445 7.8 CVE-2019-12756
1.x.x.4 Windows Medium TCP 445 8.8 CVE-2019-13725
1.x.x.4 Windows Medium TCP 445 8.8 CVE-2019-13767
1.x.x.4 Windows Medium TCP 445 6.4 CVE-2017-5715
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-18197
1.x.x.4 Windows High TCP 445 8.8 CVE-2019-20503
1.x.x.4 Windows Medium TCP 445 6.5 CVE-2017-8529
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-4x5
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-4x5
1.x.x.6 Windows High TCP 445 8.1 CVE-2018-0978
1.x.x.6 Windows Medium TCP 445 8.8 CVE-2018-5007
1.x.x.6 Windows High TCP 445 8.1 CVE-2018-0x9
1.x.x.6 Windows Medium TCP 445 8.8 CVE-2018-5007
1.x.x.6 Windows High TCP 445 9.8 CVE-2018-12824
1.x.x.6 Windows High TCP 445 8.8 CVE-2018-3615
1.x.x.6 Windows High TCP 445 9.8 CVE-2018-12824
1.x.x.6 Windows Medium TCP 445 7.5 CVE-2018-8360
1.x.x.6 Windows Medium TCP 445 6.4 CVE-2018-3615
1.x.x.6 Windows Medium TCP 445 7.5 CVE-2018-15967
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-0965
1.x.x.6 Windows Medium TCP 445 7.5 CVE-2018-15967
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-8421
1.x.x.6 Windows High TCP 445 8.8 CVE-2018-8320
1.x.x.6 Windows Medium TCP 445 7.5 CVE-2018-15978
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-8256
1.x.x.6 Windows Medium TCP 445 7.5 CVE-2018-15978
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-15981
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-15981
1.x.x.6 Windows Medium TCP 445 5.6 CVE-2017-5715
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-15982
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-15982
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-8477
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2018-8517
1.x.x.6 Windows Medium TCP 445 6.8 CVE-2018-12238
1.x.x.6 Windows Medium TCP 445 7.8 CVE-2018-12245
1.x.x.6 Windows High TCP 445 7.5 CVE-2018-8653
1.x.x.6 Windows High TCP 445 7.8 CVE-2019-0536
1.x.x.6 Windows Medium TCP 445 7.5 CVE-2019-0545
1.x.x.6 Windows Medium TCP 445 5.6 CVE-2017-5715
1.x.x.6 Windows Medium TCP 445 6.5 CVE-2019-7090
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-0590
1.x.x.6 Windows Medium TCP 445 6.5 CVE-2019-7090

2
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-0613
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-0603
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2019-7096
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-0685
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2019-7096
1.x.x.6 Windows Low TCP 445 6.5 CVE-2018-18366
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-7837
1.x.x.6 Windows High TCP 445 8.8 CVE-2018-12126
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-7837
1.x.x.6 Windows Medium TCP 445 7.5 CVE-2019-0820
1.x.x.6 Windows Medium TCP 445 8.8 CVE-2019-7845
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-0620
1.x.x.6 Windows Medium TCP 445 8.8 CVE-2019-7845
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-0785
1.x.x.6 Windows Medium TCP 445 8.8 CVE-2019-1006
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2019-0714
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2019-8069
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-0928
1.x.x.6 Windows Critical TCP 445 9.8 CVE-2019-8069
1.x.x.6 Windows Low TCP 445 5.5 CVE-2019-1142
1.x.x.6 Windows High TCP 445 7.5 CVE-2019-1367
1.x.x.6 Windows High TCP 445 7.8 CVE-2019-0608
1.x.x.6 Windows High TCP 445 7.8 CVE-2018-12207
1.x.x.6 Windows High TCP 445 7.8 CVE-2019-12756
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-1453
1.x.x.6 Windows Medium TCP 445 8.8 CVE-2019-13725
1.x.x.6 Windows Medium TCP 445 8.8 CVE-2019-13767
1.x.x.6 Windows Medium TCP 445 6.4 CVE-2017-5715
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-18197
1.x.x.6 Windows High TCP 445 8.8 CVE-2019-20503
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-4x5
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-4x5
1.x.x.7 Windows High TCP 445 8.1 CVE-2018-0978
1.x.x.7 Windows Medium TCP 445 8.8 CVE-2018-5007
1.x.x.7 Windows High TCP 445 8.1 CVE-2018-0x9
1.x.x.7 Windows Medium TCP 445 8.8 CVE-2018-5007
1.x.x.7 Windows High TCP 445 9.8 CVE-2018-12824
1.x.x.7 Windows High TCP 445 8.8 CVE-2018-3615
1.x.x.7 Windows High TCP 445 9.8 CVE-2018-12824
1.x.x.7 Windows Medium TCP 445 7.5 CVE-2018-8360
1.x.x.7 Windows Medium TCP 445 6.4 CVE-2018-3615
1.x.x.7 Windows Medium TCP 445 7.5 CVE-2018-15967
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-0965
1.x.x.7 Windows Medium TCP 445 7.5 CVE-2018-15967

3
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-8421
1.x.x.7 Windows High TCP 445 8.8 CVE-2018-8320
1.x.x.7 Windows Medium TCP 445 7.5 CVE-2018-15978
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-8256
1.x.x.7 Windows Medium TCP 445 7.5 CVE-2018-15978
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-15981
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-15981
1.x.x.7 Windows Medium TCP 445 5.6 CVE-2017-5715
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-15982
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-15982
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-8477
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2018-8517
1.x.x.7 Windows Medium TCP 445 6.8 CVE-2018-12238
1.x.x.7 Windows Medium TCP 445 7.8 CVE-2018-12245
1.x.x.7 Windows High TCP 445 7.5 CVE-2018-8653
1.x.x.7 Windows High TCP 445 7.8 CVE-2019-0536
1.x.x.7 Windows Medium TCP 445 7.5 CVE-2019-0545
1.x.x.7 Windows Medium TCP 445 5.6 CVE-2017-5715
1.x.x.7 Windows Medium TCP 445 6.5 CVE-2019-7090
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-0590
1.x.x.7 Windows Medium TCP 445 6.5 CVE-2019-7090
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-0613
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-0603
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2019-7096
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-0685
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2019-7096
1.x.x.7 Windows Low TCP 445 6.5 CVE-2018-18366
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-7837
1.x.x.7 Windows High TCP 445 8.8 CVE-2018-12126
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-7837
1.x.x.7 Windows Medium TCP 445 7.5 CVE-2019-0820
1.x.x.7 Windows Medium TCP 445 8.8 CVE-2019-7845
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-0620
1.x.x.7 Windows Medium TCP 445 8.8 CVE-2019-7845
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-0785
1.x.x.7 Windows Medium TCP 445 8.8 CVE-2019-1006
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2019-0714
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2019-8069
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-0928
1.x.x.7 Windows Critical TCP 445 9.8 CVE-2019-8069
1.x.x.7 Windows Low TCP 445 5.5 CVE-2019-1142
1.x.x.7 Windows High TCP 445 7.5 CVE-2019-1367
1.x.x.7 Windows High TCP 445 7.8 CVE-2019-0608
1.x.x.7 Windows High TCP 445 7.8 CVE-2018-12207

4
1.x.x.7 Windows High TCP 445 7.8 CVE-2019-12756
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-1453
1.x.x.7 Windows Medium TCP 445 8.8 CVE-2019-13725
1.x.x.7 Windows Medium TCP 445 8.8 CVE-2019-13767
1.x.x.7 Windows Medium TCP 445 6.4 CVE-2017-5715
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-18197
1.x.x.7 Windows High TCP 445 8.8 CVE-2019-20503
1.x.x.8 Windows High TCP 445 CVE-2010-1263
1.x.x.8 Windows High TCP 445 CVE-2011-1972
1.x.x.8 Windows High TCP 445 CVE-2013-0006
1.x.x.8 Windows High TCP 445 CVE-2015-1642
1.x.x.8 Windows High TCP 445 CVE-2015-2555
1.x.x.8 Windows High TCP 445 CVE-2015-2503
1.x.x.8 Windows High TCP 445 7.8 CVE-2015-6117
1.x.x.8 Windows High TCP 445 7.5 CVE-2017-0009
1.x.x.8 Windows High TCP 445 7.8 CVE-2017-8759
1.x.x.8 Windows High TCP 445 6.6 CVE-2017-11885
1.x.x.8 Windows High TCP 445 7.5 CVE-2017-5715
1.x.x.8 Windows High TCP 445 7.5 CVE-2017-5715
1.x.x.8 Windows High TCP 445 7.5 CVE-2018-0811
1.x.x.8 Windows High TCP 445 8.8 CVE-2018-0870
1.x.x.8 Windows High TCP 445 7.8 CVE-2018-0765
1.x.x.8 Windows Medium TCP 445 7.8 CVE-2018-0765
1.x.x.8 Windows High TCP 445 8.1 CVE-2018-0978
1.x.x.8 Windows High TCP 445 8.1 CVE-2018-0x9
1.x.x.8 Windows High TCP 445 8.8 CVE-2018-3615
1.x.x.8 Windows Medium TCP 445 7.5 CVE-2018-8360
1.x.x.8 Windows Medium TCP 445 6.4 CVE-2018-3615
1.x.x.8 Windows Critical TCP 445 9.8 CVE-2018-8271
1.x.x.8 Windows Critical TCP 445 9.8 CVE-2018-8421
1.x.x.8 Windows High TCP 445 8.8 CVE-2018-8330
1.x.x.8 Windows High TCP 445 7.8 CVE-2018-8256
1.x.x.8 Windows Critical TCP 445 9.8 CVE-2018-8477
1.x.x.8 Windows Critical TCP 445 9.8 CVE-2018-8517
1.x.x.8 Windows Medium TCP 445 6.8 CVE-2018-12238
1.x.x.8 Windows Medium TCP 445 7.8 CVE-2018-12245
1.x.x.8 Windows High TCP 445 7.5 CVE-2018-8653
1.x.x.8 Windows High TCP 445 7.8 CVE-2019-0536
1.x.x.8 Windows Medium TCP 445 7.5 CVE-2019-0545
1.x.x.8 Windows Medium TCP 445 5.6 CVE-2017-5715
1.x.x.8 Windows High TCP 445 8.8 CVE-2019-0590
1.x.x.8 Windows High TCP 445 8.8 CVE-2019-0613
1.x.x.8 Windows High TCP 445 8.8 CVE-2019-0609
1.x.x.8 Windows High TCP 445 8.8 CVE-2019-0688

5
1.x.x.8 Windows Low TCP 445 6.5 CVE-2018-18366
1.x.x.8 Windows High TCP 445 8.8 CVE-2018-12126
1.x.x.8 Windows Medium TCP 445 7.5 CVE-2019-0820
1.x.x.8 Windows High TCP 445 8.8 CVE-2019-0620
1.x.x.8 Windows High TCP 445 8.8 CVE-2019-0880
1.x.x.8 Windows Medium TCP 445 8.8 CVE-2019-1006
1.x.x.8 Windows Critical TCP 445 9.8 CVE-2019-0714
1.x.x.8 Windows High TCP 445 8.8 CVE-2019-0787
1.x.x.8 Windows Low TCP 445 5.5 CVE-2019-1142
1.x.x.8 Windows High TCP 445 7.5 CVE-2019-1367
1.x.x.8 Windows High TCP 445 7.8 CVE-2019-0608
1.x.x.8 Windows High TCP 445 7.8 CVE-2018-12207
1.x.x.8 Windows High TCP 445 7.8 CVE-2019-12756
1.x.x.8 Windows High TCP 445 8.8 CVE-2019-1453
1.x.x.8 Windows Medium TCP 445 6.4 CVE-2017-5715
1.x.x.8 Windows High TCP 445 8.8 CVE-2019-20503
1.x.x.8 Windows Medium TCP 445 6.5 CVE-2017-8529
1.x.x.9 General Medium TCP 3389 7.5 CVE-2016-2183
1.x.x.9 Windows Medium TCP 445 6.8 CVE-2018-12238
1.x.x.9 Windows Medium TCP 445 7.8 CVE-2018-12245
1.x.x.9 Windows Medium TCP 0 7.3 CVE-2018-5927
1.x.x.9 Windows Low TCP 445 6.5 CVE-2018-18366
1.x.x.9 Windows High TCP 0 7.8 CVE-2019-6328
1.x.x.9 Windows Medium TCP 0 7.1 CVE-2019-1161
1.x.x.9 Windows High TCP 445 7.8 CVE-2019-12756
1.x.x.9 Windows Medium TCP 445 8.8 CVE-2019-13725
1.x.x.9 Windows Medium TCP 445 8.8 CVE-2019-13767
1.x.x.9 Windows Medium TCP 445 6.4 CVE-2017-5715

6
Annexure 02 Sample Lsit of Exploitable vulnerabilitis

Plugin Name Family Severity Protocol Port Exploit?


RARLAB WinRAR < 5.70 Beta 1 Multiple Windows Medium TCP 445 Yes
Vulnerabilities
Windows Speculative Execution Configuration Windows Medium TCP 445 Yes
Check
Google Chrome < 80.0.3987.87 Multiple Windows High TCP 445 Yes
Vulnerabilities
KB4489871:- Windows 10 Version 1703 March Windows :- High TCP 445 Yes
2019 Security Update Microsoft Bulletins
KB44x474:- Windows 10 Version 1703 April Windows :- High TCP 445 Yes
2019 Security Update Microsoft Bulletins
HP Support Assistant < 8.7.50.3 DLL Loading Windows :- High TCP 445 Yes
Vulnerability Microsoft Bulletins
Adobe Flash Player <= 32.0.0.192 (APSB19-30) Windows :- High TCP 445 Yes
Microsoft Bulletins
Security Updates for Microsoft .NET Windows :- High TCP 445 Yes
Framework (July 2019) Microsoft Bulletins
KB4512507:- Windows 10 Version 1703 Windows :- High TCP 445 Yes
August 2019 Security Update Microsoft Bulletins
KB4516115:- Security update for Adobe Flash Windows :- Critical TCP 445 Yes
Player (September 2019) Microsoft Bulletins
Security Updates for Microsoft .NET Windows Critical TCP 445 Yes
Framework (September 2019)
Windows 10, Server 2016 and Server 2019 Windows :- High TCP 445 Yes
September 2019 Security Update (CVE - 2019- Microsoft Bulletins
1367)
KB4520010:- Windows 10 Version 1703 Windows :- Critical TCP 445 Yes
October 2019 Security Update Microsoft Bulletins
Google Chrome < 79.0.3x5.88 Vulnerability Windows :- High TCP 445 Yes
Microsoft Bulletins
Windows 10 / Windows Server 2016 Windows :- High TCP 445 Yes
September 2017 Information Disclosure Microsoft Bulletins
Vulnerability (CVE-2017-8529)
KB4284880:- Windows 10 Version 1607 and Windows Medium TCP 445 Yes
Windows Server 2016 June 2018 Security
Update
Adobe Flash Player <= 30.0.0.113 (APSB18-24) Windows Medium TCP 445 Yes
KB4338814:- Windows 10 Version 1607 and Windows High TCP 445 Yes
Windows Server 2016 July 2018 Security
Update
KB4343887:- Windows 10 Version 1607 and Windows Critical TCP 445 Yes
Windows Server 2016 August 2018 Security
Update (Foreshadow)
KB4343902:- Security update for Adobe Flash Windows :- Critical TCP 445 Yes
Player (August 2018) Microsoft Bulletins

7
Security Updates for Microsoft .NET Windows :- High TCP 445 Yes
Framework (August 2018) Microsoft Bulletins
Adobe Flash Player <= 30.0.0.154 (APSB18-31) Windows :- High TCP 445 Yes
Microsoft Bulletins
KB4457146:- Security update for Adobe Flash Windows High TCP 445 Yes
Player (September 2018)
Security Updates for Microsoft .NET Windows :- High TCP 445 Yes
Framework (September 2018) Microsoft Bulletins
KB4462917:- Windows 10 Version 1607 and Windows :- High TCP 445 Yes
Windows Server 2016 October 2018 Security Microsoft Bulletins
Update
KB4467691:- Windows 10 Version 1607 and Windows :- Medium TCP 445 Yes
Windows Server 2016 November 2018 Microsoft Bulletins
Security Update
Adobe Flash Player <= 31.0.0.148 (APSB18-44) Windows :- Critical TCP 445 Yes
Microsoft Bulletins
Adobe Flash Player <= 31.0.0.153 (APSB18-42) Windows :- High TCP 445 Yes
Microsoft Bulletins
KB4471321:- Windows 10 Version 1607 and Windows :- Critical TCP 445 Yes
Windows Server 2016 December 2018 Microsoft Bulletins
Security Update
Security Updates for Microsoft .NET Windows :- Medium TCP 445 Yes
Framework (January 2019) Microsoft Bulletins
Security Updates for Windows 10 / Windows Windows Critical TCP 445 Yes
Server 2016 (January 2019) (Spectre)
Adobe Flash Player <= 32.0.0.114 (APSB19-06) Windows :- Critical TCP 445 Yes
Microsoft Bulletins
KB4487026:- Windows 10 Version 1607 and Windows :- Critical TCP 445 Yes
Windows Server 2016 February 2019 Security Microsoft Bulletins
Update
KB44x440:- Windows 10 Version 1607 and Windows :- High TCP 445 Yes
Windows Server 2016 May 2019 Security Microsoft Bulletins
Update (MDSUM/RIDL)
(MFBDS/RIDL/ZombieLoad) (MLPDS/RIDL)
(MSBDS/Fallout)
KB4503267:- Windows 10 Version 1607 and Windows :- High TCP 445 Yes
Windows Server 2016 June 2019 Security Microsoft Bulletins
Update
KB4512517:- Windows 10 Version 1607 and Windows :- Medium TCP 445 Yes
Windows Server 2016 August 2019 Security Microsoft Bulletins
Update
KB4519998:- Windows 10 Version 1607 and Windows :- High TCP 445 Yes
Windows Server 2016 October 2019 Security Microsoft Bulletins
Update
MS10-036:- Vulnerability in COM Validation in Windows :- High TCP 445 Yes
Microsoft Office Could Allow Remote Code Microsoft Bulletins
Execution (983235)
MS13-002:- Vulnerabilities in Microsoft XML Windows :- High TCP 445 Yes
Core Services Could Allow Remote Code Microsoft Bulletins
Execution (2756145)

8
MS16-004:- Security Update for Microsoft Windows :- High TCP 445 Yes
Office to Address Remote Code Execution Microsoft Bulletins
(3124585)
KB40568x:- Windows 10 LTSB January 2018 Windows :- High TCP 445 Yes
Security Update (Meltdown)(Spectre) Microsoft Bulletins
KB4088786:- Windows 10 March 2018 Windows :- High TCP 445 Yes
Security Update Microsoft Bulletins
KB4103716:- Windows 10 May 2018 Security Windows :- Critical TCP 445 Yes
Update Microsoft Bulletins
Security Updates for Microsoft .NET Windows Critical TCP 445 Yes
Framework (May 2018)
KB4284860:- Windows 10 June 2018 Security Windows :- High TCP 445 Yes
Update Microsoft Bulletins
KB4338829:- Windows 10 July 2018 Security Windows :- Critical TCP 445 Yes
Update Microsoft Bulletins
KB4457132:- Windows 10 September 2018 Windows :- High TCP 445 Yes
Security Update Microsoft Bulletins
KB4462922:- Windows 10 October 2018 Windows :- High TCP 445 Yes
Security Update Microsoft Bulletins
KB4467680:- Windows 10 November 2018 Windows :- High TCP 445 Yes
Security Update Microsoft Bulletins

9
Annexure 03 :- Sample Lsit of asset criticality and exposure factor identification

IP Address Severity Protocol Port Risk Factor CVSS V3 Base Score


1.x.x.2 Medium TCP 445 Medium 6.8
1.x.x.4 Medium TCP 445 Medium 7.8
1.x.x.6 Medium TCP 445 Medium 7.8
1.x.x.7 Low TCP 445 Low 6.5
1.x.x.8 High TCP 445 High 7.8
1.x.x.9 Medium TCP 445 Medium 6.4
1.x.x.11 High TCP 445 High 8.8
1.x.x.12 High TCP 445 High 8.8
1.x.x.13 Medium TCP 445 Medium 6.8
1.x.x.14 Medium TCP 445 Medium 7.8
1.x.x.15 High TCP 445 High 8.8
1.x.x.16 High TCP 445 High 8.8
1.x.x.21 High TCP 445 High 8.8
1.x.x.22 Critical TCP 445 Critical 9.8
1.x.x.23 High TCP 445 High 8.8
1.x.x.26 Critical TCP 445 Critical 9.8
1.x.x.27 Medium TCP 0 Medium 7.3
1.x.x.28 Low TCP 445 Low 6.5
1.x.x.31 High TCP 445 High 8.8
1.x.x.32 High TCP 445 High 8.8
1.x.x.33 High TCP 445 High 8.8
1.x.x.34 Medium TCP 445 Medium 7.5
1.x.x.35 Medium TCP 445 Medium 8.8
1.x.x.36 High TCP 445 High 8.8
1.x.x.37 Medium TCP 445 Medium 8.8
1.x.x.38 High TCP 445 High 8.8
1.x.x.49 Medium TCP 445 Medium 8.8
1.x.x.52 High TCP 0 High 7.8
1.x.x.53 Critical TCP 445 Critical 9.8
1.x.x.56 Critical TCP 445 Critical 9.8
1.x.x.57 High TCP 445 High 8.8
1.x.x.69 Critical TCP 445 Critical 9.8
1.x.x.9 Low TCP 445 Low 5.5
1.x.x110 High TCP 445 High 7.5
1.x.x.6 High TCP 445 High 7.8
1.x.x.7 High TCP 445 High 7.8
1.x.x.8 Medium TCP 445 Medium 8.8
1.x.x.9 Medium TCP 445 Medium 8.8
1.x.x.10 Medium TCP 445 Medium 6.4

10
1.x.x.11 High TCP 445 High 8.8
1.x.x.12 High TCP 445 High 8.8
1.x.x.13 Medium TCP 445 Medium 6.5
1.x.x.14 Critical TCP 445 Critical 9.8
1.x.x.15 Critical TCP 445 Critical 9.8
1.x.x.17 High TCP 445 High 8.1
1.x.x.18 Medium TCP 445 Medium 8.8
1.x.x.20 High TCP 445 High 8.1
1.x.x.23 Medium TCP 445 Medium 8.8
1.x.x.24 High TCP 445 High 9.8
1.x.x.27 High TCP 445 High 8.8
1.x.x.28 High TCP 445 High 9.8
1.x.x.29 Medium TCP 445 Medium 7.5
1.x.x.30 Medium TCP 445 Medium 6.4
1.x.x.32 Medium TCP 445 Medium 7.5
1.x.x.33 Critical TCP 445 Critical 9.8
1.x.x.34 Medium TCP 445 Medium 7.5
1.x.x.37 Critical TCP 445 Critical 9.8
1.x.x.39 High TCP 445 High 8.8
1.x.x.40 Medium TCP 445 Medium 7.5
1.x.x.43 Critical TCP 445 Critical 9.8
1.x.x.44 Medium TCP 445 Medium 7.5
1.x.x.47 Critical TCP 445 Critical 9.8
1.x.x.48 Critical TCP 445 Critical 9.8
1.x.x.49 Medium TCP 445 Medium 5.6
1.x.x.50 Critical TCP 445 Critical 9.8
1.x.x.52 Critical TCP 445 Critical 9.8
1.x.x.53 Critical TCP 445 Critical 9.8
1.x.x.54 Critical TCP 445 Critical 9.8
1.x.x.55 Medium TCP 445 Medium 6.8
1.x.x.56 Medium TCP 445 Medium 7.8
1.x.x.57 High TCP 445 High 7.5
1.x.x.64 High TCP 445 High 7.8
1.x.x.65 Medium TCP 445 Medium 7.5
1.x.x.66 Medium TCP 445 Medium 6.5
1.x.x.67 High TCP 445 High 8.8

11
Annexure 04 :- Sample Lsit of prioritized vulnerabilitis

Scan Vulnerability Name Family Severity VPS Host


Plugin Total
11x62 Adobe Flash Player <= 31.0.0.153 (APSB18-42) Windows Critical 9.8 30
11x63 KB4471331:- Security update for Adobe Flash Windows :- Microsoft Critical 9.8 30
Player (December 2018) Bulletins
132858 KB4534271:- Windows 10 Version 1607 and Windows :- Microsoft Critical 9 24
Windows Server 2016 January 2020 Security Bulletins
Update
134369 KB4540670:- Windows 10 Version 1607 and Windows :- Microsoft Critical 9.7 24
Windows Server 2016 March 2020 Security Bulletins
Update
134372 KB4540689:- Windows 10 Version 1803 March Windows :- Microsoft Critical 9.7 17
2020 Security Update Bulletins
84824 Oracle Java SE Multiple Vulnerabilities (July 2015 Windows Critical 9.1 15
CPU) (Bar Mitzvah)
137702 Treck TCP/IP stack multiple vulnerabilities. Misc. Critical 10 6
(Ripple20)
66x2 Oracle Java SE Multiple Vulnerabilities (June 2013 Windows Critical 9.5 5
CPU)
80908 Oracle Java SE Multiple Vulnerabilities (January Windows Critical 9 5
2015 CPU) (POODLE)
117414 KB4457132:- Windows 10 September 2018 Windows :- Microsoft Critical 9.6 4
Security Update Bulletins
119585 KB4471323:- Windows 10 December 2018 Windows :- Microsoft Critical 9.2 4
Security Update Bulletins
127844 KB4512497:- Windows 10 August 2019 Security Windows :- Microsoft Critical 9.4 4
Update Bulletins
132865 KB4534306:- Windows 10 January 2020 Security Windows :- Microsoft Critical 9 4
Update Bulletins
134373 KB45406x:- Windows 10 March 2020 Security Windows :- Microsoft Critical 9.7 4
Update Bulletins
106606 Adobe Flash Player <= 28.0.0.137 Use-after-free Windows Critical 9.7 4
Remote Code Execution (APSA18-01) (APSB18-03)
106655 KB4074595:- Security update for Adobe Flash Windows :- Microsoft Critical 9.7 4
Player (February 2018) Bulletins
108958 Adobe Flash Player <= 29.0.0.113 (APSB18-08) Windows Critical 9.2 4
108962 KB40x110:- Security update for Adobe Flash Windows :- Microsoft Critical 9.2 4
Player (April 2018) Bulletins
101366 KB4025339:- Windows 10 Version 1607 and Windows :- Microsoft Critical 9.4 4
Windows Server 2016 July 2017 Cumulative Bulletins
Update
103354 SUSE SLES11 Security Update :- kernel (SUSE-SU- SuSE Local Security Critical 9.5 3
2017:-2525-1) (Stack Clash) Checks

1
140406 Google Chrome < 85.0.4183.102 Multiple Windows Critical 9.2 3
Vulnerabilities
132857 KB4528760:- Windows 10 Version 1903 and Windows :- Microsoft Critical 9 2
Windows 10 Version 1909 January 2020 Security Bulletins
Update
134370 KB4540673:- Windows 10 Version 1903 and Windows :- Microsoft Critical 9.7 2
Windows 10 Version 1909 March 2020 Security Bulletins
Update
117412 KB4457143:- Windows 8.1 and Windows Server Windows :- Microsoft Critical 9.6 2
2012 R2 September 2018 Security Update Bulletins
119583 KB4471322:- Windows 8.1 and Windows Server Windows :- Microsoft Critical 9.2 2
2012 R2 December 2018 Security Update Bulletins
127843 KB4512489:- Windows 8.1 and Windows Server Windows :- Microsoft Critical 9.4 2
2012 R2 August 2019 Security Update Bulletins
132863 KB4534309:- Windows 8.1 and Windows Server Windows :- Microsoft Critical 9 2
2012 R2 January 2020 Security Update Bulletins
56566 Oracle Java SE Multiple Vulnerabilities (October Windows Critical 9.7 2
2011 CPU) (BEAST)
57959 Oracle Java SE Multiple Vulnerabilities (February Windows Critical 9.7 2
2012 CPU)
5x62 Oracle Java SE Multiple Vulnerabilities (June 2012 Windows Critical 9.8 2
CPU)
625x Oracle Java SE Multiple Vulnerabilities (October Windows Critical 9.5 2
2012 CPU)
64454 Oracle Java SE Multiple Vulnerabilities (February Windows Critical 9 2
2013 CPU)
100756 Adobe Flash Player <= 25.0.0.171 Multiple Windows Critical 9.2 2
Vulnerabilities (APSB17-17)
100766 KB4022730:- Security update for Adobe Flash Windows :- Microsoft Critical 9.2 2
Player (June 2017) Bulletins
84645 MS KB3065823:- Update for Vulnerabilities in Windows Critical 9.6 2
Adobe Flash Player in Internet Explorer
9x73 Adobe Acrobat < 11.0.20 / 2015.006.30306 / Windows Critical 9.2 1
2017.009.20044 Multiple Vulnerabilities (APSB17-
11)
102427 Adobe Acrobat < 11.0.21 / 2015.006.30355 / Windows Critical 9 1
2017.011.30066 / 2017.012.20098 Multiple
Vulnerabilities (APSB17-24)
104626 Adobe Acrobat < 11.0.23 / 2015.006.30392 / Windows Critical 9.4 1
2017.011.30068 / 2018.009.20044 Multiple
Vulnerabilities (APSB17-36)
109895 Adobe Acrobat < 2015.006.30418 / Windows Critical 9 1
2017.011.30080 / 2018.011.20040 Multiple
Vulnerabilities (APSB18-09)
127903 Adobe Acrobat <= 2015.006.30498 / Windows Critical 9 1
2017.011.30143 / 2019.012.20035 Multiple
Vulnerabilities (APSB19-41)
132036 Adobe Acrobat <= 2015.006.30505 / Windows Critical 9.4 1
2017.011.30152 / 2019.021.20056 Multiple
Vulnerabilities (APSB19-55)

2
132862 KB45342x:- Windows 10 Version 1803 January Windows :- Microsoft Critical 9 1
2020 Security Update Bulletins
49996 Oracle Java SE Multiple Vulnerabilities (October Windows Critical 9.2 1
2010 CPU)
52002 Oracle Java SE Multiple Vulnerabilities (February Windows Critical 9.5 1
2011 CPU)
54997 Oracle Java SE Multiple Vulnerabilities (June 2011 Windows Critical 9 1
CPU)
73710 Google Chrome < 34.0.1847.131 Multiple Windows Critical 9.4 1
Vulnerabilities
77581 Google Chrome < 37.0.2062.120 Multiple Windows Critical 9 1
Vulnerabilities
78475 Google Chrome < 38.0.2125.104 Multiple Windows Critical 9.4 1
Vulnerabilities
79141 Google Chrome < 38.0.2125.122 Multiple Windows Critical 9.2 1
Vulnerabilities
79578 Google Chrome < 39.0.2171.71 Flash Player Windows Critical 9.4 1
Remote Code Execution
81020 Google Chrome < 40.0.2214.x Flash Player Windows Critical 9.5 1
Multiple Remote Code Execution
81207 Google Chrome < 40.0.2214.111 Multiple Windows Critical 9.2 1
Vulnerabilities
84049 Google Chrome < 43.0.2357.124 Multiple Windows Critical 9.2 1
Vulnerabilities
84667 Google Chrome < 43.0.2357.132 Multiple Windows Critical 9.6 1
Vulnerabilities
84731 Google Chrome < 43.0.2357.134 Multiple RCE Windows Critical 9.5 1
Vulnerabilities
87245 Google Chrome < 47.0.2526.80 Multiple Windows Critical 9 1
Vulnerabilities
89685 Google Chrome < 49.0.2623.75 Multiple Windows Critical 9.4 1
Vulnerabilities
91128 Google Chrome < 50.0.2661.102 Multiple Windows Critical 9.4 1
Vulnerabilities
132859 KB4534273:- Windows 10 Version 1809 and Windows :- Microsoft Critical 9 1
Windows Server 2019 January 2020 Security Bulletins
Update
134368 KB4538461:- Windows 10 Version 1809 and Windows :- Microsoft Critical 9.7 1
Windows Server 2019 March 2020 Security Bulletins
Update
85869 SUSE SLES11 Security Update :- java-1_6_0-ibm SuSE Local Security Critical 9.1 1
(SUSE-SU-2015:-1509-1) (Bar Mitzvah) (Logjam) Checks
91119 SUSE SLES11 Security Update :- ImageMagick SuSE Local Security Critical 9.5 1
(SUSE-SU-2016:-1275-1) (ImageTragick) Checks
91180 SUSE SLES11 Security Update :- ImageMagick SuSE Local Security Critical 9.5 1
(SUSE-SU-2016:-1301-1) (ImageTragick) Checks
100404 SUSE SLES11 Security Update :- samba (SUSE-SU- SuSE Local Security Critical 9.2 1
2017:-1391-1) (SambaCry) Checks
80907 Oracle Java SE Multiple Vulnerabilities (January Misc. Critical 9 1
2015 CPU) (Unix) (POODLE)

3
4

You might also like