You’ve just been hired as an architect in an up-and-coming startup. The company has the most brilliant and innovative idea for a smart device that will make you all rich. Your job description is very interesting, and your first mission is to ensure that what the company builds is secure.

First of all, congratulations are in order: Just by thinking about security, your company is already miles ahead of everyone else in the internet of things (IoT) space. As the joke goes, the “S” in IoT stands for “security.”

Why would the IoT be a special case? What’s different about it from any other project? Pick a secure development life cycle (SDLC) framework, shift your security left as much as you can and surely the result will be secure by design, right?

Unfortunately, IoT is a very special case indeed, and the evidence can be seen almost every day in the news. What makes it so special, and how can companies produce secure internet of things solutions on top of all the other security best practices they need to juggle?

IoT Security Is a New Challenge for Developers

An IoT solution, when we look at it as a whole, contains more than just applications. There are other moving parts — sometimes literally — that need to be secure for the whole thing to be secure:

  1. Hardware — By its nature, hardware has a slower turnaround cycle than software, and if a security issue is found in testing, it’s often too late to fix it prerelease.
  2. Infrastructure — It is not enough for the code running on the smart gadget itself to be secure; the infrastructure to communicate with the control center and the access to the control center must be secure as well.
  3. Communication protocols — Some IoT projects are locked in some really old communication protocols that lack modern security features.

For these reasons, an organization that develops IoT products faces extra challenges compared a web and mobile app development. The technology stack is wider — there will be embedded software, web portals and mobile apps to manage the devices and everything in between. Any issues discovered in hardware design or supply chain will be very difficult to resolve for the initial release and will most likely require workarounds and mitigations in software. If the solution has to use insecure legacy protocols, the options are quite limited: Either do nothing and hope for the best (no such luck if you use a protocol with known vulnerabilities) or build some custom compensating controls — which is better than the former head-in-the-sand option but, from the attacker’s point of view, presents an additional attack surface.

The biggest issue, though — the essence of what makes the IoT so difficult to secure — boils down to a principle that security engineers learn on day one of their education: There is no such thing as client-side security. If an attacker has physical access to a device, they will bypass whatever controls you put on the device given enough time and motivation. While attackers often aren’t particularly motivated to hijack a single device, potential communication weaknesses, such as a protocol that does not support authentication, can lead them to discover vulnerabilities in the control center and, before you know it, you’re running from a fleet of flying smart kettles chasing after you.

If you need more reasons to envy developers of plain old web apps, think about how simple they have it when it comes to updates: Just push the new code to the web server and, whether they like it or not, users are interacting with the latest version. Not so for IoT architectures; remote updates for connected devices are hard to get right, and since our threat model includes a malicious user with physical access to a device, we have to account for the possibility of an attacker actively subverting the update mechanism.

Lastly, you are likely to have developers (either directly on your teams or with your suppliers) that do not come from a software engineering background and are thus not familiar with the current concepts of security, such as defense in depth, shift left and more. This not only leads to the lack of security basics, but often manifests itself in a tendency to invent or reinvent custom security mechanisms.

In your role as the security architect, you will also have to fight feature creep. Of course, you want the first version of your software to have great features, but from the attacker’s point of view, richer functionality means a larger attack surface.

Customizing the Generic SDLC for Internet of Things Solutions

If you thought the list of challenges above was overwhelming, wait until you see the list of applicable standards and other academic and industry papers about IoT security. The good news is that the U.K. government cross-referenced and distilled all of this advice in its “Code of Practice (CoP) for Consumer IoT Security,” and the Department for Digital, Culture, Media and Sport (DCMS) created a helpful graphic that visually maps global IoT security and privacy recommendations to the CoP.

Security activities mapped to the phases of SDLC

All of the usual SDLC advice still applies, and the activities in the diagram are crucial to ensure that an IoT solution is secure by design. Security teams should also consider the following guidelines, some of which are domain-specific:

  1. Embed the thirteen recommendations from the “Code of Practice for Consumer IoT Security” into the requirements, architecture and test cases.
  2. Make sure threat modeling accounts for physical access to the devices and the attacker’s goal to own the control center.
  3. Conduct attack surface analysis (ASA) and resist feature creep.
  4. Since continuous integration and deployment (CI/CD) automation may not be equally achievable in all the strands of the technology stack (embedded, networking, web apps, mobile apps, back end), prioritize this activity according to the risk to the overall solution.
  5. Do not invent your own security mechanisms or cryptographic algorithms.
  6. You can use client-side checks for performance reasons, but only make security decisions on the server-side.
  7. When it comes to supply chain security, a solution is only as secure as the weakest link. Ask yourself, what assurance do you have on the integrity of third-party binaries and source code, keys and certificates, and data?

Picking a secure SDLC framework and shifting your security left isn’t enough to develop secure internet of things solutions. In your role as the security architect for IoT solutions, you will need to define a security program that leverages a tailored approach to hardware, infrastructure and software layers to meet your organization’s security needs. The industry as a whole may not be ready to put an “S” in IoT, but your solution can be secure by design if you apply guidance like the “Code of Practice for Consumer IoT Security” to existing best practices for building security into the development life cycle.

More from Application Security

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…

A View Into Web(View) Attacks in Android

James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

Twitter is the New Poster Child for Failing at Compliance

All companies have to comply with privacy and security laws. They must also comply with any settlements or edicts imposed by regulatory agencies of the U.S. government. But Twitter now finds itself in a precarious position and appears to be failing to take its compliance obligations seriously. The case is a “teachable moment” for all organizations, public and private. The Musk Factor Technology visionary and Silicon Valley founder and CEO, Elon Musk, bought social network Twitter in October for $44…