Thoughts on SANS .edu Security Debate

The 10 August 2005 issue of the SANS NewsBites newsletter featured this comment by John Pescatore:

"There has [sic] been a flood of universities acknowledging data compromises and .edu domains are one of the largest sources of computers compromised with malicious software. While the amount of attention universities pay to security has been rising in the past few years, it has mostly been to react to potential lawsuits do [sic] to illegal file sharing and the like - universities need to pay way more attention to how their own sys admins manage their own servers."

I agree with John's assessment, except for the last phrase that implies university sys admins "need to pay way more attention" to security. From my own view of the world, a lot of university system administrators read TaoSecurity Blog, attend my classes (especially USENIX), and read my books. I believe the fault lies with professors and university management who generally do not care about security and are unwilling to devote the will and resources to properly secure .edu networks.

The 17 August 2005 newsletter features a letter to the editor signed by eleven .edu security analysts. They take exception with Mr. Pescatore's comments. SANS is requesting comments on that letter. Here is my take on a few excerpts.

The letter states:

"Many of these schools are complex and most security implementations typically used at a corporate or government level don't fit a university model because a broader range of network activities is permitted on university networks, in large part due to a much more limited set of policies and controls compared to government and commercial entities."

The "broader range of network activities" is part of the problem. Most .edu networks apply very little inbound access control and hardly any outbound access control. (Sometimes that is reversed; one .edu I worked with implemented zero inbound control and single outbound control denying TFTP!)

Do .edu networks think the corporate world does not support a wide variety of protocols and services? I recently finished a traffic threat assessment for a client. I was surprised to see the number of protocols in use that I did not immediately recognize. This is no different from a .edu, except the .com had taken steps to restrict use of those protocols and services to defined partners. "I can't define who will access my data," a .edu might reply. If that is the case, the .edu has decided that anyone in the world can access potentially sensitive data. (See the section below on the "tenth planet" to read consequences of that stance.) In reality, the .edu is saying "it's too difficult" to define who should access data. That's a cop-out.

The "limited set of policies and controls" is not the fault of the administrators. It is the fault of management who refuse to reign in professors, or to force them to accept responsibility for operating insecure systems. If a professor is a prolific researcher, he or she is often given a "pass" to run whatever infrastructure he or she needs for research purposes. While research is obviously important, the professors and staff should realize that lack of security jeopardizes their research. How would they feel to know that a team of competing researchers, or even corporate spies, were stealing the next breakthrough in gene therapy from research systems?

We already know that so-called "tenth planet" discoverer Michael Brown was forced to rush his announcement for fear that "hackers" would reveal his work. I heard Mr. (Dr.?) Brown on NPR science Friday a few weeks ago, and he confirmed the story. He and his colleagues preferred to give an orderly press conference to inform the world of their discovery. Instead, Mr. Brown decided to rush the process. He feared a "hacker" would provide information on how to find the tenth planet to amateur astronomers, who might then take credit for its discovery! Security is not an inconvenience; it's a necessity.

The letter continues:

"Many times, the tools to secure these environments don't exist and changing the culture in these heterogeneous environments to one which promotes secure computing is very difficult."

Actually, all of the tools to secure a .edu exist. Almost all of them exist in open source form, too. Ten years ago this might not have been the case, but today one can employ open source countermeasures that in some cases exceed their commercial counterparts. The array of network-centric security capabilities offered by OpenBSD , for example, is amazing. Firewall? Pf. VPN? IPSec. Secure remote access? OpenSSH. Centralized time synchronization? OpenNTPD. I could continue at the host level if one needed a reliable platform for hosting Web sites, handling email, etc.

The tools exist, but the managerial will to implement them does not.

The letter continues:

"Our overall approach to our networking is about promoting research and information sharing and our security architecture needs to take that into account. Many schools uphold the concept of the 'End-to-End' nature of the original Internet for both research and communication of ideas. These ideas on full connectivity have merit and cannot be dismissed because the nature of faculty research or inter-university collaboration might rely on unfettered access to the Internet. The concept of a DMZ is not feasible for many schools compared to many in government and business which cannot live without one."

Immense multi-national organizations foster information sharing and research. While they admittedly are not perfect, many enterprises manage to maintain better security than .edu's. The "end-to-end" Internet is a myth that to which too many people cling. That model may have worked when the Internet was a private network, but "end-to-end" today places no barriers between your system and anyone else in the world with an IP address.

The majority of hosts are not designed, configured, or deployed in a self-defending manner. Hosts that cannot protect themselves must be supported by additional security resources. Even if a system could be operated indepedently (e.g., an OpenBSD server), without any network-based access control, this is not a tenable defensive model. The .edu world needs to understand that defense-in-depth is one of the best ways to compensate for weak host software, potential misconfiguration, and aggressive intruders.

Finally, "the concept of a DMZ" is not feasible for many organizations, not just .edu's. Security zones, which group hosts of similar security requirements, are now the best way to offer network-centric access control and monitoring.

What are your thoughts?