if you follow infosec news sources at all, by now you've probably heard about the claim made by an anonymous pair of ex-kaspersky employees that kaspersky labs weaponized false positives.
more specifically, the claim is that engineers at kaspersky labs were directed to reverse engineer competing products and use that knowledge to alter legitimate system files by inserting malicious looking code into them so that they would both seem like files that should be detected and be similar enough to the original file that the competing product will also act on the legitimate file and in so doing cause problems for users of those competing products.
i've heard this described as fake malware, but for the life of me i can't see why it should be called fake. the altered files may not do anything malicious when executed, but they're clearly designed to exploit those competing products. furthermore, there is clearly a damaging payload. this isn't fake malware, it's real malware. it may launch it's malicious payload in an unorthodox and admittedly indirect manner, but this is essentially an exploit.
some consider the detection of these altered files to be false positives because the files don't actually do anything themselves, but since they have malicious intent and indirectly harmful consequences, i think the only real false positives in play here are the original system files that are being mistaken for these modified files.
by all accounts, this type of attack on anti-malware products actually happened. what's new here is the claim that kaspersky labs was responsible at the direction of eugene kaspersky himself. there's a lot of room for doubt. the only data we have to go by so far, besides the historical fact of the attack's existence, is the word of anonymous sources (who potentially have an ax to grind) and some emails that, quite frankly, are easily forged. circumstantially there's also an experiment kaspersky participated in around the same time frame that has similar earmarks to what is being claimed except for the part about tricking competing products into detecting legitimate files as malware.
i don't expect we'll ever know for sure if kaspersky was behind the attacks. doubts have been expressed by members of the industry, but frankly i've seen too many things whitewashed or completely ignored (like partnerships with government malware writers) to take their publicly expressed statements at face value. there are certainly vendors i'd have a harder time believing capable of this but there just doesn't seem to be sufficient evidence that the claims are true. the problem is that i can't imagine any kind of evidence the anonymous sources are likely to have that isn't easy to repudiate. had they taken a stand at the time (like someone with actual scruples would have done) they would have been able to put their names behind their claims - they may have lost their jobs but they surely would have been able to find employment with a different vendor because hiring a whistle-blower would have been good PR.
however, as it stands now, the anonymous sources have to remain anonymous. if they're telling the truth then they are complicit in kaspersky's wrong-doing, and if they're lying they are throwing the entire industry under the bus for no good reason (because this claim fans the fires of that old conspiracy theory about AV vendors being the ones who write the viruses). Either way, to have this claim linked to their real identities now would make them radioactive in the industry. no one would touch them, and for good reason.
long ago it used to be that the industry only employed the highest calibre of researchers. people who were beyond reproach. naturally, in order to grow, the industry has had to hire ever increasing numbers of people and old safeguards against undesirable individuals joining the ranks don't scale very well. increasingly people who aren't beyond reproach are being found amongst the industry's ranks and there appears to be no scenario where these two anonymous sources don't fall into that category. the inclusivity that the general security community embraces (and that the anti-malware industry is increasingly mimicking) has the consequence that blackhats are included. the anti-malware industry is going to have to either figure out if they're ok with that or figure out a way to avoid what the general security community could not.
devising a framework for thinking about malware and related issues such as viruses, spyware, worms, rootkits, drm, trojans, botnets, keyloggers, droppers, downloaders, rats, adware, spam, stealth, fud, snake oil, and hype...
Showing posts with label kaspersky. Show all posts
Showing posts with label kaspersky. Show all posts
Tuesday, September 01, 2015
Monday, September 13, 2010
don't be too proud of this technological terror you've created
lot's of folks have been posting about the 'here you have' mass mailing email worm that's been making the rounds. it's strange that such an old-school technique should inspire so much discussion, but it has and some of it's actually interesting.
one of the discussions comes from the enterprise application whitelisting blog, in other words, it comes from application whitelisting vendor bit9. they are, perhaps understandably, quite bullish about the fact that their technology would have stopped the threat before it could have spread while the anti-virus software vendors were supposedly left to scramble to get detection added after the fact.
while it's true that a classical blacklist or known-malware scanner would require updating after the threat becomes known, it seems that at least some of the anti-virus software vendors that harry sverdlove was taking a shot at were actually able to detect the threat heuristically (see f-secure's post or kaspersky lab's post for example).
it also deserves to be said that many anti-virus software vendors are bundling whitelisting in their suites these days, so people using that feature of those offerings would have been just as safe as if they'd been using bit9's.
most importantly, though - if social engineering can be used to get people to extract malware from a password protected archive sent as an attachment and then run that malware (and we have historical examples of successful email worms that used precisely this technique), social engineering can be used to get people to add that malware to the whitelist.
whitelists do not make you magically immune to this threat. i'm not even convinced they raise the bar a significant amount when you consider how easily people can be tricked into doing all sorts of dumb things. perhaps an enterprise would be in a better position because relatively few would (in theory) have access to modify the whitelist, but administrative users aren't above doing dumb things.
one of the discussions comes from the enterprise application whitelisting blog, in other words, it comes from application whitelisting vendor bit9. they are, perhaps understandably, quite bullish about the fact that their technology would have stopped the threat before it could have spread while the anti-virus software vendors were supposedly left to scramble to get detection added after the fact.
while it's true that a classical blacklist or known-malware scanner would require updating after the threat becomes known, it seems that at least some of the anti-virus software vendors that harry sverdlove was taking a shot at were actually able to detect the threat heuristically (see f-secure's post or kaspersky lab's post for example).
it also deserves to be said that many anti-virus software vendors are bundling whitelisting in their suites these days, so people using that feature of those offerings would have been just as safe as if they'd been using bit9's.
most importantly, though - if social engineering can be used to get people to extract malware from a password protected archive sent as an attachment and then run that malware (and we have historical examples of successful email worms that used precisely this technique), social engineering can be used to get people to add that malware to the whitelist.
whitelists do not make you magically immune to this threat. i'm not even convinced they raise the bar a significant amount when you consider how easily people can be tricked into doing all sorts of dumb things. perhaps an enterprise would be in a better position because relatively few would (in theory) have access to modify the whitelist, but administrative users aren't above doing dumb things.
Wednesday, August 04, 2010
digital signatures are not a poor man's whitelist
back when mcafee had their catastrophic false positive i made the suggestion that av vendors in general (and mcafee in particular) could use a whitelist of critical system files to avoid false alarms that render systems unbootable/unusable. basically the idea being that known trusted files could be ignored by anti-malware components prone to false alarm. in the comments of that post didier stevens suggested checking digital signatures of files could be used as an alternative. at first i thought that was an OK compromise to developing a proper whitelist of critical files, but recent events have made me rethink that.
as kaspersky's alexander gostev described, a digital signature will cause a file to be regarded as trusted by security software, much like didier suggested in his comment, and if it's malware that means it will be effectively hidden from the anti-malware software.
i think that's a pretty glaring problem and underscores the fact that digital signatures are a poor substitute for a proper whitelist. a proper whitelist is constructed of items that are known and trusted, but with digital signatures it's neither the anti-malware vendor nor the user who's constructing this implied whitelist. instead, the implicit whitelist is constructed jointly by every tom, dick, and harry who happens by hook or by crook to get his/her hands on a valid digital certificate. that means the people who make the determination of whether a file is safe and/or trustworthy are (generally) the same ones who created it. however, those people could lie, they could fail to actually check the safety/integrity of the file they're signing, or they might not even be qualified to check the safety/integrity of the file they're signing. even if the owner of the digital certificate used to sign the file is a trustworthy entity, that doesn't mean the file is also trustworthy. first and foremost, trust is not commutative. besides that, though, as the stuxnet example shows us, the certificate can fall into the wrong hands. treating digital signatures as whitelist entries creates a situation where altogether too many entities have influence over what is considered trusted and safe.
thus digital signatures can not tell us what we need a whitelist to tell us, namely that the file is trusted and safe. the presence of a valid digital signature only tells us two things: that the file was signed with certificate X (which may or may not be under the exclusive control of the party it was issued to), and that the file hasn't changed since it was signed. whether it's safe, whether it's fit for use, is entirely outside the scope of what a digital signature can tell us.
i think the idea of using a whitelist to avoid false alarms is a good one, but using digital signatures in it's place is a shortcut. av vendors need to stop cutting corners and implement proper whitelists for this particular application. there are already tens of thousands of digitally signed malware samples in f-secure's collection so i'm at a loss trying to figure out why this technique of false positive avoidance hasn't been abandoned already. now that news that detections of stuxnet didn't start until after the digital signature expired, malware authors will surely be looking to exploit this behaviour more and more.
as kaspersky's alexander gostev described, a digital signature will cause a file to be regarded as trusted by security software, much like didier suggested in his comment, and if it's malware that means it will be effectively hidden from the anti-malware software.
i think that's a pretty glaring problem and underscores the fact that digital signatures are a poor substitute for a proper whitelist. a proper whitelist is constructed of items that are known and trusted, but with digital signatures it's neither the anti-malware vendor nor the user who's constructing this implied whitelist. instead, the implicit whitelist is constructed jointly by every tom, dick, and harry who happens by hook or by crook to get his/her hands on a valid digital certificate. that means the people who make the determination of whether a file is safe and/or trustworthy are (generally) the same ones who created it. however, those people could lie, they could fail to actually check the safety/integrity of the file they're signing, or they might not even be qualified to check the safety/integrity of the file they're signing. even if the owner of the digital certificate used to sign the file is a trustworthy entity, that doesn't mean the file is also trustworthy. first and foremost, trust is not commutative. besides that, though, as the stuxnet example shows us, the certificate can fall into the wrong hands. treating digital signatures as whitelist entries creates a situation where altogether too many entities have influence over what is considered trusted and safe.
thus digital signatures can not tell us what we need a whitelist to tell us, namely that the file is trusted and safe. the presence of a valid digital signature only tells us two things: that the file was signed with certificate X (which may or may not be under the exclusive control of the party it was issued to), and that the file hasn't changed since it was signed. whether it's safe, whether it's fit for use, is entirely outside the scope of what a digital signature can tell us.
i think the idea of using a whitelist to avoid false alarms is a good one, but using digital signatures in it's place is a shortcut. av vendors need to stop cutting corners and implement proper whitelists for this particular application. there are already tens of thousands of digitally signed malware samples in f-secure's collection so i'm at a loss trying to figure out why this technique of false positive avoidance hasn't been abandoned already. now that news that detections of stuxnet didn't start until after the digital signature expired, malware authors will surely be looking to exploit this behaviour more and more.
Tuesday, November 24, 2009
some new snake oil from kaspersky
i found this out thanks to a thread at wilders - apparently kaspersky is taking a page out of the mcafee snake oil playbook. mcafee has total protection and now kaspersky has total security.
i've been over this time and time again - this kind of branding is snake oil. the obvious implication that the average person would draw is that they simply have to use kaspersky total security and then they can be totally secure. that's a false sense of security and the folks at kaspersky know it.
obviously someone cares more about market share and getting to make commercials with jackie chan than about intellectual honesty.
oh crap - looks like bitdefender did same thing.
i've been over this time and time again - this kind of branding is snake oil. the obvious implication that the average person would draw is that they simply have to use kaspersky total security and then they can be totally secure. that's a false sense of security and the folks at kaspersky know it.
obviously someone cares more about market share and getting to make commercials with jackie chan than about intellectual honesty.
oh crap - looks like bitdefender did same thing.
Tags:
bitdefender,
ethics,
kaspersky,
snake oil
Saturday, June 07, 2008
stop trying to decrypt your data
according to a new network world article, gpcode is back... for those that don't remember it's a piece of malware whose payload encrypts your data and holds it for ransom... you have to either pay the bad guys to get the decryption key or you have to hope that the av vendors figure out how to crack it (and probably pay them for their product so you can use it to decrypt your data)...
this is all misdirected effort, though... for all intents and purposes this is a data corrupting payload - the fact that the transformation it performs on your data is reversible is a red herring meant to make people spin their wheels and eventually capitulate and give the bad guys what they want while distracting you from the fact that a data encryptor is no harder to recover from than a data destroyer...
you're prepared for drive failures, right? you have a plan for when something comes along and hoses your data irrecoverably, right? of course you do, they're called backups... those same backups work equally well against maliciously encrypted data as they do against maliciously or accidentally destroyed data so the question i have for those who are concerned about this new version of gpcode is "what's the big deal?"...
and for those working on a way to crack this thing my question is "why bother?"... for all you know the malware writers screwed up their crypto code again but this time in such a way that the data actually is unrecoverable... and if they didn't screw it up then you'll pile huge amounts of effort into cracking the key and either fail or succeed and force the malware writer to take the rather trivial step of creating a new key and releasing a new version of the malware... why bother making the distinction between this and a true data loss event for the user? if the user has backups they're fine and if they don't then this is the kind of event that they actually need in order to learn how important good backups really are... yes it would suck to be them but this is the real world and the real world has consequences that they need to know about rather than be sheltered from... consequences are what help us learn...
*non-update* (since i found out before i managed to post this article): apparently the folks at kaspersky are trying to organize a combined effort to crack the key... there's still nothing to convince me this isn't a waste of time but i should at least acknowledge the difference in opinion... then again, i suppose businesses have a tough time trying to get away with tough love, so i suppose it does make business sense for them to try and coddle their customers in this way...
this is all misdirected effort, though... for all intents and purposes this is a data corrupting payload - the fact that the transformation it performs on your data is reversible is a red herring meant to make people spin their wheels and eventually capitulate and give the bad guys what they want while distracting you from the fact that a data encryptor is no harder to recover from than a data destroyer...
you're prepared for drive failures, right? you have a plan for when something comes along and hoses your data irrecoverably, right? of course you do, they're called backups... those same backups work equally well against maliciously encrypted data as they do against maliciously or accidentally destroyed data so the question i have for those who are concerned about this new version of gpcode is "what's the big deal?"...
and for those working on a way to crack this thing my question is "why bother?"... for all you know the malware writers screwed up their crypto code again but this time in such a way that the data actually is unrecoverable... and if they didn't screw it up then you'll pile huge amounts of effort into cracking the key and either fail or succeed and force the malware writer to take the rather trivial step of creating a new key and releasing a new version of the malware... why bother making the distinction between this and a true data loss event for the user? if the user has backups they're fine and if they don't then this is the kind of event that they actually need in order to learn how important good backups really are... yes it would suck to be them but this is the real world and the real world has consequences that they need to know about rather than be sheltered from... consequences are what help us learn...
*non-update* (since i found out before i managed to post this article): apparently the folks at kaspersky are trying to organize a combined effort to crack the key... there's still nothing to convince me this isn't a waste of time but i should at least acknowledge the difference in opinion... then again, i suppose businesses have a tough time trying to get away with tough love, so i suppose it does make business sense for them to try and coddle their customers in this way...
Tags:
backup,
encryption,
gpcode,
kaspersky,
malware
Wednesday, March 21, 2007
more mobile malware madness
y'know, there are times when i'm not really a big fan of repeating myself (like when it comes to garbage masquerading as insight) but when a supposed top security [/straight face] influencer [straight face] takes a piece of techdirt trash at face value (what's next? will we be citing crackpot, errr, slashdot as an authoritative source?) what's a malware guy to do?
(if this is sounding angry it's because i finally had to unsub from techdirt a little while ago after discovering how inaccurate it is even outside the malware field)
taking the false claims and misrepresentations from the top:
(if this is sounding angry it's because i finally had to unsub from techdirt a little while ago after discovering how inaccurate it is even outside the malware field)
taking the false claims and misrepresentations from the top:
- f-secure spreads mobile malware FUD - see my previous post on the subject...
- kaspersky spread FUD about the mobile malware threat - in the original article the kaspersky folks make it clear that you may well not be very likely to see mobile malware in your home country... the dependence on the regional market penetration of susceptible devices (smart phones) on the extent of the risk has been well established..
- kaspersky took a news crew into a faraday cage in order to make them understand that mobile malware was a real threat - no, they took them in the faraday cage to demonstrate how cabir works...
- cabir is only a threat when you intentionally ignore the warnings - this is the oft cited yes/no prompt that people consistently think should mitigate the mobile malware threat even though it has been well established that the 'no' button doesn't work (the worm just sends itself again immediately so the prompt comes back as soon as you hit 'no'... if you need to make a phone call your only real options are to hit 'yes' or get out of range of the other infected device because you can't use the phone while the prompt is there)...
- kaspersky has suggested that mobile malware is common - again, read the original article, you'll find they don't make that claim at all... they do say that there are certain geographic locations where it's more common than others, though...
- kaspersky could have just found someone with the virus instead of taking the news crew inside a faraday cage - yeah, an anti-virus company is going to demonstrate the functioning of a piece of malware that is epidemiologically equivalent to an airborne biological pathogen without the protective measures necessary to keep it from spreading beyond their control... now pull my other leg...
Tags:
fud,
kaspersky,
mobile malware,
techdirt
Wednesday, January 24, 2007
the myth of overwhelming numbers
one of the myths put forward by the anti-virus is dead crowd is that anti-virus companies just can't keep up with the malware authors... this article about the death of anti-virus, balanced though it may be, contains the following quote that demonstrates just what i'm talking about:
i could end there, but that would be misleading in the opposite direction... 200,000 over 20 years works out to about 27 per day but that's not the right figure right now, that assumes a constant rate of malware production over those 20 years and it has been anything but constant... in this article stanislav shevchenko (the head of kaspersky labs virus lab) is quoted as saying that november 2006 saw 10,000 malware samples added to their database - that works out to about 333 per day... what's more, it's apparently 5 times the number from january 2006...
now you're probably thinking we're back in the overwhelming numbers range again, but wait - stanislav has more figures, specifically the time it takes for a good analyst to process an average malware sample is 5 minutes... if you add in the stated constraint of a 12 hour shift a good analyst should be able to process 144 samples per day so november's incredible figures could probably have been handled by a grand total of 3 analysts with time to spare assuming there weren't too many samples that were significantly more complicated than average - and even if that assumption is false, anti-virus labs tend to have more than just 3 analysts...
so clearly, right now anti-virus companies are not being overwhelmed by samples... that only leaves the future to worry about... if the numbers increased 5 fold from january to november in 2006, what are they going to be like this time next year or the year after that?...
the first graph shown here depicts the increase in the malware production rate over time for the past several years and admittedly it looks pretty grim but i saw a graph with a nearly identical shape (though obviously with very different numbers) ten or more years ago... somehow the world hasn't ended yet, anti-virus hasn't died yet, and life goes on... the more you do a repetitive task, the more patterns start to emerge and with those patterns comes the potential for more automation which in turn leads to faster malware analysis... advances in automation have sped up and will continue to speed up the analysis process so the future doesn't really look all that bleak either...
[edited to fix the year specified - apparently i'm still getting used to this whole 2007 thing]
"The traditional, signature-based technologies are simply not able to keep up with the sheer volume of malware that's out there," Jaquith told TechNewsWorld. "There are over 200,000 unique pieces of malware out there. Some host intrusion vendors say that number is closer to a million.200,000 indeed - that does seem like an awfully big number, how could anti-virus companies possibly keep up? in actuality, this is an example of lying with numbers... although the 200,000 figure is fairly accurate (at least it's in line with what mcafee and f-secure were saying last time i checked), it is not something you keep up with... keeping up is something you do with a rate (a certain number of things per minute or hour or day or year) and 200,000 isn't a rate, it's a total... if we were to turn that total into a rate we'd need to include the time period over which it occurred, and although 200,000 sounds like a pretty big number, 200,000 over the course of 20 years doesn't sound quite so overwhelming...
i could end there, but that would be misleading in the opposite direction... 200,000 over 20 years works out to about 27 per day but that's not the right figure right now, that assumes a constant rate of malware production over those 20 years and it has been anything but constant... in this article stanislav shevchenko (the head of kaspersky labs virus lab) is quoted as saying that november 2006 saw 10,000 malware samples added to their database - that works out to about 333 per day... what's more, it's apparently 5 times the number from january 2006...
now you're probably thinking we're back in the overwhelming numbers range again, but wait - stanislav has more figures, specifically the time it takes for a good analyst to process an average malware sample is 5 minutes... if you add in the stated constraint of a 12 hour shift a good analyst should be able to process 144 samples per day so november's incredible figures could probably have been handled by a grand total of 3 analysts with time to spare assuming there weren't too many samples that were significantly more complicated than average - and even if that assumption is false, anti-virus labs tend to have more than just 3 analysts...
so clearly, right now anti-virus companies are not being overwhelmed by samples... that only leaves the future to worry about... if the numbers increased 5 fold from january to november in 2006, what are they going to be like this time next year or the year after that?...
the first graph shown here depicts the increase in the malware production rate over time for the past several years and admittedly it looks pretty grim but i saw a graph with a nearly identical shape (though obviously with very different numbers) ten or more years ago... somehow the world hasn't ended yet, anti-virus hasn't died yet, and life goes on... the more you do a repetitive task, the more patterns start to emerge and with those patterns comes the potential for more automation which in turn leads to faster malware analysis... advances in automation have sped up and will continue to speed up the analysis process so the future doesn't really look all that bleak either...
[edited to fix the year specified - apparently i'm still getting used to this whole 2007 thing]
Wednesday, June 07, 2006
the stardust dustup
i've been seeing a number of posts like this lately, talking about how the new staroffice/openoffice macro virus is just hype...
statements like this are really telling:
there's lots of talk about how kaspersky labs is misleading the public and hyping up a non-existent threat... about how nothing in stardust is really new and how it's not really a vulnerability but rather a misuse of legitimate functionality... well, here's the thing:
statements like this are really telling:
In a statement prominently displayed on the OpenOffice.org home page, the group also disputes applying the label “virus” to Stardust, the proof-of-concept exploit discovered last week by Kaspersky Labs.you see, stardust is an intended virus as mentioned by both mcafee and kaspersky... unfortunately, kaspersky labs didn't mention it was broken in their first blog post on it, only in the actual encyclopedia description which the media (mainstream and blogosphere alike) didn't bother to read and/or understand, thus necessitating the second blog post to clarify the issue...
there's lots of talk about how kaspersky labs is misleading the public and hyping up a non-existent threat... about how nothing in stardust is really new and how it's not really a vulnerability but rather a misuse of legitimate functionality... well, here's the thing:
- while it's true kasperky labs could have made a more informative blog post the first time 'round, the place where they said further details would be clearly stated the virus was broken...
- what's new here is that someone is trying to write viruses for the staroffice/openoffice platform and they may eventually succeed or someone else may fix the bugs in the current attempts and thereby succeed in making a virus for that platform... stardust is the first attempt, and the fact that someone is making that attempt is new and newsworthy... there might not be an actual virus yet, but one (or more) is coming...
- of course it's just a misuse of legitimate functionality - that's true for viruses in general... they aren't made possible only because of security defects, they're inherent to the general purpose computing platform and if you're going to provide a reasonably powerful macro programming facility in your office suite you're going to invariably wind up supporting macro viruses...
Tags:
kaspersky,
macro virus,
malware,
openoffice,
stardust,
staroffice
Thursday, April 14, 2005
blogs are dangerous?... wtf?!
well, it looks like some tool over at the bbc thought it would be a good idea to report on how blogs were increasingly being used as a way to get malware onto the computers of people who visit those sites... what this person missed entirely was that blogs are just web pages and the threats they pose are exactly the same as for any other type of website... these are just web threats, web threats of one kind or another have been around for years, there's nothing new here and blogs don't pose any threats that are specific to just blogs...
what really struck me, though was how Viruslist.com picked up on the story and did nothing but parrot the message that blogs pose a threat... they could have set the record straight, they could have explained that these are just the same old threats in the same old medium (the world wide web), but apparently it's more important for them to use this opportunity to urge readers to use anti-virus software (and look at the pretty product placement at the bottom of the page)...
let's be perfectly clear here, web based security threats are not new and packaging them as though they're blog based security threats and are new effectively creates Fear, Uncertainty, and Doubt... the bbc news drone i can forgive for simply being ignorant, but Viruslist.com is part of kaspersky labs so they really should have known better...
what really struck me, though was how Viruslist.com picked up on the story and did nothing but parrot the message that blogs pose a threat... they could have set the record straight, they could have explained that these are just the same old threats in the same old medium (the world wide web), but apparently it's more important for them to use this opportunity to urge readers to use anti-virus software (and look at the pretty product placement at the bottom of the page)...
let's be perfectly clear here, web based security threats are not new and packaging them as though they're blog based security threats and are new effectively creates Fear, Uncertainty, and Doubt... the bbc news drone i can forgive for simply being ignorant, but Viruslist.com is part of kaspersky labs so they really should have known better...
Tags:
anti-virus,
bbc,
ethics,
fud,
kaspersky
Wednesday, July 21, 2004
this public roasting is long overdue
check out
Billgates
and
Fewster.1781
notice anything amiss? no? well you should...
both of these are examples of anti-virus companies FAILING to comply with a long standing naming standard that (among other things) states that viruses must not be named after real people unless you know for sure the virus was written by them.... rod fewster is an anti-virus professional and did not write the virus named after him - i dare say bill gates didn't write any virus named billgates either...
both of these examples are quite old, but they don't outdate the naming convention of which i speak... further, it doesn't take a rocket scientist to figure out what's wrong with letting viruses be named after real people...
not only are these companies showing a distinct lack of concern for the reputations of these people, they're also showing a distinct lack of concern for the public at large... naming standards are made for good reasons, not the least of which being reducing confusion and making it easier for people with virus problems to find information on the virus they have...
and it's not like virus names don't get changed - they do, quite regularly, it's the only way to coordinate a common name used across multiple products... but those 2 examples have been sitting around for nearly a decade now... where's the effort to make your life easier? where's the concern for the customer? certainly doesn't look like it's anywhere near these 2 companies right now...
(thanks to art kopp for digging up these examples...)
Billgates
and
Fewster.1781
notice anything amiss? no? well you should...
both of these are examples of anti-virus companies FAILING to comply with a long standing naming standard that (among other things) states that viruses must not be named after real people unless you know for sure the virus was written by them.... rod fewster is an anti-virus professional and did not write the virus named after him - i dare say bill gates didn't write any virus named billgates either...
both of these examples are quite old, but they don't outdate the naming convention of which i speak... further, it doesn't take a rocket scientist to figure out what's wrong with letting viruses be named after real people...
not only are these companies showing a distinct lack of concern for the reputations of these people, they're also showing a distinct lack of concern for the public at large... naming standards are made for good reasons, not the least of which being reducing confusion and making it easier for people with virus problems to find information on the virus they have...
and it's not like virus names don't get changed - they do, quite regularly, it's the only way to coordinate a common name used across multiple products... but those 2 examples have been sitting around for nearly a decade now... where's the effort to make your life easier? where's the concern for the customer? certainly doesn't look like it's anywhere near these 2 companies right now...
(thanks to art kopp for digging up these examples...)
Tags:
anti-virus,
eset,
kaspersky,
malware naming,
virus
Subscribe to:
Posts (Atom)