Keywords

1 Introduction

Rapid advances in the industry of handheld devices and mobile applications has fuelled the penetration of interactive and ubiquitous web-based services into almost every aspect of our lives. At the same time, users expect almost zero-delay and infinite-capacity experience. However, current 4G technologies reveal their inherent limitations, as discussed in [1]. This is true, for both human-to-human and machine-to-machine (M2M) communications [2, 3]. Both will require radically different architectural design, network protocols, and business models. To achieve that, researchers are working towards the next-generation 5G wireless networks aiming to offer high-speed and personalized services to both humans and machines, when and where needed [4].

To support highly dense areas where a vast number of users want to access the network infrastructure, deployment of small cells (SCs) is envisioned. These can co-operate with traditional macro cells, to provide high levels of user experience [5, 6]. SCs will play a significant role in 5G networks, which are expected to be highly heterogeneous. That is, future 5G networks will comprise a variety of collocated resources, such as indoor and outdoor SCs, macro cell sites, and WiFi access points. Another driving force in 5G will be the advances in hardware virtualization technologies, which can facilitate the realization of the small cell as a service (SCaaS) concept [7].

The primary benefit that comes with SCaaS is that independent actors own and lease their cellular infrastructure to multiple mobile network operators (MNOs); therefore SCaaS provides a natural multi-tenant support, by allowing each MNO to be a tenant of the infrastructure and getting a “slice” of the physical SC infrastructure [8]. This is not the only advantage that SCaaS can offer to 5G. We can leverage SCaaS to provide high-speed, low-latency communications, and to offload the mobile core network traffic and computation to the network edge, giving life to the concept of mobile edge computing (MEC) and fog computing, which has recently attained attention [9–11].

Finally, another important technology of 5G is network function virtualization (NFV), which: decouples network functions from their physical location; offers flexible function migration; and distributes functions across different network components [12, 13]. It is worth mentioning that NFV can be further enhanced with the concept of software-defined networking (SDN) decoupling the control plane from the data plane [14, 15].

Although 5G network technologies are still taking shape, and standardization activities are still ongoing, it is expected that SCaaS, MEC, NFV, and SDN are going to be integral parts of 5G networks. For example, the recently started EU 5G-PPP project SESAME (Small cEllS coordinAtion for Multi-tenancy and Edge services) aims to provide solutions in the field [16]. Another, EU 5G-PPP project called 5G-ENSURE aims at defining the security architecture and developing security enablers for 5G [17].

1.1 Contribution

In order to investigate the security challenges of 5G networks, one must look into the security issues of its elements and their interaction. In this paper, we identify the security threats and vulnerabilities of SCaaS, NFV, and MEC, as a first step towards a more comprehensive 5G security analysis that we intend to undertake in future work. Our analysis is focused on SC infrastructure, whose security is a very crucial issue because SCs are expected to support both MNOs and end-users, who cannot tolerate financial losses or data privacy violations, and therefore they seek the highest possible security guarantees. Having a comprehensive view and taxonomy of security threats and vulnerabilities in SCs, is prerequisite for architecting optimal security solutions.

1.2 State-of-the-Art

The state-of-the-art within the field of 5G security is in its infancy. Mantas et al. [18] investigated some of the potential threats and attacks against the main components of 5G systems. The authors mainly focus on security issues related to the user equipment, and although they briefly go beyond that, they do not present security issues that open up as a result of SCaaS, NFV, and MEC. Apart from this, they lack a clear list of criteria that facilitate the creation of a taxonomy of threats and vulnerabilities. In an even less depth, in terms of threats and vulnerabilities investigation, Fang et al. [19] propose a high level security framework for 5G networks, without paying particular attention in the technologies we consider in our paper, here.

Within the realm of physical layer security for 5G networks, Yang et al. [20] investigate the security challenges that open up when considering the technologies of heterogeneous networks, massive multiple-input multiple-output (MIMO), and millimeter wave, which are likely to be important parts of 5G networks. Furthermore, Duan and Wang [21] investigated the security challenges, focusing mainly on authentication handover and privacy protection in 5G. The contribution of these papers is not directly comparable to ours, here, and we only referred to them for completeness.

1.3 Outline

This paper is structured as follows. In Sect. 2, we describe a generic, high-level architecture for SCaaS. We also present our assumptions regarding the SCaaS security and the adversarial model. Section 3 discusses the security challenges of SCaaS and reveals major security threats that arise due to (i) network resources and functions being virtualized, (ii) the adoption of MEC, and (iii) the incorporation of NFV and SDN concepts. We also present a set of criteria to facilitate the taxonomy of security challenges and discuss their mutual dependencies. Finally, Sect. 4 concludes this paper by summarizing its contributions and presenting our plans for future work.

2 Prerequisites

2.1 System Architecture

Our considered high-level system architecture for SCaaS is in line with [22] and has been illustrated in Fig. 1. The main elements of this architecture include: infrastructure virtualization; NFV; SDN, and MEC. According to the SC infrastructure virtualization principle, the physical SC is sliced into a number of virtual SCs (VSCs). To enable MEC services, each VSC is equipped with a MEC server, which has the ability to communicate with the Cloud and to execute some of the functions that are traditionally hosted in the Cloud. Furthermore, multiple MEC servers can be clustered to provide enhanced services in the form of a light data centre (Light DC) and managed by the virtual resources manager (VRM). Each VSC also accommodates a number of virtual network functions (VNFs) and it is managed by the SCaaS Orchestrator via an SDN agent. Above the management layer there is the service layer, in which multiple tenants (i.e., MNOs) are accommodated.

Fig. 1.
figure 1

High-level system architecture for small cell as a service.

Full size image

The network service layer accommodates MNOs who are benefited from having on-demand access to SC resources without owing the physical infrastructure. MNOs communicate with the SCaaS Orchestrator, located in the management layer, who orchestrates the allocation of virtual resources to MNOs. The SCaaS Orchestrator closely collaborates with the VRM, which is responsible for the management of virtual resources of MEC servers in the physical infrastructure layer. The control of VSCs is performed via SDN agents using some appropriate SDN protocol, such as the MobileFlow [23]. Finally, various network functions, such as firewalling and deep packet inspection (DPI), are virtualized using the NFV technology and managed by the VNF Manager. A specific realization of the architecture of Fig. 1 could be, for example, the SESAME architecture [16, 24]. However, in this work we intentionally keep our considered system architecture as generic as possible in order to accommodate a wide range of implementation choices of the SCaaS concept.

2.2 Security Assumptions

To identify the security challenges of the investigated system architecture, we first introduce our security assumptions, regarding the baseline security of the system. One of main assumptions is the physical security of SC infrastructure and hardware integrity. More specifically, we assume that hardware tampering is prevented by appropriate security controls deployed by the SC infrastructure owner [25], and that the Cloud provider has ensured the physical security of the Cloud infrastructure and of the data centres (e.g., according to the recommendations from the Cloud Security Alliance [26]). The existence of physical attacks will be considered in our future works. Note that due to space limitations, in this paper, we do not consider attacks that are initiated from the Cloud side. Instead, we focus on attacks originated either from user equipment (UE) or from the SC infrastructure itself (e.g., from a malicious tenant or a compromised system component). Besides, modern literature has investigated Cloud-originated attacks and identified the main Cloud security challenges [27, 28]; developed adequate security solutions [29]; and proposed methods for Cloud provider selection based on security and privacy requirements [30].

2.3 Adversarial Model

Our analysis adopts the widely-used Dolev-Yao adversarial model [31]. According to this model, the cellular network is represented as a set of abstract entities that exchange messages and the adversary is capable of overhearing, intercepting, and synthesizing any message and they are only limited by the constraints of the deployed cryptographic methods. For example, the adversary neither is able to forge the message authentication code (MAC) nor has the means to obtain the plaintext of encrypted messages.

Apart from the above, we enrich the adversarial model by considering compromised nodes. The adversary per se could be a legitimate tenant interacting with network entities by using valid credentials and having privileged access to virtualized resources. Yet the adversary might run any management application in their VSC or specify various policies within its virtual domain, which is defined as a cluster of VSCs allocated to the same tenant.

3 Security Challenges

In this section we discuss the security challenges that emerge from the adoption of the SCaaS concept, using as a reference the architecture of Fig. 1. We adopt the widely-used threat taxonomy proposed in [32] and identify the security challenges that arise due to specific architectural characteristics and interaction of various components and layers of SCaaS. The different security challenges can be classified according to five categories.

  • Precondition: What are the necessary conditions to be met before the adversary is able to launch the attack? For example, if the attack requires a particular service running on the victim side, the existence of an open interface is a precondition; another case is when the adversary has some particular access rights.

  • Vulnerability: What are the vulnerabilities of the system components or the network interfaces, which can be exploited by the adversary? For example, some components could be implemented in software with flaws or non-adequate cryptographic mechanisms could be in place [33].

  • Target: Which components or interfaces are the potential attack targets? Other considerations include the communication layer the adversary targets and whether he aims to compromise the control or the data plane or both.

  • Method: What are the various attack methods, tools and techniques that the adversary might use? In the same category we examine whether the adversary follows an active (e.g., replay attack) or passive strategy (e.g., passive reconnaissance).

  • Effect: What is the impact of a successful attack on the victimized system component or network interface? Impact might be, for instance, unavailability of some services, financial costs, and leakage of sensitive data.

Below, we identify specific security challenges for each of the aforementioned five categories.

3.1 Precondition

Regarding precondition, the following types of requirements might be valid for the adversary.

Specific configuration: In some cases, to launch an attack against a component, the adversary requires that this component has specific exploitable configuration or runs a specific software. For example, a precondition for a denial-of-service (DoS) attack [34, 35] can be specific configuration of the VRM with regard to the allocation of resources to tenants. Yet, some flaws in the resource allocation algorithm can allow the adversary to prevent a tenant from accessing its portion of virtual resources. Also, other types of DoS attacks may exploit the broadband nature of the wireless medium. For example, malicious interference at the physical layer, even using off-the-shelf hardware, can cause packet collisions at the media access control (MAC) layer [36].

Ubiquitous connectivity: If a network component or function can be accessed via the public Internet, this may be exploited by a remote adversary. The adversary will require a way of discovering the vulnerable component and sending messages via control or data plane. By moving the network intelligence to the network edge, as with the Light DC, a pool of MEC servers is usually available for UEs to be connected via the Internet using conventional methods. Also, the physical location and distributed or centralised nature of the SCaaS Orchestrator could be an important factor influencing its security. For example, one way to realise the SCaaS Orchestrator is as a distributed function with its instances located across multiple SCs (e.g., in the form of a VNF). In such case, if public Internet is used to remotely configure various SCaaS policies, this can be exploited by the adversary.

Privileged access: The adversary has privileged access to some parts of the network components or functions. The privileged access can be either at the administrator level or at the user level. For example, the adversary may be a legitimate UE receiving service from its MNO, with the latter being a legitimate tenant of the SC network infrastructure. Also, the emerging bring your own device (BYOD) trend in modern enterprises, constitutes many conventional security solutions incapable of protecting the private network [37]. For example, a Trojan horse that infected an employee’s device, can bypass the security of the corporate firewall.

3.2 Vulnerabilitiy

SDN controller weaknesses: Some vulnerabilities are caused by flaws in software and programming errors. This may lead, for example, to control flow attacks [38] and buffer overflow attacks [39]. This issue is particularly important in the context of next-generation wireless networks, where the trend is to implement the control plane in software and to virtualize network functions [40, 41].

Flaws of NFV platforms: The virtualised environment itself could introduce many potential security problems [42]. In particular, flaws of the virtualisation platform in place, may constitute the guest operating system (OS) vulnerable to side-channel attacks. For example, weak isolation between host and guest OSs may lead to a side-channel attack based on cache leakage [43].

Cloud based management: Some vulnerabilities stem from the Cloud based management nature of certain network components. The Cloud based interface used for configuration and updates could be used as a potential attack channel.

Weak access control and authentication: Use of weak or default passwords could be easily exploited by an adversary and should be avoided. Also, some components may have hard-coded passwords, which can be exploited by the adversary towards the establishment of backdoor access; stealthy or not.

Weak cryptographic mechanisms: Weaknesses or improper use of cryptographic mechanisms may lead to security breaches in authentication processes and data confidentiality. Also, the generation of cryptographic keys shouldn’t rely on weak random number generators. Other security problems may arise due to communication protocols that use weak cryptographic primitives. Hence, it should be ensured that the cryptographic security controls are in place [44]. This is to say that any adopted public-key scheme that enables the encryption of the communications among SC, UE, and the Cloud, should be sufficiently secure.

3.3 Target

Physical small cell infrastructure: Attacks on the specific piece of hardware that is used in the cellular network [45]. For example the physical SC infrastructure can be a target of hardware attacks. While it is a common practice for the users to authenticate themselves to mobile devices before using them, the devices usually do not do the same to users. This means that there is a risk for the authentication secret to be revealed to a non-authenticated device. Hence, an attacker may try to obtain the secret, by replacing the device with a malicious one [46].

NFV-based management system: Some attacks initiated inside virtualised environments may aim at taking control of the Hypervisor [47]. Also, the SCaaS Orchestrator is an attractive attack target due to being in the “middle” of the system model architecture, as well as other components of the management layer, such as the VNF Manager. Finally, impersonation by the adversary of one of the VNFs or the MEC server when communicating with the management layer could be a potential threat.

VM-hosted operating system: Both host and guest OS may be targeted [48], and to alleviate the impact of such an attack, adequate isolation must be enforced between guest virtual machines (VMs), as well as between the host and guest VMs. The adversary could attempt to break the isolation by exploiting, e.g., some flaws of the virtualisation platform in use [49].

Mobility management entity: In some cases, the attack does not target a specific layer in the system architecture, but it rather aims to take control of a specific network entity, either physical or virtual, such as the mobility management entity (MME). Protecting against such kind of attacks will be even more difficult when a distributed MME is introduced in 5G networks [50].

MEC-based application: A certain application that runs, for instance, on a MEC server is a potential attack target. This does not affect only the SC that hosts the compromised MEC server. Due to clustering of MEC servers into the Light DC, as discussed in Sect. 2, and their communication with the Cloud, a compromised MEC server can be used as a door to attack other network entities and components. Also, the adversary may attempt to attack the network service isolation. This may result in the violations of limits for virtual resources or unauthorized use of other tenants’ resources. We assume that the adversary can attempt to impersonate another tenant or another network entity. Also, it may attempt to decrypt the intercepted messages.

Fig. 2.
figure 2

Dependencies among security challenges of Small Cell as a Service in virtualised MEC environments.

Full size image

MobileFlow protocol: A usual attack target is the protocol used for communication, management or control purposes, such as the MobileFlow protocol [23]. For example, the southbound and northbound interfaces, shown in Fig. 1, are potential attack targets when attempting to hijack the communication of the SCaaS Orchestrator with VSCs and MNOs. Also, the communication within the SC infrastructure could be targeted; for example, between the management and the physical infrastructure layer. This may enable an adversary to alter the network policies and create attack channels. In particular, possible attack targets are (i) communication of the VNF Manager with VNFs in a SC; and (ii) communication of the VRM with MEC servers. Hence, the adversary may try to alter or disable legitimate policies and cause attacks such as DoS and privilege escalation or to violate the privacy of other tenants data.

3.4 Method

Reverse engineering: The adversary collects and analyses sensitive information about the network and its functionality. She may also try to decompile the software to retrieve the source code. This may enable the adversary to identify vulnerabilities in the software or network interfaces. In some cases, the adversary may exploit weaknesses in the implemented access control mechanisms and exploit a device through normal usage, i.e., as a legitimate user. Other reverse-engineering techniques may target users’ sensitive personal information. For example, the increasing popularity of mobile crowdsourcing and mobile sensing projects [51] may enable an attacker to exploit various personal data such as the user location, mobility patterns or web browsing habits [52].

SDN controller hijacking: By exploiting the SDN controller implementation weaknesses, the adversary tries to divert the control flows to a controlled device [53]. Then the captured messages can be discarded preventing the data plane entities from proper operation. In a more advanced case, the captured messages may be manipulated with a special purpose code and sent into the network.

VNF/VM infection: The adversary infects a virtual network component, such as a VM or a VNF, with a malicious code. In this way, an unwanted and potentially harmful functionality can be added to the affected system and can modify its behaviour. The future trends in network softwarization and programmability [54, 55] make this attack method particularly important. Furthermore, in a typical virtualised environment, guest VMs are expected to run in complete isolation. This means that a VM is not able to interact with the host and other VMs nor is able to monitor or control them in any way. This isolation is typically enforced by the Hypervisor. However, such virtualised environments may be vulnerable to the so-called VM escape attack [56], which is a process of breaking out the aforementioned VM isolation. This can be achieved for example by installing malware on the Hypervisor [57].

Crafted packets and data: The adversary can attack communication and control protocols by injecting crafted packets or crafted input data. These actions may exploit, for example, the parsing vulnerabilities of protocol implementations [58].

Replay attack: The adversary captures packets or packet fragments and replays them at appropriate times aiming to cause protocol failures or other types of disruption and confusion.

Eavesdropping: The adversary observes messages exchanged between various network components or functions. In this way, sensitive information can be obtained, especially if this information is weakly protected by cryptographic mechanisms or not protected at all.

3.5 Effect

VM/VNF privilege escalation: The adversary, who has already some level of limited access privilege (e.g., to a VM or a VNF), manages to gain more privilege. This may have very serious negative effects for SDN-based mobile networks [59] as well as for the emerging Internet of things (IoT) technologies [60].

Denial of service: A potential outcome of attacks can be DoS leading to switched off or malfunctioning SC, or unavailable MEC servers. Also, a DoS attack against the SCaaS Orchestrator can cause service disruption and data loss. Yet, in a multi-tenant environment, security implications that may arise due weak isolation between tenants may allow adversaries to compromise more than one tenants upon compromising one of the other tenants. Furthermore, a DoS attack may be launched from within the SC [11].

Tenant data integrity violation: Some data or code, including various configuration settings and security policies, can be altered. This is a particularly important issue in a virtualised multi-tenant environment. It must be taken into account that some tenants could be malicious. Hence, adequate data isolation for different tenants must be ensured. This could be done, for example at the database level or at the hardware level.

Tenant confidentiality violation: In some cases sensitive information of a tenant may be leaked and made available to the adversary or to a malicious tenant.

Degraded level of SCaaS protection: A possible effect can be the degradation of SCaaS infrastructure protection. This can be achieved, for example, by altering the security policies or switching to weaker cryptographic mechanisms.

Illegitimate access to SC/MEC resources: The adversary gains illegitimate access to the SC resources (physical or virtual) or MEC environment. Given the increasing trend of outsourcing data and applications, an adequate security solution must ensure that only authorised entities gain access. Also, the insider threat should be considered and appropriate mechanisms must be put in place for preventing service providers form misusing tenants’ data.

In Fig. 2, we show, in the form of a directed graph, an example of possible dependencies of these categories. For instance, to cause DoS, the adversary could select VM/VNF infection as an attack method. To achieve that, malware could be injected in the management system (e.g., to the VRM or the VNF Manager in Fig. 1), a VM-hosted OS, or a MEC-based application (i.e., by compromising a MEC server), which constitute the potential attack targets. To target, e.g., the VM-hosted OS, the adversary could possibly exploit the SDN controller weaknesses or flaws of NFV platforms, and take advantage of any privileged access rights.

4 Conclusion

In this paper, we have identified the most important security challenges of SCaaS in virtualized environments of 5G networks. We envision that novel technologies, such as NFV, SDN, and MEC will be adopted in the future and will play an important role in the SCaaS realization. We have summarized the main security challenges that (i) open up with these technologies and (ii) arise due to the interoperability among them, which enables SCaaS. We have highlighted the necessary conditions for the adversary to be able to launch an attack; the vulnerabilities of various system components and network interfaces that can be exploited by the adversary; potential targets of attacks, such as management systems and applications; various methods and techniques that can be used by the adversary; and finally, the impact of the attacks on an SCaaS provider and its tenants. In future work, we intend to study and evaluate prominent security solutions developed for protecting virtualized SC networks and systems per se, focusing on NFV, SDN, and MEC. This security assessment will use this paper, here, as a basis.