How to put the S (for security) into your IoT development

A joke about the Internet of Things has been shared around Twitter over the past few months; I saw it attributed to a guy named Tim Kadlec. “The S in IoT stands for security.” Think about that for a second, and you’ll say, “Wait, there is no S in IoT.” That is exactly the point of Kadlec’s statement. IoT is missing security.

This doesn’t have to be the case. There are no fundamental, groundbreaking reasons why IoT devices are not secure by default. The lack of security in IoT is a choice that developers have made. This lack of security is a tradeoff that was made between time-to-market and security strength. It is time for an industry shift to a focus on security, so that security is embedded within all IoT products.

An IoT product is only as secure as its foundation. If security is approached in an ad hoc manner, then ad hoc results are all that can be attained. IoT developers must build security into everything, incorporating security early and often, from the time the product is dreamt up on a napkin or a whiteboard until the product reaches its end-of-life stage. Building security in raises security to the same level as any other driver within the product.

Building security into the IoT requires a standard approach to security. An industry standard for building security in has evolved over the last 15 years, and it is called Secure Development Lifecycle (SDL). SDL provides a standard, repeatable process containing security activities that improve the security of a product.

An SDL incorporates things such as security user stories, threat modeling, static/dynamic analysis, secure coding, and a product incident-response team. These activities have been validated as best practices through the experiences of the many companies that incorporate SDL.

To date, IoT development has been missing this standard approach to developing secure products.

Here are key actionable areas for building security into IoT development. There are many more, but in my experience, a product must embrace these areas as the beginning of their security journey.

The first area involves security user stories. These are just like regular user stories except that they focus specifically on security functionality in a product. Basic security user stories should be incorporated into IoT product development from the beginning of a project.

Authenticate all services, regardless of how trivial

With authentication, any entity attempting interaction with a system must prove their identity prior to gaining any access. Authentication is foundational; without it, it is difficult to control anything else on a platform.

The IoT introduces a unique wrinkle with authentication. IoT systems deal in end-user communication and machine-to-machine communication. Both require authentication. End-user authentication can employ traditional username/password, certificate, or two-factor authentication. Strong machine-to-machine authentication requires a public key infrastructure and certificates that are deployed to each device within a system. In many IoT devices, there is no console, so authentication must be baked in and support the ability to update the credentials if needed, during the life of the product.

Encrypt all data in transit using industry-standard, open encryption technology

Encryption takes information that your customers send and receive through your IoT system and runs it through a mathematical formula to scramble it so that only those with a special key can unlock the data.

IoT devices deal with data, and that data must be protected as it transitions from the device, across the Internet, and into the cloud. IoT devices need to incorporate industry-standard encryption libraries to ensure that the data is safe and secure during transfer.

It can be tempting to think that, as an IoT developer, you have a better idea for how to scramble and transfer data securely, but it is best to utilize industry-standard, peer-reviewed cryptographic functions. You are not smarter than all the cryptographers on the Internet.

Enable secure, automatic over-the-air updates to patch devices

In the early days of the IoT, devices were created quickly, and some developers forgot a basic feature: a method to update the device after it reaches the field. It is crucial to provide a secure update mechanism. A secure update mechanism is one that receives a cryptographically signed update from the vendor and checks the signature of the update to ensure that it is valid and truly from that vendor. Vulnerabilities will continue to be found in IoT devices, and a method to patch those vulnerabilities must exist.

The other catch with IoT devices is that in most cases, there is no console or user to perform the update. Updates must happen over the air, with no interaction required by the user.

Manage and update your open-source software

Open-source software is included in everything these days, and IoT devices are no different. A whole ecosystem has sprung up of open-source IoT platforms and libraries. IoT devices also rely on some of the same open-source software that web applications use, including libraries such as OpenSSL.

Open-source software suffers from vulnerabilities at the same rate as custom-written code. The biggest challenge with open source is that many developers include it in projects and then experience amnesia when it comes to updating it. They rely upon the savings it generates without acknowledging that those savings up front require work throughout the lifecycle in updating the libraries to a later version when issues arise.

Generate an open-source update plan for your IoT projects and stick to it. Know what open-source components are included within your product and assign someone to watch for published vulnerabilities in those components. When a vulnerability arises, update the software, test the integration, and then deploy an update to limit your customer’s risk.

Be wary of carrying over web apps’ vulnerabilities

The web app is the standard approach to administering an IoT device, but that means you inherit the web app’s potential security vulnerabilities. Ensure that your developers are using vetted frameworks for their web development and are aware of the OWASP Top Ten. The Top Ten is an industry-standard list of the most prevalent risks to web applications, and these issues can manifest in an IoT admin app just as easily as in a standard web app.

The IoT needs built-in security

As the use of IoT devices continues to expand, the amount of data they contain also expands. Built-in security is the answer, but it must be a conscious choice. Developers of IoT must embrace security and security user stories. They must understand encryption and ensure that it is utilized. They must track their open-source software and ensure that it is properly updated. They must write admin interfaces that are not riddled with problems identified in the OWASP Top Ten. All of this is possible, with focused effort on security.

Image credit: Flickr

By |2018-05-15T17:29:08+00:00May 15th, 2018|