1. Throttling Viruses: Restricting propagation to defeat malicious mobile code
Author: Matthew M. Williamson, HP Labs Bristol
Published at the 18th Annual Computer Security Applications Conference (ACSAC), 2002
Presenter: Walter Mundt

2. Slowing Down Worms Limit outgoing connections to unique machines
Normal traffic tends to made repeat connections to a small set of servers
Worm traffic connects to many different servers
Benign filter design exploits this difference to slow worm traffic selectively.

3. Why Bother? Why only slow worm traffic?
Primary threat of worms is their speed
Human response is too slow
Automated responses can cause damage due to false positives
Need a “benign” automated response that does not interfere with normal traffic.

4. How to tell the difference?
HTTP Traffic
Worm Traffic

5. What Not to Do Drop connections classified as “worm traffic”
Slow down normal traffic unnecessarily
Fail to slow down worm traffic

6. How?
Set a limit on the rate of outgoing connections to “new” machines to r
“New” machines are those not connected to recently
A buffer of 4-5 remote hosts is sufficient
Queue connections that are too fast
Constantly de-queue and send connection attempts, at a rate of r

7. Algorithm Flow
On connection attempt
Delay queue loop

8. Behavior for normal traffic
Normal traffic has bursts of new connections followed by repeated connections to the same hosts
New connections get queued briefly, but delay is minimal
Reconnections are allowed as normal

9. Behavior for worm traffic
Worm traffic connections attempts are much faster than allowed rate
A few connections go through, but most will be stuck in delay queue
When the queue fills, the user can be notified and take action against the offending process

10. Contribution of the paper
This paper provides an effective way to slow down worm traffic from an infected machine.
The effects of false positive results are minimal.
If widely implemented, could effectively limit worm spread rate enough to allow human intervention.
Implementation would be fairly simple on most platforms

11. Weaknesses in Paper Tests few types of “normal” traffic
Too much focus on HTTP
Would need to be implemented very widely to significantly effect worm spread
Does not stop worm spread, ineffective against slow-spread or “stealth” worms
No future work discussed

12. Possible Improvements
Experiment with more types of data
Discuss future work
Consider limitations, possible issues
Test an implementation on an actual network environment
Combine with other methods of identifying worm traffic and limiting worm effectiveness.