Chris Hickman | CSO, Keyfactor
It’s no secret that Internet-connected devices need security to protect data – and the device itself – from compromise. However, in many cases, IoT products are not engineered with sufficient security to defend against today’s threats. Other times, hardware manufacturers make mistakes implementing their own security controls, such as the recent incident at Netgear.
In any case, adding network capabilities to embedded devices means we can no longer apply the same security techniques we used in isolated systems. Designing a secure connected product requires considerable thought and planning and there really is no ‘one-size-fits-all’ solution. How security should be implemented draws upon a multitude of factors, including:
- What data is being stored or transmitted between the device and other connected apps?
- Are there regulatory requirements for the device? (i.e. PCI DSS, HIPAA, FDA, etc.)
- What are the hardware or design limitations that will affect security implementation?
- Will the devices be manufactured in-house or in a remote/untrusted facility?
- What is the expected lifespan of the device?
The idea here isn’t to provide a complete guide to secure IoT device design, but rather to get you thinking in terms of security requirements. Here are six simple questions to ask yourself:
6 Key Considerations for Secure IoT Design
01 When does the device get an identity?
If the new California IoT Security Law hasn’t made it clear enough, recent exploits show us that hard-coded passwords or shared keys don’t cut it. Every device requires a unique identity. The next logical question is “when does the device get that identity?”
Some devices are manufactured in-house, others by contractors. Some devices require an identity to initiate connectivity, while others can wait until later in the process. The initial provisioning of identity will be critical to understand in terms of product design and lifecycle management.
02 How will the device authenticate securely?
IoT devices require a unique identity that can be used to authenticate when they attempt to connect to gateways or backend systems. With this unique ID, manufacturers can also ensure trust throughout the product lifecycle, and revoke or replace credentials to mitigate risk.
Let’s assume you are making a device that stores data and then transmits it to a backend server. You’ll need to ensure that every device has been provisioned with unique credentials to verify authenticity to other systems and ensure the integrity of data transmitted from the device.
03 Does data stored on the device need to be encrypted?
Depending on the type of device and regulatory requirements, you may need to encrypt data that is stored on the device. Generally, if the device contains any personally identifiable information (PII), it will need to encrypt data-at-rest. Data encryption can require significant design consideration with respects to the amount of processor and compute power needed on the device. Cryptographic functions also put strain on battery consumption, so it’s important to make these considerations upfront.
04 How will the device establish end-to-end secure communications?
The device will need to establish a secure session with backend systems using sufficient encryption to protect communications. This is typically accomplished with SSL/TLS – already widely used to secure connections between web browsers and servers. However, keep in mind that, just like with encryption of data at rest, encryption of data in transit will also require a certain amount of compute power.
05 How will trust be managed on the device?
One of the often-overlooked elements of security design is how trust is granted to a device and managed throughout its lifecycle. While trust is relatively easy to manage within a trusted manufacturing environment, it is much more difficult once that device leaves the factory floor.
Many devices have a lifespan of months or years and today’s security norms are under constant attack. We can safely assume that what is secure today will be ‘breach-able’ at some point in the future. Being able to manage the root of trust on a device is imperative to making sure it can remain secure.
06 How will software/firmware updates be validated?
Every connected device will need to be updated at some point throughout its lifespan. One of the advantages of IoT devices is that they can receive software/firmware updates over the air (OTA). That said, the ability to only allow authorized updates is critical to ensuring the integrity of the device and code running on it.
Simply put, use secure code signing processes to validate the signature of updates and ensure that only trusted code is executed on the device. Protecting code-signing keys and certificates is equally important to prevent attackers from compromise signing processes to inject malware onto devices.
The Bottom Line – Security Starts at Design
Security does not just happen. It needs to be designed in from day one and maintained until the device is powered down for the last time. Security requirements should be mapped out against the entire lifecycle of the device to ensure that it remains reliable and operational from design to end of life.
Companies that provide strong identity by design will be able to deliver to market faster, differentiate their products, withstand stricter regulatory requirements, and protect their business against costly (and often embarrassing) product recalls.
Where to Begin
Learn how Keyfactor and Thales together enable manufacturers to secure IoT design and zero-trust manufacturing. Watch the IoT World Today webinar live on Tuesday, May 5 @2:00 PM EST or on-demand.