What is a security vulnerability?: Security vulnerability definition

Defining a security vulnerability 

The United Nations defines a vulnerability as 

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

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 trade-offs 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. 

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 NIST definition can be compared to the one used by ISO 27000. 

Weakness of an asset or control that can be exploited by one or more threats 

The main difference is that NIST uses “could be exploited” while ISO 27000 says that the weakness “can be exploited”. NIST is thus here a bit more liberal in the possibilities for exploitation. 

Categorizing security vulnerabilities 

Looking at the definitions above, a vulnerability can be seen as a specific instance of 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 keep 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 are also needed. 

Cyber security 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. 

New vulnerabilities 

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 helps find mistakes. Such pentests can often uncover security problems that are missed by developers. 

Researcher  

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. 

Existing vulnerabilities 

Finding new and previously unknown vulnerabilities is only one side of the story. Having un-patched vulnerabilites that are publically known could arguably be worse for an application. Such vulnerabilities would allow anyone to apply an existing exploit in order to attack a service or a system.

Software Composition Analysis tools, or SCA tools, are then often used to scan for known vulnerabilities in third-party and open-source components. Often, such scans reveal tens or hundreds of vulnerabilities indirect or transitive dependencies. A competent tool will also help you open pull requests that will remediate the vulnerabilities with just the click of a button.

Some prominent security vulnerabilities 

Throughout the years, there have been a number of important security vulnerabilities that have affected both the industry and how we look at cybersecurity in our society. This impact can be very different.  

High severity and widespread 

Heartbleed and Log4Shell were high severity vulnerabilities that affected a very large number of services and they were very easy to exploit. Together they are considered the most impactful vulnerabilities to date. 

• Heartbleed. This was a problem with the OpenSSL software. It allowed an attacker to send a request to a server, tricking it to send back data that was not really meant to be included. This data could include passwords, private keys, or other sensitive information.  
• Log4Shell. This vulnerability allowed anyone that could affect the logging data handled by the Log4j library to download and execute and arbitrary program. 

OpenSSL is widely used for providing secure HTTP connections and Log4j is widely used for logging events and errors in Java application. 

Fundamental problems 

The Meltdown and Spectre vulnerabilities showed fundamental design limitations in today’s processors. Their underlying problem is not easily fixed without accepting a rather significant performance hit. However, though proof-of-concepts exist they are difficult to exploit. Their fame is due to the huge impact on processor design and how conscious design decisions can turn into vulnerabilities, not to exploitation and risk to end users. 

Impactful exploitation 

On the other end of the scale, we have vulnerabilities that are most known for their actual exploitation, rather than the vulnerability itself. Examples of that include Stuxnet, the Equifax attack and the supply chain attacks on Solarwinds, Keseya and Codecov.  

For the supply chain attacks in particular, it is sometimes not only clear that a vulnerability was exploited. Access to the supplier can use, e.g., social engineering instead. Then malware can be added to the software which is then distributed to the consumers. For a more detailed overview of supply chain attacks, check out our Software Supply Chain Attacks series. 

Security 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 for 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 is 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.