SecureState Blog

Read SecureState's award winning blog.

What is a Vulnerability Management Program and Why Do I Need One?

Simply put, a Vulnerability Management Program is a program an organization develops in order to manage its vulnerabilities.  A good Vulnerability Management Program gives an organization a great view of the effectiveness of the security controls they have implemented.

All good Vulnerability Management Programs have a core set of components that must be in place in order for the program to be effective.  Some of these components are as follows:

  • Pre-assessment activities including:
    • Compiling a current list of system owners
    • Developing a policy which forces system owners to address vulnerabilities identified in the course of a Security Assessment
  • Regularly occurring Security Assessments like:
    • Vulnerability Assessments
    • Attack and Penetration Assessments
    • Web Application Assessments
  • Metrics and tracking, which can be used to track the effectiveness of your Vulnerability Management Program and aid in identifying trends
  • Root cause analysis and process changes, which will help with creating or fixing processes used to eliminate vulnerabilities at the root of the problem
    • How many vulnerabilities were found during the latest Vulnerability Assessment?
    • Were any of the same vulnerabilities found during the current Assessment that were on the last Assessment?
    • Were any of the same categories of vulnerabilities found during this Assessment that were the last Assessment?
    • What severity are these vulnerabilities?
    • How long did it take a system owner to address a specific vulnerability?
    • Average lifespan of a vulnerability with and without a system owner.
    • Number of systems that are known to be active or decommissioned.


Pre-Assessment Activities (How to Maintain Your Sanity)

There is a saying:  “For every minute spent in organizing, an hour is earned.”  Preparation is vital to a good Vulnerability Management Program. Before even performing a security assessment (like a Vulnerability Assessment) some housekeeping needs to be done.  One of the first things you will need is a list ofGoing Crazy without a VMPdevices on your network and the system owner(s) for each of these devices.  You will need this list in the event that a security assessment identifies vulnerabilities on a specific device.  It is vital that you can quickly find the device’s system owner in order to contact them and have them address the vulnerability expediently.

A second pre-assessment item that is vital to an effective Vulnerability Management Program is a policy which forces system owners to address vulnerabilities that are identified on systems they own.  This policy should have clearly defined timelines for how long a system owner has to address a vulnerability on a system they own.  As an example, your policy may require vulnerabilities which pose an extreme technical risk to be addressed within a five-day window, a vulnerability which poses a high technical risk be addressed in a two-week window, and a vulnerability which poses a medium technical risk be addressed within a month.  Unless these policies are created before a security assessment is performed, you may find yourself fighting with system owners, because they are not addressing identified vulnerabilities in a reasonable amount of time.


The Assessments (Let’s Roll)

After the pre-assessment activities have been completed, the next step is to perform an assessment in order to identify vulnerabilities in your network.  The most popular assessment most organizations regularly use as part of their Vulnerability Management Program is a Vulnerability Assessment.  A Vulnerability Assessment is performed by running one or more vulnerability scanners against your network.  A good Vulnerability Assessment will consist of running a general purpose vulnerability scanner against the entire network and then running a web application specific scanner to scan any web applications the organization owns.  The scanner(s) then provide a list of vulnerabilities it identified.

It is important to note that not all vulnerabilities constitute a technical vulnerability.  For example, vulnerabilities may also exist in policies.  One of the most common vulnerabilities related to policy is a weak password policy.  In many cases, it is possible to compromise a web application with passwords like “password”, the username the same as the password, or “1234”.  The vulnerability management program must also be capable of dealing with these vulnerabilities and not just technical problems like missing patches.

Once you have a list of vulnerabilities, the system owners of affected systems are contacted and provided with the details of the vulnerabilities identified on their system.

Although a Vulnerability Assessment is a good assessment to perform for a quick high level view of some of the vulnerabilities, it is important to supplement this Assessment with manual security assessments.  Assessments like Attack and Penetration Assessments and Web Application Assessments that primarily rely on manual techniques are important components of a solid Vulnerability Management Program.  Although many vulnerability scanners find vulnerabilities that are considered low hanging fruit, they do not have the ability to think as an attacker would.  I have been on External Attack and Penetration Assessments where I was able to exploit vulnerabilities that a vulnerability scanner did not identify.  In many cases, these Attack and Penetration Assessments end in a complete compromise of the organization’s internal network.  I have also performed Web Applications Assessments that primarily rely on manual techniques in order to assess a web application.  While performing these Assessments, I regularly find vulnerabilities a web application scanner did not identify.  In many cases, these vulnerabilities enable me to gain access to the web application’s underlying operating system.


Tracking and Metrics (I Can Eat 10 Saltine Crackers at One Time)

Tracking is a vital part of any Vulnerability Management Program.  Some examples of things a Vulnerability Management Program should track are as follows:

SaltinesAll of these are important metrics that a Vulnerability Management Program should track.  One of the advantages of tracking this data is that you can analyze the data in order to identify any vulnerability trends.  The tracking of these metrics will help an organization to judge the success of the current Vulnerability Management Program and will aid in identifying vulnerability trends.

Using metrics is about organizing and creating data that gives us insight into what we are trying to understand.  The metric must be relevant to what you are trying to accomplish instead of merely collecting mounds of information.  Handing the CIO a report that just includes the number of vulnerabilities on all systems is not going to provide much value.  However, showing the average lifespan of a vulnerability per system owner group sheds light into how effectively each group is managing their vulnerabilities.  The CIO can then compare each group to another and take action by determining which group may need more help.


Root Cause Analysis and Process Changes (Removing the weed – Root Cause and all)

So the vulnerabilities on the affected system are remediated.  We can chalk this up as a victory and go home, right?  Wrong!  Unless we get to the root of the problem, we are likely to encounter the exact same vulnerability either on the same device or on a completely different device in the future.  In order to improve the overall threat Root Cause Analysisposture of the organization, you must identify the root cause of the vulnerability and make changes to current processes in order to verify the root of the problem is addressed correctly.  Examples of processes that may need to be changed in order to address the root of a vulnerability include:  updating / creating Minimum Security Baselines (MSBs), verifying the patch management program includes all devices (not just windows) and software (not just IIS), and updating current policies in order to require system owners apply MSBs before placing a new system in production.

As an example, suppose that you find SQL injection on one of the organization’s internally coded web applications.  Upon further investigation, it appears you may have reached the root(s) of the problem: your web application developers have never even heard of SQL Injection, the current Software Development Life Cycle (SDLC) does not even mention security in any of the phases of the SDLC, and web applications are placed in the production environment without going through web application security assessments.  Once the root causes are determined, you implement changes to the web application developer training program by requiring web application developers to attend regular secure web application coding practices training.  In addition, you integrate security into all phases of the SDLC and require all new web applications be subjected to manual web application assessments before being placed into the production environment.


Conclusion (“NOT” All good things come to an end)

A Vulnerability Management Program should be an integral part of any security program.  It is a great way to reveal weaknesses in your current security controls so they can be adjusted as needed.  It may even reveal that critical controls that you never even considered are missing from your network.  (Let’s hope it’s not something like your externally facing firewall).  A vulnerability management program is not a project or an Assessment.  It is not an exercise bound to a specific interval in time, with a defined beginning and ending.  Vulnerability management is a continual process that monitors the effectiveness and the efficiency of your organization’s ability to identify, classify, remediate and mitigate vulnerabilities.  Without a Vulnerability Management Program, you and your security program could be completely off-course and blindly walking off the edge of a cliff.