Europe Wants Patches

The Proposal for a Regulation on Cybersecurity Requirements, recently published by the European Commission, significantly raises the profile of software vulnerabilities and processes for dealing with them after a product is delivered. The Regulation on Digital Resilience in the Financial Sector (DORA), proposed in 2020 and likely to become law shortly, does require organisations to “have appropriate and comprehensive policies for patches and updates” (Art.8(4)(f)). But that’s limited to the financial sector.

The new proposal covers all manufacturers/vendors of software that is capable of being “connected” to anything else “via hardware interfaces … network sockets, pipes, files, application programming interfaces or any other types of software interface” (Recital 7), with only a very limited exemption if software is not “supplied in the course of a commercial activity” (Recital 23). Criticality of software or application doesn’t change the requirements (it does make a difference to how compliance needs to be demonstrated – see Annex III), because “even hardware and software considered as less critical can facilitate the initial compromise of a device or network, enabling malicious actors to gain privileged access to a system or move laterally across systems” (Recital 7).

The requirement that all such products be “designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity” (Annex I 1(1)) is an obvious read-across from existing laws on physical product quality and safety. Annex I 1(3) provides an extensive list of cybersecurity issues that should be considered in design: secure by default, access controls, data confidentiality/integrity, logs, etc. And “Products with digital elements shall be delivered without any known exploitable vulnerabilities” (Annex I 1(2)).

What’s new is the recognition that a digital product – and its manufacturer’s responsibility – isn’t finished when it is delivered to the customer. The last bullet of Annex I 1 introduces an obligation to: “ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates and the notification of available updates to users”. And there follows a lot more detail in Annex I 2 (my summaries):

  1. Provide a Software Bill of Materials (SBoM) listing third-party components
  2. Address and remediate vulnerabilities without delay, including by providing security updates
  3. Regular tests and reviews of product security
  4. Public disclosure of information about fixed vulnerabilities, including impact, severity and how to remediate
  5. Coordinated Vulnerability Disclosure (CVD) policy
  6. Contact details for reporting vulnerabilities
  7. Mechanisms for secure distribution of updates
  8. Dissemination “free and without charge” of patches and information about mitigation

That’s a pretty state-of-the-art vulnerability handling process! And, according to Article 10(6), it must be maintained for at least five years or, if shorter, the expected product lifetime. Some software producers may already meet the requirements, but many will need to improve.

Once the law is passed – which could take a while – manufacturers will have two years to comply, so there won’t a sudden improvement in the availability of patches. But it’s a striking statement of what European legislators feel is needed to secure the digital society.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *