How to conduct a vulnerability assessment

The realm of information security is fraught with jargon, as anyone who has come across vulnerability-related terms can tell you. To complicate matters further, some of these terms are used interchangeably or in contexts outside of computing. This can muddy the waters for people looking to learn about vulnerability assessments – so in this blog we’ll begin by demystifying the language, before delving into how you can perform vulnerability assessments on Ubuntu installations. 

What is a vulnerability?

A vulnerability is any kind of defect that can cause harm if either exploited by a malicious threat actor, or accidentally triggered by an unwitting well-intentioned user. In the context of risk management, a vulnerability will increase risk, by making a threat more likely, increasing the loss caused by a threat materializing, or both.

In cybersecurity, a vulnerability is most commonly understood to be one of two things:

• a logic flaw in a system, most often software code, that could result in an adverse impact;
• a misconfiguration or misuse of a system that similarly weakens overall security.

This distinction is somewhat arbitrary, but it’s important for you to know it due to its prevalence within cybersecurity. We’ll use this distinction to form the basis for the rest of our discussion. 

To make things more tangible, here are two examples of well-known vulnerabilities:

• Log4Shell – a critical flaw in the popular Apache Log4j software framework that, under certain circumstances, exposes an application using this component to remote exploitation via the execution of arbitrary attacker-controlled code;
• The inadvertent exposure of an internal service to the Internet – a generic description that falls into the latter, misconfiguration category; such an instance does not affect a particular product, but rather any incorrectly set up system deployments.

The wider view

A vulnerability assessment is the process of identifying and reporting vulnerabilities found in a system at a particular moment in time. This is normally highly automated and performed on a frequent basis by using a service, or software application, known as a vulnerability scanner. It is a central part in an organization’s wider vulnerability management strategy, but it can also be performed as part of your regular risk assessments.

Government regulations and industry standards often mandate vulnerability assessments. As an example, certain compliance levels of the PCI DSS standard used by the major payment card companies require merchants that take online payments to implement vulnerability assessments using Approved Scanning Vendors (ASVs).

Even when there are no regulatory compliance requirements, best practice dictates that vulnerability scans should still be performed – after all, vulnerabilities increase risk and there are few things worse for one’s security posture than not knowing which vulnerabilities exist. Frankly, it would not be wise to leave yourself exposed to threats, just because you are not mandated to perform scans.

Preparation

The initial steps to putting together a regular or one-off vulnerability assessment are the following:

1. Identify and classify the systems that are to be scanned. These systems are often called “assets” and will form the targets of the scan. Determining the functions and criticality of the targets is going to be crucial to interpreting the results and prioritizing any necessary remediation.
2. Define what kind of vulnerabilities are in scope of the assessment. It may be the case that all publicly-known vulnerabilities affecting installed software need to be found; or that the scope should be limited to any issues that can be identified over the Internet by a threat actor, whether misconfiguration or outdated software.
3. Choose an appropriate scanner, according to the scope defined in the first two steps. Solutions from different vendors take different approaches and they may not all be appropriate for the requirements you’ve identified.

Performing the scan

This is the simplest step and, as previously mentioned, it is often automated. There are two main classes of scanner:

• Network scanners reach out to the target over the Internet or a private network and perform a series of tests. There are two approaches that you can take here:
  • An unauthenticated scan will base its results exclusively on what can be determined from the outside, just as an attacker would. The scanner will not be given credentials to access the system, with the downside that all installed software and their versions are unlikely to be identified accurately.
  • An authenticated network scan, on the other hand, makes use of access to the target in order to derive more accurate information. It will provide more comprehensive results, but will fail to shed light on what an attacker can observe.

Either way, network elements such as firewalls or intrusion prevention systems (IPS) may interfere with the activity or raise operational alerts, as is their purpose.

• Host scanners are fully-fledged applications or thin agents that run on the target system directly and collect data, such as installed software versions. Often with privileged access to the operating system, a host scanner is in a better position than a network scanner to provide a full list of known software vulnerabilities. The downside is that mitigating security controls, such as the aforementioned IPS, would not be taken into account. An alternative to utilizing a running system, but with a similar end result, is to run a host scanner against the target’s offline disk or root filesystem.

The scope of the vulnerability assessment will dictate the type of scanner and the approach used. Whatever your choice, it is important to remember that scanners can give out false positive or false negative results. False positives are vulnerabilities that are reported, but do not actually exist whereas false negatives are vulnerabilities which do exist, but are missed by the scanner.

Once a scan completes (which can take anywhere from seconds to hours), a report is produced. Along with data about the target, this report contains information concerning the identified vulnerabilities, such as whether there are CVE IDs assigned along with their CVSS scores, as well as in-depth descriptions and potential remediations or mitigations.

Interpreting results

Scanning tests are not infallible and it is important to remember that scanners rarely test for the vulnerabilities directly, especially when it comes to known software or hardware flaws (such as those that are assigned CVE identifiers). Instead, they rely on indirect cues, such as the version of an installed application. 

This poses a problem with open source, when vulnerabilities are fixed without upgrading to the latest upstream software version. In Ubuntu, fixes are backported to provide stable security updates for LTS releases, a process designed to ensure compatibility and maintain stable behaviour. Therefore, packages do not get the same version that the upstream OSS project uses. Instead, the fix receives a version unique to the Ubuntu ecosystem, just as would happen with other stable-release Linux distributions. Many scanners correctly take this into account, but the full information may not always be available, as is the case with unauthenticated network scans (for which even the Linux distribution’s name may be concealed).

Notwithstanding the possibility of false positives, not all vulnerabilities are created equal. Some are more difficult to exploit than others. Similarly, the impact of a threat that does materialize can vary, affecting any combination of confidentiality, integrity and availability of systems (the CIA triad). Scoring schemes, such as the Common Vulnerability Scoring System (CVSS) or the Ubuntu CVE Priority, help standardize the evaluation of the results.

The most important aspect is to put any true positive vulnerability into perspective, within the wider context of the target deployment. This is where it is important to  classify the target assets. It may be the case that an existing compensating security control greatly diminishes exploitability, or that a vulnerability may simply not be applicable to your particular configuration. The bottom line is that interpretation must be performed by taking into account the characteristics of the affected system and prioritizing resolution within this personalized environment.

Next steps

You’ve identified the targets and the right scanner, completed the scan, interpreted the results and you now have a refined report with prioritized issues in front of you – the vulnerability assessment is now officially concluded. However, security operations do not end here: the wider vulnerability management process is a continuous cycle. A common adage in risk management is that risks can be reduced (mitigated), avoided, transferred or accepted – but should never be ignored. With vulnerabilities being a source of increased risk, addressing them ensures that good security hygiene is maintained.

For known software product vulnerabilities, security updates are the best course of action, which is why we recommend timely patching. Hardware vulnerabilities can generally be mitigated through firmware or microcode updates from the vendor. Misconfigurations need to be understood and corrected directly. The prioritization performed in the previous step ensures that a logical order is followed.

One thing to keep in mind is that vulnerabilities are a fact of life and their eventual discovery in a product is something to be expected, making preparations critical. These take the form of both mature security processes, as well as a defence-in-depth approach whereby not-yet-discovered vulnerabilities are mitigated through security features, such as application confinement.

How Ubuntu helps

At Canonical, we’re committed to ensuring that users of Ubuntu have the right tools at their disposal to conduct thorough and effective vulnerability assessments. Ubuntu takes a three-pronged approach to improving the security posture of any deployment:

• Transparency and visibility – open source facilitates an open policy that puts all the information necessary for users to make informed choices in the public domain. The Ubuntu Security Team’s processes are described in documentation available to all. Similarly, Canonical publishes data feeds for all known vulnerabilities affecting Ubuntu packages in open standard formats (OVAL, OSV and VEX). This is particularly useful for learning the Ubuntu-specific package versions that fix vulnerabilities through backported patches, as mentioned earlier. Indeed, scanners often make use of these data feeds in order to produce accurate results.
• Reactive – security updates are provided for software packages, with up to 12 years of Long Term Support with Ubuntu Pro (available for free on 5 devices). Notifications, in the form of Ubuntu Security Notices, provide information on available fixes. Standard installations enable unattended upgrades by default, ensuring timely automatic rollout of the patches.
• Proactive – a multitude of security features offer mitigations and are available on default installations. New ones are added on a regular basis, as advancements take place. As an example, AppArmor is an application confinement technology that fulfils a Mandatory Access Control (MAC) function at the Linux kernel level and can greatly reduce the blast radius of an attack, not unlike SELinux.

Ubuntu Security Research Alliance Program

Towards the end of 2024, Canonical announced the introduction of the Ubuntu Security Research Alliance Program. The initiative is designed to help ensure that the vulnerability scanners mentioned in this article provide as few false positives or false negatives as possible, in addition to accurate remediation advice. This free partnership with scanning vendors will assist Ubuntu users in staying one step ahead of threat actors. You can learn more about the Ubuntu Security Research Alliance Program in our announcement. We’re excited to work with industry partners to make the open source landscape a more secure place for all our users.

Further reading

• Get open source security from Canonical
• What is vulnerability management?