When setting up a new Vulnerability Management program, ask yourself these questions before the first scan
For many organizations, when they first think about Vulnerability Management, they focus on which one of the big three vulnerability scanner companies to use. Next, they think about where to put the scanners. Then, when can the scans be run? Since this is my specialty, during a conversation about VM, I will get asked about these important things, but there are strategies that should be developed before any actual deployment takes place.
Do you already know about problems within your organization?
Hold on, you say. If I haven’t scanned and don’t know what’s wrong with my assets, how can I get support for a new vulnerability management program? Here’s the thing, you probably do know about big problems with your assets.
Do you have a patching cycle for your devices? Or do you patch when it is convenient — also known as rarely? Without a regular patching cycle, you’re missing tons and tons of Windows and Linux updates; you don’t even need a vulnerability scanner to tell you this.
But it’s not just operating systems that will be found to have issues during vulnerability scans. Various teams within your organization may be running software on the servers, software that each of those teams should be maintaining and updating. There’s monitoring software, performance software, drivers for hardware components, and, of course, the business applications themselves.
If your teams initially install the servers and software and then walk away once it is working, vulnerability scanning is just going to find that you’ve never updated anything. If you have this technical debt, before tackling vulnerability scanning itself, you should consider kickstarting your patching game on the operating systems and applications, especially if you have limited resources.
Do you have resources to fix the problems that vulnerability scanning would find?
Clearly, the worst case scenario is a weak patching program that doesn’t apply updates on a regular basis. But even if your company undergoes frequent patching on the operating system and application levels, vulnerability scanning will find additional configuration issues that patching alone would never fix.
Fixing the patching program or application issues requires resources, but not usually from the team that conducts the vulnerability scanning. These other operational teams — Windows, Linux, network, SAN, application, and development — often will have the biggest competing priority of all, keeping the business running.
However, security, including vulnerability remediation, needs to be a business priority as well. Whatever your business objectives, your customers will expect their transactions with you to be secure. They don’t want to find anything — their proprietary business plan, their credit card number, or their account status — plastered all over the internet. And you don’t want to lose money due to a breach within your organization. If you don’t have support for security improvements, in general, make your case before actually setting up vulnerability scanning because otherwise you will end up with a lot of vulnerability data — and no one using it.
What is your scope for scanning and remediation of vulnerabilities?
It is really easy to say “scan everything” and we’ll deal with the results once we have them. But in any sized organization, this could quickly overwhelm the team doing the scanning, and the teams doing the remediation.
There’s a few ways to determine what is most important, but one method is finding assets closest to the internet first. A vulnerability on an internet-facing asset could provide a backdoor for an attacker into more sensitive areas of your network. The same goes for any vendor connected networks, as those networks are sometimes trusted by both sides, a little too much. The infamous hack on Target in 2014 came through an HVAC company.
What comes after that? If you have areas with sensitive company or customer data, those are good choices to expand your program, as are areas with employee personally identifiable information. This one is up to what your company thinks is important.
Keep in mind that you do not need to treat every place on the network as equally important. You can choose to scan internet-facing assets on an hourly or daily basis and less sensitive places like the employee intranet every quarter. Use a risk-based approach to get the data you need to remediate the issues, given the resources needed to fix the issues will likely be more available for important assets than less important assets. Eventually, we’ll all want to end up in a zero trust view of our networks, but that doesn’t mean you can’t prioritize one asset over another.
Do you have a way to assign vulnerabilities to teams?
Once you start scanning, the vulnerability scanner will put out a firehose of non-stop data. Collecting this data is useless unless you have a good way to communicate it to teams. Smaller organizations may be able to use Excel pivot tables to get their points across, but larger companies will definitely need a more robust system that generates tickets for teams to take action.
This isn’t just a ticket issue. Unless your asset owners run every single application on their servers, you’re likely going to need to split the data between the operating system team, the application team, and various system monitoring teams. If you have a CMDB, that will be a good start for who owns the overall asset, but you’ll likely need to reassign vulnerability tickets from the asset to other teams that can actually fix the issues.
Do you have the technical resources to assist asset owners with remediation?
The last thing you want is every asset owner reading the presented vulnerabilities and saying that they don’t apply because they are accidentally, or intentionally, misreading the output from the vulnerability scans.
Certainly, you do not need to tell every asset owner how to fix every vulnerability that is found by the scanners. However, your team should be able to read and understand a wide variety of technical details related to operating systems, networking, and application configurations to assist in coming up with a solution.
If you have a team in place with this knowledge and ability, they can push back on teams shouting “this doesn’t apply to our situation” or saying there isn’t anything they could do. Some of the most rewarding solutions come from the two teams working together.
For instance, I once had a case where apparently random ports were open on a server. The vendor said it had nothing to do with their application, but a quick command on the server showed that it was the vendor’s application listening on those now not mysterious ports. Sure enough, once escalated, the vendor confirmed they did open those ports, and provided a fix. If we hadn’t checked, that could have easily been marked not applicable and ignored.
Technical resources are very important on a vulnerability management team. A great source of talent to fill these roles are system engineers, network engineers, or developers looking to move in a security position. They know the technical details and can, in some cases, even provide solutions.
Do you have a plan for fragile applications and devices?
In some companies, you may not be allowed to scan applications when customers are using them, due to risk of disrupting applications.
Keep in mind that vulnerability scanners are usually programmed to be as non-destructive as possible. If you find that applications are crashing or becoming non-responsive after or during a scan, that itself is a vulnerability with the application that should be addressed and remediated.
Certainly, some companies may have legacy applications that cannot be fixed or are intentionally designed in a certain manner. If an application can’t survive a vulnerability scan, you should segment those applications to a protected location on the network because if a vulnerability scanner can take down the application, anyone else with network access probably can too.
Are you going to be able to scan real servers or can you instead scan their clones?
Most companies scan production because there’s no good way to confirm that their development or test environments are set up exactly the same way. If you have the ability to scan test environments in place of production — great for you, you’re probably in a cloud and/or have very strong DevOps practices.
For most companies, you are going to need to scan production because every server is potentially a “snowflake.” Initially, the servers were all set up in the same manner, but over time, they change as “slight adjustments” or upgrades are only partially successful, making no two servers exactly the same. Because of this, each server must be reviewed individually.
The one place you never want to scan the approximation of production is the internet or vendor perimeter. You will want to conduct full scale scans of those network ranges because a slight mistake in configuration of the perimeter can cost you dearly in security.
Will teams give you the appropriate access to scan the devices with authentication?
Finally, vulnerability scanning is best when you can actually read the configuration of the devices being evaluated. This is done by either installing an agent on the server to read the configurations or providing a login to the server for the vulnerability scanner.
Many companies may find it initially uncomfortable to provide a cloud vulnerability scanner with access to their devices, no matter how secure the provider says they are. This is a good discussion to have in advance because it may determine whether you want to buy a cloud based scanner or an on-premise based scanner. But beware the potential complexities of an on-premise scanner, as you’ll likely need resources to manage infrastructure around that — resources that might better be used for remediation.
Now can I setup vulnerability scans?
If you thought about all of these questions and have a good idea of how you would proceed, you are finally in a great place to setup vulnerability scans and choose a vendor. If not, save yourself some trouble and plan this out before deciding on a vendor, as they may inform your purchases.
Happy vulnerability hunting!
At this time of great need, please consider giving to your local food bank. In the Chicago area, I recommend the Greater Chicago Food Depository.
Based in Chicago, Jerry Galvin has over 15 years of experience in data center and cybersecurity operations. He currently specializes in vulnerability management. Contact him on Twitter at @jerry_galvin.
