From: list at geeksamazing.com (Al Reust)
Subject: (no subject)

Nick et al...

After having really suffered the thread(S) what is missing is.

         Most SysAdmins do not know what it takes to run a business.

         Most Business Administrators do not know what it takes to run a 
network.

With that said Maarten will never understand the Business Point that you 
are making, nor will most other SysAdmins.

The bottom line is no matter how many "technical" people would like it or 
it would actually make Sense AND make Everyone's lives easier. The bean 
counters prevent it, there is no Profit.


At 02:52 PM 8/15/2004 +1200, Nick FitzGerald wrote:
>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
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists