Skip to content ↓ | Skip to navigation ↓

Only the truly committed ever reach the summit of anything. This sentiment holds true for vulnerability management. An organization cannot reach the summit without a serious commitment to fund and staff the program appropriately across the organization.

Reaching ML:5 means tying the program to the business. Everyone must be aligned with the metrics and be ready to find the root cause of any misses so that mitigations can be implemented to alleviate this miss in the future.

Business alignment is key at this level because if all the groups do not agree on the goals, then there will be a lot of disagreement and accusations.

Some example areas of alignment to consider:

  • What risk level is considered acceptable when it comes to vulnerable assets? Does it differ depending on the asset?
  • What is the SLA for fixing a critical vulnerability? Does it differ depending on the network, locale, or use of the asset?
  • What is the process for fixing a vulnerability on a critical asset that may impact the business? Is there a process for emergency change control windows?
  • What is the process for allowing new assets on the network that have vulnerabilities? How are they assessed?

Next, there needs to be alignment on enforcement.

When an asset does not meet the agreed-upon metrics and standards, what happens? The asset should be removed or quarantined from the network until the risk has been mitigated to an acceptable level. This will become a sticking point because Murphy’s Law dictates that this will happen at the worst times: a critical server will have a new exploitable vulnerability on the last day of the quarter, the CEO’s laptop will need to be quarantined while he is traveling out of the country for some reason, or a zero-day vulnerability becomes public on Christmas Day.

Continuous patching should also be implemented at this stage. Using the data from the vulnerability management tool, a worklist should be generated to show which assets need to be patched. The list should be based on the overall risk score and not solely on the vulnerability score. This risk score should take into account things like:

  • Vulnerability score
  • Asset business impact
  • Exploitability of the vulnerability
  • Exploitation in the wild
  • Ease of patch

The list should not be a 10K page report but more in a usable form. This could be take the form of a “top 10” roundup for each week that can be delivered to the system owners. Longer lists are often overwhelming and can prove to be a waste of time and paper. Limit this list to actionable items that can be remediated in a timely manner.

There will be missed metrics and SLAs, so the focus should be on the root causes and what constructive changes can be implemented to improve the process. Having full business buy-in helps these root cause analysis meetings be more productive and reduces the amount of finger-pointing.

Getting to the top of the mountain is not an easy climb, and every organization will experience setbacks along the way. While the goal should be to reach the summit, there is no set timeline.

Some organizations never reach the summit but accept the risk of staying at a lower level.

Sometimes the goals may need to be adjusted for business reality, but you can decide if these are temporary or permanent. If they are temporary, then set timelines to re-visit so that they don’t become permanent.

Some organizations find that climbing the vulnerability mountain is not something they have the skills, manpower, or even desire to attempt.

In these cases, outsourcing the work to a trusted security advisor is a great way to get the benefits at a reduced resource investment. The vendor should assess the current situation and provide a map and guidance specific to the organization. A good vendor will understand the process, monitor the risk and provide actionable output to create and cultivate a good vulnerability management program.

The vulnerability management plan is part of the overall security plan for the company. This security plan should be exercised regularly. Once a quarter, collect the groups together for a tabletop exercise. Run a fictitious but realistic scenario to make sure all groups and processes work together.

And remember… the harder the climb, the better the view!

 

FURTHER READING ON CLIMBING THE VULNERABILITY MANAGEMENT MOUNTAIN:

  1. Climbing the Vulnerability Management Mountain
  2. Climbing the Vulnerability Management Mountain: Gearing Up and Taking Step One
  3. Climbing the Vulnerability Management Mountain: Taking the First Steps Towards Enlightenment
  4. Climbing the Vulnerability Management Mountain: Reaching Maturity Level 1
  5. Climbing the Vulnerability Management Mountain: Reaching Maturity Level 2
  6. Climbing the Vulnerability Management Mountain: Reaching Maturity Level 3
  7. Climbing the Vulnerability Management Mountain: Reaching Maturity Level 4
  8. Climbing the Vulnerability Management Mountain: Reaching the Summit (VM Maturity Level 5)