Security Capability Coordination Execution Framework for 5G Core Networks

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.

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.

The following terms are used in this document: A set of software modules deployed independently from 5G core network functions but closely collaborating with them to provide security capabilities. Includes NF-SA and MSC. An independent process running in the same virtual machine or container as a 5G network function (e.g., AMF, SMF, UPF), performing monitoring and enforcement through local operating system interfaces. Can be deployed independently or co-located with the local management system, aggregating data from multiple NF-SAs for global policy decision and event analysis. Fine-grained access control between network functions, VMs, Pods, and management systems based on identity labels rather than IP addresses alone. A numerical value dynamically computed based on observed security events, reflecting the trustworthiness of a network function or workload, and serving as input to policy decisions.

Current security deployments in 5G core networks face the following challenges: Trust Drift: Static security policies quickly become outdated when VNFs are instantiated, migrated, or scaled, creating blind spots. Lateral Movement: Once an attacker compromises one network function, they can exploit internal implicit trust relationships to spread laterally across the network. Insufficient Granularity: IP-based policies cannot distinguish different services within the same Pod, leading to overly permissive rules. Disjointed Orchestration: The security policy lifecycle is decoupled from the network service lifecycle managed by NFVO/VNFM, making coordination difficult. Security Coordination Components, deployed close to network functions, can sense the state of network functions in real time and adjust policies dynamically, effectively mitigating the above problems. This framework provides a standardized architecture for this solution.

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.

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.

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.

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.

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.

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.

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.).

The Security Coordination Components themselves need to be protected: Sensitive data MUST be encrypted at rest and in transit. NF-SA and MSC should implement integrity verification and anti-tampering mechanisms. Resource consumption of NF-SA must be limited to avoid impacting network function performance. Policy conflicts must be resolved deterministically, with logging.

None