*>>**Hard question I am sure, but it’s a risk that has to be either accepted or rejected.*
Actually, it's a relatively easy question. Every environment has a current state that is presumed to be "known good" or "known bad". (It is possible to be bad, but unknown, but if you don't know, you will treat it as "known good") Introducting items into a known good environment automatically increases risk, and so some consideration should be given to mitigating that risk, whther that involves testing or letting others go first and checking the results. If, however, there is a published exploit that you become aware of, then your environment has entered "known bad" state. This means that the risk of problems achievable by adding the patch or fix has diminished relative to the risk of doing nothing. Even then, testing is possible, and may be very desirable -- albeit with greater urgency. -ASB: http://XeeSM.com/AndrewBaker On Mon, Apr 26, 2010 at 10:26 AM, Ziots, Edward <[email protected]> wrote: > I agree, > > > > With your situation that probably is a better situation of the “wait and > see” but what happens when the 0day that is being exploited and the patch > comes out of cycle, do you still subscribe to the “wait and see” and allow > the drive by attacks to continue? Hard question I am sure, but it’s a risk > that has to be either accepted or rejected. > > > > Also if you are supporting multiple small clients any way to do testing in > the office on VM’s before having clients updated accordingly? I like VM’s in > undoable mode, for this especially, either that or do snap-shots before > patching and roll-back as needed. > > > > Z > > > > Edward Ziots > > CISSP,MCSA,MCP+I,Security +,Network +,CCA > > Network Engineer > > Lifespan Organization > > 401-639-3505 > > [email protected] > > > > *From:* Angus Scott-Fleming [mailto:[email protected]] > *Sent:* Monday, April 26, 2010 10:02 AM > *To:* NT System Admin Issues > *Subject:* Re: OT what is the lesson for IT deparments and AV vendors > after MCAFEE issue " update" > > > > 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/> ~
