Start Your Security Program With Vulnerability Management

Have you been tasked to start a security program? Then make sure to read this article. You can no longer afford to be green.

Let me preface this by saying that I work for a well known Cybersecurity company. I’ve developed the LA Cybersecurity Guy persona to write candidly about my experience in the space. I tend to work with security professionals who are responsible for developing or building out their own security programs. I take pride in providing a bit of insight on what it takes to really make a difference out there. Security professionals are the first ones to get blamed if something goes wrong and they are also the first ones to respond to any and all malicious behavior on a network they are responsible for. It’s a tough job, but if you start with what matters it can become just another task on your daily list.

In the last few months the media hype machine has been in full effect about ransomware attacks. These attacks normally take advantage of vulnerable operating systems which have not been properly maintained. Every business regardless of size tends to have some sort of legacy operating system which can easily be exposed to these sort of attacks. These machines require additional layers of security which patch management can not solve. Typically I would recommend some sort of Next-Generation Firewall (NGFW) for this particular use case. From there you can create a security policy which will virtually harden these legacy machines.

Now that we got that out of the way, let’s completely forget about firewalls. Let’s act as if they do no exist. Let’s pretend that the network we are responsible for only has one layer of protection which starts and ends with the operating systems installed on the wide array of endpoints that we maintain. This is ultimately where Vulnerability Management would come into play. Fortunately I have had several years of experience in this space and I’ve identified that effective vuln management really comes down to the following items:

  1. Discover
  2. Categorize
  3. Prioritize
  4. Report
  5. Remediate

Now that we have identified 5 steps that will encapsulate the majority of our vulnerability management program let’s discuss these numbered items a little more.

You can not fix what you can’t see. That statement may seem overly simplified but I did that on purpose. The first step to starting a vulnerability management program begins with discovery. There are a number of ways to discover endpoints on your network, some which are free and some which cost money. Regardless of the tool that you decide to use it is important to create a virtual blueprint of your network. For the sake of this article, I am not going to go into detail about the tools currently available for discovery. I will write something in the future which can be utilized as a resource and which will be vendor agnostic.

After you discover the endpoints in your environment it is important to organize these assets into categories. Thinking ahead will help you deliver the information that your remediation teams will need. If you are running a smaller security program and are wearing multiple hats, then this step will really help you organize the information that matters.

Lots of organizations have a problem with this step. This is something that really requires you and your team to think outside of the box. If you don’t get this right during the development stages of your vulnerability management program, then it really could effect your overall security posture later down the line. The best way to tackle this step head on is to start simple. Choose a category that everyone can identify with first and then expand on it.

For example, categorizing end-points based on the type of operating system they are running is a great starting point. You might have a mixed-OS environment, so separating Windows assets from Linux assets will be key to the remediation workflow. From there you can choose to go a step further and break those groups down into whether they are servers or workstations. You get the picture, the goal is to not over-complicate this particular stage. The layered approach I just described above can be custom tailored for just about any environment regardless of size.

Once you place your assets into categories, then you can spend time on prioritizing the items that matter. This step will require you to sit down with other team members to identify the most critical points of your network’s infrastructure. In pentesting, some might actually refer to these items as the assets that contain the flag or the crown jewels. Identifying the most critical assets in your environment will allow you to create a custom index internally that you can then rely on.

In my opinion this custom index is an equalizer. It allows you to not only manipulate the risk scoring system in your favor, but it allows you to also communicate to your executive team where the REAL risk resides on your network. Most of the vendors offering vulnerability management solutions tend to have their own proprietary risk scoring systems. The real question you need to ask yourself is whether the system itself can be custom-tailored to fit your own environment. If the answer is no, then the solution will not meet your future needs. Who wants to buy something that will become shelfware?

This step is by far the most important step to any vulnerability management program, so please treat it as such.

For those of you that are lucky enough to have your own Business Intelligence teams, you could probably depend on them to turn raw numbers into beautiful metrics. For the rest of us that don’t have the luxury of relying on a BI team, it is really important to generate actionable reports. It’s really important to think about the teams you are communicating with. Who are the beneficiaries of this data?

Immature vulnerability management programs will just slap some data together and wonder why their System Administrators and Helpdesk team members never seem to use what is provided to them. If you don’t have an open line of communication with those that are actually performing the remediation efforts, then you are pretty much dead to them. These actors don’t want to admit that they could be doing better. In their opinion things are either perfect or perfectly acceptable. As security practitioners, this just isn’t acceptable.

Start off with a few generic reports. The major vulnerability management vendors tend to suggest reports to start off with which really encapsulate those that will be receiving these reports. Here are a few reports that you should start off with:

  1. Remediation Plan
  2. Executive Overview
  3. Vulnerability Trending

From there you can setup meetings with the teams that will be utilizing these reports to see if they are acceptable in their current format or if they would prefer to have something that is more in line with the way they currently govern their remediation workflows. It’s not always easy to get teams to change old habits, regardless if they are good or bad. Setting up a weekly meeting with these teams will help you keep the communication lines open and get to a point where the data you are providing them is effective.


Chances are you already have a Remediation Workflow in place. If you lack a vuln management program, then you aren’t taking advantage of the right data. Just because something needs to be patched, doesn’t mean it is worth your team’s time doing so. You need effective analytics to tell you where the risk actually resides. Although I don’t recommend automating the patching process because of all the problems which could possibly occur with that, I do recommend merging vulnerability management and patch management into one seamless system.

At the end of the day, a vulnerability management program means absolutely nothing if the teams performing the actual remediations do not find the reports you are providing them useful. Some IT departments do not feel they are doing anything wrong. These organizations look at security teams as a burden to them because of the constant nagging and nitpicking. It is absolutely mandatory to create a synergy between security and IT. The goal is not to change what IT is doing, the goal is to make what they are doing better. Even if they find value in one report being generated by the vulnerability management system that would be considered a win.

In conclusion, Vulnerability Management can positively effect your company’s security posture. Start slow first to make sure you build that blueprint for success. Also remember that the effectiveness of your vuln management program doesn’t necessarily depend on the software that is purchased, it depends on the people in the background running the software and performing the remediations. Without them, the reports generated from such a system will be just that.

On a personal note, I have 3 years of experience in the Vulnerability Management space. I have had the luxury of working with countless organizations in the position I currently hold. If you have any questions on anything that pertains to Vulnerability Management, feel free to shoot me an email: lacybersecguy[a]