IoT Security – What’s our Vector?

IoT security failures such as the Mirai bot DDOS attack have served to remind us that failing to secure IoT devices can have serious consequences.  

As we rise to the challenge of securing the next generation of IoT devices, it is important to start by identifying the vulnerabilities in IoT systems before launching into building solutions.

Security is a Weakest-Link Problem
When planning the security for any system, keep in mind that security is a weakest-link problem.  Consider all the security aspects of your system as if they were links in a chain.  When tension is placed on that chain, it will be the weakest link that breaks. For example, you may have the fanciest encrypted secure booting features enabled in your system, but if you ship with a default password or JTAG pins populated, all your efforts in other areas will be nullified by these mistakes.

Consider your Attack Surface
The concept of an attack surface is as old as computer security.  The attack surface is all of those points of vulnerability (called attack vectors) where attackers can attempt to access the system to cause harm.  Attack vectors can be in firmware, hardware, system design, physical design, or process.

The Simple Stuff – Lock the Front Door.
Millions of IoT devices have been placed into service with their default access passwords left unchanged.  Simply requiring passwords to be changed during installation is table-stakes level stuff in security.

Reduce the Attack Surface
Many IoT systems are built on full featured operating systems such as embedded Linux.  By default, these operating systems have a plethora of interfaces into the system – Telnet, FTP, serial console, SSH.  These may be a required feature in the system.  Or, they may be just an unnecessary door left open, a weak link in the security chain.  Even if they are necessary, there are strict protocols for securing each of these interfaces which are well know from the server community. 

Physical Attack
Unlike PCs and server based systems, embedded systems have a long history of physical style attacks.  The same electrical engineering skills, development tools and in-circuit emulators that are used to build embedded systems can also be used to pry them open and attack them.  Signals on a board can be traced, snooped, and decoded.  In a few minutes, firmware can be siphoned out of an EEPROM, to then be examined offline for hours.  The best prevention from physical attack is to prevent physical access to the system, but this is not always possible.  Techniques such as secure encrypted boot, and encrypted file systems can protect ‘data at rest’.  Encryption of data during transmission can protect a system from excess scrutiny while it is running.

Remote Update – a Double-edged Sword
The ability to update the software in an IoT device in the field is important for security.  If a software vulnerability is found, the software must be updated to fix the vulnerability.  If not properly protected, this same remote update can be used to install all sorts of malevolent software into the system.  For that reason, in-the-field update should be combined with application verification and/or secure encrypted boot to validate whatever image is loaded.

Conclusion
Security is an integral part of any IoT design, not something to be left as an afterthought to be bolted on at the end of a design.  The first step in building a secure system is identifying where it is likely to be insecure.  Then security can be properly considered in every step of the design process.