Best practices for your Vulnerability Management Program

Nowadays most organizations have begun to implement a Vulnerability Management Program (VMP), but implementing one is daunting. Most organizations realize they either have no true categorical ownership over systems or they lack the authority to enforce remediation of identified vulnerabilities. Either way, it is time consuming to track down and enforce a true VMP within many organizations.

What is a Vulnerability Management Program?

If you are new to implementing a VMP, then you first must understand what vulnerability management is. It seems self-evident, but it is the management (life-cycle) of identifying risks related to unpatched, misconfigured and unknown systems within an entity and implementing a remediation process for any identified risk.

Within any vulnerability management program you typically have these milestones:

• Identification of vulnerability management hardware/software
• Asset and owner identification
• Policies related to scanning, reporting and remediation of vulnerabilities

When implementing a VMP, most organizations start with implementing a policy that all must follow. This can work for some organizations, but in my experience, you are pigeonholing yourself to work within arbitrary boundaries when you have no baseline of what is capable when it comes to remediation of vulnerabilities. I suggest that you wait on implementing a policy until you know what is capable.

Identification of vulnerability management hardware/software

The first step you should take is to have an arbitrary list of requirements from your organization. This means go talk to the individuals that will be impacted by a vulnerability management policy and gather your requirements. In my experience, asking the following questions will help generate your initial requirements:

1. Asset and owner identification:
   1. Do you have an inventory of all systems (machines) for which you are responsible?
   2. Do you know the criticality of those systems in relationship to the organization’s data classification system?
   3. Are there grey areas where you are the owner of a specific piece of software but not the entire system?
2. Policies related to scanning, reporting and remediation of vulnerabilities:
   1. What seems like a reasonable scanning period for your systems? Two weeks? Four weeks? Every quarter?
   2. If you were to receive a report of all your systems, what format works best for you?
   3. How often do you update the systems under your control?
   4. Are there cases where you cannot upgrade/update software on a specific system? Why?

These questions should begin to outline you base requirements for any hardware/software scanning product on the market, and there are quite a few of them. Once you have identified your overall requirements, find and set up demos of products that meet your requirements.

Finding a product that meets your needs will not be difficult, but I definitely recommend that you choose one that has an API. I have extensive experience with both QualysGuard Vulnerability Management (VM) and Tenable’s line of products, but there are plenty of additional products available as well.

Asset and owner identification

In the previous list of questions I mentioned one that is extremely important with identifying an asset and it’s owners: Are there grey areas where you are the owner of a specific piece of software but not the entire system?

This question seems straightforward, but imagine a web application that has a front-end, back-end database, and the server it resides on. Each of these may be maintained or owned by different departments within your organization. So who is responsible for patching/updating this web application? Identifying and coming up with an agreement on where those lines are is critical for your VMP.

Once you have identified these grey areas, determining the remaining assets and their owners is fairly straightforward. You can approach identifying assets by either doing an internal (unauthenticated) scan to identify all systems on your network(s) or by reaching out to your networking team. They have this information.

Identifying the owners may be trickier depending on your network topology. If your network is segmented you should be able to identify owners by subnets. If not, simply add identified assets in an excel sheet and start tracking down the owners of each system.

Tracking and ensuring the asset/owner relationship is continually updated is also difficult—especially if you are in a larger global organization. The import part at this time is creating that initial list. Most vulnerability management products will have an asset and owner management component that will help alleviate some of these concerns once it is implemented.

Scanning, reporting and remediation policies

Now that your general requirements have selected a vulnerability management product (even if only on a trial basis) and have a centralized list of assets and owners, it’s time to perform a gradual roll-out of your VMP.

Select a department or organizational unit that you believe will work with your team closely. You can even start with your own department’s assets.

Almost all vulnerability management products have two (or more) scan types: unauthenticated and authenticated.

Unauthenticated scans means that the vulnerability management product will attempt to guess at what each system is, what ports are open, what OS the system has, and attempt to identify vulnerabilities based on this information.

Authenticated scans means that the vulnerability management product will login to the asset using a provided ssh key, username/password, or requires an agent to be installed on the system. This type of scan is more valuable for an organization and gives you exact results without guessing. It will identify outdated software versions, missing updates/packages, open ports, firewall rules, etc.

Once you have decided on a scan type to be used for either a specific asset or all assets, you should begin testing the scanning and reporting functionalities of your vulnerability management product. This time period of testing can range between two weeks to six months, depending on your organization size and structure.

The point of this is to determine which scan configurations impact your organization the most. There are multiple ways to configure what is scanned for and what is not. This is all dependent based on your overall objective for your VMP. I suggest focusing on key areas first. This is completely subjective, but I would first focus on these areas before trying to remediate everything:

• External scan: Determine what is visible to the outside world.
• External scan: Determine what ports are open externally.
• Internal scan (unauthenticated): Determine network map/topology and open ports.
• Internal scan (authenticated): Scan a subset of hosts using an authenticated scan.
• Finally, set up a schedule for every two weeks, a month, etc., depending on your organization.

By first establishing a baseline, you can make determinations on what is feasible based on system types instead of mandating an arbitrary time duration. Establishing a scheduled scanning duration that meets your organization’s requirements but does not overwhelm the system owners is crucial. As the asset owners get used to this new process, they will become more cognizant of their responsibilities and be far better off at responding when critical vulnerabilities are released that impact their systems.

The point of a VMP is to remediate any found vulnerabilities as quickly as possible, but you cannot accomplish this by simply turning on the fire hose. If you give someone a report that says their 100 servers/systems are vulnerable to these 1,000 vulnerabilities, they will not know where to even start. So, it’s important to focus on providing reports that focus on the critical areas first (e.g. open ports, configuration settings, unpatched Level 5 vulnerabilities, etc).

Once these critical areas are addressed, move on to Level 4, Level 3, Level 2, etc.. If (when) a new critical vulnerability is identified, then switch gears and focus on patching that vulnerability. Once remediations have been completed, continue moving forward by eliminating the next highest level vulnerability—rinse and repeat.

Another approach is to tackle your most critical systems first. This can help elevate the overall organizational risk while making progress on the overall results. In my experience, the most critical systems for an organization often rely on outdated software. Try and remediate those vulnerabilities by working with your vendors or putting in mitigations to these vulnerabilities.

Vulnerability management and your VMP should not be considered a race. This new program is a never-ending service your security team is taking on, so approach it with patience, and do not expect that all vulnerabilities will be remedied within the first year. It won’t happen.

Vulnerability Management with SOAR datasheet

Unpatched, unrecognized and misconfigured hardware, applications, security stacks, systems, endpoints and cloud services can result in massive security breaches via open ports, configuration settings, and unpatched vulnerabilities. Download the datasheet today to learn how Swimlane can integrate with your vulnerability management tools and provide centralized visibility across your entire security stack.

Read Now