Securing the 5G Core (5GC) and Evolved Packet Core (EPC) with Cisco Security White Paper
Available Languages
Contents
2. Applying zero trust methodology
Zero trust workforces and Data Control Network (DCN) access security
Before and after zero trust packet core access security
Determining normal traffic flows (visibility)
Configuring the policy (enforcement)
Zero trust workloads and servers
This paper discusses how to secure the packet core for 4G (also referred to as the Evolved Packet Core [EPC]) and 5G Core (5GC) using the concept of zero trust security. A zero trust security policy proposes that organizations should not trust anything inside or outside of their network perimeters and should instead verify anything and everything that tries to connect to applications and systems before granting them access. Simply put, no traffic inside a network is any more trustworthy by default than traffic coming from the outside and it is up to an organization to determine under which conditions they decide to trust something—a user or a device—prior to granting access.
Traditional networks are based on defined perimeters, where most of the mobile packet core functions are centralized. The evolving mobile packet core architectures such as 4G control plane and user plane separation (CUPS) and 5GC using Multi-access Edge Compute (MEC) create software-defined perimeters. The 5G core is based on a cloud-native architecture with the 5G core network functions being deployed as a microservice in a private data center of the service provider or in a public cloud such as Amazon, Azure, Google Cloud, etc. Multiple vendors will supply Network Function Virtualization Infrastructure (NFVI) components, Virtualized Network Functions (VNF), and many contractors and sub-contractors will require access to the network for support, configuration, and deployment purposes. Many of the interfaces in the 5G core rely upon web-based communications, including the Representational State Transfer (REST)-based API, which doesn’t have any predefined security methods, so developers would need to define their own. The previously mentioned threat vectors and threat actors in 5G drive a requirement of having a robust security foundation while deploying 5G networks.
Zero trust security for the packet core consists of multiple layers of security, establishing trust in user identity, enhanced end-to-end visibility, and trustworthiness of the user device. Enforcement using risk-based and adaptive access policies while enabling secure connections to devices and applications may then be undertaken.
The main models within zero trust security for the mobile packet core are as shown in Figure 1.
Establishing trust in user identity may be enabled through the use of multifactor authentication (MFA). Password re-use and sharing is commonplace and using a static username and password creates a potential security risk. Many service providers today allow multiple contractors and users from a vendor or a contracting company to log in to their infrastructure using a static username and password, which could lead to the credentials being used by unauthorized people.
Enhanced visibility provides the ability to identify and correlate information from the carrier cloud to baseline-correct behavior and then to measure deviation from that norm. Trustworthiness of the user device may be summarized as the trust for both the user identity and the device being used to access the infrastructure. It is important to note that the trustworthiness decision for both users and devices takes place before a user is allowed access to the application or infrastructure. For example, if a user has the right credentials, but is trying to log into the service provider network from a device that in some way doesn’t meet the minimum criteria set by the service provider, they’ll be denied access.
Risk-based and adaptive access policies provide a control mechanism and the security policies for the users and devices. Some controls are taken proactively, while others are applied after an attack takes place. There are two types of attacks: zero-day attacks are threats that are previously unknown, and day-one attacks are threats that have been communicated by the vendor but have not necessarily been patched in the production environment. Typically, deviations in known good behavior of the carrier cloud and applications that request service and state from it are identified by the security controller and some action is then taken to mitigate the attack or to gain additional visibility. An action is then taken to properly identify the miscreant and mitigate the risk. Day-one or n-day attacks are attacks where publicly acknowledged vulnerabilities are leveraged before the vendor releases the security patch or the customer has applied the security patch to mitigate the vulnerability. These attacks can be reduced by ensuring that the latest patch is applied to minimize damage caused by the vulnerability exposure.
Secure connections to devices and applications may be augmented with adaptive policies, trust in user identities, and trustworthiness of devices. This shifts access decisions from the network to the applications, which is a core tenet of a zero trust security model.
In the rest of this paper we will see how each of the three main components of zero trust security—zero trust workforces, zero trust data, and zero trust workloads and servers—are managed by the Cisco® recommended security architecture.
2. Applying zero trust methodology
Zero trust workforces and Data Control Network (DCN) access security
We have thus far focused on applying a zero trust principle to the control plane and user plane interfaces of the packet core elements; however, it should be noted that other aspects of the packet core have an impact on the overall security posture in this environment:
The Data Control Network (DCN) provides management access to the packet core elements and is predominantly used by Network Management Systems (NMS) as well as third-party vendors for troubleshooting access and for internal command-line access for configuration and troubleshooting.
Typically, the DCN provides:
● VPN remote access for third-party vendor troubleshooting and for internal remote support
● ‘Grey’ management Virtual Routing and Forwarding (VRF) for transport across MPLS cores
● Routed and switched network infrastructure for DCN traffic (e.g., logging, configuration, and performance management)
● A proxy or “jump-host” to break external communication and provide proxied access
● Logging and reporting of user access and commands issued by each user
● Out-of-band access to Lights-Out Management (LOM) and console ports (terminal server access)
Vendor access into the DCN to provide support assistance is a normal requirement; however credential re-use (sharing a single password for multiple people within the vendor) and the potential for staff churn are all risks that potentially allow unauthorized access to devices. This can be mitigated through the use of a VPN concentrator in combination with multifactor authentication (MFA) technology.
Once ‘vendor A’ has authenticated and is allowed onto the DCN, it is not uncommon that they would have unfettered access to all the devices connected to the network (i.e., vendor B, C, and D management interfaces). In a zero trust methodology we would wish to limit vendor A to only being able to access elements that they need to support, also limiting the protocols allowed on that interface.
Visibility plays a key part in understanding security and can be enabled on the DCN through extensive logging of activity via RADIUS and TACACS+ with a focus to ensure that log data is able to be stored for a long enough period for forensic investigation purposes. Understanding network traffic profiles and potential data exfiltration may be achieved by Cisco Stealthwatch®, which is able to automatically baseline normal traffic and identify data being exfiltrated.
Figure 2 shows an example of a service provider DCN and multiple remote users accessing the service provider’s network resources. The network has multiple personnel (employees, vendors, contractors, and sub-contractors) accessing the infrastructure, which includes multi-vendor NFVI, multi-vendor VNFs, and containers for various provisioning, operational, and maintenance purposes.
To prevent malicious actions intentionally and unintentionally, there are three steps through which the operator could deploy a zero trust security architecture in the mobile packet core. They include:
1. Install a VPN layer
2. Implement multifactor authentication and segmentation
3. Enhance visibility and threat mitigation
Step 1. Install a VPN layer
As the first step, a Virtual Private Network (VPN) could be used for any external access to the service provider’s DCN. VPNs use the IPSec protocol suite for encryption of packets, authentication, and anti-repudiation. Figure 3 shows where a VPN is typically deployed in a service provider’s infrastructure.
Cisco AnyConnect® VPN includes protocols for establishing mutual authentication between agents at the beginning of a session and negotiation of cryptographic keys to use during the session. It can protect data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host). Internet Protocol security (IPsec) uses cryptographic security services to protect communications over IP networks and also supports network-level peer authentication, data-origin authentication, data integrity, data confidentiality (encryption), and replay protection.
Step 2. Multifactor authentication and segmentation
The next step is to deploy the policy control and enforcement layer along with the Multi-Factor Authentication (MFA) layer using Cisco Identity Services Engine (ISE) and Duo Security. Cisco ISE is a Network Access Control (NAC) solution and DUO is a multifactor authentication (MFA) solution. Figure 4 shows how ISE and DUO work with the network infrastructure.
The user authenticates to Cisco ISE and the device is verified to make sure it is authorized for access to the requested area of the network. The switch or Wireless LAN Controller (WLC) tags (with a Secure Group Tag [SGT]) the traffic. Then the policy is enforced on the data center firewall with a Cisco Security Group Firewall (SGFW) that allows EPC and 5G core resources (hardware and VNFs) access only to those devices and users that are authorized; all other devices and users are denied access. SGTs are applied to authenticated users in order to explicitly allow access for authorized users by using security group access control. Using the Security Group Tag (SGT), we are able to group each vendor’s access and control access to network and application resources on a granular level.
In this example, Duo integrates with a Cisco Adaptive Security Appliance (ASA) VPN to add two-factor authentication to any VPN login, thereby providing and enforcing access security policies based on user, device, and application risk, and verifying the identity of all users. This integrated solution provides security admins with the ability to enforce consistent user and device-based policy for VPN access and thereby reduce the risk of data breaches while meeting compliance requirements. Additional differentiators of Duo are explained in the section, “Before and after zero trust security.”
Step 3. Enhanced visibility and threat mitigation
Cisco Stealthwatch uses Cisco Platform Exchange Grid (pxGrid) to obtain user session information for populating tables, and for taking Adaptive Network Control (ANC) mitigation actions on the endpoint, including quarantining endpoint devices.
Stealthwatch Management Console (SMC) will successfully connect and register with the ISE pxGrid node and subscribe to the ISE pxGrid node Session Directory Topic to obtain the MAC address, IP address, last active time, user name, security group, VLAN, domain name, interface device IP, and interface device port ID. (At the command line these attributes are: macaddress, ipAddress, lastActiveTime, username, securityGroup, vlan, domainName, interfaceDeviceip, and interfaceDevicePortId). These attributes are mapped to the MAC address, endpoint IP address, start active time, user name, security group ID, VLAN Active Directory (AD) domain name, NAS IPC address, NAS port ID in Stealthwatch. These key pieces of information, coupled with network visibility, allow Stealthwatch to provide key insights into endpoint behavior and identity.
In addition to integration to ISE, Cisco Stealthwatch is able to analyze encrypted traffic using the Encrypted Traffic Analysis (ETA) feature without decrypting the encrypted traffic. This is particularly relevant when the level of encrypted traffic is rising on all networks. Figure 5 illustrates the integration of ISE with Stealthwatch on the network.
These three steps can help ensure that service providers authenticate users, and continuously monitor and govern their access and privileges. It also provides a method to secure and verify users, user access, and privileges as they interact with the mobile packet core, thereby mitigating malicious actions and intent.
Before and after zero trust packet core access security
Figure 6 shows access without zero trust access installed.
Vendors and subcontractors from various companies can access the servers and VNFs of other vendors and cause unintentional or intentional network impact.
Vendors and subcontractors from various companies can access only the authorized servers and workloads, thereby preventing any malicious attacks.
Furthermore, the Duo network gateway (requires a Beyond DUO license) gives the user granular access control per web application, a set of SSH servers, and user groups. Different policies can be configured to make sure only trusted users and endpoints are able to access internal services. Duo checks the user, device, and network against an application's policy before allowing access to the application, thereby providing tighter control on the network and application access.
Traditionally, security has been applied at the perimeter of a network with hosts and devices within the ‘trusted’ network being given the ability at a network level (IP connectivity and protocol port) to communicate freely. It has been shown historically that this approach allows for threat actors to more easily discover the network topology and pivot across devices to achieve their goal should any of the internal hosts get compromised.
The zero trust concept suggests that we should provide the minimum amount of connectivity that is possible between all hosts and devices without impacting functionality, and should allow for enhanced visibility to prevent any data exfiltration. For a mobile operator, this process may be applied to the MPC/EPC/5GC to provide enforcement between packet core elements. An example of this is illustrated in Figure 8.
A set of rules has been identified as to which flows are valid to and from the Mobility Management Entity (MME) between identified devices using specific protocols and ports. This policy would be centrally configured and enforced within the underlying network that provides connectivity to the packet core elements.
Previously, the complexity of gaining visibility into what connectivity is valid and normal, creating policy across many different network devices, and then configuring access controls across many network devices, has been one of the main obstacles to an implementation of this type.
Cisco have solutions capable of dynamically learning what is normal behavior for the network, and create a centralized policy that can then be dynamically pushed out to the network infrastructure to enforce security posture. In addition, the 3GPP has also published packet core connectivity information, which may aid with this initial policy configuration.
Determining normal traffic flows (visibility)
The first step in implementing a zero trust packet core is to understand what policies need to be adhered to and what level of granularity of enforcement is going to be configured. The following controls are available:
Source IP Address - A specific /32 address, a subnet or a range of addresses
Destination IP Address - A specific /32 address, a subnet or a range of addresses
Protocol - TCP- or UDP-based transport protocol
Src Protocol Port - Source protocol port (0-65535)
Dst Protocol Port - Destination protocol port (0-65535)
The protocol ports are separated into three distinct groups:
Port range 0->1023 – well known / system ports reserved by IETF or IESG (Telnet, FTP, etc.)
Port range 1024->49151 – user / registered ports managed by IANA (RADIUS, GTP-C/U, etc.)
Port range 49152->65535 – dynamic / private ports
We can use the following methods to determine the policy to be implemented:
1. Static configuration based upon vendor documentation or published 3GPP information. Here, we are creating the policy based upon what we know should be happening. Once the policy is configured in Cisco ISE we can deploy in a monitor mode to identify what traffic might be blocked to check our policy before moving into an enforcement mode.
2. Using Cisco Stealthwatch to analyze the network traffic between the elements allows us to model what is normal and presently happening on the network. We can then translate this model into a policy within Cisco ISE. Cisco has a selection of pre-configured EPC, MPC, and 5GC Stealthwatch templates available to provide visibility, logging, and alerting of traffic flows.
3. Cisco ISE can be configured with a log-only option, whereby we can identify what traffic is present and would be dropped should an enforcement policy be applied. This information allows us to determine what policy needs to be implemented.
In most cases, a starting point of vendor information, Stealthwatch templates and 3GPP-published communication models will be used and refined for each specific use case prior to enabling enforcement mode.
Configuring the policy (enforcement)
The first step is to configure a basic policy template to determine which elements we would like to communicate together. Figure 9 shows the MME communication policy we described earlier (see Figure 8).
We are then able to add further granularity by specifying what will be allowed or blocked based upon the transport protocol type and protocol ports used, as shown in Figure 10. (There is an implicit ‘deny-all’ after the ALLOW.)
We are now able to configure each of the element types by simply adding each type’s IP address into ISE and assigning it to a group (i.e., MMEs, Serving GPRS Support Node, Home Subscriber Server, Packet Data Network Gateway).
Once we have configured a policy in Cisco ISE and assigned our packet core elements into each of the relevant groups we are ready to enable enforcement of the policy. It is normal to enter a non-blocking mode where we would monitor what would be blocked should the policy be set to enforce as a means of checking our policy is correct at an initial phase. Once we have confirmed this we would then move into a blocking mode.
Cisco ISE communicates with the network fabric (routers, switches, firewalls) to program the configured policy. This single, centralized policy rollout reduces the amount of effort required to enforce security across a network and reduces the potential for human error.
Segmentation and control are facilitated by Cisco TrustSec®, which is an IETF standard for software-based segmentation. Each element is assigned a Security Group Tag (SGT), which determines what can communicate based upon the policy. ISE uses the SGT over Exchange Protocol (SXP) to send policy information to the network devices, programming the policy across many devices automatically.
Applying this methodology allows enhanced visibility in the control plane within the packet core. The same security architecture can also be applied in the 5G core, where the communication between the packet core elements are using Application Programming Interfaces (API) in the Service-Based Architecture (SBA), which can be consumed by Stealthwatch using API calls from the Network Resource Function (NRF) component to detect any anomalies.
Zero trust workloads and servers
In the evolving architecture towards 5G and the new Service-Based Architectures (SBA) there are new interfaces that need to be secured (see Figure 11).
For the MEC deployments, we will see multiple Gi/SGi and N6 Direct Internet Access (DIA) interfaces and API-based interfaces to other applications. Apart from the Gi/SGi and N6 interfaces, the 5G cloud-native architecture includes lawful intercept, billing, and charging systems.
In service provider networks, the orchestration layer uses a policy-driven approach to automate the network resource allocation to deliver a service or an application. Orchestration allows networks to scale as needed, enables network services to be provisioned across multiple devices, and makes it possible to deploy resources as needed, thus making the network more agile and responsive. An API is the most common interface for interactions between the EPC and 5GC to the orchestration layer. An API is a set of tools and protocols used to develop application software. This interface-predefined request–response message system exposes reliable content and operation negotiation (typically expressed in JSON or XML). Figure 12 illustrates ways to secure interfaces.
Web Application Firewall (WAF) and API gateways are the two major inline security tools for API protection. While API gateways do usually offer authentication and authorization features, the HTTP and OWASP Top 10 protection offering is either limited or absent. To protect API-based communications, a Web Application Firewall (WAF) can be used to ensure APIs are secured.
To provide enhanced visibility on the packet core (EPC and 5GC), Cisco Stealthwatch gives network-wide visibility from the private network to the public cloud, and applies advanced security analytics to detect and respond to threats in real time. It continuously analyzes network activities and creates a baseline of normal network behavior, then uses this baseline, along with advanced machine-learning algorithms to detect anomalies. However, not everything unusual is malicious, and Stealthwatch can quickly and with high confidence correlate anomalies to threats such as C&C attacks, ransomware, DDoS attacks, illicit cryptomining, unknown malware, as well as insider threats. With a single, agentless solution, you get comprehensive threat monitoring across the data center, branch, endpoint, and cloud, regardless of the presence of network encryption. Sensitive data exfiltration could also be mitigated by Cisco Stealthwatch as it provides specific alerts based on suspected events.
To secure the applications and to prevent the migration of the threats between the virtual components of the infrastructure, Cisco Tetration Analytics™ collects and stores all of the data flows, which allows the user to search them in a flexible manner. This significantly reduces the mean time to investigate and solve problems. Tetration provides an application behavior-based mapping of processes and flows based on unsupervised machine learning from within the Cisco Big Data Platform. Because we are collecting all of the flows north-south and east-west, we built intelligence into the system so that it can map and group your applications autonomously. Tetration acts like a DVR in that it allows you to replay packets from a historical perspective to validate potential network or application changes prior to actually making the change. It provides a powerful assessment so you know with a high level of confidence if proposed policy changes could have an undesirable impact upon the environment.
After policy simulation and impact assessment, Tetration will provide an automated allowed list policy that can be exported and deployed within your infrastructure for a true zero trust model. Tetration will continue to ingest telemetry from the sensors to provide policy compliance of the network infrastructure and auditability of all traffic flows.
Secure Hardware & Software
Cisco Trust Anchor Technologies start with standards-based technology and add security functions and features, providing cost-effective and efficient solutions for the protected product. Cisco’s Secure Boot implementation not only provides a secure boot of signed images, but also anchors a root of trust into hardware components. The hardware components that start the chain of trust can perform both system-critical functions and security functions, including proactive monitoring of the startup process and a shutdown of the process if tampering is detected. The fundamental concepts of Cisco Trust Anchor Technologies are image signing and trust chains, which includes digital signing, trusted element verification, root of trust and chain of trust, immutable identity, highly secure storage, data-at-rest encryption and decryption, strong random number generation, and entropy source.
As new cyber security risks and challenges emerge, it is more important than ever for industry-leading IT vendors to work with their customers to establish trustworthy, transparent, and accountable relationships. Cisco is committed to these principles. In response, Cisco created Technology Verification Service, which provides customers with the ability to review Cisco technology in a secure, dedicated Cisco facility. Cisco offers customers the chance to review a wide range of assets. Hardware, software, firmware, schematics, technical documentation, Bill Of Materials (BOM), Application-Specific Integrated Circuit (ASICs), and Field-Programmable Gate Arrays (FPGAs) are all available for in-depth review.
Cisco’s Secure Development Lifecycle program is designed to mitigate the risk of vulnerabilities and increase the resiliency of Cisco solutions. And our dedicated Product Security Incident Response Team (PSIRT) manages security vulnerability information related to Cisco products and networks.
The EPC and 5GC are critical parts of a mobile operator’s infrastructure, which encompasses a diverse range of technologies—from legacy signaling protocols to the latest distributed, virtualized environments which includes multi-vendor NFV & multi-vendor Virtual Network Functions (VNF) based of virtual machines and containers. This broad attack surface creates gaps in the security posture that can be addressed, as shown in Figure 13, through the use of trusted platforms, visibility solutions, and limiting communication in line with the zero trust methodology.
Additional resources
Cisco 5G Security Innovation white paper
Zero Trust
https://www.cisco.com/c/en/us/products/security/zero-trust-network.html
Cisco Duo Security
https://duo.com/partners/technology-partners/select-partners/cisco
Cisco Stealthwatch
https://www.cisco.com/c/en/us/products/security/stealthwatch/index.html
Cisco Identity Services Engine (ISE)
https://www.cisco.com/c/en/us/products/security/identity-services-engine/index.html
Software defined Segmentation (TrustSec)
https://www.cisco.com/c/en/us/solutions/enterprise-networks/trustsec/index.html
Cisco Tetration
https://www.cisco.com/c/en/us/products/data-center-analytics/tetration-analytics/index.html
Cisco Trust Anchor Technologies
Feedback