Owasp vulnerability Management Guide (ovmg) June 1, 2020

Define/Refine scope 
2.4 Reports 
3.4 Exceptions 
1.2 Tools 
2.1 Assets Groups 
2.2 Metrics 
2.4 Reports 
3.1 Prioritize 
3.4 Exceptions 
 
# 
 
 
TO-DO 
 
 
 
WHY 
1.1.1 
Know the enterprise risks 
Whether your organization does or doesn’t have a risk registry, you have to 
understand what risks worry your management the most and where those 
risks are coming from. Understand the magnitude of
monetary losses, 
understand what may jeopardize the business your organization is in. 
Understand what may become grounds for potential exceptions.
1.1.2
Know operational constraints
Understand what may jeopardize your business due to inadequate 
procedures, processes, system failures, human errors, lack of talent, 
fraudulent or criminal activities. What are the legal, regulatory, and contractual 
requirements that
your organization must meet? 
Gather information about the relevant policy. Do you need to create a 
vulnerability management policy or update it? 
1.1.3
Know technical constraints
Know and understand the limits of your assets and interdependencies with 
regards to obsolete technologies. For example, some SCADA hardware may 
not work unless the OS supporting it is Windows XP. 
1.1.4
Distinguish primary assets 
vs. secondary
Know the essential assets, the loss of which would be detrimental for 
business, as well as the supportive, secondary assets. For example, a 
production server for the customers and a financial server with the payroll 
data.
Know the assets that are exposed to the public Internet, consider these assets 
as critical.

---

OWASP Vulnerability Management Guide (OVMG) - June 1, 2020 
5 
When rolling out an enterprise-wide vulnerability management program, start 
with the critical assets, and then incrementally expand to all essential, or 
secondary assets, and all other assets. 
1.1.5
Embed vulnerability 
management processes into 
enterprise processes 
Promote incremental change to fight any incumbent inertia (or a push back) at 
your organization. Sometimes 
it’s faster to build a new program on top of 
existing processes and refining the processes as you go.
For example, by knowing the dates of the monthly patching window, you can 
aid your engineering team by providing vulnerability analysis before patching 
and after. 
1.1.6
Build managerial support 
You must have a managerial buy-in because a vulnerability management 
program will require the attention of several departments and multiple 
stakeholders. Make sure your management understands its importance and 
supports the vulnerability management program. If not, please review 1.1.1 
and do some additional reading on enterprise risk topics. No business leader 
wants to incur losses. 
End Goal: your management should give you sign-off on a specific vulnerability test in writing. Ideally, you should have 
a vulnerability management policy ready, but that might happen after you complete several rounds of OVMG. By 
completing the Scope task, you should be able to explain to your management and your peers why vulnerability testing 
is needed and how it benefits the business. You should be able to outline the next steps. You should
understand the 
boundaries of vulnerability tests. 
1.2 
Tools