The terms threat, vulnerability and weakness are often used in cybersecurity. Understanding the difference between these terms is important. It allows organizations to correctly implement, document and assess their cybersecurity activities and controls. Here, we take a closer look at vulnerabilities.

Defining a vulnerability

The United Nations, defines a vulnerability as

“…the inability to resist a hazard or to respond when a disaster has occurred”.

United Nations

This is a very general definition and is not restricted to cybersecurity. We can see it as a property of an asset that makes it susceptible to damage. This property can be inherent in the design. It can also be a result of tradeoffs that have to be made, or it can be the result of actual design mistakes.

Let us look at the more specific case of (cyber)security vulnerabilities. There are several different, but often similar, definitions in the literature. We look at a few examples from well-known sources.

In RFC 4949, IETF defines a vulnerability as

A flaw or weakness in a system’s design, implementation, or operation and management that could be exploited to violate the system’s security policy.

RFC 4949

NIST uses the definition

Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.


The Common Criteria defines it as

Weakness in the TOE [Target Of Evaluation] that can be used to violate the SFRs [Security Functional Requirements] in some environment.

Common Criteria

TOE is the Common Criteria’s word for an IT product. An SFR is a standardized formulation of a security objective. More definitions from other sources can be found in this Wikipedia article.

Categorizing Vulnerabilities

Looking at the definitions above, a vulnerability can be seen as a specific instance of a weakness. These can be found in either software, hardware, a network or inside an organization. This lets us divide the vulnerabilities into four main categories. Some examples that can be present in these categories could be:

  • Software vulnerability: This could be unvalidated input allowing an attacker to overflow a buffer. This can cause the program to execute arbitrary code. This is a classic buffer overflow attack, which exists in several different variants.
  • Hardware vulnerability: High density DRAM cells causes electromagnetic interactions between nearby memory cells. If we write to one memory row, we can affect the memory cells in nearby rows. Through this, an attacker can overwrite parts of the memory, even if he should have no access to it. This vulnerability is known as rowhammer and has been shown to affect primarily DDR3 and DDR4 SDRAM modules.
  • Network vulnerability: An insecure wireless access point would constitute a vulnerability in the computer network. No encryption or using WEP are examples of this.
  • Organization vulnerability: Lack of security awareness among employees can leave the organization susceptible to attackers. Sending emails with malicious attachments is one typical attack. It also increases the chances of personnel inserting untrusted USB sticks into otherwise secured computers.

Technical tools that detect and react to attacks can help keeping up with the ever expanding security landscape. Still, the examples above show that vulnerabilities can not be mitigated with only technical tools. They are not restricted to the actual computer system. Security training and increased awareness among personnel is also needed.

Vulnerability sources

Many vulnerabilities are tracked, enumerated and identified through the Common Vulnerabilities and Exposures (CVE). CVE is a list of vulnerabilities with an identifier, a description, and at least one reference. CVE identifiers are used, e.g., by the National Vulnerability Database (NVD). NVD provides more in-depth information for each security problem. CVE are commonly used for software security, but they also include security problems found in hardware. Not all problems are reported as a CVE entry. Security advisories provided by developers or vendors are other sources. Issues found in the product’s repository is yet another example.

Users and vendors can be made aware of new problems in several different ways.

  • Tools used by the development organization. Static and dynamic analysis of software can be used to analyze the program code. This can help find new vulnerabilities already in the design stage.
  • Penetration tests. Vendors and service providers often use external security experts in order to test the security of the service. Having a second or third pair of eyes looking at the security often help finding mistakes. Such pentests can often uncover security problems that are missed by developers.
  • Researchers. Academic research can help identify new problems. New results are frequently published and often vendors have time to respond to the discovered problems before results are published.
  • Bug bounty programs. In a bug-bounty program, service providers allow hackers to try to bypass their security controls. Anyone is allowed to try to hack the product or service. If successful, the problems are reported to the vendor and the attackers receive a reward. These programs are increasingly popular. They provide actual targets for security analysts in addition to the reward. This makes it more fun to attack it. Also, the vendors only have to pay for each security problem and bug that is found in their system. Though these rewards can be very high, in some cases thousands of dollars, it is still favorable for the vendor.
  • Zero-days and cyberattacks. Some security holes are identified due to the fact that they are exploited in the wild. This is the most severe form of vulnerability disclosure. The vendor has not been able to develop a patch before it is exploited. This leaves users at risk for attacks. Such issues with no patch are called zero-day vulnerabilities.

The impact of a vulnerability is given in terms of the CIA triad, namely confidentiality, integrity and availability. As an example, if only partial information can leak it is less severe than if there is total exposure. The severity is given as a CVSS score. This score is designed to be objective and reproducible. It includes impact, but also how easy it is to exploit it. If an attacker needs physical access to the device to attack it, then it is less severe than if it can be exploited over a network.

Vulnerability response

Developers respond to new vulnerabilities by releasing patches and software updates. Here, the vendor needs to make several decisions. Who will decide if the patch should have priority? Who will develop the patch? How will the security information be delivered to customers? Having clear methods for responding to new security issues will allow a more effective process. In the end, this will also result in a more secure product.

For end users, the most important safeguard against attacks is to keep programs and operating systems up-to-date with the latest security patches. This is even more important in today’s world of digitalization where critical infrastructure being built using software intensive systems. It is becoming more and more common for software to support automatic updates. This minimizes the time when the software or device is exposed to cyber attacks.

Write A Comment