Privileged Access Management at CERN: Q&A with Dr. Stefan Lüders

February 22, 2022 8 minute read

In an era of increasing cyber attacks, how do you balance the desire for unrestricted research freedom against the need to protect that research from cyber threats? This is the challenge faced by CERN, leaders in the scientific research community. Their solution? Provide a clear articulation of what constitutes privileged data, and create flexible security policies that remove some of the usability barriers that are associated with higher levels of security. 

Established in 1954, CERN works to push “the frontiers of science and technology,” a mission that relies heavily on creativity, innovation, and collaboration. To support this mission, academic researchers are given the flexibility and freedom to work however they want. More than 15,000 users from over 70 countries join CERN either locally or remotely, resulting in more than 70% of BYOD on CERN’s network. As such, CERN acts like an ISP to them. 

CERN began working with Yubico in 2012, looking for a modern solution that would protect access to critical services by its most privileged users: those on the CERN Computer Security Team and the wider IT team. Today, CERN, benefitting from its central SSO, is widening the requirement for strong multi-factor authentication (MFA) for any user with access to critical control systems, IT system administrators, or people with access to sensitive data. They also have plans to further widen the roll-out to users across other teams as needed. 

CERN’s approach to security is highly dictated by its academic requirements, where traditional security rules and boundaries would sit at odds with the organization’s need for creative freedom. To explore this unique privileged access management challenge, we sat down with Dr. Stefan Lüders, Head of Computer Security at CERN, to discuss the evolution of cyber risk and security, the critical need to protect users requiring higher security access, and the challenges of balancing security in an environment designed to support academic freedom. 

What makes computer security challenging at CERN? 

How CERN does things is adapted to our particular environment. A top-down approach to security, such as one could take in other contexts, wouldn’t work here alone. So, we apply a combination of both. 

Part of CERN is like a university and has a large academic community: lots of researchers, students, PhDs, physicists, and engineers doing particle research. Lots of flexibility and freedom: it’s BYOD with large amounts of responsibility placed on the individual, so you can pretty much run anything you want (as long as it is legal, of course), program in anything, set up any environment. Flexibility begets creativity. You want to give creative minds the minimum number of boundaries and limitations possible. This side of CERN requires academic freedom and flexibility. 

On the other side of CERN is the industrial control systems, such as the particle accelerators, which require a different set of policies and processes – i.e. more aligned with industry requirements, albeit still in an academic environment. The particle accelerators are unique and, hence, are all prototypes. Consequently, they are being improved upon on a continuous basis. This kind of agile engineering requires a stringent yet flexible approach to security. 

In the past five years, the volume of cyber attacks and the cost of data breaches have continued to rise, despite significant investment in cyber security. How have you personally seen security needs evolve? 

Security used to be a marathon, but now security is a triathlon. It’s getting ever more challenging. The risk of a secured intrusion is proportionate to the threats multiplied by the vulnerabilities multiplied by the consequences. At CERN, we believe it’s important to deeply understand the consequences of a breach – and the consequences have remained similar over the years and seem well controlled. However, the threat scene is going in the inverse: it’s exponential. Today’s surge of ransomware attacks and malware around the globe across industries, particularly healthcare, energy, government, and universities, are not going away and are becoming worse. 

The same holds true for vulnerabilities. In the past, I was running a computer center with some hardware (and its BIOS), an operating system, and an application on top – three layers to protect. Now, a computer center still has the hardware to protect, but also has a hypervisor layer running multiple virtual machines, which in turn host containers, and then the applications. There are more layers to protect today. More complexity. More vulnerabilities. 

Given that rise in vulnerabilities and threats, how do you approach cyber security at CERN? Do you pay attention to the rising number of attacks? 

The notion of what constitutes an “attack” is badly defined. Counting apples, we can agree what an apple is; and so we can count them. But what is an attack? Is it one log-in attempt with the wrong password? Is it brute forcing all user accounts? I don’t look at the count of attacks. We look at vectors, occurrences, types, and improve our defenses accordingly. 

It’s like the pandemic: you, as a human being, are subject to viruses all of the time, so your body is under permanent attack. But nonetheless you continue going about your day-to-day life, going to the tram and the supermarket, hoping your immune system is able to protect you. This is what we are doing at CERN: putting our defenses up so that, in principle, everything is getting blocked by our firewall, which we monitor. As long as these attacks do not become an intrusion – a fever, in our immune system analogy – we are ok. We observe and monitor the attacks, but we’re more interested in preventing successful attacks. 

For many organizations, COVID-19 had a significant impact on organizational culture and employee behavior, with remote work creating potential gaps in cyber security and controls. How did the pandemic impact how CERN secures its users? 

CERN went into the pandemic with a huge existing remote working community, so the bulk of the required infrastructure was already in place. The only thing that needed to be enhanced was to scale up the remote gateways to enable more people to connect to CERN simultaneously. The only other particular issue we faced was with our licenses, as most of the third-party software we use was geographically licensed to the CERN site, so needed to be renegotiated with the license holders to enable staff to use it remotely. 

Endpoint management is one task that has also had to be managed differently due to the pandemic. This can be especially tricky when it comes to BYOD. If the computer is compromised, I will only notice this when the account is compromised and using resources within CERN. This is where multi-factor authentication comes in, as one way to help protect account security.

What is the strategy for privileged access control at CERN? 

In the past, our strategy was to protect critical services with MFA, including using YubiKeys. As long as you were doing basic things, you could use your password. When you log into a critical service, you are required to utilize  your second factor. 

To help scale, instead of talking to critical services, we now speak to critical users. Critical users now leverage CERN’s central SSO portal to log on at least once a day with a second factor. This way the application sphere has been decoupled from the login sphere to ensure the greatest flexibility and usability for the end-user. We also allow users to use the YubiKey to secure their personal accounts (using its second OTP slot). 

In security, holistic or global controls always create problems. There are always exceptions, and exceptions kill cyber security. You have to use a piecemeal approach. We started with YubiKeys for the Computer Security team, then we rolled it out to the IT department for administering computer centers, and now it is also for those accessing control systems remotely. 

Privilege is defined more by function at CERN – it’s not dependent on the people, but about what they need access to. If you are an administrator of a computer service, you are subject to MFA. If you are an operator of an industrial installation, you’re subject to MFA. Next, we’re looking to extend MFA to other communities such as procurement, management, and secretariats. In each step, we extend control to cover more corners. 

———

To learn more about how to define and secure privileged access, read our whitepaper, “The critical strong authentication need for privileged users: why legacy authentication is putting your privileged users at risk.

Share this article:

Recommended content

Thumbnail
Thumbnail
Thumbnail
Thumbnail