Any network which allows for a sufficient amount of specific control can work. This can include managed switches that allow for IP layer or VLAN level access control lists (ACLs), agents that disable the port on some malicious software event (like a buffer overflow being detected), or the like. You can even do this with sub-unit firewall appliances everywhere. The key is to have the same level of access control options that you have at the perimeter close to the end host. The key to remember is that the malicious events don't just come from the outside world; worms are one way that threat are brought inside.

It's a lot like a submarine and bulkheads. You have a hatch to the outside world that keeps water out, but you also have a series of doors inside that can contain any leaks to a single compartment. You want to contain the worm's traffic, and as specifically as possible, when a worm outbreak occurs.

I don't know if full disclosure, responsible disclose, or irresponsible disclosure will make much of a difference. Interested attackers will always find a way, even if they have to use holes they find and exploit themselves. Since I began working for a commercial software vendor and I've been working with many commercial vendors, my views changed significantly and I was reminded what I was interested in in the first place: better software, and better security. If I don't get to disclose the vulnerability, I'm ok with that.

That being said, I don't advocate anything but working with the vendor if what you're interested in is more secure software. But I don't know if we stopped disclosing vulnerabilities that worms would go away. Full disclosure helps everyone in the end, I think, including the attackers, but it helps a whole host of people learn and fix bugs, even if they do so quietly. That's a benefit I can live with, and those are risks I accept.

One of the funny things we found in our [PDF] wormability research at Arbor Networks is that it appears that we have three different actors in the vulnerability to worm cycle in many cases: a vulnerability discoverer, an exploit author, and a worm author. The worm author uses the exploits written by others to propagate their worms. As long as they can do so, and as long as worm creators have the motivation to do so by spreading spamming wares, phishing site kits, spyware, and other forms of crimeware, this can keep being effective. But this doesn't mean I think we should shut down exploit authors, either, just because their product can be used for ill.

In the end I think that threats like worms will always be around, no matter what kind of knowledge we try and restrict. Instead, network operators, security admins and system admins will simply have to apply decent security practices, which have been shown time and time again to be effective at keeping malware out. Leading organizations do this quite well, so it's been shown that it can be done on a small scale and a large scale.

In some cases yes, for instance SQL Slammer. In many cases, though, it's just the cascading changes and alerts. A growing number of hosts begin acting in the same way: scanning, attacking, and in general causing some havoc. Even if it's not very aggressive it's noticeable.

It's usually not the flood of traffic but the change in trends.

Most worms rely on a handful of methods. Most network worms operate by generating a random IP address and scanning from that. Many recent worms use "island hopping" techniques where they generate addresses in the local (to the worm) /16, /8 and a random address to scan from. Some worms (like SQLslammer and Witty) just try random addresses.

By random I mean a psuedorandom number generator (PRNG), often seeded by the local system's uptime, process id, and some other stuff put through a poorly constructed random number generator. It's far from random (see [PDF] Toward Understanding Distributed Blackhole Placement), but is generally sufficient for most worm outbreaks.

Many application layer worms, like IM-based worms and mass mailers, generate their target list often by just going through your contact list. This helps them focus their efforts.

A few network worms have tried to use ARIN allocations to focus on populated networks, but many semi-random worms haven't had to do this and have spread successfully. There isn't a whole lot of creativity or rigor of thought when it comes to these algorithms, though they simply work.

Some propagation strategies like hitlists have been hypothesized and some researchers have claimed to have seen these in actions.

In an effort to avoid hitting the same hosts or to focus on local networks and hosts, a few strategies have been proposed: using hitlists, hashing, and distributed hash tables, among others. These usually aren't needed, though, or even wanted. One of the success facets about network worms is that they keep trying the same hosts from various vantage points, which can let them slip past firewalls and other security mechanisms.

Stealth is very difficult to achieve with a worm, because of the way that it propagates and causes all of the victims to begin launching new attacks. However, a few simple things can assist the worm with its stealth. Worms like RBot and NeseBot got very far before they were analyzed due to their relatively slow speed (compared to worms like Nimda and Blaster), and the variety of attack mechanisms they use. It's hard to identify that a worm is at work when the cause isn't fully understood. By the time this family of worms was found it was installed on thousands of hosts.

Indeed. We've seen a whole host of parties adopt the worm as a malware distribution platform, and this means that we have hundreds of authors competing with micro distributions of their worm. The populations can range from a few dozen machines to tens of thousands, most of which stay below the press' surface.