Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Categories
Articles

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 *