Message-ID: <411D65F8.10765.3052471@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: (no subject)

Todd Burroughs wrote:

Before trying to explain a few items to Todd, it is clear that he is 
either smoking something very bad or he jumped into the middle of 
thread on a topic he knows nothing about and decided the rest of the 
world wanted his ignorant, pea-brained opinions anyway.  If Todd reads 
all the rest of the thread that came before this and still cannot see 
why his post makes him appear to be a complete moron, I'll gladly try 
to explain it again...

> > I can easily understand how someone unversed in the _market forces_
> > pertaining to antivirus software could hold that position, and as a
> > theoretical solution to the problem of lack of cross-vendor naming
> > coordination it has often been suggested even by though who know it
> > would never work in the real world.
> >
> > Neat and tidy as such a solution seems, it will not, however, work.  As
> > I explained in other of my posts in this and the related "AV Naming
> > Convention" thread, in general by far the largest "cost" of naming
> > disagreement is borne by the users in the early hours of large-scale
> > outbreaks.  Thus, a "solution" that specifically _requires_ all vendors
> > to use a different name until a name is agreed (no matter what this
> > process it will take some _additional_ time) is, by design, an _anti-
> > solution_ as such a "solution", by design, ensures perfect naming
> > inconsistency at the time the highest cost of naming inconsistency is
> > borne.
> 
> Vendors should not "have to" use a different name until the "real"
> one is detrermined, they should use whatever they want to.

Dip-stick -- that is, as I just pointed out immediately above, 
precisely what happens now and is (part of) the cause of the problem 
that is being discussed.  Please read the rest of the thread then re-
read the message you think you are responding to so you actually know 
what is being talked about and who holds what positions.

> You know what, I don't work in the "anti-virus" field, but what you are
> saying is BS.  ...

Of course you do.

And someone with well over a decade's close association with these 
issues, at the bleeding edge of malware naming decisions for most of 
his waking hours wouldn't know what he is talking about.

Just like I am not a medical doctor so I must be better qualified to 
sort out the medical profession...

> ...  There is no good reason that I can think of that the AV
> companies cannot rename these things after the fact.  ...

Well, fortunately for the world, you don't get to shape the solutions 
here...

> ... When an outbreak
> happens, they provide a fix and name it whatever they want.  ...

This _IS_ what happens now.

_THAT_ is part of the problem.

A _LARGE_ part...

> ...  After the
> fact, they could rename things and their updates reflect the "proper"
> name.  ...

Indeed, some can and sometimes some of them do.  Of course, often 3, 6, 
12, 24, 48 or even 72 hours after the event (and after processing 
perhaps several dozen more submissions from their users) very few folk 
actually care any more.   Yeah, yeah, there are exceptions, but the 
reality is that the often massive re-architecting of internal processes 
in some AV companies is simply not seen as worth the effort (and 
therefore the cost).  Thus, it _will not_ happen unless the ROI factor 
of making such changes as will allow nimble naming and rampant re-
naming change dramatically.  Exceptionally few customers have ever 
actually changed product loyalties because of the naming mess, so there 
really is no compelling business case for fixing some of the 
chronically stupid processes that prevent staff in some AV companies 
from changing names at will.

Now, I did not say I like this situation and I was not defending it -- 
if you'd the whole thread you would, in fact, realize I am one of the 
strongest critics of the current situation and am certainly the best 
informed about the topic amongst those posting.

However, no matter how elegant a proposed solution is, it has to face 
the cold hard facts of the commercial realities, and technical 
realities, that will constrain its possible adoption.  Thus, as much as 
you may not like the reasons I gave for why that proposal will not 
work, those reasons are some of the  constraints that have prevented 
such ideas from already being implemented.  As an outsider you cannot 
know this, but from watching and participating in the day-to-day 
workings of the AV industry for all these years now, I can tell you 
there hasn't yet been a vaguely original sentence in all the ideas 
thrown into these F-D threads on malware naming and there are 
established practices and reasons for why none of those ideas have been 
adopted and/or never will be.  (This does not mean that some of the 
ideas might be at least half worth considering, as often the reasons 
for their non-acceptance are very poor, though this is NOT the case 
with this idea -- its downright stupid and will never fly if the 
objective is to make things better.)

> ...  They can keep a reference to their name in the description, what's
> a few more characters in the signature files for every piece of malware
> going to matter? another 100k in a download at most?  I agree that there
> is probably a lot of marketing pressure that may make this difficult,
> but there is no technical reason for it.

You're quite wrong.

You're making all kinds of assumptions about internal data layouts and 
formats and you are ignoring all manner of non-detection collateral 
whose production and maintenance is a huge sub-industry unto itself, 
and in some cases is architected in very stupid ways that revolve 
centrally around _the_ name for each piece of malware detected by the 
product.  Yes, such things should have been designed by someone with 
ten minutes formal database or work-flow training but sometimes they 
weren't and the cost of re-architecting and transitioning a massive 
store of existing material to anything different will have to be signed 
off very high up the management chain -- the kind of "high" that will 
respond to "we'll lose all our US government contracts if we don't do 
this" reasoning as a purely business case, but would never do it for 
some "soft" reason like "on average our users will prefer us 7.94% 
more".

> The AV companies cannot be that lame that they cannot handle a simple
> name change.  I mean we use databases and other things and using these
> "computers" that should make this easy.  If thay are that lame, maybe
> they shouldn't be in busines.

You cannot be that lame that you cannot understand how complex, 
unnecessarily constraining systems often develop when their designers 
didn't know where the goal-posts would be moved during the next 15 
years, can you?  If you are that lame, maybe you are unemployable?

> It's up to people like us that read lists like this to make them fix
> this silly problem, or we can ignore it.  It doesn't affect me much,
> it just seems silly that they cannot name things consistently.

You're wlcome to try to convince them, but unless you control s/w 
purchasing decisions for many, many tens (or even perhaps hundreds) of 
thousands of users, you will not convince _one_ of them, let alone all 
of them (and, if you think about it, it would require similar market 
force -- whatever that may be -- to be brought to bear against several 
of the large developers all at once to actually provide enough 
incentive to get them to support some kind of centralized naming 
authority mechanism).

> > Secondly, one of the greatest impediments to ongoing (as opposed to
> > initial, outbreak-phase) naming inconsistency is that many vendors do
> > not have internal processes robust enough to easily handle renaming
> 
> This is a lame excuse at best, maybe these companies need to redesign
> themselves, this should not be a big problem.

I never said it was anything else but that.

You have missed my point and are trying to argue against me on 
something we largely agree on here.  Yes, that is a lame excuse, but it 
is one of those monstrously lame things that cannot be fixed without a 
huge intervention.

> > (And please, before replying to this message, please, please, please,
> > please, please read _all_ the rest of thread -- as the only person
> > making a significant contribution who has more than half a clue about
> > how all this stuff works, what may be technically feasible, and what a
> > great deal of customer and industry history suggests may be acceptable,
> > answering the same misconceptions over and over is getting tiresome...)
> 
> We'll be sure to bow down to you...

Good -- while you're bowing down, like my boots clean as I seem to 
trodden in some muck in one of the mailing lists...

Then you can go and read the earlier parts of the thread so you will 
see what a nut-job you made yourself look...


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

Powered by blists - more mailing lists