Connected Cars, and especially cooperative connected and automated mobility, are very important for the future of transportation. They can improve traffic efficiency, reduce emissions, enhance road safety, and provide better mobility services for users.

TECNALIA has set up a pilot to enable the platforms’ connectivity so as to provide a cooperative maneuver of platooning, which is dependent on communication systems for its tight control of inter-distance between vehicles. The pilot includes the Twizy vehicle platforms, which have connectivity and automated capabilities, and a control station as infrastructure, which monitors and provides high-level control to the cooperative maneuvers.

Figure 1 IoTAC platform in the Connected Car pilot

Cybersecurity remains a concern for these connected systems, which could hamper or even impede the correct functioning of the vehicle systems. TECNALIA’s automated vehicles make use of V2V communications for the platooning use cases, as well as internet connectivity via 4G. In the context of the connected car pilot, the IoTAC modules have been placed both (1) in the control station infrastructure, which will handle the platooning, to provide appropriate coverage for threats in the platooning service and (2) in the automated vehicle itself.

To this extent, the development and deployment being done in the IoTAC project referred to as this pilot, can be split into the following:

1. Control station security, where one of the main concerns is the security of the information being exchanged with the vehicles’ platforms. A second concern is the availability of the platform itself and its potential exposure to attacks, which could render the service availability.
2. Automated Vehicle Platform security, which tackles the possibility of attacks in the vehicle network itself, either by having a physical entry point or by exposure to internet connectivity. A second concern is the correctness of the data reported by the vehicle, and the appropriate functioning of the platform.

To this end, the IoTAC project serves as a testing ground for connected vehicle cybersecurity, by fully integrating the designed platform to tackle these concerns. The modules have been placed in accordance with the aforementioned risks, both in the vehicle and infrastructure for the control station.

The development of a monitoring framework in the IoTAC project – by aggregating different modules thus maximizing coverage – is critical to the connected car pilot. The Attack Detection module and the Security Gateway have been placed in the vehicle, monitoring all traffic data exchanged between sensors, computational equipment, and communication devices, which allows an assessment of the network state. The Honeypot module has been put adjacent to the control station, protecting it from possible malicious intruders and informing directly to a centralized IoTAC framework via a data bus.

The Front-end Access Management (FEAM) module is deployed to target the control station, specifically the authentication layer and role assignment. This module introduces a secure registration process as well as adds an additional layer of security over IoT connectivity by assigning specific roles to each user. This removes the concern regarding unauthorized access to the control station capabilities as well as manages the specific functionalities given to each role in the administration of the platoon.

A Runtime Monitoring System (RMS) is also deployed and connected via the data bus which inspects messages from the vehicle platform, the FEAM, and the Honeypot modules. From the vehicle data, it checks its correct deployment (i.e. kinematic variables within range, vehicles in the correct area, etc) and provides information via a dashboard solution. In the case of the FEAM and the Honeypot, specific messages are also shared for monitoring purposes to assess in real-time via a dashboard the correct functioning of the system.

The lessons learned from the assessment results of these IoTAC modules deployed in the connected car demonstrator will follow at the end of the project.

The CERTH/ITI Smart Home is Greece’s first house that combines advanced construction materials with intelligent ICT solutions, resulting in a future-proof, sustainable, and active testing environment. It offers a variety of innovative smart IoT-based technologies, including energy, health, big data, robotics, and artificial intelligence (AI). The Smart Home is equipped with a wide set of heterogeneous sensors and actuators providing information for several operations taking place within its infrastructure (e.g., smart light bulbs, smart appliances like smart washing machine and smart refrigerator, etc.).

Information Security is a major concern for any ICT system, and the ITI Smart Home is not an exception. Energy and Health modules apply and maintain diverse controls across the wide network of heterogeneous interconnected IoT sensors and actuators. Smart Home inhabitants have the possibility to switch on/off appliances using dedicated software services. Besides, sensitive information such as energy consumption or outputs of healthcare sensors is constantly exchanged between built-in services via the Smart Home network. This implies a large attack surface and a significant challenge for appropriate security controls across the whole system.

Considering the aforementioned risks, the security concerns pertaining to the Smart Home can be categorized into two main dimensions. Firstly, there is a need to address the potential risks associated with the execution of malicious commands and the reporting of falsified sensor or device measurements to the Smart Home administrator. To this end, a more secure policy is needed for identifying if the reported measurements are accurate or not, or more specifically, if they have been altered in a malicious way by an intruder. Secondly, we must ensure security measures are in place to prevent unauthorized access to the resources and data within the Smart Home system. Regarding authentication and user access control on the resources of the Smart Home system, a combination of basic authentication and role-based access control is currently used, which defines to which resources the user has access and what actions the user can perform on these resources. We consider that this scheme is adequate for some cases, but it has room for improvement.

To this end, within the H2020 IoTAC project, the Smart Home infrastructure serves as a successful test bed to evaluate the proposed IoTAC security solutions. By deploying the innovative IoTAC security solutions in the Smart Home System, we can effectively address both of the aforementioned security concerns. Figure 1 depicts a high-level overview of the integration of the novel IoTAC security modules into the Smart Home infrastructure.

Figure 1 – High-level Overview of IoTAC Integration in Smart Home

To address the security concerns in more detail, the deployment of the novel runtime monitoring features of the IoTAC framework plays a crucial role. Specifically, the IoTAC Attack Detection (AD) and Honeypot modules effectively alleviate the concern of executing malicious commands and reporting altered device and sensor measurements to the Smart Home administrator, ensuring the integrity of the reported data. Supporting these modules is the IoTAC Runtime Monitoring System (RMS), which facilitates data distribution and provides security-related information to the Smart Home administrator, such as the number of identified malicious attacks and affected devices.

Additionally, to mitigate the security concern of unauthorized access to Smart Home resources, the IoTAC FEAM (Front-End Access Management) module is deployed. This module introduces novel authentication and authorization mechanisms that enhance the registration process for users in the Smart Home System and regulate their access to resources. By leveraging FEAM, the protected system is secured against unauthorized access attempts.

Finally, in terms of design time security, all newly developed applications and services undergo evaluation and certification by the Software Security by Design (SSD) platform. This ensures that these components meet rigorous security standards before integration into the Smart Home ecosystem.

As the integration of IoTAC into the Smart Home enters the validation phase, there is a high level of confidence that incorporating the novel IoTAC hardware and software security solutions will significantly enhance the overall security of the Smart Home environment. More details on the results will follow in the upcoming pilot-related public deliverables. Stay tuned!

After much deliberation, the family decided to install solar panels in our holiday home.

When it came to sizing, we set ourselves the goal of avoiding back-feeding, as the rules for this can change all the time and the calculation of the return on investment is fraught with too much uncertainty.

As the summer house is mostly used in summer and therefore our consumption is higher in summer, this fits well with the annual production cycle of solar PV systems. In summer we regularly charge our hybrid car, which means a consumption of 15-20 kWh per day. Circulating and tempering the small swimming pool requires 5kWh of energy per day, and other household consumers (fridge, hobs, air conditioning, etc.) consume on average another 5 kWh. So it can be seen that we are quite heavy consumers in summer, with an average daily consumption of around 30kWh.

Regarding the timing of the consumption, it is possible to match it to the instantaneous production of the generating unit by switching some of the consumers on and off. The swimming pool, the fridge, but also air conditioners are relatively large heat consumers, and car charging can be slid too.

The first step was to monitor the time distribution of actual consumption over a period of one month (this can now be done very cheaply using smart meters connected to the internal wifi network). The required solar panel capacity and the storage to match it were then sized. The system thus consists of a 10kWh battery and 16 solar modules, as this combination yields the best payback figures, assuming that the option of recharging will not come back to us.

In winter, the cottage is converted to a low-temperature control heating – using the heating mode of the air conditioners. The cost of this is of course highly dependent on the weather, but it is certainly considered to be more economical than the case without the use of renewable energy.

When 14-year-old Peter, who lives in the neighborhood, asked to see our equipment, I was happy to show him all the components. He looked at them with interest and then asked me how they were connected. Then he took out his mobile phone and pressed it thoughtfully. I didn’t pay much attention to what he was doing, as teenagers are always busy with their mobile phones.

Peter thanked me for showing him the system and went home. An hour and a half later he turned up again and said he had something to show me. He came in again and showed me on his mobile phone how he could switch off the soul of the installation, the inverter, in a few seconds. I watched in disbelief, certain that only I would have access to the password-protected device.

I had heard a lot about the attacks and threats to which IT equipment is exposed. But it’s one thing to hear something and another to experience it! After all, my house is not the only one with solar panels, and it’s bad to think that Peter’s game is to turn them all off! On a hot summer day, it would be like Peter turning off a large nuclear power plant!

I started looking for a suitable technical solution for protection. Consulting experts, I was surprised to find out how much it would cost. I was told that solutions are being developed to protect the IoT systems I use, which are cheap but provide high security, because the owners of many small systems cannot be expected to purchase expensive solutions.

But there is a need for such solutions. In our country, for example, a system that is shut down by external intervention can lead to frost damage in winter and disruption of comfort in summer. Strangely, the hybrid inverter at the heart of the system is easily accessible by anyone, no high-level hacking required. We have decided to provide this delicate IoT system with anti-piracy protection.

After much enquiry, we met with the IoTAC project specialists. The modular protection system they are developing will be able to protect our household. We will be installing them soon and I will report on the results in an upcoming blog.

This article was originally published in Hungarian in Computerworld.

If a smart home is hacked and the residents wake up to blaring music at night, it is extremely annoying. However, hacking and attacking IoT systems can cause a lot more damage. It is worth a thought where this can lead, for example, if unauthorized persons gain access to self-driving cars, or if the network of household power plants is attacked.

How secure are systems in which a large number of simple devices, such as sensors, are connected to a network? There are IoT systems where basic level protection such as username/password is sufficient, but there are also those ones where personal and other sensitive data must be protected at the highest level. An international consortium led by Atos Hungary intends to create an IoT architecture for these latter ones that enables the development and operation of flexible and resilient IoT service environments. In the IOTAC project, funded by the European Union, 13 industrial players, research centers, and universities from seven European countries collaborate. The project is running for 36 months, and completion is expected in August 2023.

Did the development start from scratch or were there already basic solutions that could be built on? – we asked project manager András Vilmos and László Vajta, professor of BME, Budapest University of Technology and Economics.

András Vilmos: When submitting the project proposal, we had the concepts and basic solutions. During the project, we develop the modules that implement these ideas.

László Vajta: It is a clear trend in the IoT systems that the number of protected components is drastically increasing which in some cases are very simple with low capacity and are not suitable for receiving expensive, sophisticated protection. In such circumstances, it became necessary to have a new approach for the protection of IoT systems with large number of endpoints.

Computerworld: How novel is the approach?

András Vilmos: It is a flexible system in which protection modules are connected to a central gateway. These modules are the front-end access management, as well as various runtime security functions: artificial intelligence-based attack detection models, honeypots, rollback points, and the real-time monitoring system. These technologies provide adequate protection at both hardware and software levels. Since the system can be flexibly configured, it can be used both in large industrial environments, as well as in small and medium-sized companies or even in household environments where the appropriate expertise and cyber-security background are missing for the protection. The basis of the system is the security-by-design paradigm. The recommended policies and procedures cover the entire lifecycle of secure software development, from design through development and testing, to evaluation and certification. It is very important that not only certain technological components are implemented during the project, but that they are also validated in pilot operations.

CW: In which IoT service environments will the results of the development work be validated?

László Vajta: With the cooperation of the consortium members, pilots will be running in industrial (prosumer system), residential (intelligent home), automotive (autonomous vehicle), and aerial (drone operation) IoT service environments. BME will set up a household-sized, independent energy management unit that produces and consumes energy from the combination of renewable energy and energy storage. In this so-called prosumer unit, we test the applicability of the technologies, as well as analyse security issues. It must be noted that the proliferation of household power plants entails serious security risks. If, for example, many household power plants are attacked simultaneously, the energy supply of even larger areas can be seriously threatened. The IoTAC project therefore also has the mission to draw attention to the special challenges of IoT systems, to reveal potential dangers, and to draw attention to the possibilities of reducing risks. Fortunately, more and more decision-makers recognize the problem and are looking for a solution.

Vilmos András: IoTAC also participates in other pilots: with Airbus in drone operation, with Tecnalia using autonomous vehicles, and with CERTH, in smart home management. Atos is creating a new solution for chip card-based access control that provides the highest level of protection. The point is that the physical chip cards are stored in the cloud, so that every cardholder can access them anywhere, anytime, without the need for a separate device.

CW: Are the tests conducted in real or simulated environments?

András Vilmos: There are real, simulated, and mixed pilots. The prosumer and smart home pilots, for example, take place in real environments, in Balatonfüred in Hungary and in Thessaloniki, Greece. We have created a half-real, half-emulated environment for self-driving cars. This means that real, and computer-simulated cars drive on a real, closed test track in Spain. The drone pilot is completely simulated.

CW: There is roughly half a year left from the project. How far have you come?

András Vilmos: The development works are more or less completed. We are currently deploying and testing the pilots. The results of the tests are fed back to the developers, who finetune the systems based on the feedback and satisfy any new needs that may arise along the way. We are progressing fully according to the plans and schedule.

CW: Does BME involve students in the research and development work?

László Vajta: Yes, masters students and doctoral students. Their activities are always managed by tutors. Typically, we entrust them with smaller tasks. Since the tasks are of a rather high level and complicated, we were able to involve only a few students in the work.

CW: The IoTAC consortium recently participated as an exhibitor at the Cyber ​​Security Congress in Barcelona, ​​which was organized together with the IoT Solutions World Congress (IOTSWC). What experiences did you gain there?

András Vilmos: More and more people are becoming aware that something needs to be done, as the number of devices connected to networks is rapidly increasing, and consequently risks are increasing. IoT security is in focus, and demand for security solutions is on the rise. By the way, we did not only participate in the IOTWSC with the IOTAC project but together with 6 EU sister projects, also related to IoT technologies.

CW: Do you promote the importance of protecting IoT systems at other forums as well?

András Vilmos: This April, we are organizing the IoT Day Roundtable for the third year, where we choose a special topic each time. Last year it was about standardization, this year the EU Cyber ​​Resilience Act is the main topic. The Act regulates how to implement consumer IoT devices with security being integrated by default. The event obviously will also introduce the IoTAC project. We invited representatives of the European Commission, and various industry organizations, with speakers from several European countries, as well as an expert from NIST (National Institute of Standards and Technology) from the United States. The virtual event can be followed online from anywhere in the world and the recording is available on the IoTAC website.

CW: After completion of the IoTAC project, how will the project results be used?

András Vilmos: During the project, we created the IoTAC Association, whose task is to coordinate the utilization of the results. The association does not carry out business activities but supports presence in industry organizations, communication with partners, and commercial activities of project members. The goal of the partners is to commercially exploit the project results. The business model was developed and the IoTAC framework is built in such a way that it can be marketed as one platform. We strived for flexibility, the individual modules can be activated separately, and most of them can also be used as standalone products. The IoTAC Association also has its tasks in standardization. In collaboration with ETSI, we are working on creating standards that describe how IoT environments should be protected, what requirements should be met, and how the tools to accomplish these should be developed. Disseminating this knowledge and requirements also belongs to our tasks.

CW: Who and what kind of organizations are expected to be the customers, the main users?

László Vajta: Let’s take an example! Nowadays, every household or small power plant sends the data generated during its operation – partly for security reasons – to the cloud of the inverter manufacturer. Thereafter, all data access (which we perceive as communication with our own power plant) takes place with the knowledge and permission of the foreign manufacturer. One of the results of the IOTAC project is that it enables the separation of small power plants from the manufacturer’s cloud while ensuring the necessary data protection and data access. This is a good example of how a research and development project can bring usable, tangible results.

András Vilmos: We see great potential in smart homes. We will have to contact the manufacturers, service providers, and integrators that install smart homes. We need to ensure that our solution is treated as an option or a default option. In general, our direct partners are not the end users, but the system integrators who install the IoT system. The results created in the IoTAC project are therefore not directly B2C, but rather B2B2C solutions.

This article appeared in Electronic Design and has been published here with permission.

IoT device security a feature no more? Recently enacted and upcoming cybersecurity regulations and standards will significantly impact how these devices are designed.

 

Deployment of robust embedded device security has been slow as many IoT devices ship with incomplete or improperly implemented security. In the absence of regulations, manufacturers have largely been left to their own determination on when, what, and how to implement device-level security.

However, increases in the frequency and severity of hacking attacks are motivating governments to propose regulations to improve the security posture of IoT devices. 2022 accelerated the enactment of new standards and laws that will impact the design and deployment of IoT devices in 2023 and beyond.

Automotive Leads the Way

Automotive has been one of the earlier adopters of embedded cybersecurity with the advent of electric vehicles, autonomous driving, and software-defined vehicles. Even traditional internal combustion vehicles are increasingly connected and are prime targets for hackers.

Last year saw the UNECE R155 automotive cybersecurity regulation come into effect for new vehicle type approval. Aligned with the ISO/SAE 21434 standard, R155 requires the automotive supply chain to establish and certify cybersecurity management systems (CSMS), which are designed to assess risks, manage those risks through security by design, and secure each vehicle throughout its lifetime.

Compliance with this regulation is a key focus for all auto manufacturers selling into the European market and their suppliers. 2023 is considered as a critical year to broadly drive adoption across the automotive supply chain.

Intensifying IoT Cybersecurity

The U.S. government is bringing greater attention to IoT cybersecurity. For federal and supplier networks, Cybersecurity Maturity Model Certification (CMMC) requirements and implementation of NIST SP 800-171 and 800-53 have primarily focused on IT security. However, that’s now expanding to include IoT devices handling government controlled unclassified information (CUI) data.

Network-connected equipment that was previously exempted from meeting cybersecurity requirements is now being required to implement access and management controls in addition to FIPS-validated encryption. While timetables for the enforcement of these mandates are still fluid, IoT device suppliers to U.S. federal organizations should be assessing their products and solutions for compliance with these mandates.

Medical Device Security

The FDA also took steps in 2022 to increase focus on security for medical devices by issuing a Cybersecurity in Medical Devices draft guidance update for premarket submissions. This guidance emphasizes that cybersecurity is a part of medical device safety and quality system regulations. It recommends manufacturers implement a secure product-development framework that includes threat modeling, software bill of materials (SBOMs), security by design, and lifecycle management.

The FDA also recommends best-practice security controls such as authentication, authorization, cryptography, code/data/execution integrity, confidentiality, event detection/logging, resiliency, and updatability.

Then, in December 2022, the Consolidated Appropriations Act passed and included authorization for the FDA to regulate medical device cybersecurity. This law requires medical device manufacturers to submit security monitoring and maintenance plans, support device security lifecycles through software updates, and provide SBOMs for new devices. The FDA is currently studying these requirements and will be issuing updated guidance in 2023.

IoT Security Measures in the EU

2022 also saw the enactment of the U.K. Product Security and Telecommunications Infrastructure Bill, which will require IoT device manufacturers to no longer use default passwords, confirm how long security updates will be provided after the device is launched, and disclose known vulnerabilities.

Similarly, the EU proposed the European Cyber Resilience Act to improve security for all IoT devices sold in Europe where security isn’t currently mandated. This proposal requires that IoT devices have an “appropriate level of cybersecurity enabled in devices” default configuration, prohibits the sale of products with known vulnerabilities, and that the impact of security incidents be minimized.

While both mandates leave the implementation of the needed security to be determined, these are critical first steps toward driving the adoption of broadly deployed security controls for IoT devices in Europe.

What About the Consumer?

Even the consumer markets are showing signs of increased attention to device cybersecurity. The U.S. government is currently in the definition phase for a Consumer IoT Product Labeling program that will provide security capabilities, recommended configuration, and long-term security maintenance for consumer IoT products.

In the industry side of the market, 2022 saw the approval of the Matter interoperability and security standard for smart-home devices. Matter-compliant devices have already begun to enter the market with wide support from consumer semiconductor and smart-home device manufacturers.

Conclusion

The proliferation of the broadly defined Internet of Things has brought a revolution in convenience, efficiency, information, and automation across nearly all aspects of our daily lives. However, these benefits bring greater risks to privacy, safety, and national security that are under daily attack.

Governments, device manufacturers, and even consumers are more focused on these risks than ever before as we all come to realize that basic security is no longer optional. We expect IoT device cybersecurity to accelerate in 2023 and throughout the upcoming years, with increasingly active government security regulations driving adoption broadly across the IoT device supply chain.

In September 2022, the European Commission presented a proposal for a new Cyber Resilience Act (CRA) to protect consumers and businesses from vulnerable IT products. It is the latest in a set of cybersecurity regulations including the EU Cybersecurity Act and the NIS2 Directive. Its goals are commendable, but a careful reading is required to understand its consequences and identify potential drawbacks. As usual, the devil is in the details.

For the first time, a regulation seems to address all security aspects in a consistent way

The Cyber Resilience Act in a nutshell

Understanding a huge regulation is always a challenge and requires knowledge of the regulator’s intent. For those who haven’t followed the preliminary discussions, the fact sheet published along with the proposal gives a fair summary of the European Commission’s objectives.

It proposes practical measures to improve security, such as requiring security in all phases of a product lifecycle, making configuration instructions clear and understandable, providing security patches, and reporting exploited vulnerabilities. Another positive aspect is the intent to leverage the EU Cybersecurity Act’s existing certification schemes to immediate enable third-party security assessments.

From an enforcement perspective, EU regulations don’t wait for Member States to enact them. They are immediately applicable and enforceable, as GDPR has proved. Like GDPR, the CRA can impose huge penalties, meaning it’s not a regulation that CEOs can afford to ignore!

It is also a good thing to have such regulation at European level, with an authority (ENISA) already in-place whose role is strengthened by the regulation. For the industry, it is reassuring to have a single authority for such a large market.

The obligations for manufacturers are detailed in Article 10. They can be summarized as:

1. Meet the essential requirements set out in Section 1 of Annex I
2. Assess the cybersecurity risks associated with their product
3. Ensure their supply chain does not compromise the security of their product
4. Document the security aspects of their product
5. Maintain the security of their product during its lifetime.

These are all very sane principles, and no one could call these objectives into question. What’s revolutionary about the CRA is its very wide scope. In it, the legal definition of a “product with digital elements” includes not only the product itself, but also the back-end software and hardware with which the product is intended to work. From a legal and security perspective, this makes sense, but in practice it may have unforeseen consequences.

The section which may have more impact on manufacturers is Article 24. It states that “the manufacturer shall perform a conformity assessment of the product… and (of) the processes put in place by the manufacturer to determine whether the essential requirements set out in Annex I are met.”

This is a very positive approach, in that it tries to improve not only the security of a product, but also the processes which will ensure security during the product’s lifetime. Taking these processes into account is key, given the rapid evolution of today’s technologies. Yet, limiting security only to processes is insufficient to ensure complete protection. For the first time, a regulation seems to address both sides of the coin in a consistent manner.

Also interesting is the notion of defining a level-based approach for critical and highly-critical products. Indeed, some products’ security may have a direct impact on other systems, making it important that they meet higher security assurance standards.

The CRA denies authority to the market surveillance authority it creates

Diving into some key details

Any company wishing to sell products in the European Market must read Annex I carefully, because it encompasses all the new requirements that any operator (manufacturer, distributor or importer) will have to comply with. Annex I is pretty straightforward, divided in two parts: one for the products, one for the vulnerability handling process.

The one sentence which will undoubtedly raise concern requires a product to be “delivered without any known exploitable vulnerabilities” when put on the market. This immediately raises the question of exactly what a “known exploitable vulnerability” is — and unfortunately, no legal definition appears in the CRA.

In fact, this term only appears in Annex I, and the introductory memorandum of the legal text, but not in the text itself. The only related definition refers to an “actively exploited vulnerability,” which is defined in Article 3 (39) as “a vulnerability for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner.”

Is a known exploitable vulnerability a vulnerability that is known to have been actively exploited? Given the legal impact of an exploitable vulnerability (which forbids a product from being put on the market), it is therefore key to have a clear definition of it.

Why? Because virtually every product has some known exploitable vulnerabilities under certain definitions.

Let’s take the example of CPUs. “General purpose microprocessors” are listed among the most critical products under the CRA (see Annex III, Class II). This makes sense, given the wide usage of CPUs in our IT systems. But it is also true that, by design, any CPU is prone to so-called “side channel” attacks, which can be exploited if certain conditions are met.

In simple terms, modern CPUs try to optimize their efficiency. To do so, they calibrate their performance (cache access, power consumption, etc.) based on program data submitted as input. Thus, modern CPUs — by their very nature — leak information about the programs being run on them. If a malevolent program is running in parallel on the same CPU, this information leak can be amplified to compromise sensitive information from a program.

In terms of risk assessment, everything can be documented, and most CPU vendors have already analyzed and described these threats. However, laboratory testing has shown that it is possible for these small leaks to be exploited to extract cryptographic keys, but this is usually demonstrated on specially crafted programs.

So, are all CPUs condemned to be banned from the EU market due to the CRA? This question may be not as silly as it sounds, since Article 43 of the project raises another concern.

At first reading, this article seems to make sense. But from a legal perspective, it doesn’t leave a lot of freedom for the market surveillance authority. According to Article 43.1:

Where the market surveillance authority of a Member State has sufficient reasons to consider that a product… presents a significant cybersecurity risk, it shall carry out an evaluation of the product. Where… the market surveillance authority finds that the product with digital elements does not comply with the requirements laid down in this Regulation, it shall without delay require the relevant operator to take all appropriate corrective actions to bring the product into compliance with those requirements, to withdraw it from the market, or to recall it…

How will the “significant cybersecurity risk” be assessed? Does the existence of an exploitable vulnerability qualify? What about the CPU case we just outlined? Will a market surveillance authority risk ignoring a vulnerability presented as exploitable?

Let’s consider another recent incident, in which the open-source component Log4j put thousands of products at risk. How will the market surveillance authority perform an evaluation of all the impacted products? If this evaluation reveals any non-compliance, it is required to issue corrective actions to the relevant operator? The current wording doesn’t leave room for interpretation. In a sense, it denies the market surveillance authority its authority.

Another problematic aspect of the CRA is an unclear definition of the period during which security patches are to be delivered. Item 12 of Article 10 in the CRA obligates manufacturers to maintain full conformity with Annex I for five years or the expected lifetime of the product, whichever is shorter.

This obligation may lead to a domino effect. Let’s take the example of CPUs again. A CPU vendor that puts its product on the market must maintain security monitoring for five years, despite the CPU’s longer expected lifetime. Now assume that a server maker like Atos decides to embed this CPU in its server, but due to integration constraints, the server is put on the market one year later. Thus, the CPU in that server now only has four years of guaranteed security support remaining. Perhaps you also need some embedded GPUs in your server. It’s possible that these might have three years left in terms of maintenance.

Multiply that complexity with every embedded component and it becomes likely that after a year or two, one component or another will become obsolete. As a product vendor, you can find a functional replacement for the obsolete component, but if you no longer have support from the component vendor, is your vulnerability process still compliant?

Will you have to swap out every obsolete component in the servers you have already sold? This would change completely the economics of the manufacturing industry.

We have reached dangerous ground, where the regulator gives value to the bug, and denies value to the patch.

Where the CRA could backfire

Despite these shortcomings, in my opinion the worst impacts are elsewhere in this regulation. It’s not from the legal part of the text (the Articles) but from Annex I. The last point of this annex refers to an operator’s obligation to “ensure that, where security patches or updates are available to address identified security issues, they are disseminated without delay and free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.”

The other part of the vicious circle comes from item 36 in the preamble to the CRA, which promotes bug bounties. I have already expressed concern about this, but I think we have now reached dangerous ground. Here, the regulator not only gives value to the bug and the vulnerability, but also denies value to the security patch.

This approach could be detrimental to the security of many products, because open-source developments are often financed by their support, and especially their security support. For example, the widely-used OpenSSL library is supported by an organization whose revenues come partly from providing extended support on previous versions of its library.

Companies pay for this support because they want to have security fixes guaranteed for a long period, and because the stability of their products is not compatible with the never-ending development of new features. On the other end, making new versions available free-of-charge allows companies to rapidly implement new features, test them, and propose them in their new products.

Enforcing an obligation to work for free seems counterintuitive to me. Why incentivize bug finding but not security patching? If you pay for security patches, it’s more likely that you will apply them!

Given the legal risk and the amount of the penalties, some hackers could also be tempted to ransom companies by threatening to disclose their vulnerabilities. If you risk €150 million in penalties, you may opt to pay €1 million to prevent a public disclosure. Unless I’m wrong, the CRA puts the obligation on operators to disclose the vulnerability of their products to ENISA. The hackers are under no obligation to disclose vulnerabilities to the operators, to the market surveillance authorities, or to ENISA.

In my opinion, this obligation should be enforced free-of-charge — not the security patches, which require a lot of cost and effort to properly develop and validate, and which can be embedded in larger upgrade packages. Again, the purpose is to mitigate cybersecurity risks, not to obtain security for free, because this won’t happen.

 

Conclusion

The new Cyber Resilience Act is a step in the right direction to improve the security of the digital products we all rely on. However, I feel strongly that a few of the requirements must be reconsidered before it comes into force, in order to avoid some of the negative consequences outlined above.

This guest blog is published with the kind permission of Atos and originally appeared here.

If you want to learn more about the CRA and its impact, join our Roundtable on 17. April, where you can hear not only Florent Chabaud speak, but also listen to the position of the European Commission, the US NIST, standardization organizations, and industry. For agenda and registration, please go to https://iotac.eu/iot-day-roundtable-2023/!

We live at a time when much of what we buy – watches, phones, fridges – is connected to the internet. Although technology has made our daily lives more comfortable, it has also made us more vulnerable.

Manufacturers have been keen to sell connected products, but often paid little attention to making them cybersecure. In other words, the market has not delivered. And the EU has been slow in setting effective rules to address this major problem.

Over the past years, Consumer organisations have repeatedly flagged that too many products on the market carry cybersecurity risks and lack the most basic security features. This must stop.

In proposing the Cyber Resilience Act, the European Commission took a major step forward. The law would establish EU-wide cybersecurity requirements by design and by default for all connected devices. However, there are still  key improvements to be made to ensure it can adequately protect consumers.

Products should be secure before and after being placed on the market

Consumers are right to expect that products on the market are not only safe and secure when they are sold, but during their expected lifetime. But the sad truth today is that products like PCs or smartphones only receive security updates for so long, after which they become vulnerable to hacking.

When manufacturers fail to protect their products with necessary software updates, these devices not only expose consumers to cybersecurity vulnerabilities, they also become slower, less performative, and sometimes unworkable way before their end date. Apart from causing consumer frustration and putting them at risk, this premature obsolescence fuels waste and is fundamentally at odds with efforts to align our society with planetary boundaries.

The new rules must ensure that consumer-facing connected products are protected before and for sufficiently long after they are bought: you can’t talk about real cybersecurity if a product you buy is only secure for a year when it can last for up to ten!

That is why BEUC is pushing for manufacturers to provide essential software updates during a product’s expected lifetime. The proposal only requires a maximum protection period of five years, which would leave all kinds of products unprotected beyond that timeframe. Think of dishwashers, fridges or TVs!

Making sure a product is secure

How can consumers be sure that a product is ultimately secure? The Commission proposal relies on self-assessment by the manufacturer for over 90% of products. That is a clear conflict of interest which has echoes of dieselgate: the manufacturer is also the certifier. Which company is going to contradict itself and say that a product it made is not in conformity with the law?

Consumers need more to go on than just the word of the manufacturer when their cybersecurity and personal safety are on the line.

Independent third parties should be tasked with verifying if a product is secure. This is especially important for certain products which, given their sensitive nature and potential risks of misuse by a cyber-attack, carry enormous risks for consumers, from violations of their fundamental rights (privacy, data protection) to even compromising their physical safety.

What about us? Consumer devices are high risk too

The new rules do recognise that certain products are too risky to leave to self-certification by the manufacturer. Although this is a step in the right direction, the option to put forward a short closed list of critical devices risks barely scratching the surface of high-risk products: without a risk methodology with clear criteria that can be applied to all products  this legislation risks overlooking many sectors. In particular, this closed list clearly risks overlooking one key stakeholder: consumers.  The proposal leaves out consumer devices from this list. The law should be aligned with what consumers expect: it should recognise the real risks posed by devices in our homes which, if hacked, have the potential to cause significant harm and substantial damage to us.

For example, it is astonishing that home internet routers are not considered important enough to go through third-party certification. And there are other consumer devices which should require mandatory certification, given the sensitivity of their use and private location (children’s devices, smart home systems, security devices) for which the manufacturers’ word is not good enough.

When everything else fails

New EU rules must provide a clear answer to the following question: what can consumers do once the harm has occurred? At the very least, consumers should be able to hold manufacturers to account. There should be a clear mechanism for reporting problems directly to manufacturers from the beginning. Consumers should also have accessible means to engage with public authorities, who have every reason to welcome the (much needed) help of civil society in the market screening and enforcement process.

And just as importantly, consumers must be able to demand compensation for damages caused by the lack of conformity with these rules. That means they need effective redress including the possibility to launch collective actions when many consumers have been affected by the same harm. It is therefore crucial the Cyber-Resilience Act is added to the annex of the Representative Actions Directive.

In conclusion, the Commission proposal for a Cyber Resilience Act is a much-welcomed first step to addressing some of the key issues currently facing consumers. However, this proposal can still go further: BEUC has issued key recommendations on key improvements to ensure that the CRA proposal is truly fit for purpose. It is now up to EU legislators to deliver.

 

This guest blog is published with the kind permission of BEUC – The European Consumer Organization and originally appeared here.

If you want to learn more about the CRA and its impacts, join our Roundtable on 17. April, where you can hear not only Claudio Teixeira speak, but also listen to the position of the European Commission, the US NIST, standardization organizations, and industry. For agenda and registration, please see https://iotac.eu/iot-day-roundtable-2023/!

More and more successful cyberattacks are targeting hardware and software products, leading to an estimated global annual cost of cybercrime of EUR 5.5 trillion by 2021 according to the EU commission. This is due mainly, on one side, to the lack of appropriate security in such products who often go to market including inherent vulnerabilities and on the other side, to the lack of awareness of the consumers or enterprises adopting those products due to an insufficient transparency of the manufacturers when it comes expressing their level of security.

This is why, on September 15, 2022, the European Commission published the EU Cyber Resilience Act (CRA) regulation proposal necessary to increase the level of trust among users and the attractiveness of EU products with digital elements while providing legal certainty.

The regulation is very exhaustive, and we would recommend you to go through it in details. In the meantime, here are the top 8 things you should know about the EU Cyber Resilience Act that we just picked for you…

 

1- Am I concerned?

Yes, if you are a manufacturer, importer or distributor of connected products (Hardware/Software) with digital elements (e.g. smart sensors, smart cameras, mobile devices, network devices, etc.). All market sectors are concerned in a horizontal way except sectors where some other EU regulations already applies such as in the medical, civil aviation, motor vehicles domains. Note that this can consist also of non-embedded software (software that can be made available without hardware). For instance services such as SaaS applications are not
within the scope of this regulation unless these are used to remote processing the product at a distance which is under the responsibility of the product manufacturer and the absence of which would prevent such product from performing one of its functions. Finally, Free and
open-source software supplied outside of a commercial activity should not be covered by this regulation.

 

2- What are my obligations?

One of the main goals of the CRA is to cover the entire lifecycle of digital products. So your first obligation would be to insure that a list of essential cybersecurity requirements and harmonized rules have been considered at all stages including the design phase, delivery,
actual product use, maintenance decommission, and disposal. Security by design, security by default, the security of the supply chain and vulnerability handling will be the main domains to be addressed. Secondly you need to conduct and document a security risk assessment and
provide user guidance. You must report actively exploited vulnerabilities and provide security updates for at least five years. If you know or have reason to believe that the product or the processes put in place by the manufacturer are not in conformity with the CRA essential requirements, you shall immediately take the corrective measures necessary, to withdraw or to recall the product as appropriate and notify ENISA within 24 hours.

 

3- How should I demonstrate conformity?

Most common families of digital products belong to non-critical risk category requiring a conformity self-assessment that should be carried out under your responsibility. Some other products considered belonging to higher risk categories will be qualified critical (Class I) and might require additional assurance requirements to be satisfied by applying harmonised standards or the EU cybersecurity certification schemes such as the EUCC or the EUCS and that could be under your responsibility or through a third-party CAB. Some other highly critical (Class II) products should always involve a third-party CAB. Finally, certified products according to the EU cybersecurity certification schemes such as the EUCC developed under the CSA are supposed to satisfy by default the EU Cyber Resilience Act requirements and can provide a presumption of conformity.

 

4- How does it relate to other EU policies?

The CRA complements the existing Directive on the security of Network and Information Systems (NIS2) and the existing EU Cybersecurity Act (EU CSA). It is also based on the New Legislative Framework (NLF) for industrial products, which aims to improve market surveillance and the quality of conformity assessments. It is expected to satisfy the Radio Equipment Directive (RED) cybersecurity-related requirements. This means that RED-related harmonised cybersecurity standards (under development) will most probably serve as basis for the EU CRA essential requirements.

 

5- What are the potential Costs vs Benefits?

It is estimated that any compliance costs for businesses would be outweighed by the benefits brought by a higher level of security of products, by preventing divergent security requirements and an increase of trust of users and market adoption. It also increases positive competitiveness and quality standards by levelling the playing field. It would reduce the number of incidents, incident handling costs and reputational damage. For the EU this means roughly 180 to 290 billion Euros of consequence costs could be avoided. Finally, non-compliance with the CRA essential cybersecurity requirements and all relevant obligations shall be subject to fines of up to 15 000 000 EUR or, if the offender is an undertaking, up to 2.5 % of its total annual turnover for the preceding financial year, whichever is higher.

 

6- By when it will be applicable?

The proposal will now pass to the European Parliament and Council that will form their own positions before coming together for the trialogue negotiations in Q3/Q4 2023. So in order for all stakeholders (manufacturers, distributors, importers, CABs, Member States, ENISA, etc.) to adapt to the new requirements, the proposed CRA regulation will become applicable 24 months (at the latest by Q1 2026) after its entry into force, except for the reporting obligation on the manufacturer, which would apply from 12 months (most probably by Q1 2025) after the date of entry into force.

 

7- How could I recognize a conformant product?

I’m sure you’re all familiar with CE marking which you could find on all products circulating in the EU. This same mark will indicate the conformity of all products with digital elements with this regulation. Only beta releases for testing purposes could be issued without that mark as long as these are time limited to testing purposes. Most importantly, importers of products with digital elements must ensure in addition to checking on the CE marking that the appropriate assessment procedures have been carried out by the manufacturer depending on the risk assessment and that the manufacturer has created all required technical documentation.

 

8- Yes, you could appoint an authorized representative

Indeed, as a manufacturer you could mandate an external authorised representative who could discharge you from the EU declaration of conformity management and for market surveillance purposes.

Finally, it’s not too early to start planning accordingly, adapt your digital product strategy and chose the right specialized partners to avoid missing the EU single market access opportunity.

 

This guest blog is published with the kind permission of Red Alerts Lab and originally appeared here.

If you want to learn more about the CRA and its impact, join our Roundtable  on 17. April, where you can listen to the position of the European Commission, the US NIST, standardization organizations, and industry. For agenda and registration, please go to https://iotac.eu/iot-day-roundtable-2023/!