Here’s the sobering reality: across the Internet of Things (IoT), security has been overlooked. An amazing 1.51 billion IoT devices were breached in the first six months of 2021, an increase from 639 million in the same time period in 2020. With the anticipated number of connected devices worldwide predicted to reach 50 billion by 2030 (Statista), there is still a lot that needs to be done to ensure that these devices are protected from attacks.
And this includes ensuring the security of your connected devices and data lives up to the promise you make to your customers. The impact of your devices being compromised is a big one and can often be ignored until it is too late. Consumers and device builders are increasingly aware of the importance of device security, but it can be challenging to know which devices are secure by design and which just haven’t been targeted yet.
For many device builders, security is an afterthought as they prioritize the features of the product or service itself when working towards a minimum viable product. Equally, security can sometimes be considered a necessary but un-exciting piece of the product development – the hoops you have to jump through. It can also be hard and therefore expensive to retro-fit security into an existing product.
Maybe these are some of the reasons we see insecure products released into the market. But it is worth remembering that the risk profile of a security incident is high and the impact can be extremely severe. If the worst was to happen, and a breach or hack occurs, you may well end up suffering company damaging impacts. Because of this high level of risk, the security of your data and device must be foundational, and must be built-in from the start.
Security needs to be considered as a necessary system component within your system architecture.
“Security can come later…”
Before it became a household name, there were a series of security loopholes discovered with the Zoom client implementation across several platforms. Within the AV industry, there was a lot of comment, news articles, and concerns raised around the general security of the Zoom implementation. This, in turn, started to cause the kind of reputational damage that can be so damaging for a growing company.
Zoom’s response to these security concerns was pretty damn impressive. By pivoting to address the issues raised in a timely fashion, it managed to turn a problem into an opportunity – and to excel. Which is no mean feat. One can only imagine the sleepless nights for Zoom execs while these fixes were put in place – and I’m sure they would, in retrospect, have preferred to have had security as a core feature of the initial product, rather than an afterthought.
“A breach will never happen to us”
Several years ago, the connected security cameras from Hikvision were compromised through a weak password implementation and a back door / misuse of a cookie which resulted in devices being compromised. The Department of Homeland Security characterized the vulnerability as “remotely exploitable” with a “low skill level to exploit” – in other words, anyone with a computer and a little know-how could access another camera user’s footage.
Rather than this just being a security incident that was raised and publicized as so many are, actual users were targeted and the security of their devices was exploited. The hypothetical worst-case scenario of actual users and their data being hacked was a reality.
“What’s the cost of an attack?”
Only this year, the well-documented Colonial Pipeline cyber attack took place and ransomware impacted computerized equipment managing the Texas based pipeline (a bit like a connected IoT device). This was only resolved when a 75 Bitcoin ($4.4 million) ransom was paid.
“Okay, so you have me worried…”
These examples are just some of the many security incidents, vulnerabilities, and design mistakes that affect products somewhere in the world every single day. As someone responsible for a connected device, the risk of a security incident should be enough to keep you awake at night. But the important thing is to learn and understand that similar things happen all the time.
Because unless you are aware of the risks as part of your product development, this too could happen to you. So – as an embedded software engineer, a device developer, a chief executive, or a product manager – what should you think about and look for to make sure that your device is one of the secure ones?
1 | Threat models
Firstly, you should start by considering threat models – what are you trying to protect, and who are you trying to protect? On one side, this boils down to protecting against accidental misuse and sloppy implementation (the Hikvision default password for example), through bad actors, rogue employees, untrusted manufacturing partners (the kind of things ISO 270001 helps protect against).
On the other side, it goes all the way through to hypothetical government-sponsored hacking, where silicon chips will be ‘de-capped’ and power supply injection used to read flash contents. The approach that you would consider necessary to protect against accidental misuse is somewhat different to that required to protect against state sponsored hacking.
2 | Rules and regs
The basics of IoT device security can be considered somewhat covered by legislation or certification and standards. For example, the most obvious ‘weak authentication’ – in general, a poor or default password – must be avoided, and is increasingly being included in new IoT legislation around the world (in California, Australia, and more recently, the UK). IoT legislation is attempting to banish the weak / default password approach, but this will still take time to adopt.
Standards – whether specific security standards (ARM PSA or SESIP, for example), or ISO implementations (ISO 27001, say) – can also help with some of the specific issues and people-based risks, putting in processes around which employees have access to which systems and the data within them. Many of these are essentially hoops you need to jump through, but if you can’t jump through the hoop, then your product is not ready for market.
3 | The device itself
Microsoft has laid out one approach to device security in its paper on the seven properties of highly secure devices; here, it discusses seven properties that must be shared by all highly-secure network connected devices:
- Hardware-based root-of-trust
- Small trusted computing base
- Defense in depth
- Compartmentalization
- Certificate-based authentication
- Renewable security
- Failure reporting
This forms a great basis for considering what your device needs to do in order to be secure. It is important to note Microsoft uses a custom silicon part to support these seven properties, but they can be achieved in a variety of ways and should all be considered necessary for IoT devices.
As well as these seven properties, there are some other things to consider for a secure device implementation, including:
- Secure boot
- Secure factory provisioning
Whatever you are thinking your threat model is, it is vital you control and manage the code running on your device. Because if you cannot trust the device is running the code you think it is, then you cannot trust anything.
To this end, a method of secure boot and secure factory provisioning is a must-have in order to trust the device and device code. The combination of these ensures your device is running your code.
If you can’t manufacture it securely, then it certainly isn’t secure. The need to get things ‘up-and-running’ quickly tends to lead to insecure implementations, as the many industrial cases built on Raspberry Pi testify. Raspberry Pi is great to get things moving, but it supports neither secure boot or factory provisioning. Secure-by-design, it is not. “A great hobbyist platform, but not suitable for commercial apps” – as Pen Test Partners told TechCrunch.
“So, what to do about it?”
The challenge can be that once you have committed to an approach, be it hardware or software, then switching or changing your development approach can be seen as both hard and costly. The inertia and the sunk-cost of the development combined with the pressure to get a product out-the-door often means that many developers and devices tend to stick with a relatively insecure approach.
To the end, it is crucial to ask how important a secure device implementation is. Is the approach properly secure? Are we happy with the risk level? What would happen if our devices were compromised? Crucially, it is important to decide whether the cost and risk of in-secure devices is worth it. Don’t be afraid to ask these questions, and to conclude security matters more. The earlier you do this, the better it will be.
And remember: switching to a secure architecture isn’t as hard as it seems.
Jonathan Williams is a Product Manager for IoT and Wireless at Twilio. Having worked in both the semiconductor industry as well as in cloud video communications, he has a focus on building developer friendly platforms that solve real world problems.
