Before Trusted CI, much of the NSF community assumed cybersecurity was a barrier to the mission of science. Scientists are used to managing risks to their research – bias, data corruption, instrument failure, etc. – but the connection between computer attacks and these risks was ambiguous. Trusted CI’s flexible approach balances baseline practices with risk management and emphasizes the mission of scientific research. Science and security are not mutually exclusive, and this perspective helps the community move project practices from avoiding cybersecurity to embracing it. As the NSF Cybersecurity Center of Excellence, Trusted CI continues to develop the understanding of how cybersecurity can be a supportive, enabling tool for productive, trustworthy research.

What is Trusted CI? What sets it apart from other cybersecurity initiatives?

Trusted CI – originally known as the Center for Trustworthy Scientific Cyberinfrastructure (CTSC) – has now been around for a little over 5 years. It was established with a $4.297 million grant from the National Science Foundation (NSF) to help build community around producing trustworthy computational science. The NSF funds over $7 billion dollars of research every year, spread over 11,000 different projects. Making sure that all this scientific research is happening in a manner that is secure and trustworthy, which are the foundations to reproducible science, is a key concern.

But it’s easy to come down and do really onerous, heavyweight cybersecurity – to lock down the computers so much that they’re secure and absolutely no science is getting done. Trusted CI originally started working with individual science projects and building a community – hosting an annual conference, inviting people to come together, giving talks, and raising awareness. Then we started to produce cybersecurity practices that would manage risks to science but with enough flexibility that different projects (everything from neutrino sensors under the ice to telescopes on top of mountains) could adapt them while maintaining science productivity.

Why don’t off-the-shelf enterprise IT solutions work in this situation?

Most of enterprise IT tends to be desktop machines or server machines in a typical office environment with typical office applications. But if you take the checklist that works for that and start applying it to the computer that runs a telescope or the computers sharing the data that’s coming out of CERN …Those types of huge data flows and large-scale collaborations would be one of the first things that break when you start talking about standard firewall (security) setups.

How does good cybersecurity boost science?

Our real concerns are: 1) If someone calls scientists onto the carpet and says ‘Hey your data has been tampered with,’ you want to be able to come back with “No, I don’t believe that’s true, and here are all the steps we take to make sure it hasn’t.” Imagine somebody calling a climate scientist and saying this data is all nonsense, making claims like “We hacked into that ten years ago and we’ve been manipulating your data for the last 10 years.” Now you’re left disproving a negative. If you don’t have a program like this in place, then you’re just in the muck of finger pointing.

The other thing we want to do is prevent a perceived vacuum in cybersecurity from spurring a really onerous program. You see some of this right now in Congress. They’re concerned about theft of intellectual property in the pre-patent stage or in an early research stage that might become classified down the road. And they may come in and impose one of these more onerous, heavyweight structured cybersecurity programs on the NSF scientific community, and say, ‘We don’t care if you’re doing genomics or physics or chemistry, you’re all going to take a one-size-fits-all cybersecurity program.’ It would just kill productivity.

These are the two things you’re always trying to balance – the risks versus your mission. Without understanding how the risks and mission relate, it’s easy to overemphasize risk eradication. You’ve got to balance safety with the productivity of the science mission. We want to make sure the community has a solid program in place, so someone doesn’t get fearful and come in and try to force something upon them.

Why is trust important?

So much of science is collaborative these days. The physics communities studying gravity waves and new particles are leaders in this. I forget how many hundred plus institutions are involved in the LHC. These institutions need to collaborate; they’re giving each other access to each other’s computers. Having these baseline cybersecurity programs in place means you can look at each other and go, okay, I don’t know all the ins and outs of your university. But I know you’re at least putting some baseline practices in place, and I can have some good marginal trust. We go a long way in establishing collaboration around that.

What can a potential Trusted CI collaborator expect?

The first thing we tell folks is we’re always open for brief consultations. If you’ve got a question or you just want to spend an hour on the phone with a cybersecurity expert, then drop us an email. A lot of effective work happens that way. People often need a quick sanity check or to know what’s normal.

Others come to us with a hairier issue or an existing program where they want somebody to come through and tell them if they’ve missed anything. That’s what we would call an engagement. We get more of those requests than we have time for, unfortunately – so we evaluate them based on the skills we think they’re going to take, the science they’re going to do, how ready they really are to work with us. Every six months we pick the ones we’re going to work with, and then we have a team that goes and works with them.

We really say, if it’s related to cybersecurity we’ll take it on. We’ve done everything from working with a group in the city of Chicago on privacy issues around their sensors (Array of Things), to a software group trying to figure out how to run this particular weird scenario on clusters that don’t run a grid software stack so we have no way of doing delegation. We worked with them to come up with the best answer that balances risk and productivity.

How does a longer Trusted CI engagement unfold?

We’ll spend about six months working with them. We expect them to be collaborative. Usually we’re spending a fair amount of the time in the beginning saying describe your problem to us – What are your use cases? Walk us through what you’re trying to do. Who are your stakeholders? Who has to be satisfied with this answer? We’ll go talk to different people in the organization. We’ll make calls. Then we sit down and perform analysis, and we’ll come up with our report.

This is not a situation where they throw a security problem over the wall to us, we fix it and deliver it to them on a silver platter. At the end of that six months, the solution needs to be sustainable. They’re going to have to take whatever we’ve given them and maintain it. What we’re really trying to do is teach everybody to fish.

What resources do you provide for the larger NSF community?

We have a couple sets of guidelines out there right now. Our most used is what we call our Cybersecurity Practice Guidelines – we just call it the Guide internally. The cybersecurity community uses a lot of scare tactics. One of the things we found working with projects early on was communities out there were already nervous about cybersecurity and what could be going wrong. They just didn’t know what to do about it.

The Guide walks you through the basic process of starting a cybersecurity program – little things like you need to designate somebody as the person responsible, and they’re going to need a budget to hire some people to give some guidance. If you have an IT budget, you’re probably looking at 5 percent of that to start with.

What are the basics of starting a cybersecurity program?

Some people just pick up the Guide and start working, in which case we’re happy to have a couple phone calls and walk through it. But mostly we’ve empowered them to do that on their own. The first thing they’re going to do is create a master information policy, which lists everything they have: What’s the acceptable use? What can you use our infrastructure for? Can you use our computers to mine bitcoin? Then, What are our key risks? Just figuring out really basic questions and walking them through things.

Then we get them to the point of “Now we’ve got the basics done, what do we do about this computer on a telescope over here? We’re constantly told we have to keep its patches up to date.” Well, it’s running a version of Solaris that’s now ten years old that hasn’t had a patch put out for, you know, nine years. So how are we supposed to keep this thing secure? We can’t change it because that’s the only computer that can run this telescope. They’re in these situations that you can’t just yell at them for – so it’s a process of walking them through developing a program, documenting how you keep things up to date and what’s the process.

Once a year you have to revisit this. The Guide basically provides them with a series of templates, so you can take somebody who knows the project relatively well but is not a cybersecurity expert and walk them through the process. Really what we are doing is building up cybersecurity expertise in the community through our guides. It becomes kind of a training program in the form of a set of templates and documented how-tos.

For more on Trusted CI, visit trustedci.org.

Von Welch is director and PI of Trusted CI, as well as the director of Indiana University’s Center for Applied Cybersecurity Research (CACR).