A Simple Guide to Vulnerability Management

A “vulnerability assessment” discovers what vulnerabilities are present on your organization’s infrastructure and classifies them according to their level of criticality. Vulnerability assessments are usually conducted by qualified personnel or Approved Scanning Vendors (ASVs) by means of a vulnerability scanner, such as Nessus, OpenVAS, QualysGuard, Nexpose, and so on. These are special forms of software designed to assess computers, information systems, networks and applications for weaknesses that could be exploited by cybercriminals. Some common vulnerabilities often seen on our networks are weak passwords, missing patches or updates, misconfigurations, and lack of encryption. However, there are literally thousands of different vulnerabilities that these scanners can detect and, as a bonus, they usually include a remediation or suggestion for each vulnerability they detect.

Vulnerability assessments may not always be a requirement, but they are necessary if security is your top concern. If your organization sits in a regulatory environment, then it’s likely that vulnerability assessments are required to meet compliance. Companies that handle credit card information must comply with the Payment Card Industry Data Security Standard (PCI DSS) and conduct internal and external vulnerability assessments of their systems and processes every quarter. Likewise, agencies that handle federal information systems are required to conduct vulnerability assessments of their assets in accordance to the Federal Information Systems Management Act (FISMA). Companies or hospitals that handle personal health information must comply with the guidelines established in the Health Information Portability and Accountability Act (HIPAA). Though HIPAA does not strictly require vulnerability assessments, it does require a risk analysis, which is usually accomplished with the assistance of a vulnerability scan.

Before the Scan

Before a vulnerability scan is conducted, your organization should consider the following. Depending on the scope of the assessment, the results of a vulnerability scan can be very lengthy. Ideally, you’ll want to consider the capabilities of your staff, your goals, and any constraints hindering your assessment and remediation.

Consider the residual risk and the amount of risk your organization is willing to accept. Sometimes, we can simply avoid a risk by not providing a service or simply opting out of something. Similarly, if a security control outweighs the risk itself, it might just be better to accept that risk. On other occasions, we can transfer risk to a third party, such as an insurance company. Or, we can mitigate a risk by implementing security or compensating controls that eliminate the vulnerability or reduce its impact.


Are you required to follow a specific regulation? If so, inquire into what the regulatory body requires from your organization. Often times, regulatory environments are not only required to conduct vulnerability assessments, but are also expected to remediate uncovered vulnerabilities and prove that these vulnerabilities are resolved through an additional vulnerability scan. The PCI DSS requires a vulnerability scan whenever there have been any significant changes to systems or processes, so it pays to know how frequent scanning should occur and when scanning should occur off-schedule.

Assess any technical constraints that are impeding the vulnerability assessment and address them before the scan. Do you have personnel that are qualified to conduct the vulnerability scan? If not, consider hiring an ASV. Does the frequency of your intended vulnerability scans require higher technical capacity? Sometimes, vulnerability assessments can affect the systems being scanned. Servers can slow down and printers can act erratic, so address the scope of the vulnerability scan as well. If a server is bringing in thousands of dollars in revenue per hour, you should rethink how you scan this server. Similarly, you have to be careful with what information is on these systems. If you’re scanning a server that holds personal health information, you must be sure that the vulnerability scan does not somehow reveal this type of sensitive information

Address Your Scanning Criteria

As I just briefly mentioned, consider the security and classification of the data of the assets your are scanning. What standard information classification does it hold? Is the system holding corporate confidential information or proprietary information whose improper disclosure could severely damage the company? Take care to ensure that this information isn’t compromised

Take a look at your vulnerability feed. The NIST’s “National Vulnerability Database (NVD)” provides an RSS web feed that alerts subscribers to new vulnerabilities when they are discovered or analyzed. When a critical vulnerability is discovered, you’ll know when it’s appropriate to conduct an out-of-schedule vulnerability scan to uncover if the vulnerability resides on your network.


A list of Common Vulnerabilities and Exposures (CVEs) for April 2018 reprinted from the NVD Web site. 

Organizations should also contemplate the scope of their vulnerability assessments. It would be nice to scan the entire network at once, but this isn’t feasible. Instead, create a series of scans and perform each one separately. Start the scan, take a nap, and then wait for an alert for when the scan is finished. Then, start the next scan.

Think about the type of vulnerability scan you want to conduct. There are credentialed scans and non-credentialed scans. As its name suggests, a “credentialed” scan uses the credentials of an account(s) for the vulnerability scan. This allows the scan to penetrate much deeper into our systems and reveal more vulnerabilities. With a “non-credentialed” scan, we are evaluating our systems from the seat of the attacker. These scans are much quicker, but yield less results.

Vulnerability scanners, like Nessus, are server-based or agent-based. In a “server-based” architecture, the Nessus server resides on the host or somewhere else on the network. The server is responsible for coordinating the vulnerability scan and generating reports. The server detects active hosts on the network and scans them for vulnerabilities. This traditional scanning method is easy to do, but takes up a lot of bandwidth. The “agent-based” architecture, on the other hand, has agents installed on every host. The hosts then conduct the vulnerability scans on themselves and the agents report the results back to the server. Since the vulnerability scan isn’t being conducted over the network, it takes up less bandwidth. So, decide which type of architecture is best for you.

server-based agent-based.png

What information do you wish to include in your report? This might be specific for regulatory compliance or you might want to look for specific weaknesses. Luckily, vulnerability scanners come with thousands of different plug-ins to choose from, which scan for the specific flaw you’re interested in. Furthermore, there is the “Security Content Automation Protocol (SCAP),” which was created by NIST to standardize the way in which vulnerability scanners report vulnerabilities. That way, you don’t have to worry about whether or not your particular vulnerability scanner complies with regulatory requirements. As long as it supports SCAP, you should be fine because SCAP follows a similar reporting format and CVSS score for every scanner.



How will you prioritize the vulnerabilities you discover? Sometimes, the amount of vulnerabilities are overwhelming, so you must come up with a plan to prioritize them. Here are some options that will assist you.

Clearly, you’ll want to prioritize the more critical vulnerabilities first. And fortunately, most vulnerability scanners already classify vulnerabilities by their level of criticality by following the “Common Vulnerability Scoring System (CVSS),” which ranks vulnerabilities on a scale from 0 to 10. The higher, the number, the more severe the vulnerability is.


Administrators would likely prioritize the two critical vulnerabilities first. 

Think about how difficult it will be to remediate the vulnerability. Sometimes, there are budget constraints, technical constraints, or operational constraints that hinder the remediation process. Or, perhaps there needs to be ample time for a compensatory control to be developed and implemented. Also, consider the capabilities of the change control committee. Each change request for remediation will be have to reviewed and approved by the change advisory board because we have to ensure that the change is necessary and not putting the organization at risk. Therefore, you might want to prioritize the quicker changes too.

Common Inhibitors to Remediation

The corporate governance of your organization, that is, the way in which organizations conduct its operations, may interrupt the remediation process. Some remedial actions might interrupt important business processes, and senior leaders might not appreciate this negative effect. Some systems, especially legacy and critical assets, are more sensitive to disruption. Efficient communication is a necessity here. You’ll have to make it clear to senior leaders or executives that the remedial actions might reduce process time, but it will increase efficiency and security. If the fear of interruption pushes senior leaders to avoid remediation, you’ll have to come up with a compensatory control.

When vulnerabilities are discovered, they’re often patched with a new update. Patches should be tested in a sandbox before they’re rolled out onto production networks because a bad patch could degrade the functionality of a system or application. Imagine rolling that patch out to multiple critical systems only to discover it crashes each system. If a patch proves faulty in a test environment, you’ll have to try again or consider another type of control.


Maymi, F. J., Chapman, B. (2018). All-in-One CompTIA CSyA+ Cybersecurity Analyst Certification Exam Guide CS0-001. McGraw-Hill Education: New York, NY.

Scarfone, K., Souppaya, M., Cody, A. & Orebaugh, A. (2008). Technical Guide to Information Security Testing and Assessment (NIST Special Publication 800-115). Retrieved from the National Institute of Standards and Technology Web site: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: