Given the sophistication of Stuxnet, it might have been hard to detect such a targeted attack against CERN, if at all. But this is not the point. There are much simpler risks for our accelerator complex and infrastructure. And, while “‘computer security’ is [indeed] not the raison d' être”, it is our collective responsibility to keep this risk at bay.

 

Examples? Just think of a simple computer virus infecting Windows-based control PCs connected to the accelerator network (the Technical Network, “TN”) and disrupting their functioning. Windows-based control PCs are rather susceptible as they cannot be patched as timely as office computers - neither at CERN nor in industry. Taking advantage of this window of opportunity, the virus might have come via a compromised development PC connected to the office network; shipped in via a new, but already compromized Supervisory Control And Data Acquisition (SCADA) terminal by a third party control system provider; or it might have been introduced by a maintenance laptop connected temporarily to the TN…

 

Another example would be an account name/password combination for accessing critical accelerator control systems. This combination was accidentally disclosed on one of our public websites. Spotted by an attacker, it could have been misused to manipulate the system in an adverse way. A final example would be malicious code, introduced by an attacker on a Linux-based control PC with a connection to the TN. As the attacker would not know where they “are”, they would run this code to scan the network. This introduces network delays, and stops other control systems from working correctly.

 

Impossible? Not at all. Harmless variations of these examples have been seen at CERN recently! If they had been serious, they might have brought months of downtime to our physics programme. Fortunately, they have had zero impact so far.

 

Will this last? “Computer Security” must become another important ingredient in the accelerator complex (like “functionality”, “availability”, “usability”, “maintainability”; read our article “A Short Tale of the Black Sheep of –ITY”). In 2004, the CERN Management mandated a strategic working group, the CNIC (Computing and Networking Infrastructure for Controls), to improve the cyber-security of CERN’s control system. This group brought together representatives from all the LHC experiments, the technical and accelerator sectors as well as the IT Department and the Computer Security Team. The result was the separation of the office network from the TN, the switch from individual office PCs to Windows Terminal Servers and virtual machines for developing controls applications, the introduction of a Windows installation scheme for control PCs (“CMF”, subsequently used throughout CERN), and the prohibition of USB sticks, laptops and wireless devices on the TN. Unfortunately, those measures had to be deployed in an existing operational environment and, thus, had to cope with a multitude of boundary conditions, exceptions and workarounds. Therefore, none of those measures are perfect and some impact heavily on usability and convenience, particularly for people developing and maintaining accelerator control systems.

 

Give us your feedback! With the Long Shutdown 1 now underway, we should work together to see how to improve your situation, while maintaining an acceptable high level of “security”.

 

Join the CNIC users exchange or send an e-mail to the Technical-Network.Administrator@cern.ch. If you are running control systems, check out the CNIC control system security policy: Is your configuration safe? Do you have proper access control? Do you patch in a timely manner? Do you know “security”?

 

For further information, please check our website or contact us at Computer.Security@cern.ch.