IoT Security

IoT Security is Different

IoT traffic is generally vastly different from the traffic in general-purpose devices such as laptops, computers, and mobile phones. This imposes both benefits and challenges from a security point of view.

 

IoT – Security Benefits

One significant advantage of IoT devices, in contrast to general-purpose devices, is their high consistency in communication requirements. IoT devices of the same type and brand generally have the same communication patterns. For example, a power meter typically employs specific protocols and destinations for reporting metering data and downloading firmware updates. This predictability paves the way for effective security control, with the network Access Control List (ACL) prohibiting any other traffic, thereby thwarting unauthorized communication or use of unauthorized protocols.

The uniformity of the majority of IoT devices also eliminates the need for DPI and similar functions. Enterprises armed with knowledge of their devices’ communication patterns should utilize the ACLs to ensure they adhere to these patterns. This, however, relies heavily on proactive measures taken by the enterprises. By actively managing and controlling the communication patterns of their IoT devices, enterprises can significantly bolster their security. Of course, there are exceptions to this rule. Some IoT devices may exhibit a less predictable general-purpose type of communication. In such cases, Deep Packet Inspection (DPI) solutions like the Enea Network Traffic Classification & DPI could benefit these devices.

Another factor making IoT devices easier to protect is that they are generally designed to initiate the connection to the application in the cloud. It is rare for a cellular IoT device to listen and wait for the application’s communication. One reason is to preserve the battery, and another is to save costs. Instead, IoT devices periodically poll the cloud or wait for a wake-up event to see if any communication is needed. Even when the application appears to initiate the communication, it is often the device that has started it.

 

IoT – Security Challenges

It’s important to note that many IoT devices are vulnerable due to their simple designs and lack of extensive security features like client VPN capabilities. Furthermore, their ‘headless’ nature, devoid of screens and human monitoring, makes detecting attacks more challenging, highlighting the need for enhanced security measures.

This is where Enea IoT CCS comes in! First, the Multitenancy Private APN functionality in IoT CCS automates the Enterprise VPN creation process, making it possible to do it in minutes rather than weeks. Second, each IoT enterprise customer, including SMEs, gets their own stateful firewall function configurable with enterprise-specific settings. Learn more about how Swisscom uses IoT CCS to chase the long-tail of SME customers.

Moving IoT Security Closer to the Enterprise Customer

With Enea IoT CCS, an IoT CSP can move the IoT security settings closer to their customers. Customers can make their own firewall and routing settings from your customer self-service portal enabled by the IoT CCS API.

This is how the operator managed IoT security works:

1. Using a shared APN, the IoT CSP forwards the traffic to their instance of IoT CCS hosted at Amazon Web Services (AWS).
2. Since IoT CCS allocates device IP addresses, it knows to what stateful firewall function the traffic should go (IP-based routing, teal-, orange-, and grey-colored lines in the picture above). Enea IoT CCS uses FortiGates, next-generation firewalls from Fortinet to apply the firewall policy.
3. The traffic is then forwarded according to the routing rules created by the Enterprise customer. The routing is very flexible:   a. Send traffic to one or many Enterprise VPNs (depending on protocol and destination).
   b. Send traffic directly to the internet. (protected by the firewall).
   c. Block the traffic, for instance, if the wrong protocol (port) or destination is used.

Note that some of the traffic from an IoT device, such as firmware upgrades or sensitive data, can go through an Enterprise VPN, while all other traffic can go directly to the Internet.

Since Enterprise customers can easily create as many IPSec VPNs as they need, they can also set up VPNs for their partner companies. This opens the possibility of, for instance, sending data for predictive maintenance to subcontractors via VPN. With IoT CCS, you, as an IoT CSP, can deliver a secure SD-WAN service instead of only a Private APN. You may even be able to do this internationally by providing a unified global connectivity service.

You will also get ‘hyperscale’ scalability, as it is just a matter of adding more resources on AWS.

Double NAT and Stateful Firewall Protect the IoT Traffic

By default, the devices are well protected, as they cannot be reached from the outside. They are behind double Network Address Translation (NAT), as both AWS and IoT CCS perform NAT. The stateful Firewall function allows the Enterprise customer to set up its security policies, including:

• Destination filtering: only send traffic to specific IP addresses or hostnames.
• Protocol filtering: Only allow traffic on specific ports.
• DNS-based filtering: Reject IP address lookup of restricted domains.

Other Security Policies

Apart from the traditional firewalling IoT CCS also features the following:

• Suspend or enable a device/SIM.
• IMEI Lock: A SIM can only be used in a specific device.

Other Features on Customer Request

Most of our best inventions have come from concrete customer requests that we have packaged into products or services. IoT CCS is no exception; it was created in close partnership with our first IoT CCS customer. We have capabilities in Enea’s broader product portfolio and the FortiGate firewall that we can enable if they are in high demand.

Examples of such features include:

• Business-related policies such as
  • Maximum bandwidth usage.
  • Maximum data usage.
  • Location down to individual cell level.
  • Time of day policies.
  • Approved for service, e.g., the bill was paid, and it’s okay to onboard the device.
  • Quarantine: The device needs configuration.
• DPI with quarantine for devices with suspicious behaviors.
• Location lock: The use of a SIM is only possible where you want it to be used.
• More granular protocol filtering going beyond port-based filtering. For instance, filter on MQTT, AMQP, and CoAP.

Beyond the scope of IoT CCS, we also offer leading Signaling- and Messaging firewall security solutions for cellular networks.