At Mobility Field Day 11, Celona brought an unexpected partner into the room, Palo Alto Networks.
After all my experience covering many of the up and coming Private Cellular vendors, Celona continues to innovative.
Private Cellular has not taken off as once expected. It’s been a slow growth. There are issues that Private Cellular solves that are difficult to solve with other solutions such as Wifi, but the market has been filled with lots of proofs of concepts and lots of misunderstandings.
When I started this blog, use cases were not being widely shared across the industry. I gained personal notoriety because I was sharing potential use cases in a public manner. As with many technologies, we often learn the limits of the technology by working through the weeds.
Private Cellular security has been one of those things that a lot of people haven’t put a lot of though about. Marketing shares that 4G LTE and 5G is more secure than Wifi and leaves it at that. Sometimes they branch out beyond that and talk about the encryption keys and usage of SIM cards, but that is the extent of the talk about security. For several years, I’ve been looking into the solution to securing the interface between clients and building the network more like a enterprise network than a carrier network. Celona has introduce a solution to this problem.
But first, let’s explore the problem that Celona and Palo Alto are solving.
CBRSPi Security Testing
Many of my long time readers may remember my testing with the CBRSPi. I haven’t forgotten this device, I’ve just been building some things that I’m hoping to share publicly soon. That’s not what I’m going to focus on at the moment though.
When I first installed a Qualcomm modem on a Raspberry Pi, I wanted to see how the device performed on the network. When I was connecting other devices such as my iPad, I couldn’t see the IP Address on the cellular network. The CBRSPi SIMCOM Modem that I was using created a wwan0 interface that had an IP Address from my P-GW on the LTE EPC Core.
I then attempted to see what was available on that subnet since 255.255.255.248 has six devices. I was able to ping the gateway of the subnet, other CBRSPi UEs, and since it was Layer 2 anything in that subnet. I then installed NMAP and started testing known networks up the chain from the P-GW. There is no protection for access to other servers if the network is not properly segmented, so called North-South traffic, and UEs may not be protected from each other, so called East-West traffic.
Private Cellular Networks Security Issues
Cellular networks were designed for a Carrier to be in complete control of the path between the Radios and the Core and all external access to be segmented properly. In Private Cellular, that may not be the case. As I talked about in a previous blog post and on a webinar with GXC, there is a need to protect the RAN and Core networks or other subnets.
For example, on my iPad connected to a private cellular network the traffic connected through the P-GW is dropped off locally on the network (192.168.5.0/24) in the North-South path. In this example, the IP Address assigned to a device by to the P-GW is in the 192.168.128.13/30 range. The P-GW then NATs the internal network to a private external address in the 192.168.5.0/24 range.
All the UE devices are protected from the outside because of NAT and the P-GW, but there is no protection from the UEs outbound attacking the network. For the test system that I have at my house, I can run the Network Analyzer app on my iPad and scan the ports on my internal network. My private NAS server returns the following open ports.
My NAS has open SSH, HTTP, HTTPS, NETBIOS, and MS-DS that the client is able to access from the cellular network. Some of these may be wanted while others you may want to block depending on policy. With this setup, you are unable to block any of the traffic in this manner.
Notice it is connected to the LTE network ONLY on the top right. Field Test Mode on my iPad gives the following information about the network.
Because of this vulnerability, I could use a UE or CPE to attack anything on my local network. Someone could remove a SIM card from a device, install it in another device, and have full access to the internal network, unless you tie a IMSI to IMEI. If you are using a CPE, someone could plug into the ethernet interface of the CPE or join the Wifi network and there is nothing protecting the juicy internal network or other UEs.
Attacking the network can be solved with proper network segmentation between the P-GW and other devices. The attacks between UEs cannot be solved through standard firewalls and segmentation.
As an industry, we are preaching cellular as more secure. For the most part it is more secure out of the box than Wifi, but there are still threats that need protected against.
Firewalling UEs from North-South and East West
Celona and Palo Alto are attempting to solve these issues with the integrations announced at Mobility Field Day 11. Celona has integrated Palo Alto’s firewall rules and controls into their Core through APIs.
Using Rest APIs between Celona Orchestrator and Palo Alto Cortex XSOAR, Palo Alto Panorama firewalls can be inserted in the middle of each and every UE and the network. This gives full Layer-7 Inspection of North-South and East-West Traffic as well as the devices behind the CPE. This is all available because of Celona’s Supernetting features.
The really cool thing about this announcement is that the Subscriber Identity (IMSI) or the identifier of the SIM and Equipment Identity (IMEI) or the identifier of the device are columns now available in the Palo Alto Monitor tab.
You can identify traffic that originates or is destined to a LTE or 5G UE or CPE right in the Palo Alto. This is like the User-ID feature that you can integrate with a directory service like Active Directory to identify a device as a user account then create policies based upon the user.
Creating Policies based on IMSI and IMEI
Now that you can identify the device by the IMSI and IMEI, you can also create policies based on that traffic.
For my example, I could allow access to web traffic, HTTP and HTTPS, to my NAS server but block access to SSH, NETBIOS, and MS-DS. During the demo, the example was used to block Modbus traffic based upon the IMEI. You can do this for any kind of traffic.
This is bringing Private Cellular into something that Enterprises understand. This is a game changer on bringing Private Cellular into the enterprise and securing it properly.
Mobility Field Day 11 Presentation
I highly recommend that you go watch all of the Celona and Palo Alto presentations at Mobility Field Day 11. Celona talks about building a Zero Trust system for Private Cellular before exploring the Palo Alto integration. I’ve long believed Private Cellular can provide an easier path to Zero Trust architecture because of SIMs. It just lacked these controls.
Ultimately, Celona is exploring issues and innovating in ways that other vendors are not thinking about yet. For the industry’s benefit, I hope that similar integration with Palo Alto or other Firewall vendors can be built to work with other vendor cores.
