Yes, issues can always happen. I'm sure each of us has experienced problems in our infrastructure no matter how attentive and diligent we have been.
The issue here isn't that there was a one-time occurrence. Well, actually, for this situation, it is. Even a mediocre QA test would have uncovered this. But really, the issue is that McCrappy has had systematic failures in quality for quite some time, but they remain supported on brand recognition alone. We have to reward corporations which routinely make decisions that benefit us, and punish those that don't. And I say this knowing full well that many of the recipients of this email do not, unfortunately, have sufficient budget authority. But please remember this for that time when you do. -ASB: http://XeeSM.com/AndrewBaker On Mon, Apr 26, 2010 at 1:02 AM, Raper, Jonathan - Eagle < [email protected]> wrote: > 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* > *[email protected]* > *www.eaglemds.com > ------------------------------ > > *From:* Andrew S. Baker [mailto:[email protected]] > *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 <[email protected]> wrote: > > Or better yet... Don't install McAfee > > > On 4/24/10, Micheal Espinola Jr <[email protected]> wrote: > > The same as it ever was. Test. > > > > -- > > ME2 > > > > > > On Fri, Apr 23, 2010 at 2:23 PM, justino garcia > > <[email protected]>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/> ~
