Layering is a well-known strategy for security. By using layers, we increase the difficulty of penetration and reduce the impact of a failure at any given layer.

Here are some guidelines for applying layered security to universal customer premises equipment (uCPE) deployments. The uCPE layers include the platform layer (including management, virtualization, and networking), the application layer, and the management and orchestration (MANO) layer.

As a reminder, uCPE consists of software virtual network functions (VNFs) running on a standard operating system hosted on a standard server. An ideal uCPE deployment supports a multi-vendor multi-component construction, underscoring the need for security at multiple layers.

(*Please, excuse the not-so-subtle play on the title of the 1955 film “Love is a many-splendored thing.”)

Platform-layer security: management
 

Security starts at the platform layer, which provides a foundation for the other security layers. Let’s start with the needed features to secure management of the platform:

• The command line interface (CLI) must support role-based access across multiple privilege levels, limiting access to certain commands
   
• Root operating system login should be blocked on Ethernet ports and serial ports
   
• SSH key-based logins should be supported to eliminate password exposure
   
• The system should have the ability to enable/disable accounts, and to lock-out accounts in the case of multiple failed logins
   
• Use an embedded cloud architecture to minimize the attack surface
   
• Radius and TACACS+ authentication options should be supported
   
• Use available tools to enhance security: automated scans of source code, automated scans of network ports, application of required patches

Platform-layer security: virtualization layer and VNFs
 

Next, we need to secure the virtualization layer of the platform, including the VNFs. Here we assume that the VNFs are running in virtual machines (VMs). Most of the same considerations also apply to containers.

The first set of requirements protect against VNF escape, i.e. they protect the VNFs from one another:

• VNFs should be run as VMs rather than containers, limiting exposure of the VNF to host exploits
   
• VMs should be executed as the “qemu” user (i.e., non-root), thus limiting inherited privileges
   
• Each VM should be a unique Linux process so the VM cannot access memory allocated to another process
   
• Each VM should be assigned a specified CPU and RAM quota, ensuring resources remain for system management
   
• Network traffic isolation should be enforced to ensure that a VM with a promiscuous network interface cannot see traffic from other VNFs or the management plane across the vSwitch

The next set of requirements prevent rogue management system connectivity to the hypervisor:

• Management access to vSwitch interfaces should be subject to normal user account management and authentication
   
• Once authenticated, the platform should provide an authentication token string that must be supplied in the “X-Auth-Token” header for all subsequent API calls and defines the unique session
   
• Persistent per-session functions, such as configuration locks, should be tied to this token
   

Finally, there should be support for VNF attestation confirming the integrity of running VNF matches VNF image stored. This prevents the execution of a corrupted image.

Platform-layer security - networking and physical
 

Next, we must ensure that networking is secured. Requirements include:

• The platform should implement a variety of networking options, including E-LAN, E-Tree, and multiple secure VRFs
   
• Service chain segments should be built as E-LAN services within the vSwitch. Isolation between tenants in the cloud network is ensured by VLAN isolation
   
• For Layer 3 forwarding, the platform should support VRF instances, each of which is a unique and isolated forwarding entity that uses independent route tables and ARP tables for isolation
   
• The management network should be secured by interfacing into standard security gateways using IKE
   
• Management firewall protection should be assigned to all types of physical/logical interfaces. Doing so prevents unwanted VNF data plane connectivity into the carrier management network
   
• The platform should support a wide range of open servers, including those with RF shielding to limit emissions and anti-tamper devices to support security certifications such as FIPS
   

Application-layer security
 

The point of a secure platform is to host VNFs to construct a service. We also need to ensure security of the services supported by those VNFs:

• The platform should provide software-based encryption of data plane traffic at Layers 2, 3, or 4
   
• The platform should be optimized for performance so it can support compute-intensive VNFs such as best-of-breed firewalls or unified threat management (UTM) systems
   
• The VNFs should be built with the same considerations listed above for platform-layer management security

MANO-layer security
 

The final piece of the puzzle is to provide security at the MANO layer. Requirements include:

• Enforce 2-factor authentication for turnup of uCPE at the customer site
   
• Provide encryption of management and user tunnels
   
• Support TACACS+ authentication options
   
• Provide multi-tenant MANO that segregates inventory, config and control traffic, and that provides role-based access
   
• Enforce encryption of locally stored passwords
   

Putting it all together
 

Service providers want to gain the benefits of the cloud by assembling multi-vendor systems based on the uCPE deployment model. By implementing the requirements listed above, they can maximize those benefits while minimizing the exposure to security threats. That’s a many-splendored result!

For more articles by Prayson Pate on Technically Speaking, please see: http://blog.advaoptical.com/en/About/prayson-pate.aspx