Security Capability Coordination Execution Framework for 5G Core Networks

1.1. Background and Motivation

The evolution of 5G networks has led to a significant expansion of the attack surface, a surge in east-west traffic, and dynamic scaling of network functions, resulting in blurred trust boundaries. Traditional perimeter-based security models cannot perceive threat behaviors inside network functions and struggle to adapt to rapid changes in virtualized environments.¶

To address these issues, we propose a security capability coordination approach: deploy lightweight security agents near 5G core network functions, achieving zero-trust control and policy enforcement through local monitoring and execution without invading the core network functions themselves. This mode preserves the independence of the core network while providing fine-grained security enhancement.¶

This document defines a zero-trust security enforcement framework for 5G core networks, consisting of two types of attached security coordination components:¶

• Network Function Security Agent (NF-SA): deployed alongside each 5G network function instance, responsible for local monitoring, micro-segmentation enforcement, and asset data collection.¶

• Management Security Controller (MSC): deployed centrally, responsible for policy decision, event correlation, asset management, and component orchestration.¶

1.2. Scope

The security capability coordination execution framework defined in this document applies to 5G core network environments. The framework focuses on the coordination between security components and core network functions and does not involve modifications to the core network functions themselves.¶

4.1. Logical Components

Figure 1 shows the high-level architecture.¶

+---------------------+
|  Upper Security     |
|  Platform (SOC/SIEM)|
+----------+----------+
           |
   Northbound Interface
           |
+----------+----------+
|  MSC (PDP)          |
|  - Policy Decision  |
|  - Event Correlator |
|  - Asset Manager    |
+----------+----------+
           |
   Southbound Interface
           |
+----------+----------+
|  NF-SA (PEP/Sensor) |
|  - Micro-seg. Engine|
|  - Intrusion Det.   |
|  - Asset Collector  |
+----------+----------+
           |
+----------+----------+
|  5G NF Instance     |
|  (AMF/SMF/UPF etc.) |
+---------------------+

The NF-SA coexists as a sidecar with the network function instance in the same virtual machine or container. It obtains the runtime status of the network function through operating system interfaces (e.g., eBPF, netlink) and enforces access control policies. There is no direct business coupling between the NF-SA and the network function; they exchange necessary information only through local IPC.¶

The MSC centrally manages all NF-SAs, maintains a network-wide asset view and event correlation, and generates new policy instructions based on preconfigured policies or dynamic trust scores, delivering them via the southbound interface.¶

5.1. Identity-Based Micro-Segmentation

Traditional micro-segmentation relies on IP five-tuples, which are costly to maintain in dynamic environments. This framework uses identity labels instead of static addresses. Labels include:¶

• VNF name¶

• NF type¶

• Service name¶

• Deployment region¶

• Trust level¶

Policy rules are based on label matching. The NF-SA translates abstract rules into underlying enforcement rules based on the current mapping between IP addresses and labels.¶

The framework supports automatic learning of baseline connectivity patterns: during a learning period, the NF-SA records all normal connections, and the MSC generates whitelist policies accordingly. When business flows and ports change, the MSC synchronously updates security policies and delivers them to the relevant NF-SAs.¶

5.2. Local Intrusion Detection and Trust Scoring

The NF-SA incorporates a lightweight intrusion detection engine that can monitor the following types of events:¶

• Malware: Rootkit, Webshell, Reverse Shell¶

• Intrusion Attempt: Brute force (including seven subtypes: single-target fast, single-target slow, multi-target fast, multi-target slow, password spraying, distributed brute force, slow login attempt), password guessing¶

• Account Anomaly: Unauthorized account creation, unauthorized password change, user privilege escalation, file privilege escalation, process privilege escalation¶

• File Integrity: Shell file tampering, critical file tampering, illegal file download¶

• Kernel Anomaly: Hidden processes/ports, VM escape attempt¶

Each event carries a severity level (info, low, medium, high, critical) and a unique event class identifier. After collecting events, the MSC computes a trust score for each network function using a configurable algorithm. For example, deduct points when a critical event occurs, and slowly recover during event-free periods.¶

The trust score can directly influence policies: when a network function's trust score falls below a threshold, the MSC automatically issues an isolation policy, allowing only management-plane communication.¶

5.3. Policy Information Model Overview

To enable vendor-neutral policy representation, this framework defines a policy information model containing the following core elements:¶

• Policy Identifier: Uniquely identifies a policy.¶

• Subject: The asset object to which the policy applies, specified by asset type or label.¶

• Condition: Conditions under which the policy takes effect, including time range, trust score range, triggering event class, etc.¶

• Action: The action type to be enforced, including allow, deny, alert, isolate, etc.¶

• Target: The target asset on which the action operates, similarly specified by asset type or label.¶

• Priority: The basis for resolving conflicts among multiple policies.¶

• Status: Whether the policy is active or inactive.¶

The detailed data model definition will be provided in a future version of this draft.¶

6.1. Southbound Interface (Policy Provisioning)

The southbound interface connects the MSC (PDP) to the NF-SA (PEP) for policy configuration, updates, and health checks. The transport layer MUST be secured with TLS or SSH for mutual authentication and encryption.¶

Request data fields include: security event ID, source asset ID, destination asset ID, source address, destination address, source port, destination port, communication protocol (UDP/TCP), service name, policy type (add to whitelist/blacklist). Response data fields include error code and failure detail message.¶

6.2. Northbound Interface (Event Reporting)

The northbound interface exports security events and asset information to an upper security platform. The event format contains fields such as priority, version, timestamp, hostname, app-name, procid, msgid, and message content. The message content contains specific security event fields: event ID, affected asset ID/name/type/IP, affected business asset information, event type, event name, event class, event level, evidence, attack status, occurrence time, first/last occurrence time, source IP/port, attacker IP, destination IP/port, victim IP, username, user group, source asset ID, service name, etc.¶

6.3. Asset Data Interface

The asset data interface is used for asset inventory synchronization between the NF-SA and the MSC. Asset data fields include: region ID, network function ID, network function name, manufacturer ID, VM list (including VM ID, attributes, hostname, network interface information, IP address, broadcast address, description, destination address, MAC address, name, netmask, NIC type, NAT address list, etc.), operating system attributes (distribution version, name, patch level, kernel version), database/middleware/web application attribute list (installation path, component name, component open port, component version, project list, plugin list, etc.).¶