One size does not fit all

One size doesn't necessarily fit all, and under certain circumstances, Fermilab cybersecurity allows use of security controls that are different from the baseline standards. Photo: jessamyn west

One size doesn’t necessarily fit all, and under certain circumstances, Fermilab cybersecurity allows use of security controls that are different from the baseline standards. Photo: jessamyn west

Sometimes it seems like the security team members are the bad guys, telling users only what they are not allowed to do. But remember, our primary objective is to enable the laboratory to continue to carry out its scientific mission without interruptions. Imagine the cost to our scientific program if we were forced to turn off our Internet connection while we repaired and recovered from damage caused by computer hackers.

An important tool in accomplishing this mission is to provide policies, procedures and guidelines for operating lab computing systems in a secure manner to avoid interruptions caused by attacks by unauthorized users.

Consequently, we have rules in place designed to provide protection, but very few of these rules are absolute. There is a wide variety of ways to protect computing systems. And while we don’t want everyone to choose his or her own protection methods independently, we also do not want to arbitrarily impose a one-size-fits-all policy. Sometimes having computers behind locked doors is the best solution; sometimes active surveillance is appropriate; sometimes automated detection and countermeasures are needed; and sometimes for our most sensitive systems we may require even more stringent controls.

Thus it makes sense for us to have a formal process in place that allows individuals (or groups of users with similar concerns) to request allowance to use security controls that are different from the usual baseline standards. This process is called requesting a variance, and, of course, it has constraints. First, the variance must be fully documented and archived so we can demonstrate to external auditors which systems have been granted variances and why. Next, the requestor must demonstrate a clear scientific or business need explaining why the standard solution significantly interferes with their mission. Finally, the requestor must offer and implement a set of compensatory security controls that provide (in the judgement of the security team, who will review the request) at least that same level of security as is provided by the baseline controls.

An instance in which this process has been used in the past is the requirement to update the operating system kernel of Linux systems by regularly scheduled dates. This is important to prevent security vulnerabilities in older versions from being exploited. But for systems that were part of the CDF and DZero data acquisition systems, making the computers unavailable while updating the kernels, even for short periods of time, would interfere with data taking and compromise the scientific mission. The managers of these systems applied for and were granted a variance allowing them to defer the kernel updates for up to six months, until there was an experiment downtime. Additional security was provided by restrictions on how these systems could be accessed, keeping them inaccessible to an Internet hacker.

If you need to request a variance, you can do this by submitting a Service Now general request (there are standard Service Now forms for the most common cases). Not all requests can be granted, and in that case you will need to consider a slightly different way of accomplishing your objective. But one way or another, we will work with you to make sure the scientific mission is not impeded.