It's a very valid discussion for this list, however. Just think about it: McCrappy essentially facilitated a distributed denial of service to some percentage of its customers. And I daresay that this percentage was larger than any virus that has inflicted those customers in the past 18-24 months.
So, the cure was worse than the disease. Testing and provisional deployment are vital at this stage of the game. Most AV products don't facilitate the kind of internal QA scheduling that you suggest, but it is something for us to consider implementing. The tradeoff of a slightly longer window of initial vulnerability to greatly reduce the likelihood of a denial of service by AV vendor. -ASB: http://XeeSM.com/AndrewBaker On Mon, Apr 26, 2010 at 8:39 AM, Ziots, Edward <ezi...@lifespan.org> wrote: > Honestly, > > > > I also work for healthcare, and if you think AV is going to stop > Information Disclosure or data leakage, that is a little misguided. Blind > faith in any company or product is also foolish ( trust but verified). > > > > Yes most of the AV vendors do release multiple time per day, but we need to > look at this like any risk, how many times am I going to get burnt by a bad > dat and what is the fallout from that, vs being up to date dat wise and > protecting from the latest viruses out in the wild that the vendor has > written dats from. > > > > As you probably already know my company made National headlines due to the > Mcafee fallout, therefore, I think the same approach used for patching ( > TEST) then deploy has to be implemented accordingly. > > > > 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) > > > > Probably the quickest procedure fix to the issue, again it creates a risk > of its own, but when you explain it to the management and they explain to > the business, it tends to get across accordingly, especially when the pain > of a bad DAT snapfu and the associated fallout is fresh in executives minds. > > > > > As for dedicated people, in healthcare nobody is dedicated to just one > thing, we are multi-tasked up to the hilt, therefore I would still recommend > and adjustment of procedure with an associated risk assessment based on the > AV patches you are deploying like any other change management process. > > > > Happy to talk with anyone offline about this if possible. I don’t want this > becoming a flame war on the list. > > > > Z > > > > Edward Ziots > > CISSP,MCSA,MCP+I,Security +,Network +,CCA > > Network Engineer > > Lifespan Organization > > 401-639-3505 > > ezi...@lifespan.org > > > > *From:* Raper, Jonathan - Eagle [mailto:jra...@eaglemds.com] > *Sent:* Monday, April 26, 2010 1:02 AM > > *To:* NT System Admin Issues > *Subject:* RE: OT what is the lesson for IT deparments and AV vendors > after MCAFEE issue " update" > > > > In the ideal (read, “best practices”) world of IT, I agree wholeheartedly > that testing is what we SHOULD do, BUT… > > > > I dumped McCrappie last month, so I’m thankful I wasn’t impacted. However, > who is to say something like this couldn’t happen from any of the other AV > vendors? While we can all stand around and dump on (insert AV vendor name > here that you particularly despise or have been burned by in the last 20 > years), the fact is that they all develop new code every day, and there is > always the chance that someone will make a mistake and screw up, just like > McAfee did. Maybe not likely, but it is possible. > > > > DAT updates come out daily from all the major players, and the ones who are > serious are putting out multiple updates daily. At the customer level, how > the heck is anyone supposed to test that? Dedicate a staff person to nothing > but AV? Who has the time, let alone the budget? Considering that the > downturn in the economy here in the US has finally caught up with us in the > healthcare sector, and Medicare is continually cutting back reimbursement > (which is a significant chunk of our revenue stream). People aren’t coming > to the doctor as much, which means my budget is getting smaller. They have > lost jobs and therefore insurance, and are thinking twice about what is > serious enough to go to the doctor for versus what they feel like they can > either suffer through or deal with on their own. > > > > Even though we’re a medium to large size healthcare provider, we don’t have > the resources at our fingertips to be able to test every stinking security > update that comes out. And if we don’t have the resources, I can guarantee > that MOST of the businesses out there don’t have the resources. > > > > So, like I said, what do we all do? Pray that this doesn’t happen to us and > just continue to have blind faith in our AV vendor? If we wait to deploy an > update because we’re “testing”, we run the risk of being exposed to whatever > vulnerability is out there. Which is worse? Dealing with security > vulnerability, or being taken down by a security update? > > > > Personally, I’d rather risk downtime because of a bad DAT or engine update > than to be open to a security vulnerability that could leak my data or my > customers’/patients’ data. At least if the update shuts my machine down or > breaks its network connection, the machine can’t be infected… > > Jonathan L. Raper, A+, MCSA, MCSE > Technology Coordinator > Eagle Physicians & Associates, PA* > *jra...@eaglemds.com* > *www.eaglemds.com > ------------------------------ > > *From:* Andrew S. Baker [mailto:asbz...@gmail.com] > *Sent:* Monday, April 26, 2010 12:16 AM > *To:* NT System Admin Issues > *Subject:* Re: OT what is the lesson for IT deparments and AV vendors > after MCAFEE issue " update" > > > > Indeed. Test and don't support vendors who are poor at testing. > > > -ASB: http://XeeSM.com/AndrewBaker > > On Sat, Apr 24, 2010 at 12:02 PM, Don Ely <don....@gmail.com> wrote: > > Or better yet... Don't install McAfee > > > On 4/24/10, Micheal Espinola Jr <michealespin...@gmail.com> wrote: > > The same as it ever was. Test. > > > > -- > > ME2 > > > > > > On Fri, Apr 23, 2010 at 2:23 PM, justino garcia > > <jgarciaitl...@gmail.com>wrote: > > > >> McAfee has changed its official response [warning: interstitial] on how > >> many enterprise customers were affected by a bug thatcaused havoc on > >> computers globally. It originally stated the bug affected 'less than > half > >> of > >> 1 per cent' of enterprise customers. NowMcAfee's blog states it was a > >> 'small > >> percentage' of enterprise customers > >> > >> zd Net notes a supermarket giant in Australia that had to close down its > >> stores as they were affected by the bug, causing a loss of thousands of > >> dollars > >> > >> > http://siblog.mcafee.com/support/mcafee-response-on-current-false-positive-issue/ > >> < > http://siblog.mcafee.com/support/mcafee-response-on-current-false-positive-issue/ > > > >> http://isc.sans.org/diary.html?storyid=8656 > >> > >> <http://isc.sans.org/diary.html?storyid=8656>McAfee's "DAT" file > version > >> 5958 is causing widespread problems with Windows XP SP3. The affected > >> systems will enter a reboot loop and loose all network access. We have > >> individual reports of other versions of Windows being affected as well. > >> However, only particular configurations of these versions appear > affected. > >> The bad DAT file may infect individual workstations as well as > >> workstations > >> connected to a domain. The use of "ePolicyOrchestrator", which is used > to > >> update virus definitions across a network, appears to have lead to a > >> faster > >> spread of the bad DAT file. The ePolicyOrchestrator is used to update > >> "DAT" > >> files throughout enterprises. It can not be used to undo this bad > >> signature > >> because affected system will lose network connectivity. > >> > >> What the lesson to be learned? > >> -- > >> Justin > >> IT-TECH > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
