Computer Security: 20 years of securing controls (or trying to): mitigations

We've seen in the past two Bulletins that control system cybersecurity is the black sheep of IT, a hard-to-change tanker's course. Still, with significant daily damage of 250 000 USD for ALMA, the costs of falling to a cyberattack can no longer be ignored by any accelerator laboratory or experiment collaboration. A paradigm change has come about in the past decade - slowly, but constantly, and still too slowly compared to the speed with which information technologies advance and attackers adapt.

While a comprehensive guide to implementing and deploying a full-fledged, sophisticated and thorough cybersecurity programme is beyond the scope of this article, a series of first steps can be recommended:

• Obtain buy-in from management, who must actively and consciously acknowledge the risks of cyberattacks, analyse and prioritise the risks, sponsor their control and mitigation, and accept any residual risk.
• Get cybersecurity reviewed by a qualified third party, following good practices like the international ISO 27k standard, the NIST 800 special publication series, the German "BSI Grundschutz" handbook, the Trusted CI framework sponsored by the US National Science Foundation (NSF), or the more pragmatic and detailed CISv8 framework.
• Deploy multi-factor authentication as the silver bullet for all computing accounts, in particular those used to connect remotely from the internet and to connect to control and safety systems.
• Segregate networks with dedicated purposes for each: data centre services, control systems, campus devices. Control the cross-boundary traffic down to the level of serving and consuming IP addresses as well as used ports and services.
• Penetration-test all systems, whether externally purchased or internally developed, in order to find misconfigurations, weaknesses and vulnerabilities. Ideally, involve those penetration testers early on in the design and architecture phase.
• Control the CI/CD pipelines such that non-validated code is verified first (modern tools like GitLab or OpenStack come with supporting scanning tools like "Harbor", "Secret scanning", "SAST"). Apply screening of externally imported virtual machines, containers, software packages and libraries. Avoid the blind usage of PyPI and NPM; instead, put in place a software curation process.
• Have immutable back-ups of all data, installation and configuration files and the associated operating and built systems in order to re-establish the status quo from scratch (i.e. assuming that the entire IT infrastructure is broken). Test those back-ups on a regular basis.
• Train all experts, developers and operators to understand risks and mitigations, buy into enhanced security measures and help improve the security of their control systems.

In fact, CERN IT and OT (operational technology, i.e. our accelerator, experiment and infrastructure control and safety systems) already follow the guidelines above, implementing them as thoroughly and completely as possible. For a good reason: black swans.

The world lives in a symbiosis between control and IT systems, taking advantage of its benefits but also suffering from its drawbacks. Similarly, accelerator and large experimental physics control systems embrace modern IT technologies for more precise control loops and quicker processing, faster development and improved maintenance, and/or cost and resource savings. But that makes them susceptible to the common cybersecurity threats to which "normal" IT systems are subject, as devastating successful incidents in the past have shown.

Therefore, now more than ever, control system experts, developers and ultimately the people responsible for operating and running accelerator and experiment control systems must (start to) further invest in the cybersecurity of their installations, embrace good practices and standards, analyse the residual risks, and either sponsor their mitigation or consciously accept them. This is to avoid greater damage, as the question is not if they will fall to a cybersecurity attack but when. Do we want to act before or after such an incident?

This is an abridged version of an article that first appeared in the proceedings of the ICALEPCS 2025 conference.

________

Do you want to learn more about computer security incidents and issues at CERN? Follow our Monthly Report. For further information, questions or help, check our website or contact us at [email protected].