The TN (Technical Network) v3.0 (see our previous article) is a necessary step forward in properly and thoroughly securing the control systems used at CERN for accelerator operation and facility management and for running our (digital) infrastructure of lifts, electricity, cooling and ventilation, heating, site security, etc. But why "necessary"? Here are some examples of the Internet of Damn Insecure Stupid Things that were deployed (or intended to be) at CERN. Be prepared to shake your head.
The mess already started decades ago. Nice, useful gadgets, controllers, the Internet of Things, with brilliant and sophisticated functionalities but lacking any security protections. Early in 2005 the "Teststand On Control System Security In CERN" (TOCSSIC) vulnerability tests revealed hundreds of devices ignoring basic security principles, devices that crashed when sent non-conform, malformed or simply-too-big network packets, or devices that lacked any authentication mechanism and allowed anyone with direct access to manipulate the system. This triggered the creation later that year of TN v2.0.
But not much has changed today. Take, for example, CCTV cameras for site security and surveillance. CERN employs about six different brands from major manufacturers. Earlier this year, an EPFL student dissected those cameras and analysed their network traffic with the central monitoring system for a master's thesis. Given that these are professional systems, you would expect top-notch security on par with that - say - of your smartphone connecting to the Google or Apple cloud.
After carrying out the tedious work of removing the conformal coating* from the camera's embedded chips, unsoldering the chip from the motherboard and analysing its firmware, that student figured out the master password of at least four camera types - either in plain text or using outdated and easy-to decipher "hashing" algorithms (i.e. MD5). The password to access them remotely, modify their settings and watch their footage. While smartphones (and modern laptops) store all security-relevant information in a Trusted Platform Module (TPM) - a specially protected chip on their motherboard - these four camera models used at CERN did not. Professional physical security cameras without any best cybersecurity practices implemented. And there is nothing that CERN can do (except for moving them all into a dedicated and separately protected virtual network segment). Face palm ☹
And those cameras don't even use the cloud. But lots of embedded devices today do require cloud access, cloud control, and the possibility to "phone home" to "their" cloud, with all the weaknesses that cloud computing entails. Here are two examples that CERN intended to purchase recently: "smart" lockers and defibrillators, both of which require cloud integration.
- The "smart" lockers were intended to store people's belongings (backpack, laptop, etc.) while they were in CERN's library or restaurant. To open such a locker, you would need to scan a locker-specific QR code that is transmitted to the locker via their cloud. Unfortunately, that network transmission goes completely unencrypted and, with it, the master password for their cloud configuration. And not only CERN's master password, but that of any company using that "smart" product. Naturally, CERN did not purchase the lockers. Instead, it opted for lockers requiring a 4-to-8-digit code like hotel safes.
- Similarly with the next-generation defibrillators, which are cloud-connected so that they can perform remote configuration, monitoring and maintenance. Too bad that their web interface got the implementation of authentication and authorisation completely wrong and gave CERN's penetration testers access to all the defibrillators ever sold by that company. A no-go - and no-buy − of course. Good defibrillators should remain stand-alone and disconnected!
To protect against such blunders, the Computer Security team reviews any new or significantly modified project involving IT hardware and/or software. Actually, and "ideally already during their design, architecture or development phase, all High-Risk Applications/IT Services/Projects with a software component that are due to be deployed or are already running at CERN must be subject to a computer security review conducted by the Computer Security Office. Only those with a positive review outcome are permitted to proceed to deployment or to continue operating", as stipulated by two Subsidiary Rules to CERN's Computing Rules. In addition, the Office contracted and will contract again in the future external companies to proactively scan CERN's internet presence for vulnerabilities and blunders that could give attacking evildoers an advantage. A new batch of findings is expected to be reported soon - we wait with bated breath for more blunders.
If you are interested in an annual summary of all this "Abuse, Blunder and Fun", look out for our end-of-year presentation, usually held on one of the last Fridays before the annual closure. See you there for more face palms on the stupidity of things.
* This coating protects the motherboard against wear and other environmental impact. In other cases, like for some access card readers, epoxy is used.
