Building a Vulnerability Management program

Sharing is caring!

This is the first post in a series that will provide some (much needed) insight into vulnerability management. We will cover many angles of this topic from “Management Buy In” to reporting, scanning processes and quantifying what a successful vulnerability management program looks like.

This information will help anyone looking to start or improve their vuln management processes. You could be the ‘point of contact’ for all technical matters (regardless of your training & background) in a small business or you might be overseeing a department of engineers and analysts just looking for ways to improve. Because this series is vendor agnostic and follows a few simple ideas, the methods are nearly universal.

Finally, a word of caution. While I consider myself to be qualified to discuss this topic at length, remember that everything in this series is a generalization and in some instances may not apply to you or your organization. Alright lets get started…

The universal truth of vuln management…
Across industries, across all sizes of information systems there is an unfortunate universal truth when it comes to managing vulnerabilities within your system. It’s HARD. Each industry and every organization will have there own unique hurdles, the things that slow down progress or stand in the way of completion.

For this reason, I don’t believe in a one size fits-all solution or matrix of steps to follow. There is however a simple (not easy), method to building a vulnerability management program within your organization. These steps are built off from insights gained from managing the smallest of systems to the management of very large systems. Across them all, these same steps applied.

Management Buy In
Yes! The first step is not selecting a scanning platform, its not hand picking the best company to help you accomplish this goal and its not even reading articles like this before you start. Its getting senior level management buy in to support this program when the hard times arrive. The senior management should be informed of the risks posed by failing to properly manage vulnerabilities. You will need them when (for example) you discover a business critical application has the potential to disclose customer data but the app owner(s) want to delay the remediation until the end of the year. Who decides when the remediation goes? Senior management!

Management buy in will be needed to also:

  • Support the expanded budget to acquire the vulnerability scanning software (I.E. Rapid7, Tenable, Netsparker, etc…).
  • To provide additional man-hours to support the process (either from existing staff members or a new hire)
  • To acquire additional training for the new scanning tool
  • To provide the push to get team leads to vet false positives, join vuln management meetings and in general help this process exist outside of your scope of influence
  • Support you (and your team) when vulnerability scanning has a negative consequence on the information system (i.e. crash an app, empty a printer, etc…)
  • This is a lot to ask of a leader who is (in all likelihood) not a technical person. To get them comfortable with this new set of responsibilities you should be ready to discuss at length the potential (negative) impacts of vulnerability scanning. This person will also likely want to be kept in the loop, they might want day-by-day updates when the program first starts. Maybe they want to be a part of the regular vuln discussions that will occur. Whatever the request is, keep in mind they are asking because they “don’t know what they don’t know” and it is your job to help them discover and learn this process!

Alright! We have management buy in, he/she is sold on the idea and is now looking at you for next-steps. What now? Lets figure out what the environment to be scanned looks like. We will be building or verifying a CMDB or aka asset list in the second post in this series.

Comments are closed.
shares