Securing the Things – Micro Control Units
Securing the Things
As threat levels increase it is no longer about Securing the Data, more Securing the Things.
Traditionally the Data was the domain of the IT manager, their technology partners and the associated security services. The service is covered by best practice, ISO and Pentest programs and should have board level representation.
But the Things are diverse in functionality, geography, ownership and supporting skill levels.
‘An Organisation’s inability to prove they are In Compliance, means they are Out of Compliance and all that entails
The Things now need to be connected and produce more meaningful compliance data.
In response, new Things offer richer functionality and orchestration, whilst deployed Things require Digital Transformation.
But Things are siloed creatures. Their procurement and subsequent operations are protected enclaves, isolated from IT Data operations and traditionally serviced by ‘the-man-in-the-van’
Does your organisation have a compliance policy for new Things or a seamless Security policy for the whole estate?
At AnotherPeak we now have several Proof of Concept labs built around Edge Computing with Intelligent Asset Tracking and Computer Vision forming the pillars.
Over the next few blogs we will discuss Tiny Edge and Computer Vision but today I wanted to focus on a relatively untapped but very vulnerable Thing namely the Micro Control Unit(MCUs).
Micro Control Units
We live in a world surrounded by MCUs, servicing everything from Water Treatment Plants to Traffic lights.
Critical time-dependant devices require uniform response times hence the use of RTOS as opposed to say a Linux operating system. Yet this creates monolithic firmware stacks and associated operator reluctance to upgrade(fear factor).
But recent high profile hacks have focused attention on MCUs because once hacked always hacked.
Do you rip and replace millions of MCUs, wait for the next breach then rip and replace again?
We’ve worked on smarter Tiny Edge platforms but in many cases installing more powerful compute runs into potential power draw issues especially in remote environments.
Therefore If I can augment the MCU processor with a secure front end enabling both firmware upgrades and additional compliance functionality I could unleash the full computational capacity of that installed base, and bring the security in line with IT department expectations.
Great. So with our experience in micro-services why not use containers? The initial answer was no. MCUs run monolithic firmware to achieve consistent real time results, unlike say an interrupt driven Linux operating system.
Think of Nubix as the AWS for MCUs, the ability to securely build, deploy and manage additional code on you existing MCU estate…..or embed in your new devices.
The first obvious benefit is firmware updates of the existing stack, using the nubix engine.
The second comes back to Compliance. Compliance is documentation, but the documentation of pertinent data.
If the current MCU comms cannot handle additional data rates then you rip and replace right?
No. Using a Nubix model download the appropriate analysis engine to your MCU which only forwards the pertinent data, trashing the rest.
The overall Nubix operation is via a simple Portal, and we are looking at integration into our existing Intelligent Asset Management solution set. Now your MCU estate is part of a wider, policy based edge/core visibility platform with the associated analytical and reporting tools in private or public cloud deployments.
Our challenge is to better understand ‘who we sell to’, but the sooner we do, the less likely it is that all your traffic lights turn green or your tap water tastes of too much chlorine or worse.
Chris @ Anotherpeak.tech