This document explains configuring and operating the Cloudi-Fi platform for IoT profiling. It doesn’t focus on a specific security vendor integration.

Use Case

Introduction

The final objective of the IoT engine is to apply specific Internet security profiles to each category of IoTs, see Figure 1. First, this allows for the protection of the IoT itself and the encompassing environment, through dedicated security filtering. Second, it enforces a restricted set of destinations so that IoT, which sometimes has a loose security framework, cannot get corrupted or corrupt remote parties. This has become key in the context of some well-known security events like the family of MIRAI bots.

Figure 1. Profiling IoTs

In a Wi-Fi captive portal environment, users interact with the identification system through a web form. They provide, for instance, credentials. On the contrary, since they cannot interact, IoTs require automated identification. To fulfil that objective, the Cloudi-Fi IoT framework relies on the DHCP process to identify the devices. This is later named fingerprinting.

Figure 2. Onboarding IoTs

After the fingerprinting process, the device goes either into :

• A “whitelist” security profile where they will get an IP address from the DHCP server and be attached to a security policy at the firewall level (a “Security Profile” is bound to a "DHCP pool" within the DHCP Subnet you will configure - details later)  
• The “blacklist” security profile where no IP is delivered. The blacklisted devices have no Internet service. This profile is aimed at devices that are not supposed to connect to that Wi-Fi/LAN service.

Devices that are not authenticated remain in the “Quarantine” profile. Further, this document will describe how these exceptions are managed.

The DHCP process

The Cloudi-Fi DHCP service operates in the cloud. When a device boots up, it sends a DHCP request, relayed over an IPSec tunnel from the customer location to the DHCP server nodes in Cloudi-Fi infrastructure, see Figure 3.

Figure 3. DHCP infrastructure

This DHCP request carries the MAC address of the device and DHCP data (i.e. options), which are meaningful for identifying the device.

Based on a match between the DHCP fingerprint and the pre-configured policies, the device then gets bound to a security profile. As per Figure 4, each security profile is materialized as a DHCP pool.

Figure 4. DHCP and Firewall integration

This means that a device gets segregated into security profiles thanks to its IP address. This IP address is the device information that links it to the security profile it belongs to. Hence, security policies are applied within the firewall based on the source IPs.
To control and enforce a safe binding between a device and its profile within the LAN and Wi-Fi framework, we recommend the implementation of well-known device isolation and anti-spoofing methods: client isolation, private VLANs, DHCP snooping and IP-source guarding.

In firewalls and cloud firewalls that can expose APIs for configuring the policies, Cloudi-Fi automates the configuration of the synchronized IP ranges as:

1. DHCP pool on the DHCP server side
2. Source IP range for applying a policy in the firewall.

As per May 2023, the Cloudi-Fi IoT engine automates the scaling of these ranges only in a Zscaler integration model. Other integrations will come online later on.

Besides this automated onboarding toolkit, exceptions arise. When no policies can be bound to a device type, device remains in quarantine. Cloudi-Fi proposes alternative onboarding methods as a fallback. We will discuss these in sections 3. and 4.

Let’s now explain how to:

• Onboard individual devices
• Configure the security profiles
• Manage exceptions

As a preliminary task, make sure you have deployed the DHCP server configuration:
https://help.cloudi-fi.com/hc/en-us/articles/12021080251677-How-to-enable-Cloudi-fi-DHCP-for-your-guest-users

1. Identifying devices

As per Figure 5, the DHCP fingerprinting system provides insight into the device's characteristics:

• Type, e.g., Camera, printer, sensor, laptop, mobile …
• Brand
• Model
• Operating system
• MAC address vendor

These device recognition data have a confidence score: Low, Medium, and High. The score reflects how much the DHCP fingerprinting was differentiated from other device types. Keep that parameter in mind when interpreting data from the device recognition engine.

Figure 5. Devices

As an example, the first device in Figure 5 is recognized as:

• Type: IP Camera
• Brand: Google
• Model: Nest Cam
• MAC vendor: Nest Labs
• Operating System: Chrome OS

The data gathered here above will be input into the security profile filtering configuration. Since recognition is not entirely predictable, creating a rule for classifying devices and knowing how devices are recognized are critical.

2. Profile configuration

For well-recognized devices, we recommend using profiling rules that rely on automatic identification. These rules are named “Automated”. Let’s see how to configure them.

First, go to Admin UI > Networks > Security profiles and create a security profile (“Add Profile”) to host these devices. As per Figure 6, we input the following data:

• Portal toggle: disabled
  Since we do not expect devices to run captive portal requests into this profile, this remains disabled. For integrations where automated firewall configuration happens (e.g., Zscaler), enabling this toggle would configure the redirection of captive portal discovery requests.
• Name: An admin-friendly unique identifier
• Location: specifies whether the profile (and related DHCP pool) will be deployed in all locations or only a specific set of locations
• Subnet: specifies whether the profile (and related DHCP pool) will be deployed in all subnets or only a specific set of subnet names. Some location might have multiples subnets/SSID where the same profile would apply. Please note that using the same subnet name in multiple locations allows the profile to be applied to a set of location/subnet combinations. For instance, when configuring an “IoT - security” subnet in a subset of locations, only these locations will get the security profile attached to that subnet.
• IPv4 pool size: The percentage of the subnet that must be assigned to that profile. In a Zscaler configuration, since DHCP pools are dynamically sized, 0% should be configured.
• Description: as per the field title
• Advanced/type: either quarantine (created for all subnets by default), whitelist, or blacklist. A subnet can have multiple whitelists and blacklist profiles but a single quarantine pool.

Figure 6. Adding a security profile

Once the profile is settled, a group must be configured. Groups are meant to structure the configuration in a hierarchy and keep the structure easily readable. A profile contains one or multiple groups. A group includes one or multiple rules.

Figure 7. Adding a device group

The rules are installed at the next lower level. They implement filtering capabilities that will match the devices to be inserted in the group and profile. The rule implements a recognition method:

• Automated: based on the device recognition data, described in Figure 5
• Static MAC: MAC addresses range
• Static MAC (advanced): MAC addresses regular expression
• MAC Vendor: MAC addresses ranges for a matching vendor OUI regular expression 
• DHCP Fingerprint: Regular expression on DHCP options 55 and 60

Rules cannot be used with boolean operators. A single rule matches.

Again, for configuration readiness, each rule might include multiple sequences.

Figure 8. Adding a sequence to an automated rule

Let’s take a look at the configuration of an automated rule. It implements the following parameters, as per Figure 8:

• Enabled toggle: when selected, the sequence will be parsed. If it matches first (see groups sequencing menu), the device is bound to the related inclusive security profile
• Name: an admin-friendly unique identifier
• Confidence score: high, medium or low. If “low” is selected and the device recognition system returns a confidence level of “high” or “medium”, it will match.
• Fingerprinting devices: the Cloudi-Fi family of devices that will match
• Brand: regular expression matching the brand
• Model: regular expression matching the model

When automated device recognition doesn’t provide enough meaningful information, it’s recommended to enforce either manual DHCP fingerprinting or MAC address-based rules. Cloudi-Fi Customer Success would help you operate those configurations.

In configurations where multiple rules are implemented, we recommend that you check the groups sequencing menu, see Figure 9. Conveniently order the rules, in case some of them would overlap. The first matching rule from the top would get the device inserted into its encompassing profile.

Figure 9. Checking the sorting of rules sequences

3. Committing configuration

Before moving on, security profile configuration must be applied to the DHCP system. To do so, click on Admin UI > Networks > Security profiles > Reassign pools. Figure 10 depicts the information window that shows the impact of the configuration.

Figure 10. Reassigning DHCP pool configuration

4. Checking profile behavior 

When newly configured security profiles have been pushed, and a device matches one of them, it gets instantaneously sorted into the related profile, see Figure 11. 

Please note the “Profile status” row. It shows whether the device already has its target security profile IP address (green) or the DHCP cycle hasn’t yet happened. In this latter case, the timer displayed shows the worst delay for the DHCP cycle to take place and the device to get its target IP address.

Figure 11. Device DHCP profile status - pending

Once the device has been through an additional DHCP request/reply cycle, it actually gets a new IP address, see Figure 12.

Figure 12. Device DHCP profile status - active

This IP address now belongs to the DHCP pool bound to its Security profile, see figure 13.

Figure 13. DHCP pools assigned to profiles

Other rules types

When “Automated” rules fail to identify your devices, the other rules might be used as fallbacks. They might be looser, but sufficient.

5. Fallback process

For cases where you cannot or do not want to onboard devices automatically, fallback scenarios are available:

• Manual onboarding
  As per Figure 14, security profiles (and device groups) can be attached manually

Figure 14. Manual profile assignment

• E-mail notifications
  When a device doesn’t match a security profile and stays for some time in quarantine, it will generate a notification to the location's administrators, see figure 15. Assigning Administrators to location is operated in the Administrators > Teams menu. 

Please note this is only available in Zscaler integration as per March 2024.

Figure 15. IoT onboarding fallback with e-mail

What's Next ?

Congratulations on configuring your security profiles for your IOT Onboarding.