Threats, Vulnerabilities, Exploits and Their Relationship to Risk

The tale of The Three Little Pigs can teach us more than you think about cybersecurity risk.
By Debbie Walkowski (additional contributions by Raymond PomponShahnawaz Backer)
February 22, 2021
10 min. read

If you read much about cyberattacks or data breaches, you’ve surely run across the terms vulnerabilities, threats, and exploits. Unfortunately, these terms are often left undefined, used incorrectly or, worse, interchangeably. That’s a problem, because misunderstanding these terms (and a few other key ones) can lead organizations to make incorrect security assumptions, focus on the wrong or irrelevant security issues, deploy unnecessary security controls, take needless actions (or fail to take necessary actions), and leave them either unprotected or with a false sense of security.

It’s important for security professionals to understand these terms explicitly and their relationship to risk. After all, the purpose of information security isn’t just to indiscriminately “protect stuff.” The high-level objective is to help the organization make informed decisions about managing risk to information, yes, but also to the business, its operations, and assets. There’s no point in protecting “stuff” if, in the end, the organization can’t sustain its operations because it failed to successfully manage risk.

What is Risk?

In the context of cybersecurity, risk is often expressed as an “equation”—Threats x Vulnerabilities = Risk—as if vulnerabilities were something you could multiply by threats to arrive at risk. This is a misleading and incomplete representation, as we’ll see shortly. To explain risk, we’ll define its basic components and draw some analogies from the well-known children’s tale of The Three Little Pigs.1

Wait! Don’t decide to bail just because you think a children’s tale is too juvenile to explain the complexities of information security. In the Infosec world where perfect analogies are hard to come by, The Three Little Pigs provides some pretty useful ones. Recall that the hungry Big Bad Wolf threatens to eat the three little pigs by blowing down their houses, the first one built of straw, the third one built of bricks. (We’ll ignore the second pig with his house built of sticks since he’s in pretty much the same boat as the first pig.)

Defining the Components of Risk

A discussion of vulnerabilities, threats, and exploits begs many questions, not the least of which is, what is being threatened? So, let’s start by defining assets.


An asset is anything of value to an organization. This includes not just systems, software, and data, but also people, infrastructure, facilities, equipment, intellectual property, technologies, and more. In Infosec, the focus is on information systems and the data they transact, share, and store. In the children’s tale, the houses are the pigs’ assets (and, arguably, the pigs themselves are assets since the wolf threatens to eat them).

Inventorying and assessing the value of each asset is a vital first step in risk management. This can be a monumental undertaking for many organizations, especially large ones. But it’s essential in order to accurately assess risk (how do you know what’s at risk if you don’t know what you have?) and then determine what type and level of protection each asset warrants.


A vulnerability is any weakness (known or unknown) in a system, process, or other entity that could lead to its security being compromised by a threat. In the children’s tale, the first pig’s straw house is inherently vulnerable to the wolf’s mighty breath whereas the third pig’s brick house is not.

In information security, vulnerabilities can exist almost anywhere, from hardware devices and infrastructure to operating systems, firmware, applications, modules, drivers, and application programming interfaces. Tens of thousands of software bugs are discovered every year. Details of these are posted on websites like and (and hopefully, the affected vendors’ websites) along with scores that attempt to assess their severity.23

Responsible vendors typically publish patches in a timely way to correct specific known vulnerabilities. However, that doesn’t guarantee that organizations using those vulnerable products will apply the patch. In fact, some of the highest profile attacks and data breaches have occurred in organizations that did not patch vulnerabilities that had been known about for years. (Zero-day refers to a newly discovered vulnerability for which a patch does not yet exist.)


A threat is any action (event, occurrence, circumstance) that could disrupt, harm, destroy, or otherwise adversely affect an information system (and thus, an organization’s business and operations). Viewed through the lens of the CIA triad, a threat is anything that could compromise confidentiality, integrity, or availability of systems or data. Except in cases of natural disaster such as flood or hurricane, threats are perpetrated by threat agents or threat actors ranging from inexperienced so-called script kiddies to notorious hacker groups like Anonymous and Cozy Bear (also known as APT29). Threats can be intentional or accidental and come from internal or external sources. In The Three Little Pigs, the wolf is the obvious threat actor; the threat is his stated intention to blow down the pigs’ houses and eat them.


Used as a verb, exploit means to take advantage of a vulnerability. Used as a noun, an exploit refers to a tool, typically in the form of source or binary code. This code makes it easy for threat actors to take advantage of a specific vulnerability and often gives them unauthorized access to something (a network, system, application, etc.). The payload, chosen by the threat actor and delivered via the exploit, carries out the chosen attack, such as downloading malware, escalating privileges, or exfiltrating data.

In the children’s tale, the analogies aren’t perfect, but the wolf’s mighty breath is the closest thing to an exploit tool and the payload is his destruction of the house. Afterward, he hoped to eat the pig—his “secondary” attack. (Note that many cyberattacks are multi-level attacks.)

Exploit code for many vulnerabilities is readily available publicly (on the open Internet on sites such as as well as on the dark web) to be purchased, shared, or used by attackers. (Organized attack groups and nations state actors write their own exploit code and keep it to themselves.) It’s important to note that exploit code does not exist for every known vulnerability. Attackers generally take the time to develop exploits for vulnerabilities in widely used products and those that have the greatest potential to result in a successful attack. So, although the term exploit code isn’t included in the Threats x Vulnerabilities = Risk “equation,” it’s an integral part of what makes a threat feasible.


For now, let’s refine our earlier, incomplete definition and say that risk constitutes a specific vulnerability matched to (not multiplied by) a specific threat. In the story, the pig’s vulnerable straw house matched to the wolf’s threat to blow it down constitutes risk. Similarly, the threat of SQL injection matched to a specific vulnerability found in, for example, a specific SonicWall product (and version) and detailed in CVE-2021-20016,4 constitutes risk. But to fully assess the level of risk, both likelihood and impact also must be considered (more on these two terms in the next section).

Before we go any further, there are two important points to understand:

  • If a vulnerability has no matching threat (no exploit code exists), there is no risk. Similarly, if a threat has no matching vulnerability, there is no risk. This is the case for the third pig, whose brick house is invulnerable to the wolf’s threat. If an organization patches the vulnerability described in CVE-2021-20016 in all of its affected systems, the risk no longer exists because that specific vulnerability has been eliminated.
  • The second and seemingly contradictory point is that the potential for risk always exists because (1) exploit code for known vulnerabilities could be developed at any time, and (2) new, previously unknown vulnerabilities will eventually be discovered, leading to possible new threats. As we learn late in The Three Little Pigs, the wolf discovers the chimney in the third pig’s brick house and decides to climb down to get to the pigs. Ah-ha! A new vulnerability matched to a new threat constitutes (new) risk. Attackers are always on the lookout for new vulnerabilities to exploit.

Accurately Assessing Risk

Without getting into a deep discussion of risk assessment,5 let’s define the two essential elements of risk calculations that are often overlooked.


Likelihood is the chance or probability that a specific threat will exploit a specific vulnerability. Factors that figure into likelihood include things like a threat actor’s motivation and capabilities, how easily a vulnerability can be exploited, how attractive a vulnerable target is, security controls in place that could hinder a successful attack, and more. If exploit code exists for a specific vulnerability, the attacker is skilled and highly motivated, and the vulnerable target system has few security controls in place, the likelihood of an attack is potentially high. When the opposite of any of these is true, likelihood decreases.

For the first pig, the likelihood of an attack was high because the wolf was hungry (motivated), had opportunity, and a reasonable exploit tool (his mighty breath). However, had the wolf known in advance about the pot of boiling water in the third pig’s fireplace—the “security control” that ultimately killed the wolf and saved the pigs—the likelihood of him climbing down the chimney would probably have been zero. The same is true of skilled, motivated attackers who, in the face of daunting security controls, may choose to move on to easier targets.

If…if…if. There are endless variations in motivation, capability, ease of exploit, security controls, and other factors that affect likelihood.


Impact describes the damage that could be done to the organization and its assets if a specific threat were to exploit a specific vulnerability. Of course, it’s impossible to accurately gauge impact without first determining asset value, as mentioned earlier. Obviously, some assets are more valuable to the business than others. Compare, for example, the impact of a company losing availability of an ecommerce website that generates 90 percent of its revenue to the impact of losing a seldom-used web app that generates minimal revenue. The first loss could put a faltering company out of business whereas the second loss could be negligible. It’s no different in our children’s tale where the impact was high for the first pig, who was left homeless after the wolf’s attack. Had his straw house been just a makeshift rain shelter that he rarely used, the impact would have been insignificant.

Putting the Risk Jigsaw Pieces Together

Assuming a matched vulnerability and threat exists, it’s essential to consider both likelihood and impact to determine the level of risk. A simple, qualitative (versus quantitative)6 risk matrix like the one shown in Figure 1 illustrates the relationship between the two. (Note that there are many variations of this matrix, some far more granular and detailed.)

Likelihood and impact form this simple qualitative risk assessment matrix.
Figure 1. Likelihood and impact form this simple qualitative risk assessment matrix.

Using our earlier example, yes, the loss of a company’s primary ecommerce website could have a significant impact on revenue, but what is the likelihood of that happening? If it’s low, the risk level is medium. Similarly, if an attack on a seldom-used, low-revenue-generating web app is highly likely, the level of risk is also medium. So, statements like, “If this machine gets hacked, all our data is owned!” or “Our password lengths are too short and that’s risky!” are incomplete and only marginally useful because neither one addresses both likelihood and impact.7


So, where do these definitions and explanations leave us? Hopefully with a better high-level understanding of risk and a more accurate grasp of its components and their relationship to one another. Given the number of new threats, vulnerabilities, and exploits exposed daily, understanding these terms is essential to avoid misunderstandings, miscommunication, and misguided focus. Security professionals need to be able to ask and answer the right questions, such as: are our systems and apps vulnerable? If so, which ones, and what are the specific vulnerabilities? Threats? What is the value of those systems and the data they hold? How should we prioritize protection of those systems? What would be the impact of an attack or a major data breach? What is the likelihood of a successful attack? Do we have effective security controls in place? If not, which ones do we need? What policies and procedures should we put in place or update? And so on, and so on, and so on.

You get the idea. The point is, information security is a complex discipline (with many sub-disciplines) and the stakes of failing at it can be very high. That’s why it’s so important for security professionals to understand these concepts so they can accurately assess risk.

For more information about security fundamentals, read What Is the CIA Triad?What Are Security Controls?, and What is the Principle of Least Privilege?, all from F5 Labs’ Learning Center.





4This CVE example was chosen at random and is not meant to reflect negatively on this vendor. Vulnerabilities are possible in virtually any vendor’s products.

5For a detailed explanation of risk assessment, see chapters 3, 4, and 5 of IT Security Risk Control Management: An Audit Preparation Plan; Ray Pompon; (Apress, 2016).

6Quantitative risk analysis is another method for analyzing risk that is based on monetary asset value, exposure factor, loss expectancy, and rate of occurrence. One is not “better” than the other and often, both are used.

7Examples from IT Security Risk Control Management: An Audit Preparation Plan; Ray Pompon; pg. 24; (Apress, 2016).

Join the Discussion
Authors & Contributors
Debbie Walkowski (Author)
Raymond Pompon (Contributor)
Shahnawaz Backer (Contributor)

More from Learning Center

Forward and Reverse Shells
Forward and Reverse Shells
09/15/2023 article 5 min. read
Web Shells: Understanding Attackers’ Tools and Techniques
Web Shells: Understanding Attackers’ Tools and Techniques
07/06/2023 article 6 min. read
What Is Zero Trust Architecture (ZTA)?
What Is Zero Trust Architecture (ZTA)?
07/05/2022 article 13 min. read