lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <411F7898.19093.579D988@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: (no subject)

Maarten wrote:

> First off:  Nick, please lose that damn attitude of yours !

Why?

You're clearly ignorant of what you are talking about, yet you speak 
with an air as if you do know something about the topic.  Further, your 
ignorance would have been cured by carefully reading all of the 
foregoing thread.  There's a point where the idiocy and chutzpah that 
several have shown in this thread makes them no longer worthy of polite 
consideration and at that point I usually adopt the "beat it into them 
in case that helps" approach...

> Further, by hammering on the endless we-have-done-it-for-many-years-so-who
> are-you-to-tell-us-differently part you're actually making yourself part of 
> the problem, not part of the solution.  

You show more and more of your ignorance each time you open your mouth.

_If_ this "problem" is ever solved, it is very likely that I will have 
been a not insignificant part of that solution.  I can't prove that to 
you but it is "just one of those things" and probably undeniable to 
anyone who knows what they are talking about when discussing this 
problem.

> You're saying that internal procedures make it so difficult to adapt names 
> after the fact.  When in fact the strength of a company, any company, IS to 
> be able to adapt to changing circumstances.  
> And if they're not able to, eventually they will go the way of the dinosaurs.

You are confusing two different aspects of the AV industry.  Yes, the 
industry has to be quite flexible and able to quickly react to 
significant shifts in the malware detection problem set.  That does not 
mean it has to be equally flexible (or even "flexible in the tiniest 
little bit") when it comes to malware naming, as the last 15 years of 
commercial AV software development, marketing and sales prove.  Your 
suggestion is found wanting in the light of significant history -- care 
to make some more obviously uninformed comments??

> The only thing Todd (and I) are trying to say is that it is possible to rename 
> after the fact.  ...

Of course it is.

I never denied that.

I have, however, pointed out several reasons why that generally doesn't 
happen, why that situation is very unlikely to change  _AND_ why it 
would not be particularly helpful even if it did change.  In response 
to those explanations you and Todd (and some others) just keep dumbly 
repeating "but they should change".

Something we both agree on.

The difference is that in designing a better naming system, I am not 
limited to parrotting stupid inanities about things I don't understand
-- I can analyse the history in multi-layered and interacting terms of 
the industry's technical, economic and political development, its 
current internal culture, place that in larger market and political 
contexts, and as a result make useful suggestions that are much more 
likely to be adopted inside the industry and that mean the industry can 
change to better suit those external factors.  I can also advise those 
"outside" AV what elements of those environments they may best and most 
easily change to increase the likelihood the AV industry will make 
"suitable" changes.

I await your parrot squawk response...

NOT!

> ...  I don't #!%$&* care how many old Cobol programs need 
> adapting for that to "get" possible, but the fact remains that it IS.   

_Theoretically_, yes.

I have now lost track of how many times I have agreed with you (and 
others) on this now.

The larger and much more salient fact is that, in today's market (and 
everything that has gone before it), there is no compelling reason for 
several of the very large players to make the expenditure and introduce 
the huge upheavals to internal processes (that are clearly working 
because these companies have not gone the way of the dinosaurs and, to 
the contrary, are experiencing some of their strongest growth ever) 
that fixing the naming problem will require.

> Don't start again about how your current procedures may prevent or complicate 
> that.  Worse integration problems, by far more complex and bigger companies 
> or conglomerates are being tackled every day.  Yeah. To name a few ?  
> How about mergers, or international intelligence-exchange between law 
> enforcement agencies.  Do you think that they let anyone stop them by 
> complaining that database format X isn't readily compatible with format Y ?  
> No. They fix it, they make it work together no matter what.
> So don't start about how impossible it is for you to rename one simple entry.

Both your belief in, and your abject inability to see, your own 
ignorance are truly astonishing!

As Valdis (?) has already addressed the most egregious flaws of your 
"logic" here, I'll move on other, more AV-specific issues.

> To conclude, I'd like to put serious question marks by your statement that the 
> first few hours are the all-important ones.  First off, by renaming after the 
> fact (after the first few hours/days/weeks) no-one is changing ANYTHING about 
> those first hours so you shouldn't have ANY complaint regarding that.

Huh???

What _are_ you trying to say?

The first few hours _under current processes_ produce nearly all of the 
confusion caused by naming inconsistencies.  Media outlets latch onto 
the multiple names (though some will only report one of these, at least 
initially).  System admins get multiple reports and warnings of new 
outbreaks and have to work out whether the updates from the three (or 
more) different AV suppliers whose products they use all cover "all" of 
the new viruses (which may only be one, but the admins don't know yet). 
Then, after the initial hub-bub dies down, the way all the foregoing 
works produces a (modest to significant) negative pressure on the  AV 
companies to change the name reported by their scanner -- they have 
sent out alerts to system admins with their initial name and as 
confusing as it was at the time that this was not the same name as some 
of the competition used the admins of their scanners have become 
somewhat familiar with that name, the major news agencies all included 
that company's name for the malware in their reports so folk will come 
looking for that name at their web site, and so on.  Those everyday 
(well, every incident) negative pressures for name change further 
reduce any perceived ROI of changing the processes that would allow for 
much greater naming flexibility (when viewed as a business issue, 
rather than as a theoretical or technical one).

> Secondly, a lot of the confusion only comes later. The guys that have their AV 
> software up and running and current mostly do not suffer from the outbreaks.
> The problem often comes (much) later, with the people who didn't update, 
> 'forgot to', or plain disregard any security or updates whatsoever.  And then 
> you are only called in to fix things when stuff is really breaking down.  
> Or are you saying you've never been asked to de-toxify your parents'-, 
> friends'- or siblings'- computers that got infested despite everything ?
> Everyone has.

I did not say that there were not downstream problems as a result of 
not renaming.  I said the majority of the cost (as a business factor) 
of naming inconsistency occurs in the first few hours of an "outbreak" 
situation, either directly (e.g. the sysadmins rushing round trying to 
work out if the three alerts from three different vendors in the last 
15 minutes for FooBar.AB, FooBar.AC and FooBar.AD are, in fact, just 
different names for one virus or two or three new variants they then 
have to ensure all their products get updated to detect ASAP) or 
indirectly (the media reports start to be written as the developers 
post alerts to sysadmins, and these promulgate _and preserve_ further 
confusion based on the mish-mash of names from early in an outbreak, 
and worse, can add their own cutesy, media-coined names to further mess 
things up).

Those are the reasons why renaming after the event will not 
significantly reduce the costs and complications of naming confusion.

Before you respond Maarten, please re-read the whole thread again to 
see how many times this has already been explained...  (Note that I 
consider this and the parallel thread on naming conventions to be part 
of the same thread.)

> Oh and P.S.:  Yes, I did read all of the threads pertaining to this.

It's a pity you didn't understand what you read then, as you have 
presented no good arguments against the points I have now made several 
times, and mostly you simply regurgitate the clue-free comments that 
you have already made.

I am now very tired of repeating myself and having you and some others 
fail to grasp the slightest bit of what I have been explaining.  If all 
you do is repeat yourself again I shall most likely just ignore you, as 
I have better things to do with my time than beat my head against the 
block wall of your ignorance.


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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ