Whether you are managing a fleet of soda vending machines or electric vehicle charging stations, the devices in a connected system offer a unique set of challenges to anyone tasked with keeping them secure because they are:
- In active service for extended periods of time and must work reliably .
- Often unattended and geographically dispersed, complicating remote software updates
- Vulnerable to physical tampering, both curious and malicious
- A potentially weak point for attackers to obtain access to corporate networks
To stay on top of these challenges, you must make a series of important security choices throughout the life cycle of a connected system, starting with the design phase.
Assessing risk
One of the most effective ways to identify potential threats is the practice of threat modelling, which should start very early in the product development lifecycle and continue throughout. This process typically involves creating a model of the system, finding the threats, ranking and addressing these threats, and validating the work.
It helps to apply a process when looking for threats, whether they are external from a deliberate hack or internal from a disgruntled employee. There are several ways to do this—one well-regarded approach is Microsoft’s STRIDE framework:
Spoofing | Pretending to be someone else |
Tampering | Unapproved modifications |
Repudiation | Denying certain actions |
Information Disclosure | Exposing information to someone not authorized to see it |
Denial of Service | Attacks designed to prevent a system from providing service |
Elevation of Privilege | A user can do things that they are not supposed to |
To use this model, create a high-level diagram of the software system showing data flows and stores, and boundaries of who controls what (network boundaries, different physical computers or virtual machines, accounts, organizations, etc.). Then work through this diagram considering each part for all the STRIDE threats. A gaming approach like Elevation of Privilege might work well for your team and can be fun.
This will create a list of threats that should be ranked and prioritized. Once your threat profile is complete and you know what your main risks are, there are several critical design decisions to take to strengthen the security of your connected system.
Hardware
When a device registers and connects to the system, you need to identify and authenticate it. Ideally, these steps are based in hardware, making it more difficult to duplicate a device or change the identity of an existing one. Many modern computer hardware systems have a trusted platform module (TPM), a chip that can provide additional hardware-based security by protecting access keys and other confidential information during a physical attack, for example, or by providing the encryption key to unlock a device when there is no trusted human present to interact.
Operating system
Several factors, both technical and commercial, influence the choice of operating system (OS) for embedded devices.
- License model: An open-source OS reduces license costs, but you should be sure to comply with the terms of the type you have chosen.
- Footprint: An OS can range from a few hundred megabytes to several gigabytes, and the size of the OS image affects the time taken to deploy and update, as well as the storage costs.
- Security: OS differ in the support they provide for integrated security mechanisms.
- Safety: Not all OS may be used for medical devices or where there is a danger of harm.
- Application development: Open-source solutions often have a wider choice but can have a more fragmented development environment than a commercial OS such as Windows.
- Support (immediate & long-term): How long will an OS be supported with security updates? What is the strategy for upgrading to the next major version of an OS when the time comes?
Making updates
A vital component of system security for any connected device is an over-the-air update mechanism. Malware attacks rely on the fact that software is often run without the latest security patches. It is important to make sure all third-party software is being updated in a timely manner, and to monitor lists of known vulnerabilities and patches for open-source software. This seems simple, but in a distributed fleet of single-purpose devices it can be challenging to keep software updated while ensuring that the device functionality and availability remain unaffected.
Cloud connectivity and robustness
Depending upon the environment and the type of network connection, your kiosk or energy meter may experience power outages or periods of limited or no connectivity. Your system design must accommodate this and ensure that data is stored and retransmitted, and that it continues to operate as normal. MQTT, a lightweight messaging protocol designed for low bandwidth environments, has become the de-facto standard for connecting embedded devices to the cloud, and the main cloud vendors all support it.
Interoperability
It is much easier to update the system to new components or adapt for a different use during a system’s lifetime if you avoid proprietary protocols. Often additional benefits or uses become apparent during the development and initial use of a new system, and it is easier to make changes and additions if standard protocols are used in the design.
In today’s connected world, we are seeing an astonishing number of single-purpose devices linked with each other to create systems essential to business operations, and that introduces a host of vulnerabilities. Designers of everything from heart monitors and imaging machines to self-service kiosks for restaurants and hotels must anticipate issues across the lifecycle of these devices to ensure they remain in service.
Bsquare will continue to share our insights on security in a connected world.