5G Security Assessment Process Guidelines

2022.09.08
5G Security Assessment Process Guidelines
On May 26, 2022, the U.S. Department of Homeland Security's Science and Technology Directorate, Cybersecurity and Infrastructure Security Agency, and the Office of the Secretary of Defense Research and Engineering jointly released the 5G Security Assessment Process Guidance.

On May 26, 2022, the U.S. Department of Homeland Security's Science and Technology Directorate, Cybersecurity and Infrastructure Security Agency, and the Office of the Secretary of Defense Research and Engineering jointly released the 5G Security Assessment Process Guidance. This guidance is not a new security requirement or framework, but a five-step security assessment process for government agencies to assess whether their 5G system security levels meet production requirements, building on outcomes such as existing standards frameworks. This process requires flexibility in the federal government's approach to 5G cybersecurity assessments to account for the continuous introduction of new 5G standards, deployment of capabilities and policies, and the continuous identification of new threat vectors. Federal agencies use this process to assess, understand, and address security and resiliency assessment gaps in their technology assessment standards and policies.

The standards for the first and second phases of fifth-generation (5G) cellular network technology have been completed, and cellular operators are rolling out 5G services. Federal agencies have used mobile wireless networks for years; however, prior to the advent of 5G, agencies tended to view cellular networks only as conduits for transport-layer communications. After the emergence of 5G, agencies hope to expand the different usage scenarios of 5G, that is, the spectrum of low, medium and high frequency bands. However, transitioning an unclassified federal system from prototype to production requires a security assessment to obtain Authorization To Operate (ATO). Because the deployment of 5G Standalone (SA), Mobile Edge Computing (MEC), and network slicing is still in its early stages, it is important for the federal government to understand and study 5G before widespread deployment of 5G services and capabilities by mobile operators. services and functions, which can pose challenges to system security. For governments, a flexible, adaptive, and repeatable approach is needed to assess the security and resiliency of any 5G network deployment. Additionally, the approach requires evaluating systems for compliance with existing federal cybersecurity policies, regulations, and best practices to address known attack vectors, undiscovered threats, and vulnerabilities in specific implementations.

On May 26, 2022, the U.S. Department of Homeland Security's Science and Technology Directorate, Cybersecurity and Infrastructure Security Agency, and the Office of the Secretary of Defense Research and Engineering jointly released the 5G Security Assessment Process Guidance. This paper explores the uniqueness that 5G brings to security assessment processes and frameworks, such as the traditional ATO process defined in the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) challenge. The work was developed by a team of researchers led by the Department of Homeland Security's Science and Technology Directorate, the Cybersecurity and Infrastructure Security Agency, and the Office of the Secretary of Defense for Research and Engineering, all of which are currently active in 5G research and security.

1. Background

When 5G networks are deployed on a large scale, upgrades to the core network infrastructure will be necessary. During a period of network infrastructure upgrades, rapidly evolving technology standards, dynamic global markets (including many new entrants to telecom markets), and an ever-changing and diverse threat landscape, governments must adopt flexible, adaptive, and repeatable approaches to Evaluate the security and resiliency of any 5G network deployment.

This paper proposes a five-step process for 5G security assessment, which can be widely applied to various 5G system architectures, deployment scenarios, and operating environments. Step one requires the use of use case definitions to identify the interfaces involved in the 5G subsystems, component configurations, applications, and system operations that are part of the system. The complexity of 5G technology makes the process of defining security assessment boundaries for the Federal ATO extremely challenging. Therefore, step two involves defining boundaries to identify technologies and systems that require Assessment and Authorization (A&A), taking into account the ownership and deployment of products and services that encompass use cases. After defining the assessment boundary, step three includes conducting an advanced threat analysis of each 5G subsystem to determine the need to address reduced cybersecurity capabilities through assessment and authorization (e.g., identity, credential and access management, network security, communications and interfaces Safety). Step four involves creating a catalog of federal security guidance that includes the RMF, NIST’s Cybersecurity Framework, Supply Chain Risk Management, the Federal Risk and Authorization Management Program (FedRAMP), other NIST and Federal Cybersecurity Guidelines, and related industry codes. Step five checks for alignment between safety requirements and federal safety guidance and assessment procedures. If security needs exist, but no assessment guidelines exist to guide A&A activities, gaps can be identified and alternatives developed to fill assessment gaps. For example, if federal assessment guidelines for Open Radio Access Network (O-RAN) are not available, international or commercial programs such as the O-RAN Alliance's Test and Integration Center Certification may be considered.

2. 5G Security and Threat Overview

2.1 5G Security

5G will serve more different types of devices and more use cases than 4G cellular technology. 5G introduces new functions and services, mainly including: (1) New Radio (NR) with enhanced performance, spectrum increase, spectrum sharing, and low, medium and high frequency band frequencies; (2) Services for a large number of users. New technologies, such as cell encryption and beamforming, can direct wireless communication channels to users and reduce interference; (3) MEC moves typical centralized applications closer to the network edge to reduce latency and maintain high data transmission speed and ingest large amounts of data; (4) network slicing can create multiple virtual networks that provide different quality of service levels on a shared physical infrastructure; (5) virtualized Radio Access Network (RAN) and 5G core to dynamically expand network capabilities.

The 3rd Generation Partnership Project (3GPP) is the main standard development organization for 5G and has made many improvements in 5G security. The main points are summarized in Table 1.

Table 1 5G Security Improvements (Standalone Architecture)

picture

Continuation table

picture

2.2 5G Threat Status

Threat analysis is a key element of any security risk assessment, and to help characterize threats and serve as a starting point for agencies to develop their own 5G threat models, the research team categorized potential threats. Understanding these threats helps enterprise risk managers prioritize security activities and the security capabilities needed to mitigate threats associated with 5G systems and subsystems within the boundaries of their 5G-enabled systems. Threat categories include:

(1) General network security threats. These threats affect all 5G subsystems, including misconfiguration, human error, failure to properly harden hardware and software, lateral adversary movement, information leakage, and general unauthorized access attacks. Misconfigured components or failed hardware and software hardening could be exploited by attackers to reconfigure 5G elements, direct traffic to attackers, or steal data.

(2) Virtualization threats. Threats to Virtual Machine (VM) and container service platforms affect 5G core, RAN, MEC, network slicing, virtualization, and orchestration and management Evasion, side-channel attacks, and cloud service consumer misconfiguration. In a multi-tenant virtualization environment, extreme resource consumption by one tenant can create a DoS event for adjacent tenant systems. This event can prevent or severely reduce mission functionality. Likewise, colocation attacks, such as virtual machine/container escape or side-channel attacks, can expose adjacent computing workloads to the risk of resource deprivation, lateral movement, and compromised data confidentiality, integrity, or availability. Side-channel attacks on the 5G RAN or core functions could lead to bypassing user account permissions, virtualization boundaries, or protected memory regions, exposing sensitive information.

(3) Network and management interface threats. These threats affect the network, management, and air interfaces of all 5G subsystems and include DoS, jamming, eavesdropping, address spoofing, traffic/message tampering, system/protocol discovery, inappropriate tenant communication isolation, and access control attacks. Air interface threats are located between User Equipment (UE) and RAN, and radio interference techniques can be used to cause interference, thereby preventing UE access or causing loss of 5G services. Virtualized/contained core network functions are deployed as tenants on shared cloud infrastructure, and improper isolation of communications between tenants can expose these virtual environments to unauthorized access or loss of confidential information (e.g. user data, network configuration, etc.) .

(4) Application and service threats. Threats related to 5G application and service delivery affect all 5G subsystems, including malware and malicious code injection, DoS and Distributed Denial of Service (DDoS) attacks, Application Programming Interface (API) ) manipulation, exploitation of software vulnerabilities and access control attacks. Endpoints such as smartphones are vulnerable to applications and malicious code that can expose private data to threat actors. Unprotected or vulnerable APIs in the MEC can lead to unauthorized access to the MEC's ​​applications and information and facilitate further attacks from within the network.

(5) Malicious elements. Threats from malicious UEs, malicious base stations or radios in the RAN, and malicious network hosts or spoofed components in the MEC can be used to attack 5G systems. For example, a malicious base station can use jamming to force a UE to use a malicious base station and then capture user information and location, while a malicious component in the MEC can compromise the MEC application, delete, alter or steal data.

(6) PRIVACY THREAT. Threats to UEs, RANs, and 5G cores involving the processing, sharing, storage, and communication systems of related information among 5G network users, including eavesdropping, user and device identifiers and location tracking, and user, protocol, and system spoofing attacks. Attackers can monitor the air interface between RAN and UE devices to extract unprotected unique device identifiers and track device users, while unauthorized access to user data stored in the 5G core can be used for identity theft or wire fraud.

(7) Environmental and physical threats. Vulnerabilities and vulnerabilities in environmental and physical access control systems, power outages, and natural disasters will affect the RAN, 5G core, MEC, and virtualization subsystems. Among them, physical access to ports, equipment and devices, natural disasters, electromagnetic pulses and power outages are the most important issues. In RAN, small batteries placed on lamp posts can be subject to physical theft or damage, while power outages or natural disasters can damage RAN nodes or 5G cores, rendering them inaccessible.

(8) Supply chain threats. Threats can occur during the provisioning, acquisition and integration of software, firmware and hardware components of the UE, RAN, 5G core and virtualization subsystems. Threats include the insertion of exploited or malicious components, exploited or malicious open source components, and attacks on vulnerable hardware, firmware, or operating systems. Malicious code injection into common code bases used to build system software for release into production can have serious operational implications, especially when the affected system has access to privileged user systems, such as for identity and access management or network health and Configuration management system. The inclusion of firmware/hardware components of unknown origin or security posture (eg in the UE or RAN) could introduce malicious or counterfeit components into these subsystems, resulting in the exposure of sensitive user and network data to adversaries.

(9) Threats of Artificial Intelligence/Machine Language (AI/ML). Threats to data integrity, confidentiality and availability of UEs (eg gateways for IoT or cyber-physical devices), RAN, coordination and management subsystems. These threats affect AI/ML software and systems, as well as network elements and services that rely on the accuracy, timeliness, and trustworthiness of data to make AI/ML-based decisions such as dynamic allocation of network functions. For example, broken code or fake, tainted data inserted into AI/ML algorithms used to perform algorithmic analysis functions will slow down the network, potentially impacting human safety (e.g., when using autonomous vehicles or smart city traffic management) ).

3. Proposed 5G Security Assessment Process

3.1 5G Concept Deployment Scenario

In the federal government, many early adopters of 5G opt for a private 5G network solution that can be tailored to specific security and performance requirements to support specific missions. Private 5G networks can be built and operated in a variety of configurations, from fully stand-alone solutions (on-premises + unlicensed/shared spectrum access + government-owned infrastructure + government operators) to hybrid government and commercial operational components, services "hybrid" solution. The example deployment shown in this article will be implemented through a new hybrid public-private approach using network slicing. The scheme uses a simple and practical configuration of components, services, and actors, and is not intended to serve a single task or application; instead, the network can be segmented to meet various application and task needs. Its key deployment details are described below.

(1) Network infrastructure. The private network will be delivered by the network operator, which is transported through the operator's public RAN and SA core network infrastructure. The network operator will acquire, install and maintain the RAN infrastructure (including towers, base stations and radios). Governments can choose to create subnets to support multiple tenant organizations, or by creating additional slices to meet unique application performance needs.

(2) Spectrum. The wireless portion of the private network will use spectrum offerings licensed by the network operator. For use cases that do not require high security or resiliency, increased network capacity can be achieved by sharing mid-band spectrum such as Citizens Broadband Radio Service (CBRS).

(3) Safety. The government must clearly define federal regulations and security requirements that meet local 3GPP security measures and features. Additionally, each network segment may require additional security enhancements and remote access controls, depending on the deployment scenario and associated mission risks. For example, operators can provide "end-to-end" security through their network slicing products, however, their security capabilities may not meet government security requirements or even require additional security mitigations. Government-provided smart devices will use software-based Public Key Infrastructure (PKI) certificates and be managed remotely by the enterprise's Unified Endpoint Management (UEM) system. Integration with government perimeter security solutions, zero trust architectures, or other wired/wireless networks and gateways can also add to the cost.

(4) Network management. The management and coordination of the RAN portion of network slicing will be exclusively controlled by the government. The fault, configuration, billing, performance and security functions of other layers may be applied to the RAN portion by the government or authorized contractors.

(5) Cloud computing. The government-operated portion of this example deployment does not include the MEC solution or any public cloud infrastructure or services. Network operators' data centers and edge cloud nodes are expected to perform virtualized network functions on commodity hardware.

3.2 Step 1: Define Federal 5G Use Cases

The first step in the process is to define use cases and 5G usage scenarios (enhanced mobile broadband, ultra-reliable low-latency communications, large-scale machine-type communications), including at UE, RAN, core, MEC, and related to interface systems and applications In the 5G reference design. Depending on the use case and its associated usage scenarios, the integration of 5G system elements and other systems and networks can be described. Defining a use case includes: (1) describing the purpose of the use case (e.g., connecting devices, wearables, environmental sensors, and building sensors to provide situational awareness to first responders); and (2) identifying the 5G usage scenarios that the use case encompasses. Many federal use cases will leverage 3rd Generation Partnership Project 5G use cases; (3) describe the systems, subsystems, interfaces, applications, endpoints, security, etc. required to support the use case; (4) provide the Details of 5G system models and reference designs, and interfaces to other systems, networks or applications.

Since the example network deployment scenario is a simplified optimal scenario, the following alternative deployment scenarios detail the potential impact on the security assessment process.

(1) Delivery of a dedicated 5G network. Hyperscale cloud providers are rapidly advancing the delivery of managed services to private 5G networks as an emerging market. These services include pre-configured network equipment and management system software that can be quickly installed into licensed spectrum and shared mid-band CBRS spectrum (available in the US only). Using this managed service does not simplify or reduce the effort required to evaluate individual devices (including SIM cards) and software components, but it can speed up the deployment of the network.

(2) Neutral Host Network (NHN). To reduce overhead and operating expenses, government sites with multiple tenant organizations can choose to share RAN infrastructure costs and outsource network operations to a qualified third party. Neutral hosts allow multiple organizations and users to share the network (including shared RAN and core networks). As network equipment and possibly spectrum will be shared, hardware footprint and infrastructure investment will be greatly reduced. As a result, NHN deployment will result in a simpler and faster security assessment process that may involve more stakeholders and increased administrative costs (eg MOUs, separate charges and billing).

3.3 Step 2: Determine Evaluation Boundaries

The complexity of 5G technology makes the process of defining security assessment boundaries for the federal ATO difficult. The second step involves defining boundaries to identify technologies and systems that require A&A, considering ownership and deployment of products and services that encompass use cases, and defining roles and responsibilities for the implementation, management, and monitoring of security capabilities. Once the assessment boundaries are defined, the security requirements to be addressed by the A&A activities can be determined. The boundary includes all components in the system that are authorized to operate, excluding the individually authorized systems to which the system is connected. Examples of boundaries include:

(1) a single boundary (such as a separate private network);

(2) systems within systems (e.g. shared network infrastructure with constituent/tenant systems);

(3) Mixed (eg public and private).

As examples of private 5G networks are currently defined, the evaluation boundaries are clear. Most of the public core network is located in the network operator's data center, and network traffic is segmented through end-to-end network slicing. Unique security needs may require a detailed assessment of core network elements, processes, and vendors. Otherwise, the assessment boundary may include network slices provided by operators, infrastructure construction and operation of government-operated RAN segments, and endpoint devices.

However, if a government tenant organization is assigned a government network slice subnet, the organization can get an MEC node to provide additional processing close to the network edge. The installation of MEC will introduce a threat vector that requires a security assessment. If the third-party MEC solution has its own management system, it will also be included in the assessment scope.

3.4 Step 3: Identify Security Requirements

The third step is a multi-stage step that involves conducting an advanced threat analysis of each 5G subsystem and identifying the cybersecurity requirements to be addressed by A&A activities. It requires a thorough understanding of the use case under consideration in order to provide context for evaluating the technologies employed within the boundary and all interfaces with external systems. This step includes performing the threat analysis and risk assessment defined in the RMF system-level preparation steps. In doing so, the focus is on individual 5G system elements and 5G connected systems.

To simplify the mapping of requirements, assessment strategies, and guidance, the security capabilities of the various threats summarized in Section 2.2 are categorized. For example, authentication, authorization, and least privilege access control are grouped under the Identity, Credential, and Access Management (ICAM) category, while intrusion detection, network segmentation, and port/protocol security are grouped under network security category.

3.4.1 User Equipment

Taking a private 5G network as an example, Government Furnished Equipment (GFE) smart devices are network terminals and are subject to a series of threats from inside and outside the government's private 5G network. Due to the pre-assessment of the security risks and vulnerabilities of GFE equipment, this step is mainly done for those equipment that are fully compliant with the security protection requirements and are up-to-date. GFE smart devices provide endpoint security, are managed by enterprise device management systems, and authenticate using personal authentication, public access card credentials, software-based credentials. The application of these security capabilities allows GFE equipment to be used immediately on government 5G networks, according to agency guidance. If non-GFE smart devices are to be introduced into private 5G networks, a thorough assessment of applicable hardware, ICAM, application, data and communication security requirements will be necessary.

3.4.2 5G Radio Access Network

Depending on system assessment boundaries and configurations, 5G RAN infrastructure can include infrastructure elements from one or more geographic locations and involve various network switches/routers, base stations, and access point/cell site equipment and software. For example, private 5G networks involve a local RAN segment with RAN slices to support multi-tenant applications. All hardware and software components, including cloud/edge platforms and internal and external system interfaces, are subject to threat and security capability analysis. Certain security conditions and assurance needs may require a broader investigation, possibly involving second-tier (and above) suppliers, and proof of completeness of each software bill of materials.

If the RAN segment adopts an open, classified RAN solution, there will be more Tier 1 suppliers (and their component hardware and/or software products) involved in this security assessment step than traditional RAN solutions. The level of interoperability and penetration testing will likely increase, as will the ability to identify and mitigate potential open RAN attack vectors.

3.4.3 5G Core Network

The 5G core network is the heart of the 5G system. It connects end users with services provided by the network through a reliable and secure connection. The basic functions provided by the 5G core network include user authentication and authorization, data connection, mobility management, user data management, policy management and control. Depending on the operator's network slicing implementation, this segmentation technique may alleviate some aspects of the core network's assessment results. However, since network slicing is a new technology, its threat vector is not fully understood, so further testing is required.

If shared spectrum access (such as CBRS spectrum) is incorporated into private 5G networks, additional steps will need to be taken to ensure that commercial operators are licensed and that appropriate traffic management is in place to achieve high guaranteed traffic on the licensed spectrum portion of the network. Additional measures may be required at the time of review.

3.4.4 Deployment Environment and Operational Responsibility Considerations

A system is more than the sum of its parts. The same is true when evaluating individual 5G system elements, there are additional security requirements and considerations that affect the overall assurance of an end-to-end system. When determining security requirements, it is also important to understand the intended deployment environment for the technologies involved and who will own and operate the systems in question. For example, the properties of the deployment environment may introduce additional risks or mitigations that can significantly impact the security posture of the network. Where base station equipment is located on government premises, physical access may be limited to authorized government and contractor personnel. If site-specific or deployment-specific attributes are accepted as system security capabilities, those attributes will be included in the assessment.

Additionally, as subsystem owners and operators adhere to their operation and maintenance policies, system security assessments must determine whether new vulnerabilities are introduced. If a system is built to be exclusively owned and operated by the government, then the system needs to be applicable to the government's cybersecurity requirements.

3.5 Step 4: Map Security Requirements to Federal Guidelines and Industry Specifications

Federal safety requirements meet the requirements enumerated in international industry codes. The fourth step involves creating a catalog of federal security A&A guidelines consistent with the technologies included in the assessment boundary and the implied security capabilities identified in the third step. For example, RMF applies to all categories of security capabilities, as well as other NIST and DoD networks related to ICAM, Supply Chain Risk Management (SCRM), data security, virtualization/cloud/container security, and cybersecurity protection Safety Guidelines. Federal systems may need to have the following auditable security capabilities:

(1) SCRM as defined in the Acquisition Policy, Executive Order, National Defense Authorization Act, and Executive Order 13556 (Controlled Unclassified Information);

(2) RMF as defined by NIST SP 800-37, NIST SP 800-53A, and DoD Directive 8510.01;

(3) Federal Information Processing Standards (FIPS) as defined by FIPS 199, FIPS 200, and FIPS 140-2/3;

(4) System hardening as defined by the Defense Information Systems Agency's Security Technology Implementation Guidelines, the National Information Assurance Partnership's (NIAP) Common Criteria and Protection Profiles, and organization-specific policies and/or security guidelines;

(5) Architecture, such as the Organizational Zero Trust Reference Architecture and Adoption Principles and/or the structure defined by NIST SP 800-207;

(6) The foundation of trust as defined by Federal or Department of Defense, PKI, and ICAM policies;

(7) 5G infrastructure security guidance as described in the joint NSA, CISA publication series;

(8) Ongoing diagnostic and mitigation procedures, as defined by DHS or NIST SP 800-137. Commercial service providers may be required to comply with the Federal Acquisition Regulations or the Defense Federal Acquisition Regulation Supplement, NIST SP 800-171, DoD Cybersecurity Maturity Model Certification or FedRAMP or DoD FedRAMP+ Cloud Services.

3.6 Step 5: Assess gaps in safety guidelines

The fifth step checks for consistency between safety features and available federal safety guidelines to guide A&A activities. If security capabilities are required to mitigate identified threats and reduce risk to federal businesses, there must be a way to assess the effectiveness of their implementation. Institution-specific policies or general government guidance and policies may be employed, and/or an independent assessment agency may be established to conduct the assessment. Gaps are identified when security needs exist without assessing guidance, policies, or organizations to validate their effectiveness for government operations. Gaps can also arise when security requirements are believed to exist to mitigate threats, but no formal requirements have been established.

In the absence of a U.S. government evaluation program or recognized government standards, risk managers may identify alternative evaluation systems, such as industry certifications, security assurance programs created by commercial trade groups, or other best practice evaluation frameworks. However, risk managers should carefully assess the applicability and comprehensiveness of any such approach before attempting to use assessment alternatives. For example, when examining the security of 5G-enabled IoT devices, a lack of the NIAP Common Criteria Protection Profile was found to guide security implementations or perform security assessments. After a reasonable evaluation, the agency will find that an existing industry certification program can serve as a suitable evaluation alternative.

Through preliminary analysis, this study identified some gaps. In addition, the research team expects that 3GPP, the European Telecommunications Standards Institute and the O-RAN Alliance will continue to work on project research and security specification development, and may uncover additional threats.

4. Conclusion

5G networks are designed to provide better security than 4G networks. However, the complexity of 5G networks with new capabilities and services, coupled with the expected significant increase in the number and types of 5G network equipment, coupled with the virtualization and disaggregated use of the RAN and 5G core, expands the threat surface, making it possible to define system boundaries very challenging. Enterprises implementing or planning to implement 5G systems may be unaware of the impact of incorporating 5G technology on the system risk assessment/ATO process. Additionally, because 5G deployment is still in its early stages, businesses may not be aware of the potential threats 5G faces and are not prepared to access the security features 5G offers.

To determine the likely impact of incorporating 5G technology into the federal system on the ATO process, the research team developed the five-step 5G security assessment process presented in this paper, identifying key threat frameworks for 5G system network assessment, 5G system security considerations, industry security Specifications, Federal Safety Guidance Documents, and Related Organizations and Methods. Through their investigation, the research team concluded that the NIST RMF is technology neutral and does not require modifications to 5G. The 5G security assessment process described in this paper is a repeatable methodology that federal program/program managers can use when conducting NIST RMF preparation steps for 5G systems and can be applied to a wide range of 5G system architectures, deployment scenarios/use cases, etc. other operating environments.