Throttling Computer Viruses
An anonymous reader writes "An article in the Economist that looks at a new way to thwart computer viral epidemics, by focusing on making computers more resilient rather than resistant. The idea is to slow the spread of viral epidemics allowing effective human intervention rather than attempting to make a computer completely resistant to attack."
Could you imagine how slow Slashdot would be at one connection per second? How well could this work on high traffic sites?
If you read the article, you'll see that the limit is on OUTgoing connections, not incomming traffic. In other words, this type of AV effort will not eliminate the slashdot effect.
//Wegge
Here's Williamson's paper on the idea: Throttling Viruses: Restricting propagation to defeat malicious mobile code I haven't read it yet, but I see one potential problem right away. When you load a web page, you normally make quite a few connections--one for each image, e.g. I'll have to see how he handles that
We've got malware that now disables personal firewall software so as to avoid detection. This throttle might be an effective patch against current viruses, but the next round will simply work around the throttle, if it is applied locally.
Of course the article doesn't really say whether this is enforced on the local machines or is applied from outside (i.e. at a switch or router). However, by talking about it as an inoculation, it suggests it really enforced on the local machine.
It's a good idea, in general, but it has to be user-tweakable, and that means it's virus-tweakable too.
People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
Seriously, this is a whole new way to think about security, and it has a lot of promise. Security systems will never be perfect, and if they are designed never to fail, the consequences of failure are likely to be dire. By managing the consequences of failure, you can best limit the effects of a determined attack. I think this is equally true of electronic security and physical security.
Brevity is the soul of wit
-- Polonius
True, but why do people have to keep writing programs with static buffer sizes?
I think it isn't that people WRITE programs with static buffers now-a-days as much as it is that people who maintain old software don't fix the static buffers.
Plus I could also argue what is more important to the program? Static gives me knowledge of the maximum size of memory used, if that knowledge is required. Searching is faster in arrays than linked lists (although replacing, on average, is slower). Don't assume that static buffers are ALWAYS wrong.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
-j
I support the notion that the key to ultimate security lies in the quality of the code. I'll go further and say that open source is the key to reaching the absolute goal of inpenetrable code. The open source model is our best bet at insuring that many, many eyes (with varying degrees of skill and with different intentions) will scan the code for flaws. I just wish that some of the more popular open source projects were more heavily reveiwed before their latest builds went up.
heuristic scanning is very ineffective.
Yes. By definition, heuristics can only find some evil programs, not all of them. (If they could, they'd be algorithims). Holes will always exist.
And since virus-scanner software must be widely distributed to all the users it's supposed to protect, the virus author can always test his code against the heuristic until he finds a way to slip past it.
This suggests an altered business model for anti-virus vendors: start treating their heuristics like a trade secret, and don't let them out of the building. Run virus scanning on an ASP model.
Of course, the privacy, network-capacity, and liability problems with that approach are enormous.