IoT Device Security: Learn About a Growing Imperative

Billions of devices, all doing something, all connected to something, all generating data. By 2025, deployed and functioning IoT based devices will total more than 5X the world’s population. With this number of devices and trillions of GBs of data being generated daily, malicious actors see a golden opportunity to access these devices and push their agenda as a nation state sponsor of cyber terrorism or simply a criminal gang stealing data for financial gain.
Learn About IoT Device Security
IoT device designers and software developers have to recognize that eventuality their device or system is going to be attacked. The question is, will the inevitable attempt succeed or fail? If security is at the forefront of an overall IoT software design philosophy (also known as: Security by Design), the opportunity to minimize or prevent a successful hack is significantly higher.
What is Security by Design?
Security by Design was developed as a practice just over 20 years ago and is still the best structure for software engineers and developers to ensure that their IoT designs are as secure as possible. In reality, any system, despite best efforts to the contrary, has vulnerabilities that can be exploited. A look at the ever expanding number of reported “common vulnerability events” tells the true story, with 16,555 alone reported in 2018.
So what are some of the key aspects that are required to ensure IoT products and their supporting infrastructure are as secure as possible? IoT devices are, at their heart, embedded systems and the mechanisms used to secure or “harden” traditional embedded products are essentially the same.
Rather than discuss in generalities, we’ve broken the software components comprising an embedded IoT products into categories that represent the high level attack surfaces. The below items represent a small subset of the total number of potential attack surfaces, however, they provide some quick hits that could prevent your company and product from being front page news.
OS
The lion’s share of IoT devices use a Linux OS or a variant thereof. While Linux as a whole is relatively easy to secure, there are a number of attack surfaces that have to considered. As we discussed in our post on secure OTA updating, one of most important of these is securing the boot process. Here are 3 key requirements for this:
Ensure the device boot process loads trusted code image
Have a mechanism to verify that the code is indeed valid
Verify using public key cryptography
With a secure boot process there is no avenue for malicious actors to replace a boot image with a corrupted version, reboot the device and take control.
Networking
IoT means connected and this connectivity means TCP/IP, Ethernet/WiFi or Bluetooth. Networking means that there are numerous attack surfaces that can be exploited. By far the majority of IoT devices will be connected to a network via WiFi and this is probably one of the most overlooked attack surfaces. One key preventative design action that can lower the probability of a device being compromised through WiFi is to ensure that only secured connectivity is permitted:
Set a minimum secure WiFi connectivity standard for the device
Refuse to establish a WiFi connection with a network if there is no security in place or only minimal security is configured
Establishing and enforcing a minimum security connection standard, such as WPA/WPA2 or WPA Enterprise/WPA2 Enterprise will ensure that any WiFi based communications are secure and also prevent the IoT device from being used as the illegal entry point into a network.
Management/Monitoring
Depending on the device type, usage and location, management/monitoring of an IoT device may be required. This can be accomplished in 3 or 4 different ways; in-device webserver, web-based application which pulls management/monitoring related data from the device, direct login to the device or finally via SNMP.
Any of these management/monitoring interfaces have multiple attack surfaces and all of them should be reviewed and looked upon as opportunities to close vulnerabilities. If IoT devices are going to be used in an enterprise or manufacturing environment, it is almost certain that network infrastructure administration teams are going to include these devices as part of their monitoring strategy. This means that to ensure that their devices can be monitored by existing network management tools; the device software development team has to include SNMP functionality in the product and that it is addressed as a security by design objective:
Specify that only SNMP v3 is used on the device as v1 and V2 are not secure
Use minimal necessary permission to implement SNMP; add watchdogs to ensure SNMP daemon is not stopped, or reconfigured
Allow ability to disable SNMP, if it is not being used. Ability to disable functionality helps to reduce attacker’s surface area for exploitation
Data
A connected thermostat or an IoT device in a manufacturing environment monitoring a process generates data even though the purpose for which the information is used is completely different. Many IoT devices are specifically designed for a particular function and to keep price points low are running the minimum hardware needed to allow the device to run and function.
When a device is operating and generating data, the data cannot be stored locally and must be sent to a back-end system in the cloud or on-site for processing, storage and presentation. Data integrity is paramount, especially in enterprise and manufacturing and needs to be a high priority objective for IoT software engineers and developers for any devices used in these environments. Beyond secure connectivity, data integrity protection is an absolute requirement.
Any data transmitted between an IoT device and a local or cloud-based back-end must be encrypted
Data protection can be hardware or software based
Encryption should use PKI or certificate system and at a minimum use the AES standard
Despite Deadline Pressure, Security by Design is a Must Have Approach in Engineering
While some of these security by design objectives may seem trivial in nature, it is amazing how frequently they are overlooked in the rush to meet a sprint date, launch deadline or hit a market window.
The TRENDNet IP camera debacle is a classic example of not paying attention to the security by design principles. TRENDnet marketed its SecurView cameras for various uses, ranging from home security to baby monitoring and stated they were secure. Turns out the software was flawed and allowed anyone, who obtained the IP address of a camera to view what the camera was transmitting and infrequently listen in as well.
To add insult to injury, when camera owners remotely accessed their device, the user login credentials were transmitted in the clear. No encryption, nothing. The implications of this lapse go far beyond access to cameras, as hackers are presented with a wide open door for further malicious activity, such as PII theft or worse. This door is opened to them by the simple fact that most people are not security conscious and reuse credentials, specifically IDs and passwords, for multiple accounts. With some simple research about the target, hackers are basically handed the keys to the kingdom.
A comprehensive review of IoT device security during hardware and software development process will ensure that attack surfaces are minimized and any vulnerabilities found are addressed before the product ships.
Click here to read more posts on IoT device security and more.