8 key factors for an effective Internet of Things (IoT) network

Connected devices, or the Internet of Things (IoT), are exploding on the market. Securing their access has become one of the major concerns in recent years. But security is only part of the equation. What good is a secure network if you cannot access it?

 As more and more devices connect together, the availability to connect becomes paramount. If your business is going to depend on an IoT infrastructure, it must be available, accessible, and safe from attack. If you cannot count on your infrastructure, you cannot depend on it. When selecting an IoT platform, these are the sort of issues that should be considered.

Data Point 1: The platform needs 24x7 uptime.

If your business depends on real-time data for command, control, or even telemetry, the platform must be up in order to communicate.  For example, early last year, a major cloud provider platform went down taking many connected homes with it. Not being able to listen to music is one thing, but not being able to enter your house or turn off your IoT oven is another.  Therefore, platforms that work towards achieving high availability numbers will often leverage multiple distributed servers with no single point of failure. For faster failover, a virtual service that is distributed can often provide higher uptimes than single location platforms with redundant data centers. 

Data Point 2: You need to be able to scale as device volume grows.

Performance and reliability for a thousand devices is one thing, it is quite another to maintain that performance for a million devices. Depending on the desired scale, some platforms may not scale as well as the others. Be cognizant of what happens to the performance and uptime and throughput as the number of connected devices grows. Like with reliability, if your platform cannot scale, it will not be effective as your demand grows. 

Data Point 3: Distributed Denial of Service (DDoS) attack detection and mitigation is essential.

In a perfect world, there would be no bad actors, but Distributed Denial of Service (DDoS) attacks are becoming more and more common. Historically, these attacks are eventually rebuked by whatever security is in place. However, a significant attack can cripple a system’s ability to accept more connections by overwhelming the platform’s ability to authenticate and authorize connection requests. 

These types of attacks are getting bigger and bigger and more coordinated. For example, a 1.3 TBPS attack on a software development company was thwarted by Akamai’s intelligent network. The Memcached reflection attack was the largest recorded to date but is anticipate that it will not to hold that record too long. 

Data Point 4: Authentication and access denial should be equally fast.

If the system needs to call out to another service to validate credentials, connect requests can easily back up and overwhelm the security requests. Additionally, security services need to be able to dynamically scale to reject a massive wave an invalid client attempting to connect.

Data Point 5: Security and IoT services must be decoupled.

Your security mechanisms must be managed separately from the actual service. This allows you to scale separately and protects your platform from becoming unavailable to authenticated clients that are already connected if and when security services fail. 

Data Point 6: Always be prepared for rogue devices and bad actors.

Whether a device has a flaw in its software, a client gets hacked, or credentials are stolen, it’s inevitable that a rogue device will gain access to the platform at some point. Regardless of the situation, you don’t want a bad actor gumming up the works by clogging pipeline or using up too much capacity. You also don’t want a bad actor corrupting your data. Your platform should automatically detect suspicious behavior, such as attempting to connect multiple times, and allow you to permanently or temporarily blacklist devices. 

Data Point 7: There should be different delivery guarantee levels.

There are many different types of data being sent up from the devices. Some data may be large volumes of diagnostic data. Some data may be command and control. Other data may be financial or transactional. Because of this, different levels a delivery confirmation may be required. In the MQTT vernacular, this data would be sent using different Quality of Service (QoS) levels. The diagnostic data can be sent via QoS 0 or send only once. Losing a sample every once in a while, is fine. Command and control can be sent using QoS 1: send at least once, resend if necessary. Finally, transactional or financial data can be sent using QoS 2: send exactly once. Having all levels allows for faster and cheaper transmission of bulk data while increasing the overhead when necessary to increase the delivery guarantee. 

An example of how a QoS may work is, a message is sent from a sensor utilizing QoS level 0, indicating that the machine is powered. A message that is QoS 1, is sent that the machine is operating in an acceptable RMP performance zone. QoS 2 may be message that is received only once that can be used for trend analysis on the RPM of the system based on production runs. 

Data Point 8: Leverage compute at the edge to decrease latency.

With devices scattered all over the world, transmission distances can affect the latency of message delivery. Additionally, performing compute at the origin has the same scaling and failover issues as does message delivery. As such, it is important to be able to leverage compute at the edge in a distributed manner. This not only provides for the scalability and up-time, but it allows for considerably smaller decision latency. 

Securing IoT devices is only the first step in establishing a safe and reliable ecosystem for your devices. But, to truly rely on an IoT network, it needs to be available, it needs to scale, and it needs to be able to protect itself from DDoS attacks and compromised devices. The network should also provide for different delivery guarantees and distributed compute at the edge. These factors must be considered when selecting or building your IoT infrastructure in order to have a solution that you can depend on, and that can grow with your needs. 

Image credit: Jirsak / Shutterstock

Mark M Ingerman is a Senior Product Architect in the Web Performance Division at Akamai. Mr. Ingerman is responsible for the product architecture and definition of Akamai’s IoT product line. Mr. Ingerman has over 20 years of development, architecture, and product road map design experience. Prior  to Akamai, he served as an Architect and as a Chief Architect at various startups as well as a 12-year consulting career. Mr. Ingerman earned his Bachelor of Engineering from Case Western Reserve University in Cleveland, OH.