Runtime threat modeling for attack prediction and defense

In today’s increasingly interconnected and fast-paced digital ecosystem, mobile networks are critical national infrastructures. They span sectors such as healthcare, energy, transport, manufacturing, and public safety. Ensuring 5G and – in the future – 6G security is paramount to safeguard both individual users and the industries that depend on these networks. An essential condition for maintaining and improving the security posture of a system is the ability to effectively, yet proactively, measure and monitor its security state.

Threat modeling is a defense mechanism that involves proactive identification and assessment of potential security threats. It provides robust system security, allows organizations to prioritize their security efforts effectively, and helps mitigate risks before they can be exploited.

The drawback is that threat modeling is typically performed during the architecture or design phase and usually remains static once the system goes live. It is not updated with runtime telemetry or configuration changes on a regular basis, which may leave blind spots as the environment and threat landscape evolve.

Threat observability complements threat modeling by continuously monitoring systems in production to surface early indicators of attack. Threat observability fuses telemetry across layers and applies analytics to predict precursors before the attack advances. We define observability as going beyond logs and dashboards to a continuous, proactive understanding of risk and its intent.

Based on our research on threat observability, we are introducing the concept of runtime threat modeling.

Runtime threat modeling

This type of modeling continuously updates the design-time threat model with live telemetry, configuration states, and asset or context changes, so it reflects how the system operates, and not how we assume it would. In today’s network, this model security is essential since modern environments such as 5G or cloud native drift rapidly: controls change, vendors update, workloads move, and attackers adapt. By predicting posture drift, validating countermeasures, and re-prioritizing risks in near real time, runtime threat modeling enables timely, high-impact mitigation and safer automation.

Runtime threat modeling transforms security from guesswork to evidence-driven operation. It exposes the live posture, allows risk-based decisions, and powers automation. By converting observations into threat scores, we can prioritize what matters most, continuously evaluate and tune security controls, and trigger targeted detections on demand. Those capabilities lay the groundwork for intent-based management. This automation also frees security experts to focus on higher-value analysis while adapting and optimizing defense in real time, delivering strong security with greater operational efficiency.

By designing a measurement system for securing 5G and future networks, we introduce a state machine model to capture the security life cycle of network functions and the transitions between different states within the life cycle. Such a model can calculate security risk locally at each node, or hierarchically, by aggregating measurements into security domains or the entire network.

We identify three essential security metrics: attack surface exposure, impact of system vulnerabilities, and the effectiveness of applied controls that collectively form the basis for evaluating the overall threat level score.

Extending security observability with objective, automated, and dynamic metrics provides insights for shaping risk management and for informed decision-making strategies in 5G and 6G. These strategies will lay the foundation for the threat management of 6G networks.

How do we achieve enhanced security observability in practice?

Due to the massive number of connected devices and the evolving threat landscape, the runtime security state of a network function in radio access network (RAN) is unclear and prone to rapid deviation from the original security requirements and policies that are set in the network to protect it.. Communications service providers (CSPs) have limited end-to-end visibility across diverse entry points, such as compromised user equipment (UEs), rogue small cells, and fronthaul and backhaul links. CSPs cannot point out how controls are configured on different network components, such as distributed units (DU), centralized units (CU), and next-generation Node B (gNB). The configuration parameter space is relatively large, and some are vendor-specific, which means that manual checks will inflate operating expense (opex) yet remain unreliable. Point-in-time audits do not guarantee the same output every time.

Enabling stronger security measures can tax central processing units (CPUs) and slow down throughput and latency, while aggressive performance optimization can weaken detection fidelity and increase risk. So, without live, standardized telemetry, and configuration attestation, operators are essentially flying blind on security, unable to guarantee that yesterday’s security state still exists today.

Can you defend what you cannot see?

As illustrated in Figure 1, raw data or event monitoring is first unified and enriched with context such as topology, assets, slices, and policies. A machine reasoning engine then converts these observations into threat observability, which is an early, explainable hypothesis about precursors and posture drift.

From this, two outputs are generated: the first feeds into proactive control recommendations, such as strengthening of policies, while the second feeds into observation-driven threat detections, such as rogue node suspicion with confidence and impact estimates. The next step is to execute and validate actions, then have their effects fed back into the observation layer to refine models and policies.

Diagram 1 (left): Circular flow with three black icons – gauge at top labeled “Detection (reactive),” shield on left labeled “Data and event monitoring,” and strategy symbol on right labeled “Recommendation and mitigation.” Blue arrows connect them around a central antenna icon. Below: four descriptive bullet points – “Limited visibility,” “Delayed detection,” “Static rule sets,” “Manual investigation.” Diagram 2 (right): Circular flow with four black icons – gauge at top labeled “Threat observability (continuous and proactive),” shield on left labeled “Data and event monitoring,” gauge at bottom labeled “Threat detection (observation driven),” and strategy symbol on right labeled “Recommendation and mitigation.” Blue arrows form the loop, plus purple dashed arrows between top and bottom gauges. Below: four descriptive bullet points: “Early indicators observed,” “Real-time threat hunting,” “Learning new threats,” “Auto rule generation.”.

Figure 1: Positioning threat observability within the RAN security stack.

How does quantified observability reduce risk and cost?

Observe to automate

Observability enables automation by turning raw signals into a measurable and trustworthy state. With live, explainable metrics, operators can make risk-aware adjustments, whether to tighten or relax controls to match current exposure and balance the cost of protection against risk reduction without sacrificing performance.

Risk-based decision making

The clarity provided by observability also exposes the performance, such as security trade-offs in real time, so actions are deliberate, reversible, and accountable. Ultimately, observability is the backbone for intelligent control by closing the loop for security operations and intent-based management, where policies are automatically suggested, enacted, and validated.

Prioritization of actions and decisions

With real observability, prioritization becomes evidence-driven, where live telemetry and context create a dynamic risk score that ranks actions by expected risk reduction per unit cost/latency impact.

Our approach: automated runtime threat modelling

The fundamental principle of threat modelling is that security resources are limited, so they must be used effectively. However, changes in the environment can alter the attack surface during the design phase. This may invalidate initial assumptions about the to-be-implemented countermeasures, which require a continuous and adaptive threat modeling process.

Figure 2 presents a high-level view of the proposed runtime threat-modeling solution.  Each network function (NF) continuously collects telemetry from RAN nodes. The solution extracts attack indicators and feeds them into a machine reasoning engine backed by a knowledge base, which compiles attack definitions, tactics or techniques, and detection rules. The reasoner applies both deductive and abduction reasoning to compute a time-varying score to prioritize threats and apply mitigations. It also continuously updates the recommended security controls to address identified risks. All of this results in the knowledge base eventually being enriched with the new extracted threat insights.

A diagram on a white background showing a blue dashed circle on the left and a purple box on the right. The circle contains an antenna icon at the center, with arrows pointing to three labels: “Configuration actuation,” “SOC + NOC” with a monitor icon, and “Indicator of attack events.” An arrow leads to the purple box labeled “Reasoning engine,” which contains a triangle icon titled “Reasoner and Knowledge base” and four surrounding items: “Events analysis,” “Controls analysis and proposal,” “Probabilistic threat prediction,” and “Threat score measurement.” At the bottom right, three horizontal bars show metrics: “Attack surface exposure” (blue), “Threat vectors impact” (gray), and “Control effectiveness” (purple).

Figure 2: High-level overview of the reasoning engine.

Can numbers alone tell the threat story, or do we need relations too?

The reasoning engine operates as a continuous loop: new data constantly updates a model that reasons over possible threat scenarios, assesses risk, and produces actionable recommendations. It combines machine reasoning (MR) – relations and logical inference – with the statistical models and numerical methods of machine learning (ML) to draw both structural and empirical insights. Both are anchored by a knowledge base using a graph representation of the environment, such as topology, configurations, events, and threats. The graph representation enables the engine to iteratively refine its conclusions as fresh observations arrive, while being able to extract different measurements.

A diagram titled “Knowledge-driven reasoning” shows a network of connected nodes arranged in three columns. On the left, three circles labeled E₁, E₂, E₃ connect to two blue squares labeled AS₁ and AS₂. These link to three green squares labeled TV₁, TV₂, TV₃, which then connect to three purple squares labeled SC₁, SC₂, SC₃. Above the columns are labels: “P(AS|E),” “P(TV|AS),” and “P(SC|TV).” At the top, a dashed arrow spans “Machine learning” to “Machine reasoning.” On the far left, icons of stacked mobile devices labeled “RAN nodes.” On the right, three horizontal bars represent metrics: “Attack surface exposure” (blue), “Threat vectors impact” (green), and “Control effectiveness” (purple).

Figure 3: Combining machine learning with machine reasoning for knowledge-driven reasoning.

Figure 3 illustrates the engine’s workflow:

From observed events (E), an ML model derives per-event attack surface profiles (AS).

Then, a machine reasoning layer, such as probabilistic inference, computes, for each attack surface profile, the impact of the candidate threat vector (TV) and the effectiveness of available security controls (SC):

1. Attack surface profiles:
   The attack surface profiles are time-stamped, machine-readable snapshots of what is currently exposed, built from change-driven observations. From these signals, the system maps assets, interfaces, trust boundaries, and control states, and clusters them into exposure events that pinpoint where to analyze first. The resulting profile seeds threat enumeration and risk scoring.
2. Attackers’ probable actions executed on the attack surface:
   Given a current attack surface profile, the engine infers the attacker’s most probable next actions as a ranked set of threat vectors, each with an explicit uncertainty score. Because observations are partial and noisy, we treat vector presence as a probability distribution: priors that come from the knowledge base are then updated with live evidence to compute posteriors. Vectors whose preconditions are satisfied by the observed exposure receive a higher likelihood than those lacking prerequisites.
3. Identify suitable security controls and configurations to mitigate attacks:
   To identify suitable security controls and their configurations, the reasoner maps all of the most likely attacker actions to a respective control catalog. For each candidate, it estimates expected risk-reduction versus key performance indicator (KPI) cost and chooses the configuration that maximizes utility under current conditions. Uncertainty is explicit: control efficacy and performance impact carry confidence intervals based on priors and live evidence. When confidence is low, the engine recommends conservative defaults, staged rollouts, and tight observability checks.

The engine generates the most probable attack surface profile, corresponding threat vector impact, and their estimated control effectiveness. This process also involves continuously updating the knowledge base with new indicators, inferring threat probabilities by reasoning over the symbolic model, evaluating and scoring the current security posture using those probabilities alongside existing controls, and proposing controls and action plans to reduce exposure and mitigate risks.

Automation: are we close enough?

The autonomic loop reference architecture, defined as MAPE-K, anchors the proposed runtime threat modeling architecture (see Figure 4) by closing the automation and the loop. All components, such as knowledge, monitor, analyze, plan, and execute are orchestrated by a shared knowledge base to enable continuous and risk-aware automation. These components perform the following actions:

1. Knowledge: continuously updates the knowledge base, such as threat definition, topology, configuration, and trail termination points (TTPs).
2. Monitor: collects and processes RAN/NFs telemetries and configuration drifts.
3. Analyze: performs data analysis, condition matching, and threat analysis/inference through machine learning and reasoning to compute the probabilities and impacts.
4. Plan: turns these insights into threat-level measurements and concrete control recommendations.
5. Execute: applies the controls through NF hooks, validates the risk effects such as threat level measurements and KPI, and feeds the results back into the knowledge base, closing the loop.

Two connected diagrams on a white background. The left diagram is a five-point loop with colored circles labeled: “Data processing,” “Events analysis,” “Threat inference,” “Controls evaluation,” and “Threat level measurement,” surrounding a central “Knowledge base” icon. The right diagram is a four-point loop with circles labeled: “Monitor,” “Analysis,” “Planning,” and “Execution,” also around a “Knowledge base” icon. A purple arrow between them reads “Mapping to MAPE-K loop phases.” Both loops use colored arrows to show flow.

Figure 4: Closed-loop view: Mapping the solution to the MAPE-K loop.

Use case example: ensuring radio robustness through runtime threat modelling

The air interface is the first reference point to allow communication and connectivity between the user equipment and the network. It is a critical attack surface in RAN nodes as it is widely exposed to any UE or a mobile communication-capable device, making it subject to continuous possible threats. Ensuring a robust air interface is crucial, because no availability means denied access to services and the network.

In our use case, the objective is to ensure that the RAN NFs are proactively configured with suitable configurations and controls, to prevent possible threats and to ensure robustness. Robustness characterizes the relative strength of mechanisms that provide security services. Setting a target value for robustness allows the system to continuously monitor its environment—specifically, the threat environment—and evaluate how effective security controls are. Continuously assuring robustness enables a proactively secure system that allows easier adaptation of the security controls to meet threat environment changes.

Robustness has an inverse proportional relationship to threat, that is, if robustness level is low the threat level will be high.

Fig 5: Robustness level vs. threat level

The use case discussed in this blogpost is related to the Radio Resource Control (RRC) signaling storm. This type of attack occurs when a large volume of signaling messages is generated either due to a misbehaving UE or coordinated attacks, causing congestion and degraded performance in the RAN.

The objective is not to detect if there is an attack, but rather to determine which threat vectors are most likely to cause changes in the environment. This eventually results in proactively identifying the observed potential attack indicators, allowing network operators to prepare the existing controls with a suitable configuration to mitigate the threat.

Different types of events can occur on an RAN NF that can introduce changes to the air interface attack surface and require identifying the potential threats and procedures an attacker can leverage. These include some of the following:

• new UE connected to the cell
• new cell added to the NF
• new connections to neighboring cells
• new connections to the core network

Those events can be triggered due to, for example, configuration changes, and others could be triggered in performance management (PM) data. Each triggered event has a set of information required to evaluate the impact of the change of attack surface, and which threat vectors shall apply.

As illustrated in Figure 6, the threat reasoning engine can eventually provide a set of recommended configuration updates that should be used in suitable controls, such as modifying configurations related to admission control.

A diagram on a white background showing three mobile device icons on the left, each with arrows labeled MSG3, MSG4, and MSG5 pointing toward a central antenna icon. From there, a purple arrow labeled “Data collected” leads to a rectangular box titled “Reasoning engine.” Inside the box, a purple triangle labeled “Reasoner and knowledge base” is surrounded by four items: “Events analysis,” “Controls analysis and proposal,” “Probabilistic threat prediction,” and “Threat score measurement,” each with small icons and blue arrows pointing inward.

Figure 6: Identifying potential threat indicators for RRC signaling storms

What happens in the reasoning engine:

• Events analysis: Triggering events (PM Counters, PM events) and CM (relevant radio control config).
• Probabilistic threat prediction: Probable threat vectors causing events to be triggered.
• Controls analysis and proposal: Configure adm control with parameter, OldRrcThrsh= 500 msg3/sec, NewRrcThrsh= 200 msg3/sec.
• Threat score measurement: Calculating attack surface exposure, threat vector impact, security control effectiveness

Conclusion

Observability capabilities in mobile networks should be extended beyond the current known monitoring and configuration events to include more runtime capabilities.

The runtime observability capabilities should provide insights and situation awareness of the environment and the security state. The security state observability capabilities are dynamic and provide a time-series view on how the state deviates with changes occurring in the network. Additionally, a quantified security observable enables risk-based decision-making based on the security state score. Moreover, it provides the opportunity to enhance security operations and management.

In our research, we developed the concept of Runtime threat modeling, where we focused on use cases in the RAN domain. This approach turns security from guesswork into evidence-driven operations. It exposes the live posture, enables risk-based decisions, and powers automation. By converting observations into threat scores, we can prioritize what matters most, continuously evaluate and tune security controls, and trigger targeted detections on demand.

Read more

Delve more into the security evolution and threat modeling mechanisms for the current network environment:

Learn more about cyber defense and related research

• See how unifying threat modeling and hunting helps in proactive cyber defense
• Discover Zero Trust Architecture enabled by 3GPP security
• Learn about Safeguarding telecom networks against advanced threats with Ericsson’s cyber defense solutions
• Explore Ericsson’s approach for Securing networks against sophisticated threats
• Read more about telecom security for a connected world
• Learn how machine reasoning can analyze and translate knowledge data into clear insights