Most traditional security operations centres (SOCs) were built around IP-based enterprise infrastructure. Firewalls, endpoints, servers, identity systems, cloud logs and network traffic form the core of the detection stack.
That approach assumes suspicious activity will eventually surface through an IP connection, a managed device, an application log or another monitored part of the enterprise environment.
For a long time, that assumption covered much of the attack surface. It no longer covers all of it.
Wireless systems have always introduced risks that conventional monitoring may not see directly. Wi-Fi, Bluetooth, radio-frequency identification (RFID) and earlier cellular generations all created activity beyond the visibility of standard endpoint and network sensors.
Radio frequency (RF) does not stop at Wi-Fi.
5G has expanded the wireless attack surface across user equipment, radio access networks (RAN), virtualised core functions, edge infrastructure, service-based interfaces and machine-to-machine communications. 6G is likely to extend that dependence on distributed, software-defined and radio-connected infrastructure further still.
RAN activity, over-the-air signalling, rogue radio infrastructure, interference, handovers between devices and base stations, and manipulation of radio-layer protocols may never touch the sensors used by a traditional enterprise SOC.
Some of the resulting activity may eventually appear in an IP log or core-network event. The initial radio-layer activity may remain unobserved.
If your monitoring stack only watches enterprise networks, hosts and cloud infrastructure, an entire class of wireless threats may be invisible by design, not by accident.
This is not a minor blind spot. It is a structural visibility gap.
Where there is no SOC at all — which is common among smaller operators, private-network operators, MVNOs, suppliers and technology vendors — the gap does not disappear. It means a different process is needed to identify and prioritise the risk before an incident occurs.
Threat modelling without a SOC
Without a SOC, you are not necessarily detecting live attacks.
You are anticipating plausible attack paths, identifying what you could observe, exposing what you could not observe and deciding where controls should be strengthened.
That shifts the workflow from continuous detection towards structured prioritisation, but the underlying threat-modelling frameworks still provide a practical foundation.
Image 1: Threat modelling without a SOC. An IntSpired-style workflow combining the Diamond Model, MITRE FiGHT and ATT&CK, visibility-gap analysis, GSMA and ENISA guidance, baseline control mapping, and a prioritised risk register.
1. Diamond Model — frame the scenario
Before moving into technical detail, define the hypothetical event.
Who is the likely adversary? What infrastructure could they use? What capability would they need? Which device, service, network function, organisation or user would be the victim?
These four elements form the principal vertices of the Diamond Model:
- Adversary
- Infrastructure
- Capability
- Victim
The purpose is not to name a specific attacker without evidence. It is to create a structured scenario.
The adversary might be a financially motivated group, hostile operator, insider, criminal service provider or opportunistic attacker.
The infrastructure could include rogue radio equipment, rented cloud services, compromised network functions, malicious applications or attacker-controlled signalling infrastructure.
The capability might involve radio reconnaissance, identity manipulation, signalling abuse, denial of service, exploitation of a network function or unauthorised access to subscriber information.
The victim could be user equipment, a base station, private 5G deployment, core-network function, connected enterprise or the operator itself.
This is the scaffolding on which the rest of the analysis is built.
2. FiGHT and ATT&CK — enumerate the techniques
The capability vertex can then be expanded into specific adversary behaviours.
MITRE ATT&CK provides a structured knowledge base for tactics and techniques affecting enterprise, cloud and mobile environments.
MITRE FiGHT performs a similar role for 5G environments, covering techniques associated with user equipment, radio access, the core network, telecom services and supporting infrastructure.
The two should not be treated as competing frameworks. A realistic attack path may involve both.
An adversary might begin with activity against the radio or telecom environment and later use conventional enterprise techniques for credential access, persistence, lateral movement, command and control or data exfiltration.
The reverse is also possible. An attacker may first compromise an enterprise system, cloud service or management platform and then use that access to affect mobile-network infrastructure.
The technique-mapping stage should therefore ask:
- Which FiGHT techniques are relevant to the RAN, core and telecom environment?
- Which ATT&CK techniques become relevant once the attack reaches enterprise, cloud, identity or endpoint infrastructure?
- Where do the two sets of behaviours connect?
This produces a more complete technique list than using either framework in isolation.
3. The coverage gap — flag what you cannot see
This is the step many threat-modelling exercises skip.
Identifying a plausible technique does not mean the organisation can detect it.
Traditional SOC monitoring commonly provides visibility into:
- Firewalls
- Endpoints
- Servers
- Identity systems
- Applications
- Cloud logs
- IP and network traffic
- Managed network devices
Visibility into the wireless and radio domain may be far more limited. This can include:
- RF-spectrum activity
- Air-interface behaviour
- RAN signalling
- Over-the-air traffic
- Rogue or unauthorised radio infrastructure
- Device-to-tower handovers
- Radio interference and jamming
- Subscriber identity activity involving SIM or eSIM systems
- Manipulation of mobility or control-plane procedures
Some telecom operators have specialist RAN, signalling and network-assurance capabilities. Some private-network environments also collect detailed telemetry from radio and core components.
Many enterprise SOCs, however, have little or no direct visibility into those layers.
For every technique identified during the FiGHT and ATT&CK stage, the threat model should record one of three conditions:
Visible: the organisation has appropriate telemetry and can reasonably detect the activity.
Partially visible: some evidence may appear, but the initial activity or complete attack path cannot be observed.
Not visible: the organisation has no reliable source of telemetry for the technique.
This creates a visibility matrix, not merely a list of threats.
A control may exist while the telemetry required to confirm its effectiveness does not. That distinction matters.
4. GSMA FS.40 and ENISA — validate against known risk categories
Technique mapping should then be checked against broader telecom-security guidance.
GSMA FS.40 provides guidance on security considerations for 5G networks, while ENISA's work on the 5G threat landscape provides a wider view of threat actors, assets, vulnerabilities and attack scenarios affecting mobile infrastructure.
This cross-check helps prevent the threat model from becoming too narrow.
Working only from ATT&CK or FiGHT may produce a strong list of adversary techniques, but wider industry guidance can reveal categories that also need to be considered, including:
- Fraud and identity abuse
- Unauthorised access
- Supply-chain compromise
- Misconfiguration
- Signalling exploitation
- Eavesdropping and interception
- Privacy and data exposure
- Service disruption
- Physical compromise
- Third-party dependency
- Virtualisation and cloud-infrastructure risk
- Operational and management-plane weaknesses
The objective is not to copy every risk from every framework. It is to test whether the scenario has omitted an important category.
5. GSMA FS.31 — map to baseline controls
Once credible techniques and risks have been identified, they should be mapped against baseline security controls.
For each plausible attack path, ask:
Is there already a control intended to prevent it?
Is that control implemented across the relevant part of the architecture?
Can its effectiveness be verified?
Does the organisation have telemetry that would reveal failure or bypass?
Who owns the control? Is it operated internally, by a supplier or by a managed service provider?
This is where the exercise becomes an actual gap analysis.
A technique may be theoretically possible but already well controlled. Another may have a preventative control but no detection capability. A third may have neither.
The assessment should distinguish between:
- Control present and monitored
- Control present but not monitored
- Control partially implemented
- Control dependent on a third party
- No effective control
- Control status unknown
Unknown should not automatically be treated as secure. It should remain open until evidence is available.
6. Risk register — the output
Where there is no SOC converting the analysis into detection rules, alerts and response playbooks, the primary output is a prioritised risk register.
Each entry should contain enough information for leadership, engineering teams, suppliers or an MSSP to act on it, including:
- Scenario and affected assets
- Likely adversary
- Relevant techniques
- Existing controls
- Visibility status
- Potential impact
- Likelihood or plausibility
- Residual risk
- Recommended action
- Responsible owner
- Target completion date
The result is not simply a list of theoretical wireless attacks.
It is a structured record of which attack paths matter to the organisation, which controls already reduce the risk and which areas remain exposed or invisible.
Where security monitoring is outsourced, the same register can be translated into specific requirements for an MSSP.
Instead of asking an MSSP to "monitor 5G security", the organisation can define the events, data sources, network functions and behaviours that must be covered.
Threats do not stay in one lane
None of this is as clean as placing wired and wireless into separate boxes.
The Extended Diamond Model adds meta-features such as timestamp, phase, result, direction, methodology and resources because a real intrusion is rarely a single isolated event.
It is more often an activity thread.
That thread can move from reconnaissance through weaponisation, delivery, exploitation, installation, command and control, and actions on objectives. It may affect several systems or victims during the same campaign.
When multiple activity threads are connected, the result becomes an activity-attack graph rather than one standalone diamond.
Image 2: Threats do not stay in one lane. An IntSpired-style interpretation of how individual Diamond Model events can form activity threads and wider activity-attack graphs spanning the radio layer, telecom core, cloud infrastructure and enterprise environment.
The same principle applies to the distinction between wired and wireless infrastructure.
An attacker is unlikely to remain in one environment throughout an entire campaign.
A hypothetical attack might begin with RF reconnaissance against a radio site or device. It could continue through a malicious over-the-air interaction, exploitation of a modem or protocol weakness, compromise of a handset or subscriber identity, and access to data or services through the mobile core.
From there, the attacker may reach cloud infrastructure, management systems or enterprise networks.
The route can also move in the opposite direction.
An attacker might first compromise a cloud-hosted management service, supplier account, orchestration platform or enterprise administrator. That access could then be used to manipulate telecom services, network functions, subscriber systems or radio-connected devices.
The important point is not that every wireless event leads to a wired compromise.
It is that real attack chains can cross the boundary.
Treating wired and wireless as separate and absolute security categories misses how campaigns may progress in practice.
Wireless is not a separate security world. It is another layer of the same attack surface.
Why this matters
The Diamond Model, ATT&CK, FiGHT, GSMA guidance and ENISA threat analysis can help an organisation structure what it needs to examine.
They do not create telemetry.
They do not guarantee that a SOC can see radio-layer activity.
They do not confirm that a baseline control has been implemented correctly.
And they do not replace the need to understand the architecture being protected.
Where there is no SOC, threat modelling provides a method for identifying and prioritising credible exposures before monitoring capabilities are built or outsourced.
Where there is a SOC, the same process exposes the difference between what the organisation believes it monitors and what its sensors can actually observe.
That is where the value sits.
Wired infrastructure receives most of the conventional monitoring budget.
Wireless infrastructure often carries risk outside that conventional line of sight.
Threat modelling that does not account for the difference is not modelling the complete threat.
Need help identifying wireless and RF visibility gaps?
Speak to IntSpired®.
OFFENSIVE BY DESIGN. INTELLIGENT BY NATURE.
Top comments (0)