Before moving on to discuss vulnerabilities, I hope I don't have to remind you that the use of vulnerability scanning tools to probe systems or networks that you do not own or have explicit permission to test is illegal in most jurisdictions. Unauthorized scanning can be considered a form of hacking or computer intrusion and may result in civil or criminal penalties.

Moving forward, when discussing vulnerabilities, you won't get very far before you collide with CVEs, or Common Vulnerabilities and Exposures, a system developed by MITRE to provide a standardized way to identify and catalog vulnerabilities in software and hardware.

When a new vulnerability is discovered (whether it be in malware or insecure software from a vendor, etc.), the MITRE corporation collaborates with the reporting entity to perform an in-depth analysis to rank the CVE with CVSS Score (Common Vulnerability Scoring System)

In addition, MITRE has developed useful resources, such as the CWE (Common Weakness Enumeration), a community-developed list of software and hardware weaknesses, as well as the MITRE ATTACK framework. The framework is not only useful for understanding adversarial attack patterns but is also referenced for each CVE/CWE.

For example, if a software developer is writing code in C for an API, if not checked, dangerous functions may be written into the source code, allowing for buffer overflows to access various unintended locations of running memory.

CWE - CWE-242: Use of Inherently Dangerous Function (4.13) (mitre.org)

This is a CWE that could have been prevented with an analysis tool for static code analysis testing (SAST). Tools such as cppcheck, a tool for analyzing C/C++ code, and SonarQube. Other scanners include cwe_checker, bandit, and Brakeman.

This is why we, as security professionals, should ensure secure coding practices are maintained, including awareness training and tool or peer review.

Regarding these vulnerabilities, proper due diligence should be upheld by performing a risk assessment of the discovered vulnerabilities appropriate to their environment.

For example, suppose there is a database software vulnerability that is moderate in CVSS (3.9), meaning it poses a considerable risk and is typically found in databases that are accessible to the public. More research, however, shows that the vulnerability is essentially unexploitable remotely because of strong security and hardening mechanisms such as network segmentation service, port limitations or preventative input validation, etc. This shows that there is a mismatch between the assigned CVSS score and actual exploitability. Even though the actual risk is present, it is greatly reduced by these safeguards.

In most cases, tools will be used to interact with and interface with vulnerabilities, so let's reference some commonly used tools. Some examples include Rapid7, Tenable, Qualys, and even cloud service offerings such as Amazon Inspector and Azure Defender.

These tools definitely have their place, but I'll avoid going down the vendor/product trail. For added clarity, vulnerability scanners come in many shapes and sizes, from your web application scanners, port and service scanners to SAST/DAST code analyzers. In development, DevSecOps pipelines can be established to automatically perform these scans with deployment tools such as Jenkins.

Let's go back a step to discuss the big picture and why vulnerability management is so important.

We've performed our risk assessments, put out a request for proposal (RFP), performed assessments for third-party risk management, weighed the options, and selected a scanning vendor. An engineer has deployed a VM and run BASH scripts to install the vendor packages on the server, set up the licensing, and install agents or agentless configurations. Application accounts were created with administrative access to perform credentialed scans. All is well.

The scanning begins, and there are findings, which is good because it means we can understand what needs to be remediated. But there's an issue. We see that there are problems, but how do we correct them?

This is where vulnerability management truly begins.

Depending on the type of vulnerability, remediation efforts may wildly vary. Another question we have to ask is, where did the vulnerabilities come from?

Are we using older hardware that's end-of-life (EOL) or not supported (EOS)?

If we're cloud-native, how are these systems being added to the inventory? Are developers using the latest images for our clustered workloads? Are there any dependencies or reasons why we're unable to remediate the issue?

Perhaps we're not even at that stage yet.

Who is responsible for updating or patching systems?

The organization is likely structured in a way that doesn't allow the vulnerability scanning admin(s) to also manage patching or configurations. Maybe we should have an entire team designated for patching in a timely manner. What threshold of the risk calculation are we willing to accept versus mitigate?

What if we're not even at that stage yet?

Are these scans internal or external?

What types of systems are being scanned?

Are we simply going based on the CVSS score?

How are we calculating risk? Is it additive or multiplicative, and why?

(Threat + Vulnerability = Risk)

(Threat * Vulnerability = Risk)

Do we need to use Magerit (from Enisa) for our calculations?

Are we subject to any regulations or authority documentation, such as PCI DSS 4.0 or SOC 2?

Remember, those high-critical vulnerabilities need to be remediated at least once every 3 months (~90 days) [Requirement 11.3 of PCI DSS 4.0]

These questions are often overlooked, but whatever the case may be, the effort we're criticizing here is in the business process, which significantly varies from business to business. One patch here may cause an issue there.

IT infrastructure is static, while architecture is dynamic.

Vulnerability management requires a dedicated team, with individuals who understand the role they play in the bigger picture and communicate with the various departments where these vulnerabilities arise. If scans are not being performed, systems are not being patched, or systems are being deployed into production in an insecure state, there's a problem. The issue doesn't stem from technicality; rather, it is a business or administrative issue.

Looking back at this writing, we've covered a lot. We've introduced and gone over tools used in the vulnerability management space. We've also asked valuable and impactful questions, getting down to the why and how. I hope you've enjoyed this post as much as I've enjoyed writing it.

The last thing I'll say is that I highly recommend taking advantage of all of the free vendor training they provide. Remember, they want you to be skilled with the product so they can get the most value for the client. I'm talking Qualys, Rapid7, the SC-200 from Microsoft for Defender 365/Cloud, AWS Security for Inspector, and others.

Vulnerability management jobs are out there. If you don't know how to do something, check the documentation. I'm sure the answer is out there.