Cybersecurity best practices to implement highly secured devices

Almost three years ago, we published The Seven Properties of Highly Secured Devices, which introduced a new standard for IoT security and argued, based on an analysis of best-in-class devices, that seven properties must be present on every standalone device that connects to the internet in order to be considered secured. Azure Sphere, now generally available, is Microsoft’s entry into the market: a seven-properties-compliant, end-to-end product offering for building and deploying highly secured IoT devices.

Every connected device should be highly secured, even devices that seem simplistic, like a cactus watering sensor. The seven properties are always required. These details are captured in a new paper titled, Nineteen cybersecurity best practices used to implement the seven properties of highly secured devices in Azure Sphere. It focuses on why the seven properties are always required and describes best practices used to implement Azure Sphere. The paper provides detailed information about the architecture and implementation of Azure Sphere and discusses design decisions and trade-offs. We hope that the new paper can assist organizations and individuals in evaluating the measures used within Azure Sphere to improve the security of IoT devices. Companies may also want to use this paper as a reference, when assessing Azure Sphere or other IoT offerings.  In this blog post, we discuss one issue covered in the paper: why are the 7 properties always required?

Why are the seven properties applicable to every device that connects to the internet?

If an internet-connected device performs a non-critical function, why does it require all seven properties? Put differently, are the seven properties required only when a device might cause harm if it is hacked? Why would you still want to require an advanced CPU, a security subsystem, a hardware root of trust, and a set of services to secure a simple, innocuous device like a cactus water sensor?

Because any device can be the target of a hacker, and any hacked device can be weaponized.

Consider the Mirai botnet, a real-world example of IoT gone wrong. The Mirai botnet involved approximately 150,000 internet-enabled security cameras. The cameras were hacked and turned into a botnet that launched a distributed denial of service (DDoS) attack that took down internet access for a large portion of the eastern United States. For security experts analyzing this hack, the Mirai botnet was distressingly unsophisticated. It was also a relatively small-scale attack, considering that many IoT devices will sell more than 150,000 units.

Adding internet connectivity to a class of device means a single, remote attack can scale to hundreds of thousands or millions of devices. The ability to scale a single exploit to this degree is cause for reflection on the upheaval IoT brings to the marketplace. Once the decision is made to connect a device to the internet, that device has the potential to transform from a single-purpose device to a general-purpose computer capable of launching a DDoS attack against any target in the world. The Mirai botnet is also a demonstration that a manufacturer does not need to sell many devices to create the potential for a “weaponized” device.

IoT security is not only about “safety-critical” deployments. Any deployment of a connected device at scale requires the seven properties. In other words, the function, purpose, and cost of a device should not be the only considerations when deciding whether security is important.

The seven properties do not guarantee that a device will not be hacked. However, they greatly minimize certain classes of threats and make it possible to detect and respond when a hacker gains a toehold in a device ecosystem. If a device doesn’t have all seven, human practices must be implemented to compensate for the missing features. For example, without renewable security, a security incident will require disconnecting devices from the internet and then recalling those devices or dispatching people to manually patch every device that was attacked.

Implementation challenges

Some of the seven properties, such as a hardware-based root of trust and compartmentalization, require certain silicon features. Others, such as defense in-depth, require a certain software architecture as well as silicon features like the hardware-based root of trust. Finally, other properties, including renewable security, certificate-based authentication, and failure reporting, require not only silicon features and certain software architecture choices within the operating system, but also deep integration with cloud services. Piecing these critical pieces of infrastructure together is difficult and prone to errors. Ensuring that a device incorporates these properties could therefore increase its cost.

These challenges led us to believe the seven properties also created an opportunity for security-minded organizations to implement these properties as a platform, which would free device manufacturers to focus on product features, rather than security. Azure Sphere represents such a platform: the seven properties are designed and built into the product from the silicon up.

Best practices for implementing the seven properties

Based on our decades of experience researching and implementing secured products, we identified 19 best practices that were put into place as part of the Azure Sphere product. These best practices provide insight into why Azure Sphere sets such a high standard for security. Read the full paper, Nineteen cybersecurity best practices used to implement the seven properties of highly secured devices in Azure Sphere, for the in-depth discussion of each of these best practices and how they—along with the seven properties themselves—guided our design decisions.

We hope that the discussion of these best practices sheds some additional light on the large number of features the Azure Sphere team implemented to protect IoT devices. We also hope that this provides a new set of questions to consider in evaluating your own IoT solution. Azure Sphere will continue to innovate and build upon this foundation with more features that raise the bar in IoT security.

To read previous blogs on IoT security, visit our blog series:  http://approjects.co.za/?big=en-us/security/blog/iot-security/   Be sure to bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity