Two points, Angus 1 -- the Microsoft BSOD update was really a "your machine had a rootkit and now it's not playing nice with the update". So, that's not Microsoft's fault, and it points to an underlying deficiency with rootkit detection.
2 -- Situations where routine testing doesn't easily find the problem are manageable, as that means that the conditions aren't necessarily common and might take special circumstances to uncover. This is very different from the recent McAfee issue, which could have been tested and identified VERY easily. -ASB: http://XeeSM.com/AndrewBaker On Mon, Apr 26, 2010 at 10:01 AM, Angus Scott-Fleming <[email protected]>wrote: > On 26 Apr 2010 at 8:39, Ziots, Edward wrote: > > > Basically new DAT is downloaded, it is deployed to a small subset > group > > of computers and those are verified to work accordingly, without issue > for a > > set number of hours etc etc, then it is deployed to the rest of the > > organization. Very similar to what everyone should do with their patching > > cycles ( Ahem I HOPE you all are doing this, then just blindly having > faith > > in M$ to give us patches that wont cause problems) > > Might be cost-effective for you, if you have enough machines. But if you > support multiple small-business clients, all of whom have different AV > products chosen before you started supporting them, this is NOT an option > for me. I have to let the AV products update automatically. > > Fortunately, the fact that my clients have multiple AV vendors also means > only one or two will be down at the same time due to a bad AV update*, so I > can clean them up and get them back only without having to decide among > them. > > Unfortunately, they are all running Windows. This means if there is a > bad Windows Update event, all my clients would be down at the same time, > resulting in an impossible support situation. As a result I disable > "Automatic Updates" and manually roll out updates a few days after MS does > so, allowing for the rest of the world to be my test-bed ;-). Explaining > why I do this sometimes is a little difficult to clients, but every so often > MS rolls out a blue-screen update (like they did a few months ago :-) ) and > I'm vindicated. > > IMHO, YMMV. > > Angus > > > * False positives happen to many AV vendors. Last week VIPRE quarantined > (or deleted, depending on your settings) a bunch of PDFs -- check the > Sunbelt "Enterprise" forums if you're curious. It happened for at least two > different Def. versions according to my console. Machines weren't shut > down, but unquarantining the PDFs (or restoring them from backup) had to be > done on a machine-by-machine basis which had a non-zero cost to my client. > It only happened on two machines of the 35 on my VIPRE client's network, so > "testing" this on a test network almost certainly would not have found the > issue. And the detection only happened on a "Deep Scan" which takes hours. > Since VIPRE rolls up Def. updates every few hours, testing is not really an > option on a small network. > > > > -- > Angus Scott-Fleming > GeoApps, Tucson, Arizona > 1-520-895-3270 > Security Blog: http://geoapps.com/ > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
