Assessing Internet Viruses Like Human Epidemics

underpar writes "This ComputerWorld.com article discusses the UCSD's $6.2 million attempt to study Internet viruses in a manner similar to the study of human epidemics. Stefan Savage, a computer science professor, is quoted in the article as saying, 'We'll be focused on what vectors are used, just like in assessing West Nile, to spread computer viruses and ultimately try to develop defenses to prevent them from spreading.'"

Comments

Primary sources...

[StefanSavage]

FWIW, readers should always understand that when they read a news story they are getting a reporter's interpretation of an interview that itself attempts to simplify a larger story. Inevitably, this means that technical details don't survive the translation. To wit, on the second page of the proposal we write: While it is tempting to repurpose the epidemiological models of infectious disease in humans [29], Internet pathogens are in fact quite different--they are authored by intelligent adversaries. Consequently, traditional stochastic analyses are highly fragile tools for predicting the dynamics or limitations of future outbreaks. For those actually interested in what our center is planning to do, I've made the proposal and the summary available. It also gives some insight into what an NSF grant proposal looks like for those who are curious. - Stefan

Re:Interesting Academic Exercise

[SJS]

This is an interesing academic exercise, but the basic defenses that have been preached for years work just fine:

Um.... the actual basic defenses being preached go back much farther than you suspect. The Internet did not coincide with the development of the computer, or viruses.

Basic defenses are:

• Don't trust live data
• Don't let random programs run on your machine if there's any data accessible -- i.e. control access to your machine
• Don't engage in risky/stupid behavior -- practice safe computing
• Long-term backups are important

'Avoiding IE for surfing' should be "Don't use Microsoft Internet Explorer, full stop." Likewise, "Avoid OL/OE for eMail" should be "Don't use Microsoft Outlook or Outlook Express, full stop." Both of those fall under the category of "risky/stupid behavior". Just because your boss tells you that you have to use 'em doesn't make it any less risky.

Firewalls do two things -- one, they hide your network, so as to keep the black hats away from the data on your network, and two, they hide broken systems that are running insecure programs. This pretty much counts as controlling access to your machine.

I'm not a big fan of automated patching. Patching, yes, but if you automate it, you offer Yet Another Way for the black hats to sneak in to your system. A program that contacts another program to download programs that are replacing programs on that machine fails to (1) control access to your machine and (2) you're trusting "live data".

"Warn on Anomolous behavior" sounds good (intrusion detection systems are sometimes based on this concept), but it doesn't really help too much in *preventing* viruses.

An up-to-date virus scanner is the belt you use in addition to suspenders; it's there to catch your goofs, where you're falling down on the job. As a mitigation strategy, it is good for your network... but it's already too late to get your system back into a pristine state. (Thus a good backup strategy is essential.)

In "the old days", you could bring a system back to a known-good state by powering it down, inserting known-clean read-only media, and booting it up again. (In hindsight, those floppy-based systems had a lot going for them. If you were careful, you could avoid exposing your system to viruses, even if you ran a known-infected program.)

It's a bit harder on modern operating systems. For one, there isn't a good way to run a program in isolation. If you're lucky enough to get a statically-linked program, a chroot jail is a simple place to start, but chroot jails aren't terribly secure, and there's not a lot of statically-linked programs out there these days. Setting up a chroot jail can be prohibitively expensive (in terms of time or disk space).

User-mode Linux and virtual hardware (e.g. Virtual PC) are even more expensive in terms of disk space and set up costs.

Both chroot jails and user-space operating systems tend to keep a program from usefully interacting with other programs. If the output of one program is the input to another, and they're running in different jails/VMs, I need to start worrying about networking in order to facilitate communication. More complexity!

You can always partition your system so that /, /lib, and /usr are read-only, while /var, /tmp, and /home are noexec, but that's not often done, and more often than not, systems are shipping (or defaulting to) single-partition installs. (Madness, I say, madness!)

What would be nice is a system like chroot, but would make the entire system (to that process and sub-processes) read-only, aside from a list of directories, and no-exec, aside from a _different_ list of directories, and at no time would you have the same aspect of a filesystem both read-write and execut