7 minutes
How to Build a Simple Threat and Vulnerability Management Program
Vulnerability management has been a key part of my career in information security. I have built two full programs at this point, one at a fortune 200 company and another at sub one thousand employee company. From the perspective of information security the process and program were nearly identical in how they were built, the differences only show in the remediation process.
Choosing a Vulnerability Management Platform
This is an important (if not the most important) part of a security organizations toolbox. With the device count growing and the move to a remote workforce it is becoming increasingly important to implement a solution for monitoring individual assets. Work from home has created a big problem for infosec teams due to the vast number of unknown variables; is the home router up-to-date, are ports open on the firewall, what other devices sit on the home network, are the other devices up-to-date. This is where a good vulnerability platform comes in, my top three all have the ability to install agents on individual machines that can be scanned over the internet.
I am a Tenable guy, I consider it the industry standard in simplicity and effectiveness. They have recently been switching to a new interface which I am not a fan of but even with its shortcomings no other tool comes close to its performance.
I personally don’t like Qualys, in my opinion it’s a bit inefficient. It does the job and I can work with it, I would just be far more efficient and effective as a technical resource with Tenable. If you already have Qualys or have engineers familiar with the tool it will accomplish the task of scanning but not at the level of superior efficiency which is what I strive for.
I have the least experience with this tool and could be a reason for it coming in third, however this doesn’t excuse it from being a bit clunky. I haven’t used it in over two years so I am hoping it’s been refreshed to create a more efficient environment for program management.
Define the Remediation Patching Timeline
Depending on the side of your operations team and compliance requirements this can differ. There really is no one size fits all way to define this, understand that the goal is to keep the timeline as close to immediate as reasonably possible. If you have any compliance requirements do yourself a favor and set it to the max allowed, it’s a pain trying to explain yourself out of not hitting the defined patching schedule to an auditor; you and your operations team can thank me later. Here is an example patching schedule:
| Severity | CVSS | Patching Timeline |
|---|---|---|
| Critical | 9.0 - 10.0 | 5 Business Days |
| High | 7.0 - 8.9 | 10 Business Days |
| Medium | 4.0 - 6.9 | 15 Business Days |
| Low | 0.1 - 3.9 | 30 Business Days |
If you are running a mature security program you can base the patching timeline off an internally defined metric that aligns with a risk registry. This allows you to redefine the patching timelines based on a business risk model instead of clear cut CVSS scores (check your compliance requirements though as this may not be an option). I have always found it labor intensive to manage and set up a risk registry, I only recommend it if you have the man hours to spare.
Define the Scanning Schedule
This always seems to be the defining moment for a vulnerability management program; getting the operations team onboard. This is especially difficult if there has never been scanning activity before. Vulnerability scans are notorious for accidentally finding configuration issues and errors throughout the infrastructure; this could easily cause outages on a semi-regular basis until the network is brought up to a secure baseline. I consider these configuration issues to be major vulnerabilities however they will likely not show on the scan but instead just break things throughout the network. Just be cautious when running scans on new networks in the organization and be sure to over communicate with the operations team.
An important thing to note about scanning is how to break down the networks. The goal should be to group them in a logical manner that suits the business, therefore use the following outline as a guideline for how to create scanning schedules in your organization.
Network Breakdown Options
-
Based on Region
-
Based on Responsible Team
-
Based on Office/Datacenter
These three network breakdown options are what I have found to be most effective. I almost always break datacenters into individual scans first unless PCI is involved. I always separate scans for PCI to ensure the scope is limited to only what is needed for the certified scan.
Suggested Scan Types
Host Discovery Scans
I mirror my host discovery scans to the vulnerability scans. I only use host scans on the monthly/quarterly scans to keep the IP list up-to-date. I usually want datacenter host scans happening on a weekly basis, they are low risk and give a clear picture of the asset count.
Daily External Scans
I do not believe permission or notice should be given to anyone when performing external scans, malicious threat actors don’t require approval to scan external facing devices and neither should the information security team.
Corporate Office Scans
I split office scans into one per office when possible, with larger organizations however I would go by region to reduce the number of scans that must be reviewed. Splitting the scans up allows you to compare them and create a risk rating by location. Tools like Tenable do have the ability to comb through all the scan results on one dashboard and filters are available but I find it more efficient to just build python scripts to review and manage individual scans.
Production & UAT/Dev Scans
This is obviously dependent on if you have these environments, I would break them down based on region or datacenter. Both are viable options, I would make a decision based on the amount of assets; the goal should be a 2-3 hour scan.
Compliance Scans
I like all compliance related scans separate especially the ones for PCI. It is far easier to keep a tight scope for regulated networks [i.e. cardholder data environment] then trying to explain why some assets are out of scope to an auditor.
Meetings
Monthly Status Meeting
I set up a monthly meeting with the leads on the operations team to provide program updates and any process changes that might be required.
Weekly Support Meeting
I personally don’t do this anymore but am mentioning it for the inexperienced in vulnerability management. This is a great way to show your support to the operations team and allows for a scheduled troubleshooting; it is really unnecessary though, if you communicate well and are willing/able to answer questions on the fly I would just have them reach out when they have questions.
Program Maturity
To me this is simple, if it can be automated it should be. My career objective revolves around automation and yours should too. Scripting (specifically in Python 3.x) is not difficult to learn and will really enhance your engineering abilities, if this doesn’t interest you take a look at a tool I have working on AVMP (Automated Vulnerability Management Program) which is being built to automate the life cycle of vulnerability management. If setting up the tool is still too much for you feel free to reach out. I can help with basic troubleshooting and if hands on is required I can offer consulting.
Conclusion
This is the basics to a vulnerability management program, in trying to avoid the fluff I am assuming questions will arise, feel free to comment or message me and I will update the FAQ at the bottom of the page with my responses.
FAQ
Why not do one big scan to cover all networks?
The bigger the scan the longer it takes, I always want someone available on the information security team during scanning windows in case something goes wrong, we want to turn scans off if issues arise. It also allows for easier reporting and notification to the appropriate teams. I like scans to take no longer then about 2-3 hours unless the scans are compliance related as those are out of our control.
Management is not onboard with the potential downtime on production?
This is going to require some risk analysis which is not easy, estimating losses due to cyber attacks or breaches is no simple task, hopefully your team has a proficient CISO that is able to communicate this risk in terms of dollars, that always gets the CFO onboard.