Rhetorical questions: Why doesn't Microsoft post information about current
Trojans/viruses/worms like Trojan.Qhosts??? The
www.microsoft.com/security
page "Technical Virus Alerts" lists a massive 26 entries from Nov 26 2001
(badtrans) through Sep 18 2003 (swen).
There are several answers to this, especially if by "post" you mean
"send alerts to news groups or by email" (how would you know an
unsolicited incoming message is genuine MS or malware SE?)
There are several excellent reference sites that detail malware, such
as
www.f-secure.com/v-descs, and while MS is out of the
antivirus-update front lines, thiers would not be an authoritative
voice on such details.
What MS *would* be expected to be authoritative on, are the risks and
vulnerabilities that malware exploit.
For every risk (point of entry or escalation), there will be anything
between none and several hundred exploiters. Listing alll the
exploiters would create a "too much wood to see the trees" problem.
Often these risks are fixed and documented while there are still zero
exploiters - as was the case with the RPC hole. This dates at least
as far back as NT 4, was documented and patched in July 2003, and
exploited by Lovesan and several others in August 2003.
Loot at those dates, and you will see one of the problems involved.
On the one hand, you want to be informed about risks as they are
discovered - but before there's an exploiter, it's all theoretical and
many users (myself included) may not bother to chase up the patch.
Once it blows up, it's "why didn't you tell us?"
But it's telling that this hole wasn't widely exploited to anyone's
knowledge through several versions of NT over some years, until
Microsoft documented and fixed it - then all hell broke loose a month
later. Some might say it's better not to publicize holes until they
are known and the risk of exploit becomes high or manifest.
I do agree with your take on risk management, though (tagline refers).
I wall out as many unused functionalities as possible, but it's not
easy when MS merges crucial internal services with external access, as
was the case with RPC, or makes it difficult or impossible to not
install (or uninstall) facilities you don't want.
So far, we are used to the "virus infects computer" model, where the
emphasis is on malware detection and removal - in other words, the
main thrust is to clean infected computers.
But Lovesan et al, and Code Red, Nimda, Slammer and Sapphire before
them, demonstrate a new model; "worm infects infosphere". It's
impossible to clean the entire infosphere, so risk management (closing
the risks, not killing the exploiters) becomes the only defence.
This is the crisis we are facing - a patching model that requires
access to patches from one or few servers after clicking through EULAs
and other links, and that typically goes into effect after a restart.
While you are trying to do that, there are thousands of infected PCs
sending you an exploiter that is a fraction of the size of the patch
you are trying to download, and the attackers go active immediately.
See the problem? Seems to me to be a rigged race that you will lose
every time - if you wait until an exploit war before trying to fix the
hole, as most of us will tend to do. The problem is magnified by
repair strategies that lose all patches and service packs ("just
re-install", "do a repair install, and then..." etc.), as these PCs
then have to pull down *everything* all over again.
My response to this crisis would be as follows:
- leverage the builder/reseller channel to patch before crisis
- use out-of-band distribution methods (CDs)
- integrate patches with (re)installation media somehow
- patch downloads for OSs other than that installed
- multiple and local-region patch servers
- offer premium clients direct (non-Internet) dial-in access
- develop authentication scheme to prove news source
- continue to NOT send patches or code (spoofing risk)
- improve patch self-documentation (aids re-usability)
- maintain uninstallation standards (do NOT rely on System Restore!)
- above and other steps to improve user confidence
The last is important, when users (again, myself included) ask
themselves; how likely is this hole to be exploited? vs. how likely is
this patch going to mess up my system, not be able to be uninstalled,
infringe my privacy, throw my settings away so that I have to reapply
risk management, beat me with an anti-piracy stick, etc.?
Unless MS can convince users that the steady stream of urgent code
changes are safer to use than to stay naked, there will always be a
lot of naked and exploitable PCs out there.
-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
