Re: [Full-Disclosure] (no subject)

• Previous message: Feher Tamas: "[Full-Disclosure] Re: YAPPS..."
• In reply to: Todd Burroughs: "Re: [Full-Disclosure] (no subject)"
• Next in thread: Maarten: "Re: [Full-Disclosure] (no subject)"
• Reply: Maarten: "Re: [Full-Disclosure] (no subject)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: full-disclosure@netsys.com
Date: Sat, 14 Aug 2004 01:08:08 +1200

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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• Previous message: Feher Tamas: "[Full-Disclosure] Re: YAPPS..."
• In reply to: Todd Burroughs: "Re: [Full-Disclosure] (no subject)"
• Next in thread: Maarten: "Re: [Full-Disclosure] (no subject)"
• Reply: Maarten: "Re: [Full-Disclosure] (no subject)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]