Remember the good old days of the Technical Network (TN), when CERN (accelerator) control systems were easily accessible from the Campus network? Unfortunately, those control systems were (and still are today!) using devices of the "Internet of Damn Insecure Stupid Things". External protections became necessary in 2005: enter TN v2.0. While this new protection brought us until today, the worlds of IT and control systems have changed drastically thanks to virtualisation, containers, big data, machine learning, artificial intelligence, large language models, etc. The TN v2.0 is not sufficiently protected anymore. CERN needs to evolve towards Technical Network v3.0. Have a read below.
TN v1.0 The Technical Network of the last millennium was simple. Initially managed by what is now the Accelerators and Technology sector (ATS), it was fully interconnected with the CERN Campus network (the General Purpose Network, or GPN, at the time) and the CERN data centres. Every single office PC could be interactively used to directly connect to controllers, front-ends, PLCs and any other accelerator device. Easy, convenient and insecure: an initial penetration test in 2005 on the "Teststand of Control System Security in CERN" (TOCSSIC) showed that many control systems were inherently unprotected, not up to date and lacked basic security features to protect their operations. We will discuss this "Internet of Damn Insecure Stupid Things" more in a future Bulletin article. The TN v1.0 could not be kept as it was. The risk of infecting control system devices and servers with viruses circulating among PCs and office systems was too great (the "Blaster" and "Slammer" worms just made their way through CERN infecting Windows PCs en masse). The "Computing and Networking Infrastructure for Controls" initiative (CNIC) was born. And with it TN v2.0.
TN v2.0 Following the CNIC policy initially approved by IT and the ATS in 2007 and its implementation by CERN's Network team, new capabilities for filtering between the Campus Network and the TN were introduced. Any GPN device that needed to communicate with the TN had to be explicitly declared to be "TN TRUSTED" before it could connect to the TN. And vice versa, any TN devices with communication partners on the GPN had to be marked "TN EXPOSED". Due to technical limitations, "TRUSTING/EXPOSING" were one-to-all relations. A "TRUSTED" or "EXPOSED" device could connect to anything on the TN and GPN, respectively. While this was suboptimal for security, the whole concept was a huge step forward in protecting the TN. In parallel, any TN device not linked to accelerator control systems or CERN's infrastructure was moved to a dedicated experiment network (or the GPN). Similar measures were deployed for the then-new LHC experiment networks and, later, for other experiments. This mechanism brought CERN securely through the 2000s, but the 2010s already showed that it did not scale properly and was not adapted to the evolution of conventional IT services like virtualisation, containerisation, big data, artificial intelligence, etc. - IT concepts that are now also of interest and use for control system deployments. In terms of networking and network security, this became a nightmare. Enter: TN v3.0.
TN v3.0 With modern control systems increasingly embracing these new IT concepts, the TN v2.0 "TRUSTED/EXPOSED" mechanism is no longer granular enough. Actually, the 2023 audit on cybersecurity requires CERN to "implement and enforce network filtering between CERN network segments", namely the TN, the data centre networks and the Campus network. It is also required to "complete the MFA [Multi-factor Authentication] rollout for all required users and use cases" as already discussed in our previous Bulletin article on "5 ways to remotely connect to CERN". Hence, in the course of Long Shutdown 3 (LS3), the TN-Campus network filtering will evolve from router-based ACL (Access Control Lists, the "TRUSTED/EXPOSED" rules) to firewall filtering with fine-grained granularity between clients and services (i.e. at the level of TCP and UDP protocols and port numbers). For this, every IT service hosted in the Meyrin or Prévessin data centres will identify their user- and client-facing servers and the corresponding network protocols used, and have those explicitly configured in the new TN firewall. Similarly, the ATS controls groups and experts will need to identify their corresponding clients that consume these IT services so that a communication envelope between services and clients can be spun up.
It is planned to introduce these new firewall rule sets during LS3 such that TN v3.0 is fully implemented by the end of LS3 and Run 4 will start with better protected accelerator operations. Also during LS3, the same firewall mechanism will be deployed to improve the separation between IT data centre services and the Campus network itself. Hence, stay tuned for some changes. And a big thank you to all those involved in helping to secure CERN, its accelerators and its operations!
