According to www.computerworld.com/article and www.cgisecurity.com/2008/03/08. From computer world "Microsoft Corp's security team today acknowledged that it knew of bugs in its Jet Database Engine as far back as 2005 but did not patch the problems because it thought it had blocked the obvious attack vectors." Mitigation of threats happens on the front lines, by IT in the trenches. Firewalls, IPS/IDS are all mitigation, software and hardware vendors need to actually fix the problem not mitigate it, at least not as a long term fix.
IMHO patches should be as numerous as press releases if not more so. Patches should be painless to install across 1 or 1 million machines, and not require a reboot. If there is a critical issue that needs to be patched, involve a trusted community, where mitigation can be developed, while you (the vendor) writes the patch, and tests it.
A single patch to fix a single issue may not be the most prudent or timely solution. Take the case where a quick patch fixes the problem for a large number of machines, but in a small number it does nothing, and in the rare case it crashes the service. In the example case I just described, release the patch, show where it works and where it does not, then allow it to be deployed where it works, and fix the rest quickly. For in the case of a network worm that spreads very rapidly, I'd rather see a patch released hours after it was discovered that would immunize 35+% of the systems than a patch that is 99%+ effective weeks later.
-- Tim Krabec
Kracomp.com
IMHO patches should be as numerous as press releases if not more so. Patches should be painless to install across 1 or 1 million machines, and not require a reboot. If there is a critical issue that needs to be patched, involve a trusted community, where mitigation can be developed, while you (the vendor) writes the patch, and tests it.
A single patch to fix a single issue may not be the most prudent or timely solution. Take the case where a quick patch fixes the problem for a large number of machines, but in a small number it does nothing, and in the rare case it crashes the service. In the example case I just described, release the patch, show where it works and where it does not, then allow it to be deployed where it works, and fix the rest quickly. For in the case of a network worm that spreads very rapidly, I'd rather see a patch released hours after it was discovered that would immunize 35+% of the systems than a patch that is 99%+ effective weeks later.
-- Tim Krabec
Kracomp.com
No comments:
Post a Comment