What to know about vulnerability scans for the Security+ exam
Regularly auditing systems for potential vulnerabilities is an important part of securing an organization’s environments, systems, and applications. One of the ways that we can achieve that is with vulnerability scanning. In this post, we’re going to talk about important concepts you need to know about vulnerability scans for the Security+ exam.
What are vulnerability scans?
Vulnerability scanning uses automated tooling to look for potential issues in your systems, devices, and networks. By looking for weaknesses, issues, or misconfigurations proactively, the goal is to identify what they are and how to fix them before a malicious actor finds them and exploits them.
So the main goals of vulnerability scans are to:
- Identify vulnerabilities
- Identify common misconfigurations
- Identify needed security controls
By being able to identify vulnerabilities, common misconfigurations, and needed security controls, we can take vulnerability scans and turn them into actionable reports. It basically gives you a prioritized list of what needs to be fixed, and in what order.
Vulnerability scanning results
If weaknesses or vulnerabilities are found during a scan, what are the next steps?
We can think of that as our plan of action, and that is defined as part of a vulnerability management program.
Sometimes the same team that ran the scans will take action on them, while other times the report gets handed off to a different team. Typically, though, someone will need to verify and test the results to determine if they’re accurate or not.
If the results are accurate, then we can identify what security controls need to be implemented to fix the issues before they get exploited.
The solution could be anything from changing application code, all the way to modifying configurations.
The types of results that you get also depend on whether you are running an intrusive or non-intrusive scan.
Intrusive vs. non-intrusive scans
Non-intrusive scans
A non-intrusive scan is one that only aims to gather information about issues. It doesn’t actively attempt to exploit any issues that it thinks it found.
So if the tool believes that it found an open port that it could exploit, for example, it would simply report that it found the open port, but it wouldn’t try to see if it is exploitable.
This is a much less aggressive form of scanning that minimizes the likelihood of causing damage to an environment since it’s not trying to alter the targeted system in any way.
Intrusive scans
Intrusive scans do attempt to exploit vulnerabilities or weaknesses based on the information that gets gathered. This means it may able to provide more accurate results, and it can help provide more information about the severity of an issue.
That benefit comes with its own potential problems. If there is a legitimate vulnerability, and the tool exploits it, it could modify or damage data. For production environments, that would be a major problem and is not acceptable.
When to use one over the other
So overall, intrusive scans are typically only used on environments that mimic production environments…such as on development, testing, or staging environments.
Non-intrusive scans are less risky to use on production environments and may also be more practical to use on a regular basis, whereas intrusive scans might make more sense to perform on a less frequent basis and as part of a more in-depth checkup.
Credentialed vs. non-credentialed scans
The effectiveness of scans also depends on whether you are performing a credentialed or non-credentialed scan.
Non-credentialed scans
Non-credentialed scans are searching for vulnerabilities in publicly-facing systems, devices, or networks. The scan is not accessing environments that require authentication.
This is great for faster scans that can be performed on a more regular basis, but it provides little to no visibility into any of the internal systems, devices, or networks. That usually means that non-credentialed scans won’t find potentially critical vulnerabilities in applications, network devices, or operating system versions unless they are exposed to the open Internet.
Some organizations are fine with that because they feel like their internal networks won’t get breached, so it’s not worth spending time on looking for issues there. Of course, if those internal networks do end up getting breached, there could be major vulnerabilities that are easily found by the malicious actor that could have been prevented.
Credentialed scans
Credentialed scans are the opposite of non-credentialed scans, which means that the scan is able to access areas that are typically restricted to the general public, or that require some form of authorization to access.
Because credentialed scans have more access, they can look for issues in internal or gated applications, internal network devices, and operating systems powering our servers, devices, etc…
This typically means that credentialed scans are a lot more involved, take longer to complete, and require more processing power as well as network usage.
False positive and false negative results
Once you run the automated vulnerabilities scans, you will receive a bunch of results. Some results will be informational, while other results will be labeled as vulnerabilities with a ranking of the estimated impact.
Of those labeled vulnerabilities, you may have false positives. Or, you could also have false negatives.
False positives
False positives happen when a scan flags a vulnerability that ends up not being an actual vulnerability.
The automation tool thought that it had found one, labeled it as such in a report, but it turns out to be a false alarm.
False positives happen all of the time. There can be a number of reasons for that, far too many to list, but it highlights why human verification is so important.
False negatives
False negatives, on the other hand, are far worse than false positives. Instead of the vulnerability scan reporting a false alarm, it fails to report a valid vulnerability because it didn’t find it.
When in reality, there is a vulnerability, and the report simply gave you a false sense of security.
False negatives are considered far worse than false positives, because false positives at least give you a chance to verify even if they end up wasting time.
Speaking of human verification, let’s talk about the differences between vulnerability scanning and penetration testing.
Vulnerability scanning vs. penetration testing
While we will talk about penetration testing in a separate post, I do want to mention it here because penetration testing and vulnerability scanning are sometimes assumed to be the same thing, when in fact, they have differences.
Vulnerability scans
A vulnerability scan, as we talked about, is an automated and high-level test that looks for potential security vulnerabilities in systems. You configure the scan for your environment, you run it, and then you look at the results.
Penetration testing
Penetration testing, on the other hand, is a more manual approach. Following our scanning example, a pentester could take the results of that vulnerability scan, and then attempt to manually exploit identified vulnerabilities.
In general, penetration tests attempt to achieve an objective like: access sensitive data, modify configurations, and so on. If the tester achieves one or more of these goals, they will then report back how it was achieved and what needs to be fixed.
Pentesters use automated tools all of the time to speed up the process, but they will typically take results from those tools and attempt to exploit what was found. They should not be relying strictly on the results of automated tools in their reports, otherwise, they are just performing a very expensive vulnerability scan.
Even if you are running an intrusive scan, automation can only take it so far. Humans are still far more capable when it comes to testing in-depth for many types of vulnerabilities.
Tools to perform vulnerability scans
Examples of automation tools
Speaking of tools, there are a number of vulnerability scanning tools that exist. Some of them are free, some are open source, and some are paid and closed source. For example, we have:
Pro tip: all of the above except for Acunetix are free tools (or have free tiers). It’s well worth the time to set one or more up in a virtual machine if you’re still fuzzy on what vulnerability scanners do and how they work.
While each tool will have its differences and function a little bit differently, most of them are very similar.
Determining impact
They will typically provide the name of the result and the estimated severity. They might say that something is:
- Informational
- Low level risk
- Medium level risk
- High level risk
- Critical level risk
Most of this information comes from the Common Vulnerabilities and Exposures (CVE) and Common Vulnerability Scoring System (CVSS) so that you can further investigate what the issue is and why the tool rated it the way that it did.
Again, the point here is to make these reports as actionable as possible so that stakeholders can take a look and understand what’s going on.
Conclusion
Think of vulnerability scans as being very helpful when it comes to finding low-hanging fruit issues, and nothing more. They are not a silver bullet, they are not going to find every security issue that exists in your networks, and they do need human intervention. But, they also can help save a lot of time and they absolutely should be part of everyone’s security testing.
If you’re studying for the CompTIA Security+ certification exam, check out our course and practice exams where we teach this and everything else you need to know to pass and get certified!
We also have an Ultimate Guide to Passing the CompTIA Security+ to help you find the resources you need.
Responses