Filling the Gap in Risk Management: Probabilistic Threat Modeling
Construct Markov Chains for enhanced risk analysis and incorporate predictions to better anticipate and mitigate potential threats.
Enjoyed this post? Explore more in my E-book "Geopolitical Cyber Risk Analysis Handbook"! - predictivedefense.io
Introduction
Threat modeling is a method used to identify potential threats specific to a software's functionality during its design phase. By addressing these threats early, the software can be designed securely from the beginning, reducing the risk of overlooking security issues and aiming to launch with minimal vulnerabilities. Frameworks like STRIDE and OWASP Top 10 are often used in threat modeling.
However, this article isn't about those specific frameworks. While threat modeling is commonly linked to software development, its scope is much broader and can be applied to almost any area of cybersecurity. In this article, we'll explore how threat modeling, particularly probabilistic threat modeling, can complement risk management practices.
Probabilistic threat models can help clarify the "Likelihood" parameter, which often remains uncertain in risk analysis. Unfortunately, because threat models are often used in a superficial and qualitative way within risk management, this potential is not fully realized. In this article, we'll develop probabilistic models that allow us to directly calculate how anticipated changes within a company (such as hiring) might impact cyber risk.
The Unknown in the Risk Equation: Likelihood
In risk analysis, there's a commonly used equation: Risk = Impact x Likelihood. This equation helps compare different types of risks with each other. For instance, you can compare the risk of a DDOS attack with the risk of an SQL injection attack to determine where to invest more in protection. Although this equation seems simple in theory, it's more complex in practice. Some impacts are easier to quantify than others. For example, you can estimate the number of new customers lost and the financial cost to the company if a site goes down for X minutes due to a DDOS attack. However, calculating the impact of a personal data leak from an SQL injection isn't as straightforward.
Many companies address this by assigning categorical values (High, Medium, Low) to Impact. Fortunately, the industry is evolving. With the help of frameworks like FAIR and annual reports from organizations like the Cyentia Institute's IRIS and IBM's Cost of Data Breach, we can now use industry benchmarks to quantify Impact. This shift allows us to move beyond categorical values and perform risk calculations with greater accuracy.
The situation with the Likelihood parameter is even more challenging. Unfortunately, there are no industry benchmarks available to quantify the likelihood of an event, and it's unlikely that such benchmarks will be developed anytime soon. While efforts like EPSS try to address this issue within a narrow scope, they don't provide results that can be directly used in risk analysis. As a result, companies traditionally assign categorical values to likelihood. However, in this article, we'll explore how to assign probabilistic values to the Likelihood parameter, moving beyond the limitations of categorical values.
Introducing Markov Chain
Every event in life often depends on what happened just before it. For example, before you can enter your house, you need to unlock the door. But to unlock the door, you first need to find your key. Each of these steps is connected, and the chances of moving from one step to the next are based on probabilities. For instance, even if you find your key, there's no guarantee you’ll be able to unlock the door—maybe the lock is broken, or the key could get stuck. Similarly, you might not find the key at all; perhaps you left it in the car or misplaced it. This chain of events, where each step depends on the one before it, can be modeled using something called a Markov chain.
When you think about it, a cyber incident is really just a series of steps executed in sequence. We even have models like the Cyber Kill Chain that describe this exact process. However, these models often lack the probabilities needed to complete the Markov chain. In this section, we’ll explore how to easily assign these probabilities based on the information we have and build our own probabilistic models.
To make this clearer, imagine a company with the following scenario: It’s a typical software development firm that hosts its software in the cloud. The development environment is straightforward, including CI/CD elements. The company’s workforce is as follows:
1 DevOps engineer
8 Developers
2 IT engineers
89 Non-IT employees
In our scenario, the asset we want to protect is the "source code." Now, let's assume that the likelihood of a "compromised identity" has occurred. Regardless of the method used—whether phishing, brute force, or an info-stealer—a compromised identity could belong to one of the following groups, with the following probabilities:
89% chance it’s a Non-IT employee
2% chance it’s an IT engineer
8% chance it’s a Developer
1% chance it’s a DevOps engineer
Based on the diagram, there appear to be three possible ways for an attacker with a compromised identity to access the source code:
If they’ve compromised a Developer’s identity, they can directly access the source code.
If they’ve compromised a DevOps engineer’s identity, they can access the deployment environment to steal the source code.
If they’ve compromised an IT engineer’s identity, they can remotely access the Developer’s computer to steal the source code.
Now, let's begin by adding these probabilities to our model.
Now that we know one of the key steps to stealing the source code is compromising an identity, let's look at the possible methods for achieving this. Here are a few scenarios that come to mind:
Brute-forcing a Username and Password
Employee Credentials Being Sold on the Dark Web
A Spear Phishing Attack Targeting Employees
Malware Infection While Employees Browse the Internet
Let's break down the controls in place for each scenario and the relevant information we have. (Note: The figures below are hypothetical.)
1. Brute-forcing a Username and Password
Control: We have a lockout policy that triggers after three failed login attempts.
Likelihood: 0% (due to the lockout policy)
2. Employee Credentials Sold on the Dark Web
Control: Over the past year, our identity intelligence service detected that 15 employees had their credentials sold on the dark web.
Additional Info: 60% of our employees have MFA enabled on their corporate accounts, so even if credentials are compromised, access cannot be gained without MFA.
3. Spear Phishing Attack
Control: Our email security gateway blocked 1,700 phishing emails last year.
Additional Info:
Employees manually reported 21 phishing emails that slipped through the gateway.
Based on previous phishing simulations, we know that employees report about 3% of suspicious emails. This suggests there were roughly 700 phishing emails that bypassed the gateway, giving it a detection rate of 70%.
On average, our employees click on phishing emails 13% of the time, according to past simulations.
Additionally, 60% of employees have MFA enabled on their accounts, so compromised credentials alone won’t grant access.
4. Malware Infection Through Malvertising
Control: Based on insights from purple team simulations and post-mortem analyses, we estimate our EDR (Endpoint Detection and Response) system has an 85% success rate in detecting malware.
Additional Info: Last year, our EDR blocked 130 infections. Given the detection success rate, we estimate the total number of infections was likely around 150.
These insights provide a clearer understanding of the controls and probabilities for each scenario, helping us further refine our threat model.
As you can see, by analyzing data like the number of blocked malware and phishing attempts, the number of leaked credentials detected by our intelligence services, the success and click-through rates observed in simulations, and the False Negative rates of our security products, we've been able to calculate the success probability of each attack vector as a percentage.
Brute-forcing a Username and Password: 0% success probability
Credentials Sold on the Dark Web: 40% (proportion of accounts without MFA)
Spear Phishing Attack: 30% (False Negative rate of our email security gateway) * 13% (phishing click-through rate) * 40% (proportion of accounts without MFA) = 1.5% success probability
Malware Infection via Malvertising: 15% success probability
Next, we can apply these probabilities to the proportion of employees who have access to the source code, allowing us to calculate the overall success probability of each attack vector in achieving the goal of stealing the source code.
Buying Credentials on the Dark Web -> Stealing Source Code: 40% * 11% (proportion of employees with access to the source code) = 4.4% success probability
Spear Phishing -> Stealing Source Code: 1.5% * 11% = 0.17% success probability
Malvertising -> Stealing Source Code: 15% * 11% = 1.6% success probability
If these calculations seem complex or lengthy, the following graphic will help clarify things. Notice how the attack chains are modeled as a Markov chain.
Calculating Likelihood from Probabilities
In the model we developed, we calculated the success rates of different attack vectors as probabilities. But how do we determine the likelihood, which is crucial for our risk analysis? To do this, we simply multiply these success probabilities by the frequency with which each attack occurs over a specific period. Let's continue with our example of source code theft and calculate the likelihood of this event occurring through each attack vector over a one-year period.
Likelihood of a Credential Leak on the Dark Web Leading to Source Code Theft:
Calculation: Probability of success * Number of occurrences in a year
Result: 4.4% * 15 = 66%
Likelihood of Spear Phishing Leading to Source Code Theft:
Calculation: 0.17% * 2,400 = 4.7%
Likelihood of Malvertising Leading to Source Code Theft:
Calculation: 1.6% * 150 = 240%
With these likelihoods calculated, we can now multiply them by the Impact value to complete our risk analysis. For instance, if the impact of source code theft is estimated at $1,000,000, then our annual risk exposure would amount to $3,170,000.
One important observation is that, while the credential leak on the dark web initially appeared to have the highest probability of success, when we account for the frequency of events, malvertising turns out to have the highest likelihood. According to these calculations, our source code is exposed to the risk of theft from malvertising about 2.4 times per year.
This doesn’t mean our source code will be stolen every year—malvertising attacks often aim at simpler targets, like Bitcoin mining. However, a probabilistic threat model is an effective tool for understanding the factors that increase or decrease our risk exposure.
Getting Predictive Value from your Threat Model
Probabilistic threat models are incredibly useful for risk analysis, evaluating investment decisions, and comparing the effectiveness of different security controls. For instance, look at the graph below and imagine you're about to implement a new security control. Consider the various controls that come to mind and estimate how much each one could reduce risk exposure. Which controls have the most significant impact? And how much should one invest in the most effective one? As you can see, once you have a model like this in place, making these kinds of assessments becomes much easier.
But their value doesn’t stop there—they can also help forecast future risks by incorporating predictions. Let’s consider a few scenarios:
Your company plans to expand the software team next year, increasing the number of developers to 20.
A major news event (like M-pox) leads you to believe attackers might launch more phishing attacks.
Your early warning system detects a 40% increase in activity from malware families that have affected your company before.
Each of these scenarios offers predictions with different levels of certainty. With probabilistic models in place, you can easily calculate the risks if these predictions come true.
Increasing the Software Team to 20 People: This would increase the percentage of employees with access to the source code from 11% to 20%. As a result, the likelihood of success for all identity-compromise-based attacks—and the associated risk exposure—would double, bringing the total risk exposure to $6.34 million.
Anticipating an Increase in Phishing Attacks: We can estimate how much phishing attacks might increase by looking at similar past events (like the early days of COVID). Suppose we assume a 20% rise in phishing attacks. This would impact only one attack vector, increasing its likelihood of success from 4.7% to 5.64%, leading to a mere $9,400 increase in risk exposure.
Surge in Malware Activity: A 40% increase in malware activity would mostly affect one attack vector. The likelihood of a successful malvertising attack would rise from 240% to 336%, temporarily increasing the total risk exposure by $960,000.
These examples show how probabilistic threat modeling can effectively assess the impact of company changes, respond to early warning signals, and make informed decisions based on future predictions.
Conclusion
Probabilistic threat modeling is a powerful tool that goes beyond traditional risk analysis. It allows organizations to not only assess current risks and the effectiveness of security controls but also to anticipate and prepare for future threats. By incorporating predictions—whether they stem from internal changes, emerging trends, or early warning signals—companies can make more informed decisions and better allocate resources to mitigate potential risks. As demonstrated, understanding how different factors influence risk exposure enables organizations to stay ahead of threats and protect their critical assets more effectively.
If you found this work insightful, consider supporting my efforts by purchasing a copy of my book, Geopolitical Cyber Threat Intelligence. I hope you'll like that as well!
Thank you for reading so far!