Written by Kriss Andsten, Cloud System Architect
I have a love / hate relationship with EU regulations; thankfully, it goes along swimmingly with my love / hate relationship with software – and don’t get me started on hardware. Any developer who claims they haven’t at one point in their life considered getting into potato farming instead of writing code is probably lying.
That said, the love part is quite enough to keep me off the potato field. Take for instance the GDPR; it’s not perfect, but I can really appreciate how a privacy legislation carried noticeable impact on business ethics merely by requiring companies to be upfront about what they’re doing with personal data and to consider the implications thereof. Once the discussion shifts from “Should we leave money on the table?” to “Should we break the law?”, even the most entrepreneurial of spirits gain an incentive to avoid the grey areas. This sets a tone.
Cyber Resilience Act (CRA)
I have high hopes that the upcoming Cyber Resilience Act (henceforth CRA) – affecting any software or hardware/software combo product sold in the EU – does something similar for software hygiene. The problem statement in this area is in many way similar to the one we saw for privacy pre-GDPR; products aren’t necessarily designed with security in mind, since security (at least in non regulated sectors) is a secondary factor at best.
The risk of someone finding out that you’re still shipping an end of life’d and unsupported piece of code in your product is slim, the risk of that being seen as a dealbreaker, even less so – so should you really spend time refactoring the code when the alternative is a new feature? Can you defend a decision to do so? Is it really in the shareholders’ best interest? Grey areas without clear answers.
Post CRA, if you know your product is vulnerable, fix your product. Full stop. Design with security in mind. Fix vulnerabilities. Be reasonably transparent. Again, this sets a tone.
From 2024 to 2027…
For a few years, it’ll be a bit of a standards salad with a fair amount of overlap
Ironically, that’s also the segue to the hate part. Said CRA is expected to go into effect in 2027. Between early 2024 and that date, we’ll also have the NIS2 directive, the Radio Equipment Directive (or RED), the GPSR, the AI Act and the Machinery Regulation playing out, all mandating some variation of an adequate and risk based approach for cyber security. For a few years, it’ll be a bit of a standards salad with a fair amount of overlap and ever so slightly different regulatory requirements depending on the date until the CRA (hopefully) wraps it all together nicely under one cyber security regulation.
For a manufacturer that makes connected (RED scope) machinery (Machinery Regulation scope) for a sector of high criticality (NIS2 scope) – say, transportation – they’ll have to spend cycles considering that overlap. Harmonised standards for RED and the Machinery Regulation are not yet finalised, so it’s practically speaking a moving target that’ll need to be kept track of for the next few years.
Luckily for us, there are also commonalities. All regulations – directly or indirectly – require those in scope to manage their software supply chain, preferably starting some time before the respective regulations come into play.
Our take at Ekkono…
Ekkono – as a part of said software supply chain – is in a fairly good spot from the get-go. Our software is designed for embedded, our footprint is small and the vast majority of our code is just that – our code. Any vulnerabilities, bugs and quality issues are of our own doing – but on the flip side, we don’t have a deep software supply chain of our own to vouch for as a part of our products. For a smaller company, this is much preferable to vouching for the security of millions of lines of other people’s code in the devices of our customers.
Not that we can avoid the code of others entirely; for our Synthesis product – combining insights from a fleet of devices rather than having devices learn in isolation – we’re more of a traditional web application. This invariably means a supply chain to consider, the complexity of managing it well and overall designing in a defensive manner. Known your risks, add layers of defences, test, and test again. Get the basics right. Thankfully, there’s a lot of good practice out there to lean on, including standards.
Thus, our way of aiding our customers in meeting their cyber security obligations – both in this interim period and post-CRA – is to:
- Maintain high software quality, ramping up additional development security process
- Meet and exceed transparency, documentation and communication requirements early; we want our customers to understand the security considerations, the threats and to have an SBOM
Since we’re a part of the industrial space, we’re modeling our CSMS (or Cyber Security Management System) on the IEC 62443-4-1 standard, coupled with ISO 27001 for general cyber security hygiene.
Those familiar with the standards will realize that this is a tall order for a small company; they’d be quite right – it will involve some long hours and deep discussions.
But, as we’ve established, sometimes it’s all about setting a tone. This is no exception.
