- Massive IoT–Based Threats in 5G
- Securing mIoT Deployments in 5G Networks
This chapter is from the book
This chapter is from the book
This chapter is from the book
Another method of authenticating the IoT devices is by using the software development kit (SDK) provided by many IoT service providers, as shown in Figure 8-14, which illustrates IoT device integration with the public cloud using an installed SDK.
)
FIGURE 8-14 IoT Device Integration with Public Cloud Using SDK
Figure 8-14 illustrates the authentication of the IoT device using the installed SDK and is explained as follows:
The SDK will include open source libraries. The recommended practice for low-powered devices is to use an SDK that supports device connections that use Message Queuing Telemetry Transport (MQTT). The SDK will include a basic set of functionalities and policies to access the cloud-based IoT provider.
The key functionalities of the IoT service provider are deployed in the cloud. One of the key components is Identity and Access Management (IAM), which is used for authenticating the IoT devices. The API gateway (API GW) is used to protect the IoT applications from API vulnerabilities, such as providing rate-limiting functionalities and enhanced authentication and authorization functions.
Installing SDKs in the IoT devices will help you integrate IoT products to your choice of IoT providers deployed in public cloud.
The SDK deployed within the IoT device will initiate an HTTPS request toward the authentication, authorization, and accounting (AAA) component of the cloud-based IoT provider. The HTTPS request includes the X.509 certificate, which is verified by the AAA component to authenticate the IoT device.
Once the mutual authentication is performed, initial configuration can be downloaded to the IoT device. One of the other functions that can be performed is to attach a policy for the device, such as allowing the device to connect to the analytics engine, enabling you to enhance the services being offered to the IoT use cases.
In pragmatic deployment considerations, you also need to consider integration of hundreds of thousands or even millions of devices, which might require AAA to be deployed in the public cloud, as illustrated in Figure 8-15.
)
FIGURE 8-15 Cloud-Based Authentication for IoT Devices
One way to tackle the issue of identifying millions of devices is to build a strategy around having a unique ID (UID) assigned during the manufacturing process that can be used to identify and authenticate the device. Having a unique ID will also allow service providers to have proper lifecycle management, including tracking the software and hardware changes. Any infection or abnormal behavior can be easily tracked down to a specific device or group of devices.
Network Slice Isolation and Segmentation
Network slicing is one of the key evolutions of the network deployment brought in by 5G technology. Network slicing is the ability of the network to (automatically) configure and run multiple logical networks as virtually independent business operations on a common physical infrastructure. Network slicing is a fundamental architecture component of the 5G network, fulfilling the majority of the 5G use cases. Many operators are considering the offer of a network slice per enterprise, which is not that dissimilar to the per access point name (APN) offer for an enterprise in play today. As we consider the points where the enterprise then touches the 5G slice, a number of security aspects must be addressed—one of them being slice-level isolation, as illustrated in Figure 8-16.
)
FIGURE 8-16 Slice Isolation and Segmentation for IoT Devices
Network slicing architecture, which allows the ability to run multiple logical networks as virtually independent business operations on a common physical infrastructure, also requires high isolation between the slices. Isolation within the components of the slice prevents the vulnerabilities from spreading to other components within the slice and between the slices in the case of any malicious attacks.
Intra-slice and inter-slice isolation should be implemented for both public and non-public networks (NPNs). The network slices should also allow a quarantine slice for identified malicious hosts, which provides isolation and restricts the spread of malware due to lateral movement.
Intra-slice can be provided by ensuring that the CNFs serving the slice are deployed on separate hosts. This ensures high availability for the slice.
Inter-slice isolation can be provided by deploying 5GC CNFs on separate hosts and then implementing network segmentation between slices. This mitigates malware propagation between slices of different sensitivity, such as a slice serving critical infrastructure (considered a highly sensitive slice) and a slice serving IoT devices (considered a less sensitive slice).
Segmentation and isolation mechanisms used for the IoT deployment will vary depending on your deployment mode to cater for the mIoT use cases. If network slice mechanisms are used to provide access to the IoT device, you should ensure that the 3GPP 5G functions are isolated from other slices. This can be done by using separate x86 servers for deploying mIoT slice NFs. You should also architect your network such that web-facing applications are in a separate security zone and are not deployed in the same x86 server. This will ensure physical separation of the NFs and will reduce the probability of any side-channel attacks exploiting the vulnerability of the host OS and hardware (HW). If the mIoT devices are being deployed in the NPN network, then you should ensure that you have the mIoT network and the operational technology (OT) completely isolated from your IT network using a demilitarized zone (DMZ). In fact, if the mIoT is being deployed for critical use cases, there should be integrations with the IT network only if it is really necessary. Remote access to such networks should follow stringent identity and access mechanisms and should be continuously audited. This could be done by using a next-generation firewall (NGFW) integrated with your Network Access Control (NAC) and IAM layers.
Securing network slices is covered in detail in Chapter 7, “Securing Network Slice, SDN, and Orchestration in 5G.”
Mitigating IRC and P2P-Related Attacks
In general, deploying IRC and P2P IoT devices in the subscriber’s location should be avoided. But pragmatically speaking, it is well known that the security team of the service provider is rarely informed of IoT devices being sold to customers by the customer-facing teams of the service provider. To solve this issue, recommended practice dictates that service providers check the type of device, secure the development lifecycle followed by the device manufacturer, and look at the supply chain lifecycle of the device manufacturer.
If the existing devices within the service provider use IRC, then in cases of IRC-related botnet attacks, each bot client must know the IRC server, port, and channel. Anti-malware solutions available today can detect and shut down these servers and channels, effectively halting the botnet attack. If this happens, clients are still infected, but they typically lie dormant since they have no way of receiving instructions. A botnet can also consist of several servers or channels. If one of the servers or channels becomes disabled, the botnet simply switches to another. It is still possible to detect and disrupt additional botnet servers or channels by sniffing IRC traffic, which can be catered for by anti-malware and monitoring solutions.
If the existing devices within the service provider use P2P, for mitigating the P2P attacks that use the firewall pin-holing technique, then granular firewall configurations to block traffic on specific ports should be used. This would prevent infected devices from communicating with the malicious P2P servers.
Zero-Touch Security
Many of the consumer devices aimed at enabling IoT use cases use Zero Touch Provisioning (ZTP) to allow the PnP capabilities. This is done to allow easier deployment for the customer and provide a better user experience. Before choosing such devices from a manufacturer or vendor, the service provider should check whether the device manufacturer or vendor uses ZTS as a model for the ZTP process. Depending on the vendor, the method of ZTS is also called secure zero touch or zero touch secure identity, or other variants.
Implementing ZTS by the device vendor is quite critical, as it secures the device and authenticates and encrypts its communication with the cloud-hosted provisioning and configuration server or PnP servers and provides a secure lifecycle thereafter, including secure auto-deployment of patches, secure auto-installation of updates, and so on.
ZTS techniques used by the vendor should also ensure continuous authentication if any anomaly in behavior is detected or if reauthentication of the device occurs at certain intervals without interrupting the device functions. During assessment of the device vendor by the service provider, scalability of the solution should also be verified. Quite a few vendors in the market today use artificial intelligence (AI) to detect anomalies in behavior and can initiate the detection and response capabilities automatically depending on the behavior of the devices, including triggering the reauthentication of the devices and moving the devices with anomalous behavior to an isolated segment.
DNS Security for 5G IoT Devices
The Domain Name System (DNS) plays a very important role in the IoT ecosystem. The 5G devices enabling consumer IoT would primarily be using cloud-based provisioning servers for PnP, which is usually configured using an FQDN that will have the URL of the provisioning server configured or hardcoded. Using this configuration, the device will connect to the provisioning server, get authenticated (depending on the device vendor), and then connect to cloud services to transmit and receive data.
One of the key threats is DNS cache poisoning attacks, where a malicious or fraudulent IP address is logged in the local memory cache. The device configuration can also be modified for it to connect to a malicious server. This is because the devices trust the domain names to be secure. If an attacker changes the original domain name within the configuration template of the device or can change the hardcoded domain name to a malicious one, the device will try connecting to that domain name. The attacker can then insert a rogue update to the device, potentially taking full control of the device and targeting it against the service provider infrastructure, causing a DDoS attack or taking down the infrastructure, causing a DoS attack.
DNS, although scalable, does not include any inherent security mechanisms such as encryption, which makes it vulnerable to MitM attacks for interception and manipulation. Domain Name System Security Extensions (DNSSEC) and DNS over HTTPS (DoH) improve the security capability of DNS. DNSSEC is becoming more important for IoT devices due to the fact that it secures parts of the supply chain system as well. When an IoT device is manufactured, many of the device vendors use the cloud-based configuration for shipping and initial factory configuration. This is because many of the orders from service providers can be customed labeled so that when the customers receive their devices, they will be in the name of the service provider. This requires some changes at the manufacturing end, and many of these processes are automated in the industry these days. Secure DNS solutions can also be used by the service providers to enhance security for the IoT devices. This is further explained in detail in this section.
DNSSEC
DNSSEC is a set of extensions to DNS that provides a security chain of trust and protection from DNS vulnerabilities. DNSSEC provides DNS clients with cryptographic authentication of DNS data by using cryptographic keys to validate connections between the DNS client and a domain name.
Having DNSSEC as part of the device capability will ensure that the device is routed and connected to the authentic server.
Although DNSSEC adds integrity and trust to DNS, it does not provide confidentiality (DNSSEC responses are authenticated but not encrypted), which means that the DNSSEC responses can be intercepted. As the attacker can attempt to use DNSSEC mechanisms to consume a victim’s resources, it does not provide complete mitigation against DoS attacks.
DoH
DNS over HTTPS (DoH) caters for DNS resolution using the HTTPS protocol. Using HTTPS, DoH provides better user privacy and prevents MitM-type attacks because it includes encryption between the DoH client and the DoH-based DNS resolver. DoH is published by the IETF as RFC 8484.
DoH works just like a normal DNS request, except that it uses Transmission Control Protocol (TCP) to transmit and receive queries. DoH takes the DNS query and sends it to a DoH-compatible DNS server (resolver) via an encrypted HTTPS connection on port 443, thereby preventing third-party observers from sniffing traffic and understanding what DNS queries users have run or what websites users are intending to access. Because the DoH (DNS) request is encrypted, it’s even invisible to cybersecurity software that relies on passive DNS monitoring to block requests to known malicious domains.
If service providers plan to use DoH-based endpoints, there are certain mechanisms the security team can put into place to ensure that the devices use specific browsers. Browsers such as Chrome ensure that DoH will only be enabled when system DNS is observed to be a participating DNS provider. After DoH is enabled in Chrome, the browser will send DNS queries to the same DNS servers as before. If the target DNS server has a DoH-capable interface, then Chrome will encrypt DNS traffic and send it to the same DNS server’s DoH interface.
Secure DNS
In many cases, consumer IoT devices today are not yet fully DNSSEC or DoH capable. One of the mitigation mechanisms from DNS cache poisonings and malicious DNS configurations is to use a cloud-based DNS security layer that ensures that the DNS request is not resolved to a malicious domain. There are vendors in the market today that integrate the secure DNS resolution along with the threat intelligence, anti-malware, and antivirus capabilities.
As illustrated in Figure 8-17, when the DNS security layer receives a DNS request from a 5G-capable IoT device, be it for the provisioning or PnP layer or for CM, PM or FM, it should use threat intelligence to determine if the request is safe, malicious, or risky—meaning the domain contains both malicious and legitimate content. Safe and malicious requests can be routed as usual or blocked, respectively. Risky requests can be forwarded to an inspection layer for deeper inspection. The secure DNS layer should also inspect the files attempted to be downloaded from the sites using antivirus (AV) engines and anti-malware protection, and based on the outcome of this inspection, the connection should be either allowed or blocked.
)
FIGURE 8-17 Securing DNS Layer Communication of IoT Devices
This is one of the most effective methods that will lead the security teams to remediate fewer instances of malware, and the threat is mitigated even before the devices are impacted or an attack is launched. Service providers selecting vendors or partners for secure DNS solutions should ensure that they have extremely good threat intelligence to ensure high efficacy. They should also ensure that the vendor providing such solutions has a robust machine learning algorithm that allows the solution to predict attacks. Many of the recursive DNS service providers resolve millions if not billions of Internet requests every day, and they have ML algorithms analyzing the massive amount of data to understand patterns and co-relate patterns by running statistical and machine learning models to identify attacks and thus uncover the attacker’s infrastructure.
The secure DNS layer is also easy deployable and doesn’t have any requirements on the device itself. It only requires the DNS IP address to be changed from a previous DNS IP address to the secure DNS provider’s IP address. Any DNS request coming from the device will now be redirected to the secure DNS vendor’s cloud network, which will then resolve all the DNS requests and block any request to the malicious domains.
Enhanced Visibility and Monitoring
One of the most important security capabilities that’s required in any organization is enhanced end-to-end monitoring to understand the communication among the devices and between the devices and the network elements, including monitoring the encrypted traffic.
After discussing and deploying proof of value (PoV), which is a marketing term used by many vendors to make solution validation in service provider networks sound cooler, a number of service providers see very little value in aggregating and tapping the user plane data of the devices. In 5G, the user plane data from devices (eMBB slice-related devices) will be in the terabytes of volume. Having a solution for end-to-end user plane (UP) monitoring is not viable due to cost and technical reasons. Control plane, service plane, and OAM are the key layers that should be monitored at minimum. By validating this method in multiple service providers, it is quite clear that many of the anomalies can be detected by monitoring the control plane, service plane, and OAM layer. Once the monitoring for these layers is established, the service provider can pick and choose the UP-layer visibility for specific use cases. IoT devices (related to machine-to-machine use cases), as such, are not user plane intensive, so having granular visibility would not be a major hurdle in terms of cost.
Before investing in an end-to-end monitoring system for the consumer IoT, service providers should try to build a unique ID system, as explained in the section “Identification, Authentication, Access, and Certificate Management” in this chapter. This will also help the service providers in reducing the mean time to repair (MTTR), as the service provider can quickly respond to the unplanned device breakdown.
Figure 8-18 illustrates the monitoring system for anomaly detection for your deployments.
)
FIGURE 8-18 Enhanced Visibility of IoT Device and IoT Slice Layers
As shown in Figure 8-18, the monitoring solution should also cater for enterprise use cases, as 5G allows easier integration into the enterprise networks using methods such as multi-access and edge computing (MEC) and network slicing. Due to the flexibility in deploying the use cases, the monitoring solution should also follow flexibility and scalability. There are monitoring solutions available in the market today that allow for multivendor packet flow collection (without the need for physical probes) and then analyze the data collected after packet de-duplication and VXLAN striping. Having such monitoring solutions would also support other use cases, such as reusing the same solution for IT and telco DC infrastructure monitoring.
It is also recommended that you look at utilizing monitoring solutions that have integration with the products with capabilities such as responding to any detected anomalies within the device or the device network. The minimum possible response should be the capability to isolate the infected devices or push the devices into a segment that will have access to only critical services.
The visibility and monitoring layer, though very critical, might become very expensive for you if you don’t plan it properly for the IoT use cases. One of the methods you could use here to optimize is to consider enhanced visibility and monitoring for control plane, service and management layer of the network functions, and network devices specific to the IoT network. If the IoT network and devices use API-based communications that are encrypted using Transport Layer Security (TLS), it is important to have visibility in the encrypted layer as well. Using a decryption engine and then analyzing the packets, though effective, is not always the best method, as multiple decryption points will reduce the effective security posture of your network. In such cases, it will be more effective to perform malware detection in encrypted traffic without decryption using solutions available today that analyze the encrypted packet header and look at the behavior of cipher suites and so on to determine any anomaly and malicious behavior. Some smart mIoT devices will also provide a basic telemetry with a couple of key counters, which will help you to understand if they have been tampered with. Such IoT devices can be blocked or reported to the IoT device user, depending on the SLA.
Access Control
Access control for 5G SIM or universal integrated circuit card–capable devices are catered for by the inherent 5G Identity and Access Management mechanisms. But many of the consumer IoT devices being deployed for quite some time will use non-3GPP technologies and legacy 3GPP mechanisms and connect to the 5GC using network elements like the non-3GPP Inter-Working Function (N3IWF), which is responsible for the interworking between the untrusted non-3GPP components and the 5GC.
There are various access control mechanisms used by service providers today, primarily role-based access control (RBAC), mandatory access control (MAC), access using security group tags (SGTs), attribute-based access control (ABAC), and so on. For the cloud-hosted IoT management functions such as CM, PM, and FM and provisioning servers catering for consumer IoT devices, a very strict RBAC schema should be applied as a minimum, which is then followed by using multifactor authentication (MFA) for the users and devices. There should be layers of access control for any remote configuration of the IoT subsystem (controller, server, device, and so on).
To ensure that only legitimate users with the right levels of access are accessing the management layer/operational technology (OT) of the IoT network, you should apply zero-trust principles and use mechanisms where you authenticate and re-authenticate the users at varying levels of time and network layers. For example, you should use mechanisms such as MFA, which is integrated into your existing Identity and Access Management (IAM) layer. This integration will ensure that any change in the user’s role is mapped to RBAC. If the previous role of the user was admin with privilege access, once the person leaves the organization or changes role, the integration will ensure that the person does not have privileged access anymore. This layer, although foundational, is rarely designed properly due to multiple access control vendors and multiple MFA vendors being deployed at different departments of the service provider. In some cases, there are six to seven multiple IAM solutions deployed in the same domain of the service provider, thus unnecessarily complicating the access control and leading to improper configuration and blind spots.
Figure 8-19 illustrates the granular access control for IoT deployments by providing the secondary authentication mechanism for IoT devices using the enterprise AAA/IAM.
)
FIGURE 8-19 Granular Access Control for 5G IoT Network
As shown in Figure 8-20, the user will have to go through primary authentication, secondary authentication, secure Internet access, and a granular role-based access for accessing the device and the consumer IoT subsystem.
)
FIGURE 8-20 Granular and Multilayered Access Control for 5G IoT Network and IoT Devices