AWS (Internet of Things) IoT

Introduction

AWS Internet of Things (IoT) is a set of coordinated AWS services that enable an organization to centrally command and control a fleet of remote computing devices. To give you an example of the possibilities, think of raspberry pi devices embedded in vending machines, internet enabled thermostats monitoring food storage shipping containers, or even remote sensing equipment located deep in the heart of a jungle.

“With great power comes great responsibility,” –Benjamin Parker (Spiderman)

This line from a fictional movie, is an excellent mantra when designing your IoT infrastructure. In 2016 University of Michigan Engineering Professor Kevin Fu testified in front of Congress stating: “Internet of Things security is woefully inadequate”.¹ 

With this responsibility in mind, we’ll cover both how-to take a strong security posture and a practical approach to building for IoT.

Security Posture

In order to understand security, we must understand what we are securing in the first place. Below is a concise dictionary of terms as they relate to AWS IoT:

• Thing: A logical or virtual representation of a remote computing device
• Thing Group: A logical grouping of “Things”
• Thing Type: An arbitrary label definition of remote computing devices. Think “thermostat”, or “kiosk”. These exist as human friendly ways to understand the make, and models of your hardware.
• Component: Software packaged in a particular format with the intent of installing on your device. Examples are company developed applications, or docker containers.
• Deployment: A clear definition of devices (Things) that should contain specific software (Components)
• Job: A system process responsible for ensuring that deployment steps are performed on the appropriate devices.
• Greengrass: The client side AWS provided application that manages connectivity and remote management of the device.

The terms only cover concepts around IoT Core, and Greengrass. For more advanced concepts around analytics, and security monitoring please visit Amazon’s AWS Whitepaper.

“Dead men tell no tales”. This quote, often attributed to pirates of antiquity, is a grim reminder that people are notoriously terrible at keeping secrets. Our technologies, as an extension of ourselves, are just as guilty. With this perspective in mind, sooner or later, one of your security secrets will leak. Regardless of whether the leak’s origin is accidental or malicious, the result is the same: a security compromise, kkio.

While a compromise is unavoidable; you can take solid preventative measures to mitigate the risks.

• Principle of least privilege: IoT devices are shipped with minimal IAM permissions to identify itself as an untrusted device to our infrastructure. This process involves joining a thing group with just enough permissions to connect and await further instructions while our verification process does a background check. Once verification is complete, the device is moved to an appropriate device group amongst other valid devices where it has access to the appropriate components (business related software). Please note all authentication/authorization is handled server-side in real-time. It is best practice to avoid trusting client-side actions for anything related to security.

• Encryption: All data is protected while in transit across networks, and while stored locally on the device, or within Amazon’s infrastructure. Network connections are secured by SSL protocols. Data stored locally is kept to a minimum and resides on encrypted hard drives. Data collected in Amazon’s infrastructure is secured by KMS.
• Resource isolation: In the event that an attacker gains access to an individual device and extracts its authentication certificate, the compromise is limited to that single device. One of the provisioning steps requires every new IoT device to generate its own unique security certificate. Please note that to extract a security certificate requires an attacker to have physical access to the local hardware, and local network. After obtaining that physical access, the attacker would need to defeat the hard drive encryption. While the risk is incredibly low, it is never 0%. For a decent primer on physical security best practices, the US Department of Education has an informative resource available:

Practical Approach

The client-side requirements of an IoT formula refers to devices which have hardware implications. At the time of this writing, a global pandemic, and international war, may render hardware prohibitively expensive, or just outright unavailable. How then could an organization hope to scale up IoT, not just to customers, but internally for development environments? Virtual Machines! The system requirements for Greengrass, the client side software of your IoT device, outline:

1. Windows or Linux
2. ~ 200 MB of memory
3. Minimum 256 MB of hard drive space

Using the most basic of system requirements allows us an opportunity to provision multiple virtual IoT devices on a single physical machine. The next challenge is automating the creation and destruction of these virtual devices to facilitate rapid development, and testing iterations. There are various great solutions out there that address this problem, but we chose Vagrant for its adaptability, and low barrier of entry.

Using Vagrant, we automate the provisioning of both windows and Linux based devices, and quickly test our software against multiple configurations. This has the advantage of shielding application developers from the constant barrages of environment issues and allows them to focus instead on the interesting problems of the day.

Summary

When working on IOT solutions, it is important to take a strong security posture and use a practical approach.

References:

1. https://security.engin.umich.edu/stories/professor-to-congress-internet-of-things-security-is-woefully-inadequate