The launch of Memfault’s IoT compliance toolkit recently demonstrated how embedded software companies like Memfault are responding to challenges businesses are navigating in ensuring their compliance to cybersecurity regulations including the Cyber Resilience Act and NIS2 Directive. To get at the heart of this, Editor Caitlin Gittins spoke to Chris Coleman, Co-Founder and CTO at Memfault.
The growth in the connectedness of devices and the complexity has widened the attack surface, and in doing so, has led to a greater focus on cybersecurity and understanding of the risks.
“For a long time [the] devices developed were [designed to] turn a stove on and off, or an application put in a factory somewhere, and there was no data being sent back to the Internet,” said Coleman. “Increasingly, more devices have become connected in the last five to 10 years … Security always falls into that bucket where it can become an afterthought.”
With security having been an afterthought previously, what triggered this change in focus?
“There are a couple of factors there,” said Coleman. “One, if we look at the hardware itself, a lot of companies today aren’t providing just the hardware but the software stack and the Cloud services that sit on top of that. If you’re an organisation that is responsible for Cloud services and software, you’re going to have a security posture and stance.”
Another factor, Coleman explained, can be attributed to a push from governments towards standardisation and regulation. “Some of these regulatory aspects [are] saying, we have to set a baseline practice for making sure these devices that are getting deployed in hospitals, factories and people’s homes have a baseline of compliance.”
Outlining cybersecurity requirements
In a simple sense, regulations such as the CRA and NIS2 Directive outline requirements for companies to follow to create secure devices and hardware and ensure their compliance.
Coleman said that his past experience working with companies creating connected products have indicated an approach that can be best characterised by designing hardware to be perfect, not have issues and therefore not required to be updated out in the field – a scenario that is, ultimately, unrealistic.
“I can see how that could have been the case some time ago, when the stack was much simpler,” remarked Coleman. “But if you’re looking at a device that’s connected over Wi-Fi, or cellular … I can guarantee you the thousands of devices you’re connecting to … have vulnerabilities in there.”
The CRA requires companies to update their software to make sure that if there are any vulnerabilities that are detected, it can’t be exploited.
“It calls out for understanding,” said Coleman. “CRA calls out to be able to understand whether you’re seeing anomalous behaviour in your fleet, or problems out there in the field.”
One area of cybersecurity regulation that Coleman said that may need work is the ambiguity around what companies have to do to be compliant, as well as establishing the main differences between following the CRA, the NIS2 Directive – even the US Cyber Trust Mark, which is, importantly, a voluntary labelling scheme.
“That’s where we see [an] opportunity to help folks on providing the infrastructure and tooling to allow them to do over-the-air updates, or track the assets that are running on their device.”
IoT compliance toolkit
On the tooling in question, Memfault recently released an IoT compliance toolkit which provides its customers with access to technology that can support them with ensuring compliance to these regulations, with features including vulnerability detection, to identify anomalies; device and software inventory; issuing vulnerability fixes and compliant data collection.
The notable points about the toolkit is that it enables the user to keep track of the version of software running on the device, as the CRA requires tracking a software bill of materials; it enhances OTA update capabilities; and it enables monitoring or detecting any potential security holes.
“If you think about an embedded device, it’s running your code, third party libraries, code for network stacks,” explained Coleman, outlining the complexity. “When people are looking at these stacks and there are vulnerabilities or problems that are detected … One of the questions that you want to be able to answer when something like that pops up is: am I impacted too? Is there something I need to fix? Did I already fix this issue?”
By keeping track of the version of the software running on the device, the user can then understand the impact of any problems or issues that pop up in the stack.
“Any time there’s a security bug or hole published one [common] question is, has this been exploited? If it has, how many of these devices have been exploited? Companies can take action by proactively reaching out to folks and saying, ‘We need to close this gap right away’, or seeing what’s there.”
Coleman’s key takeaways were to be mindful of the regulation: “If you’re not talking about it now you should, because they’re coming into effect. Typical hardware programmes take 18 to 24 months to get something out there.
“Looking at when these policies are going live over the next year or two, the time is now.”
There’s plenty of other editorial on our sister site, Electronic Specifier! Or you can always join in the conversation by commenting below or visiting our LinkedIn page.
