Everyone knows weak security poses a threat to their business, and the connected devices of IoT present a substantial attack surface for hackers. However, there appears to be a general attitude among organisations of hoping a breach won’t happen to them, and this attitude can see inadequate device-level security incorporated from the solution concept onwards. Although security technology is mature, it can be complicated and costly to design and manage. Organisations have to balance this expense and complexity against the competitive landscape and the ultimate return on investment of their IoT solution.
Typically, it takes a breach or introduction of new regulation for security to become a priority, but it doesn’t have to be like this. By adopting a clear security architecture, organisations can address many of the security basics. They can also outsource many of the management burdens to specialist providers, enabling them to focus on the core business. For many, the goal only needs to be to have better security than other organisations that then present softer, more attractive targets for hackers.
Alon Shamir, the senior director of product management for Pelion Device Management at Arm, and Duncan Jones, a senior product manager with responsibility for chip-to-cloud security at Arm, discuss security with George Malim. In essence, even though security is a never-ending quest, organisations should not lose heart and instead focus on getting a fit-for-purpose security architecture in place, enabling them to layer additional security on to that as the landscape evolves.
George Malim: What does Arm see as the key threats that affect devicelevel security?
Alon Shamir: Any conversation about IoT and security starts with the fact that we are seeing more incidents that drive more businesses to be mindful of cybersecurity and invest more in this area. Cybersecurity is complicated, and while it might be heaven for security geeks, for other people, it’s hell. There’s no silver bullet that can solve security, once-and-for-all, and in every situation. What’s needed is a considered, logical evaluation of threats, matched to a plan that mitigates them.
Attacks come from physical and cyber points of origin, and both come with challenges. One comprises the threats you know about and can, therefore, do preventative work to stop. The other involves the threats you don’t yet know about, and this is where your weak spot lies. These threats need to be detected so that a mitigation strategy can be developed and implemented. A comprehensive approach necessitates both detection and prevention.
An attack from an unknown or untrusted source on your network means the prevention aspect was ineffective, and you then have to rely on detection to stop an attack. There are two methods of detection to rely on. There is the management data from the device, which can reveal the connections you have open, and this presents a straightforward way to know which device has been breached. The second method is to perform network-level prevention, requiring probes to be deployed all across your networks to detect and identify anomalies.
A famous example of where this would have helped is the Las Vegas casino that was hacked from an aquarium fish tank device that was part of the casino’s general network. Proper detection would have identified that the device, which should only communicate with the aquarium service provider, was talking to other casino systems, and this should have triggered an alert, thereby preventing the attack from doing real damage.
Both detection and prevention are essential, but life is not ideal at all times, and you have to adjust to achieve the best security for each use-case, device lifecycle and budget. We do a lot of work on prevention. We have a complete security device lifecycle management strategy, which starts with embedding capabilities into devices at the point of provisioning and continues throughout the entire end-to-end lifecycle.
This in-built prevention capability is so important because, although your devices won’t be 100% safe, attackers tend to find and exploit the most easily accessible vulnerabilities. It’s like the story of two people running away from a lion; one asks the other: “Do you think you can outrun the lion?”
“I don’t have to outrun the lion, I only have to outrun you,” is the reply.
The same is – mostly – true in device security. If you make it difficult for attackers, they tend to move on and find an easier target to attack. For this reason, a priority for us is to deliver a strong foundation of security to our customers, even if they’re not security experts themselves.
GM: How can IoT organisations and their partners ensure device-level security is optimised?
AS: Attackers tend to gravitate to the weakest link, as we saw with the casino aquarium example1, and get in through that. Therefore, you need to be extremely careful about how you onboard devices and manage them remotely. You can have very good cybersecurity, but once a technician needs to access a device, such as an elevator, they typically have full access. In the case of IoT, the device itself isn’t necessarily the target, but the enterprise is. The IoT device is simply how access is gained.
If you can get access through one physical device that is part of the network, the whole network can be exposed. It doesn’t matter if you get in through one device or a thousand different devices.
Duncan Jones: When you hear the news that breaches are still happening, that’s an indication that some people still see security as something that can be omitted or sprinkled on at the last minute. As tedious as some of these processes are, they are necessary. People are still trying to skip too many steps.
I understand this is because organisations are focused on keeping a low bill of materials (BOM) cost for the IoT device and on getting to market quickly. Still, they need to consider the cost of even one breach.
Some people are doing it right. We’re working with customers who choose us because they care about strong security. In addition, there is a difference between devices companies develop themselves – with the necessary security framework – and devices that they may adopt from other sources. We focus on developing devices that are secure in their own right.
This doesn’t necessarily mean you need extra components on the device. Still, a fraction more spend can allow you to strengthen the root-oftrust and, for many use-cases, represents only an incremental additional investment in hardware.
Of course, it’s not just about what components you put in the device. The structural approach that organisations take to establishing and maintaining their device security architecture is essential. We have a security framework – the Platform Security Architecture – something we make freely available to help organisations with this aspect. Even the cheapest chip can take you a long way in security, just so long as the correct logical structure has been applied.
GM: It’s not a one-size-fits-all landscape but what solutions are being brought to market to address device-level security?
AS: I think it’s worth pointing out that there is a disparity between different sectors. The Economist Intelligence Unit, for example, has reported that consumer and retail businesses have suffered the highest-profile breaches but are the least concerned about whether these have diminished interest in IoT. In contrast, energy and natural resources companies are the most interested in security.
DJ: Ultimately, it depends on the quality of the job you want to do. In a perfect world, you would do things rigorously and have a threat model developed that exactly matched your IoT application. Arm’s Platform Security Architecture identifies various examples of threat models and the processes, elements, and techniques recommended to deliver an appropriate level of protection. Our most security-conscious customers take this approach.
Organisations may want to take on the task of developing their defence against the threats that could affect their use-case. However, not everyone wants to do this, and this is where Pelion comes in. People can get many advantages out of just addressing the basics, but if they are in a high-risk industry or face brand damage, they may wish to go further.
GM: Why are we still having the same conversations about security weaknesses at enterprises despite of all the high-profile breaches and brand damage that’s been reported?
DJ: Most of my career has been in security, and you’d imagine that things would gradually get better. But, ultimately, it’s only regulation that causes change. We’ve had cryptography and all the elements in place for years – after all, it’s only maths – yet we still find ourselves with breaches in the news. Often these aren’t caused by malicious actors doing anything especially clever; it’s usually caused because something has been left unencrypted, or a well-known vulnerability left unpatched.
Arm is trying to do as much as we can to support the industry to move in the right direction, but unfortunately, my money is on the situation remaining more-or-less the same for many years to come.
AS: Often, we think of IoT as a market, but actually, it’s a collection of markets. A cheaply manufactured consumer device has cost as the most important consideration, whereas other use-cases and verticals do genuinely prioritise security.
Five years ago, for example, carmakers wouldn’t bother with a secure system-on-a-chip (SoC) design, but now they won’t even talk at all without a secure SoC being available. For the utility, automotive, and other industries, the bar is rising and the conversation about security is being held relatively early. I’ve worked with some of the biggest names in the auto industry, and security was once just an afterthought. Now, that’s not the case, it’s front and centre.
Sometimes it’s regulation that causes this change, but sometimes it’s just a case of an attack or an incident going viral that casts a spotlight on security and results in the market reacting. In automotive, the trigger was the Jeep Cherokee hack that saw hackers take control of the systems of a vehicle driven by a Wired magazine journalist. Things like this mean the conversation evolves.
GM: What are the realities of device-level security? There’s no such thing as complete security, but what comfort level needs to be achieved?
AS: You’re right, and this is where threat modelling helps by juggling the anticipated threats, the required usability, and the desired cost to mitigate. Customers may start by aiming for full security, but when they understand the implications on cost, they may be willing to compromise here and there. Alternatively, there may be implications on the production line with embedding greater security. Also, if your actual production line isn’t secure, you have a black hole, and it can be complicated and costly to address. Some trade-offs are possible and a good security model can balance the three issues.
GM: How can Arm help?
DJ: I think the Arm difference is measured by the value that we add throughout the various stages of the IoT device life cycle. For example, we take care of 70-80% of the fundamental, but mundane, security coding required during the application software development phase; this can have a dramatic impact on your time-to-market. Another example involves ensuring that the chain-of-trust has its foundation in secure, trusted identity, and Pelion establishes this at the very earliest opportunity: in device production. We inject the device with a cryptographic key and a certificate. During activation and onboarding, we use this embedded identity to secure and authenticate communications with both the device management service and the data management platform.
Additionally, the techniques for securely storing and applying over-the-air updates are all managed by the Pelion service; it’s essential to ensure that everything that runs on the device is valid. Typically, when the device’s firmware or the IoT application software are improved, or a patch is needed to fix a bug or a security vulnerability, you need to apply an update. We ensure this process is securely executed, with signed updates, and an anti-rollback control. There’s a surprising amount of device functionality needed to ensure the integrity of the process, and that device availability isn’t compromised due to an update being incorrectly applied.
And finally, something that is overlooked, or at least minimised, is the life-long need to monitor device health. We’ve pioneered a capability to detect and report on anomalies. Collecting specific device operational metrics – for example, CPU and memory utilization – provides insight into how the device is performing relative to accepted baselines. Proactively checking for deviations could be indicative of a software bug that will accelerate battery drain or a cyberattack that’s attempting to establish unauthorised connections.
AS: Pelion provides a security framework that extends across the device’s end-to-end life cycle. Many times, security rules are broken when companies attempt to stitch things together from multiple sources and do that in a way that isn’t secure. We don’t sell the chipsets or the devices; we provide the building blocks to run everything and ensure the secure interoperation of systems and devices.
Security is a topic that continues to roll on. We’ll see spikes of activity when exciting things happen, but most security breaches still go unnoticed. If a carmaker doesn’t need to run and tell of a breach, it won’t. They just quietly address the threat and move on.
Astute organisations find the right balance, so they’re not exposed, and hackers go elsewhere to find a softer target. That’s been the story of security up until now, and it will probably continue that way.
SPONSORED INTERVIEW
via https://www.aiupnow.com
by IoT Now Magazine, Khareem Sudlow
