Anastasiya Kazakova, Senior Public Affairs Manager, Kaspersky
Igor Kumagin, Cybersecurity expert, Kaspersky
Reflections on what should be considered by regulators and decision-makers to actually bring more cybersecurity to digital products and services.
In May 2022, the European Commission invited all interested stakeholders to share their inputs for the upcoming Cyber Resilience Act (CRA). Having identified a necessity to strengthen security in modern “digital products and ancillary services” as well as the lack of incentives for both consumers and manufacturers to assess the security of such products and services, the Commission launched a wider discussion on a potential new set of direct cybersecurity requirements for “everything which is a computer now” (and not only). This will, for sure, have the potential to change the entire tech industry beyond the formal EU’s borders and to have further technological and economic implications.
In this piece we would like suggest some frameworks for such a discussion and the future CRA. Our key purpose is to share our first reflections (given the current earliest start of the legislative process) stemming from our vast cybersecurity expertise and professional experience. Below we focus on the key six ideas for brevity; however, the complete list of all such ideas can be found in the full submission made last month.
Don’t hesitate to reach out to share your feedback – we would be happy to discuss this further!
#1 Take a differentiated approach: digital products (hardware, software) and services require a tailored set of cybersecurity requirements and should be carefully approached.
Considering the outlined intention to introduce cybersecurity requirements for digital products and ancillary services, what needs to be considered first is the necessity of keeping a careful differentiated approach to each sub-set of such products, i.e., hardware, software, IoT and services. A tailored approach is most needed to realistically capture the specifics in the use of such products and, therefore, their risk profiles. In particular, use of digital services does not commonly create direct risks of compromise to the customers’ or end-users’ network, while the use of on-premise digital products does. In a similar fashion, software and hardware are products with a different ‘nature’ and application.
#2 Open source tools and libraries that are used in critical services should also be addressed.
The recent disclosure of a series of vulnerabilities in open source libraries (log4j) highlighted the “endemic vulnerability” across the global internet within old and new software products, thus affecting multiple stakeholders in the software development community, tech industry and government. And while there is no universal solution developed to address this, it’s important to raise questions of availability and security of such critical open source tools and libraries. Hopefully, the future CRA will outline coordinated efforts across the EU and beyond with international partners to work on this.
#3 Entire lifecycle of on-premise digital products should be covered by cybersecurity requirements, while services require a different approach.
In the co-authored analytical report on policy gaps in ensuring ICT supply chain security (developed with a multistakeholder community within the Paris Call Working Group 6), we highlighted that “ensuring the security of ICT products and services is a continuous effort, throughout the deployment lifecycle, to protect customers and end-users”. This is hardly a finalized concept. And in this regard, we, in particular, agree with the Netherlands that the entire lifecycle should be covered in the CRA; i.e., “from the design phase up to and including its decommission and disposal”. But there are important nuances.
First: use, maintenance, decommission and disposal are not the same for products and services. In particular, digital services (e.g., in the context of cloud processing) are not on-premises solutions, meaning the customer or end-user doesn’t have complete local ownership of the data processed or the software and hardware being used. Second: most digital services cannot (except for specifically designed closed cloud-based networks) be fully autonomous – third-party access is a default feature, meaning that the manufacturer or supplier (such a third party) plays a part in ensuring security throughout the lifecycle.
This clearly leads to different contexts between products and services with different forms of relationships between manufacturers/suppliers and customers/end-users. For instance, vulnerability management requirements should in particular be differentiated between on-premises software and cloud services to reflect the different roles and responsibilities in this regard. With on-premises software, the customer or client knows best its infrastructure and has full control to define and inspect security requirements; this is why they would be primarily responsible for immediate patch management and for ensuring that all products in the perimeter run with up-to-date software or hardware. With cloud services, the context is different: it’s the owner of a cloud service that’s primarily responsible for effectively patching its services and mitigating any vulnerabilities – not the customer.
We hope that such different contexts, uses and forms of relationships will be considered in the future CRA to develop tailored cybersecurity requirements.
#4 Incentives for more security-orientated behavior should be provided for both the demand and supply side.
We applaud the Commission’s effort to equally address the lack of incentives as a prerequisite for greater security awareness from both consumers and manufacturers. In the Paris Call WG6 analytical report mentioned earlier, we developed both a detailed and structured list of key incentives to stimulate security-orientated behavior in the market. Economic incentives – which include pressure from customers/end-users, and peer pressure from and competition with other players – are only one of them. Even though the incentives could be market and sector-specific, government intervention seems to be much needed to address existing information asymmetry (we wrote about this in a previous blogpost) and lack of incentives.
So what can be done? Labelling, conformity assessments and certifications – all surely could be a part of the broader solution. Introducing voluntary labelling of digital products’ security is one of the regulatory practices that’s also being discussed by the OECD, Geneva Dialogue, and in the U.S. – where the President’s Executive Order has already prescribed steps on both IoT consumer product and cybersecurity software labeling programs. The U.S. NIST has even proposed draft baseline criteria for consumer software cybersecurity labeling, and developed four categories of attestations under which consumers can have more information about secure software development, data protection practices and more. In approaching this within the CRA, we believe some key factors should be considered:
- it is critical for the CRA as horizontal legislation to be harmonized and consistent with other legislation – the EU Cybersecurity Act, which has already mandated the creation of European cybersecurity certification. In defining cybersecurity requirements, the CRA should complement the Cybersecurity Act, not overlap.
- modern software products are multi-component, and in designing labels/conformity assessments, static criteria for dynamic consumer software will hardly work – for conformity therewith would be lagging fairly quickly. The focus, therefore, should be shifted from static evaluations to assessing processes and controls. For instance, instead of a security requirement for a software product formulated as “does not have vulnerabilities”, it would be better as “implements vulnerability management and disclosure controls”.
In a separate piece, we wrote further on the key factors for making consumer software labelling effective.
#5 The existing end-of-life (EOL) gap should be addressed.
Numerous expert discussions within the Geneva Dialogue, OECD and the Paris Call WG6 analytical report on policy gaps in ICT supply chain security have all highlighted the existing end-of-life (EOL) gap; i.e., the gap between the end of security support and the end of use.
For addressing the EOL gap, a tailored approach is again required for different products (software or hardware or IoT). Some ideas include: e.g., requiring supply-side actors to design and implement clear and transparent EOL policies for their digital products and services, and publicly stating the minimum length of time for which a product will be provided with security updates.
#6 International cooperation is key in avoiding fragmentation in emerging standards and requirements.
The Commission has announced its objective to develop cybersecurity standards as a step toward “boosting the EU’s leadership on standard setting by shaping standards for digital products and ancillary services that could serve as global benchmarks” in accordance with the EU Strategy for Standardization (February 2022). Given the large role that the EU plays globally in developing norms and pursuing values while approaching cybersecurity regulation, we urge to develop dialogue with other countries (their regulatory bodies), standardization bodies, industry and the technical community at large at the international level.
If the CRA establishes direct cybersecurity requirements for modern digital products and services, including IoT (until such are clearly excluded from the scope), there is no doubt that the EU’s legislation will impact the entire tech industry – affecting far more manufacturers beyond just those who are registered in the EU. That’s why it’s critical to ensure ongoing international dialogue to avoid fragmentation in emerging standards and requirements. Similar recommendations and messages have also been made by the OECD as one of the six high-level recommendations to policy-makers, as well as the Geneva Dialogue (during its online event together with the representatives of governments, industry, research and academic community).
Conclusion
Fully supporting the intentions of the European Commission to establish direct cybersecurity requirements for modern digital products and services, we’re eager to see if a single piece of legislation might be able to cover the whole set of such products and services (software, hardware, IoT, cloud services [for all: both industrial and consumer]). In any case, the initiation of wider industry discussion on the future CRA is a timely and much welcomed step from the regulator to bring greater security and safety to a rapidly digitalizing society.
