💻 computer science

Intent-based Security Management Using the TM Forum TR292I Security Ontology

This paper proposes an autonomous, intent-based security framework leveraging the TM Forum TR292I Security Ontology and Description Logic to dynamically neutralize threats in complex 5G-Advanced and 6G cloud-native architectures while balancing protection with resource constraints, validated through the automated mitigation of a DDoS attack on a gNB slice.

Original authors: Loay Abdelrazek

Published 2026-05-28

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Loay Abdelrazek

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the manager of a massive, futuristic city made entirely of digital buildings (the 5G/6G network). In the past, you had a team of security guards who walked around with clipboards, manually checking every door and changing locks whenever they saw a suspicious person.

The problem is that this city is changing too fast. Buildings appear and disappear in milliseconds, and the "bad guys" (hackers) are attacking from every angle at once. By the time a human guard figures out what's happening and changes a lock, the city is already compromised.

This paper proposes a new way to run this city: An autonomous, self-protecting system driven by "Intent."

Here is how the paper explains this solution, broken down into simple concepts:

1. The Problem: The "Manual" Bottleneck

In modern networks, everything is fluid. A security rule that says "Block traffic from this specific IP address" is useless if that address changes every second.

The Old Way (Imperative): Telling the computer, "If you see X, do Y." This breaks when the network changes shape.
The New Way (Declarative/Intent): Telling the computer, "I want the city to be safe, and I want it to stay fast." You don't tell it how to do it; you just tell it what the result should look like.

2. The Solution: The "Security Dictionary" (TR292I Ontology)

To make the computer understand your "Intent," everyone needs to speak the same language. The authors created a new standard dictionary called TM Forum TR292I.

Think of this as a universal translator that allows different security systems (from different companies) to understand each other.
It defines what a "threat" is, what a "security goal" is, and what a "security tool" is, using a strict mathematical structure (like a very organized filing system).

3. The Brain: The "Intent Management Function" (IMF)

This is the smart software brain that sits in the middle.

It listens: It hears your goal: "Keep the network safe, but don't slow it down."
It looks: It scans the city in real-time to see where the attack is happening.
It decides: It automatically picks the best tool to fix the problem without asking a human.

4. The Balancing Act: Safety vs. Speed

This is the paper's most important trick. Usually, security slows things down (like a heavy security checkpoint).

The system has a built-in "calculator." Before it picks a security tool, it asks: "How much will this tool slow down the network?"
The Rule: If a security tool is super fast at stopping a hacker but slows down the network too much (violating the speed promise), the system rejects it.
It only picks a tool that stops the attack and keeps the network fast enough to satisfy the customers.

5. The Real-World Test: The "Drone" Scenario

The paper tested this with a story about a network controlling industrial drones.

The Attack: A hacker started flooding the drones' control signals (a DDoS attack).
The Goal: Stop the attack in under 50 milliseconds, but don't add more than 20 milliseconds of delay to the signal.
The Choice: The system had two options:
1. Option A (The Heavy Shield): Stops the attack instantly (10ms) but slows the network by 35ms. Result: Rejected! It breaks the speed rule.
2. Option B (The Smart Filter): Stops the attack in 30ms and slows the network by only 15ms. Result: Accepted! It meets both the safety and speed rules.
The Outcome: The system automatically chose Option B and stopped the attack without a human ever touching a keyboard.

Summary

The paper argues that we can no longer rely on humans to manually configure security for fast-moving 5G and 6G networks. Instead, we need a system that:

Understands a high-level goal ("Be safe, stay fast").
Uses a shared dictionary to talk to different machines.
Automatically calculates the trade-offs between safety and speed.
Fixes problems instantly on its own.

The authors claim this approach makes networks "self-protecting," allowing them to fight off complex attacks while keeping the service running smoothly for everyone.

Technical Summary: Intent-Based Security Management Using the TM Forum TR292I Security Ontology

Problem Statement

Modern 5G-Advanced and emerging 6G cloud-native telecom architectures face unprecedented hyper-complexity, characterized by fluid structural topologies, multi-layered threat vectors, and disaggregated environments (e.g., Open RAN). Traditional security management relies on manual, imperative configurations (e.g., "If Condition A, then Action B"). In dynamic, software-defined networks where components like the Centralized Unit (O-CU) scale or migrate instantly, static rules become a liability. They introduce severe latency gaps, rendering security blind to topology changes or inadvertently causing self-inflicted Denial of Service (DoS) by severing critical control loops. The inability of human engineers to manually analyze, update, and deploy configurations across thousands of cell sites in real-time leaves networks vulnerable to sophisticated, multi-stage attacks that outpace traditional response mechanisms.

Methodology

The paper proposes a declarative, autonomous, self-protecting framework centered on the TM Forum TR292I Security Ontology v4.0.0. This approach shifts security management from imperative configuration to declarative state management driven by an Intent Management Function (IMF).

Core Architectural Design

Ontology Foundation: The TR292I v4.0.0 ontology extends the foundational TM Forum Intent Common Model (ICM) using lightweight Resource Description Framework Schema (RDFS) vocabularies. This design choice avoids the computational overhead of heavy Web Ontology Language (OWL) reasoners, ensuring suitability for millisecond-sensitive telecom edge loops.
Semantic Abstraction: The model decouples high-level functional security goals from technical enforcement capabilities. Key classes include:
- sec:Asset: Represents logical or physical resources (e.g., gNB slices) as subclasses of icm:Target.
- sec:AttackSurface: Explicitly maps exposure vectors (e.g., control-plane interfaces) to assets.
- sec:SecurityExpectation: Divided into Protection Expectations (functional goals like confidentiality) and Performance Expectations (non-functional constraints like latency).
- sec:SecurityCapability: Models countermeasures (Preventive, Detection, Mitigation) and explicitly declares their resource costs via the sec:impactOnResource property.
Closed-Loop Execution: The IMF ingests operator intents, reads real-time operational context, and maps necessary configuration changes. If the environment deviates from the intended state, the system dynamically recalculates a remediation path without human intervention.

Optimization Engine

The system formulates security intent compliance as a multi-constraint optimization problem. When a threat is detected, the IMF selects a mitigation capability ( $c^*$ ) by minimizing response time while satisfying two constraints:

Time Constraint: The mitigation time must be within the maximum acceptable processing time ( $P_{max}$ ).
Resource Constraint: The resource impact cost ( $I_{value}$ ) of the capability on critical resources (e.g., network latency) must not exceed the performance degradation threshold ( $V_{ceiling}$ ) defined by active Service Level Agreements (SLAs).

Key Contributions

The paper outlines three primary contributions:

Standardized Security Meta-Model Design: The presentation of the TR292I v4.0.0 ontology, which provides the first comprehensive semantic domain vocabulary for intent-based security. It decouples functional expectations from physical countermeasures and standardizes the structural understanding of threats across multi-vendor ecosystems.
Multi-Constraint Optimization Formulation: A formal logical engine that ensures security actions do not violate consumer SLAs. It explicitly models the trade-off between threat neutralization speed and the resource overhead (latency, compute) introduced by the countermeasure.
Formal Semantic Verification Walkthrough: A structural validation of the architecture using a real-time Distributed Denial of Service (DDoS) mitigation scenario on a virtualized Next-Generation NodeB (gNB). This demonstrates the system's ability to resolve runtime constraint conflicts using SPARQL and Description Logic graph processing.

Results and Validation

The paper validates the model through a conceptual case study involving a DDoS attack on a 5G network slice supporting industrial drones.

Scenario: An intent requires threat neutralization within 50ms while limiting latency penalties to 20ms.
Execution:
- Candidate A (DPI Redirect): Offers 10ms mitigation speed but incurs a 35ms latency penalty. The system discards this candidate as it violates the 20ms SLA ceiling.
- Candidate B (Edge Throttling): Offers 30ms mitigation speed with a 15ms latency penalty. This candidate satisfies both the time constraint ( $30 \le 50$ ) and the resource constraint ( $15 \le 20$ ).
Outcome: The IMF autonomously selects Candidate B, triggering dynamic edge request throttling. The system successfully neutralizes the signaling storm while maintaining SLA integrity, demonstrating the capability to resolve conflicts without human intervention.

Significance and Claims

The paper claims that the design and standardization of the TM Forum TR292I Security Ontology v4.0.0 provide the telecommunications industry with a necessary blueprint to transition from fragile, human-in-the-loop imperative configurations to self-protecting operations.

By extending the ICM with a lightweight, RDFS-compliant schema, the framework enables autonomous loops to:

Evaluate security postures and map attack perimeters declaratively.
Activate technical controls while explicitly balancing functional protection against non-functional resource impacts.
Ensure that 5G-Advanced and emerging 6G systems possess the automation, scalability, and multi-vendor interoperability required to defend disaggregated network topologies against sophisticated threat landscapes.

The authors position this work as a critical step in bridging the structural gap between the fluidity of modern network architectures and the rigidity of traditional security enforcement, ensuring that security remains effective even as network topologies shift instantaneously.