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.