Owasp vulnerability Management Guide (ovmg) June 1, 2020

 
2.2 
TASK 
 
 
INPUT 
 
OUTPUT 
Define/Refine Metrics 
1.1 Scope 
2.4 Reports 
2.4 Create Reports 
 
# 
 
TO-DO 
 
 
WHY 
2.2.1 
Determine the amount and 
percentage of vulnerable 
assets
Distribute the determined amount and percentage across all functional 
groups. It would be significant to present in reports that some functional 
groups are more vulnerable than others. 
2.2.2 
Determine the amount and 
percentage of vulnerable 
assets by severity and CVSS 
Repeat the step above and apply severity or CVSS score. Severity grading 
depends on the vulnerability scanner tool but usually corresponds with CVSS.
In the end, you should have several graphs where axes Y are functional 
groups A, B, C, D, and axes X are severity ratings.
2.2.3 
Determine the amount and 
percentage of new 
vulnerabilities:
During this step using the most recent and verified test results, you
’ll populate 
tables, graphs, charts for your report,
applying the qualifiers from the left 
column (2.2.3.1 to 2.2.3.6.) 
2.2.3.1 
-by severity 
Severity grading depends on a scanner
’s brand but corresponds with CVSS 
for network scanners. For web applications, it could be high, medium, and 
low.
2.2.3.2 
-by functional groups 
Apply your results from 2.1 and break down further or consolidate. 
For example, functional groups could be: 
- predefined by teams that support these assets: network, customer hosting, 
e.g.; 
- predefined by the type of the devices: webservers, ICS, workstations, IoT;
- predefined by the location of the assets. 
2.2.3.3 
-by type of environment 
For example: production, development, testing, enterprise network, public 
IPs, hosted applications.
2.2.3.4 
-by type of system 
Apply the results from 2.1. and aggregate data by an operating system. 
2.2.3.5 
-by CVE numbering authority Apply the results from 2.1. and aggregate data by CVE number.
2.2.3.6 
-by type of vulnerability 
Please see 2.1.5. 

---

OWASP Vulnerability Management Guide (OVMG) - June 1, 2020 
10 
2.2.4
Compare and analyze aging 
data by the severity of 
vulnerabilities and their 
share: 
There are two aspects of vulnerability aging: the date of publishing a 
vulnerability (reflected in CVE number) and the time of discovery. Aging 
vulnerability data analysis will impact the priority for remediation work. 
2.2.4.1 
-enterprise-wide 
Think about enterprise elements that have the oldest vulnerabilities. 
2.2.4.2 
-among all other vulnerable 
assets 
An asset could be more susceptible to exploitation if aged vulnerabilities 
prevail. On the discovery side, if your report shows that the vulnerability was 
discovered 180 days ago, it can mean that the specific business process did 
not get fully adopted or lacks quality control. 
2.2.4.3
-by functional groups 
Aggregating this data by functional groups, namely which are responsible for 
remediation of asset groups, would be an accountability reference in your 
report. 
2.2.4.4 
-by type of environment 
For example: a public infrastructure vs. private infrastructure, production vs. 
testing. Define what contrasts are essential to your organization. 
2.2.4.5 
-by type of system 
For example, public servers, internal servers, network endpoints, 
workstations, IoT systems, SCADA systems. You can go more granular to 
distinguish DNS servers from email servers, e.g., or firewall interface from 
other network devices. You can identify vulnerability by the type of operating 
system.
2.2.4.6 
-by CVE numbering authority 
Look at your data and assess whether there is any disproportion among 
specific vulnerabilities.
2.2.4.7 
-by type of vulnerability 
Please see 2.1.5 and cross-reference the test results among functional 
groups. By doing that, you would be able to map certain types of risks that 
should be mitigated or accepted organizationally. 
2.2.5
Draw out trends by count 
and percentage utilizing KPI 
that matter to your enterprise 
risks and compliance 
As you repeat the OVMG tricycle, you
’d be able to observe changes that put 
everything in perspective. Note, a downward trend may mean that we are 
doing a good job remediating vulnerabilities or that we 
don’t detect them 
correctly
. If that’s a concern, consult with 1.4 Confirm findings.
2.2.6
Determine exploitability of 
vulnerable assets by 
severity; specify count, 
percentage, decrease or
increase 
Use a reputable source for exploitation and 
don’t default to one source only, 
such as a KB reference. Some software companies may be less transparent 
than others.
End Goal: you should create (and later revise) metrics for vulnerability reports. These metrics should be consistent and 
make sense for the audience of the reports (management and teams assigned to do remediation work). 
2.3 
Audit Trail