UCSF CIO Discusses Network Security for University Campuses

April 28, 2004

It's one thing to talk about improving network security, but it's another to actually do it. As campus chief information officer for the University of California, San Francisco, Ken Orgill understands that difference all too well. These days most network administrators are struggling to balance security with accessibility. After all, the greatest advantages of data networking come from its ability to connect people across geographies. But today's security concerns have ended the days of innocence for universities. Years ago, few campus network administrators worried about security, but the new breed of viruses and worms do not play favorites. They are just as happy to run wild on campus as in corporations.

Orgill recently spoke with News@Cisco about the particular challenges of boosting security on a major university campus. He also will be a featured speaker at the second annual Information Technology Security Conference presented by Cisco in partnership with The California State University and The University of California, held at the San Francisco Hyatt Regency April 27-30.

What is it about university networks that makes them so difficult to protect?

Ken Orgill: Historically, university networks have been extremely open. Networks are often viewed as a sort of greater good and a public asset that should be freely available to anyone who needs to communicate. Researchers need to provide high-level access to their research data and to freely collaborate with their peers around the world. They don't want barriers that might in some way inhibit that collaboration. And so each department within a university has been left in charge of the administration of their own computers. The problem with that setup these days is that these departmental networks are connected to the campus backbone and can infect each other. Basically there are a lot of open doors flapping in the wind and it's hard to get people to close them. The tradition of open networks now permeates not just high-level researchers but most of the university culture. So it's a bit of an understatement to say universities have had a tough time coming to terms with the idea of network security. There's even still some belief in the university community that security isn't that important, although that percentage of thought is shrinking rapidly with each passing attach and virus infection.

Keeping networks open is crucial to the effective use of data networking, so how do you make your case for security to the university community?

Ken Orgill: Security, done right, is about preserving use of the network rather than taking away people's access to it. In the past, malicious programs didn't widely exist. It was a more genteel time and the computing community was much smaller, with a higher level of respect. Certainly, there was some hacking that occurred but the new-generation virus programs didn't exist. Now, in some instances, one infected user can bring the entire network down. Also, unprotected research files can be destroyed and important services severely impacted. This has produced some very serious situations. At UCSF, our campus network is connected to the medical center network. While at the moment the medical center network is better protected, a virus coming from the university network can "backdoor" the medical center network, affecting admissions systems, access to e-records, and a whole host of other critical applications and data. This is an issue that simply doesn't have room for philosophical debate. The medical center services must be protected.

It sounds like you have quite a challenge on your hands for implementing security. What approach are you taking to boost security?

Ken Orgill: Well, first of all, any changes that happen will only take place over the long term. Given the culture of our computer users and the design of the network, we cannot pull off the "big bang" approach to security upgrades as many companies can. Since I'm relatively new to the post and security became a major priority just as I joined the university, we are pretty much starting from scratch. When I arrived at the university, there was little focus on security. But to be fair, the university had never had a major security incident. Soon after I arrived, we were hit by the Slammer virus. It devastated our network, requiring 50 staff members working frantically to bring the network back on line over the weekend. After that it was clear to everyone that we needed to focus on security and improve our sophistication about protecting the network. It also became clear we were understaffed in achieving these objectives. We've begun to build a robust information security organization. In fact, last week Carl Tianen, the former information security officer of Levi Strauss Inc., started work as the UCSF ISO, a new position for us.

In terms of tactics, our approach, like most companies, is creating layers of security defense. We've been able to firewall our main data center, and our next step is to firewall the campus, in order to set up a basic perimeter and some control. After that, we're going in several directions to create other security layers. We are encouraging departments, with our assistance, to firewall important servers. Within a year or so we are hoping to gain some synergy around requiring personal firewalls on every desktop, along with anti-viral software, which most have now. The issue in a university environment in this regard is accountability. We must build in accountability as we institute policies. As another layer of protection independent of policies related to our end-users, we're also looking at intrusion detection and intrusion prevention systems.

Besides the capabilities you are now looking into, what other types of security capabilities would you like to be able to deploy on your network?

Ken Orgill: Well, again, the big issue for us is that at the moment we have a highly distributed network design as well as a highly decentralized management infrastructure. This has resulted in a lack of granularity to identify exactly where infected machines are. We end up cutting off whole subnets sometimes, affecting many users. Ideally we need a tool to automatically quarantine infected machines. Manually shutting down machines during a virus outbreak is incredibly resource intensive.

The light at the end of the tunnel is the new, state-of-art network we are deploying. It will go live next year and will have advanced security features built into it. Coinciding with that, new network users will need to agree to a set of security policies and practices and be accountable for their actions or lack of action. The network and new user policies will help, but we still have a long road ahead of us.