February 14, 2003

Securing the academic community

The academic community has always gained immensely by its "open" nature. The Internet, although military in orgin, rapidly became an incredible tool for academic research. In particular the Europe-wide academic network has been evolving through the various "Framework" programmes now connecting 30 countries at Gbit/s speeds through Géant.

Security has inevitably been rearing its head (anyone for a multi-Gbit/s denial of service attack?) and clashing with the needs for academic overture.

It wasn't that long ago when the biggest concern for computing centres was to limit access under COCOM rules (relaxed in 1992) to "dangerous nationals". Indeed, my problem in taking delivery of the first Digital DEC3000 alpha-based systems was that they qualified for regulation. It meant that, amongst others, a brasilian PhD student in theory couldn't use them as Brasil hadn't signed the Nuclear Non-Proliferation Treaty.

Then came people trying to poke at supercomputing sites. In the meantime I had migrated to the (now defunct) London Parallel Applications Centre where the problem could no longer be swept under the carpet. A 486sx was pressed into action as a "sniffer" (using tcpdump) on our external link and discovered all sorts of interesting traffic (we weren't the only ones... see Steven Bellovin's famous paper in PDF). Among the traffic was someone from Intel in Israel trying to get in via telnet hacks (this does rather give the time period away, doesn't it?).

If we fast-forward to the current day we are suddenly faced with a security problem of gigantic proportions: the European Data Grid Project.

The idea is to link the LHC particle accelerator at CERN to various academic computing sites around Europe to store, elaborate and trawl the data produced. Furthermore, because of international collaborations, this could well include users from the USA and Asia amongst them. A physicist anywhere on the Internet needs to be able to access the data and run his jobs. From an academic standpoint this is virtually Nirvana: tap into all the computing resources of the world from anywhere in the world.

The first reaction from a security practitioner is: "nightmare!". Followed by ample discussions on how they "certainly forgot" about security. The truth of the matter is fortunately somewhat different: for starters authentication & authorisation uses PKI (An example is the Grid-Ireland Certification Authority). This in itself is not perfect: certificates can be lost, machines on which they reside taken over, but it does mean that the Grid won't become the largest contributor to Seti@Home overnight.

The second reaction takes place when the realisation that the task in hand is far from trivial dawns in the security practitioner's mind. Fine, so let us assume that the authentication & authentication mechanism works. The next daunting issue is that of the code. If all the servers run the same code then breaking into one of them means that you can break into all of them. It is the same principle by which viruses are written for Windows. This means that all of a sudden you might have in your hands the most amazingly powerful DDoS network on planet Earth.

There are a number of solutions: code audit, in the style of the OpenBSD project, running everything on a private network, limiting bandwidth out of the servers, etc. All of these have to face the reality of academic coding: this code is not being developed to military standards. It will not necessarily survive close scrutiny by someone wishing to break into the system and, at the same time, it cannot be expected of the coders to actually audit the code for security flaws. What about running it all on a private network? This simply defeats the concept of a world-wide Grid. Well, then surely we can limit the bandwidth? ... which then renders completely moot the idea of having a 10Gbit/s academic core network.

It is a very difficult problem waiting for someone to work on it.

Posted by arrigo at February 14, 2003 03:49 PM