5 reasons why device makers cannot secure the IoT platform

If Akamai, Cisco and Google’s post-platform security and privacy machine learning security systems protecting the web and mobile platforms are indicative of the future, IoT device makers will only be part of a larger security ecosystem. That’s because they will not have the data to train the AI machine learning models.  

As a result, IoT post-platform security and privacy will become a layer on top of IoT device security. These five factors are why that will happen.

1. Product developers underestimated IoT security

In their race to market, product developers building for new platforms will underestimate the security and privacy features that should be built into their products. In some cases, this will be an act of commission, but most will be an act of omission because it is difficult to anticipate the vulnerabilities until the products reach the market at scale. Windows and mobile devices experienced something similar. They have been hardened, but earlier in their evolution they were an easy target for cyber criminals.

2. Defending the IoT perimeter and endpoints will fail

There is no perimeter in IoT to defend, and defending the perimeter has failed on all other platforms. One look at the list of largest breaches, and you’ll see most companies victimized by the cyber criminals relied on defending the perimeter. Though much less frequent, mature mobile and PC endpoint zero-day vulnerabilities are still discovered and exploited. A better outcome for IoT devices cannot be expected. 

3. Bank robbers go where the money is; cyber criminals go where the vulnerabilities are

IoT in its infancy has demonstrated vulnerabilities attracting cyber criminals due to weak security. Cyber criminals may be attracted to these devices because they are an easier target than mobile and windows platforms.

4. Security and privacy for small memory microprocessor based IoT devices are still being invented

Developers with IoT devices built on larger 32bit processors that run Linux have the option to add strong security based on the 25-year history of Linux’s development. It does not guarantee that product developers will take advantage of Linux’s rich security. But building low-cost and power-efficient IoT devices with microcontrollers and small memory footprints is a new security problem that cannot draw on prior platforms for security. Many IoT devices will be shipped before the IoT platform is hardened, exposing billions of devices to exploits.

You can see in the below comparison of a typical battery-powered microcontroller configuration to web transport layer security (TLS ) that encrypts browser traffic why security and privacy protection built for mature robust platforms like mobile and windows will not fit.

IoT device:

16 KB RAM

128 KB Flash

Low-power WAN with physical layer packet sizes limited to about 100 bytes

Applications that minimize communications to extend battery life

TLS:

TLS is designed for large bandwidth internet WAN networks.

TLS certificates are over 1 KB and require two round trips to establish an encrypted link.

TLS requires a minimum of 4KB of memory not including its libraries with over 100 algorithms.

Standards to protect IoT are in development by the Internet Engineering Task Force. Part of the transport security of small memory microcontroller IoT devices has been standardized with Constrained Application Protocol (CoAP), a lightweight HTTPS-like protocol, and Concise Binary Object Representation (CBOR) for a human-readable data representation of attribute–value pairs and array data types like JSON used by browsers, but more compact.

In addition, CBOR Object Signing and Encryption (COSE) for securing CBOR objects and Object Security for CoAP (OSCoAP) for securing CoAP messages are in development and remain drafts.

While standards are proposed, debated and ratified, IoT device makers are shipping vulnerable devices with either the best available security features or as many as can fit their development schedules.

5. IoT does not have the data to train machine learning models to defend the IoT platform

The high accuracy of natural language processing, language translation and photo classification demonstrate the potential for applying machine learning to IoT security. Akamai, Cisco and Google have built post-platform security solutions to fill the perimeter and endpoint security and privacy gaps of mature mobile and web platforms using machine learning.

Machine learning requires a lot of data to train the models. Google consumed one -hird of the internet to train its language translation models. Akamai at any moment holds one-sixth of the internet’s traffic within its network that it used to build its Kona Site Defender platform to protect its customers against Distributed Denial-of-Service (DDoS) and web application attacks. But there is not a trusted entity like Google or Akamai that has access to a large corpus of IoT data to train a machine learning security model to protect the IoT platform comprised of diverse platforms.

Akamai, Cisco and Google’s post-platform machine learning security methods

Akamai has used machine learning security behind the scenes to improve products and defend themselves against DDoS and web application attacks. The models are now products to which customers have access to tune the models to their websites. Machine learning model accuracy can reach the high 90 percentiles. Web requests can be hard to classify as malicious or benign, though. A customer’s website may be a corner case with less accuracy deviating from the high accuracy of experienced across Akamai’s network. The Kona Site Defender reports these hard-to-classify cases so customers can acquire the data to retrain the models trained on enormous corpora of data with a small amount of data to increase the accuracy in categorizing web requests as malicious or benign.

Cisco wanted to protect itself from malware in encrypted traffic without sacrificing its employee’s privacy. Google and Mozilla have influenced web developer to use TLS to protect data during transport between server and client. Attackers abuse the internet’s trust system by forging, stealing or even legitimately signing SSL certificates to encrypt and camouflage their attack. The obvious solution is to set up a proxy server between the server and the client to decrypt the packets and inspect them, like a man in the middle attack at the cost of violating user privacy.

Cisco chose a different approach preserving user privacy. By analyzing millions of sample TLS flows, malware samples and packet capture, it found that the unencrypted metadata in a TLS flow contains fingerprints that attackers cannot hide, even with encryption. After completing the analysis and understanding the machine learning model that they needed to create and train, the development team acquired much more TLS flow data than the sample data to train the model.

Google’s Android security uses a machine learning model trained to identify malware that runs on Android phones. The trained model called Play Protect is updated with up to date vectors regularly from a central machine learning model that is retrained with samples of malware and meta data which can be re-trained to categorize new malicious apps on as little as 100 malware samples. Similar models categorize apps uploaded to the play store as malicious or benign.

IoT security standards will be just part of an ecosystem that emerges to protect IoT devices. An IoT machine learning layer on top of endpoint and perimeter security will likely arrive as soon as enough data is available as a third layer of defense.