EU Cyber Resilience Act

[pacive (Anders Alfredsson)]

A few months ago, EU finally finalized the Cyber Resilience Act (CRA) which aims to put essential security requirements on all “products with digital elements” in order to increase security for both consumers and businesses. There are special rules for free open source software to not burden them with compliance, but there are some light requirements on “open-source software stewards”, which is defined as

“a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products”

I’m not sure the if the openHAB foundation qualifies for this, since the Eclipse license allows for commercial use, but OH is not “intended” for it.

This is not, however, the issue I wish to address. I know from this forum, however, that there are several people who use OH for commercial purposes, and they will be considered as manufacturers according to the regulation and need to comply with all the requirements. Personally, i don’t wish for them to be individually responsible for all those requirements, which for some might be overwhelming and lead to discontinuation of their business ventures.

Instead I hope that we as a community can collaborate on some of the the requirements, to ease the burden on these individuals allowing them and others to continue their businesses. I work as a cybersecurity consultant myself, and have read up on the legislation quite a bit since it affect many of our customers. There are several things I can see that we as a community could contribute with to enable people to use OH in their businesses in an easy way:

1. Create and publish a Software Bill of Materials (SBOM) in a standard format (SPDX or CycloneDX) for every major release. Since we are using Maven for dependencies, this should be quite straight forward to do in Jenkins or a Github action.
2. Create documentation on the architecture of OH, on a high level, to show how the different parts of the system interacts.
3. Based on the architecture diagrams, create a threat model and risk analysis, to discover both areas of improvement in OH itself, and/or serve as a manual for those who use OH in where they need to take extra care of security.

I can gladly look into #1, but would like to get some input on if this should be done for OH Core/Addons/UI etc separately, or if it should be done on the OH distro? (I could experiment a bit to see what’s viable, but if anyone can help with reasoning it is very welcome).

I have a basic grasp of #2, but will definitely need help from the people who have better knowledge of how things fit together.

#3 would be best done in a collaborative way between people who have good knowledge of different parts of OH (mainly UI and Core) and people who know security (I know that there are others beside myself who work in this area). If we could gather a few of these people (physically or virtually) that would likely be the best and hopefully interesting to all involved, I would live to be a part of this.

Hope that we can make the best of this in the interest of all current and future OH users!

[garyfree]

Hopefully this doesnt end up like a lot of EU legislation
Ignored, adopted wholesale without thought or extended(something UK often did).

[rlkoshak (Rich Koshak)]

@pacive

I can gladly look into #1, but would like to get some input on if this should be done for OH Core/Addons/UI etc separately, or if it should be done on the OH distro? (I could experiment a bit to see what’s viable, but if anyone can help with reasoning it is very welcome).

It probably has to be done at each repo individually and then aggregated up to the distro repo.

@pacive

I have a basic grasp of #2, but will definitely need help from the people who have better knowledge of how things fit together.

It depends on how deep this needs to go and what they mean by “documentation on the architecture”. If they just want a couple of high level diagrams that’s one thing. If they want something in Zachman or TOGAF that’s a whole other kettle of fish.

@pacive

#3 would be best done in a collaborative way between people who have good knowledge of different parts of OH (mainly UI and Core) and people who know security (I know that there are others beside myself who work in this area). If we could gather a few of these people (physically or virtually) that would likely be the best and hopefully interesting to all involved, I would live to be a part of this.

I’m a professional computer security engineer can contribute some. I’m also very familiar with ATT&CK, though that’s probably a step beyond what’s needed here. But I know nothing of EU regs and this one frankly looks like another way to snuff out FOSS.

[pacive (Anders Alfredsson)]

@rlkoshak

But I know nothing of EU regs and this one frankly looks like another way to snuff out FOSS.

FOSS is explicitly exempted from all requirements, so legally we don’t need to do anything, the burden falls entirely on those who use the FOSS in their commercial products.

Why I raised this is because I know there are at least a few individuals who do just that, and it may be difficult for them to interpret the regulation and provide the correct documentation.

@rlkoshak

It depends on how deep this needs to go and what they mean by “documentation on the architecture”. If they just want a couple of high level diagrams that’s one thing. If they want something in Zachman or TOGAF that’s a whole other kettle of fish.

This is something that is not very clear at the moment, but there are a three year grace period before the regulation is in effect, so will hopefully be more clear later on. (Meaning there’s no rush do do this, maybe considered if/when updating the documentation for other reasons). There will be lighter documentation requirements for small- and micro enterprises however, which is IMO what should be the target here. If any larger corporation wants to base a product on OH, they should have sufficient resources to do this on their own. My guess, the high level diagrams should be enough.

[splatch (Łukasz Dywicki)]

@pacive

This is something that is not very clear at the moment, but there are a three year grace period before the regulation is in effect, so will hopefully be more clear later on. (Meaning there’s no rush do do this, maybe considered if/when updating the documentation for other reasons). There will be lighter documentation requirements for small- and micro enterprises however, which is IMO what should be the target here. If any larger corporation wants to base a product on OH, they should have sufficient resources to do this on their own. My guess, the high level diagrams should be enough.

I have followed some of CRA discussions earlier on within Apache Software Foundation which provided some feedback among other open source organizations. I may be able to seek for Q&A published a while ago based on OSS steward questions.
There are several factors which force legal entities to implement CRA early on. Assuming that we speak about commercial entities, if company acts in specific sector (i.e. energy), have a large installation base, or large volume of commercial activity (holding/group independently of its kind) its due date for CRA might be much shorter. If I recall correctly, all EU countries have to align their own legislation to what been agreed by European Commission, thus the 3 year window mentioned above, may already count in a bureaucratic slip which can be shorter depending on the country and its involvement in preparation of legislation at European level. Taking it back by one step, it means that status of open source steward for openHAB Foundation will most likely depend on German legislation, where foundation is registered.

What is not entirely clear to me, whether the PV inverters sold to individual households, are considered a energy sector? If so, then from what I understand the due date might be already past due. Until now PV inverters were usually approved by grid operator (beside CE mark) before being plug into grid. Yet, by chats I have had during PV trade fairs, most of grid operators would just stamp whatever producer declared (if they like him), without putting any effort in confirming whether inverter supports a sunspec or not (not to mention how well it does!). There is no surprise that some of imported equipment does not even support modbus interface or some of brands start to limit access to it through various ways.

Seeing the past directives I personally feel no certainty that CRA will make any difference better than GDPR. It is again reaching a fundamental aspect of our (digital) life. I just hope that it won’t be another playground for layers and big techs. For GPDR many, if not all major suppliers managed to avoid large chunk, if not any responsibility, by becoming “data processors”. They keep collecting everything, just like they did before, but now they do it on behalf of innocent individual who is personally responsible for implementing GDPR regulations, even on a dummy wordpress which holds blog 10 posts. Not to mention cases that self employed contractor who lost a cell phone should report it to appropriate authorities and face possibility to get a fine.