well, it's been a couple days since i tore anyone a new one so here goes... some of you may be familiar with the mess revolving around the infosecsellout blog (as discussed at these sites 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, not to mention slashdot) but if not, here's my perspective...
to start out, infosecsellout announced the discovery of a remotely exploitable mac vulnerability but he/she/they weren't finished working on it so he/she/they weren't ready to give apple the details yet... nothing new with finding mac vulnerabilities (that is why apple has been releasing security patches after all) but i suppose it was a little pointless to announce the existence of the vulnerability to the community before you're ready to do anything about it for the community...
then infosecsellout wrote a worm that exploited the vulnerability... obviously i'm not going to condone writing malware, but to his/her/their credit at least he/she/they weren't going to release it to the public, only to his/her/their employer - and he/she/they may have had good reason to trust that that employer wouldn't do anything stupid or malicious with the worm so it might have been responsible handling of malware (at least after the fact, though there are better ways to go about proving things)...
then the criticism started rolling in... obviously writing malware for the mac at this stage isn't proving the mac is vulnerable to malware since that was objectively proven some time ago, but the criticism went beyond that... some apparently felt that details should be given to apple when they (rather than the researcher) felt the researcher was ready... others felt (perhaps justifiably) that without proof of the vulnerability and without a reputation to fall back on (an inherent limitation of anonymity) that there was no reason to believe the vulnerability claim was legitimate... ah to be a mac fan...
all that seems fairly civilized so far, but some folks decided they'd rather have infosecsellout shut up and thus he/she/they started receiving death threats... were some of them mac fans? maybe... were some of them security professionals? probably since they implied they'd be at security-related events when they put a bullet in the sellout and buried him/her (no them, since the people making threats didn't seem to consider the fact that they'd need to deal with more than one person)... there are some pretty twisted people in the world and threatening death and/or mutilation over an exploit is pretty despicable, i have to agree with dave lewis on that one... although in usenet i often used to see people wish to see virus writers strung up by their testicles or various other body parts so as sick as it may be perhaps it's more common than anyone wants to admit...
another attack seemingly designed to silence the infosecsellout was an attack against his/her/their identity(/ies)... security professionals, whining about the mean and nasty things infosecsellout has said (oh, boo hoo - toughen up kids, this is the internet not a school playground), tried to out the infosecsellout... first of all, this is a dangerous thing to do to someone who is receiving death threats... were the threats real? it's impossible to know for sure but when it comes to people's lives i think it's probably better to err on the side of caution... second, although it may be true that there is no real anonymity on the internet (especially where security pros are concerned) the same can be said for privacy... anonymity, like privacy, is a luxury we afford each other and we do so because we value these things and want others to afford those luxuries to us... just as privacy is a prerequisite for personal liberty, anonymity is a prerequisite for freedom of speech - and i'm not talking about happy/friendly speech that doesn't need protecting in the first place, it's unpopular speech that anonymity is designed to protect... you should expect to not like unpopular speech, but you should also understand why a free society needs it... i regard those who disrespect anonymity with the same sort of disdain as those who disrespect privacy (like peeping toms or hammer hawks)...
the blog hijacking, had it been a real one like these two from recent memory instead of just fat fingers (so there's an insider threat even in blogging!) and a cooperative blog creator, would have come the closest to shutting him/her/them up... but even when the blog seemed to be gone, infosecsellout was still getting his/her/their voice(s) heard in blog comments so it would seem that the infosecsellout is here for the duration and folks should just get used to it...
if you think the infosecsellout is a troll then act accordingly and stop paying attention to him/her/them... if you don't like the things infosecsellout has to say, just about the worst thing you could do would be to lend credence to those things by trying to silence him/her/them...
(and if you're wondering why i didn't link directly to the infosecsellout blog, or why the blog doesn't appear in my blogroll at the time of writing even though it used to, look no further than the supposedly corrected hijacking [and, i suppose the malware writing]... it's back on my probationary list for now...)
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...
Saturday, July 21, 2007
Tuesday, July 17, 2007
microsoft's anti-malware ethical conflict
regular readers can probably recall me saying that anti-virus companies don't hire virus writers on occasion... i've called the notion that anti-virus companies are paying for the creation of viruses an urban myth because it would just be too hard to keep that sort of thing secret from their competitors and if their competitors found out about it they'd use it to hurt the company and free up some of it's market share for themselves... each company acts as a watchdog for the others, waiting to blow the whistle on ethical misconduct and in this way they actually help to keep each other honest...
now you'd think this same principle would work for other forms of malware besides viruses, but as i've shown in the past (here and here) that's not always the case... still, it should probably come as a surprise that microsoft, after sinking untold amounts of resources into entering the anti-malware market, has filed for patents on adware/spyware technology... no, not anti-adware/anti-spyware technology, literally technology to serve you ads (adware) based on the contents of your hard drive (spyware)...
so not only does microsoft have conflict where their anti-malware software may prove a disincentive to fixing vulnerabilities in their other software (not to mention that they're charging you money to protect against threats exploiting flaws in their other software) but now they have an ethical conflict where they're considering producing malware and anti-malware at the same time... apparently some of the PHBs at microsoft haven't gotten the memo yet about the new ethical constraints of the company now that it produces anti-malware software... let me put it as bluntly as possible: if you're going to be an anti-malware company you have to be anti-malware... that means no malware creation or malware-based revenue for you...
i, for one, would neither feel comfortable using nor endorsing the use of anti-malware software produced by an entity that ever seriously considered producing malware, never mind one that did so while producing the anti-malware in question at the same time...
now you'd think this same principle would work for other forms of malware besides viruses, but as i've shown in the past (here and here) that's not always the case... still, it should probably come as a surprise that microsoft, after sinking untold amounts of resources into entering the anti-malware market, has filed for patents on adware/spyware technology... no, not anti-adware/anti-spyware technology, literally technology to serve you ads (adware) based on the contents of your hard drive (spyware)...
so not only does microsoft have conflict where their anti-malware software may prove a disincentive to fixing vulnerabilities in their other software (not to mention that they're charging you money to protect against threats exploiting flaws in their other software) but now they have an ethical conflict where they're considering producing malware and anti-malware at the same time... apparently some of the PHBs at microsoft haven't gotten the memo yet about the new ethical constraints of the company now that it produces anti-malware software... let me put it as bluntly as possible: if you're going to be an anti-malware company you have to be anti-malware... that means no malware creation or malware-based revenue for you...
i, for one, would neither feel comfortable using nor endorsing the use of anti-malware software produced by an entity that ever seriously considered producing malware, never mind one that did so while producing the anti-malware in question at the same time...
Monday, July 16, 2007
sony vs. the drm manufacturer
as has been reported in a number of places, sony has filed a suit against amergence (formerly sunncomm) because the drm they provided to sony was 'defective'...
contrary to what a number of folks have written, this has nothing to do with rootkits (and not just because 'rootkit' is the most misused term in anti-malware since 'virus')... the reason this has nothing to do with rootkits and the whole sony 'rootkit' debacle is that that debacle involved drm produced by a company called first4internet, not sunncomm...
sony was employing drm technology from 2 separate companies at the same time (xcp from first4internet and mediamax from sunncomm) and sunncomm was able to fly mostly under the radar because most people were so focused on the stealthkit functionality of xcp... of course the added attention to sony cd's probably did raise awareness of the spyware-like qualities of mediamax, but considering that even now most people jump to the conclusion that sony+drm='rootkit' it's clear that sunncomm dodged a big PR bullet when that fiasco was going on...
but all good things come to an end and now they're being sued for reasons that most people are associating with the 'rootkit' debacle... one probably wonders, then, why sony isn't suing firts4internet instead (since first4interent's xcp cost sony a heck of a lot more than sunncomm's mediamax), and i wonder how they're being sued at all since software liability is supposed to be something we need not something we have (if schneier is to be believed)... my best guess is that with existing precedents for spyware prosecution, sony may believe they have a better chance of a judgment in their favour with a sunncomm suit than with a first4internet suit... however, if the claims that sony had final say on the functional specification of the software is true (and given that control is a strong motivator in the decision to deploy drm, it wouldn't surprise me if those claims were true), then sony shares an equal portion of the blame for anything the software did to sony's customers...
but the true lesson in this is for drm providers everywhere: if you're unethical enough to try and provide drm technology, you may one day find your customers (the content industry) trying to bite the hand that feeds them (you)... and when that happens, having customers with deep pockets won't seem like such a blessing anymore...
contrary to what a number of folks have written, this has nothing to do with rootkits (and not just because 'rootkit' is the most misused term in anti-malware since 'virus')... the reason this has nothing to do with rootkits and the whole sony 'rootkit' debacle is that that debacle involved drm produced by a company called first4internet, not sunncomm...
sony was employing drm technology from 2 separate companies at the same time (xcp from first4internet and mediamax from sunncomm) and sunncomm was able to fly mostly under the radar because most people were so focused on the stealthkit functionality of xcp... of course the added attention to sony cd's probably did raise awareness of the spyware-like qualities of mediamax, but considering that even now most people jump to the conclusion that sony+drm='rootkit' it's clear that sunncomm dodged a big PR bullet when that fiasco was going on...
but all good things come to an end and now they're being sued for reasons that most people are associating with the 'rootkit' debacle... one probably wonders, then, why sony isn't suing firts4internet instead (since first4interent's xcp cost sony a heck of a lot more than sunncomm's mediamax), and i wonder how they're being sued at all since software liability is supposed to be something we need not something we have (if schneier is to be believed)... my best guess is that with existing precedents for spyware prosecution, sony may believe they have a better chance of a judgment in their favour with a sunncomm suit than with a first4internet suit... however, if the claims that sony had final say on the functional specification of the software is true (and given that control is a strong motivator in the decision to deploy drm, it wouldn't surprise me if those claims were true), then sony shares an equal portion of the blame for anything the software did to sony's customers...
but the true lesson in this is for drm providers everywhere: if you're unethical enough to try and provide drm technology, you may one day find your customers (the content industry) trying to bite the hand that feeds them (you)... and when that happens, having customers with deep pockets won't seem like such a blessing anymore...
Sunday, July 15, 2007
how NOT to fight spam with gmail
there's a rather misguided piece of gmail-related anti-spam advice that crops up from time to time and has been seen most recently here, here, and here... i try to debunk this whenever i see it but gosh darn it the blog comments just don't seem to be getting through to people so . . .
the basic idea is to transform your gmail address (using the well known transformations of adding extraneous dots or the '+keyword' trick) when you give it out to sites so that when (not if) the address gets misused by spammers you can easily make a filter to delete mail sent to that address...
here's an example: the.president@gmail.com
here's another example: thepresident+nopoliticalmessagehere@gmail.com
now, these tricks are well known, they're easy to apply, but most importantly they're easy to reverse because all the information needed to determine what the true gmail address is must remain present for the tricks to work... if you know that google ignores any dots before the @ sign can you guess what address email to the.president@gmail.com gets delivered to? yeah, thepresident@gmail.com... futher, if you know that everything between the + and @ get ignored (+ inclusive) can you guess where email to thepresident+nopoliticalmessagehere@gmail.com gets delivered to? once again, thepresident@gmail.com...
doesn't seem like rocket science, in fact, it's so easy you can write a program to do it for you - and not to put too fine a point on it but it's almost a certainty that someone already has and put the functionality into an email address management program used by email harvesters and spammers...
that means this trick has next to no value in actually combating spam... i've written before about handing out special email addresses to web sites to help stop spam but the key aspect to that, the thing that makes it actually work, is that your true email address remains secret... not only does the gmail id aliasing trick not keep your true gmail address secret, it gives the spammers the opportunity to create arbitrarily many other aliases so that you can never filter by alias - if you filter out mail to the.president and thepresident, mail to t.h.e.p.r.e.s.i.d.e.n.t will still get through as will mail to thepresident+wants.v1agr4...
these tricks can be useful for organizing incoming mail, but if you want to combat spam by handing out special email addresses you have to use addresses that keep your true address secret...
the basic idea is to transform your gmail address (using the well known transformations of adding extraneous dots or the '+keyword' trick) when you give it out to sites so that when (not if) the address gets misused by spammers you can easily make a filter to delete mail sent to that address...
here's an example: the.president@gmail.com
here's another example: thepresident+nopoliticalmessagehere@gmail.com
now, these tricks are well known, they're easy to apply, but most importantly they're easy to reverse because all the information needed to determine what the true gmail address is must remain present for the tricks to work... if you know that google ignores any dots before the @ sign can you guess what address email to the.president@gmail.com gets delivered to? yeah, thepresident@gmail.com... futher, if you know that everything between the + and @ get ignored (+ inclusive) can you guess where email to thepresident+nopoliticalmessagehere@gmail.com gets delivered to? once again, thepresident@gmail.com...
doesn't seem like rocket science, in fact, it's so easy you can write a program to do it for you - and not to put too fine a point on it but it's almost a certainty that someone already has and put the functionality into an email address management program used by email harvesters and spammers...
that means this trick has next to no value in actually combating spam... i've written before about handing out special email addresses to web sites to help stop spam but the key aspect to that, the thing that makes it actually work, is that your true email address remains secret... not only does the gmail id aliasing trick not keep your true gmail address secret, it gives the spammers the opportunity to create arbitrarily many other aliases so that you can never filter by alias - if you filter out mail to the.president and thepresident, mail to t.h.e.p.r.e.s.i.d.e.n.t will still get through as will mail to thepresident+wants.v1agr4...
these tricks can be useful for organizing incoming mail, but if you want to combat spam by handing out special email addresses you have to use addresses that keep your true address secret...
what happens when the malware stops?
not too long ago there was a post about wabisabilabi on the authentium blog that was interesting on a couple of different levels...
rjs' primary angle was ethics, and i can't really fault anything he wrote - it sounds dead-on to me, not to mention being very much in line with sentiments i've seen many other av personalities make over the years...
but there was one question that the wabisabilabi blogger asked and rjs answered that i think bears closer examination... the question is, essentially, what happens if/when everyone stops writing malware... both the asking of the question and the answer given seem to operate under the assumption that malware will cease to be a problem if/when people stop writing it...
however, as i've observed previously, old viruses never die so that assumption doesn't seem to hold... in fact, as i've suggested on more than one occasion, self-replicating malware will continue to pose a threat long after anyone associated with it's release loses interest and moves on... so long as it poses a threat there will be a need for anti-malware software so the shareholders that wabisabilabi's blogger feigned concern for shouldn't need to worry about their investment becoming completely worthless...
of course one could make the argument that without new malware the nature of what anti-malware companies do would be irrevocably changed - and while that's true it's not as big a change as one might think (at least not right away)... you see, the products detect hundreds of thousands of instances of malware but do they do so perfectly? do they do so optimally? what about removal, is that perfect or optimal in all cases? the answer is no on all counts so there is still plenty of room for malware analysts and engine designers to make improvements... even after all that gets taken care of, it's not like the lack of compelling reasons to upgrade have hurt the word processor market or stopped microsoft from regularly releasing new versions of word...
so it really doesn't seem like the end of malware writing would be all that damaging to the anti-malware business, but what i'd like to do now is take a step back and look at look at what the end of malware would mean... as i've mentioned before malware is (or at least starts out as) a proxy for the intent of a human attacker so why would such attackers stop employing this particular technique for attacking digital assets and resources? malware is a way for an attacker to benefit from automation and make their attacks easier to perform - the most likely reason (though still very unlikely) for them to give that up would be that they were giving up attacking digital assets/resources entirely... in which case, by rjs' reasoning it shouldn't just be the anti-malware folks throwing parties and getting blitzed, it should be the entire computer security industry because the giant pain in the ass that protecting those resources represents will be over...
but let's go further... attacking digital assets/resources is just one of many avenues that people use to attack each other - why give up one and not the others? either computers stop being a useful avenue of attack (which likely can only happen if computers simply stop being useful - seems like a rather apocalyptic change) or people just stop attacking each other... when man stops attacking his fellow man it will be just as much the end of the world as we know it as if it were a conventional apocalypse, only nicer... either way, the end of malware writing would signal the end many other things...
that's not to say that the end of malware writing would cause an apocalypse or that writing malware keeps the world from falling off it's axis - malware is not the cause of things, it is a symptom of the human condition and the only way for it to go away is if the human condition itself undergoes a fundamental and profound change... as such, there's really no problem with anti-malware vendors discouraging malware writing... nobody's under any illusions about whether or not it's going to stop malware from being written, but it is the ethical high road and it is the right thing for them to do...
and if anyone has an even longer view i'd love to hear it...
rjs' primary angle was ethics, and i can't really fault anything he wrote - it sounds dead-on to me, not to mention being very much in line with sentiments i've seen many other av personalities make over the years...
but there was one question that the wabisabilabi blogger asked and rjs answered that i think bears closer examination... the question is, essentially, what happens if/when everyone stops writing malware... both the asking of the question and the answer given seem to operate under the assumption that malware will cease to be a problem if/when people stop writing it...
however, as i've observed previously, old viruses never die so that assumption doesn't seem to hold... in fact, as i've suggested on more than one occasion, self-replicating malware will continue to pose a threat long after anyone associated with it's release loses interest and moves on... so long as it poses a threat there will be a need for anti-malware software so the shareholders that wabisabilabi's blogger feigned concern for shouldn't need to worry about their investment becoming completely worthless...
of course one could make the argument that without new malware the nature of what anti-malware companies do would be irrevocably changed - and while that's true it's not as big a change as one might think (at least not right away)... you see, the products detect hundreds of thousands of instances of malware but do they do so perfectly? do they do so optimally? what about removal, is that perfect or optimal in all cases? the answer is no on all counts so there is still plenty of room for malware analysts and engine designers to make improvements... even after all that gets taken care of, it's not like the lack of compelling reasons to upgrade have hurt the word processor market or stopped microsoft from regularly releasing new versions of word...
so it really doesn't seem like the end of malware writing would be all that damaging to the anti-malware business, but what i'd like to do now is take a step back and look at look at what the end of malware would mean... as i've mentioned before malware is (or at least starts out as) a proxy for the intent of a human attacker so why would such attackers stop employing this particular technique for attacking digital assets and resources? malware is a way for an attacker to benefit from automation and make their attacks easier to perform - the most likely reason (though still very unlikely) for them to give that up would be that they were giving up attacking digital assets/resources entirely... in which case, by rjs' reasoning it shouldn't just be the anti-malware folks throwing parties and getting blitzed, it should be the entire computer security industry because the giant pain in the ass that protecting those resources represents will be over...
but let's go further... attacking digital assets/resources is just one of many avenues that people use to attack each other - why give up one and not the others? either computers stop being a useful avenue of attack (which likely can only happen if computers simply stop being useful - seems like a rather apocalyptic change) or people just stop attacking each other... when man stops attacking his fellow man it will be just as much the end of the world as we know it as if it were a conventional apocalypse, only nicer... either way, the end of malware writing would signal the end many other things...
that's not to say that the end of malware writing would cause an apocalypse or that writing malware keeps the world from falling off it's axis - malware is not the cause of things, it is a symptom of the human condition and the only way for it to go away is if the human condition itself undergoes a fundamental and profound change... as such, there's really no problem with anti-malware vendors discouraging malware writing... nobody's under any illusions about whether or not it's going to stop malware from being written, but it is the ethical high road and it is the right thing for them to do...
and if anyone has an even longer view i'd love to hear it...
Tags:
ethics,
malware,
virus creation
Tuesday, July 03, 2007
what's happening to security blogs on blogger.com?
over the weekend i received an email (thanks again, luke) alerting me to the fact that the blog for superantispyware (a well known and respected anti-spyware application) had been compromised and was serving up malware... on checking my stats i saw that there were a few clicks on that link in my blogroll over the course of the past month so i was concerned and tried to get details from nick skrepetos, but while waiting for a response i find out via the sunbelt blog that a virtually identical fate has befallen another security related blogger.com blog...
is it just those two? are there more? is it just security blogs being compromised or is it just blogger.com blogs in general that are falling victim to the malware profiteers? it seems an unlikely coincidence that 2 security blogs on blogger.com would be found compromised and serving malware around the same time due to unrelated causes... as a blogger.com user myself and a security blogger, i'd really be interested in further details on how the compromise happened - as i'm sure quite a number of other security bloggers who use blogger.com are...
at any rate, if you've visited either of the 2 blogs in question recently, you might want to give your system a thorough inspection - just to be safe...
is it just those two? are there more? is it just security blogs being compromised or is it just blogger.com blogs in general that are falling victim to the malware profiteers? it seems an unlikely coincidence that 2 security blogs on blogger.com would be found compromised and serving malware around the same time due to unrelated causes... as a blogger.com user myself and a security blogger, i'd really be interested in further details on how the compromise happened - as i'm sure quite a number of other security bloggers who use blogger.com are...
at any rate, if you've visited either of the 2 blogs in question recently, you might want to give your system a thorough inspection - just to be safe...
Sunday, July 01, 2007
the three preventative paradigms
something i've had circling around in my head for a while now is a fundamental division between malware prevention techniques... i'm moderately certain i've missed something (because three just comes up way too often in security) but it seems to me that everything falls into one (or more) of three broad categories: blacklisting, whitelisting, and sandboxing...
i know, right now you're probably saying "kurt! you missed a whole bunch of stuff - what about heuristics? what about behavioural techniques?"... well, lets look at that - what does behaviour-based malware detection do anyways? it monitors behaviours, sure, but how does it decide something is bad? what's going on is that it's actually comparing the behaviours (or combinations thereof) to a list of known bad behaviours (or behaviour combinations) which means it's a type of behavioural blacklist... likewise, heuristics compares properties (like the presence of certain familiar routines) of the program being scanned to a list of properties known to be used in bad programs and so also represents a type of blacklist... the blacklist technique is not the exclusive domain of signature scanning... anything that tries to identify something as bad (basically anything that tries to algorithmically answer the question "is this bad?") must do so by comparing it or some aspect of it to a list of known bad things of a similar type - and that makes it a blacklist...
"but kurt," you say, "that's not the only kind of behavioural technique out there. what about ones where you define what behaviour different programs are allowed to perform such as provided by various HIPS products?"... well, you'd be right, that behavioural technique is not a blacklist... besides being a process-centric access control system, it is more generally a behavioural whitelist... just as the blacklist technique is not exclusive to signature-based virus scanning, the whitelist technique is not so narrowly defined as to only specify application launch whitelists and/or the preferred paradigm for deploying firewalls... if it tries to block everything that isn't good/allowed/authorized (rather than everything that is bad/not allowed/unauthorized) then it must first be able to answer the question "is this good/allowed/authorized?" and to do that it must have a list of known good/allowed/authorized things - and that is a whitelist...
so if it answers the "is it bad?" question it's a blacklist and if it answers the "is it good?" question it's a whitelist - what's left? you might think it's some combination of the two but in fact it's not answering any question at all... the truth is our ability to answer either of those questions is limited so we need to take care of the case where we can't answer either of them and that's what a sandbox does... rather than blocking things outright based on knowledge of what's good or what's bad, sandboxing prevents malware intrusion to the host system by misdirection... the software which may or may not be malware is given a sandboxed environment to work in rather than the host environment and barring any ability to escape sandboxes, what happens in the sandbox (good or bad) stays in the sandbox... it doesn't necessarily prevent extrusion (leaking) of sensitive data you enter into applications running in the sandbox, mind you, and in that sense is a lesser form of prevention - but preventing malware from affecting the host system without any knowledge of or ability to decide on what's good or bad is no small feat...
if we could just assume everything that a blacklist doesn't alert on was good then life would be simple, but unfortunately that's not the case... likewise, assuming everything that isn't on a whitelist must be bad isn't very useful either (at least not unless you're dealing with very restrictive environments and even then there are complications)... once again, these three approaches are complementary and are best used together...
i know, right now you're probably saying "kurt! you missed a whole bunch of stuff - what about heuristics? what about behavioural techniques?"... well, lets look at that - what does behaviour-based malware detection do anyways? it monitors behaviours, sure, but how does it decide something is bad? what's going on is that it's actually comparing the behaviours (or combinations thereof) to a list of known bad behaviours (or behaviour combinations) which means it's a type of behavioural blacklist... likewise, heuristics compares properties (like the presence of certain familiar routines) of the program being scanned to a list of properties known to be used in bad programs and so also represents a type of blacklist... the blacklist technique is not the exclusive domain of signature scanning... anything that tries to identify something as bad (basically anything that tries to algorithmically answer the question "is this bad?") must do so by comparing it or some aspect of it to a list of known bad things of a similar type - and that makes it a blacklist...
"but kurt," you say, "that's not the only kind of behavioural technique out there. what about ones where you define what behaviour different programs are allowed to perform such as provided by various HIPS products?"... well, you'd be right, that behavioural technique is not a blacklist... besides being a process-centric access control system, it is more generally a behavioural whitelist... just as the blacklist technique is not exclusive to signature-based virus scanning, the whitelist technique is not so narrowly defined as to only specify application launch whitelists and/or the preferred paradigm for deploying firewalls... if it tries to block everything that isn't good/allowed/authorized (rather than everything that is bad/not allowed/unauthorized) then it must first be able to answer the question "is this good/allowed/authorized?" and to do that it must have a list of known good/allowed/authorized things - and that is a whitelist...
so if it answers the "is it bad?" question it's a blacklist and if it answers the "is it good?" question it's a whitelist - what's left? you might think it's some combination of the two but in fact it's not answering any question at all... the truth is our ability to answer either of those questions is limited so we need to take care of the case where we can't answer either of them and that's what a sandbox does... rather than blocking things outright based on knowledge of what's good or what's bad, sandboxing prevents malware intrusion to the host system by misdirection... the software which may or may not be malware is given a sandboxed environment to work in rather than the host environment and barring any ability to escape sandboxes, what happens in the sandbox (good or bad) stays in the sandbox... it doesn't necessarily prevent extrusion (leaking) of sensitive data you enter into applications running in the sandbox, mind you, and in that sense is a lesser form of prevention - but preventing malware from affecting the host system without any knowledge of or ability to decide on what's good or bad is no small feat...
if we could just assume everything that a blacklist doesn't alert on was good then life would be simple, but unfortunately that's not the case... likewise, assuming everything that isn't on a whitelist must be bad isn't very useful either (at least not unless you're dealing with very restrictive environments and even then there are complications)... once again, these three approaches are complementary and are best used together...
Tags:
blacklist,
malware,
prevention,
sandbox,
whitelist
Subscribe to:
Posts (Atom)