Skip to main content

IoT security failures are no child's play

(Image credit: Image source: Shutterstock/everything possible)

Just over the past few years, the Internet of Things (IoT) has emerged as a powerful and widespread technology. In fact, IDC has estimated there will be 41.6 billion connected IoT devices, generating 79.4 zettabytes of data by 2025, with the global IoT device management market anticipated to reach $5.1 billion.

With more and more devices connected to the internet every day, from self-driving vehicles to children’s toys, it’s safe to say that IoT devices are everywhere. Considering this, it should come as no surprise that vulnerabilities found in IoT devices have more than doubled since 2013 -- meaning IoT security must be top of mind as software and devices continue to be developed.  Furthermore, as the number of organisations embracing IoT continues to grow, so does the number of consumers who are unaware of the potential threats associated with software vulnerabilities. This includes a lack of understanding of how or why it is critical to manually update devices as patches are released.

So how can organisations combat this and develop fundamentally more secure IoT devices? A key step is inserting security as far left as possible -- at pull requests -- to reduce the number of exploitable vulnerabilities that make it into production. And developers should be on the front lines of helping to achieve this.

How bad could these vulnerabilities really be?

Could a software vulnerability in an autonomous vehicle allow an attacker to permanently depress the gas pedal in thousands of vehicles at the same time? Could embedded devices on a construction site be exploited to take over critical machinery and equipment? While the prospect of these scenarios may sound dramatic, they are plausible and must be taken seriously.

We’ve already discussed how the number of IoT devices and software programs have reached unprecedented highs, which means the opportunity for unknown and evolving security risks and vulnerabilities is bound to reach new heights. Take these instances, for example:

  • The explosion of privacy issues and scandals surrounding Amazon-owned Ring. Researchers found several flaws in the IoT device, including one that allowed attackers to spy on families, and even one that exposed Wi-Fi network passwords.
  • At Black Hat USA 2019, researchers demonstrated the ability to exploit flaws in the LeapPad Ultimate tablet, which serves as an educational device for children. The flaws could allow bad actors to track the devices, send messages to children, or launch man-in-the-middle attacks.
  • The 2009 Stuxnet computer virus that crippled the Iranian nuclear facility in Natanz, Iran. Yes - the implications have the potential to be nuclear.

So how can software-driven organisations better protect devices? And, what can be done during the software development life cycle (SDLC) to ensure vulnerabilities are identified and fixed in development, or prioritised for remediation in production based on actual usage? First, let’s consider the programming languages IoT programs are written in.

The popular choice when developing IoT code is C and C++. Why is this, when there are more secure, next-generation languages? The fact of the matter is that C and C++ are optimised for IoT. They have lower defect rates than other languages, which means updates are required less frequently. As low-level languages, they also have fewer hardware requirements making it possible for companies to reduce the number of IoT components they manufacture and ultimately trim costs. IoT devices have specific/limited purpose. Writing this in a language like C/C++ allows the company to use cheaper and lesser hardware (including memory and compute power) to achieve the purpose. This ultimately means developers can create digestible code that can be inserted into a single, small chip for little cost at faster production speeds.

What does this mean for consumers? Often manufacturers avoid adding over-the-air (OTA) update capabilities, as they require additional work and may result in higher hardware costs. As a result, most IoT devices are not easy to update. Take that smart coffee pot you bought two years ago, for example. The chances of you buying the newer model when something stops working is much higher than figuring out how to push a software update to it. Not to mention, manufacturers would rather create newer product versions than push updates for older devices, so often updates aren’t even provided.

Since IoT devices inherently have smaller hardware footprints and are not indefinitely connected to the internet, it is important to get security right the first time around. This also ensures software updates and patches pose less of a threat since the likelihood of them issuing those patches is slim.

Unfortunately, the use of C and C++, particularly for IoT, has made it abundantly clear that legacy code analysis tools are not equipped to handle the scale and speed needed to keep up with innovation, while also keeping software secure.

Ensuring secure and quality IoT software

Legacy code analysis tools rely on manual intervention to prioritise and triage threats, reducing accuracy, speed and scalability. They also yield an abundance of false positives, hindering teams from making quality and accurate decisions - ultimately compromising the speed of development.

It is no wonder that developers have lost faith in these tools, as they are inherently slow and cannot accurately identify vulnerabilities. Because of this mindset, crucial flaws are often ignored due to a lack of trust in the accuracy of the scan. As a result, developers unknowingly push vulnerable code into production phases with the hope that flaws won’t be exploited.

So what can developers do?

To ensure code is as secure as possible, the right developer needs to receive the right vulnerability information at the right time. This allows them to more efficiently address vulnerabilities in their respective code, improving the overall security of the final build. To achieve this, security needs to be inserted as far left as possible, at the pull request. In doing so, developers can make quality security decisions without compromising on speed and accuracy. Vulnerabilities can be identified and remediated before they reach production.

On a more granular level, developers need to understand what must be addressed when developing and deploying IoT software. The OWASP Top Ten IoT list is a great source that helps technology and security teams understand how threats are developing year over year.

By addressing these issues as early in development as possible, and not in production, developers can create secure software, allowing for a rapid release, and reduce the need for multiple software updates. In turn, consumers can trust they’re getting the most secure devices as possible, and organisations can drastically reduce the risk of vulnerabilities in IoT devices.

Chetan Conikee is Chief Technology Officer at ShiftLeft

Chetan Conikee is the co-founder and CTO of ShiftLeft. Chetan is a serial entrepreneur with over 20+ years of experience in authoring and architecting mission-critical software. His expertise includes building web-scale distributed infrastructure, personalization algorithms, complex event processing, fraud detection, and prevention in investment/retail banking domains. He was most recently Chief Data Officer and GM Operations at CloudPhysics. Prior to CloudPhysics he was part of early founding teams at CashEdge (acquired FiServ), Business Signatures (acquired Entrust) and EndForce (acquired Sophos). Chetan earned his M.S. in Computer Engineering from Iowa State University and B.S in Computer Science and Engineering from Bangalore University.