Last updated at Tue, 03 Sep 2024 21:04:34 GMT

Welcome to the third blog post on the CIS Critical Security Controls! This week, I will be walking you through the third Critical Control: Continuous Vulnerability Management. Specifically, we will be looking at why vulnerability management and remediation is important for your overall security maturity, what the control consists of, and how to implement it.

Organizations operate in a constant stream of new security information: software updates, patches, security advisories, threat bulletins, etc. Understanding and managing vulnerabilities has become a continuous activity and requires a significant amount of time, attention and resources. Attackers have access to the same information, but have significantly more time on their hands. This can lead to them taking advantage of gaps between the appearance of new knowledge and remediation activities.

By not proactively scanning for vulnerabilities and addressing discovered flaws, the likelihood of an organization's computer systems becoming compromised is high. Kind of like building and implementing an ornate gate with no fence. Identifying and remediating vulnerabilities on a regular basis is also essential to a strong overall information security program.

What it is:

The Continuous Vulnerability Management control is part of the "basic" group. This control consists of eight (8) different sections with 4.1 and 4.3 giving guidelines around performing vulnerability scans, 4.2 and 4.6 talk about the importance of monitoring and correlating logs, 4.4 addresses staying on top of new and emerging vulnerabilities and exposures, 4.5 and 4.7 pertains to remediation, and 4.8 talks about establishing a process to assign risk ratings to vulnerabilities.

How to implement it

To best understand how to integrate each section of this control into your security program, we're going to break them up into the logical groupings I described in the previous section (scanning, logs, new threats and exposures, risk rating, and remediation).

A large part of vulnerability assessment and remediation has to do with scanning, as proven by the fact that two sections directly pertain to scanning and two others indirectly reference it by discussing monitoring scanning logs and correlating logs to ongoing scans. The frequency of scanning will largely depend on how mature your organization is from a security standpoint and how easily it can adopt a comprehensive vulnerability management program. Section 4.1 specifically states that vulnerability scanning should occur weekly, but we know that that is not always possible due to various circumstances. This may mean monthly for organizations without a well-defined vulnerability management process or weekly for those that are better established. Either way, when performing these scans it is important to have both an internal and external scan perspective. This means that scans on machines that are internally-facing only should have authenticated scans performed on them and outward-facing devices should have both authenticated and unauthenticated scans performed.

Another point to remember about performing authenticated scans is that the administrative account being used for scans should not be tied to any particular user. Since these credentials will have administrative access to all devices being scanned, we want to decrease the risk of them getting compromised. This is also why it is important to ensure all of your scanning activities are being logged, monitored, and stored.

Depending on the type of scan you are running, your vulnerability scanner should be generating at least some attack detection events. It is important that your security team is able to (1) see that these events are being generated and (2) can match them to scan logs in order to determine whether the exploit was used against a target known to be vulnerable instead of being part of an actual attack. Additionally, scan logs and alerts should be generated and stored to track when and where the administrative credentials were being used. This way, we can determine that the credentials are only being used during scans on devices for which the use of those credentials has been approved.

So now that we have discussed scanning and logs, we are going to address how you can keep up with all of the vulnerabilities being released. There are several sites and feeds that you can subscribe to in order to stay on top of new and emerging vulnerabilities and exposures. Some of our favorite places are:

It isn't enough to just be alerted to new vulnerabilities, however, we need to take the knowledge we have about our environment into consideration and then determine how these vulnerabilities will impact it. This is where risk rating comes into play. Section 4.8 states that we must have a process to risk-rate a vulnerability based on exploitability and potential impact and then use that as guidance for prioritization of remediation. What it doesn't spell out for us is what this process looks like. Typically, when we work with an organization, we recommend that for each asset they take three factors into consideration:

  1. Threat Level – How would you classify the importance of the asset in terms of the data it hosts as well as its exposure level? For example, a web server may pose a higher level of threat than a device that isn't accessible via the Internet.
  2. Risk of Compromise – What is the likelihood that the vulnerability will compromise this system? Something to keep in mind is how easy is it to exploit this vulnerability, does it require user interaction, etc.
  3. Impact of Compromise –What is the impact to the confidentiality, integrity, and availability of the system and data it hosts should a particular vulnerability gets exploited?

After our scans are complete and we are staring at the long list of vulnerabilities found on our systems, we need to determine the order in which we will do remediation.

In order to ensure patches are being applied across all systems within the organization, it is recommended to deploy and use an automated patch management tool as well as a software update tool. As you look to increase the overall security maturity of your organization, you will see that these tools are necessary if you want to have a standardized and centrally managed patching process. In more mature organizations, part of the remediation process will include pushing patches, updates, and other fixes to a single host initially. When the patching efforts are complete on this one device, the security team then performs a scan of that device in order to ensure the vulnerability was remediated prior to pushing the fix across the entire organization via the aforementioned tools. Tools are not enough to ensure that patches were fully and correctly applied, however. Vulnerability management is an iterative process, which means that vulnerability scans that occurs after remediation should be analyzed to ensure that vulnerabilities that were supposed to be remediated are no longer showing upon the report.

Vulnerability management software helps you identify the holes that can be used during an attack and how to seal them before a breach happens. But it's more than launching scans and finding vulnerabilities; it requires you to create processes around efficient remediation and to ensure that the most critical items are being fixed first. What you do with the data you uncover is more important than simply finding vulnerabilities, which is why we recommend integrating the processes around each section of Critical Control 4.

Like what you see? Check out our next post in this series, “The CIS Critical Security Controls Explained, Part 4: Controlled Use of Administrative Privilege.”