Cybersecurity system for telecommunications networks using a cloud-native zero-trust framework and machine learning-based anomaly detection

Abstract

A system for the cybersecurity of telecommunications networks (100), comprising: a cloud-native zero-trust control plane (1) configured to generate and enforce access policies for telecommunications workloads, network functions and application programming interfaces; an identity, device and context engine (2) configured to determine an identity context for at least one entity that includes a participant, a device, a network function, a service or an administrator; a telecommunications telemetry acquisition and streaming layer (3) configured to acquire multiparameter telemetry data from at least one telecommunications domain which includes a radio access network, a core network, an IP transport network, an edge cloud or an OSS / BSS domain; a feature engineering and normalization layer (4) configured to transform the collected telemetry data into standardized features for analysis; an ML-based engine for anomaly detection and threat assessment (5) configured to detect anomalous behavior and output a threat assessment based on standardized features and identity context; a correlation, threat intelligence, and explainability module (6) configured to correlate the anomalous behavior with the telecommunications topology context and generate an explainable security alert; and a dashboard (7) for automated response, orchestration and compliance monitoring, configured to trigger one or more remediation actions based on the threat assessment and to log the remediation actions for audit purposes, where the system (100) performs a continuous review of the entity and enforces least-privileged access according to a zero-trust framework, while using machine learning to detect cyber anomalies.

Description

INVENTION AREA

[0001] The present invention relates to cybersecurity for telecommunications networks, in particular a cloud-native zero-trust security system for telecommunications environments (including 4G / 5G networks, IMS, OSS / BSS, SDN / NFV and Kubernetes-based network functions) that performs continuous monitoring and machine learning (ML)-based anomaly detection to identify, correlate and defend against cyber threats in near real time. BACKGROUND OF THE INVENTION

[0002] The subject matter discussed in the background section should not be considered prior art solely because it is mentioned therein. Likewise, a problem mentioned in the background section or related to its subject matter should not be considered to be prior art. The subject matter in the background section merely presents various approaches, which could themselves also be inventions.

[0003] Telecommunications networks have evolved from hardware-centric, perimeter-protected architectures to highly distributed, software-defined, cloud-native ecosystems. Modern operator environments encompass multi-vendor deployments that include Radio Access Network (RAN), 4G / 5G core network, IMS, IP transport, edge cloud, and OSS / BSS platforms. Network functions are increasingly implemented as virtualized network functions (VNFs) and cloud-native network functions (CNFs), deployed on NFV infrastructures and Kubernetes clusters. Furthermore, modern 5G networks leverage service-based architectures (SBAs) with extensive internal and external API exposure, creating numerous new security surfaces not present in traditional telecommunications designs.

[0004] In such environments, data and control signals are not confined to north-south boundaries (external input and output) but also encompass significant amounts of east-west communication between microservices, CNFs, service mesh components, data stores, and orchestration layers. Consequently, traditional perimeter-based models—which focus on firewalls and gateway checks—are no longer sufficient, as attackers can exploit internal trust relationships, misconfigurations, or stolen credentials to move laterally. Furthermore, telecommunications networks must ensure high availability, low latency, and stringent quality of service requirements, making it difficult to implement extensive security controls without compromising service continuity.

[0005] Telecommunications-specific cyber threats include, but are not limited to: signaling storms and control plane floods, API abuse against SBA endpoints, fraud and account takeover through compromised credentials, SIM / eSIM-related identity theft, malicious roaming or location spoofing, distributed denial-of-service (DDoS) attacks on edge and core services, and lateral movement between network functions once an internal access point has been gained. Furthermore, operator platforms typically integrate numerous third-party systems and provide partner interfaces, increasing the likelihood of privilege escalation and misconfigured access controls. As telecommunications environments become multi-tenant in many deployments (including private 5G, MVNO models, and shared infrastructure), the ability to enforce strict isolation between tenants, slices, and services is critical.

[0006] Another major challenge is the nature of telecommunications telemetry. Operators generate vast amounts of security- and network-relevant signals across multiple domains, including control plane signaling events, user-plane data flow metadata, API gateway and service mesh protocols, IAM authentication protocols, Kubernetes audit logs, container runtime events, and SDN / NFV orchestration events. These telemetry sources are heterogeneous in terms of format, temporal granularity, and semantics. Existing security monitoring solutions often rely on centralized SIEM pipelines and static correlation rules, which can be limited by ingestion bottlenecks, inconsistent normalization, and delayed detection. Furthermore, static, rule-based systems struggle to distinguish genuine attacks from legitimate telecommunications behavior, such as...Temporary peaks caused by planned maintenance, increases in roaming, emergencies, or regional traffic fluctuations.

[0007] In parallel, modern security architectures are increasingly adopting zero-trust principles, which require continuous verification, risk-based access decisions, and least-privilege authorization, rather than implicit trust based on network location. However, the effective implementation of zero trust in telecommunications networks presents unique challenges. Telecommunications entities such as subscribers, devices, network functions, and service accounts often have dynamic identities and contexts that change rapidly due to mobility, roaming, slice switching, and events throughout the session lifecycle. Traditional access control models may not be able to accommodate such frequent context changes.Furthermore, enforcement must occur across various enforcement points, including API gateways, service mesh sidecars, workload ingress / egress policies, CNF service identities, and network policy engines.

[0008] Even where zero-trust controls are partially implemented, many existing solutions lack integrated, real-time anomaly detection specifically tailored to telecommunications. While machine learning-based anomaly detection can offer stronger protection against unknown or evolving threats, telecommunications traffic patterns change due to seasonal trends, rollout events, and evolving subscriber behavior. This leads to conceptual drift, where fixed models lose accuracy over time, resulting in false alarms or false negatives.Furthermore, security teams need not only detection, but also actionable and traceable results - including the reasons for a threat assessment, affected resources such as slices or network functions, and recommended remediation measures - so that automated responses can be safely applied in business-critical operator networks.

[0009] Therefore, there is a technical need for an improved cybersecurity solution that is cloud-native and scalable, capable of capturing and streaming large amounts of telecommunications telemetry, creating identity- and context-related representations, performing ML-driven anomaly detection with drift handling, correlating anomalies with topology and threat information, and executing automated response orchestration such as microsegmentation updates, quarantine, rate limiting, or credential rotation, while maintaining audit trails and compliance reports.The present invention overcomes these limitations by providing a system for cybersecurity in telecommunications networks (100) that integrates a cloud-native zero-trust control layer with machine learning-based anomaly detection and explainable security response capabilities suitable for modern telecommunications implementations.

[0010] It is understood that for the purposes of this description and the subsequent detailed explanation, the security framework described herein will be referred to as the "Framework of Zero Trust Maturity Architecture for Cyber ​​Security (FOZTMA-CS)," with this terminology used solely for the sake of simplicity and clarification. The framework was developed and tested by the inventor, and reference to it in this description is only intended to facilitate understanding of the disclosed concepts, architecture, approach to maturity assessment, and implementation methodology. Any mention of recognized guidance, models, standards, or maturity references, including but not limited to NIST SP 800-207, CISA Zero Trust Maturity Model v2.0, and NIST Cybersecurity Framework (CSF) 2.0 serves solely contextual and informative purposes to illustrate possible similarities and is not to be interpreted as a limitation of the scope of the invention, as an acknowledgment of the prior art or as a restriction of the invention to a particular nomenclature, framework designation, compliance rule or implementation standard.

[0011] The use of any examples or illustrative phrases (e.g., "as") in relation to certain embodiments described herein serves only to better illustrate the invention and does not constitute a limitation of the scope of the otherwise claimed invention. No wording in the description shall be construed as referring to an unclaimed element that is essential for the exercise of the invention.

[0012] The information disclosed above in this "Background" section is provided solely for the purpose of better understanding the background of the invention and may therefore contain information that is not part of the prior art already known to a person skilled in the art in this country. SUMMARY

[0013] Before describing the systems presented here, it should be noted that this application is not limited to the specific systems and methods described, as there may be several possible embodiments not expressly presented in this disclosure. It should also be noted that the terminology used in the description serves only to describe the specific versions or embodiments and is not intended to limit the scope of this application.

[0014] The present invention relates to a cybersecurity system for telecommunications networks (100) that secures telecommunications environments such as 4G / 5G core networks, RAN edge cloud, IMS, OSS / BSS, SDN / NFV, and cloud-native network functions using a cloud-native zero-trust framework integrated with machine learning-based anomaly detection. The system (100) is configured to provide continuous verification, enforcement of the principle of least privilege, and near real-time threat detection across telecommunications workloads, service-based interfaces, and exposed APIs.

[0015] In one embodiment, the system (100) comprises a cloud-native zero-trust control plane (1) and an identity, device state, and context engine (2). The control plane (1) is configured to define, establish, and enforce access policies based on zero-trust principles, including continuous authorization and micro-segmentation, while the engine (2) is configured to determine an identity context for entities, including subscribers, devices, network functions, service accounts, and administrators, using parameters such as SIM / eSIM identity, certificate identity, slice identifiers, roaming status, location region, and security state attributes.

[0016] In one embodiment, the system (100) further comprises a telecommunications telemetry data acquisition and streaming layer (3) and a feature engineering and normalization layer (4). The acquisition layer (3) collects multiparametric telecommunications telemetry from various sources, including control plane events, user flow metadata, API gateway protocols, IAM protocols, service mesh traces, and container / Kubernetes runtime events, and transmits the telemetry data in a time-synchronized manner. The feature layer (4) transforms the heterogeneous telemetry into standardized feature representations, such as time series windows, behavioral baselines, statistical summaries, and graph features that depict relationships between entities and network functions.

[0017] In one embodiment, the system (100) comprises a machine learning (ML)-based engine for anomaly detection and threat assessment (5) and a module for correlation, threat intelligence, and explainability (6). The ML engine (5) processes the standardized features together with the identity context to detect anomalous behavior, generate anomaly indicators, and calculate threat assessments, optionally employing an ensemble of models and drift-handling mechanisms to maintain accuracy as telecommunications traffic distributions change. The module (6) correlates detected anomalies with the telecommunications topology / slice context and threat intelligence indicators, generating explainable security alerts, including contributing factors, confidence levels, affected assets, and recommended actions.

[0018] In one embodiment, the system (100) includes a dashboard for automated response coordination and compliance (7) configured to trigger remediation actions based on threat assessments and correlated alerts, including dynamic policy updates in the zero-trust control plane (1), workload or slice isolation, quarantine, API rate limiting, credential blocking or rotation, and automated SOC ticketing. The module (7) further maintains audit logs and generates compliance reports, enabling telecom operators to achieve continuous monitoring, rapid containment, and traceable security governance in cloud-native telecom deployments. BRIEF DESCRIPTION OF THE DRAWING

[0019] To clarify various aspects of some embodiments of the present invention, a more detailed description of the invention is given with reference to specific embodiments shown in the accompanying drawing. It is understood that this drawing represents only illustrative embodiments of the invention and is therefore not to be considered a limitation of its scope. The invention is described and explained with additional specificity and detail using the accompanying drawing.

[0020] To make the advantages of the present invention easily understandable, a detailed description of the invention is discussed below in conjunction with the accompanying drawing, although it should not be assumed that the scope of the invention is limited to the accompanying drawing, in which: Fig. Figure 1 shows a block diagram representation of the system (100) for cybersecurity in telecommunications networks using a cloud-native zero-trust framework and machine learning-based anomaly detection. DETAILED DESCRIPTION

[0021] The present invention relates to a system (100) for cybersecurity in telecommunications networks using a cloud-native zero-trust framework and an anomaly detection based on machine learning.

[0022] Fig. Figure 1 shows a detailed block diagram representation of the system (100) for cybersecurity in telecommunications networks using a cloud-native zero-trust framework and machine learning-based anomaly detection.

[0023] Reference to embodiments: The following detailed description is intended to enable a person skilled in the art to implement the invention. The described embodiments are illustrative and not limiting, and the scope of the invention is defined by the accompanying claims. The same reference numerals throughout the description denote identical elements.

[0024] In this description, the term “System for Cybersecurity in Telecommunication Networks (100)” refers to the overall platform. The system (100) comprises: a cloud-native zero-trust control layer (1), an identity, device health, and context engine (2), a layer for collecting and streaming telecommunications telemetry data (3), a feature engineering and normalization layer (4), an ML-based engine for anomaly detection and threat assessment (5), a correlation, threat intelligence, and explainability module (6), and a dashboard for automated response orchestration and compliance (7).

[0025] In one embodiment, the system (100) is implemented as a set of cloud-native, containerized microservices deployed on a telecommunications cloud, public cloud, private cloud, and / or edge cloud infrastructure. The microservices can be orchestrated using a container orchestration platform such as Kubernetes or an equivalent orchestration framework. The system (100) is configured to work with telecommunications network functions, including but not limited to 4G / 5G core network functions, service-based architecture (SBA) interfaces, information management systems (IMS) functions, IP transport components, network slicing functions, SDN controllers, network frequency vault (NFV) orchestration platforms, API gateways, service mesh infrastructures, and open-source software / business service systems (OSS / BSS) platforms.In such a deployment, the system (100) supports horizontal scaling, high availability and fault tolerance to meet telecommunications-level service continuity requirements.

[0026] In one embodiment, the system (100) is designed to enable security enforcement and detection at multiple points, including: (i) API exposure points for SBA APIs, (ii) east-west communication paths between cloud-native network functions (CNFs), (iii) edge cloud workloads, and (iv) operator management interfaces. The system (100) is configured to apply zero-trust principles to both north-south and east-west service-to-service traffic, thereby reducing implicit trust within the operator network and restricting lateral movement.

[0027] In one embodiment, the system (100) operates in a continuous verification loop, continuously evaluating identity / context, continuously collecting telemetry data, continuously updating model-based anomaly assessment, and dynamically adapting enforcement policies to changing risks. This continuous loop enables the system (100) to detect threats earlier than with batch-driven security analyses and apply remediation measures, while maintaining network stability.

[0028] In one embodiment, the cloud-native zero-trust control plane (1) is configured to manage the lifecycle of zero-trust policies, including policy definition, policy decision-making, and policy enforcement. The control plane (1) may include a policy management function for defining and versioning policies, a policy decision-making function for evaluating access requests and risk context, and a policy distribution function for distributing enforceable rules to enforcement points. The control plane (1) enforces least-privilege authorization by allowing only explicitly permitted actions for specific identities, workloads, APIs, slices, and operational contexts.

[0029] In one embodiment, the control plane (1) enforces access control for telecommunications services by evaluating at least one of the following elements: identity attributes generated by the identity engine (2), a threat score generated by the machine learning engine (5), a slice / service criticality level, the time-of-day context, the roaming context, the device state, and / or service-to-service trust boundaries. By using such a multi-factorial context, the control plane (1) performs continuous authorization instead of a one-time perimeter authorization.

[0030] In one embodiment, the control plane (1) implements a micro-segmentation, restricting communication between services using service identity rules, mutual authentication requests, and policy-based network segmentation. The micro-segmentation can be enforced at API gateways, service mesh sidecars, CNF entry / exit points, network policy engines, or any equivalent enforcement points. This reduces the propagation of attacks by restricting communication to known and validated service paths.

[0031] In one embodiment, the control plane (1) supports dynamic policy updates based on the threat score and correlation results. For example, if the ML engine (5) identifies high-risk behavior for a workload identity or participant context, the control plane (1) can update the policy to require stronger authentication, restrict access to sensitive APIs, enforce stricter rate limits, or isolate a specific slice / workload while keeping essential disaster recovery or critical services available.

[0032] In one embodiment, the Identity, Device Posture & Context Engine (2) is configured to create and continuously update an identity context for one or more entities, where the entities include subscribers, user devices, CNFs / VNFs, service accounts, APIs, administrator accounts, and operator tools. The identity context can be represented as a structured dataset, a context vector, or a graph entity profile and is used by the zero-trust control plane (1) and the machine learning engine (5).

[0033] In one embodiment, the identity context generated by the engine (2) includes at least two of the following elements: participant identity parameters (including persistent or temporary identifiers), subscription class or service entitlement, roaming status, access type, geographic region, device identifiers, certificate identities, workload identities, Kubernetes service account identities, slice identifiers, and device state attributes. State attributes may include compliance status, security patch status, integrity checks, device risk markers, and other trust indicators. The engine (2) also incorporates historical context, such as past anomalies, previous access denials, repeated authentication failures via " ", suspicious token reuse, or previously observed indicators of malicious activity.

[0034] In one embodiment, the engine (2) performs context unification by resolving identities observed in different telemetry feeds into a single logical unit. For example, an API token observed at an API gateway can be associated with a service account identity and further associated with a workload identity and a cluster identity. Similarly, participant activities can be associated with a slice identifier and a roaming region, enabling the system (100) to distinguish legitimate roaming spikes from malicious spikes.

[0035] In one embodiment, the engine (2) outputs the identity context to other modules via a standardized interface, enabling: (i) risk-based policy assessment by the control layer (1), (ii) feature enrichment by the feature layer (4), and (iii) entity-centric anomaly assessment by the ML engine (5).

[0036] In one embodiment, the telecommunications telemetry collection and streaming layer (3) is configured to collect and stream multiparameter telemetry data from telecommunications domains and cloud-native infrastructure. Such telemetry data can include control plane signaling events, user plane data stream metadata, DNS / HTTP(S) metadata, API gateway logs, IAM logs, authentication and authorization logs, service mesh traces, workload-to-workload request logs, Kubernetes audit events, container runtime events, SDN / NFV orchestration events, and configuration changes. The collection layer (3) is configured to accept telemetry data in various formats and protocols and to normalize timing for near real-time analysis.

[0037] In one embodiment, the acquisition layer (3) performs temporal coordination and correlation of events by linking acquired events with entity identifiers. The entity identifiers can be derived directly from event metadata or determined by querying the identity engine (2). This linking enables the system (100) to calculate baseline values ​​at the entity level and to detect anomalies associated with specific subscribers, devices, workloads, APIs, and slices.

[0038] In one embodiment, the acquisition layer (3) performs functions to improve acquisition reliability and quality, such as buffering, deduplication of repeated events, enrichment with topology labels (region, cluster, slice), and priority routing for critical telemetry streams. The acquisition layer (3) is further configured to support the high throughput typical of telecommunications networks and provides backpressure treatment to prevent telemetry loss during bursts.

[0039] In one embodiment, the feature engineering and normalization layer (4) is configured to transform heterogeneous telecommunications telemetry into standardized feature representations that can be processed by machine learning analytics and correlation logic. The layer (4) can generate time series windows and aggregates (e.g., burstiness per second / per minute), behavioral baselines per identity context, graph features representing communication relationships between entities and network functions, and statistical summaries for slice traffic and API usage.

[0040] In one embodiment, the feature layer (4) creates telecommunications-specific features that capture patterns such as signaling storms, unusual session fluctuation, abnormal connect / disconnect patterns, abnormal API endpoint entropy, unexpected east-west call paths, repeated authorization failures, anomalous token reuse, abnormal request fan-outs, and deviations from slice-specific traffic profiles. The feature layer (4) can also compute features that describe rare event sequences or unusual combinations of context attributes (e.g., a high-privilege API called from an unusual region with an unusual service account).

[0041] In one embodiment, layer (4) performs data normalization functions, including unit normalization, schema normalization, null handling, compensation for missing telemetry data, and outlier clipping based on operational thresholds. Layer (4) further enriches features using topology and configuration context to ensure that anomaly detection takes into account scheduled maintenance windows, rollout states, or operator-approved changes, where such context is available.

[0042] In one embodiment, the ML-based anomaly detection and threat assessment engine (5) is configured to receive standardized features from layer (4) and identity context from engine (2) and generate anomaly indicators, a threat score, and optionally an anomaly class label. The threat score can be a numerical risk value, a categorical severity level, or a probabilistic confidence output and can be calculated per entity, per slice, per workload, per API endpoint, or per region.

[0043] In one embodiment, the ML engine (5) implements an ensemble of models comprising at least one unsupervised model configured to detect novel or unknown threats, and at least one supervised or semi-supervised model configured to detect known malicious patterns learned from flagged incidents or curated datasets. The outputs of multiple models are combined using weighted aggregation, risk fusion logic, or confidence calibration to generate the final threat score. In some embodiments, the ML engine (5) may additionally incorporate rule-based constraints as safeguards to ensure conservative measures for business-critical services.

[0044] In one embodiment, the ML engine (5) includes a concept drift handler configured to detect drifts in telecommunications traffic distributions and update thresholds and / or model parameters while maintaining operator-defined safety limits. Drift can be detected using statistical divergence, change point detection, baseline degradation detection, or power feedback signals. The drift handler reduces false positives caused by harmless changes such as seasonal fluctuations, roaming spikes, planned upgrades, or the introduction of new services, while maintaining sensitivity to malicious behavior.

[0045] In one embodiment, the ML engine (5) supports low-latency inference by processing streaming features and maintaining incremental baselines. The ML engine (5) can operate in a near real-time mode to generate alerts and threat assessments within a defined latency threshold suitable for telecommunications operations.

[0046] In one embodiment, the Correlation, Threat Intelligence, and Explainability module (6) is configured to correlate anomaly outputs with the telecommunications topology context, threat intelligence indicators, and historical incident patterns. The topology context may include the affected slice, network function, region, tenant, cluster, API endpoint, or service dependency chain. Threat intelligence indicators may include suspicious IP addresses, domains, known malicious patterns, and other indicators of compromise.

[0047] In one embodiment, the module (6) generates an explainability output associated with each alert, the explainability output including contributing features, an explanation of why the activity is anomalous compared to the baseline, a confidence score, affected resources, and recommended response measures or playbooks. The explainability output enables operators to validate alerts and take corrective action, thereby reducing the risk of disruption to legitimate telecommunications services.

[0048] In one embodiment, the module (6) assigns correlated incidents to attack phases or tactics, enabling prioritization and triage. For example, an anomaly characterized by credential abuse and unusual API token reuse can be attributed to credential abuse or privileges abuse, while a pattern of abnormal east-west communication can be attributed to lateral movement attempts. Such an attribution improves the operational response workflow and reduces the average response time.

[0049] In one embodiment, the automated response coordination and compliance dashboard (7) is configured to receive threat assessments and correlated alerts and trigger remediation actions. Remediation actions may include dynamic policy updates at the control plane (1), changes to microsegmentation enforcement, isolation of a slice or workload, quarantine of an entity identity, API rate limiting and throttling, credential revocation / rotation, session termination, and / or automated ticket generation for SOC workflows.

[0050] In one embodiment, the module (7) implements a response decision logic that selects remediation actions based on severity, confidence, service criticality, and operator-defined safety modes. For example, the module (7) can apply rate limiting and enhanced verification for medium-reliability alerts, while for high-reliability alerts it can quarantine a workload identity or isolate a slice, maintaining whitelists for essential services. In certain embodiments, the module (7) supports human-in-the-loop escalation for high-impact actions but still allows automatic containment for clearly malicious events.

[0051] In one embodiment, module (7) maintains audit logs that capture telemetry identifiers, identity context, timestamps, decisions, applied policies, actions taken, and results. The dashboard component provides visualizations for the operator, incident timelines, and output data for compliance reports. The logged data records enable forensic investigations, regulatory compliance, and internal governance.

Claims

[1] A system for the cybersecurity of telecommunications networks (100), comprising: a cloud-native zero-trust control plane (1) configured to generate and enforce access policies for telecommunications workloads, network functions and application programming interfaces; an identity, device and context engine (2) configured to determine an identity context for at least one entity that includes a participant, a device, a network function, a service or an administrator; a telecommunications telemetry acquisition and streaming layer (3) configured to acquire multiparameter telemetry data from at least one telecommunications domain which includes a radio access network, a core network, an IP transport network, an edge cloud or an OSS / BSS domain; a feature engineering and normalization layer (4) configured to transform the collected telemetry data into standardized features for analysis; an ML-based engine for anomaly detection and threat assessment (5) configured to detect anomalous behavior and output a threat assessment based on standardized features and identity context; a correlation, threat intelligence, and explainability module (6) configured to correlate the anomalous behavior with the telecommunications topology context and generate an explainable security alert; and a dashboard (7) for automated response, orchestration and compliance monitoring, configured to trigger one or more remediation actions based on the threat assessment and to log the remediation actions for audit purposes, where the system (100) performs a continuous review of the entity and enforces least-privileged access according to a zero-trust framework, while using machine learning to detect cyber anomalies. [2] System (100) according to claim 1, wherein the zero-trust control layer (1) comprises a policy decision function and a policy enforcement function that enforce micro-segmentation for telecommunications services by applying service-to-service authorization and mutual authentication for east-west traffic. [3] System (100) according to claim 1, wherein the identity, device state and context engine (2) derives the identity context using at least two of the following elements: SIM / eSIM identity, device identifier, certificate identity, Kubernetes service account identity, network slice identifier, roaming state, geolocation region or device state attributes. [4] System (100) according to claim 1, wherein the telecommunications telemetry acquisition and streaming layer (3) acquires at least one of the following elements: control plane signaling events, user plane data flow metadata, DNS / HTTP(S) metadata, API gateway protocols, service mesh traces, container runtime events or SDN / NFV orchestration events, and aligns the telemetry data temporally into a common event stream. [5] System (100) according to claim 1, wherein the feature engineering and normalization layer (4) generates at least one of the following elements: time series windows, behavior-based base values ​​for “ “ per identity context, graph features representing relationships between participants and network functions, or statistical summaries for network slice traffic. [6] System (100) according to claim 1, wherein the ML-based engine for anomaly detection and threat assessment (5) comprises an ensemble of models, including at least one unsupervised model and at least one semi-supervised or supervised model, and further comprises a concept drift handler that updates model thresholds or model parameters based on observed changes in the distribution of telecommunications traffic. [7] System (100) according to claim 1, wherein the correlation, threat information and explainability module (6) integrates threat information indicators and tactics to associate the anomalous behavior with at least one attack pattern and generates an explainability output that includes contributing features, a confidence score and likely affected telecommunications resources. [8] System (100) according to claim 1, wherein the dashboard for automated response coordination and compliance (7) performs at least one remedial action comprising: dynamic policy update in the zero-trust control plane (1), isolation of a network slice, quarantine of a workload, API rate limiting, revocation or rotation of credentials, or automated ticket creation for a security operations workflow. [9] System (100) according to claim 1, wherein the system (100) is deployed in a cloud-native manner using containerized microservices and a distributed message bus, and wherein the telecommunications telemetry collection and streaming layer (3) and the ML-based anomaly detection and threat assessment engine (5) operate in near real time to generate alerts within a predefined latency threshold. [10] System (100) according to claim 1, wherein the ML-based anomaly detection and threat assessment engine (5) performs a closed-loop learning process by receiving feedback from the automated response coordination and compliance dashboard (7) indicating whether a security alert was true or false, and updating at least one model, rule or threshold based on the feedback to reduce false alarms in telecommunications-specific traffic patterns.

Images