Making IoT Secure: A Holistic Approach

The IoT (Internet of Things) has changed the way we interact with machines of many kinds. It has influenced the way we live and work, and IoT driven trends such as smart cities have improved our quality of lives and the environments in which we live. But as the IoT has grown, its security has become one of the most prevalent concerns of the security community.

A recent survey of businesses in the US showed that nearly half of US companies using an IoT network have experienced a security breach, which can cost up to 13 per cent of smaller firms’ annual revenues. Nearly half of larger firms with annual revenues above $2billion estimated the potential cost of one IoT breach at more than $20 million. Furthermore, 70 per cent of respondents said that IoT security breaches were more costly to deal with than traditional breaches or incidents.

Why and how has this happened? What are the risks and challenges it presents? How can we safeguard networks, devices and users? What is a comprehensive end to end approach for IoT security? And what should each of the players in the IoT ecosystem do to assure such security?

The built-in vulnerabilities of IoT

When IoT emerged, the industry’s priority was to rapidly produce and sell devices, and enable them to communicate. The most important considerations for device manufacturers, IoT connectivity vendors, IoT application providers and network operators were that they were available (cheap), connected and manageable. Protecting IoT devices from external attacks was not a significant consideration. It was only an after-thought. Often, devices merely had easily-breached default security settings built into them. In many cases, they had no security measures at all.

Now, IoT network and mobile operators are considering the problem more deeply. Their two main concerns are how to deliver a secure IoT service or security VAS in addition to IoT connectivity. Both general purpose and dedicated IoT service providers face a challenge to safeguard their own infrastructure from attacks initiated by IoT devices deployed within their own network.

Current risks and challenges

Broadly, all IoT devices / services are either Machine to Human (M2H) or Machine to Machine (M2M).  M2H devices include home-based items (refrigerators, washing machines, Amazon Echo) and those deployed within the enterprise network (printers, connected x-ray units, etc.) They share the same network infrastructure with all other local devices, including those that are not IoT-related. These devices risk being:

  • Compromised and can stop performing their main function properly, or completely
  • Part of a botnet and can infect other devices in the network
  • A bridge to the local network for intrusion
  • Used for accessing private data and allow data leakage
  • Used for initiating DDoS attacks on internal and external resources
  • Contributing to network congestion due to massive data transfer

Machine to Machine (M2M) devices are usually deployed as standalone remote units and they communicate with the IoT service backend via mobile networks or a dedicated gateway. Examples include gas pressure meters on gas pipes, control units of power turbines, electricity usage meters, automated car systems for engine health monitoring and collision avoidance. Machine to Machine (or Industrial) IoT is fast-growing with far-reaching consequences. These devices risk, for example:

  • Malfunctioning, leading to severe damage when they are responsible for critical workloads (such as gas pipes or moving cars) or revenue loss
  • Sensitivity to quality of the communication channel (e.g. monitoring systems in the area of healthcare)
  • Becoming used as part of distributed botnet
  • Experiencing compromised communication channels or impersonation of the agent or server
  • Causing damage when legitimate commands (e.g. “controlling the spin of a turbine”) are used in an unauthorized way or directed by an unauthorized source

So, although IoT provides significant benefits, enabling modern trends such as autonomous cars, smart grid and smart cities, what comes with these benefits is more threat.

How do we enjoy what IoT can bring while ensuring that network and users’ data are secure, that legitimate traffic runs swiftly and smoothly, devices operate well, and users can be assured of a high quality of experience?

A comprehensive approach to IoT security

Robust IoT security requires a holistic approach that involves coordinating security measures (both preventative and reactive) between the following different elements of an IoT service supply chain, these include:

  • IoT devices
  • IoT Gateways
  • IP core network (e.g. Core network of CSP)
  • Communication and Application provider’s cloud

End to End policy enforcement

The main principle of End to End (E2E) policy controls is coordinated behavior control, anomaly detection and security responses across all critical elements of the IoT service supply chain:

  • Behavior control
  • Anomaly detection
  • Security response

Let’s take a look at each of these in turn.

Behavior control

Since most IoT services have a well-defined and expected behavior pattern, the definition of a behavioral profile can be associated to different types of IoT-based services or they can be particular to a specific IoT deployment. Behavior control is based on the applicable security capabilities of each element in the chain and is specific to the function and position of the element.

Ecosystem element Security capabilities
IoT device Separation of the business logic and infrastructure elements, etc. (KasperskyOS, Google’s AndroidThings/Brillo, Windows 10 IoT Core, etc.)

Ability to remotely “reset” the device

Automatic reporting on performed actions

IoT Gateway Limiting Protocol usage, Applying Firewall rules for communication, Bandwidth limits, Open ports and services
IP core network FW rules, limits on usage of protocols and applications , connection establishment rates, time and volume of communications
Communication/Application Cloud E2E authentication, authorization and data privacy

Patterns of legitimate actions sequence (taken actions to be reported by device)


Some of the security capabilities are defined by the use case (e.g. protocols for vending machines, or bandwidth limitations on car entertainment systems), while others are specific to the particular IoT service (e.g. IP addresses).

In all cases, and in order to apply and enforce secure policies, we need to understand the typical behavior of the different IoT devices. Then we can establish clearly what they should be doing, and easily identify when they are behaving anomalously, so that necessary security measures can be activated.

Anomaly Detection

Anomaly detection is based on predefined rules that describe deviation from the behavior profile of the IoT deployment. They can be strict and specific to an IoT deployment or loosely defined based on a generalization of the use case. Some of the rules can be dynamically built baselines or verbatim rules that apply to a very specific deployment.  Examples of anomalies are:

Ecosystem element Behavior profile parameters
IoT device Unexpected system calls

KPIs of CPU load, memory usage, I/O rate and volume

Deviation of communications pattern

Bot activities of IoT devices: port/ip scans, etc.

IoT Gateway Open ports/services

Bot activities of IoT devices: port/ip scans, etc.

Command and control communications

IP core network Bot activities,

C&C communication,

Unusual volume of a protocol/application traffic.

Other network behavior anomalies

Violation of FW rules

IPS/AV hits (based on the cloud intelligence feeds)

Communication/Application Cloud Predictive analytics

Anomalies in Operation and Maintenance (O&M) data patterns

Devices activities (taken actions)

Failed authentication attempts etc.


End to end communication of anomalies between core ecosystem elements would enable a coordinated comprehensive security response.

Security response

A coordinated security response can be initiated by any of the core ecosystem elements that detects an anomaly. The action can be taken by the same element or other element(s) depending on the type of violation. For example, if the IP Core Network detects bot activities, network policy enforcement points can take action to block the traffic from the device, reset connections to suspect command and control servers and notify the operations center of a security event. Similarly, if an IoT device detects an unusual memory usage, it might indicate to the Application cloud that some device activities should be suspended.

The information about new threats and malware should be shared globally through threat intelligence services to facilitate preventive actions, e.g. new malware signatures to be downloaded to the IP Core Network security element, or device patch downloads to fix vulnerabilities, or closing of communication ports that are used by the new threats.

Next steps

Cross vendor interoperability is required to build a solution for end to end IoT policy enforcement. There is now a strong market demand for IoT security, based on a growing understanding that security issues will soon become the main obstacle for wider IoT adoption. At the same time, this concern might create a business opportunity for vendors who can present the most comprehensive solutions.

Even before end to end security is implemented, security vendors should focus on tailoring their security products to specific IoT use cases, by creating predefined configuration templates for them, investigating vulnerabilities in specific use cases, and defining best practices.

Allot is currently working with a number of large service providers to define security best practices for common IoT use cases.

For further information on IoT security, click here to learn about Allot IoT Defense for service providers, or click here to learn about Allot IoT Defense for enterprise.

How Israel’s Tech Experience Can Protect “Smart Cities”
The DDoS Education Series Part 1/4: You’re Going to Need a Bigger Boat: Staying Afloat Against TOS Flood Attacks

Leave a Comment

Your email address will not be published. Required fields are marked *