Chapter 11. Security

Security is top-of-mind for Telcos and specifically mobile operators. Security violations lead to downtime which goes against the high availability requirements of Telcos. There are stringent security requirements that is stipulated by most local governments where EPC (3G or 4G) is deployed. Any network or cloud deployment needs to be protected from malicious attacks. The key difference is that in the past we used proprietary hardware and even protocols which were harder to hack.

In context of vEPC “Lawful/Legal Intercept” (LI) comes to mind. Many governments require service providers/operators to be able to identify the subscriber based on request and furthermore, “Camp-on” that subscriber’s session to be able to track messaging or data that is being transmitted on that session. The government could also request triangulation of the subscriber to obtain the location of the subscriber in certain cases. In the past EPC/MPC (Mobile Packet Core - 3G) ran on dedicated hardware where sensitive information about subscribers were mostly passed between blades of chassis in most instances. The LI packets would be traversing the backplane of the EPC/MPC hardware and not in any danger of being exposed to hackers. With the advent of virtualization and cloud, the VMs that constitute the vEPC VNFs could span several servers spread across the cloud. vEPC typically would be deployed on private cloud opposed to public cloud such as AmazonWedb Services(AWS) and Microsoft Azure. However, MVNOs could obtain access to certain applications “as a Service” which could bring public cloud into context. The LI packets that traverse the cloud would now have to be encrypted due to their sensitive nature. This may have significant impact on packet throughput unless specific steps are taken to use dedicated hardware with sufficient horsepower to perform the encryption/decryption and in some cases even use hardware assist.

Mobile operators go through numerous measures to ensure the environment in which vEPC runs is secure. This includes but not limited to:

  • Using rack-mount servers instead of blade servers . This is done by some operators as they require console access to the physical servers. Blade servers use virtual consoles. If and when a VM is compromised if all else fails, the operator may chose to use this Out Of Band (OOB) access the server and shut it down
  • Create zoning . The operators may employ zoning to segregate portions of the datacenter (servers) that house and deal with sensitive information such as subscriber database, policy servers etc into a “Secure Zone”. Only control plane data typically requires access to the secure zone. Data plane is separated into its own zone. Firewalls are employed between zones to minimize exposure to security threats and hacking.
  • Hardening hardware and software : Service providers/Mobile operators require NEPs to provide hardware and software that is hardened and less susceptible to security threats. Additionally installing software updates and patches on a regular interval and conducting security audits is required.

Platform Hardening (Hardware, Host OS and OpenStack) is not new to service providers. Mobile operators should apply the same procedures and ensure security best practices are applied up and down the stack from application all the way to the hardware, layer by layer.

11.1. Operational Best Practices

Security cannot be an afterthought. It is very hard to go back to a completely open environment and plug holes. It needs to be thought through along with the architecture and design of a network. This requires security operational procedures to be agreed upon, documented, maintained and implemented. This includes but not limited to:

  • Physical security: Who has physical access to the datacenter. Even within the datacenter, it is important to partition racks that belong to groups and create barriers or cages that only those groups have access to. Sometimes the racks may be in Co-Los (Colocated in shared datacenter also known as “hoteling”)
  • Limiting access: Many Telcos will allow changes to be made to servers and network equipment to a very small set of individuals. Others will to open a ticket to get this done. Often the servers/switches can only be accessed is through jump-servers or known hosts. Additionally, there are several levels of privileges that are assigned and controlled using AAA/Radius servers. Just because someone can logon to a server/switch they cannot make configuration changes or cause damage
  • Audit Trails: All access to servers/switches should be logged with accurate timestamps and details of individuals who execute commands and what commands were executed.
  • Credentials: Most Telcos implement complex passwords and require these password be changed periodically. In some cases the passwords are assigned by the Telco to the users/admins and cannot be modified.
  • Monitoring: Syslogs, SNMP traps and log messages have to be proactively monitored for security violations such as repeated password failure or someone trying to access something that they are are not authorized to.

11.2. Hardware and Software

  • Hardware: Server and switch firmware, BIOS etc have to be known certified quantities. Additionally NIC level settings such as which port is allowed to PXE boot etc should be controlled. There are some things to be aware of with hardware:

    • PCI passthrough uses DMA to speed up transfers and allows access to physical memory on the host. If compromised due by using a rogue firmware, it can potentially cause damage.
    • Infected hardware is hard to manage, reset etc and may result in running the virtual machines in an unsecure environment.
  • Host OS and Virtualization: The hypervisor can become a weak link. If it has vulnerabilities, attacks can be launched starting from the guest VM, breaking out using this vulnerability in the hypervisor, replicating itself. If it reaches the host, it can access other tenants as well. It is important to proactively harden QEMU and KVM by maintaining uniform code base, using compiler hardening, and access control using SELinux. We should keep in mind that while the beauty of NFV is to mix and match VNF vendors it can also become a security bottleneck as not all vendors would have gone through the same high level of hardening and taken precautions as others. Many hypervisor vendors including Red Hat have achieved Common Criteria Certification - Identification and Authentication, Audit, Role-Based Access Control etc. Details of this topic can be obtained at http://docs.openstack.org/sec/
  • Cryptography: Several options are available within OpenStack to use cryptography for various activities such as identification and authorization, data transfer and protection of data at rest.

ETSI provides detailed guidelines on security and platform hardening for NFV. This can be found in “ETSI GS NFV-SEC 012 V0.0.13 (2016-11)” and related documents.

The OpenStack security project issues Security Advisories (OSSA) and Security Notes (OSSN) which operators, infrastructure providers as well as NEPs who provide VNFs should pay attention to.