Apart from the purely cyber aspect, the Crowdstrike case is a warning light on the risks of the EU approach to cybersecurity management by Andrea Monti – Adjunct Professor of Digital Law – University of Chieti-Pescara – Intitialli published in Italia by Formiche.net
In these hours, public facilities, banks, hospitals, transport systems, and broadcasting stations halfway around the world are struggling to resume their operations, which were blocked not by a large-scale attack by hostile actors or criminal groups , but by a programming error contained in a software update for the Microsoft Windows operating system, carried by a cybersecurity multinational, Crowdstrike, in all infrastructures using the local component of the platform called Crowdstrike Falcon.
To summarise, this approach to cybersecurity management involves installing a software component on each individual computer to be protected, which then interacts with the vendor’s centralised platform, which is also used to convey local updates. It was precisely a flaw in one of these updates that caused the computers on which the local component of the security system was installed to crash.
The update spread like a virus, thus paralysing even the essential services using the platform in question.
This case provides insights on several levels, from the strictly legal ones, to those related to the strategic choices of EU decision-makers on cybersecurity, and their effects on the service models of information systems security management.
Liability for damage caused by defective software
The most immediate aspect that springs to mind is that of the compensability of damage caused by defective software.
Although the Civil Code already establishes a general obligation to compensate for damage caused unjustly, and software development activities and the provision of IT services are subject to the rules of contractual liability, in practice this compensation is difficult to obtain.
The reasons are diverse and complex, but can be summarised in the difficulty of identifying – even if this is not the case – the actual liability of the software producer, in the difficulty to prove the link between defect and damage, and, above all, in the ability to deal with litigation based on US contractual law, which admits broad limitations of liability, to the point that any judicial success could turn out to be a Pyrrhic victory.
Criticisms of the EU approach based on user liability
This state of affairs, which has persisted as it is since the dawn of information technology, has always been far from the attention of European decision-makers, who have chosen to make the users of software tools accountable but not those who produce them.
The paradigmatic case is the data protection regulation (but also the complex European legislation on critical infrastructures), whose system of compliance with security requirements is conceived precisely in this way.
On paper, the general preventive approach based on risk analysis that characterises these areas across the board should be able to prevent such events. In the specific case of this incident, one can even go so far as to assume a prevailing liability of the user over that of the manufacturer, because it is a recognised best practice to carry out checks on each new software update to be installed before actually proceeding.
Therefore, entering into the technical-legal aspects, one would have to verify the apportionment of liability between the dissemination of the defective update and the failure to check its potential dangerousness; and it is quite possible that the supervisory authorities may penalise the supervised entities precisely for not having performed these preliminary checks.
The point is, however, that in practice these checks are difficult to demand, especially when we are talking about complex or critical technological infrastructures, where security must be guaranteed in near real time. Which means, on the part of the recipients of the standards, favouring cybersecurity management models based on outsourcing at the expense of direct and immediate control entrusted to an internal structure.
Here again, the difference between theory and practice is significant, but the point remains that a model based on outsourcing to a single provider and on the automation of cybersecurity activities has as a major drawback precisely that of the chain reaction that then, in the event of an incident, results in a catastrophe.
The EU bureaucratisation of cybersecurity
This drive towards decentralisation has been accelerated by the amount of red tape imposed by EU legislation.
If we add to the regulations already mentioned, just to name a few, the regulation on operational resilience (DORA), the regulation on AI, the future regulation on cyber resilience, and the security aspects of EIDAS2 , it is not difficult to realise the sheer volume of tasks to be fulfilled, which leads to the inevitable tendency to favour purely formal compliance and to offload tasks (but not responsibilities) onto external providers, preferably non-EU ones and as such less reachable by national authorities.
This leads to the creation, if not of an oligopoly, of a market in which the supply is composed of a limited number of players. The consequence is that if one of these collapses, it drags behind it a huge number of infrastructures, creating potentially exacerbating problems for the entire country system.
The interdependence of electronic communication systems and networks
The issue of the concentration of cybersecurity services in the hands of a limited number of players also recurs in the area of physical, mobile and satellite communication networks. A market composed of a limited number of players amplifies the consequences of attacks directed at a single infrastructure, or of internal malfunctions or malfunctions caused, again, by an element of the supply chain that enables the provision of services, or by a technology and software provider.
Here again, therefore, a strategic choice that limits the possibilities of technological diversification and pushes towards exasperated standardisation would require careful consideration.
Conclusions
The Crowdstrike case clearly highlights the need, on the one hand, to foresee precise responsibilities for cybersecurity providers, but on the other hand, the importance of returning to a cybersecurity management model that is less based on formal aspects and more oriented towards activity in the field.
This would be possible by creating a regulatory framework that simplifies purely bureaucratic requirements, for instance by unifying them, that facilitates the development of independent research into software and system vulnerabilities, and that thus encourages software houses to improve their products in the knowledge that they are under the control of the cybersecurity community, according to a model that has long been tried and tested in the US.