Image of closeup green eye

Five Best Practices For Developing Secure IoT Solutions

Padraig Scully shares exclusive insights from the latest IoT Analytics whitepaper on best practices in IoT security.

Padraig Scully, vice president of market research for analyst firm IoT Analytics GmbH, shares exclusive insights from the latest IoT Analytics whitepaper on best practices in IoT security:

Security is often an afterthought when developing IoT solutions. Security features are commonly cut from initial designs to accommodate additional device functionality. However, security needs to play a central role in IoT projects if we are to secure the Internet of Things.

The process of developing secure IoT solutions was recently analyzed as part of an industry white paper published by IoT Analytics with the title “Guide to IoT solution development”. In the paper, the analysts discuss the IoT Solution development process across 5 major phases: 1. Business case, 2. Build vs. Buy Decision, 3. Proof of Concept, 4. Piloting, and 5. Commercial Deployment.

According to the paper, discussions with IoT experts revealed the following 5 best practices to develop secure IoT solutions:

1. Use a security threats model to assess the attack surface

Security can’t be done by the device or cloud alone. Rather, both must work together and with each component of the solution to reduce the overall attack surface area and keep the weakest link to a minimum. It is important to realize that one weak link can open up your whole system (e.g., hackers have gained access to entire company networks by simply entering the default device password for an IoT connected surveillance camera).

Combining hardware and software solutions (i.e., cyber physical) that go from device to cloud and cover everything in between will enable more seamless security in IoT. OEMs /ODMs /device manufacturers need to understand that threats can come from a number of different areas and may be unknown initially; the STRIDE model outlines six possible threats to IoT.

STRIDE MODEL Example
Spoofing identity Attacker uses another user/device's credentials to access the system
Tampering Attacker replaces software running on the device with malware
Repudiation Attacker changes authoring info of malicious actions to log wrong data to log files
Information disclosure Attacker exposes sensitive information to unauthorized partners
Denial of service Attacker floods device with unsolicited traffic, rendering it inoperable
Elevation of privilege Attacker forces the device to do more actions than it is privileged to do

2. Implement security by design

Security-by-design is a fresh approach that entails security experts, architects and engineers from each layer getting involved in full architecture design of an IoT solution right from the outset and to create a security development lifecycle (SDL).

As outlined in IoT Analytics’ 2016 IoT platforms market report, thinking about security across the product lifecycle helps IoT developers build more secure software and address important security compliance requirements. Another innovation related to security-by-design is the involvement of an “attacker” performing penetration testing to assess the system and look for vulnerabilities in the product development process.

3. Force yourself to think security from end-to-end

IoT demands end-to-end security solutions that traverse the layers. A Senior Product Manager at a leading IoT cloud platform says “IoT Security must be consistent across the device OS, network, cloud and application.” Unfortunately, not all IoT systems are thought out from end-to-end. For example, in many cases identity verification is only available on the device level.

However, if a hacker jailbreaked the device he/she could remove software restrictions imposed by the OS and permit root access to the file system allowing them to install untrusted applications on the device. In case of such a hardware compromise the other layers should also confirm authentication of device and user identity e.g., the cloud should know which device is compromised and restrict access to the network.

4. Do not minimize security features to get the MVP out quickly

Companies developing IoT solutions often want to get to market quickly and overlook the importance of building crucial security features into their minimum viable product (MVP) or even beyond. In many cases, it is up to the solution providers to make the customer aware of threats and push for security.

However, with 360+ competing providers in the market today the competition is fierce and for companies the temptation to rush to market without the highest security level is unfortunately a reality.

5. Design the system using proven industry best practices

The white paper outlines some best-practices of engineers building secure IoT Solutions including:

  • Employing hardware-based security such as TPM 2.0 to offer an additional root-of-trust.
  • Using unique identity keys associated with the device (flashed into the hardware trust module or using manufacturer IDs e.g., Intel EPID).
  • Shielding devices behind a gateway or firewall.
  • Enabling user-selected device IDs verified across the stack e.g., on OS, Edge gateway, Cloud.
  • Employing secure boot processes for malware resistance (e.g., only run secure signed images).
  • Using a cross-stack standards-based security approach, thereby making it easy to adopt, easy to adapt (with the standard) and easy to justify to the stakeholders.
  • Auditing and monitoring events and potential breaches in real-time, employing security analytics.
     

It is worth noting, if the hardware is designed with vulnerability the end-to-end solution may still be compromised. Thus, it is important to not only look at the software security aspects but also the hardware aspects e.g., root-of-trust chip security, board-level protection and anti-tamper measures.

For more details on developing secure IoT solutions as well as other best practices for OEMs, ODMs, and device manufacturers check out the IoT Analytics’ “Guide to IoT solution development” white paper which is available for download free of charge.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish