Methuselah small

The time at ML:0 can be eye-opening form many organizations. There are generally a lot of assets discovered that are new or had been forgotten about. Almost every organization discovers their own Methuselah; this is the system that has been around forever and performs some important tasks but has not been updated in years. The system admins are scared to touch it for fear of breaking something.

At this point in the climb, you see the value of asset discovery and vulnerability assessments, but this is a lot of manual work, so is the return on investment here? If you have plenty of manpower, then ML:0 might be a place you decide to hang out in for a while. If your organization is like most others and you are hit by the security skills gap, then you know how hard it is to staff good security engineers.

If you are ready, it is time to climb to the next level: ML1.

Let’s start with a plan to get to ML1.

At this point, you know what is on the network and have an idea of the overall volume of vulnerabilities that exist in the organization. Your teams have also patched or mitigated some of these vulnerabilities so the cost involved is also known. Doing the manual scans is costly, so at this point, you need to invest in a tool that can kick off scans at the push of a button. It is time to break up the network into logical chunks that can be assessed and mitigated in a timely manner.

There are many ways to break up the environment to help get to ML1, and the right choice depends on a multitude of factors. Here are some examples of best practice for breaking up next works:

  • If you have a smaller network of 1,000 or fewer machines, the best option may be to just create two groups: internal and external or DMZ machines.
  • Geographically diverse organizations may want to break up the networks based on locale by country, state, county or province.
  • If you do not have a huge mixture of operating systems, breaking up the scans by operating system is a good option.
  • The systems can also be broken up by owners. A system administrator is often responsible for a number of systems, so breaking up systems along these lines allows you to give a report to that owner of just their systems.
  • Breaking up systems by type is also popular. This would be laptops, web servers, desktops, network devices, etc.

As you can see, there are lots of ways to break up the environment into manageable pieces. There is no right or wrong answer here, so pick a methodology that works for you and know you can change it in the future as needed.

When to scan is always a big question in getting to ML1. If you scan during business hours, then you risk the possibility of taking a system offline during the business day if that asset has a bad interaction to the scan traffic. We see this most often with network devices, IP phones, cameras and printers. Launching a scan at the close of business and monitoring for system failures is a good way to proceed until know that all of the assets behave during the scans.

How often to scan is the next big question. Continuous scanning is the end goal, but it is way too early for that at this point. Weekly, monthly or quarterly scans are the norm at this point in the maturity model. Large asset vendors like Microsoft, Oracle and Cisco have a cadence for when they release patches, so if you have these assets in your network, try to sync up to these release dates. If you scan too much, you are wasting resources because you do not have time to respond to the results, and your system admins will be hit with too much data that could result in lower velocity due to task switching between new reports. A good option is to pick a time frame to run the scan; at the next scan time, you can validate the results and catch any new issues.

At this stage, you are still just fixing issues in an ad-hoc manner, but you should put some more process around it and set some goals. For example, fix every issue a CVSS score above 9 by the next scan time.  This method is not perfect, but it fixes some of the highest priority issues, and we can improve from here. If that goal is too low or high, adjust accordingly.

Welcome to ML1! You are now running manual scans across all assets on a cadence with a plan for patching the highest ranking CVSS issues.


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