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

Critically close to zero(day): Exploiting Microsoft Kernel streaming service

10 min read - Last month Microsoft patched a vulnerability in the Microsoft Kernel Streaming Server, a Windows kernel component used in the virtualization and sharing of camera devices. The vulnerability, CVE-2023-36802, allows a local attacker to escalate privileges to SYSTEM. This blog post details my process of exploring a new attack surface in the Windows kernel, finding a 0-day vulnerability, exploring an interesting bug class, and building a stable exploit. This post doesn’t require any specialized Windows kernel knowledge to follow along, though…

Gozi strikes again, targeting banks, cryptocurrency and more

3 min read - In the world of cybercrime, malware plays a prominent role. One such malware, Gozi, emerged in 2006 as Gozi CRM, also known as CRM or Papras. Initially offered as a crime-as-a-service (CaaS) platform called 76Service, Gozi quickly gained notoriety for its advanced capabilities. Over time, Gozi underwent a significant transformation and became associated with other malware strains, such as Ursnif (Snifula) and Vawtrak/Neverquest. Now, in a recent campaign, Gozi has set its sights on banks, financial services and cryptocurrency platforms,…

Vulnerability management, its impact and threat modeling methodologies

7 min read - Vulnerability management is a security practice designed to avoid events that could potentially harm an organization. It is a regular ongoing process that identifies, assesses, and manages vulnerabilities across all the components of an IT ecosystem. Cybersecurity is one of the major priorities many organizations struggle to stay on top of. There is a huge increase in the number of cyberattacks carried out by cybercriminals to steal valuable information from businesses. Hence to encounter these attacks, organizations are now focusing…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today