Private 5G IoT Security Drivers
For 5G to live up to its promise of transforming industries, enterprises need to strengthen the security of 5G networks, services, and applications. Security built on the principles of a Zero Trust architecture has the potential to drive digital transformation across all industries, from manufacturing and industrial sectors to energy, healthcare, and more.
The integration between Celona 5G LAN and Palo Alto Networks (PAN) provides real-time mapping of device IMEI/IMSI data and IP addressing that enables automated enforcement of Zero Trust policies, such as security and incident profiling, secure access, and behavioral analysis of cellular connected IoT devices. Open APIs also allow the exchange of essential client information between Enterprise IoT Security offerings on the Palo Alto Networks’ Network Security platform and Celona’s Edge OS.
How does the integration benefit Enterprises?
Subscribers connected to Cellular Mobile networks have inherent identifiers that differ from regular IP networks. In Mobile networks, the assigned IP address can be volatile; there is no mandatory DHCP assignment and no MAC address concept. From the Zero-Trust security standpoint, the IP is not a single trusted device identifier; other identifiers must be used for visibility. Private Cellular Devices are composed of IMSI/SUPI (Subscriber ID) or IMEI/PEI (Equipment ID). Those are trustable identifiers in cellular networks. With the existing Palo Alto Networks GTP features, it is possible to obtain real-time visibility, correlation, and security enforcement for mobile subscribers. One way to gain this visibility is via exposure from the cellular network signaling interface to the NGFW. Such exposure is usually possible in SP’s (Service Providers) deployments; however, for Private Network deployment, it is usually not possible, as it is a self-contained downscaled version of a 3GPP core, which does not allow the exposure of the signaling interface.
With this solution integration, the customers will be able to extend the Zero-Trust approach to their Private 5G networks by having the following benefits:
Provide correlated visibility of the cellular Subscribers and Equipments traffic connected throughout their Private 4G/5G networks
Enforce Security Policies based on the trusted cellular device identifications
Create customized Security Automation that controls the status and profiles of the devices on the Private 4G/5G network
Enables PAN IoT Solution to learn about the 5G identifiers and profile the 5G devices
This guide provides step-by-step instructions on how to integrate Celona's Orchestrator (CSO) with Palo Alto Networks' firewall solutions. The integration enhances network security by enabling visibility into cellular devices using IMEI and IMSI identifiers and automating threat detection and remediation.
Integration Scenarios
This guide covers two integration methods:
With Cortex XSOAR: XSOAR automates threat detection and response by analyzing security events and triggering remediation actions in Celona CSO. This document covers the integration with Cortex XSOAR.
Without Cortex XSOAR: The Palo Alto Networks Next-Generation Firewall (NGFW) directly handles visibility and remediation. Refer to the Celona and Palo Alto Integration without Cortex XSOAR document to configure without Cortex XSOAR.
Prerequisites
Active Celona private network deployment
Palo Alto Networks NGFW
API credentials for Celona CSO
Cortex XSOAR (for automated remediation scenario)
Integration with Cortex XSOAR
Architecture Overview
Devices connect to the Celona private network.
The firewall retrieves IMEI and IMSI data via Celona APIs.
XSOAR detects security threats and triggers remediation via Celona CSO.
Configuration Steps
Step 1: Configure API Access in Celona CSO
Log in to Celona Orchestrator.
Devices should be associated with an External IP domain
Celona MPN may need an external DHCP server for network and UE IP assignments. In L3 deployments, configure the NGFW as the Default Gateway for the PGW-U DHCP server. The PGW-U SGi IP address must be set as a static route in the NGFW. The NGFW can also serve as the DHCP server for all or some IP allocations.
XSOAR requires an API key to authenticate with CSO.
Click on the menu, navigate to Admin Settings, and Click on API Keys.
Click Generate API Key on the top right corner of the page.
Note the API endpoint URL for device visibility.
Step 2: Configure Palo Alto Networks NGFW
There are two components to configure on the Palo Alto Networks side: the NGFW and Cortex XSOAR.
Palo Alto Networks NGFW Setup and Configuration
Log in to the Palo Alto Networks firewall.
Security Zones Recommendations: Three security Zones are recommended, shown in colored (green, yellow, and pink) shades in the previous diagram.
Networking: The NGFW interfaces should be configured according to the customer networking topology and addressing. XSOAR needs to communicate Radius messages to the NGFW via a data plane interface. For the Security automation use case, the NGFW should have connectivity to XSOAR via the management interface; for downlink routing, a static route towards the device’s IP pool is required, using the PGW-U SGi IP as a next hop.
NAT to UE traffic and Celona O&M: The NGFW can be configured to perform NAT to Celona O&M and to the UE’s.
Enable GTP Security: By default, the NGFW has GTP Security disabled. Enable it following these steps. Commit and reboot are needed.
Configure the MNPP (Mobile Network Protection Profile) for RADIUS: This profile will indicate the use of Radius as a source of the UE correlation information. Set the Mode as Loose.
Create the RADIUS Security Policy: Add a security policy allowing Radius AppId and associating it to the RADIUS MNPP (created in step 6).
Create the Subscriber Traffic Security Policies: Add all the necessary Subscriber policies depending on the customer traffic inspection and security posture requirements. The subscriber traffic security policies can be created based on SubscriberID (IMSI/SUPI), EquipmentID (IMEI/PEI), and/or Mobile-specific EDLs.
Step 3: Configure Cortex XSOAR
Steps to install XSOAR 6 instance
Install VM on the hypervisor applicable. Most installations use Ubuntu Server LTS.
Open SSH Session to the VM and run the following three commands (you need the token and customer email).
wget -O xsoar.sh "https://download.demisto.com/download-params?token=mFBVCqdXkmvU&email=customer@paloaltonetworks.com&eula=accept" sudo chmod +x xsoar.sh sudo ./xsoar.sh
3. Once installation is complete, connect to the XSOAR GUI Instance using a web browser, e.g. https://10.6.144.180
Apply XSOAR license
Get your license file from email or the Customer Support Portal. Save the file to the computer from where you run your web browser to access XSOAR.
In the XSOAR GUI, click "Settings" -> "About" -> "Licenses", scroll to the bottom of the page and upload your license file.
You should see your personal license and its limitations applied after reloading the page.
Download the XSOAR Celona Integration
This step consists of downloading the Celona Integration content to XSOAR and the communication plugin for the NGFW.
Setup the XSOAR Celona integration instance
Add a new Celona Integration Instance: At the XSOAR GUI, on the left pane, click on
Settings -> Integrations - > Instances You can search for ‘Celona’ in the search box, then click on Add instance.
The Instance settings box will pop up, and you need to fill in the parameters of the Celona instance.
The parameters that you need to fill in are:
Instance Name: This is any name that identifies the instance, e.g. “Celona_Customer_ABC”
Server URL: This is the Celona CSO URL where the API call will be triggered. Celona should provide it.
If you do not have the certificate, check the box Trust any certificate
Check the box Long running instance
API Key From Celona: Paste the API key generated at the Celona web portal
Query Interval: This is the interval of the API polling. The recommended setting is 10 seconds
Enter Numeric Customer ID: It can be found at Celona’s web portal
Admin Settings -> Account info -> Account IDEnter site name: It can be found at Celona’s web portal under Sites
Log Level: You can set it to Debug while setting up the integration and then turn it off for normal operation
When finishing the parameters, press the Test button to verify the API connectivity between XSOAR and Celona CSO. Check that the result says Success. Now press Save & exit.
Set the Site ID Config
Some deployments may have multiple sites, with multiple NGFWs deployed. We only want the device information sent to the NGFWs at the appropriate sites in these situations. The Site_ID will link the MICS to the specific Celona Site within the multiple customer private networks. At the XSOAR GUI in the left pane, click on Settings -> Advanced - > Lists -> Site_ID_Config -> Edit.
Within the Site_ID_Config file parameters, you need to include the following:
Celona Site ID: This can be obtained from the web portal URL bar when listing the sites
instance: MICS instance name given in the previous step
ngfw_ip: NGFW data plane IP that receives or sees the Radius messages
ngfw_port: Set it to 1813
Press Save Version, explain the change, and press Update List.
At this point, the NGFW, XSOAR, and Celona are configured. The testing can be started if connectivity is in place and the Subscribers are provided with the Celona Private Network.
Step 4: Validate the Integration
For the initial test, ensure the mobile device is provisioned in the Celona network but offline. This is achieved by turning off the mobile or putting it in Airplane mode.
At the NGFW CLI, check that there are only UEIP mapping entries for the online devices, but for the testing device, use the command to show them all.
Turn ON the device or disable Airplane Mode in the testing device. The expected delay from toggling Airplane mode off until being 4G/5G connected is around 5-12 seconds (depending on how fast the UE finds the NW). Verify the phone is connected to the cellular network by looking at the “LTE” icon (or something similar) with signal bars.
The Celona Orchestrator GUI will show the UE as Active seconds after it has been connected to the network. The expected delay between the actual UE network Connectivity and updating the Cloud API is around 30 - 90 sec. Verify that the UE IMSI, IMEI, and IP are visible, match, and are Active in all the solution components: Celona Orchestrator, XSOAR, Ue, and NGFW.
For Celona Orchestrator visibility: Go to the Devices page.
For XSOAR visibility: The Cortex XSOAR Integration will see the UE as a new IMSI and update the NGFW via the MICS. This happens only after the cloud API has been updated. Depending on the polling settings of the integration and on where within the polling cycle a change happens, Cortex will need 1 - 30 sec to update the NGFW after a change arrives in the Celona API. Verify the IMSI is visible in XSOAR and that its updates are tracked as Incidents.
Opening the Incident -> War Room, it is possible to see more details.
For UE Visibility: On the Phone, the IMEI and Ue IP are in the device menus, e.g., for Android, click on Settings -> About Phone. IMSI visibility has been removed from the recent Android versions.
For NGFW Visibility: The NGFW has received the updated IMSI-UEIP mapping. Check it at the NGFW CLI (show ueip all).
A GTP-log is created in the NGFW with GTP Event Type “UEIP mapping start.”
Verify that the UEIP can make a data connection; for example, at the UE, open a web browser and connect to an internet webpage. You can also ping to a known IP, like 8.8.8.8.
At the NGFW, check that the Traffic logs now have the SubscriberID and EquipmentID visibility.
Similarly, other logs (Threat, URL Filtering, Data Filtering, etc ) will have the 5G identifiers' visibility.
Note that the SubscriberID and EquipmentID fields are populated once XSOAR provides the Correlation information. Previously, the values are shown as ‘0’. If the Radius MNPP is set to ‘Loose’ mode the NGFW will let pass this traffic without knowing the correlation, otherwise if it is in ‘Strict’ mode it will drop it. At the NGFW logs, you can also filter by specific IMSI or IMEI.
Once this test is successful, you can proceed with testing with the UE detach. You can turn off the phone or put it on Airplane mode. Due to this UE detachment, all the solution components will be updated to reflect the UE's disconnected status.
UE: Won’t have the “LTE” icon
Celona CSO: UE will go Offline status
XSOAR: A new incident will occur, changing the status to offline
NGFW: A new GTP log with GTP Event Type “UEIP mapping end.” All traffic log sessions from this UE will end after a while
You can now create Security policies based on those 5G SubscriberID and Equipment ID
Validate the enforcement by checking the logs.
