Business have been rushing to take advantage of the Internet of Things (IoT) for some years now. The early IoT has been a ‘gold rush’, with entrepreneurs jumping in to secure their share of an exciting and rapidly growing market – one that is expected to reach $933.62 billion by 2025 according to findings by Grand View Research. The opportunity is huge – but so is the risk.
In this gold rush, and the race to realise the market’s potential, many companies have been deprioritising security. Marry this with a new security breach being reported almost every week, and we have a problem. The biggest security flaw we’re seeing is a result of code being exposed to the internet but where are the threats coming from, and how do those at the coalface, developers, react?
The growing threat
The past year has demonstrated for many that while software updates have not become substantially easier for end users to manage, the frequency and impact of security vulnerabilities make the process unavoidably necessary. It is no longer acceptable to consider any connected software a finished product. Software maintenance must stretch to cover the lifetime of the product.
This realisation was made more prominent by the likes of Spectre and Meltdown – a huge wake-up call for the industry. It didn’t matter what you were doing, it was coming for you. As robotics and edge computing bring more devices online, the threat becomes more widespread.
In 2017 Canonical carried out research with IoT professionals, which showed that over two thirds of respondents felt that a lack of agreed industry security standards worried them when it came to IoT. Further compounding this issue, nearly a third of respondents claim they are struggling to hire the right talent when it comes to IoT security. So the problem exists, has widespread awareness, but without the right skills, businesses are relying on their developers to ensure that their software is robust.
The liable developer
Developers can trade the evolution and growth of their software for a sense of safety by treating their code as immutable. It ships and is never updated. Developers are being driven to this approach taken by many device makers who view clogged support lines as being much more inconvenient than facing down a security breach.
Alongside this, the surface area of software is increasing. The industry continues creating ever more software components to plug together and layer solutions on. Not only does the developer face the update question for their own code, they must trust all developers facing that same decision in all the code beneath their own.
Expectations are expanding, and so are responsibilities. Developers are no longer just makers, they now bear the risk of breaking robotic arms with their code, or bringing down MRI machines with a patch. As an industry we acknowledge this problem – you can potentially have a bad update and software isn’t an exact science – but we then ask these developers to roll the dice.
How then can developers under these pressures deliver on the promises of their software with predictable costs? The answer this could be wide-ranging, but some of the solutions may just lie in snaps.
Extending the security arsenal
Snapcraft (https://snapcraft.io) is a platform for publishing applications (snaps) to an audience of millions of Linux systems and connected devices. Because snaps bundle their runtime dependencies, they work without modification on all major Linux distributions. They are tamper-proof and confined. A snap cannot modify or be modified by another snapped application and any access to the system beyond its confinement must be explicitly granted.
Snap packages use the same underlying security mechanisms as containers. They’re confined from the OS and other apps, but can exchange content and functions with other apps according to policies controlled by the administrator and the remote Snap Store.
Administrators have fine-grained control over what resources snapped applications have access to. Video cameras, microphones, network traffic, and an ever-increasing range of peripherals and subsystems can be plugged into snaps or removed. Snapped applications cannot peer into the storage of other snaps nor by default see into the system storage.
The confidence to build
The difference between a real threat and a hypothetical one is not that different. You essentially have to ‘build for failure’, assuming that something ‘cannot go wrong’ will cost you the most when it does because you don’t have a plan.
This is the approach taken by snaps. Instead of treating software updates as a risky operation and only employing them in the rarest circumstances, snaps acknowledge that updates will fail. When they do, the snap rolls back to the last working version all without the end user experience being compromised. The developer can then investigate without time pressure.
Developers are at the core of everything innovative being done within technology today. But as software-first companies are launching all the time, placing untold pressure onto these teams, there needs to be a compromise – and it shouldn’t be in security. We’ve seen in the past year the kind of damage that cyber-attacks can cause, the stakes are too high to ignore the capabilities that the likes of snaps can offer. By following this lead, developers will have the time, but crucially the confidence, to continue building great things.
About the Author
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.
