Security Best Practices

This is the final step of the ‘exploring IoT security considerations’ activity.

Securing an IoT infrastructure requires a rigorous security-in-depth strategy. This strategy requires you to secure data in the cloud, protect data integrity while in transit over the public internet, and securely provision devices. Each layer builds greater security assurance in the overall infrastructure. Let’s take a look.

This security-in-depth strategy can be developed and executed with active participation of various players involved with the manufacturing, development, and deployment of IoT devices and infrastructure. Take a look at the high-level description of these players.

• IoT hardware manufacturer/integrator: These players are typically the manufacturers of IoT hardware being deployed, integrators assembling hardware from various manufacturers, or suppliers providing hardware for an IoT deployment manufactured or integrated by other suppliers.
• IoT solution developer: The development of an IoT solution is typically done by a solution developer. This developer may be part of an in-house team or a system integrator (SI) specialising in this activity. The IoT solution developer can develop various components of the IoT solution from scratch, integrate various off-the-shelf or open-source components, or adopt solution accelerators with minor adaptation.
• IoT solution deployer: After an IoT solution is developed, it needs to be deployed in the field. This process involves deployment of hardware, interconnection of devices, and deployment of solutions in hardware devices or the cloud.
• IoT solution operator: After the IoT solution is deployed, it requires long-term operations, monitoring, upgrades, and maintenance. These tasks can be done by an in-house team that comprises information technology specialists, hardware operations and maintenance teams, and domain specialists who monitor the correct behaviour of overall IoT infrastructure.

See Microsoft’s document on IoT best practices for more detail on each of these.

Areas of Focus

In this activity, we’ve categorised security considerations into three main areas: devices, communication, and cloud services. The IEEE focuses their best practices guidance on two areas: securing devices and securing networks. As a standards body, this makes sense since they wouldn’t focus on specific technologies but on high-level categories. Much of the guidance here amplifies what we’ve already seen in this activity, but we’ll briefly cover some of the salient points for easy reference and to provide a wrap-up summary for the activity.

Securing Devices

1. Make hardware tamper-resistant:

   This guidance focuses on ensuring the physical device is secure. Since devices exist in the public domain and can be vulnerable to manipulation, protecting the device is critical for ensuring a safe IoT deployment. Specifically, the IEEE recommends:

   • Using tamper-resistant packaging when transporting devices to ensure the device is not manipulated during transit.
   • Using small plastic containers with a lock to keep ports and apertures from casual manipulation.
   • Using port locks, a small device that keeps the physical network port on a device from being manipulated.
   • Setting the device so it automatically disables if certain types of tampering occur.
   • Using strong boot-level passwords on the device itself or requiring the device to boot from local storage.
   • Closing unused TCP/UDP and serial ports.
   • Disabling open password prompts.

2. Provide for firmware updates/patches:

   As the title implies, IoT architects must ensure that devices are easily patchable and updatable when vulnerabilities are found. This becomes more challenging when you consider that hardware vendors may have little incentive (legal and financial) to keep devices up-to-date. It’s up to the IoT architect to ensure that solid relationships exist with device manufacturers, that there are agreements to keep devices updated with the latest firmware, and that vulnerabilities are patched as soon as possible after discovery.

3. Perform dynamic testing.

4. Specify procedures to protect data on device disposal:

   This may be an afterthought to IoT architects but the reality is that devices do fail and most have an end-of-life date when it becomes unfeasible to update, repair, or maintain the device. Ensuring that the device contains no onboard data, passwords, or other information that could compromise security when the device is discarded is an important part of an overall security plan.

Securing Networks

1. Use strong authentication:

   While it may seem obvious, ensuring network resources don’t use simple passwords, duplicate credentials, or include back doors are fundamentals of a secure system. According to the IEEE:

   ‘Each device should have a unique default username/password, perhaps printed on its casing, and preferably resettable by the user. Passwords should be sophisticated enough to resist educated guessing and so-called brute force methods.

   Using multifactor authentication where possible is also highly recommended. Cloud IoT platforms such as Azure help IoT engineers easily manage this as we’ve seen in previous topics. For more information on multifactor authentication and how it works, see the following:

   • Azure MFA documentation
   • Multifactor authentication.

2. Use strong encryption and secure protocols:

   There’s no substitute for using encrypted communication over secure protocols when building an IoT solution. As with device patching, the ability of a device or network to use encryption and communicate over a particular protocol may be a function of the device or network itself so architects have to ensure up front that the components they’re working with will support the type of security they desire. Committing to a particular device family or cloud solution and learning only after commitments have been made that the component doesn’t meet the required security level can have monetary and scheduling consequences.

3. Minimise device bandwidth:

   IEEE’s guidance on this area that focuses on reducing the attack surface area is a subject we touched on in the topic of threat modelling.

4. Divide networks into segments:

   We’ve seen this guidance repeated often in other material. By using network zones architects can provide more localised firewalls, security gates, and secure interfaces to ensure attacks can be stopped before compromising an entire system. Whilst segmentation can make management more complex, it can reduce the attack surface area by restricting access to other segments of the system if a single segment becomes compromised. The Azure IoT framework provides tools for working with network segments, making management easier for engineers.

Security should be a primary consideration when developing an IoT solution. Thankfully, IoT services offered through Azure are built with security which makes building secure systems easier.

You’ve reached the end of your learning activities for Week 2. Next, you’ll complete a poll before we wrap up Week 2 and move onto Week 3.