Trust management system for a communication network

Abstract

Embodiments include methods performed by a trust management system associated with a communication network. Such methods include, for each of a plurality of contexts of a network function, NF, of the communication network, determining (1810) one or more metrics representative of trustworthiness of the context and, for each context, determining (1820) a context trust score based on the one or more metrics representative of trustworthiness of the context. Such methods include determining (1840) a current NF trust score based on the plurality of context trust scores and determining (1860) a context-specific action for at least one context of the NF, based on the current NF trust score and a current value of a configurable trust threshold for the NF. Other embodiments include trust management systems configured to perform such methods.

Description

[0001] TRUST MANAGEMENT SYSTEM FOR A COMMUNICATION NETWORK

[0002] TECHNICAL FIELD

[0003] The disclosure relates to a method performed by a trust management system in a communication network. Also disclosed is a related network equipment, a trust management system, a computer-readable medium, and a computer program.

[0004] BACKGROUND

[0005] Trusted computing can be used to improve security of Internet services running on remote (e.g., cloud) infrastructure. With trusted computing, a computing node will consistently behave in ways expected by the user. Moreover, those behaviors will be enforced by hardware and software, such as by loading the hardware with a unique encryption key inaccessible to the rest of the computing infrastructure. Trusted computing can also protect user information from owners of cloud infrastructure. For example, it can be advantageous that an infrastructure owner has no “super-powers” to observe, measure, etc. the user processes that are executing on the constituent computing machines.

[0006] Trust management (TM) involves managing all aspects of “trust” in an environment, including defining a standard for “trust”, identifying involved entities and / or parties, calculating trust scores, trust propagations and / or aggregations, and decision-making based on trust calculations. Continuous trust evaluation is defined as one of the tenets in the Zero Trust Architecture defined in National Institute of Standards and Technology (NIST) Special Publication 800-207.

[0007] In general, a trust management system observes behaviors of entities (or assets) in an environment, such as nodes, network functions (NFs), services, applications, interfaces, etc., including their compliance with policies, procedures, processes, and expected behaviors. Based on these observations, the trust management system calculates trust scores and assigns them to the involved entities. Put differently, the assets’ relevant contextual information is used to calculate and assign “trust scores” indicating the trustworthiness of each asset, e.g., in terms of reliability, security, and / or dependability. Based on the respective trust scores, trusted relationships be built among trusted assets and untrusted assets can be identified for appropriate actions to be taken.

[0008] In general, an entity’s context-awareness is its capability to consider the environment in which it is situated including surrounding entities, interfaces, policies, and configurations - particularly those that influence the entity’s behavior and results produced. A context-aware entity collects contextual information about its environment and reacts accordingly.

[0009] Trust management approaches can be categorized as centralized or decentralized (or distributed). In centralized trust management, a single entity collects contextual information from other entities and performs the trust evaluations. In decentralized trust management, the respective entities collect relevant contextual data for their own evaluations of trustworthiness of other entities they interact with. However, if an entity in a decentralized trust management system is compromised, this entity’s trust evaluations may be malicious and cannot be trusted.

[0010] SUMMARY

[0011] While trust management has conventionally been applied to computing environments, it is also desirable to apply trust management in communication networks. However, there are various problems, issues, and / or drawbacks with using conventional trust management techniques in this application. For example, it is unclear what contextual information should be collected / used to facilitate trust management, such as in a radio access network (RAN). As another example, it is unclear how to determine whether entities in a communication network are trustworthy, e.g., how to determine a trust score for network entities, threshold trust levels, etc. As another example, it is unclear what actions should be taken when a network entity’s trust score falls below a threshold trust level.

[0012] An object of embodiments of the disclosure is to enable the improved security of entities in a communication network.

[0013] Some embodiments include methods (e.g., procedures) performed by trust management system associated with a communication network (e.g., 5G network).

[0014] These exemplary methods include, for each of a plurality of contexts of a NF of the communication network, determining one or more metrics representative of trustworthiness of the context. These exemplary methods also include determining a context trust score for each context, based on the one or more metrics representative of trustworthiness of the context. These exemplary methods also include determining a current NF trust score based on the plurality of context trust scores. These exemplary methods also include determining a context-specific action for at least one context of the NF, based on the current NF trust score and a current value of a configurable trust threshold for the NF.

[0015] In some embodiments, the plurality of contexts include an asset context and a plurality of services contexts. In some of these embodiments, the plurality of services contexts include a 3GPP services context and a non-3GPP services context.

[0016] In some embodiments, determining the context-specific action includes the following operations:

[0017] • determining that the NF is no longer trustworthy based on one or more of the following being less than the current value of the configurable trust threshold: the current NF trust score, and one or more historical NF trust scores for the NF; and • determining the context-specific action needed to return the NF to being trustworthy.

[0018] In some embodiments, these exemplary methods also include determining the current value of the configurable trust threshold for the NF based on one or more of the following:

[0019] • one or more previous values of the configurable trust threshold for the NF;

[0020] • mean time to detect (MTTD) a security -related failure in the NF;

[0021] • mean time to recover (MTTR) from a security -related failure in the NF;

[0022] • risk of data loss or reputation damage from a security -related failure in the NF;

[0023] • one or more NF performance requirements;

[0024] • one or more service level agreements (SLAs) for services provided by the NF; and

[0025] • prioritization of NF performance versus NF security.

[0026] In some embodiments, determining the one or more metrics representative of trustworthiness of each of the plurality of contexts of the NF includes the following operations:

[0027] • collecting unstructured data representative of security -related characteristics of the NF;

[0028] • deriving numerical values from the unstructured data and associating each of the numerical values with one or more of the contexts of the NF; and

[0029] • for each context of the NF, determining the one or more metrics based on the associated numerical values.

[0030] In some embodiments, the determined context-specific action includes one or more of the following:

[0031] • instantiate a honeypot that isolates an attacker of one of the contexts, without impact to resources of the context;

[0032] • initiate a patch or update for software used to implement one of the contexts indicated to be vulnerable based on the context trust score;

[0033] • select a less secure encryption algorithm to be used in one of the contexts, based on a tradeoff between the current NF trust score and a performance requirement of one or more of the following: the NF, and the context.

[0034] Other embodiments include trust management systems (or network equipment configured to implement such systems) that are configured to perform operations corresponding to any of the exemplary methods described herein, such as by utilizing various circuitry and / or functional modules. Other embodiments include non-transitory, computer-readable media storing program instructions that, when executed by processing circuitry, configure a trust management system to perform operations corresponding to any of the exemplary methods described herein.

[0035] These and other embodiments described herein may provide various benefits and / or advantages, especially when compared to conventional trust management systems. For example, embodiments may be based on modular components, each with different functions, thereby facilitating flexible deployment according to requirements of the communication network. In addition to fully centralized deployments, embodiments may facilitate hybrid deployments in which some components are distributed and others are centralized (e.g., in a security orchestrator). This modularity enables each component to have its own automation control loop, thus decreasing the time to detect and respond to an event (e.g., attack) that reduces trustworthiness.

[0036] These and other objects, features, and advantages of embodiments of the present disclosure will become apparent upon reading the following Detailed Description in view of the Drawings briefly described below.

[0037] BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figures 1-2 show two high-level views of an exemplary 5G / NR network architecture.

[0039] Figure 3 shows a logical architecture for an NG-RAN node arranged in a split CU / DU architecture.

[0040] Figure 4 shows a high-level diagram of an Open RAN (O-RAN) architecture.

[0041] Figure 5 shows an exemplary Trust Knowledge-Based module (TrKB) module, according to some embodiments of the present disclosure.

[0042] Figures 6-9 show various sub-graphs that may be used by the TrKB module of Figure 5, according to some embodiments of the present disclosure.

[0043] Figure 10 illustrates operation of a Data Collection module (DC), according to some embodiments of the present disclosure.

[0044] Figure 11 shows an exemplary tree or graph structure representing contexts, metrics, and measures as attributes of a NF, according to some embodiments of the present disclosure.

[0045] Figure 12 shows an example implementation of a Decision Making module (DM), according to some embodiments of the present disclosure.

[0046] Figures 13A-B show a signaling diagram that illustrates interactions between modules of the trust management system according to some embodiments of the present disclosure.

[0047] Figures 14-15 illustrates a centralized and distributed implementations, respectively, of a trust management system according to some embodiments of the present disclosure.

[0048] Figures 16-17 illustrates a centralized and distributed implementations, respectively, of a trust management system in an O-RAN architecture, according to some embodiments of the present disclosure.

[0049] Figure 18 shows an exemplary method (e.g., procedure) for a trust management system, according to some embodiments of the present disclosure. Figure 19 shows a communication system according to some embodiments of the present disclosure.

[0050] Figure 20 shows a network node according to some embodiments of the present disclosure.

[0051] Figure 21 shows host computing system according to some embodiments of the present disclosure.

[0052] Figure 22 shows a virtualization environment in which functions implemented by some embodiments of the present disclosure may be virtualized.

[0053] DETAILED DESCRIPTION

[0054] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0055] In general, all terms used herein are to be interpreted according to their ordinary meaning to a person of ordinary skill in the relevant technical field, unless a different meaning is expressly defined and / or implied from the context of use. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise or clearly implied from the context of use. The operations of any methods and / or procedures disclosed herein do not have to be performed in the exact order disclosed, unless an operation is explicitly described as following or preceding another operation and / or where it is implicit that an operation must follow or precede another operation. Any feature of any embodiment disclosed herein can apply to any other disclosed embodiment, as appropriate. Likewise, any advantage of any embodiment described herein can apply to any other disclosed embodiment, as appropriate.

[0056] The term “radio access network node” (shortened to “RAN node”) used herein may refer to any node in a radio access network (RAN) that wirelessly transmits and / or receives signals, and / or facilitates such transmission and / or reception. Some examples of a RAN node include, but are not limited to, a base station (e.g., high-power, low-power, macro, micro, femto, home, etc.), a gNB in a 5G / NR NG-RAN, an eNB in a 4G / LTE E-UTRAN, base station distributed components (e.g., CU and DU), an integrated access backhaul (IAB) node, a transmission point (TP), a transmission reception point (TRP), a remote radio unit (e.g., RRU, RRH), a relay node, an Open-RAN (O-RAN) node or function, etc.

[0057] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is generally used. However, the concepts disclosed herein are not limited to a 3GPP system, and can be applied in any system that can benefit from the concepts, principles, and / or embodiments described herein.

[0058] Figure 1 illustrates a high-level view of an exemplary 5G network architecture, which includes a Next Generation Radio Access Network (NG-RAN, 199) and a 5G Core (5GC, 198). The NG-RAN can include one or more gNodeB’s (gNBs, e.g., 100, 150) connected to the 5GC via one or more NG interfaces (e.g., 102, 152). More specifically, the gNBs can be connected to one or more Access and Mobility Management Functions (AMFs) in the 5GC via respective NG- C interfaces and to one or more User Plane Functions (UPFs) in the 5GC via respective NG-U interfaces. Various other network functions (NFs) can be included in the 5GC, as described in more detail below.

[0059] In addition, the gNBs can be connected to each other via one or more Xn interfaces (e.g., 140 between gNBs 100, 150). The radio technology for the NG-RAN is often referred to as “New Radio” (NR). With respect to the NR interface to UEs, each of the gNBs can support frequency division duplexing (FDD), time division duplexing (TDD), or a combination thereof. Each of the gNBs can serve a geographic coverage area including one or more cells and, in some cases, can also use various directional beams to provide coverage in the respective cells.

[0060] NG RAN logical nodes shown in Figure 1 include a Centralized Unit (CU or gNB-CU) and one or more Distributed Units (DU or gNB-DU). CUs (e.g., 110) are logical nodes that host higher-layer protocols and perform various gNB functions such controlling the operation of DUs. In contrast, DUs (e.g, 120, 130) are decentralized logical nodes that host lower layer protocols and can include various subsets of gNB functions, depending on the functional split. A CU connects to one or more DUs over respective Fl logical interfaces (e.g., 122, 132 in Figure 1).

[0061] Figure 2 shows another high-level view of an exemplary 5G network architecture, including an NG-RAN (299) and a 5GC (298). As shown in the figure, the NG-RAN can include gNBs (e.g, 210a,b) and ng-eNBs (e.g, 220a, b) that are interconnected with each other via respective Xn interfaces. An ng-eNB is similar to a fourth generation (4G) Long-Term Evolution (LTE) eNB, except that it supports the Xn and NG interfaces rather than corresponding X2 and SI interfaces.

[0062] The gNBs and ng-eNBs are also connected via the NG interfaces to the 5GC, more specifically to AMFs ( e.g, 230a, b) via respective NG-C interfaces and to UPFs (e.g, 240a, b) via respective NG-U interfaces. Moreover, the AMFs can communicate with one or more policy control functions (PCFs, e.g., 250a, b) and network exposure functions (NEFs, e.g., 260a, b).

[0063] Each of the gNBs can support the NR radio interface including frequency division duplexing (FDD), time division duplexing (TDD), or a combination thereof. Each of ng-eNBs can support the 4G / LTE radio interface. Each of the gNBs and ng-eNBs can serve a geographic coverage area including one or more cells (e.g., 211a-b and 221a-b). Depending on the cell in which it is located, UEs (e.g., 205) can communicate with the gNB or ng-eNB serving that cell via the NR or LTE radio interface, respectively. Although Figure 2 shows gNBs and ng-eNBs separately, it is also possible that a single NG-RAN node provides both LTE and NR functionality.

[0064] Figure 3 shows a logical architecture for an NG-RAN node (e.g., gNB or ng-eNB) arranged in the split CU / DU architecture, such as gNBs and ng-eNBs shown in Figures 1-2. This logical architecture separates the CU into CP and UP functionality, called CU-CP and CU-UP respectively. Furthermore, each of the NG, Xn, and Fl interfaces is split into a CP interface (e.g., NG-C) and a UP interface (e.g., NG-U). Moreover, CU-UP and CU-CP can communicate via an El interface. Each DU may be connected to only one CU-CP, and each CU-UP may be connected to only one CU-CP. However, a single DU may be connected to multiple CU-UPs under the control of the same CU-CP, or a single CU-UP may be connected to multiple DUs under the control of the same CU-CP. Note that the terms “Central Entity” and “Distributed Entity” in Figure 4 refer to physical network nodes.

[0065] Open RAN (O-RAN) ALLIANCE is a community of mobile operators and RAN vendors working towards an open, intelligent, virtualized, operationally efficient, and fully interoperable RANs. To achieve these goals, the community has defined an O-RAN architecture with key functions and interfaces. Various specifications published by O-RAN work groups (WGs). For example, O-RAN WG1 is concerned with use cases and overall architecture. One general principle is that O-RAN architecture and interface specifications shall be consistent with 3 GPP architecture and interface specifications, to the extent possible.

[0066] Figure 4 shows an exemplary O-RAN architecture in which various embodiments can be implemented. Al, 01, and 02 interfaces connect the Service Management and Orchestration function (SMO, 410) to O-RAN network functions (NFs) and cloud infrastructure management (O-Cloud, 460). These O-RAN NFs include Near-Real Time RAN Intelligent Controller (RIC, 420), Open Centralized Units (O-CUs, 430), Open Distributed Units (O-DUs, 440), and Open Radio Units (O-RUs, 450). Additionally, there is an interface between SMO and external information sources.

[0067] The O-RAN Architecture also includes the following three control loops with respective latencies:

[0068] • Real Time (RT) Control Loop (<10 ms), typically in O-RU / O-DU;

[0069] • Near-RT RIC Control Loop (10-1000 ms), in Near-RT RIC; and

[0070] • Non-RT RIC Control Loop (>1000 ms), shown as sub-block 412 in SMO. Use cases for Non-RT RIC and Near-RT RIC control loops are fully defined by O-RAN, but O- RAN only defines relevant interactions with other O-RAN nodes or functions for the RT control loop (which performs radio scheduling, HARQ, beamforming, etc.).

[0071] The Non-RT RIC provides the Al interface to the Near-RT RIC. One task of Non-RT RIC is to provide policy-based guidance, ML model management, and enrichment information to support intelligent RAN optimization by the Near-RT RIC (e.g., for radio resource management, RRM). The Non-RT RIC can also perform intelligent RRM in longer, non-RT intervals (e.g., greater than 1 second).

[0072] The Non-RT RIC can use data analytics and ML model training / inference to determine RAN optimizations, for which it can leverage SMO services such as data collection from and provisioning to the O-RAN nodes. These actions are performed by Non-RT RIC RAN Applications (rApps, e.g., 411), which are exposed to Non-RT RIC functionality and services via the R1 interface in SMO.

[0073] As mentioned above, it is desirable to apply trust management in communication networks, such as the communication networks shown in Figures 1-4. However, there are various problems, issues, and / or drawbacks with using conventional trust management techniques in this application.

[0074] For example, it is unclear what contextual information should be collected / used to facilitate trust management, such as in a RAN. One problem of existing techniques is the limited definition of context, which is limited to location aspects (e.g., IP address, geographic location), identifier of a requesting resource, and roles / permissions. Additionally, the paper “Trust Management Framework for Containerized Workloads Applications to 5G Networks'” by Miloudi, et al. also defines some context parameters for trust management for Kubemetes computing clusters used for 5G networks.

[0075] Even so, context information used in these existing techniques is insufficient to adequately describe context of an asset in a communication network. Other aspects that can / should be considered include changes in configuration, deployed security controls, criticality of an asset, new emerging threats, topology, and running services - not only Kubemetes-based services but also existing (non-Kubemetes) 3GPP services. Due to the dynamic and distributed nature of complex communication networks, granular and non-intrusive actions are required, which in turn require more granular / detailed asset context.

[0076] Furthermore, existing trust management systems are neither environment-agnostic nor modular, such that there is limited flexibility in where and how to deploy them. Instead, it is desirable to have a modularized, component-based trust management system that provides increased flexibility in deciding how and where the respective components are deployed. As another example, in existing trust management systems, trust level thresholds used to determine whether an entity is trusted are static and do not adapt to changes that affect security and / or reliability characteristics of an entity. Instead, it is desirable to have adaptive trust level thresholds that considers environmental changes that affect security and / or reliability characteristics of an entity subject to a trust evaluation.

[0077] As another example, existing trust management systems calculate trust scores based on individual metric and in specific circumstances. For example, in U.S. Pat. 11,012,313, trust scores are calculated based on network performance results when a network policy has been applied. As such, this technique is unable to produce an accurate trust score that captures the various security aspects of the environment. Instead, the calculated trust score may hide useful underlying information that would more accurately reflect the asset’s security state in a trust score.

[0078] As another example, existing trust management systems do not provide response actions / decisions that are context dependent. An asset can require different actions in different contexts. For example, it may undesirable to completely remove an asset that provides critical services. Instead, if the asset was determined to be untrustworthy in a specific context, a response action is applied to that specific context to improve the trust score of the overall asset, without disrupting the critical services provided by the asset.

[0079] Embodiments of the present disclosure address these and other problems, issues, and / or difficulties by a context-aware trust management system for communication networks that is based on various components (or modules) that interact with each other. Embodiments can be utilized in various domains of a communication network, such as RAN, Core Network (CN), IP multimedia system (IMS), etc. Moreover, embodiments can be utilized for various network technology generations, including 4G, 5G, and subsequent generations.

[0080] Embodiments specify or define the contexts of various network functions (NFs) of a communication network, as well as the associated trust score metrics determined based on those contexts. Embodiments may utilize knowledge bases to continuously gain extensive insights about the environment to accurately produce trust scores for the entities being evaluated. In some embodiments, the insights stored in these knowledge bases can also be used to determine dynamic trust level thresholds.

[0081] Embodiments may also store historical trust scores for various NFs, which can be used to determine trust score trends. These trends may influence the specific type of action to be applied by the responsible system component or module.

[0082] In other words, various embodiments of the trust management system continuously evaluate various entities (e.g., NFs) of the communication network and the respective environments of these entities, based on which the system evaluates or determines trust (or trustworthiness) of the respective entities. For example, the trust management system correlates a calculated trust score with an identified context of an entity to make an appropriate contextbased decision. In addition, embodiments may be based on modular components that facilitate flexible, environment-agnostic deployments.

[0083] Embodiments can provide various benefits and / or advantages, especially when compared to conventional trust management systems. For example, embodiments can be based on modular components, each with different functions, enabling flexible deployment according to the requirements of the communication network. In addition to fully centralized deployments, embodiments facilitate hybrid deployments in which some components are distributed and others are centralized (e.g., in a security orchestrator). This modularity enables each component to have its own automation control loop, thus decreasing the time to detect and respond to an event (e.g., attack) that reduces trustworthiness.

[0084] The following description of various embodiments is generally based on “cloud RAN” and O-RAN architectures and terminology. Even so, skilled persons will recognize that embodiments can be deployed in other RAN architectures, such as conventional eNB / gNB / ng-eNB configurations (e.g., Figures 1-2). Moreover, embodiments can also be deployed in other network domains such as CN, transport, IMS, and / or management. Additionally, embodiments are not restricted to any particular 3GPP (or other) technology generation.

[0085] Embodiments will now be described in more detail. As mentioned above, embodiments utilize “contexts” of an entity (e.g., NF) to determine trust scores for the entity. Different contexts for an entity may correspond to different subsets of the entity’s functionality. In general, contexts of interest in the present disclosure include asset context and service context. In general, “asset” refers to a physical entity or computing platform such as a worker node, a Kubemetes pod, a gNB computing platform, an eNB computing platform, etc. An “asset context” refers to the asset’s environment and the state of the asset within that environment.

[0086] For example, a RAN NF (e.g., gNB / eNB computing platform) in a cloud-native environment consists of worker nodes, pods (e.g., Kubemetes) deployed within these worker nodes, etc. Each of these can be considered as part of the asset context, thereby providing a more granular view of the RAN NF in relation to the environment, rather than merely an overview.

[0087] The term “services” can be further divided into 3GPP services and non-3GPP services. 3GPP services are the 3GPP defined functionality and procedures that occur over 3GPP defined interfaces, such as Fl, Uu, N2, N3 , etc.. Non-3GPP services are all other services, i.e., that are not used or defined by 3GPP. Examples of non-3GPP services include management services such as certificate management, logging, backup, authentication, authorization, configuration management, performance management, etc. A “service context” refers to the service’s environment and the state of the service within that environment.

[0088] Considering the RAN NF example above, it can have a 3GPP services context related to the 3GPP-defined interfaces (such as Fl, El, NG, Xn, etc. procedures) as well as a non-3GPP services context for services such as certificate management, logging, backup, authentication, authorization, configuration management, performance management, etc. If the RAN NF has a vulnerability related to its Fl interface, this will manifest itself in the 3GPP-services context.

[0089] Based on individual asset or service contexts, embodiments evaluate trust of each context associated with a network function, such that at any point in time, some contexts (e.g., for 3GPP services) may be trusted while the other contexts (e.g., for non-3GPP services) may be untrusted. Moreover, the individual contexts facilitate granular decision making and actions that impact individual parts (or aspects) of a network function, such that other parts with trusted contexts may continue to operate as needed.

[0090] Some embodiments of the trust management system include a Trust Knowledge-Base (TrKB) module. In general, knowledge-based systems use knowledge graphs and an inference engine (e.g., based on machine learning or machine reasoning models) to solve problems that usually require significant specialized human expertise. Knowledge graphs represent complex relationships in a structured manner, so that crucial insights can be inferred. Knowledge graphs applied to solve trust management are a novel aspect of embodiments of the present disclosure.

[0091] Figure 5 shows an exemplary Trust Knowledge-Based module (TrKB, 520) that obtains data from external services (580) and observes the contexts of various RAN network functions (570), according to some embodiments of the present disclosure. TrKB is based on several subgraphs that are stored in a graph database (521) and are input to an inference engine (522). Some example sub-graphs are discussed below.

[0092] In some embodiments, TrKB can include a security metric sub-graph that represents the calculated security metrics for trust management. Figure 6 shows an example security metric subgraph, according to some embodiments of the present disclosure. The nodes of this graph represent network function, service, and security metric score, with each service and network function having a property representation of its metric. The edges between nodes define relationship between the nodes and each other. The security metrics can be used to calculate the trust score of a service in a network function.

[0093] Below are some examples of the relationships shown in Figure 6:

[0094] • (Network Function, hasServiceContext, Service)

[0095] • (Service, hasMetric, Security Metric)

[0096] • (Security Metric, hasMetricScore, Security Metric score) • (Trust Score, calculatedBy, {Security Metric score 1, Security Metric score 2, Security Metric score 3})

[0097] Some example security metrics of the service include vulnerability level, attack surface level, defense mechanisms effectiveness, and entire security state. A more specific example of the relationships shown in Figure 6is given below:

[0098] • (CU-UP network function A, hasServiceContext, 3GPP-F1U)

[0099] • (3GPP-F1U, hasMetric, SW Vulnerability);

[0100] • (SW Vulnerability, hasMetricScore, 0.8).

[0101] From this defined relationship in the knowledge base, it can be inferred that the 3GPP F1U service on the CU-UP network function A has a SW vulnerability score of 0.8.

[0102] In some embodiments, TrKB can include a topology sub-graph that represents the logical topology of the network functions in a network or sub-network. Figure 7 shows an example topology sub-graph, according to some embodiments of the present disclosure. The graph represents network function deployment type (e.g., cloud based or purpose built), which cluster or tracking area it serves, etc. Edges can be used to model communication between different network functions. Below are some examples of the relationships shown in Figure 7:

[0103] • (network function A, communicatesWith, network function B)

[0104] • (network function A, deployedAs, purpose built)

[0105] • (network function A, servingArea, TA1234)

[0106] In some embodiments, TrKB can include a trustworthiness sub-graph that represents the trustworthiness of a network function in the context of its services. Figure 8 shows an example trustworthiness sub-graph, according to some embodiments of the present disclosure. The graph represents the network function and its services, along with the required confidence level that will act as thresholds to compare against during trust score evaluation. Additionally, the graph holds the current computed score of a service along with the historical trust scores that track evolution of the trustworthiness. The edges between nodes are defined with predicates, were it results into a relationship between the nodes and each other.

[0107] Below are some examples of relationships shown in Figure 8:

[0108] • (Network function A, hasService, O&M-Authentication-NFA)

[0109] • (O&M-Authentication-NFA, hasConfidenceLevel, 0.8)

[0110] • (O&M-Authentication-NFA, hasTrustScore, 0.6)

[0111] • (O&M-Authentication-NFA, hasAvgScore, 0.75)

[0112] In some embodiments, TrKB can include a response sub-graph that represents the response actions and their type that were actuated on a specific service in a network function or the network function as whole. Figure 9 shows an example response sub-graph, according to some embodiments of the present disclosure. This graph holds knowledge about a response action that was a result of decision making. Example response actions include patch a vulnerability, change configuration, drop a session, instantiate a honeypot, etc. For example, “instantiating a honeypot” refers to redirecting a detected attacker to a system - the “honeypot” - that represents a copy of the environment under attack in order to deceive and isolate the attacker.

[0113] Moreover, the graph also indicates the type of security control (if any) that was triggered due to the decision-making, such as adding a firewall rule, creating a seccomp profile, adding a new authorization role, etc. The graph also indicates trust score impact of the response action, i.e., increase / decrease / no change of the trust score after the response action was applied.

[0114] Below are some examples of relationships shown in Figure 9:

[0115] • (Network function A, hasService, O&M-Authentication-NFA)

[0116] • (Drop Session, appliedTo, O&M-Authentication-NFA)

[0117] • (O&M-Authentication-NFA, hasTrustlmpact, +0.06)

[0118] The sub-graphs can be used individually or collectively depending on the automation logic and what type of information should be retrieved. TrKB facilitates dynamically changing trust evaluation that adapts according to the state of the evaluated network function. TrKB includes two main functionalities that facilitate these operations.

[0119] First, TrKB ingests and stores relevant information from the network. In order to calculate trust score and evaluate trust states of the network functions individually and collectively, different types of information need to be ingested and used to adaptively updated (e.g., by inference) trust thresholds. Some examples of ingested and stored information include historical trust scores of the NFs, security metrics and KPIs reported by the NFs, new security and confidence level requirements, new network cost requirements, a representation of network topology and communication between NFs and services, etc.. This ingested information can be stored in the sub-graphs discussed above.

[0120] To collect information, TrKB interacts with various entities within the domain of interest, such as RAN, as well as possibly other domains (e.g., CN, transport, etc.). The specific information collected and the entities providing such information depends on the specific implementation of TrKB, as explained below.

[0121] In some embodiments, TrKB can be implemented as part of a RAN NF, where it has a contextual view of the RAN NF’s local environment. In this case, TrKB may ingest local data such as security state metrics and KPIs, service graphs, topology, security controls evaluation, threat landscape, etc.. In other embodiments, TrKB can be implemented in a centralized security orchestrator. In addition to the local information discussed above, TrKB can collect more global information such as high level security requirements, requirements from other domains, cost requirements, risk assessment results, etc.

[0122] Second, TrKB infers relationships based on the collected data, whether local or global. For example, this inference can use artificial intelligence (AI) / machine learning (ML) algorithms, such as graph neural networks (GNNs) based on the previously described graph models. The collected data is used by the inference engine to infer relationships between nodes in the graph models, to generate new information needed for trust calculations, and prediction of a trust state of a NF under evaluation.

[0123] Since TrKB holds data (“facts”) about the trustworthiness of the network functions and their services, embodiments of the trust management system can also be viewed as a “reasoning system” that draw conclusions from these facts using logical programming techniques such as deduction and induction. In other words, TrKB draws conclusions about the trustworthiness of network functions and their services from the data and observations (e.g., metrics, KPIs, etc.) ingested from the environment.

[0124] As such, embodiments of the trust management system can use machine reasoning (MR) technique, which unlike ML techniques do not require large amounts of data for training. Instead, MR relies on the data stored in the TrKB as graph models. One example of MR logic is continuously determining which trust metrics negatively impact the trust score of a service. This goal can be represented by the following logic rule using predicate (i.e., first-order) logic: x: SecurityMetric(x) A hasMetricScore LessThan(fi(0.5)

[0125] The above rule provides that when a security metric (x) has an average score less than (0.5), it has a possible negative impact on the overall trust score and require more attention.

[0126] Some embodiments of the trust management system include a Data Collection module (DC), which is responsible for collecting the required data in unstructured format, and processing / analyzing it to create a structured, labelled, and analyzed dataset that can be used to calculate the trust metrics. Figure 10 illustrates operation of a DC module according to some embodiments of the present disclosure. In this example, DC is represented as a pipeline with data ingestion, data labelling, analysis, and output stages.

[0127] The ingested unstructured data could be NF configuration information, available software libraries and packages, network information, interface information, information about active services, etc. The unstructured data either can be pulled periodically from the network functions or pushed by the network functions upon an event-based trigger. For instance, one possible event is availability in a network function of new data relevant to a trust metric. As mentioned above, DC is responsible for processing the collected data, such as by structuring the data so it can be accurately labelled using pre-defined context tags (e.g., 3GPP service, non-3GPP service, asset, etc.). In this manner, the data labelling produces structured and labelled data correlated to pre-defined contexts..

[0128] In addition, DC also analyzes the structured data to extract meaningful information, such as numerical values associated with the respective context. Examples of numerical values could be the number of connected NFs, ratio between updated and non-updated software libraries, number of vulnerable software libraries, etc. These numerical values can be inputs to the trust metric calculations.

[0129] In some cases, the structured data is not in the form of numerical values needed for trust metric calculation, such as event lists, logs, or configuration information. In such case, the DC module processes to generate a relevant numerical value. For example, number of NFs connected to a NF of interest is not inherently available but must be derived from the NF’s configuration file to produce a numerical value representing number of connected NFs. This numerical value will be associated with one or more relevant NF contexts, e.g., asset and / or 3GPP services contexts. The relevant contexts (e.g., service or underlying asset) are readily apparent from the event lists, logs, or configuration information. Thus, DC maps the context to the numerical values, or vice versa.

[0130] As a more specific example, DC ingests information about which versions of a library are used within different NFs and determines which libraries are up-to-date and which are out-of-date, further producing a fraction of the total libraries that are up-to-date. This information can then be an input to calculate the ratio of vulnerable software libraries on the system.

[0131] Finally, DC outputs structured, labelled data that have measures assigned to each context of the NF. Note that the DC module can be implemented as part of a network function (e.g., gNB, vCU, CU-CP, vDU, MME, etc.) or in a centralized location such as a security orchestrator, SMO in O-RAN (i.e., rApp), etc.

[0132] Some embodiments of the trust management system include a trust metrics calculation (TrMC) module, which calculates trust-related metrics that can be technical metrics, business metrics, or a combination thereof. TrMC can be implemented as part of a network function (e.g., gNB, vCU, CU-CP, vDU, MME, etc..) or in a centralized location such as a security orchestrator, SMO in O-RAN (i.e., rApp), etc.

[0133] Example technical metrics include various security metrics, which can provide situational awareness of a resource for a specific context. The numerical values of the calculated metrics will be used, with other information, by the trust evaluation algorithm to produce a trust score. Some example security metrics that can be used to evaluate trust include the following: 1. Vulnerability metric, which provides an understanding of existing vulnerabilities and their impact on vulnerability to various attacks and, thus, the NF’s trustworthiness. This metric may also be broken into multiple sub-metrics for types of vulnerabilities, such as software vulnerabilities, 3GPP protocol vulnerabilities, and configuration vulnerabilities, etc. Information used to calculate this metric may include number of known vulnerabilities within the NF, number of high and critical vulnerabilities, rate of patching vulnerabilities, etc.

[0134] 2. Attacks and compromises metric, which provides an understanding how susceptible a system is to possible attacks and compromises for which there are no controls to mitigate. Information used to calculate this metric may include number of security incidents, number of suspicious user account behaviors, number of true positive security incidents, ratio of true positive security incidents to total security incidents., etc.

[0135] 3. Attack surface metric, which provides an understanding of NF exposure and, thus, susceptibility to threats. Attack surface changes can be a result of adding new software, libraries, and / or services, or a change to topology, configuration, etc. Information used to calculate this metric may include number of NFs being communicated with, number of attack paths, etc.

[0136] 4. Hardening and compliance coverage metric, which provides an understanding how well a system is hardened against, and thus less susceptible to, attacks. Information used to calculate this metric may include ratio of patched systems, number of users with admin privilege, kernel version, Kubemetes controller version, operating system (OS) version, etc.

[0137] Some illustrative examples of trust metric calculations are given below.

[0138] For example, an attacks and compromise (AC) trust metric can be calculated as: where m represents the total number of sub-metrics used to calculate the metric and AC^et represents the value of the ithAC sub-metric used. A more specific example calculation is:

[0139] # of security events + # of true positives + # of loC

[0140] 3

[0141] Where “loC” standards for indicators of compromise found in the NF.

[0142] As another example, a hardening and compliance coverage (HC) trust metric can be calculated based on a sub-metric of the ratio of non-compliant configuration and settings with respect to benchmarks (e.g., CIS), denoted by RNCand represented as: where c represents the number of configurations available that are being benchmarked, NC, represents the ithconfiguration that is not compliant, and Tcis the total number of configurations available to test.

[0143] Additionally, the HC trust metric can be calculated based on a sub-metric of the ratio of patched systems, denoted by RPand given by: where v represents the number of vulnerabilities detected in a network function, NPj represents the ithvulnerability that has been patched, and Tvis the total number of vulnerabilities detected in a network function. Given these and possibly other sub-metrics, the HC trust metric can be calculated as:

[0144] Where m represents the total number of sub-metrics used to calculate the HC metric and represents the value of the ithsub-metric.

[0145] Some embodiments of the trust management system include a trust level requirements (TrLRQMT) module, which provides reference values (e.g., thresholds) for interpretation of trust metrics produced by the TrMC module. In other words, based on a relation between a calculated trust metric and a relevant threshold, a determination is made whether a resource is trustworthy and, if not, what if any actions are needed.

[0146] For example, a trust threshold may represent one or more requirements defined for a network function. The trust threshold can be set manually and statically (e.g., based on human intervention and expertise) or it can be set automatically and dynamically according to changes in requirements given to the trust management system. Some requirements that can be used to adjust a trust threshold may include the following:

[0147] • failure-related metrics and KPIs such as mean-time-to-detect (MTTD), mean-time-to- recover (MTTR).

[0148] • performance requirements (e.g., latency, throughput, etc.) such as from service level agreements (SLAs);

[0149] • risk-related factors such as cost of data loss, reputation damage, etc.

[0150] • historical trust scores of a network function. The information and requirements and data used to update trust thresholds can be stored in TrKB, with updated information retrieved by the trust level requirements module as needed or available for the various contexts for the network functions within the communication network. For example, the trust level requirements module can use model-based AI / ML or similar techniques to continuously infer and recommend the new trust thresholds to be assigned for each NF. In general, the trust level requirements module can be implemented in a centralized location such as a security orchestrator, SMO in O-RAN (i.e. , rApp), etc.

[0151] In some embodiments, a trust threshold may be updated manually by a domain expert that monitors and analyzes the different trust requirements for the network functions in the network. The expert can then update the relevant knowledge object (e.g., RequiredConfidenceLevel) in the corresponding knowledge graph (e.g., trustworthiness sub-graph).

[0152] In other embodiments, a trust threshold may be updated automatically based on an average of historical trust scores over some period of time. For example, a trust threshold can be calculated as the average of all relevant trust scores in the most recent daily period, such as: where the trust threshold is denoted as TSReqis the determined trust threshold, TStis the Ithelement of a historical (i.e., most recent day) trust score vector , and Nsis the total number of elements from the historical rust score vector used in the calculation.

[0153] In other embodiments, a trust threshold may be updated automatically based on using machine learning (ML), such as by using a linear regression model to predict the appropriate trust threshold for a NF (or context thereof). The model output is the predicted trust threshold and the model input is the features used for training and prediction. In its simplest form a linear regression model is given by: fw,b = wx+b, where x is the feature vector, w is the feature coefficient vector, b is the x-intercept, and fw,b is the predicted trust threshold. In general, this is a multi-feature problem where multiple input features are used to predict the output.

[0154] The following are some examples of features that can have a direct impact on the precited trust threshold:

[0155] • Asset criticality (denoted o): a value in the range 0-1 that indicates the relative criticality of an asset relative to other assets (e.g., in same area or entire network). The more critical the asset, the more trustworthiness it requires. For example, assets in sensitive locations or that carry important subscriber information must be very trustworthy. Similarly, a service criticality metric with a value in the range 0-1 can be defined to indicate the relative criticality of a service provided by a NF relative to other services provided by the NF or by the communication network.

[0156] • Mean-time-to-recover (MTTR, denoted xi): a failure related metric represents a relative TTR of an asset from a failure, e.g., due to threat or attack. An NF with high MTTR must maintain trustworthiness to avoid any failures due to threats or attacks.

[0157] • Maximum historical trust score (denoted X2), e.g., over some relevant period. This represents how well a NF has fulfilled trust requirements historically, e.g., by having trust scores close to the relevant trust threshold. If the trust scores have historically been around some value, then the trust threshold may need to be adjusted to be closer to that value. Such an adjustment will prevent adding security controls and / or requirements that increase cost of implementation to achieve a trust threshold that maybe not realistic for a given NF.

[0158] Based on these example features, the regression model predicts the trust threshold as: fw,b = woxo+ WiXi + w2x2+ b

[0159] Some embodiments of the trust management system include a trust evaluation module (TrEval), which is responsible evaluating trust of network functions based on the metrics determined by the TrMC module in view of the thresholds determined by the TrLRQMT module. In some embodiments, trust is evaluated per context per network function.

[0160] The output from the trust evaluation module is a score that can be used by a decision making module (DM) to determine whether an action is needed and, if so, which action to take. DM can also use other data in making these determinations, such as relevant historical trust scores and relevant historical trust requirements (e.g., thresholds) from TrKB. Some illustrative examples of trust evaluation calculations are given below.

[0161] As a first example, the TrEval module may compute an average of all trust metrics determined by the TrMC module, such as discussed above. As a more specific example, the vulnerability metric reflect the degree to which the NF is vulnerable, such as a “1” indicating extremely vulnerable and a value of “0” indicating not vulnerable at all. The trust metrics that are associated with each context are preferably normalized to be in the range of [0, 1] prior to be used in the weighted average calculation. ) are collected and can be used as input to calculate an average to represent the NF’s trust level.

[0162] As a second example, the TrEval module may operate based on a tree or graph structure. In other words, each NF has contexts, metrics, and measures (or measurements) as attributes that can be represented as a graph such as the example shown in Figure 11. The measures may be numerical values produced by the DC module. Each trust metric may be calculated based on an average of all associated measures (i.e., numerical values), such as:

[0163] Trust scores for each context may be calculated by the TrEval module based on the relevant trust metrics for the context, such as:

[0164] Finally, a trust score for the entire NF may be calculated based on an average of the trust scores for the contexts, such as:

[0165] Skilled persons will recognize that the above calculations are similar to calculations in the first example above, but the tree representation provides a more complete understanding of the NF trust score, such as which features (or context) most impacted the NF trust score and thus should be prioritized for an action (i.e., by the DM module below) while avoiding actions that impact other features (or contexts) that remain trusted.

[0166] As mentioned above, TrEval also receives from TrLRQMT module a trust level threshold to be used for determining whether a NF (or context thereof) is trustworthy. If the average trust score calculated by TrEval satisfies the trust level threshold, then the NF (or context thereof) is considered trustworthy.

[0167] Consider the following illustrative example. Figure 11 shows the lowest trust metric for NFi is 0.32 in the “Context N” branch. Assume that this context is less critical than context 1, which has the second lowest trust metric of 0.49. For example, context N may be less critical than context 1 due to being related to performance optimization services, while context 1 is related to delivery of a critical service and its trust metric 2 (with 0.49 value) is related to vulnerabilities.

[0168] Assuming that TrEval determines that the overall trust score of 0.645 does not satisfy the relevant trust level threshold, context 1 should be prioritized for corrective action since this trust metric indicates it has one or more exploitable vulnerabilities that can have a detrimental effect on the critical service delivered to users. An example action by the DM module could be to patch software causing the vulnerabilities indicated by trust metric 2 of context 1, which would increase the overall trust score for NFi.

[0169] In some embodiments, DM includes a knowledge base (KB) and inference engine that uses MR to deduce decisions and / or response actions that should be actuated on a service of a network function or in the network function itself. Figure 12 shows an example implement of DM according to these embodiments. In these embodiments, the TrKB module (1220) includes a knowledge base (1221) and an inference engine (1222), as discussed above. The DM module (1260) includes its own knowledge base (1261), an inference engine (1262), and an actuation engine (1263). The DM’s KB includes a solution space of the possible responses and their characteristics. For example, a response can be “instantiate a honeypot” with characteristics “isolates an attacker” and “has no impact on resource”.

[0170] In this manner, DM produces decisions (e.g., no longer trustworthy) with recommended actions that can be actuated on the resources being evaluated, either automatically or via human intervention. As illustrated in Figure 12, the recommended actions are input to the actuation engine, which transforms them to automated scripts to be executed or to a notification for a human operator to make further review and / or take action.

[0171] For example, if the root cause of a low trust score for a service is a vulnerability metric score, a recommended action can be patching or updating the software for the vulnerable service, which may improve the score. Another possible recommended action is to isolate a specific service in a network function that has a severely low trust score, which is deemed to impact the rest of the network.

[0172] In some embodiments, DM’s KB shown in Figure 12 can be periodically synchronized with the response sub-graph in TrKB. In this manner, DM can obtain updated security controls or new actions that have been added by a human domain expert.

[0173] Figures 13A-B show a signaling diagram that illustrates interactions between modules of a trust management system (1399) during evaluation of trust for a particular network function (NF, 1370), according to some embodiments of the present disclosure. Although the operations in Figure 13 are given numerical labels, this is done to facilitate explanation rather than to imply any particular operational order, unless expressly stated otherwise.

[0174] In operation 1, the NF sends all relevant data needed by a Data Collection module (DC, 1310) including configuration information, metadata, interfaces available and utilized by the NF, services of the NF, etc. Alternately, this operation can be viewed as the DC module collecting the needed data from the NF. In operation 2a, DC analyzes and normalizes the unstructured data collected from the NF to produce numerical values (i.e., measurements), such as discussed above. In operation 2b, DC associates these measurements with existing contexts of the NF. In operation 2c, DC sends the resulting data (i.e., NF identifier (ID), associated contexts and measurements) to the Trust Metrics Calculation module (TrMC, 1340).

[0175] In operation 3a, TrMC derives trust metrics from the measurements (i.e., numerical values) provided by the DC module, and combines these derived trust metrics with the associated contexts. Some example calculations were discussed above. For example, the metrics may be numerical values aggregated from the measurements, and are associated with the respective contexts of the NF ID. In operation 3b, TrMC sends the combined data (i.e. NF ID, associated contexts, and metrics) to the Trust Evaluation module (TrEval, 1350). In operation 4, TrEval requests current trust thresholds for NF ID from the Trust Knowledge Base module. (TrKB, 1320). Note that the trust thresholds of NFs are generally dynamic. For example, trust thresholds may change based on changes in the environment, changes in NF configuration, changes in network topology, etc. As such, a previous trust threshold for NF ID may not reflect recent changes, so TrEval requests TrKB to provide up-to-date trust thresholds.

[0176] In operation 5, in response to the request, TrKB sends the NF ID and all relevant information associated with that NF ID to the Trust Level Requirements module (TrLRQMT, 1330). This information may include previous trust thresholds, security metrics, and KPIs as well as new security requirements of the NF ID, network cost requirements, topology, etc.

[0177] As discussed above, TrKB ingests and stores various information from the communication network, including the domain (e.g., RAN) that NF ID resides in as well as other domains. Based on this ingested information, TrKB’s inference engine determines whether NF security requirements (including for NF ID) have changed and need to be communicated to other modules.

[0178] In operation 6a, TrLRQMT utilizes the information from TrKB to initiate calculation of an updated trust threshold for NF ID. Some examples of this calculation were discussed above. In operation 6b, the updated trust threshold for NF ID is returned to TrKB, which stores it in association with NF ID. In this way, TrKB can maintain historical trust thresholds for each NF. TrKB also forwards the updated trust threshold for NF ID to TrEval in operation 6c.

[0179] In operation 7a, using the metrics received from TrMC in operation 3b and the updated trust threshold received in operation 6c, TrEval starts evaluating the trust of the NF ID to produce a current trust score. Some examples of this calculation were discussed above. In operation 7b, TrKB sends the historical trust scores of the NF ID that will be used by TrEval for further analysis. Note that it does not matter when TrEval receives the historical trust scores for NF ID, so as long as they are received before the comparison checks in operation 7d (below).

[0180] In operation 7c, once the trust evaluation by TrEval has produce a trust score associated with NF ID, this trust score is sent to TrKB, which then has the current and historical trust scores of NF ID. In operation 7d, TrEval performs comparison checks to see whether the current trust current and historical trust scores satisfy the current trust threshold for NF ID. For example, TrEval’s comparison checks of trust scores versus relevant trust thresholds can yield any of the following three outcomes:

[0181] 1. Current trust score > threshold, and historical trust scores > threshold;

[0182] 2. Current trust score = threshold, and historical trust scores = threshold; or

[0183] 3. Current trust score < threshold, and historical trust scores < threshold. In operation 7e, TrEval sends the comparison results to TrLRQMT. In operation 8a, TrLRQMT may increase, decrease, or mtaintain the trust threshold, based on the received comparison results. Some examples based on the three outcomes above are given below:

[0184] 1. Trust threshold can increase, so long as any additional security costs, network requirement costs, etc. are acceptable, since current and (at least a majority of) historical trust scores exceed the current trust threshold.

[0185] 2. Trust threshold is maintained since the comparison indicates that trust threshold is accurate based on the information provided by the TrKB module.

[0186] 3. Trust threshold can decrease as the current and historical trust scores all indicate that they cannot satisfy the current trust threshold. For instance, if the NF is deemed critical for the network to provide critical services, the network operator may prioritize the deployment and performance of the NF over security. In such case, the trust threshold should decrease, allowing the NF to avoid network disruptions at the expense of greater security risk.

[0187] In operation 8b, if any adjustments have been made to the trust threshold, the updated trust threshold is sent to TrKB.

[0188] In operation 9, TrKB associates all received information with NF ID and sends it to the Decision Making module (DM, 1360). In operation 10, DM analyses and correlates the received information to determine whether an action is needed for a specific context of the NF and, if so, what action should be taken. Note that the combination of context, current trust scores and thresholds, and historical trust scores and thresholds provides a holistic view of security -related conditions of the NF, which enables more granular actions per context. For example, a specific context of the NF may require certain actions that are different than actions for other contexts of the NF.

[0189] As an illustrative example of an action based on comparison outcome 3 above, a 3GPP- related context of a NF could be selection of Access Stratum (AS) Radio Resource Control (RRC) encryption algorithm. As defined in 3GPP TS 33.501 (vl7.12.0), there is a priority ordering of RRC encryption algorithms in accordance with their protection capability, with NEA2 having highest priority followed by NEA1 and then NEAO (lowest / weakest). Even so, a critical NF may need to select a lower-priority encryption with less protection to meet performance objectives, resulting in a trust level that does not satisfy a trust threshold. Considering performance / security trade-off and the contexts of the NF, the action is to change to a weaker encryption (e.g., NEAO) from a stronger encryption currently in use (e.g., NEA1 or NEA2).

[0190] In general, embodiments can be implemented using standardized interfaces between nodes and functions in a communication network (e.g., 5G). In this manner, embodiments are suitable for multi-vendor network deployments. However, the choice of the implementation is dependent on architectural, performance, and scalability requirements of any given deployment. For example, if a centralized security orchestrator is unable to meet scalability and performance requirements of a fully centralized implementation, some of the modules of the trust management system may be distributed within the evaluated resources. Some specific examples that illustrate the modularity of embodiments of the trust management system are given below.

[0191] Figure 14 illustrates a centralized implementation of the trust management system, where all modules discussed above (labelled 1410-1460) are deployed in a centralized entity, such as a security orchestrator (1400). The security orchestrator then collects the relevant data from the evaluated resources (1470), such as purpose built (i.e., eNB / gNB), cloud (i.e., vCU, vDU), or O- RAN network functions. Additionally, the Data Collection module can collect other types of data from non-security external services (1480), such as business requirements (e.g., targets for cost, capital expense, operating expense, etc.), topology information or services, configuration information or services, and any other type of data that is relevant to evaluate trust levels and / or trust thresholds for each context within an evaluated resource.

[0192] Figure 15 illustrates a more distributed implementation of the trust management system, according to other embodiments of the present disclosure. In this implementation, the Trust Evaluation (1450), Trust Level Requirements (1430), and Decision Making (1460) modules are implemented in the centralized security orchestrator (1400) in a similar manner as shown in Figure 14. However, the Data Collection and Trust Metrics Calculation modules are distributed across the evaluated resources (1470), such as (1471, 1473) within a RAN node as shown in Figure 15. Additionally, the Trust Knowledge Base is split into a centralized (or network) part (1420) hosted by the security orchestrator as in Figure 14, and local parts distributed across the evaluated resources, such as (1472) within the exemplary RAN node. Some advantages of this distributed implementation are better scalability and quicker decision making and action response.

[0193] Figure 16 illustrates another centralized implementation of the trust management system in an O-RAN environment, according to other embodiments of the present disclosure. The O- RAN environment shown in Figure 16 includes similar components as illustrated in Figure 5, including an SMO (1610), a Non-RT RIC (1620) in the SMO, a Near-RT RIC (1630), an O-CU (1640) including O-CU-CP and O-CU-UP parts, an O-DU (1650), and an O-RU (1660). In this centralized implementation, the respective modules of the trust management system are implement as respective rApps (1621-1626) in the Non-RT RIC (1620).

[0194] Figure 17 illustrates a more distributed implementation of the trust management system in an O-RAN environment, according to other embodiments of the present disclosure. The O-RAN environment shown in Figure 17 includes the same O-RAN components as shown in Figure 16, described above. In this implementation, the TrKB and Trust Level Requirements modules are again implemented by rApps (1622, 1623) in the Non-RT RIC (1620). However, the Data Collection, Trust Metrics Calculation, Trust Evaluation, and Decision Making modules are implemented as respective xApps (1631, 1634-1636) in the Near-RT RIC (1630).

[0195] By implementing these modules as xApps in Near-RT RIC, they are closer to the network functions under evaluation and have shorter automation loops leading to faster decision making and actions. Keeping TrKB and Trust Level Requirements modules as rApps gives them a broader network view and enables collection data from different services within the SMO (e.g., vendor specific services). Updated trust thresholds can be provided (e.g., streamed) from the rApps to the Trust Evaluation xApp.

[0196] Various features of the embodiments described above correspond to various operations illustrated in Figure 18, which show exemplary methods (e.g., procedures) for a trust management system according to various embodiments of the present disclosure. In other words, various features of the operations described below correspond to various embodiments described above. Although Figure 18 shows specific blocks in particular orders, the operations of the exemplary method can be performed in different orders than shown and can be combined and / or divided into blocks having different functionality than shown. Optional blocks or operations are indicated by dashed lines.

[0197] The exemplary method includes the operations of block 1810, wherein for each of a plurality of contexts of a NF of the communication network, the trust management system determines one or more metrics representative of trustworthiness of the context. The exemplary method includes the operations of block 1820, wherein for each context, the trust management system determines a context trust score based on the one or more metrics representative of trustworthiness of the context. The exemplary method includes the operations of block 1840, wherein the trust management system determines a current NF trust score based on the plurality of context trust scores. The exemplary method includes the operations of block 1840, wherein the trust management system determines a context-specific action for at least one context of the NF, based on the current NF trust score and a current value of a configurable trust threshold for the NF.

[0198] In some embodiments, the plurality of contexts include an asset context and a plurality of services contexts. In some of these embodiments, the plurality of services contexts include a 3GPP services context and a non-3GPP services context.

[0199] In some embodiments, determining the context-specific action in block 1860 includes the following operations, labelled with corresponding sub-block numbers: • (1861) determining that the NF is no longer trustworthy based on one or more of the following being less than the current value of the configurable trust threshold: the current NF trust score, and one or more historical NF trust scores for the NF; and

[0200] • (1862) determining the context-specific action needed to return the NF to being trustworthy.

[0201] In some embodiments, determining the context-specific action in block 1860 is further based on the following, for each of the contexts:

[0202] • criticality of one of the following associated with the context: an asset, or a service; and

[0203] • a minimum trustworthiness of the context, as indicated by a minimum of the metrics.

[0204] In some embodiments, the exemplary method also includes the operations of block 1820, where the trust management system determines the current value of the configurable trust threshold for the NF based on one or more of the following:

[0205] • one or more previous values of the configurable trust threshold for the NF;

[0206] • mean time to detect (MTTD) a security -related failure in the NF;

[0207] • mean time to recover (MTTR) from a security -related failure in the NF;

[0208] • risk of data loss or reputation damage from a security -related failure in the NF;

[0209] • one or more NF performance requirements;

[0210] • one or more service level agreements (SLAs) for services provided by the NF; and

[0211] • prioritization of NF performance versus NF security.

[0212] In some embodiments, the exemplary method also includes the operations of block 1850, where the trust management system determines an updated value of the configurable trust threshold based the current value, the current NF trust score, and one or more historical NF trust scores for the NF. In some of these embodiments, the updated value of the configurable trust threshold is one of the following:

[0213] • higher than the current value when at least one of the current NF trust score, and the one or more historical NF trust scores is greater than the current value;

[0214] • same as the current value when at least one of the current NF trust score, and the one or more historical NF trust scores is equal to the current value; and

[0215] • less than the current value when at least one of the current NF trust score, and the one or more historical NF trust scores is less than the current value.

[0216] In some variants of these embodiments, the updated value of the configurable trust threshold is an average of the current NF trust score and the one or more historical NF trust scores. In other variants of these embodiments, the updated value of the configurable trust threshold is determined based on a linear regression model applied to at least two of the following: • a maximum historical NF trust score;

[0217] • MTTR from a security -related failure in the NF; and

[0218] • a criticality of an asset of the NF, relative to one or more other NF assets of the communication network; and

[0219] • a criticality of a service provided by the NF, relative to one or more other services provided by the NF or by the communication network.

[0220] In some of these embodiments, determining the current value of the configurable trust threshold in block 1830 and / or determining the updated value of the configurable trust threshold in block 1850 is performed by a trust level requirements (TrLRQMT) module of the trust management system.

[0221] In some embodiments, determining the one or more metrics representative of trustworthiness of each of the plurality of contexts of the NF in block 1810 includes the following operations, labelled with corresponding sub-block numbers:

[0222] • (1811) collecting unstructured data representative of security -related characteristics of the NF;

[0223] • (1812) deriving numerical values from the unstructured data and associating each of the numerical values with one or more of the contexts of the NF; and

[0224] • (1813) for each context of the NF, determining the one or more metrics based on the associated numerical values.

[0225] In some of these embodiments, the unstructured data includes one or more of the following: event lists, logs of security incidents, NF configuration information, NF interface information, NF metadata, software and hardware information for a computing platform used to implement the NF, and services being provided by the NF. In some of these embodiments, each metric is determined based on an average of the associated numerical values. In some of these embodiments, one or more of the following applies: each numerical value is in the range of zero to one, and each metric is in the range of zero to one.

[0226] In some of these embodiments, the one or more metrics include a vulnerability metric, which is determined based on numerical values derived from one or more of the following unstructured data: known vulnerabilities in the NF, high and critical vulnerabilities in the NF, and history of patching vulnerabilities in the NF.

[0227] In some of these embodiments, the one or more metrics include an attacks and compromise metric, which is determined based on numerical values derived from one or more of the following unstructured data: detected security incidents in the NF, true positive security incidents in the NF, indications of compromise (loC) for the NF, and suspicious user account activity in the NF. In some of these embodiments, the one or more metrics include an attack surface metric, which is determined based on numerical values derived from one or more of the following unstructured data: how many other NFs communicate with the NF, and how many attack paths to the NF.

[0228] In some of these embodiments, the one or more metrics include a hardening and compliance coverage metric, which is determined based on numerical values derived from one or more of the following unstructured data for the computing platform used to implement the NF:

[0229] • users with administrator privilege,

[0230] • software patching history, and

[0231] • software versions of one or more of the following: libraries, kernel, operating system, and Kubemetes controller.

[0232] In some of these embodiments, determining the context-specific action in block 1860 is further based on respective data structures for the plurality of contexts, with the data structure for each context including:

[0233] • the numerical values associated with the context,

[0234] • the one or more metrics representative of trustworthiness of the context, and

[0235] • the context trust score.

[0236] In some of these embodiments, collecting the unstructured data and deriving the numerical values in sub-blocks 1811-1812 are performed by a data collection (DC) module of the trust management system. Also, determining the one or more metrics for each context in sub-block 1813 is performed by a metrics calculation (TrMC) module of the trust management system.

[0237] In some embodiments, for each context, the context trust score is determined based on an average of the one or more metrics representative of trustworthiness of the context. In some embodiments, determining the context-specific action in block 1810 is further based on the plurality of context trust scores. An example of this determination was discussed above in relation to Figure 11.

[0238] In some embodiments, determining the context trust scores in block 1820 and determining the current NF trust score in block 1840 are performed by a trust evaluation (TrEval) module of the trust management system. Additionally, determining the action in block 1860 is performed by a decision making (DM) module of the trust management system.

[0239] In some embodiments, the context-specific action determined in block 1860 includes one or more of the following:

[0240] • instantiate a honeypot that isolates an attacker of one of the contexts, without impact to resources of the context; • initiate a patch or update for software used to implement one of the contexts indicated to be vulnerable based on the context trust score;

[0241] • select a less secure encryption algorithm to be used in one of the contexts, based on a tradeoff between the current NF trust score and a performance requirement of one or more of the following: the NF, and the context.

[0242] Skilled persons will recognize that the trust management system may also initiate or trigger the context-specific action for at least one context of the NF, which was determined in block 1860.

[0243] Although various embodiments are described herein above in terms of methods, apparatus, devices, computer-readable medium and receivers, the person of ordinary skill will readily comprehend that such methods can be embodied by various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatuses, non-transitory computer-readable media, etc.

[0244] Various network equipment can be configured to implement a trust management system that performs operations corresponding to any of the exemplary methods described above in relation to Figure 18. In some embodiments, the network equipment can comprise processing circuitry and communication interface circuitry configured to perform such operations. In some embodiments, the network equipment is arranged as one of the following in an open radio access network (O-RAN) architecture:

[0245] • a non-RT RIC configured to implement a plurality of modules of the trust management system (e.g., as shown in Figure 16); or

[0246] • a non-RT RIC configured to implement a first plurality of modules of the trust management system, and a near-RT RIC configured to implement a second plurality of modules of the trust management system (e.g., as shown in Figure 17).

[0247] In other embodiments, the network equipment can be arranged as one of the following in an cloud RAN architecture:

[0248] • a centralized service management and orchestration (SMO) function configured to implement a plurality of modules of the trust management system (e.g., as shown in Figure 14); or

[0249] • a centralized SMO configured to implement a first plurality of modules of the trust management system, and a plurality of distributed RAN nodes configured to implement a second plurality of modules of the trust management system (e.g., as shown in Figure 15). Other embodiments include a trust management system arranged into a plurality of modules that implement different operations of the exemplary methods described above in relation to Figure 18. For example, the plurality of modules can include the following: • a TrMC, module configured to, for each of a plurality of contexts of a NF of the communication network, determine one or more trust metrics representative of trustworthiness of the context;

[0250] • a TrEval module configured to, for each context, determine a context trust score based on the one or more trust metrics representative of trustworthiness of the context and determine a current NF trust score based on the plurality of context trust scores; and

[0251] • a DM module configured to determine a context-specific action for at least one context of the NF, based on the current NF trust score and a current value of a configurable trust threshold for the NF.

[0252] Some variants of these embodiments also include a TrLRQMT module and a TrKB module, examples of which were discussed above.

[0253] Figure 19 shows an example of a communication system 1900 in accordance with some embodiments. In this example, communication system 1900 includes a telecommunication network 1902 that includes an access network 1904 (e.g., RAN) and a core network 1906, which includes one or more core network nodes 1908. Access network 1904 includes one or more access network nodes, such as network nodes 1910a-b (one or more of which may be generally referred to as network nodes 1910), or any other similar 3GPP access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, telecommunication network 1902 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in telecommunication network 1902 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in telecommunication network 1902, including one or more network nodes 1910 and / or core network nodes 1908.

[0254] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or anon-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the 0-RAN Alliance or comparable technologies. Network nodes 1910 facilitate direct or indirect connection of UEs, such as by connecting UEs 1912a-d (one or more of which may be generally referred to as UEs 1912) to core network 1906 over one or more wireless connections.

[0255] In some embodiments, telecommunication network 1902 can also include one or more Network Management (NM) nodes 1918, which can be part of an operation support system (OSS), a business support system (BSS), and / or an operation / administration / maintenance (0AM) system. The NM nodes can monitor and / or control operations of other nodes in access network 1904 and core network 1906. Although not shown in Figure 19, NM node 1918 is configured to communicate with other nodes in access network 1904 and core network 1906 for these purposes.

[0256] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, communication system 1900 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. Communication system 1900 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0257] UEs 1912 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with network nodes 1910 and other communication devices. Similarly, network nodes 1910 are arranged, capable, configured, and / or operable to communicate directly or indirectly with UEs 1912 and / or with other network nodes or equipment in telecommunication network 1902 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in telecommunication network 1902.

[0258] In the depicted example, core network 1906 connects network nodes 1910 to one or more hosts, such as host 1916. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1906 includes one or more core network nodes (e.g., 1908) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of core network node 1908. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0259] Host 1916 may be under the ownership or control of a service provider other than an operator or provider of access network 1904 and / or telecommunication network 1902, and may be operated by the service provider or on behalf of the service provider. Host 1916 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0260] In some embodiments, access network 1904 can include a service management and orchestration (SMO) system or node 1920, which can monitor and / or control operations of the access network nodes 1910. This arrangement can be used, for example, when access network 1904 utilizes an O-RAN architecture. SMO system 1920 can be configured to communicate with core network 1906 and / or host 1916, as shown in Figure 19.

[0261] In some embodiments, one or more of core network node 1908, host 1916, NM node 1918, and SMO system 1920 can be configured to perform various operations of exemplary methods (e.g, procedures) performed by a trust management system (or modules thereof), such as described above in relation to other figures.

[0262] As a whole, communication system 1900 of Figure 19 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0263] In some examples, telecommunication network 1902 is a cellular network that implements 3GPP standardized features. Accordingly, telecommunication network 1902 may support network slicing to provide different logical networks to different devices that are connected to telecommunication network 1902. For example, telecommunication network 1902 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0264] In some examples, UEs 1912 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to access network 1904 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from access network 1904. Additionally, a UE may be configured for operating in single- or multi -RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0265] In the example, hub 1914 communicates with access network 1904 to facilitate indirect communication between one or more UEs (e.g., 1912c and / or 1912d) and network nodes (e.g., network node 1910b). In some examples, hub 1914 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, hub 1914 may be a broadband router enabling access to core network 1906 for the UEs. As another example, hub 1914 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1910, or by executable code, script, process, or other instructions in hub 1914. As another example, hub 1914 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, hub 1914 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, hub 1914 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which hub 1914 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, hub 1914 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0266] Figure 20 shows a network node 2000 in accordance with some embodiments. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (e.g., radio base stations, Node Bs, eNBs, gNBs), and O-RAN nodes or components (e.g., O-RU, O-DU, O-CU).

[0267] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0268] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, and positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs))).

[0269] In some embodiments, network node 2000 can be configured to perform various operations of exemplary methods (e.g., procedures) performed by a trust management system (or modules thereof), such as described above in relation to other figures.

[0270] Network node 2000 includes processing circuitry 2002, memory 2004, communication interface 2006, and power source 2008. Network node 2000 may be composed of multiple physically separate components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which network node 2000 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, network node 2000 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 2004 for different RATs) and some components may be reused (e.g., a same antenna 2010 may be shared by different RATs). Network node 2000 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 2000, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 2000.

[0271] Processing circuitry 2002 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 2000 components, such as memory 2004, to provide network node 2000 functionality.

[0272] In some embodiments, processing circuitry 2002 includes a system on a chip (SOC). In some embodiments, processing circuitry 2002 includes radio frequency (RF) transceiver circuitry 2012 and / or baseband processing circuitry 2014. In some embodiments, RF transceiver circuitry 2012 and baseband processing circuitry 2014 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 2012 and / or baseband processing circuitry 2014 may be on the same chip or set of chips, boards, or units.

[0273] Memory 2004 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by processing circuitry 2002. Memory 2004 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions (collected denoted computer program 2004a, which may be in the form of a computer program product) capable of being executed by processing circuitry 2002 and utilized by network node 2000. Memory 2004 may be used to store any calculations made by processing circuitry 2002 and / or any data received via communication interface 2006. In some embodiments, processing circuitry 2002 and memory 2004 is integrated.

[0274] Communication interface 2006 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, communication interface 2006 comprises port(s) / terminal(s) 2016 to send and receive data, for example to and from a network over a wired connection. Communication interface 2006 also includes radio frontend circuitry 2018 that may be coupled to, or in certain embodiments a part of, antenna 2010. Radio front-end circuitry 2018 comprises filters 2020 and amplifiers 2022. Radio front-end circuitry 2018 may be connected to an antenna 2010 and processing circuitry 2002. The radio front-end circuitry may be configured to condition signals communicated between antenna 2010 and processing circuitry 2002. Radio front-end circuitry 2018 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. Radio front-end circuitry 2018 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 2020 and / or amplifiers 2022. The radio signal may then be transmitted via antenna 2010. Similarly, when receiving data, antenna 2010 may collect radio signals which are then converted into digital data by radio front-end circuitry 2018. The digital data may be passed to processing circuitry 2002. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0275] In certain alternative embodiments, network node 2000 does not include separate radio front-end circuitry 2018, instead, processing circuitry 2002 includes radio front-end circuitry and is connected to antenna 2010. Similarly, in some embodiments, all or some of RF transceiver circuitry 2012 is part of communication interface 2006. In still other embodiments, communication interface 2006 includes one or more ports or terminals 2016, radio front-end circuitry 2018, and RF transceiver circuitry 2012, as part of a radio unit (not shown), and communication interface 2006 communicates with baseband processing circuitry 2014, which is part of a digital unit (not shown).

[0276] Antenna 2010 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. Antenna 2010 may be coupled to radio front-end circuitry 2018 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, antenna 2010 is separate from network node 2000 and connectable to network node 2000 through an interface or port.

[0277] Antenna 2010, communication interface 2006, and / or processing circuitry 2002 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, antenna 2010, communication interface 2006, and / or processing circuitry 2002 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0278] Power source 2008 provides power to the various components of network node 2000 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source 2008 may further comprise, or be coupled to, power management circuitry to supply the components of network node 2000 with power for performing the functionality described herein. For example, network node 2000 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of power source 2008. As a further example, power source 2008 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0279] Embodiments of network node 2000 may include additional components beyond those shown in Figure 20 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 2000 may include user interface equipment to allow input of information into network node 2000 and to allow output of information from network node 2000. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 2000.

[0280] Figure 21 is a block diagram of a host 2100, which may be an embodiment of host 1816 of Figure 18, in accordance with various aspects described herein. Host 2100 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm.

[0281] Host 2100 includes processing circuitry 2102 that is operatively coupled via a bus 2104 to an input / output interface 2106, a network interface 2108, a power source 2110, and a memory 2112. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such that the descriptions thereof are generally applicable to the corresponding components of host 2100.

[0282] Memory 2112 may include one or more computer programs including one or more host application programs 2114 and data 2116, which may include user data, e.g., data generated by a UE for host 2100 or data generated by host 2100 for a UE. Embodiments of host 2100 may utilize only a subset or all of the components shown. Host application programs 2114 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FL AC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). Host application programs 2114 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, host 2100 may select and / or indicate a different host for over-the-top services for a UE. Host application programs 2114 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real- Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0283] In some embodiments, host 2100 can be configured to perform various operations of exemplary methods (e.g. procedures) performed by a trust management system (or modules thereof), such as described above in relation to other figures.

[0284] Figure 22 is a block diagram illustrating a virtualization environment 2200 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 2200 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 2200 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0285] Applications 2202 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 2200 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. In some embodiments, one or more applications 2202 can be configured to perform various operations of exemplary methods (e.g, procedures) performed by a trust management system (or modules thereof), such as described above in relation to other figures.

[0286] Hardware 2204 includes processing circuitry, memory that stores software and / or instructions (collected denoted computer program 2204a, which may be in the form of a computer program product) executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 2206 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 2208a-b (one or more of which may be generally referred to as VMs 2208), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. Virtualization layer 2206 may present a virtual operating platform that appears like networking hardware to VMs 2208.

[0287] VMs 2208 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 2206. Different embodiments of the instance of a virtual appliance 2202 may be implemented on one or more of VMs 2208, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0288] In the context of NFV, each VM 2208 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each VM 2208, and that part of hardware 2204 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 2208 on top of hardware 2204 and corresponds to application 2202.

[0289] Hardware 2204 may be implemented in a standalone network node with generic or specific components. Hardware 2204 may implement some functions via virtualization. Alternatively, hardware 2204 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration function 2210, which, among others, oversees lifecycle management of applications 2202. In some embodiments, hardware 2204 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 2212 which may alternatively be used for communication between hardware nodes and radio units.

[0290] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the spirit and scope of the disclosure. Various embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

[0291] The term unit, as used herein, can have conventional meaning in the field of electronics, electrical devices and / or electronic devices and can include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

[0292] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0293] As described herein, device and / or apparatus can be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device or apparatus, instead of being hardware implemented, be implemented as a software module such as a computer program or a computer program product comprising executable software code portions for execution or being run on a processor. Furthermore, functionality of a device or apparatus can be implemented by any combination of hardware and software. A device or apparatus can also be regarded as an assembly of multiple devices and / or apparatuses, whether functionally in cooperation with or independently of each other. Moreover, devices and apparatuses can be implemented in a distributed fashion throughout a system, so long as the functionality of the device or apparatus is preserved. Such and similar principles are considered as known to a skilled person.

[0294] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. In addition, certain terms used in the present disclosure, including the specification and drawings, can be used synonymously in certain instances (e.g, “data” and “information”). It should be understood, that although these terms (and / or other terms that can be synonymous to one another) can be used synonymously herein, there can be instances when such words can be intended to not be used synonymously.

Claims

CLAIMS1. A method performed by a trust management system (1399) associated with a communication network (1902), the method comprising: for each of a plurality of contexts of a network function, NF, of the communication network, determining (1810) one or more metrics representative of trustworthiness of the context; for each context, determining (1820) a context trust score based on the one or more metrics representative of trustworthiness of the context; determining (1840) a current NF trust score based on the plurality of context trust scores; and determining (1860) a context-specific action for at least one context of the NF, based on the current NF trust score and a current value of a configurable trust threshold for the NF.

2. The method of claim 1, wherein the plurality of contexts include an asset context and a plurality of services contexts.

3. The method of claim 2, wherein the plurality of services contexts include a 3GPP services context and a non-3GPP services context.

4. The method of any of claims 1-3, wherein determining (1860) the context-specific action comprises: determining (1861) that the NF is no longer trustworthy based on one or more of the following being less than the current value of the configurable trust threshold: the current NF trust score, and one or more historical NF trust scores for the NF; and determining (1862) the context-specific action needed to return the NF to being trustworthy.

5. The method of any of claims 1-4, wherein determining (1860) the context-specific action is further based on the following, for each of the contexts: criticality of one of the following associated with the context: an asset, or a service; and a minimum trustworthiness of the context, as indicated by a minimum of the metrics.

6. The method of any of claims 1-5, further comprising determining (1830) the current value of the configurable trust threshold for the NF based on one or more of the following: one or more previous values of the configurable trust threshold for the NF; mean time to detect, MTTD, a security -related failure in the NF; mean time to recover, MTTR, from a security -related failure in the NF; risk of data loss or reputation damage from a security -related failure in the NF; one or more NF performance requirements; one or more service level agreements, SLAs, for services provided by the NF; and prioritization of NF performance versus NF security.

7. The method of any of claims 1-6, further comprising determining (1850) an updated value of the configurable trust threshold based the current value, the current NF trust score, and one or more historical NF trust scores for the NF.

8. The method of claim 7, wherein the updated value of the configurable trust threshold is one of the following: higher than the current value when at least one of the current NF trust score, and the one or more historical NF trust scores is greater than the current value; same as the current value when at least one of the current NF trust score, and the one or more historical NF trust scores is equal to the current value; and less than the current value when at least one of the current NF trust score, and the one or more historical NF trust scores is less than the current value.

9. The method of claim 7, wherein the updated value of the configurable trust threshold is an average of the current NF trust score and the one or more historical NF trust scores.

10. The method of claim 7, wherein the updated value of the configurable trust threshold is determined based on a linear regression model applied to at least two of the following: a maximum historical NF trust score; mean time to recover, MTTR, from a security -related failure in the NF; and a criticality of an asset of the NF, relative to one or more other NF assets of the communication network; and a criticality of a service provided by the NF, relative to one or more other services provided by the NF or by the communication network.

11. The method of any of claims 6-10, wherein determining (1830) the current value of the configurable trust threshold and / or determining the updated value of the configurable trust threshold is performed by a trust level requirements, TrLRQMT, module of the trust management system.

12. The method of any of claims 1-11, wherein determining (1810) the one or more metrics representative of trustworthiness of each of the plurality of contexts of the NF comprises: collecting (1811) unstructured data representative of security-related characteristics of the NF; deriving (1812) numerical values from the unstructured data and associating each of the numerical values with one or more of the contexts of the NF; and for each context of the NF, determining (1813) the one or more metrics based on the associated numerical values.

13. The method of claim 12, wherein the unstructured data includes one or more of the following: event lists, logs of security incidents, NF configuration information, NF interface information, NF metadata, software and hardware information for a computing platform used to implement the NF, and services being provided by the NF.

14. The method of any of claims 12-13, wherein each metric is determined based on an average of the associated numerical values.

15. The method of any of claims 12-14, wherein one or more of the following applies: each numerical value is in the range of zero to one, and each metric is in the range of zero to one.

16. The method of any of claims 12-15, wherein the one or more metrics include a vulnerability metric, which is determined based on numerical values derived from one or more of the following unstructured data: known vulnerabilities in the NF, high and critical vulnerabilities in the NF, and history of patching vulnerabilities in the NF.

17. The method of any of claims 12-16, wherein the one or more metrics include an attacks and compromise metric, which is determined based on numerical values derived from one or more of the following unstructured data: detected security incidents in the NF; true positive security incidents in the NF; indications of compromise, loC, for the NF; and suspicious user account activity in the NF.

18. The method of any of claims 12-17, wherein the one or more metrics include an attack surface metric, which is determined based on numerical values derived from one or more of the following unstructured data: how many other NFs communicate with the NF, and how many attack paths to the NF.

19. The method of any of claims 12-18, wherein the one or more metrics include a hardening and compliance coverage metric, which is determined based on numerical values derived from one or more of the following unstructured data for the computing platform used to implement the NF: users with administrator privilege, software patching history, and software versions of one or more of the following: libraries, kernel, operating system, and Kubemetes controller.

20. The method of any of claims 12-19, wherein determining (1860) the context-specific action is further based on respective data structures for the plurality of contexts, with the data structure for each context including: the numerical values associated with the context, the one or more metrics representative of trustworthiness of the context, and the context trust score.

21. The method of any of claims 12-20, wherein: collecting (1811) the unstructured data and deriving (1812) the numerical values are performed by a data collection, DC, module of the trust management system; and determining (1813) the one or more metrics for each context is performed by a metrics calculation, TrMC, module of the trust management system.

22. The method of any of claims 1-21, wherein for each context, the context trust score is determined based on an average of the one or more metrics representative of trustworthiness of the context.

23. The method of any of claims 1-22, wherein determining (1860) the context-specific action is further based on the plurality of context trust scores.

24. The method of any of claims 1-23, wherein: determining (1820) the context trust scores and determining (1840) the current NF trust score are performed by a trust evaluation, TrEval, module of the trust management system; and determining (1860) the context-specific action is performed by a decision making, DM, module of the trust management system.

25. The method of any of claims 1-24, wherein the context-specific action includes one or more of the following: instantiate a honeypot that isolates an attacker of one of the contexts, without impact to resources of the context; initiate a patch or update for software used to implement one of the contexts indicated to be vulnerable based on the context trust score; select a less secure encryption algorithm to be used in one of the contexts, based on a tradeoff between the current NF trust score and a performance requirement of one or more of the following: the NF, and the context.

26. Network equipment (1908, 1910, 1916, 1918, 1920, 2000, 2100, 2200) configured to implement a trust management system (1399) associated with a communication network (1902), the network equipment comprising: communication interface circuitry (2006, 2108, 2204) configured to communicate with network functions, NFs (570, 1270, 1370, 1470), of the communication network; and processing circuitry (2002, 2102, 2204) operably coupled to the communication interface circuitry, whereby the processing circuitry and the communication interface circuitry are configured to: for each of a plurality of contexts of a NF of the communication network, determining one or more metrics representative of trustworthiness of the context; for each context, determining a context trust score based on the one or more metrics representative of trustworthiness of the context; determining a current NF trust score based on the plurality of context trust scores; anddetermining a context-specific action for at least one context of the NF, based on the current NF trust score and a current value of a configurable trust threshold for the NF.

27. The network equipment of claim 26, wherein the processing circuitry and the communication interface circuitry are further configured to perform operations corresponding to any of claims 2-25.

28. Network equipment (1908, 1910, 1916, 1918, 1920, 2000, 2100, 2200) configured to implement a trust management system (1399) associated with a communication network (1902), the network equipment being further configured to: for each of a plurality of contexts of a network function, NF (570, 1270, 1370, 1470) of the communication network, determining one or more metrics representative of trustworthiness of the context; for each context, determining a context trust score based on the one or more metrics representative of trustworthiness of the context; determining a current NF trust score based on the plurality of context trust scores; and determining a context-specific action for at least one context of the NF, based on the current NF trust score and a current value of a configurable trust threshold for the NF.

29. The network equipment of claim 28, being further configured to perform operations corresponding to any of claims 2-25.

30. The network equipment of any of claims 26-29, wherein the network equipment is arranged as one of the following in an open radio access network (O-RAN) architecture: a non-real-time (non-RT) radio interface controller (RIC) configured to implement a plurality of modules of the trust management system; or a non-RT RIC configured to implement a first plurality of modules of the trust management system, and a near-RT RIC configured to implement a second plurality of modules of the trust management system.

31. The network equipment of any of claims 26-29, wherein the network equipment is arranged as one of the following in an cloud radio access network (RAN) architecture:a centralized service management and orchestration (SMO) function configured to implement a plurality of modules of the trust management system; or a centralized SMO configured to implement a first plurality of modules of the trust management system, and a plurality of distributed RAN nodes configured to implement a second plurality of modules of the trust management system.

32. A trust management system (1399) for a communication network (1902), the trust management system being arranged into a plurality of modules including: a metrics calculation, TrMC, module (1340, 1440, 1473, 1624, 1634) configured to, for each of a plurality of contexts of a network function, NF (570, 1270, 1370, 1470) of the communication network, determine one or more metrics representative of trustworthiness of the context; a trust evaluation, TrEval, module (1350, 1450, 1625, 1635) configured to: for each context, determine a context trust score based on the one or more metrics representative of trustworthiness of the context; and determine a current NF trust score based on the plurality of context trust scores; and a decision making, DM, module (1260, 1360, 1460, 1626, 1636) configured to determine a context-specific action for at least one context of the NF, based on the current NF trust score and a current value of a configurable trust threshold for the NF.

33. The trust management system of claim 32, further comprising a data collection, DC, module (1310, 1410, 1471, 1621, 1631) configured to: collect unstructured data representative of security-related characteristics of the NF; and derive numerical values from the unstructured data and associate each of the numerical values with one or more of the contexts of the NF, wherein the TrMC module is configured to determine, for each context of the NF, the one or more metrics based on the associated numerical values.

34. The trust management system of any of claims 32-33, further comprising: a trust level requirements module, TrLRQMT (1330, 1430, 1623) configured to determine the current value of a configurable trust threshold for the NF; anda trust knowledge base module, TrKB (520, 1220, 1320, 1420, 1472, 1622) configured to store the following: the current value of the configurable trust threshold, and information used by the TrLRQMT module to determine the current value.

35. A non-transitory, computer-readable medium (1904, 2012, 2104) storing computerexecutable instructions that, when executed by processing circuitry (2002, 2102, 2204) associated with a trust management system (1399) for a communication network (1902), configure the trust management system to perform operations corresponding to any of the methods of claims 1-25.

36. A computer program (1904a, 2014, 2104a) comprising computer-executable instructions that, when executed by processing circuitry (2002, 2102, 2204) associated with a trust management system (1399) for a communication network (1902), configure the trust management system to perform operations corresponding to any of the methods of claims 1-25.

Images