What you’ll learn:
- How to properly use IoT systems to the benefit of your security.
- Why it’s important to plan for your next security threat.
The aim of this article is to challenge some of the conventional thinking around security. It’s clearly a topic that’s on the minds of (hopefully) all embedded engineers these days. So, here goes.
1. The operating system is the right place for security policies.
More specifically, if an operating system is going to be used, this instantiation of the OS should ONLY be used to implement these policies. It should have no access to the internet and immutable, extremely constrained communication with other applications. We have seen from the laptop segment that once an operating system is hacked, all bets are off.
In this world of multiprocessor architectures, the use of a hypervisor to divide up and allocate system resources is a great step. Once that architecture is in place, a range of options are available to you, including the establishment of a specific virtual machine running bare metal code or, yes, a specific operating system.
2. Connected IoT systems are better than those that aren’t.
About seven years ago, a company created a toilet that could be controlled via a wireless USB interface. I used the default password of “0000.” Now, this raises so many questions! Yes, a poor password. But for this point, did the advantages of having a connected toilet outweigh the potential network risks? In the embedded segment, some connectivity is being added to make a system capable of being managed remotely. The recent hack of a water treatment plant in Florida earlier this year represents just one example of IoT hacks causing trouble.
My challenge to you here is to consider whether IoT is the right approach for your application. Yes, it may seem like a question from a luddite, but as soon as an accessible port is placed on a system, it brings a tangible risk.
3. Focus on bolstering the “front door.”
The technology industry has clearly advanced the capabilities of its platforms from a security perspective over the last five years. I would cite examples like Arm’s platform security architecture (PSA) and the Microsoft Azure Sphere program as two examples. The system architect can’t assume that their problems are solved through the adoption of such technologies, though.
The primary consideration is that you have to worry about the weakest link in the chain. If I use a 2021 analogy, just because COVID vaccination rates are rising, it doesn’t mean that mingling with people without wearing a mask is prudent.
4. The bar for security is fixed.
Security isn’t a static thing. The sophistication of attacks is perpetually evolving. Using the wall analogy, deployed systems must continue to add extra layers of bricks to the wall. This means the systems must be able to securely receive software updates.
5. Planning to be compromised is a waste of time.
I’ve seen engineering teams put a lot of focus on reducing the probability of systems being hacked. That’s an extremely valuable initiative. Security should be the first consideration for all companies when designing a new system.
That said, the reality is that IoT systems can be deployed for five, 10, or 20 years. Some smart-meter specifications are pushing for end of life to be determined by the degradation of the housings as opposed to electronic failure. Over a 20-year deployment period, the chances rise that some sort of illegal access will be made.
The key is for the system to recognize that intrusion quickly. Once a system is compromised, it will take some time for the hacker to identify useful resources; thus, the time window from access to recognition must be a main consideration. We’ve seen IT systems in which a hacker has taken several months before the access is recognized.
More time needs to be spent on intrusion detection techniques. This is one area in which I’m particularly excited about the potential of artificial intelligence, since a pattern of normal system behavior can be created and abnormalities be identified.
6. Development should focus on the deployment for the intended use case.
In the United Kingdom where I hail from, a TV commercial during the holiday period reminds people that “a dog is for life, not just for Christmas.” Puppies are a popular gift, yet some families start to tire of them in the New Year and the shelters become filled.
For deployed systems, companies concentrate on getting systems deployed and gathering/communicating their data. As mentioned previously, these systems are active for a long period of time. Have you designed your system to cope with changes through that period of time?
Of particular focus for me is the General Data Protection Regulation (GDPR) in Europe. Is your system able to be GDPR-compliant if a new company takes over ownership of a smart lighting network (i.e., can you guarantee that information gathered by owner A will not automatically be shared with owner B?). When that system is eventually retired, can you guarantee that all valuable data will be obliterated?
7. All hackers are bad.
Almost all engineers I’ve met over my 35 years in the industry have been standup citizens. What I advocate here is that a person be added to the engineering team very early on with the sole purpose of plotting how the system can be hacked. This “white hat” hacker needs to be challenging the team to shore up the holes identified in the system so that the product is as penetration-proof as possible, both at shipment time and throughout the useful lifecycle of the product. What I see too often is a set of cozy engineers defining a platform and then handing the product off later in the process for penetration testing. It’s prudent to disrupt this flow.
8. Time-to-market is king.
All companies are challenged to reign in development cycles. I will argue that this should not be permitted if security is compromised (or indeed unknown). To modify the well-known phrase, “deploy in haste, repent at leisure.”
9. It’s just about your data.
While at Arm, our CTO at the time had a particular fascination with connected toasters. As we started to discuss security breaches, my mind initially dismissed it as I thought “how bad can it be if the toast gets burnt?” The Mirai attack in late 2016 completely changed my thinking.
DVRs (not toasters!) were hijacked and reconfigured to send out internet traffic to a set of content servers on the East Coast of the U.S., causing services such as Netflix and Spotify to crash. System architects need to ensure that their new creation is not only able to protect its own valuable data, but that its functionality can’t be adjusted for dishonorable purposes.
10. A big padlock on the front door is enough.
One of the best analogies I heard about IoT security was when Microsoft launched its Azure Sphere program. Rather than suggesting to lock the front door of the house when leaving, their analogy for IoT was that one should lock every room in the house. Thereby, if someone broke in, there would be access to a reduced set of assets. For the system architect, this means compartmentalizing your design. Break it apart to ensure that either accidental or malicious attacks (or indeed hardware failures) don’t result in catastrophic failure of the system
11. Your only option is to test the physical device.
One of the most overused technology phrases in the last year has been “digital twin.” A digital representation of systems can be used to perform a significantly more rigorous and varied set of penetration tests using the power of the cloud.