Heise DevSec: the importance of "security-by-design" for smart devices

With much anticipation, the Heise DevSec Conference was held on October 4th through the 6th at the IHK Haus der Wirtschaft in Karlsruhe, Germany. It's safe to say it was a huge success.

Presenting to an audience of over 180 DevSec delegates, Mender Head of Developer Relations, Josef Holzmayr, stressed the importance of over-the-air (OTA) software updates as a crucial part in ensuring security-by-design – not only for the cloud, but also for all connected devices.

Josef delivered this important overarching message, stating, “Security-by-design means to design from the beginning of the process in such a way that security is enshrined in the operations and maintenance of the smart devices - and not to build something first, and then, slap on security later as an afterthought.”

“Security-by-design means to design from the beginning of the process in such a way that security is enshrined in the operations and maintenance of the smart devices – and not to build something first, and then, slap on security later as an afterthought.”

Ensuring security-by-design for OTA software updates

How do you instil security-by-design principles throughout your continuous development and iteration processes? Josef discussed three key best practices:

Always start out by expecting the worst to happen: Connected devices and the software that runs on them are prime targets for bad actors. Ensuring secure over-the-air software updates for a device fleet – from the beginning – puts the fleet owner in a better position to handle any scenario, routine or otherwise.

Avoid security by obscurity pitfalls: Don’t rely on homegrown mechanisms to deploy and manage over-the-air software updates. In most cases, homegrown solutions create additional risks, such as internal knowledge gaps (i.e., only a few individuals understand the backend, format, or requirements). Choosing a professional OTA update solution ensures security-by-design is built from the start. Your OTA solution should be both proven in the field and open source. It should also stand up to independent inspection and testing.

Use state of the art encryption and authentication in a meaningful way: Every team should understand the implications and requirements encryption and authentication has not only for the smart device, but also for the manufacturing and provisioning process of that device. The key security considerations for the OTA update process include server authentication, client authentication, software artifact verification, user authentication and verification, hardware security, and countering Denial of Service (DoS / DDoS) attacks.

Learn more about OTA encryption and authentication.

Assessing your OTA software update process

How does your process stand up to today’s security standards? Josef asked the audience just those questions. Answer these five questions to give you an idea of where your OTA software update solution ranks:

Can your hardware handle A/B updates?

Hint: This might be the architecture supporting safe bootloader updates, and it requires enough storage for two instances of the root filesystem. For system level updates, Mender requires a dual A/B rootfs partition layout on the device.

Do you have a managed and monitored build pipeline (CI/CD) that integrates with your OTA updates solution?

Hint: An example from Gunnebo Security Solutions on how to do this correctly using Azure DevOps and Mender in this case.

Do you have a thorough understanding of how the per-device provisioning of credentials should be handled in the manufacturing process?

Hint: Design does not end at the engineering department door. Get your production team around the table when you are planning a new product. Ask the question: how can leaked or duplicated credentials be prevented? What kind of authentication and auditing routines and systems are required? Specifically, look into logging and error reporting mechanisms. They often unintentionally record sensitive information and could be possibly snooped on by unauthorized 3rd parties.

Have you conducted a thorough evaluation and risk assessment of the OTA updates process in the complete context in which your smart devices will operate?

Hint: This means looking into the physical operation of the devices and requirements. On the one end these are the safe states and how will they be checked and enforced? Commonly required preconditions are the device being garaged if it is something mobile, or moving parts being mechanically locked and checked by contact switches. Mender supports arbitrary checks by plugging into state scripts.

A different point of view is the physical operational state of the whole system. What is actually worth securing? A physical tampering detection on the electronic device might be not as useful as intended, if the device is in fact part of a bigger mechanical machine that has no comparable features. Physical security-by-design requires a holistic approach first, and breaking down into single measures later.

Access this essential checklist on deploying OTA software updates to smart devices.

Preparing your smart devices for the future

Designing a smart device is not solely a question of software, hardware, and which checkboxes to tick. It also involves the careful consideration of many different aspects, ranging from hardware assembly, operation, and maintenance to creating, testing, and deploying software to many more devices over multiple years.

Taking the prudent step to integrate a secure and robust OTA update solution early in the design stage ensures that no inherent blockers are accidentally created. This approach creates an opportunity to fine tune the workflow where all the stakeholders in the software deployment are involved.

Read this comprehensive guide to smart device security-by-design.