Determining a security metric of isolation

Abstract

It is provided a method for determining a security metric of isolation between different domains (11). The method comprising: determining (40) a scope (11, 12, 13) for a security metric; determining (42) a security control set comprising a plurality of security controls; evaluating (44), for each security control in the security control set, whether the security control is implemented in the scope (11, 12, 13), wherein an implemented security control in the scope (11, 12, 13) defines coverage of the security control; determining (46), for at least each covered security control in the security control set, a correctness value indicating how well the security control is implemented; and calculating (48) the security metric based on both the coverage of the security controls and the correctness values.

Description

DETERMINING A SECURITY METRIC OF ISOLATIONTECHNICAL FIELD

[0001] The present disclosure relates to the field of telecommunication networks, and in particular to determining a security metric of isolation between different domains within a telecommunication network.BACKGROUND

[0002] In today's increasingly interconnected and fast-paced digital ecosystem, mobile networks, such as 5G (fifth generation), play a pivotal role and must be considered as critical infrastructures. Ensuring their security is paramount to safeguard both individual users and the industries that more and more depend on these networks. A crucial aspect of maintaining and improving security is the ability to effectively measure and monitor at any time the system's security state and to continuously improve it.

[0003] In the prior art, there a several attempts at providing numerical measurements of security in various networks. For instance, Shafayat Oshman, Muhammad “Assessing Security in the Multi-Stakeholder Premise of 5G: A Survey and an Adapted Security Metrics Approach”, master thesis at Carleton University, Ottawa, Canada, 2022, available at https: / / d0i.0rg / 10.2221.5 / etd / 2022-14833 at the time of filing this patent application, discloses that security metrics provide a pathway to quantitatively measure the security posture of an environment. It is analysed if and how existing security metrics can be applied to a 5G environment.

[0004] However, there always a need to improve how security metrics are calculated.SUMMARY

[0005] One object is to provide a security metric that is applicable to a modern telecommunication network, and that can be used to quantitively evaluate how desired isolation between parts of the telecommunication network is implemented.

[0006] According to a first aspect, it is provided a method for determining a security metric of isolation between different domains within a telecommunication network. Themethod is performed by a metric determiner. The method comprises: determining a scope for a security metric; determining a security control set comprising a plurality of security controls, wherein each security control is a safeguard or countermeasure for protecting one or more of confidentiality, integrity, or availability of internet protocol, IP, data within the scope; evaluating, for each security control in the security control set, whether the security control is implemented in the scope, wherein an implemented security control in the scope defines coverage of the security control; determining, for at least each covered security control in the security control set, a correctness value indicating how well the security control is implemented; and calculating the security metric based on both the coverage of the security controls and the correctness values.

[0007] In one embodiment, the evaluating, for each security control in the security control set, whether the security control is implemented in the scope, results in a coverage vector comprising binary values, wherein each binary value corresponds a respective security control, and the binary value depends on whether the security control in covered or not. In this case,, the determining, for at least each covered security control in the security control set, a correctness value, results in a correctness vector comprising the correctness values; and the calculating the security metric comprises calculating the security metric based on the coverage vector and the correctness vector.

[0008] The coverage vector and the correctness vector can be of the same size, in which case the calculating the security metric comprises performing an element -wise multiplication of the coverage vector and the correctness vector.

[0009] The calculating the security metric may comprise calculating an averaged weighted sum of the element-wise products.

[0010] The method may further comprise: calculating a weight, for each element-wise product, based on the value of the element-wise product in relation to a target range, and wherein the calculated weights are used for calculating the averaged weighted sum of the element-wise products.

[0011] The different domains within the telecommunication network may be different network slices.

[0012] The determining a correctness value may comprise performing a different determination of correctness value for each different security control.

[0013] For one of the security controls being IP isolation and / or VLAN, virtual local area network, isolation, the determining a correctness value may be based on the following formula:Njy ItTl-pl0

[0014] where IVa- represents the correctness value for IP isolation, Sub_c is a binary value, being 1 if a particular sub-control is implemented and being o if the particular sub-control is not implemented, N represents a number of sub-controls that are predefined to be implemented for the scope.

[0015] Each one of the sub-controls may be a sub-control in a list comprising: a first sub-control defining separation of user plane traffic and control plane traffic, a second sub-control defining each network slice being assigned a separate subnet range a separate virtual local area network, VLAN, and a third sub-control defining each public land mobile network, PLMN, being represented by a separate IP address and having a separate VLAN for its control plane traffic.

[0016] For one of the security controls being firewall, the determining a correctness value may be based on a number of firewall rules matching a number of expected firewall rules for a topology of the scope, such that the matching is beneficial for the correctness value.

[0017] For a security control being a firewall, the determining a correctness value may be based on a variance of a number of packet hits per node, such that a low variance is beneficial for the correctness value.

[0018] For a security control being an IP secure, IPsec, tunnel, the determining a correctness value may be based on one or more of a number of network slices sharing an IPsec tunnel, a number of network slices sharing a single IPsec authentication certificate, a number of hosts that are allowed according to a traffic selector for the IPsec tunnel, and presence of an any-any rule in a traffic selector for the IPsec tunnel.

[0019] According to a second aspect, it is provided a metric determiner for determining a security metric of isolation between different domains within a telecommunication network. The metric determiner may comprise: processing circuitry; and memory circuitry storing instructions that, when executed by the processing circuitry, cause the metric determiner to: determine a scope for a security metric; determine a security control set comprising a plurality of security controls, wherein each security control is a safeguard or countermeasure for protecting one or more of confidentiality, integrity, or availability of internet protocol, IP, data within the scope; evaluate, for each security control in the security control set, whether the security control is implemented in the scope, wherein an implemented security control in the scope defines coverage of the security control; determine, for at least each covered security control in the security control set, a correctness value indicating how well the security control is implemented; and calculate the security metric based on both the coverage of the security controls and the correctness values.

[0020] In one embodiment, the instructions to evaluate, for each security control in the security control set, whether the security control is implemented in the scope, may comprise instructions that, when executed by the processing circuitry, cause the metric determiner to provide a result in the form of a coverage vector comprising binary values, wherein each binary value corresponds a respective security control, and the binary value depends on whether the security control in covered or not. In this case, the instructions to determine, for at least each covered security control in the security control set, a correctness value, comprise instructions that, when executed by the processing circuitry, cause the metric determiner to provide a result in the form of a correctness vector comprising the correctness values; and the instructions to calculate the security metric comprise instructions that, when executed by the processingcircuitry, cause the metric determiner to calculate the security metric based on the coverage vector and the correctness vector.

[0021] The coverage vector and the correctness vector may be of the same size, in which case the instructions to calculate the security metric comprise instructions that, when executed by the processing circuitry, cause the metric determiner to perform an element-wise multiplication of the coverage vector and the correctness vector.

[0022] The instructions to calculate the security metric may comprise instructions that, when executed by the processing circuitry, cause the metric determiner to calculate an averaged weighted sum of the element-wise products.

[0023] The metric determiner may further comprise instructions that, when executed by the processing circuitry, cause the metric determiner to calculate a weight, for each element-wise product, based on the value of the element-wise product in relation to a target range, in which case the calculated weights are used for calculating the averaged weighted sum of the element-wise products.

[0024] The different domains within the telecommunication network may be different network slices.

[0025] The instructions to determine a correctness value may comprise instructions that, when executed by the processing circuitry, cause the metric determiner to perform a different determination of correctness value for each different security control.

[0026] For one of the security controls being IP isolation, the instructions to determine a correctness value may comprise instructions that, when executed by the processing circuitry, cause the metric determiner to determine a correctness value based on the following formula:Njy ItTl-pl0

[0027] where IVa- represents the correctness value for IP isolation, Sub_c is a binary value, being 1 if a particular sub-control is implemented and being o if the particularsub-control is not implemented, N represents a number of sub-controls that are predefined to be implemented for the scope.

[0028] Each one of the sub-controls may be a sub-control in a list comprising: a first sub-control defining separation of user plane traffic and control plane traffic, a second sub-control defining each network slice being assigned a separate subnet range a separate virtual local area network, VLAN, and a third sub-control defining each public land mobile network, PLMN, being represented by a separate IP address and having a separate VLAN for its control plane traffic.

[0029] For one of the security controls being firewall, the instructions to determine a correctness value may comprise instructions that, when executed by the processing circuitry, cause the metric determiner to determine a correctness value based on a number of firewall rules matching a number of expected firewall rules for a topology of the scope, such that the matching is beneficial for the correctness value.

[0030] For a security control being a firewall, the instructions to determine a correctness value may comprise instructions that, when executed by the processing circuitry, cause the metric determiner to determine a correctness value based on a variance of a number of packet hits per node, such that a low variance is beneficial for the correctness value.

[0031] For a security control being an IP secure, IPsec, tunnel, the instructions to determine a correctness value may comprise instructions that, when executed by the processing circuitry, cause the metric determiner to determine a correctness value based on one or more of a number of network slices sharing an IPsec tunnel, a number of network slices sharing a single IPsec authentication certificate, a number of hosts that are allowed according to a traffic selector for the IPsec tunnel, and presence of an any-any rule in a traffic selector for the IPsec tunnel.

[0032] According to a third aspect, it is provided a computer program for determining a security metric of isolation between different domains within a telecommunication network. The computer program comprises computer program code which, when executed on a metric determiner causes the metric determiner to:determine a scope for a security metric; determine a security control set comprising a plurality of security controls, wherein each security control is a safeguard or countermeasure for protecting one or more of confidentiality, integrity, or availability of internet protocol, IP, data within the scope; evaluate, for each security control in the security control set, whether the security control is implemented in the scope, wherein an implemented security control in the scope defines coverage of the security control; determine, for at least each covered security control in the security control set, a correctness value indicating how well the security control is implemented; and calculate the security metric based on both the coverage of the security controls and the correctness values.

[0033] According to a fourth aspect, it is provided a computer program product comprising a computer program according to the third aspect and a computer readable means comprising non-transitory memory in which the computer program is stored.

[0034] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. 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. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, in which:

[0036] Fig 1 is a schematic diagram illustrating an environment in which embodiments presented herein can be applied;

[0037] Figs 2A-D are schematic diagrams illustrating embodiments of where a metric determiner for determining security metrics can be implemented;

[0038] Fig 3 is schematic diagram illustrating how security metrics can be determined for various scopes;

[0039] Fig 4 is a schematic graph illustrating communication relationships between various nodes;

[0040] Fig 5 is a schematic graph illustrating isolation grouping for dimensionality reduction.

[0041] Figs 6A-B are flow charts illustrating embodiments of methods for; determining a security metric of isolation between different domains within a telecommunication network, such as the telecommunication network of Fig 1;

[0042] Fig 7 is a schematic diagram illustrating components of the metric determiner of Figs 3A-D according to one embodiment;

[0043] Fig 8 is a schematic diagram showing functional modules of the metric determiner of Fig 8 according to one embodiment;

[0044] Fig 9 shows one example of a computer program product comprising computer readable means; and

[0045] Fig 10 is a schematic diagram illustrating how the metric determiner 1 can be implemented in an 0-RAN architecture..DETAILED DESCRIPTION

[0046] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description.

[0047] According to embodiments presented herein, it is provided a solution to determine a security metric of isolation between different domains, such as networkslices, within a telecommunication network. The solution is based on determining whether each one of a number of security controls of a security control set is implemented, yielding a coverage measure. Additionally, it is determined numerically how correct each security control is implemented, yielding a correctness measure. The security metric is then calculated based on both the coverage measure and the correctness measure. In this way, the security metric can be used to evaluate isolation implementations, to identify problems and to work out improvement possibilities.

[0048] Fig 1 is a schematic diagram illustrating a telecommunication network 8 where embodiments presented herein may be applied. The telecommunication network 8 comprises a core network 3, 3A, 3B and one or more radio network nodes 5, here in the form of radio base stations being gNode Bs, also known as gNBs. The radio network node 1 could also be in the form of eNode Bs, etc. Whenever the term gNB or NF (network function) is used herein, this can also be applied for an equivalent radio network node 5 in another network than 5G NR, e.g. an eNB in an LTE network. The radio network node 5 can be split into a central unit (CU) for handling higher-layer protocols and control functions, and a distributed unit (DU), closer to the UEs (user equipments), for lower-layer protocols and radio transmission. It is possible for a single CU to oversee and coordinate multiple DUs. The connection between a CU and a DU is called a fronthaul interface. The CU and DU can e.g. comply with the open radio area network (0-RAN) architecture, in which case the CU is denoted O-CU and the DU is denoted 0-DU. The connection between the radio network node 5 and the core network 3A, 3B, 3 is called a backhaul interface.

[0049] The radio network node 5 implements a radio area network (RAN), to provide radio connectivity over a wireless interface to a plurality of user equipments (UEs) 2A-B. The term UE 2 is also known as mobile communication terminal, wireless device, mobile terminal, user terminal, user agent, wireless terminal, machine-to-machine device, etc., and can be implemented, for example, in what today is commonly known as an loT device, a mobile phone, smart phone or a tablet / laptop with wireless connectivity.

[0050] In the telecommunication network 8 of Fig 1, radio connectivity to the UEs 2A-B is split between two different network slices 4A-B, such that a first set of UEs 2Aare served by a first network slice 4A and a second set of UEs 2B are served by a second network slice 4B, in this case served by the same radio network node 5.

[0051] Each network slice 4A-B can have its own set of (physical and / or virtual) resources 3A, 3B in the core network. On the other hand, many of the RAN resources of the radio network node 5 can be shared between network slices 4A-B. Specifically, the first network slice 4A has its own first set of core network functions 3A, while the second network slice 4B has its own second set of core network functions 3B. For instance set of core network functions 3A-B can comprise its own user plane function (UPF). There can also a common part of the core network 3, containing functions that are common to the different network slices 4A-B, such as an access and mobility management function (AMF).

[0052] By providing different network slices 4A-B, each network slice 4A-B can be given its own set of characteristics, such as bandwidth, quality of service, priority, etc. In this way, network slices can be provided to suit various user requirements, employing only as much resources as needed, allowing also different pricing structures to be applied to different network slices. For instance, a specific network slice can be provided for remote surgery, and when a session is set up using the remote surgery network slice, a very high traffic availability is provided, compared e.g. to a media streaming network slice, which may provide more of best-effort availability.

[0053] The telecommunication network 8 may e.g. comply with any one or a combination of 5G NR (New Radio), 6G, LTE (Long Term Evolution), LTE Advanced, or any other current or future wireless network, as long as the principles described hereinafter are applicable.

[0054] Over the wireless interface 4, downlink (DL) communication occurs from the radio network node 1 to the wireless device 2 and uplink (UL) communication occurs from the wireless device 2 to the radio network node 1. The quality of the wireless radio interface to each wireless device 2 can vary over time and depending on the position of the wireless device 2, due to effects such as fading, multipath propagation, interference, etc.

[0055] Figs 2A-D are schematic diagrams illustrating embodiments of where a metric determiner for determining security metrics can be implemented.

[0056] In Fig 2A, the metric determiner 1 is shown as implemented in the radio network node 5. The radio network node 5 is thus the host device for the metric determiner 1 in this implementation.

[0057] In Fig 2B, the metric determiner 1 is shown as implemented in a core network 3, such as in a service management and orchestration framework (SMO) in the core network 3. The core network 3 is thus the host for the metric determiner 1 in this implementation.

[0058] In Fig 2C, the metric determiner 1 is shown as implemented in both a CU 5A and a DU 5B making up the radio network node. In another embodiment (not shown), the metric determiner 1 is implemented in one of the CU 5A or the DU 5B. In this case, the CU 5A and / or the DU 5B is thus the host device for the metric determiner 1.

[0059] In Fig 2D, the metric determiner 1 is shown as implemented as a stand-alone device. The metric determiner 1 thus does not have a host device in this implementation. Alternatively, various functional components for the metric determiner 1 may reside in different nodes or units in the telecommunication network 8.

[0060] Fig 3 is schematic diagram illustrating how security metrics can be determined for various scopes.

[0061] The security metric of isolation can be calculated for a local scope 11 for a specific radio network node 5, or at a higher scope level 12, 13. The security state of the local scope 11 represents the security state of a single slice implemented on a single network function (e.g. eNB, gNB, CU-CP (central unit - control plane), etc.) and an aggregate scope 12 represents the security state of the service that may be implemented in several slices that are geographically distributed on several network functions. The aggregate scope 12 can thereby include network slices in different areas (tracking areas, TA) that implements a specific service. Furthermore, a global scope 13 refers to the state of all services implemented as network slices that are implemented in a telecommunication network 8.

[0062] Identifying the right security controls that achieve the required isolation defines is the basis for providing a relevant isolation security metric. Herein, the examples given are mainly concerned with security controls to achieve transport security isolation requirement on a radio network node 5. The same procedure, possibly with slightly different calculations of correctness of implemented security controls, can be reused for other nodes or resources within the telecommunication network 8.

[0063] Table 1 below provides a mapping between each isolation level requirement and a corresponding set of security controls that are to be implemented, configured, and evaluated for their effectiveness. As an example to achieve a low-isolation requirement for network slices on the backhaul interface, IP address separation and VLAN (virtual local area network) separation can be foreseen as security controls that are required to be configured correctly to achieve the isolation level. Another example is medium isolation level, which requires, in addition to the security controls of the low isolation, an additional security control in the form of ACL (access control list) protection. As explained in more detail below, the ACL protection relates to firewall protection.Another example, for backhaul traffic isolation, if high isolation is desired, all the four associated security controls should be implemented, i.e. also IPsec tunnels, for full coverage to be considered.Context Isolation Level Security Controls Fulfilling Requirement RequirementsBackhaul Traffic NoneIsolationLow Isolation IP address separationVLAN separationMedium Isolation IP address separationVLAN separationACL ProtectionHigh Isolation IP address separationVLAN separationACL ProtectionIPsec tunnelsTable 1: Transport isolation levels

[0064] Different security controls, such as IP address separation, VLAN separation, ACL protection and IPsec tunnel, will now be presented separately to explain how a correct implementation of each security control is evaluated. This is later followed by how the individual evaluation of security controls are combined in a single isolation security metric.IP address separation and VLAN separation

[0065] The security controls of IP address separation and VLAN separation can be combined in one analysis since they are related. In the paradigm of network segmentation and isolation, separating the traffic into different IP subnets according to their functions, and in separate VLANs is considered good practice and good hygiene for a network to achieve isolation of traffic. The separation can be configured per function (e.g. O&M traffic, control traffic, user traffic, etc..). When applied for network slices, each network slice would then ideally have its own IP subnet and its own VLAN for communicating its separate core network functions 3A, 3B. The radio network node 5 may also have its own IP subnet and VLAN for communicating with the common part of the core network 3.

[0066] To ensure that the security controls are correctly configured, the configuration needs to comply with a set of requirements that gives an indication if the control is configured effectively or not, examples of those non exhaustive requirements are listed below.

[0067] For a correct configuration of the security control to be determined, it can be ensured that there is isolation on the IP level between different types of traffic (user plane (CP) vs control plane (CP)).

[0068] It can also be ensured that different traffic types can be routed differently, to enable flexible control of traffic.

[0069] It can also be ensured that each PLMN (public land mobile network) has its separate control-plane IP address (e.g. on the NG-C (next generation control plane) and CN-C (core network control plane)), when RAN sharing among different operators is implemented.

[0070] The separation of traffic can have different constellations. One example is to separate each slice that have its own slice ID (i.e. S-NSSAI (Single - Network Slice Selection Assistance Information)) in its own subnet range and VLAN on the transport network. Another, deeper, separation example, is within a single slice, separate the control plane traffic and the user plane traffic into different IP subnets and VLANs. The different constellation of correctness for this control can be realized in 3 different implementations denoted as Impl, listed here:

[0071] Impl 1'. Separate user plane (UP) and control plane (CP) inside RAN node on different IPs and different VLANs, shortened as “Separate UP&CP”.

[0072] Impl 2: Each S-NSSAI on the gNB transport resources should be in a separate subnet and separate VLAN, shortened as “S-NSSAI, Separate UP IP”

[0073] Impl 3: Each PLMN has separate IP address and different VLAN on the control plane, shortened as “PLMN, Separate CP IP”.

[0074] IP and VLAN separation is denoted herein as IVCr, which can be expressed as a binary vector where it follows binary association to the availability of the required implementations.

[0075] There are two different main cases of configuring and implementing a network slice, either a first case, where sharing of the gNB occurs between two or moredifferent PLMNs, or a second case where a single PLMNs (i.e. single mobile operator) is configured on the gNB. Both cases are captured below.

[0076] In the first case - gNB Sharing, the scenario presented here is based on multiple PLMNs are configured on the gNB, i.e. a form of RAN sharing. In this case, the correctness value can be represented by a binary vector that reflects three different constellations of implementing the IP and VLAN separation, impli, impl2 and impl3 defined above. This representation then provides 23= 8 possible combinations and value output.

[0077] Table 2 lays out the different options and resulting IVcrvalue.Impl 1 Impl 2 Impl 3 IVCrvalue (Separate UP & (S-NSSAI, (PLMN, SeparateCP) Separate UP IP) CP IP)0 0 0 0 / 3 = 00 1 0 1 / 3 ~ 0.33 1 0 0 1 / 3 ~ 0.33 0 0 1 1 / 3 ~ 0.33 1 1 0 2 / 3 » 0.660 1 1 2 / 3 » 0.661 0 1 2 / 3 » 0.661 1 1 3 / 3 = 1Table 2: IVcrvalue calculation for multiple PLMNs deployment

[0078] IVCrimpll, impl , impl3) thus has 8 possible combinations and 4 different value outputs, the value output will be either o, 0.33, 0.66 or 1, where o is thelowest value and 1 is the highest achieved value, reflecting that all 3 implementation requirements are met.

[0079] From Table 2 it can be seen that if IP and VLAN are not configured in any of the implementations that should meet the requirements, then all implementation will be assigned a value of o, which then indicates that the IVCrvalue is o, indicating that the current implementation didn’t meet the isolation requirement. Another example, if only one of the requirements are fulfilled then the IVCrvalue is 0.33. Additionally, if all implementation requirements are satisfied then IVCris assigned a value of 1, being the highest value.

[0080] In the second case, where RAN sharing is not configured on the gNB (single PLMN on a gNB), the correctness value can be represented as a vector with two elements only, that represent the constellations of the IP and VLAN implementations Impl and Impl2.

[0081] In this case, IVCrimpll, impl2) has 4 possible combinations and 3 value outputs. The value output can have the possible values o, 0.5 and 1, where o is the lowest value and 1 is the highest value, achieved when both implementations (Impl 1 and Impl 2) are met.Impl 1 Impl 2 IV(rvalue (Separate UP & CP) (S-NSSAI, Separate UP IP)0 0 0 / 2 = 00 1 1 / 2 = 0.51 0 1 / 2 = 0.51 1 2 / 2 = 1Table 3 - IVcrvalue calculation for a single PLMN deployment

[0082] Table 3 illustrates that if IP and VLAN are not configured in any of the implementations that should meet the requirements, then all implementations will be assigned a value of o, which then indicates that the IVCrvalue is o, which indicates that the current implementation didn’t meet the isolation requirement and the SecSLA is violated. Another example, if only one of the requirements are fulfilled then the IVCrvalue is 0.5. Additionally, if all implementation requirements are satisfied then IVCris assigned a value of 1 which is the highest.

[0083] Based on the two presented cases, a general method to calculate the IVCrvalue can be expressed as:Njy ItTl-pl0

[0084] Where Impl can be viewed as a binary value either 1 or o, which reflects if the security control is implemented and configured to meet a certain requirement or not., , r 1 if implementedImpl = jI 0 else

[0085] N represents the number of implementations that shall be achieved to meet the requirements, the value depends on the use case, for example if PLMN sharing is configured on the gNB then N = 3, if not then N = 2.Network Access List (ACL) / Firewall

[0086] The security control of firewalls and / or ACLs, is one way to effectively achieve isolation. Firewalls in combination with the previous IP and VLAN separation can achieve a medium isolation for network slices on a network function, see Table 1 above. There are some requirements that can be used as baseline requirements to govern that the firewall is correctly configured.

[0087] Some non-exhaustive examples of requirements are listed here:

[0088] A first example requirement is to limit communication between a set of nodes, following a communication matrix that is known to apply isolation or segmentation.

[0089] A second example requirement is to limit communication between specific services, following a service graph that is known to apply isolation or segmentation.

[0090] A third example is to limit communication for specific S-NSSAI with specific core network functions to provide service.

[0091] To evaluate correctness of a firewall implementation and ensure that the requirements are met, some pre-processing and information extraction can be performed before calculating a value. Initially, the possible required data needed for analysis could be the configuration of the current ACL implementation on the RAN NF (network function). Another possible source of information for evaluation is the topology, communication matrix or a service graph that illustrates the expected communication between the different nodes in a network, or between network slices and NF in core network, or between network slices and hosted services within a mobile network.

[0092] Fig 4 illustrates an example of a topology graph 14 of four nodes isa-d. Each NF, service, or network slice can be modelled as a node isa-d in the topology graph. A first node 15a should be able to communicate bidirectionally with a second node 15b, and to (only) transmit data to a third node 15c and a fourth node 13d. From the perspective of the second node 15b, this should be able to communicate bidirectionally with the first node 15a, and to (only) receive data from the fourth node 13d. From the perspective of the third node 15c, this should be able to (only) receive data from the first node 15a and to (only) transmit data to the fourth node isd. From the perspective of the fourth node isd, this should be able to (only) receive data from the first node 15a and the third node 15c, and to (only) transmit data to the second node 15b. The topology can be expressed as a communication matrix).

[0093] The procedure for determining a correctness value for the firewall can be summarised as a pipeline where a first stage is that a data analysis component takes asinput topology data (e.g. in the form of a communication matrix) and current firewall configuration to calculate numerical measures. The numerical measures can be then input used as input by a metric calculation component, where the correctness value is calculated and a numerical value in the range of [o, 1] is provided as an output.

[0094] An example of data required as input to the data analysis components could be a topology graph or a communication matrix that details information related on the expected communication between the NF and other nodes, network slices and services, network slices and relevant core network functions, etc. The configuration that can also be used as input can e.g. be NF configuration (e.g. gNB configuration) where the firewall configuration resides. An additional example could be counters (e.g. performance management (PM) counters) that represent packet hits on the firewall rules.

[0095] The data analysis component analyses and evaluates the firewall configuration rules against the provided topology graph, to evaluate to what degree that the required communication is reflected by firewall rules. The data analysis component analyses the unstructured data input and produces numerical measures that are meaningful for the metric calculation component. The numerical measures provide insights on the evaluation of the firewall configuration to the baseline requirements. As a non-exhaustive example, measures that can be produced by the data analysis can be: number of configured rules per graph node, number of packet hits on a firewall rule that permits traffic and existence of ANY ANY-type rules.

[0096] The number of configured rules per graph node reflects if all the communication nodes in a topology graph or a communication matrix have the right number of rules. An aim is to determine how many rules should be configured and in what role context. For example, looking again to Fig 4, the first node 15a in the topology graph 14 has communication with three other nodes, where it is expected to be in both roles a source and a destination. A source role of the first node 15a can be modelled as the following first node 15a -> second node 15b, first node 15a ->fourth node 15d, first node 15a -> third node 15c , whereby a number NSA of edges where the first node 15a is expected to be the source is NSA= 3 . Similarly, in the destination role it can be modelled as second node 15b -> first node 15a, whereby thenumber NDA of edges where the first node 15a is expected to be the source is NDA= 1. These numbers should be reflected in the number of rules configured on the firewall. If not, this gives an indication that rules are not effectively configured. Expanding to all nodes 153-d of Fig 4, the expected roles and number of rules for the whole topology graph 14 in Fig 4 are shown in Table 4:Node Role Number of rulesFirst node 15a Source 3First node 15a Destination 1Second node 15b Source 1Second node 15b Destination 2Third node 15c Source 1Third node 15c Destination 1Fourth node 13d Source 1Fourth node 13d Destination 2Table 4: expected roles and number of rules for the topology graph of Fig 4

[0097] For the number of packet hits on a firewall rule that permits traffic, the count of packet hits on a configured rule are analysed in order to take into consideration any rules that should not be allowed, that may give excessive access to certain communication that should not be there. The reason for such rules can be that it was an old rule and was not decommissioned, or a service or a port number that is allowed in the rule and is not expected in the provided communication matrix. Analysing the number of packet hits on a rule provides an accurate view to ensure that a decision made to decommission a rule afterwards is based on fact from actual traffic in the environment. An example of data used to analyse the packet hits could be the existing PM counters in a network function that stores such information.

[0098] For the description of the existence of ANY ANY type of rules, the structure of a firewall rule will first be presented. A firewall rule is often a tuple that is composed of 5 elements:(srCjp, $rCport> dstip, dstpOrf, action'),

[0099] where FWruie denotes the firewall rule, srapis the source IP address, srcport is the source port, dstipis the destination IP address, dstport is the destination port and action is the action covered by the rule.

[0100] It is considered a bad practice, and is rarely used, to include the keyword “ANY” at any element of a firewall rule. Under certain circumstances, for example if the action is “permit”, the keyword “ANY” enables any type of traffic, thus increasing the probability of compromising security and / or isolation. Based on that, if the existence of the keyword ANY is in one or more of the rules, this will result in a penalty value that reduces the calculated correctness value, as is explained in more detail below.

[0101] An example of an ANY ANY rule is a rule that allows any source to any destination (which is an excessive rule that should not be allowed): (srcHost: ANY, srcPort:ANY, dstHost:ANY, distort:ANY), action: permit): This rule implies that communication from any source IP address from any source port is allowed to communicate with any destination IP address and any destination port that that is accessible.

[0102] The overall firewall correctness value is denoted as FWCrand can be calculated according to:FWCr= |Cr- PT|,

[0103] where is Crrepresents a correctness value and PT is the penalty value.

[0104] The correctness value Crdepends on a coefficient of variation (CV) which is used to capture the variation in the number of packet hits per node and to check whether there is an abnormality (e.g. one node is experiencing very high or very low number of packet hits).

[0105] The coefficient of variation is defined by:standard deviation (cr)CV = - — - —mean ( / / )

[0106] The correctness value Crinversely related to CV, e.g. Cr= 1 — CV. This correctness value Cris beneficial to compare the correctness of a control (i.e.ACL / firewall) between two network functions in the same scope, between two slices carrying the same service. Additionally, as explained in more detail below, this correctness value Cr, can be evaluated in combination with other correctness values and coverage to end up with a combined isolation security measure.

[0107] To calculate the correctness value, a two-step procedure can be performed for every node. The first step is to check whether number of connected nodes matches the number of configured rules, and the second step is to calculate CV.

[0108] A procedure that can be used to determine the correctness value Crcan be described according to:- For all nodes:o If number of configured rules is equal to the number of corresponding flows of the node■ Cr= 1 - CVo Else■ Assign 1 to the nodes that match the equality condition (in If statement) and o to the ones that do not. Then calculate the ratio (x) or percentage (A%) of the nodes that match the equality condition.■ Calculate CV and map it to a reduction ratio r or percentage R% ■ Depending on whether percentages or radios are used, Calculate Cr= — x OR Cr= x x (1 - r)

[0109] An example of the reduction ratio mapping to CV is shown in Table 5. Other numerical values are possible, but in general, a mapping of range of CV values with greater percentages (i.e. greater scattering) results in a greater reduction ratio.CV Reduction Acceptable? Descriptionratio (%)<10% 10% Low scattering. Values close to / centred around the mean1O%-2O% 30% Yes Low-medium scattering between points2O%-3O% 50% Yes high-medium scattering between points>30% 100% No Very high point scattering.Highly dispersed valuesTable 1 An example of mapping between CV and reduction ratio

[0110] The penalty value represents a tolerance value that is subtracted from the correctness value due to the presence of a negative condition. For instance, a negative condition in the described use cases is the presence of the keyword “ANY” in one or more of the firewall elements. Depending on the use case, the tolerance value can be assigned. In one example, the penalty tolerance value can be based on the number of nodes in a graph that can reach a specific evaluated node. In another example, the penalty tolerance value can be based on the number of slices that are configured on a NF.

[0111] For network slice isolation evaluation, the penalty tolerance value can be defined as the number of slices that are configured. The reason for this is that if, for example, an ANY keyword is found in the srcipelement of the tuple, this implies that any IP initiating communication can communicate with a network slice, including other network slices that are configured on the NF. Since a requirement is the isolation ofnetwork slices on a single NF, the number of network slices configured on a NF can be taken into consideration as a value to be used for penalty tolerance.

[0112] The penalty value PT can be derived by the following procedure:For a given slice N, calculate individual penalty ratio:# of configured slices on NFPN =NT- 1 ’where P.vis the penalty ration for a given slice N and NT is the number of slices in the in the ACL.For all slices in the ACL, NT, calculate total penalty ratio:Pr(%) =IN’PCalculate the penalty value using a scalar multiplication: Penalty=Crx PTUpdate / modify the correctness value: FWCr= Cr- PenaltyIPsec tunnels

[0113] IPsec tunnel is a security control that can also be used to provide isolation between the network slice traffic on the backhaul interface between the RAN and the core network. There are some requirements that can be used as a baseline requirement to ensure that the IPsec tunnel is correctly configured.

[0114] The main two functionalities of an IPsec tunnel that are of concern to traffic isolation are traffic selectors and authentication. A first functionality is traffic selectors, that define access control requirements and traffic that is allowed through an IPsec tunnel. A second functionality is authentication that defines that each tunnel has its own method of authentication that is not shared with another tunnel being configured for another slice on the same network function.

[0115] For traffic selectors, according to one embodiment, the requirements for correctness are that user plane traffic between multiple S-NSSAIs is isolated. Moreover the traffic selector should define specific subnets (e.g. number of hosts <= 14, subnetmask not larger than / 28) or IP addresses (e.g. subnet mask / 32) that should be allowed access. Finally, presence of ANY ANY rules in the tunnel should lead to a penalty.

[0116] For authentication, according to one embodiment, the requirements is that each S-NSSAI has a separate certificate used for authentication.

[0117] The calculation of IPsec correctness, IPSecIsinCr, can be based on the following four inputs:- Number of S-NSSAIs sharing the IPsec tunnel- Number of S-NSSAIs sharing the same IPsec auth certificate- Number of allowed hosts on the tunnel (subnet mask size)- Availability of ANY ANY rules

[0118] The first two features can be used as inputs to the calculation of the IPsec security correctness, while the third and fourth features can be used to calculate the penalty value (if any), which can be used to update the IPsec correctness value.

[0119] The correctness of IPsec isolation is inversely related to the number of slices sharing the tunnel, i.e. an increase in the number of sharing slices decreases the isolation characteristics. The first two features can be combined into “number of sharing resources”.

[0120] The IPsec correctness value for IPsec, IPSecisincr can be represented by the following equation:IPSecIstnCr= min (0.1, f(# of sharing resources) X (1 — penalty))

[0121] Where (# of sharing resources) , in one example, is calculated according to 1# of sharing resources'

[0122] The penalty can be calculated as the average of all features that cause degradation in the value:penalty =

[0123] Where NPis the number of availability penalty features and PNe{PACL> PSM> ■■■> Px], PACL being the penalty value of ACL as highlighted previously and PSMis the penalty due to excessive subnet mask and can be represented as:D> # of allowed hosts

[0124] where Hoststhis the minimum number of hosts as a threshold that should be allowed in an IPsec tunnel.Calculating the security metric

[0125] The security metric is calculated by evaluating the control coverage, where the controls that map to isolation requirement are checked if they are implemented. The coverage is a vector of binary values that is denoted as Cv. Then the correctness for each available security control is calculated as explained above, e.g. one for IP / VLAN. one for ACL and one for IPsec. Correctness is denoted as a vector Cr, where each element is the value of the corresponding security control that is already covered and configured. The correctness calculations for each security control type are described in detail above. To calculate the security metric vector Cm, the vector of coverage values Cvand the vector of the correctness values Crfirst undergo element-wise product (also known as Hadamard product).

[0126] For illustration, consider an example with four desired security controls, where all are implemented except the third one. The correctness values for the security controls are, respectively, 0.7, 0,3, o, 1. The calculation would then be performed according to:C = [1, 1, 0, 1] * ~Cr= [0.7, 0.3, 0, 1] -> = [0.7, 0.3, 0, 1]

[0127] where * denotes element-wise (or Hadamard) multiplication.

[0128] Fig 5 is a schematic graph illustrating isolation grouping for dimensionality reduction. Based on the example grouping of Fig 5, the obtained security metric vector Cmcan undergo a dimensionality reduction. In one embodiment, each individual value in the security metric vector Cmis evaluated with respect which one of a plurality ofgroups that the value belongs to obtain weights. One example of a group definition, referring also to Fig 5, is:- High (H) isolation group 23: [0.8, 1]- Medium (M) isolation group 22: [0.5, o.8[- Low (L) isolation group 21: [0.2, o.s[- No (N) isolation group 20: [o, o.2[

[0129] Weights w of the values belonging to the low isolation group 21, the medium isolation group 22 and the high isolation group 2, can be computed according to:score — min rangew = - max range — min rangeFor the no isolation group 20, weight wocan be computed according to:max range — scorew = - max range — min range

[0130] For example, considering the first entry 0.7 in the vector in the example,the resulting weight w of will be equal to= 0.67, since the first entry, 0.7, belongs to the medium isolation group 22 with a minimum value in the range of 0.5. Following the same logic, the weights w of the remaining elements in the vector (0.3, o, and 1) will be equal to 0.33, 1 and 1, respectively. All weights w are then expressed as [ 0.67, 0.33, 1, 1].

[0131] The reason for having a different generalized weight calculation formula for the no isolation group 20 is that if no isolation is required, then the ideal value would be the minimum value in the range and not the maximum, since the minimum value results in the lowest resource use (the goal is to have the value as close to the minimum value, o, as possible). Unlike the other groups where the ideal value is the maximum value in the group range (goal is to have the value as close to the maximum as possible).In Fig 5, the dashed line 25 illustrates how the weight value varies depending on the correctness value.

[0132] In one embodiment target requirement for the lower limit for all metrics is a category. In this case, every slice can be grouped as the lowest encountered categorical score. For instance, we evaluate N measures and they are all in the high isolation group 23 except for the last one (H, H, ..., M). In this case, the slice isolation level to apply would be the medium isolation group 22.

[0133] In one embodiment, the target requirement also the computed value for the metric is considered. Consider e.g. the example where the measures are (1, 1,..., 0.79). Depending on the weights and their distance to the target value, we can rank the network slice as a high isolation group 23 even if not all its metrics are H.

[0134] A combination of the two embodiments for weight determination is also possible, In this case, where a low isolation group 21 is determined in case there is at least one metric evaluated in that range, and as the weighted average in case all metrics are evaluated at least equal to M.

[0135] The security metric is then be calculated as an averaged weighted sum of the vector elements._ w * Cm

[0136] where * denotes element-wise (or Hadamard) multiplication.

[0137] In the example, the calculation is performed according to:0.7 * 0.67 + 0.3 * 0.33 + 0 * 1 + 1 * 1Cm= - = 0.52m0.67 + 0.33 + 1 + 1

[0138] The security measure for the aggregate scope 12 can be calculated as the average of the security measures for the local scope 11 , e.g. of all slices in different areas that implements a specific service.

[0139] Figs 6A-B are flow charts illustrating embodiments of methods for determining a security metric of isolation between different domains within a telecommunication network, such as the telecommunication network of Fig 1. The flow chart puts into perspective the different steps of obtaining the security metric. More details of the different steps are provided above.

[0140] The method is performed by a metric determiner 1, such as the metric determiner 1 of Figs 2A-D. The different domains within the telecommunication network 8 can be different network slices.

[0141] In a determine scope step 40, the metric determiner 1 determines 40 a scope 11, 12, 13 for a security metric. The different scopes are illustrated in Fig 3 and are described above. For instance, the scope could be a local scope 11 for a specific radio network node 5, an aggregate scope 12 representing the security state of a service that may be implemented in several slices that are geographically distributed on several network functions, or a global scope 13 refers to the state of all services implemented as network slices that are implemented in a telecommunication network 8.

[0142] The scope can be defined manually by the person that configures the metric calculation.

[0143] In a determine security control set step 42, the metric determiner 1 determines a security control set comprising a plurality of security controls. Each security control is a safeguard or countermeasure for protecting one or more of confidentiality, integrity, or availability of internet protocol, IP, data within the scope 11, 12, 13. The control set can e.g. be determine in line with the definitions in Table 1 above.

[0144] In an evaluate implementation state step 44, the metric determiner 1 evaluates, for each security control in the security control set, whether the security control is implemented in the scope 11, 12, 13. An implemented security control in the scope 11, 12, 13 defines coverage of the security control.

[0145] For instance, the evaluating, for each security control in the security control set, whether the security control is implemented in the scope 11, 12, 13, can result in a coverage vector Cv. The coverage vector Cvcomprises binary values, wherein each binaryvalue corresponds a respective security control, and the binary value depends on whether the security control in covered or not.

[0146] In a determine correctness value step 46, the metric determiner 1 determines, for at least each covered security control in the security control set, a correctness value indicating how well the security control is implemented. For instance, the determining, for at least each covered security control in the security control set, a correctness value, can result in a correctness vector comprising the correctness values.

[0147] In one embodiment, the determining a correctness value comprises performing a different determination of correctness value for each different security control. This tailors the correctness value to the particular type of security control.

[0148] In one embodiment, for one of the security controls being IP isolation and / or VLAN isolation, the determining a correctness value can be based on the following formula:Njy iVipl0

[0149] where IVcr represents the correctness value for IP isolation, Impl is a binary value, being 1 if a particular sub-control is implemented and being o if the particular sub-control is not implemented, N represents a number of sub-controls that are predefined to be implemented for the scope 11, 12, 13. Details of how this can be implemented are provided above under the heading IP address separation and VLAN separation.

[0150] In one embodiment, each one of the sub-controls can be a sub-control in a list comprising: a first sub-control defining separation of user plane traffic and control plane traffic, a second sub-control defining each network slice being assigned a separate subnet range a separate virtual local area network (VLAN), and a third sub-control defining each public land mobile network (PLMN), being represented by a separate IP address and having a separate VLAN for its control plane traffic. This is illustrated in Tables 2 and 3 above.

[0151] In one embodiment, for one of the security controls being firewall, the correctness value is determined based on a number of firewall rules matching a number of expected firewall rules for a topology of the scope 11, 12, 13, such that the matching is beneficial for the correctness value. Details of how this can be implemented are provided above under the heading Network Access List (ACL) / Firewall. See also Tables 4 and 5 as well as Fig 4.

[0152] In one embodiment, for a security control being a firewall, the correctness value is determined based on a variance of a number of packet hits per node, such that a low variance is beneficial for the correctness value.

[0153] In one embodiment, for a security control being an IP secure (IPsec) tunnel, the correctness value is determined based on one or more of a number of network slices sharing an IPsec tunnel, a number of network slices sharing a single IPsec authentication certificate, a number of hosts that are allowed according to a traffic selector for the IPsec tunnel, and presence of an any-any rule in a traffic selector for the IPsec tunnel. Details of how this can be implemented are provided above under the heading IPsec tunnels above.

[0154] In a calculate metric step 48, the metric determiner 1 calculates the security metric based on both the coverage of the security controls and the correctness values. The coverage expresses whether each security control in the security control set is implemented or not, e.g. in the form of a coverage vector. When the inputs are expressed as vectors, the security metric comprises calculating the security metric based on the coverage vector and the correctness vector. As explained above, the correctness vector comprises a set of correctness values.

[0155] In one embodiment, the coverage vector and the correctness vector are of the same size, and the security metric is calculated by performing an element-wise multiplication of the coverage vector and the correctness vector.

[0156] In one embodiment, the security metric is calculated based on calculating an averaged weighted sum of the element-wise products.

[0157] Details of how this can be implemented are provided above under the heading Calculating the security metric.

[0158] Looking now to Fig 6B, only new or modified steps compared to embodiments covered by Fig 6A will be described.

[0159] In an optional calculate weight step 47, the metric determiner 1 calculates a weight, for each element-wise product. Each weight is calculated based on the value of the element-wise product in relation to a target range. In this case, the calculated weights are used for calculating the averaged weighted sum of the element -wise products.

[0160] Using embodiments presented herein, security metrics are provided for measuring the correctness and effectiveness of a isolation implementation, provided using various security controls. The procedure can repeated as needed, ensuring that implemented security controls in a network function (e.g. eNB, gNB, CU, DU) are adapted according to changes, for example environment changes (such as topology changes, configuration changes) and changes in the threat landscape. The definition of measurable security requirement is provided that can be set and maintained using high level declarative policies (e.g., Intent-based management). This facilitates decisionmaking on which security controls should be implemented and which controls should be retired, thus balancing security and cost.

[0161] Fig 7 is a schematic diagram illustrating components of the metric determiner 1 of Figs 2A-D according to one embodiment. It is to be noted that when the metric determiner 1 is implemented in a host device, one or more of the mentioned components can be shared with the host device. Processing circuitry 60 is provided using any combination of one or more of a suitable central processing unit (CPU), graphics processing unit (GPU), multiprocessor, neural processing unit (NPU), microcontroller, digital signal processor (DSP), etc., capable of executing software instructions 67 stored in memory circuitry 64, which can thus be a computer program product. The processing circuitry 60 could alternatively be implemented using an application specific integrated circuit (ASIC), field programmable gate array (FPGA),etc. The processing circuitry 60 can be configured to execute the method described with reference to Figs 6A and 6B above.

[0162] The memory circuitry 64 can be any combination of random-access memory (RAM) and / or read-only memory (ROM). The memory circuitry 64 also comprises non-transitory persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid-state memory or even remotely mounted memory.

[0163] A data memory 66 is also provided for reading and / or storing data during execution of software instructions in the processing circuitry 60. The data memory 66 can be any combination of RAM and / or ROM.

[0164] An I / O interface 62 is provided for communicating with external and / or internal entities using wired communication, e.g. based on Ethernet, or optic fibres, and / or wireless communication, e.g. a telecommunication network complying with any one or a combination of sixth generation (6G) mobile networks, next generation mobile networks (fifth generation, 5G), LTE (Long Term Evolution), or any other current or future wireless network, as long as the principles described hereinafter are applicable.

[0165] Other components of the metric determiner 1 are omitted in order not to obscure the concepts presented herein.

[0166] Fig 8 is a schematic diagram showing functional modules of the metric determiner 1 of Fig 7 according to one embodiment. The modules are implemented using software instructions such as a computer program executing in the metric determiner 1. Alternatively or additionally, the modules are implemented using hardware, such as any one or more of an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or discrete logical circuits. The modules correspond to the steps in the methods illustrated in Figs 6A and 7B.

[0167] A scope determiner 60 corresponds to step 40. A security control set determiner 72 corresponds to step 42. An implementation state evaluator 74 corresponds to step 44. A correctness value determiner 76 corresponds to step 46. Aweight calculator 77 corresponds to step 47. A metric calculator 78 corresponds to step 48.

[0168] Fig 9 shows one example of a computer program product 90 comprising computer readable means. On this computer readable means, a computer program 91 can be stored in a non-transitory memory. The computer program can cause processing circuitry to execute a method according to embodiments described herein. In this example, the computer program product 90 is in the form of a removable solid-state memory, e.g. a Universal Serial Bus (USB) drive. As explained above, the computer program product could also be embodied in a memory of a device, such as the computer program product 64 of Fig 8. While the computer program 91 is here schematically shown as a section of the removable solid-state memory, the computer program can be stored in any way which is suitable for the computer program product, such as another type of removable solid-state memory, or an optical disc, such as a CD (compact disc), a DVD (digital versatile disc) or a Blu-Ray disc.

[0169] Fig 10 is a schematic diagram illustrating how the metric determiner 1 can be implemented in an 0-RAN architecture. A service management and orchestration framework (SMO) 100 can be implemented in the core network 3. A near-real-time RIC (RAN intelligent controller) 102 is provided to manage the and operation of the Radio Access Network (RAN) in near real-time. An O-CU-CP (Open CU OP) 104 is the CU part that is responsible for the control plane and a O-CU-UP (Open CU UP) 106 is the CU part that is responsible for the user plane. An 0-DU (open DU) 108 is the DU node. An 0-RU (open radio unit) 110 is responsible for the radio interface.

[0170] Within the 0-RAN architecture, the metric determiner 1 can be implemented in various nodes. For instance, the metric determiner 1 can be implemented in the SMO 100, or within the NF implemented by the O-CU-CP 104, or the 0-DU 108. The metric determiner 1 can also be implemented in a distributed fashion across two or more of the SMO 100, the O-CU-CP 104, and the 0-DU 108.

[0171] When implemented in the SMO 100, components of the metric determiner 1 can be provided as rApps that are placed within the SMO 100 (e.g. in a a non -real time RIC of the SMO). In this case, different rApps can request the data to analyse andcorrelate to produce numerical values and eventually calculate the security metric, by requesting data from potential vendor specific services that are also located in the SMO too. An example of the services that can be used, are configuration services, topology services and configuration compliance tool service that can be all or partially implemented within the SMO too.

[0172] The aspects of the present disclosure have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims. Thus, while various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope being indicated by the following claims.

Claims

CLAIMS1. A method for determining a security metric of isolation between different domains within a telecommunication network (8), the method being performed by a metric determiner (1), the method comprising:determining (40) a scope (11, 12, 13) for a security metric;determining (42) a security control set comprising a plurality of security controls, wherein each security control is a safeguard or countermeasure for protecting one or more of confidentiality, integrity, or availability of internet protocol, IP, data within the scope (11, 12, 13);evaluating (44), for each security control in the security control set, whether the security control is implemented in the scope (11, 12, 13), wherein an implemented security control in the scope (11, 12, 13) defines coverage of the security control;determining (46), for at least each covered security control in the security control set, a correctness value indicating how well the security control is implemented; and calculating (48) the security metric based on both the coverage of the security controls and the correctness values.

2. The method according to claim 1, wherein:the evaluating (44), for each security control in the security control set, whether the security control is implemented in the scope (11, 12, 13), results in a coverage vector comprising binary values, wherein each binary value corresponds a respective security control, and the binary value depends on whether the security control in covered or not;the determining (46), for at least each covered security control in the security control set, a correctness value, results in a correctness vector comprising the correctness values; andthe calculating (48) the security metric comprises calculating the security metric based on the coverage vector and the correctness vector.

3. The method according to claim 2, wherein the coverage vector and the correctness vector are of the same size, and wherein the calculating (48) the security metric comprises performing an element-wise multiplication of the coverage vector and the correctness vector.

4. The method according to claim 3, wherein the calculating (48) the security metric comprises calculating an averaged weighted sum of the element-wise products.

5. The method according to claim 4, further comprising:calculating (47) a weight, for each element-wise product, based on the value of the element-wise product in relation to a target range, and wherein the calculated weights are used for calculating the averaged weighted sum of the element-wise products.

6. The method according to any one of the preceding claims, wherein the different domains within the telecommunication network (8) are different network slices.

7. The method according to any one of the preceding claims, wherein the determining (46) a correctness value comprises performing a different determination of correctness value for each different security control.

8. The method according to claim 7, wherein for one of the security controls being IP isolation and / or VLAN, virtual local area network, isolation, the determining (46) a correctness value is based on the following formula:Njy ItTl-pl0where IVa- represents the correctness value for IP isolation, Sub_c is a binary value, being 1 if a particular sub-control is implemented and being o if the particular subcontrol is not implemented, N represents a number of sub-controls that are predefined to be implemented for the scope (11, 12, 13).

9. The method according to claim 8, wherein each one of the sub-controls is a subcontrol in a list comprising: a first sub-control defining separation of user plane traffic and control plane traffic, a second sub-control defining each network slice being assigned a separate subnet range a separate virtual local area network, VLAN, and a third sub-control defining each public land mobile network, PLMN, being represented by a separate IP address and having a separate VLAN for its control plane traffic.

10. The method according to any one of the preceding claims, wherein for one of the security controls being firewall, the determining (46) a correctness value is based on a number of firewall rules matching a number of expected firewall rules for a topology of the scope (11, 12, 13), such that the matching is beneficial for the correctness value.

11. The method according to any one of the preceding claims, wherein for a security control being a firewall, the determining (46) a correctness value is based on a variance of a number of packet hits per node, such that a low variance is beneficial for the correctness value.

12. The method according to any one of the preceding claims, wherein for a security control being an IP secure, IPsec, tunnel, the determining (46) a correctness value is based on one or more of a number of network slices sharing an IPsec tunnel, a number of network slices sharing a single IPsec authentication certificate, a number of hosts that are allowed according to a traffic selector for the IPsec tunnel, and presence of an any-any rule in a traffic selector for the IPsec tunnel.

13. A metric determiner (1) for determining a security metric of isolation between different domains within a telecommunication network (8), the metric determiner (1) comprising:processing circuitry (60); andmemory circuitry (64) storing instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to:determine a scope (11, 12, 13) for a security metric;determine a security control set comprising a plurality of security controls, wherein each security control is a safeguard or countermeasure for protecting one or more of confidentiality, integrity, or availability of internet protocol, IP, data within the scope (11, 12, 13);evaluate, for each security control in the security control set, whether the security control is implemented in the scope (11, 12, 13), wherein an implemented security control in the scope (11, 12, 13) defines coverage of the security control;determine, for at least each covered security control in the security control set, a correctness value indicating how well the security control is implemented; andcalculate the security metric based on both the coverage of the security controls and the correctness values.

14. The metric determiner (1) according to claim 13, wherein:the instructions to evaluate, for each security control in the security control set, whether the security control is implemented in the scope (11, 12, 13), comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to provide a result in the form of a coverage vector comprising binary values, wherein each binary value corresponds a respective security control, and the binary value depends on whether the security control in covered or not;the instructions to determine, for at least each covered security control in the security control set, a correctness value, comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to provide a result in the form of a correctness vector comprising the correctness values; andthe instructions to calculate the security metric comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to calculate the security metric based on the coverage vector and the correctness vector.

15. The metric determiner (1) according to claim 14, wherein the coverage vector and the correctness vector are of the same size, and wherein the instructions to calculate the security metric comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to perform an element-wise multiplication of the coverage vector and the correctness vector.

16. The metric determiner (1) according to claim 15, wherein the instructions to calculate the security metric comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to calculate an averaged weighted sum of the element-wise products.

17. The metric determiner (1) according to claim 16, further comprising instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to calculate a weight, for each element-wise product, based on the value of the element-wise product in relation to a target range, and wherein the calculated weights are used for calculating the averaged weighted sum of the element-wise products.

18. The metric determiner (1) according to any one of claims 13 to 17, wherein the different domains within the telecommunication network (8) are different network slices.

19. The metric determiner (1) according to any one of claims 13 to 18, wherein the instructions to determine a correctness value comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to perform a different determination of correctness value for each different security control.

20. The metric determiner (1) according to claim 19, wherein for one of the security controls being IP isolation, the instructions to determine a correctness value comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to determine a correctness value based on the following formula:Njy ItTl-pl0where IVa- represents the correctness value for IP isolation, Sub_c is a binary value, being 1 if a particular sub-control is implemented and being o if the particular subcontrol is not implemented, N represents a number of sub-controls that are predefined to be implemented for the scope (11, 12, 13).

21. The metric determiner (1) according to claim 20, wherein each one of the subcontrols is a sub-control in a list comprising: a first sub-control defining separation of user plane traffic and control plane traffic, a second sub-control defining each network slice being assigned a separate subnet range a separate virtual local area network, VLAN, and a third sub-control defining each public land mobile network, PLMN, being represented by a separate IP address and having a separate VIAN for its control plane traffic.

22. The metric determiner (1) according to any one of claims 13 to 21, wherein for one of the security controls being firewall, the instructions to determine a correctness value comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to determine a correctness value based on a number of firewallrules matching a number of expected firewall rules for a topology of the scope (11, 12, 13), such that the matching is beneficial for the correctness value.

23. The metric determiner (1) according to any one of claims 13 to 22, wherein for a security control being a firewall, the instructions to determine a correctness value comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to determine a correctness value based on a variance of a number of packet hits per node, such that a low variance is beneficial for the correctness value.

24. The metric determiner (1) according to any one of claims 13 to 23, wherein for a security control being an IP secure, IPsec, tunnel, the instructions to determine a correctness value comprise instructions (67) that, when executed by the processing circuitry, cause the metric determiner (1) to determine a correctness value based on one or more of a number of network slices sharing an IPsec tunnel, a number of network slices sharing a single IPsec authentication certificate, a number of hosts that are allowed according to a traffic selector for the IPsec tunnel, and presence of an any-any rule in a traffic selector for the IPsec tunnel.

25. A computer program (67, 91) for determining a security metric of isolation between different domains within a telecommunication network (8), the computer program comprising computer program code which, when executed on a metric determiner (1) causes the metric determiner (1) to:determine a scope (11, 12, 13) for a security metric;determine a security control set comprising a plurality of security controls, wherein each security control is a safeguard or countermeasure for protecting one or more of confidentiality, integrity, or availability of internet protocol, IP, data within the scope (11, 12, 13);evaluate, for each security control in the security control set, whether the security control is implemented in the scope (11, 12, 13), wherein an implemented security control in the scope (11, 12, 13) defines coverage of the security control;determine, for at least each covered security control in the security control set, a correctness value indicating how well the security control is implemented; and calculate the security metric based on both the coverage of the security controls and the correctness values.

26. A computer program product (64, 90) comprising a computer program according to claim 25 and a computer readable means comprising non-transitory memory in which the computer program is stored.

Images