well, it was nice to see something as fundamental the issue of password masking questioned (usability expert jakob nielson's original article, bruce schneier's reaction), and then answered (rik ferguson's response, graham cluley's response). i wonder if that indicates we're collectively ready (some of us have been individually ready for a while) to question something equally fundamental like the concept of 'security experts'.
i say this because, as was alluded to by rik ferguson, bruce schneier seemed to be pulling 'blatantly evident factoids' out of his ass (as 'self-appointed authorities' tend to do).
empirical evidence of the decline of shoulder surfing, even if it exists, wouldn't be able to support the implied assertion that it would stay in decline if password masking went away. in fact, the opposite seems much more likely. while it's true that a determined shoulder surfer would be able to figure out your password from your keystrokes, without the password mask even the most casual shoulder surfer would easily be successful. remove the control that makes something rare and it won't be rare anymore.
but i digress. this post isn't about password masking, it's about 'security experts' - and i find myself in a bit of a conundrum because, while i would normally be decrying schneier's posting of material obviously outside his field of expertise, as someone who not only doesn't lay claim to the title of expert but actively rejects it would i not be practicing hypocrisy?
to answer my own question: yes, yes i would. stop that.
the problem isn't (or shouldn't be) that schneier (or anyone else for that matter) posts on topics outside their field of expertise. he should be afforded the freedom to post uninformed opinion just like everybody else. in that regard the problem isn't really bruce schneier at all (even if he is a FUD spreading self-described media whore), the problem, dear reader, is you - for not recognizing how narrow a scope expertise has, where schneier's is, and consequently when to hold his statements up to greater/lesser scrutiny (note: if you have figured out that cryptography is his area of expertise and that you should question everything else then i'm not actually talking to you but everyone else).
and yes, i am aware of the implication that you should then question everything i say - that is actually precisely what i want. one of the benefits from not being an expert that i'd like to enjoy is people not blindly accepting everything i say and actually challenging me when something i say doesn't fit with something they know. i actually like arguing, i find it to have useful properties in the gaining of knowledge, and i think it's a shame that so many seem to value the finding of consensus over the finding of correctness (nevermind the tendency to use authoritative quotes as a replacement for critical thinking). oh well, at least nick fitzgerald and vesselin bontchev were still willing to expound at length on the topic of malware last i checked (though it has been a while).
Wednesday, July 01, 2009
month of 'do as i say'
well today is the first day of july and that means it's also the first day of the month of twitter bugs. like past 'month of X bugs', each day a security vulnerability relating to the subject product/service (in this case twitter) will be disclosed to the public.
why are they disclosing these vulnerabilities to the public? as with any exercise in full disclosure the idea is to force the company(ies) involved to clean up their act and fix the disclosed vulnerability. full disclosure puts the information into the public sphere so that many people are aware of it and something as attention-grabbing as a 'month of X bugs' captures even more mind-share and gets it that much closer to the mainstream.
in theory this is good for the public. in theory the researchers doing the disclosure are doing a good deed because they care about security and the company(ies) they're pantsing are lazy, arrogant boors who don't care about security or the public and who need to be forced into doing the right thing. and supposedly fixing the individual bugs the vulnerability researchers identify is the right thing to do.
but what if the theory is wrong? not all companies are created equal (nor are all vulnerability researchers for that matter). nobody knows what goes on inside a company except the people inside that company. it's possible that a given company may actually be working on a comprehensive upgrade to their security posture that would obviate swaths of bugs including the ones that get identified by outside researchers. but that would have to be delayed and the company's time wasted so that they can chase down these individual bugs one at a time in order to appear to be doing something. such is the consequence of shifting vulnerability notification to the public sphere.
now, i'm not going to be disingenuous and suggest this is what happens all the time or even most of the time, but being in software development i feel confident that it is happening some of the time.
external full disclosure practitioners have no way to know that, however, nor have i seen any indication that they care. despite the warm and fuzzy ideology behind the practice, full disclosure is an application of force. it is an exercise in coercion, an example of using public relations to bend a company to the vulnerability researcher's own will because supposedly the researcher knows better than the company what is best for the company's users.
i'm no more a fan of lazy, arrogant, boorish companies than the next guy, but belligerent 3rd parties leave a bad taste in my mouth too.
why are they disclosing these vulnerabilities to the public? as with any exercise in full disclosure the idea is to force the company(ies) involved to clean up their act and fix the disclosed vulnerability. full disclosure puts the information into the public sphere so that many people are aware of it and something as attention-grabbing as a 'month of X bugs' captures even more mind-share and gets it that much closer to the mainstream.
in theory this is good for the public. in theory the researchers doing the disclosure are doing a good deed because they care about security and the company(ies) they're pantsing are lazy, arrogant boors who don't care about security or the public and who need to be forced into doing the right thing. and supposedly fixing the individual bugs the vulnerability researchers identify is the right thing to do.
but what if the theory is wrong? not all companies are created equal (nor are all vulnerability researchers for that matter). nobody knows what goes on inside a company except the people inside that company. it's possible that a given company may actually be working on a comprehensive upgrade to their security posture that would obviate swaths of bugs including the ones that get identified by outside researchers. but that would have to be delayed and the company's time wasted so that they can chase down these individual bugs one at a time in order to appear to be doing something. such is the consequence of shifting vulnerability notification to the public sphere.
now, i'm not going to be disingenuous and suggest this is what happens all the time or even most of the time, but being in software development i feel confident that it is happening some of the time.
external full disclosure practitioners have no way to know that, however, nor have i seen any indication that they care. despite the warm and fuzzy ideology behind the practice, full disclosure is an application of force. it is an exercise in coercion, an example of using public relations to bend a company to the vulnerability researcher's own will because supposedly the researcher knows better than the company what is best for the company's users.
i'm no more a fan of lazy, arrogant, boorish companies than the next guy, but belligerent 3rd parties leave a bad taste in my mouth too.
live by the sword, die by the sword
so yesterday i got a rather rude surprise by email. google, in their infinite wisdom, had decided to label this blog as spam and had locked it, preventing me from publishing what i had planned to publish. if i hadn't acted within 20 days the blog would have been deleted, apparently.
yes, it was the real google and not a spear phishing campaign (it would have made for good social engineering but who'd spear phish me?). they used the exact email address that i only gave to google for my blogger account, and furthermore, when i visited my blogger dashboard (not following the link in the email) it showed the warning about it there plain as day so it was definitely for real.
according to the literature i was seeing, the system by which they identify splogs is automated. they mentioned fuzzy logic, but we know what that means - heuristics (though not the same heuristics used in anti-malware, obviously). although i'm not exactly some hardcore heuristic fanboy i can't help but feel there's a bit of irony in me (or more specifically this particular blog) catching the business end of a heuristic false positive.
there is, of course, an appeal process they give you (so that your blog doesn't get deleted after the 20 day grace period) but i found it a little annoying that there was no indication anywhere that i'd successfully initiated that process and it was only when i checked again today and found the splog notification gone that i had any clue that anything had gone through. the real test, of course, is publishing and that's part of what this post is meant to achieve - if you're seeing this then the blog is back to normal.
yes, it was the real google and not a spear phishing campaign (it would have made for good social engineering but who'd spear phish me?). they used the exact email address that i only gave to google for my blogger account, and furthermore, when i visited my blogger dashboard (not following the link in the email) it showed the warning about it there plain as day so it was definitely for real.
according to the literature i was seeing, the system by which they identify splogs is automated. they mentioned fuzzy logic, but we know what that means - heuristics (though not the same heuristics used in anti-malware, obviously). although i'm not exactly some hardcore heuristic fanboy i can't help but feel there's a bit of irony in me (or more specifically this particular blog) catching the business end of a heuristic false positive.
there is, of course, an appeal process they give you (so that your blog doesn't get deleted after the 20 day grace period) but i found it a little annoying that there was no indication anywhere that i'd successfully initiated that process and it was only when i checked again today and found the splog notification gone that i had any clue that anything had gone through. the real test, of course, is publishing and that's part of what this post is meant to achieve - if you're seeing this then the blog is back to normal.
Sunday, June 14, 2009
understanding malware growth
(this is actually kind of old now, but real life has a way of interrupting this whole blogging thing)
alex eckelberry posted some graphs depicting the size and growth of the malware samples collected by andreas marx/av-test.org. what most people will take away from it is that malware is growing at an incredible rate, and that's kind of depressing. there's more to the graphs than just that however, and not all of it is depressing - in fact it looks pretty good to me.
but to understand this i think i need to point out just how bad the forecast line of the graphs is. the line represents the expected value according to a particular model of malware growth. of course models and reality never match up absolutely perfectly, but the forecast suggests a fairly simplistic model and it appears that as time wears on it diverges more and more from reality. let's construct a model bit by bit based on some reasonable assumptions and see how close it matches reality.
let's first suppose that there are a constant number of malware creators with a fixed amount of resources (i don't mean money or computing power, i mean man-power resources - you can only do so much in a day, that sort of thing). let's further suppose that the amount of malware a malware creator can create with X number of resources is constant. what would that look like?
this depicts constant growth with a linear increase in population over time. this is not the final model, of course, but simply a starting point. one of the basic flaws with it is that it assumes that the population of malware creators themselves is constant. what if we instead suppose that the set of malware creators themselves were growing at a gradual but constant rate, what would that look like?
this depicts linear (rather than constant) growth in the malware because as the set of malware creators increases over time, so too should their malware output. it also shows a curve in the population vs time graph, although the curve isn't quite as pronounced as the one depicted in the forecast on the population graph on alex's blog and that's because in that case the forecast on the growth graph predicted non-linear growth.
how could we get non-linear growth? well another of our starting assumptions that we need modify is that the number of malware samples a malware creator can create with X number of resources is fixed. in reality malware creators come up with innovations and some of those innovations improve the efficiency of their malware creation efforts such that they can create more samples with the same effort as before. minor innovations in this area (minor in the sense that the efficiency improvement is small) probably happen all the time but major innovations are probably rare. furthermore, adoption of such innovations is not immediate, it takes time for the idea to spread amongst the malware creators. finally, such innovations may not apply to all sorts of malware so it may be that only part of the malware creator population ever adopts the new methods.
so now let's suppose one of those rare groundbreaking innovations happens - one malware creator comes up with a way to increase his malware creation rate by an order of magnitude. then he tells 2 friends (it may not actually work quite that way but one way or another the idea gets communicated to others) and they tell 2 friends, and so on until eventually they approach a peak number of creators using the new method and the rate at which creators switch from the old to new method slows to a trickle. what might that look like?
this depicts the same linear growth as before at the beginning (with the scale adjusted) followed by a period of rapid expansion as the new method reaches it's saturation point amongst the malware creators (most, but not all of them adopt the new method), and then it returns to mostly linear growth but with a stepped sort of appearance as individual adopters of the new method gradually continue to trickle in.
now, i don't know about you but to me this is starting to look rather familiar. it's not quite the same shape as the actual figures, mind you, that looks a lot less smooth than this, but it's a better approximation to the shape than the simple curve used in the forecast and it's based on an entirely reasonable set of forces that would affect malware growth.
as a final step, let's try to imagine why the real values don't follow such a smooth curve. so far we've been assuming that the population of malware creators only increases over time, but that's not entirely true, is it. there are any number of reasons why individuals might leave that population either temporarily (due to things like criminal prosecution, or collapse of particular infrastructure they were using), or permanently (due to things like retirement or death). if we were to take some of the malware creators in our model out of the picture temporarily at various points (and assume that the ones that ones that leave permanently will simply be replaced and so have the same effect as a temporary departure) what might that look like?
as you can imagine, because the malware creators using the new methods contribute so much more to the growth of malware than do the ones using old methods, when the population using the new methods drops slightly it has a much more noticeable effect on the graph than when the population using the old methods drop.
so how reasonable are these assumptions? are malware creators resources fixed? i've yet to see a way to increase the number of hours in a day so any individual malware creator is still limited in the number of man-hours he or she can devote to the task of malware creation.
can an innovation have a huge effect on the number of malware samples created? well just look at the massive number of variants that server-side polymorphism has lead to. you can basically think of those setups as variant factories and once they're constructed they really don't require any extra effort on the part of the malware creator in order to create more samples - it can be entirely automated and is then only limited by the number of victims who download samples.
would adoption of such an incredible innovation really be limited? again, look at server-side polymorphism, how well would that innovation apply to malware such as autorun worms? not that great actually. if you think about it you can probably come up with other examples of malware types and malware techniques that don't naturally go well together.
do people really leave the malware creator population either temporarily or permanently? well first of all people do actually die, and malware creators are among them so yes people do leave permanently - and again, with the example of server-side polymorphism, if the servers go down because for example the hosting ISP gets de-peered (as has famously happened a few times now) then yes the creators will temporarily be removed from the malware creator population until such time as they can set their operation back up somewhere else.
so what else can we take away from those graphs at alex's blog besides the fact that malware is increasing at an alarming rate? well, for my money it's that a big chunk of that alarming rate was due to an innovation (probably server-side polymorphism) that created a rapid expansion in the malware creation rate and that that rapid expansion seems to be over (in fact it looks like it came to an end nearly 2 years ago). that's not to say malware growth will begin to slow of course, but simply that the really scary part is behind us - the malware growth rate is still enormous, but it's not increasing at an exponential rate anymore. maybe a new innovation will come along and take us for another rough ride, maybe not, but as it stands right now catching back up to the bad guys (assuming you were of the school of thought that we needed to) looks a lot more feasible than it did before.
alex eckelberry posted some graphs depicting the size and growth of the malware samples collected by andreas marx/av-test.org. what most people will take away from it is that malware is growing at an incredible rate, and that's kind of depressing. there's more to the graphs than just that however, and not all of it is depressing - in fact it looks pretty good to me.
but to understand this i think i need to point out just how bad the forecast line of the graphs is. the line represents the expected value according to a particular model of malware growth. of course models and reality never match up absolutely perfectly, but the forecast suggests a fairly simplistic model and it appears that as time wears on it diverges more and more from reality. let's construct a model bit by bit based on some reasonable assumptions and see how close it matches reality.
let's first suppose that there are a constant number of malware creators with a fixed amount of resources (i don't mean money or computing power, i mean man-power resources - you can only do so much in a day, that sort of thing). let's further suppose that the amount of malware a malware creator can create with X number of resources is constant. what would that look like?
this depicts constant growth with a linear increase in population over time. this is not the final model, of course, but simply a starting point. one of the basic flaws with it is that it assumes that the population of malware creators themselves is constant. what if we instead suppose that the set of malware creators themselves were growing at a gradual but constant rate, what would that look like?
this depicts linear (rather than constant) growth in the malware because as the set of malware creators increases over time, so too should their malware output. it also shows a curve in the population vs time graph, although the curve isn't quite as pronounced as the one depicted in the forecast on the population graph on alex's blog and that's because in that case the forecast on the growth graph predicted non-linear growth.
how could we get non-linear growth? well another of our starting assumptions that we need modify is that the number of malware samples a malware creator can create with X number of resources is fixed. in reality malware creators come up with innovations and some of those innovations improve the efficiency of their malware creation efforts such that they can create more samples with the same effort as before. minor innovations in this area (minor in the sense that the efficiency improvement is small) probably happen all the time but major innovations are probably rare. furthermore, adoption of such innovations is not immediate, it takes time for the idea to spread amongst the malware creators. finally, such innovations may not apply to all sorts of malware so it may be that only part of the malware creator population ever adopts the new methods.
so now let's suppose one of those rare groundbreaking innovations happens - one malware creator comes up with a way to increase his malware creation rate by an order of magnitude. then he tells 2 friends (it may not actually work quite that way but one way or another the idea gets communicated to others) and they tell 2 friends, and so on until eventually they approach a peak number of creators using the new method and the rate at which creators switch from the old to new method slows to a trickle. what might that look like?
this depicts the same linear growth as before at the beginning (with the scale adjusted) followed by a period of rapid expansion as the new method reaches it's saturation point amongst the malware creators (most, but not all of them adopt the new method), and then it returns to mostly linear growth but with a stepped sort of appearance as individual adopters of the new method gradually continue to trickle in.
now, i don't know about you but to me this is starting to look rather familiar. it's not quite the same shape as the actual figures, mind you, that looks a lot less smooth than this, but it's a better approximation to the shape than the simple curve used in the forecast and it's based on an entirely reasonable set of forces that would affect malware growth.
as a final step, let's try to imagine why the real values don't follow such a smooth curve. so far we've been assuming that the population of malware creators only increases over time, but that's not entirely true, is it. there are any number of reasons why individuals might leave that population either temporarily (due to things like criminal prosecution, or collapse of particular infrastructure they were using), or permanently (due to things like retirement or death). if we were to take some of the malware creators in our model out of the picture temporarily at various points (and assume that the ones that ones that leave permanently will simply be replaced and so have the same effect as a temporary departure) what might that look like?
as you can imagine, because the malware creators using the new methods contribute so much more to the growth of malware than do the ones using old methods, when the population using the new methods drops slightly it has a much more noticeable effect on the graph than when the population using the old methods drop.
so how reasonable are these assumptions? are malware creators resources fixed? i've yet to see a way to increase the number of hours in a day so any individual malware creator is still limited in the number of man-hours he or she can devote to the task of malware creation.
can an innovation have a huge effect on the number of malware samples created? well just look at the massive number of variants that server-side polymorphism has lead to. you can basically think of those setups as variant factories and once they're constructed they really don't require any extra effort on the part of the malware creator in order to create more samples - it can be entirely automated and is then only limited by the number of victims who download samples.
would adoption of such an incredible innovation really be limited? again, look at server-side polymorphism, how well would that innovation apply to malware such as autorun worms? not that great actually. if you think about it you can probably come up with other examples of malware types and malware techniques that don't naturally go well together.
do people really leave the malware creator population either temporarily or permanently? well first of all people do actually die, and malware creators are among them so yes people do leave permanently - and again, with the example of server-side polymorphism, if the servers go down because for example the hosting ISP gets de-peered (as has famously happened a few times now) then yes the creators will temporarily be removed from the malware creator population until such time as they can set their operation back up somewhere else.
so what else can we take away from those graphs at alex's blog besides the fact that malware is increasing at an alarming rate? well, for my money it's that a big chunk of that alarming rate was due to an innovation (probably server-side polymorphism) that created a rapid expansion in the malware creation rate and that that rapid expansion seems to be over (in fact it looks like it came to an end nearly 2 years ago). that's not to say malware growth will begin to slow of course, but simply that the really scary part is behind us - the malware growth rate is still enormous, but it's not increasing at an exponential rate anymore. maybe a new innovation will come along and take us for another rough ride, maybe not, but as it stands right now catching back up to the bad guys (assuming you were of the school of thought that we needed to) looks a lot more feasible than it did before.
Monday, June 01, 2009
now read this!
there was a while there where i was posting links to other peoples blogs to help drive traffic to what i thought were good posts. i fell out of that habit, however, as it became forced and formulaic.
that doesn't mean i don't still come across good posts, but good just isn't really good enough - the criteria of "good" is too nebulous, it gets watered down and loses all meaning.
so now the fact that i'm pointing out a good post again actually means something because it's not just good - it's good enough that i felt moved to do this:
richard bejtlich's post on obama's cybersecurity speech (despite our philosophical disagreement over the classification of malware as a threat) was an excellent bit of creative re-writing of the original speech. for a moment i almost thought i was reading sun tzu again (yes, i am one of those people who reads and re-reads the art of war). if only such insight could have really come from the top like that (or at least been repeated by the guy at the top for everyone to hear).
that doesn't mean i don't still come across good posts, but good just isn't really good enough - the criteria of "good" is too nebulous, it gets watered down and loses all meaning.
so now the fact that i'm pointing out a good post again actually means something because it's not just good - it's good enough that i felt moved to do this:
richard bejtlich's post on obama's cybersecurity speech (despite our philosophical disagreement over the classification of malware as a threat) was an excellent bit of creative re-writing of the original speech. for a moment i almost thought i was reading sun tzu again (yes, i am one of those people who reads and re-reads the art of war). if only such insight could have really come from the top like that (or at least been repeated by the guy at the top for everyone to hear).
Saturday, May 16, 2009
fred cohen says anti-virus doesn't work
the EICAR (european institute for computer antivirus research) conference was held earlier this week and something which may at first blush seem quite curious happened... fred cohen (a keynote speaker, the father of computer viruses, and the man behind the seminal academic treatment of the subject) said that anti-virus doesn't work...
i wish i'd been there to see that (actually no i don't, i almost certainly would have rolled my eyes, crossed my arms and gone to sleep), but since i'm not part of the industry and flying over to berlin on my own dime is kinda out of the question i had to miss out... it seems i wouldn't have even heard about it if not for randy abrams posting about it here... i've waited patiently for a couple of days now for anyone else to write something about it so i could get more details of what was actually said, but that doesn't seem to be forthcoming... even eicar's site only tells me that the title of his talk was supposed to be "Computer Virology: 25 Years From Now"...
so, since i don't have first hand experience of the conference to give me a clue as to what on earth he was thinking, i went and did some research to see if anything he's said or written in the past might give me a clue and i believe i've found what i was looking for...
in an article on his site titled "Unintended Consequences" it starts to become clear that he feels the computer security industry is in the practice of detecting and reacting to bad things instead of preventing and deterring them, and he paints that in a rather negative light... when i read this i was struck - if he thinks anti-virus (probably one of the most mainstream parts of the computer security industry) is about detection and not prevention then he's doing it wrong!... in my earlier post on defensive lines in anti-malware i illustrate pretty clearly how anti-virus technologies (both the ones that security numpties consider av and the ones they don't) are employed as preventative measures, preventing such things as access to threats, execution of threats, and behaviour of threats (among other things)...
the thing is, fred cohen is really not the sort of person you'd expect to be using av wrong... thankfully i found a pair of interviews with him - one called "Three Minutes With Fred Cohen, Virus Trends Tracker", and the other "Fred Cohen - Not all virus writing is a crime"... although anti-virus is certainly used for prevention, it's underlying mechanisms are largely detection-based - however when cohen talks of prevention he's referring to the type where the underlying mechanism is sort of like an immunity... it all became clear to me when he said we should be using systems that are less susceptible to viruses in the first place - systems that have more limited functionality... this relates back to his 1984 paper Computer Viruses - Theory and Experiments where, in the section on prevention (i really should have looked there earlier) he discusses the 3 key properties of a system that allow viruses to spread - sharing, transitivity of information flow, and the generality of interpretation...
systems with limited functionality refers specifically to the third of these properties - the generality of interpretation - by limiting the functions that a system can perform you limit what can be done as a result of interpreting data as code... cohen poses the examples of turning off macros in ms word, or turning off javascript in the browser - i would follow those up with more contemporary examples such as microsoft recently announcing the disabling of autorun for flash media, or the increasing trend (at least among security conscious users) to use alternate PDF viewers as opposed to Adobe's own Acrobat Reader which has been bloated with unnecessary (and frankly unsafe) functionality for a long time...
i'm not going to try and detract from his arguement by saying the idea doesn't have merit - it does... i even considered whether my defensive lines post needed another line regarding system immunity, though i later realized that limited functionality is already covered by existing lines (as it's just another method of preventing exection and/or particular behaviours)... the problem isn't that his argument in favour of using this technique has merit, the problem is figuring out how he could think anti-virus is broken and this technique isn't - or what he thinks the security industry can do about limiting functionality...
the very existence of the security industry underscores the fact that there has historically been no (and largely still is no) place for security in the rest of the computer industry... limiting functionality is the domain of the original product developers, not 3rd party security companies - the norton's and mcafee's of the world don't have the freedom to cripple Acrobat Reader for example (at least not without getting sued)... and the original product developers by and large aren't limiting functionality because that goes against consumer expectations for technology... technology is supposed to empower us to do more, to do things better/faster, etc - so it's a given that when we choose something we expect to empower us, we aren't going to go with the less powerful option... this is born out by history as well because there have always been less functional/powerful options available and the market has consistently selected against them in favour of the bloated product suites and application platforms...
furthermore, limiting applications is all well and good but there's plenty of malware out there that exists as native binary executables, and limiting the operating system's functionality (or worse, that of the hardware itself) to prevent things like self-replication or botnet command and control communication is a far trickier proposition...
so given the difficulty in getting more adoption of limited systems and given the fact that even cohen isn't suggesting limiting things to the point of systems with fixed first order functionality, i can't help but wonder how he could consider this any less flawed an approach in practice than anti-virus... it is clear to me that it will be just as possible to work around the limitations he's proposing as it is to work around anti-virus technologies, and limited functionality defenses are a lot less agile than things like known-malware scanning so when those special cases come along it will cost a great deal more to redesign a system to further limit functionality so as to deal with such special cases...
that should give you a clue as to my opinion of limited functionality-based defenses - they have promise as a complement to anti-virus techniques... anti-virus may not work in the sense that it's not completely effect at preventing malware infestation, but limited functionality systems aren't either... anti-virus may not work in the sense that it's a computationally expensive approach to prevention, but limited functionality has logistical costs for development, marketing, and maintenance that we may never completely overcome... i fully endorse the idea of selecting software that only has as much power and functionality as you need and no more, but i still think you should use anti-virus right along side that...
frankly, at the end of the day, the main difference between systems that are designed to have more limited functionality and ones where anti-virus is deployed is that the former's limitations are baked in while the latter's limitations are bolted on (because like it or not when an anti-virus stops a piece of malware from executing on your system it is effectively limiting your system's ability to perform the function that malware represents)... that appears to be what cohen's real contention is about - that baked in is better than bolted on... in some ways that may be true, but in others (like the matter of agility) it's definitely not (because it's easier to change the bolt than it is to change the whole system)...
i wish i'd been there to see that (actually no i don't, i almost certainly would have rolled my eyes, crossed my arms and gone to sleep), but since i'm not part of the industry and flying over to berlin on my own dime is kinda out of the question i had to miss out... it seems i wouldn't have even heard about it if not for randy abrams posting about it here... i've waited patiently for a couple of days now for anyone else to write something about it so i could get more details of what was actually said, but that doesn't seem to be forthcoming... even eicar's site only tells me that the title of his talk was supposed to be "Computer Virology: 25 Years From Now"...
so, since i don't have first hand experience of the conference to give me a clue as to what on earth he was thinking, i went and did some research to see if anything he's said or written in the past might give me a clue and i believe i've found what i was looking for...
in an article on his site titled "Unintended Consequences" it starts to become clear that he feels the computer security industry is in the practice of detecting and reacting to bad things instead of preventing and deterring them, and he paints that in a rather negative light... when i read this i was struck - if he thinks anti-virus (probably one of the most mainstream parts of the computer security industry) is about detection and not prevention then he's doing it wrong!... in my earlier post on defensive lines in anti-malware i illustrate pretty clearly how anti-virus technologies (both the ones that security numpties consider av and the ones they don't) are employed as preventative measures, preventing such things as access to threats, execution of threats, and behaviour of threats (among other things)...
the thing is, fred cohen is really not the sort of person you'd expect to be using av wrong... thankfully i found a pair of interviews with him - one called "Three Minutes With Fred Cohen, Virus Trends Tracker", and the other "Fred Cohen - Not all virus writing is a crime"... although anti-virus is certainly used for prevention, it's underlying mechanisms are largely detection-based - however when cohen talks of prevention he's referring to the type where the underlying mechanism is sort of like an immunity... it all became clear to me when he said we should be using systems that are less susceptible to viruses in the first place - systems that have more limited functionality... this relates back to his 1984 paper Computer Viruses - Theory and Experiments where, in the section on prevention (i really should have looked there earlier) he discusses the 3 key properties of a system that allow viruses to spread - sharing, transitivity of information flow, and the generality of interpretation...
systems with limited functionality refers specifically to the third of these properties - the generality of interpretation - by limiting the functions that a system can perform you limit what can be done as a result of interpreting data as code... cohen poses the examples of turning off macros in ms word, or turning off javascript in the browser - i would follow those up with more contemporary examples such as microsoft recently announcing the disabling of autorun for flash media, or the increasing trend (at least among security conscious users) to use alternate PDF viewers as opposed to Adobe's own Acrobat Reader which has been bloated with unnecessary (and frankly unsafe) functionality for a long time...
i'm not going to try and detract from his arguement by saying the idea doesn't have merit - it does... i even considered whether my defensive lines post needed another line regarding system immunity, though i later realized that limited functionality is already covered by existing lines (as it's just another method of preventing exection and/or particular behaviours)... the problem isn't that his argument in favour of using this technique has merit, the problem is figuring out how he could think anti-virus is broken and this technique isn't - or what he thinks the security industry can do about limiting functionality...
the very existence of the security industry underscores the fact that there has historically been no (and largely still is no) place for security in the rest of the computer industry... limiting functionality is the domain of the original product developers, not 3rd party security companies - the norton's and mcafee's of the world don't have the freedom to cripple Acrobat Reader for example (at least not without getting sued)... and the original product developers by and large aren't limiting functionality because that goes against consumer expectations for technology... technology is supposed to empower us to do more, to do things better/faster, etc - so it's a given that when we choose something we expect to empower us, we aren't going to go with the less powerful option... this is born out by history as well because there have always been less functional/powerful options available and the market has consistently selected against them in favour of the bloated product suites and application platforms...
furthermore, limiting applications is all well and good but there's plenty of malware out there that exists as native binary executables, and limiting the operating system's functionality (or worse, that of the hardware itself) to prevent things like self-replication or botnet command and control communication is a far trickier proposition...
so given the difficulty in getting more adoption of limited systems and given the fact that even cohen isn't suggesting limiting things to the point of systems with fixed first order functionality, i can't help but wonder how he could consider this any less flawed an approach in practice than anti-virus... it is clear to me that it will be just as possible to work around the limitations he's proposing as it is to work around anti-virus technologies, and limited functionality defenses are a lot less agile than things like known-malware scanning so when those special cases come along it will cost a great deal more to redesign a system to further limit functionality so as to deal with such special cases...
that should give you a clue as to my opinion of limited functionality-based defenses - they have promise as a complement to anti-virus techniques... anti-virus may not work in the sense that it's not completely effect at preventing malware infestation, but limited functionality systems aren't either... anti-virus may not work in the sense that it's a computationally expensive approach to prevention, but limited functionality has logistical costs for development, marketing, and maintenance that we may never completely overcome... i fully endorse the idea of selecting software that only has as much power and functionality as you need and no more, but i still think you should use anti-virus right along side that...
frankly, at the end of the day, the main difference between systems that are designed to have more limited functionality and ones where anti-virus is deployed is that the former's limitations are baked in while the latter's limitations are bolted on (because like it or not when an anti-virus stops a piece of malware from executing on your system it is effectively limiting your system's ability to perform the function that malware represents)... that appears to be what cohen's real contention is about - that baked in is better than bolted on... in some ways that may be true, but in others (like the matter of agility) it's definitely not (because it's easier to change the bolt than it is to change the whole system)...
Wednesday, May 06, 2009
defensive lines in anti-malware revisited
now, i realize i've covered the topic of defensive lines in anti-malware before, about 2 years ago, but i've refined my thinking since then and now i've found the motivation to share (guess i was just being lazy before)... this thread on wilders security forums made me realize that there are some misconceptions about defensive lines in anti-malware... specifically the ideas of what can be the first or last line of defense seem to require some refinement so here goes...
if you're thinking about multiple lines of defense then it makes sense to consider that there is a sequence of defensive lines at various 'distances' from the final outcome of complete system compromise... that is to say that there are various opportunities (some earlier, some later) during the course of a piece of malware's progression towards compromising a system at which you can prevent a system from becoming compromised, and each of these points a defense can be mounted... the first line of defense, therefore, should be the one furthest away (or at the earliest opportunity) from that possible outcome... likewise the last line of defense necessarily must be the last chance for preventing that outcome...
so what is the first possible line of defense then? well, first opportunity you have for avoiding having your computer get infested with malware is the point of initial exposure - if you don't encounter the malware in the first place then there's nothing else to say about it... when it comes to defending oneself the main defense here is actually risk aversion behaviours like not going to so-called 'dodgy' sites, not plugging strange flash drives you found on the ground into your computer, etc... when it comes to defending others, any malicious site take-down effort will also help prevent people from coming across the malware on malicious sites that get taken down... somewhere in the middle are tools like mcafee's site advisor, or google's malware warning functionality that can help users determine which sites to avoid...
the next logical point at which you can prevent compromise is preventing the transfer of the malware onto the machine we're trying to protect... for automatic transfers (such as drive-by downloads or vulnerability exploiting worms) the primary defense is closing the avenues by which such automated transfer can take place, usually by applying security patches (at least where browser exploits are concerned)... a basic NAT enabled router can also protect machines behind it from certain types of automatic transfer by virtue of preventing unsolicited traffic to those machines... for manual transfers, risk aversion behaviours again play an important role - only downloading software from reputable sites (preferably direct from the vendor's site) being a prime example... a somewhat after-the-fact but related defense is on-demand scanning all incoming materials (whether you think they could carry malware or not) before allowing them to be accessed for any other purpose (sort of like a mandatory quarantine period)...
after potential malware has successfully been transferred onto the system the next opportunity to prevent it's progression to full compromise is preventing access to it... this is where on-access scanners come into play... if the user can't access the malware then there should be no way they can trigger it...
if your malware access controls fail to prevent access (say because the malware is packaged within some obfuscating wrapper, or perhaps the malware is just new) then the following point at which full compromise can be avoided is by preventing execution of the malware... on-access known-malware scanning can prevent execution as well, at least for known malware (if it's in some obfuscated wrapper like a dropper, then when the malware is 'dropped' it will no longer be obfuscated and that camouflage will no longer be protecting it from the scanner)... application whitelisting can also prevent a great deal of malware (even that which is too new to be considered 'known' yet) from executing (by virtue of preventing everything that isn't already explicitly allowed to execute from executing) so long as the user doesn't give the malware permission to run...
after malware has successfully begun to execute on a system, any certainty about preventing that malware from compromising that system is gone, but that doesn't mean there aren't still possibilities for prevention... it may still be possible to prevent compromise by preventing one or more of the malware's bad behaviours using behavioural blacklisting, behavioural whitelisting, or some combination thereof (all of which falling under the general umbrella of behaviour blocking)... in so far as certain behaviours involve accessing system resources that can have their access restricted, operating as a user who doesn't have access to those resources (ie. running as a non-administrative user, following the principle of least privilege) will prevent a great deal of existing malware from being able to operate properly and thus can prevent compromise...
finally, if malware gets past all those previously described defensive lines, there's still one possible opportunity to full system compromise... if you can avoid the consequences of the malware's behaviour by being lucky enough (or by managing the circumstances well enough) that the malware was actually running in a sandbox rather than on the main host system then it will be the sandbox that gets compromised rather than the main host system... sandboxes are such that their compromise is usually inconsequential because they can be regenerated easily - though extrusion of sensitive data may still be a problem, if the malware was contained withing a sandbox then compromise of the host will have been avoided... otherwise the system will have become compromised, prevention will have completely failed, and it would now be an issue of detecting the preventative failure, diagnosis to determine the extent of that failure, and recovery from it...
you can make any one of these stages your own first line of defense, but only by ignoring earlier opportunities to defend yourself... likewise, you can make any of these your last line of defense, but only by ignoring subsequent opportunities to defend yourself... think about what that statement means: ignoring opportunities to defend yourself... is that really something you want to do? does it sound wise? it certainly doesn't sound that way to me...
if you're thinking about multiple lines of defense then it makes sense to consider that there is a sequence of defensive lines at various 'distances' from the final outcome of complete system compromise... that is to say that there are various opportunities (some earlier, some later) during the course of a piece of malware's progression towards compromising a system at which you can prevent a system from becoming compromised, and each of these points a defense can be mounted... the first line of defense, therefore, should be the one furthest away (or at the earliest opportunity) from that possible outcome... likewise the last line of defense necessarily must be the last chance for preventing that outcome...
so what is the first possible line of defense then? well, first opportunity you have for avoiding having your computer get infested with malware is the point of initial exposure - if you don't encounter the malware in the first place then there's nothing else to say about it... when it comes to defending oneself the main defense here is actually risk aversion behaviours like not going to so-called 'dodgy' sites, not plugging strange flash drives you found on the ground into your computer, etc... when it comes to defending others, any malicious site take-down effort will also help prevent people from coming across the malware on malicious sites that get taken down... somewhere in the middle are tools like mcafee's site advisor, or google's malware warning functionality that can help users determine which sites to avoid...
the next logical point at which you can prevent compromise is preventing the transfer of the malware onto the machine we're trying to protect... for automatic transfers (such as drive-by downloads or vulnerability exploiting worms) the primary defense is closing the avenues by which such automated transfer can take place, usually by applying security patches (at least where browser exploits are concerned)... a basic NAT enabled router can also protect machines behind it from certain types of automatic transfer by virtue of preventing unsolicited traffic to those machines... for manual transfers, risk aversion behaviours again play an important role - only downloading software from reputable sites (preferably direct from the vendor's site) being a prime example... a somewhat after-the-fact but related defense is on-demand scanning all incoming materials (whether you think they could carry malware or not) before allowing them to be accessed for any other purpose (sort of like a mandatory quarantine period)...
after potential malware has successfully been transferred onto the system the next opportunity to prevent it's progression to full compromise is preventing access to it... this is where on-access scanners come into play... if the user can't access the malware then there should be no way they can trigger it...
if your malware access controls fail to prevent access (say because the malware is packaged within some obfuscating wrapper, or perhaps the malware is just new) then the following point at which full compromise can be avoided is by preventing execution of the malware... on-access known-malware scanning can prevent execution as well, at least for known malware (if it's in some obfuscated wrapper like a dropper, then when the malware is 'dropped' it will no longer be obfuscated and that camouflage will no longer be protecting it from the scanner)... application whitelisting can also prevent a great deal of malware (even that which is too new to be considered 'known' yet) from executing (by virtue of preventing everything that isn't already explicitly allowed to execute from executing) so long as the user doesn't give the malware permission to run...
after malware has successfully begun to execute on a system, any certainty about preventing that malware from compromising that system is gone, but that doesn't mean there aren't still possibilities for prevention... it may still be possible to prevent compromise by preventing one or more of the malware's bad behaviours using behavioural blacklisting, behavioural whitelisting, or some combination thereof (all of which falling under the general umbrella of behaviour blocking)... in so far as certain behaviours involve accessing system resources that can have their access restricted, operating as a user who doesn't have access to those resources (ie. running as a non-administrative user, following the principle of least privilege) will prevent a great deal of existing malware from being able to operate properly and thus can prevent compromise...
finally, if malware gets past all those previously described defensive lines, there's still one possible opportunity to full system compromise... if you can avoid the consequences of the malware's behaviour by being lucky enough (or by managing the circumstances well enough) that the malware was actually running in a sandbox rather than on the main host system then it will be the sandbox that gets compromised rather than the main host system... sandboxes are such that their compromise is usually inconsequential because they can be regenerated easily - though extrusion of sensitive data may still be a problem, if the malware was contained withing a sandbox then compromise of the host will have been avoided... otherwise the system will have become compromised, prevention will have completely failed, and it would now be an issue of detecting the preventative failure, diagnosis to determine the extent of that failure, and recovery from it...
you can make any one of these stages your own first line of defense, but only by ignoring earlier opportunities to defend yourself... likewise, you can make any of these your last line of defense, but only by ignoring subsequent opportunities to defend yourself... think about what that statement means: ignoring opportunities to defend yourself... is that really something you want to do? does it sound wise? it certainly doesn't sound that way to me...
Wednesday, April 01, 2009
teaching bad dogs new tricks
well, april 1st is nearly gone and the internet is still here... conficker's magical doomsday payload didn't materialize - which is good, i would have felt worse if it had...
huh? what? why would i feel bad about such a thing? well it's come to my attention that i may, possibly have contributed to the problem in some small way...
take one autorun worm that employs autoplay social engineering...
add one video that suggests autoplay social engineering was first seen in this worm...
and finally add one blog post published 3 months prior to the discovery of the worm that describes that very feature as a passing remark in the last sentence...
what do you get? a not so great feeling in the pit of my stomach... of course it's probably the height of conceit to imagine that i personally gave this idea to the author(s) of conficker, but autorun worms aren't exactly new in and of themselves so this new behaviour following so close on the heels of my mentioning of it does seem a little bit troubling...
so if i am responsible for that particular feature, my apologies to, well, the entire internet and computer using public... i thought it was an obvious ploy, i assumed it had already been done... it was not my aim to give the bad guys ideas (if anything i'd rather be giving the good guys ideas - if only they'd listen)... i'd like to say that i've come up with safeguards against giving the bad guys ideas in the future, but short of keeping my big yap shut i really can't think of anything...
on the bright side, at least i didn't write and distribute proof of concept attack code that was later used in real malware like some folks i could mention...
huh? what? why would i feel bad about such a thing? well it's come to my attention that i may, possibly have contributed to the problem in some small way...
take one autorun worm that employs autoplay social engineering...
add one video that suggests autoplay social engineering was first seen in this worm...
and finally add one blog post published 3 months prior to the discovery of the worm that describes that very feature as a passing remark in the last sentence...
what do you get? a not so great feeling in the pit of my stomach... of course it's probably the height of conceit to imagine that i personally gave this idea to the author(s) of conficker, but autorun worms aren't exactly new in and of themselves so this new behaviour following so close on the heels of my mentioning of it does seem a little bit troubling...
so if i am responsible for that particular feature, my apologies to, well, the entire internet and computer using public... i thought it was an obvious ploy, i assumed it had already been done... it was not my aim to give the bad guys ideas (if anything i'd rather be giving the good guys ideas - if only they'd listen)... i'd like to say that i've come up with safeguards against giving the bad guys ideas in the future, but short of keeping my big yap shut i really can't think of anything...
on the bright side, at least i didn't write and distribute proof of concept attack code that was later used in real malware like some folks i could mention...
what is autoplay social engineering?
autoplay social engineering is a subset of social engineering tricks that specifically utilize the autoplay dialog that windows normally presents when certain types of storage media are inserted into the computer...
related to autorun malware, autoplay social engineering assists in getting the malware executed in situations where autorun doesn't automatically launch the malware as soon as the storage media is inserted into the machine... when the autoplay dialog is displayed it presents the user with a list of options for how the user can view the data on the storage media (such as viewing a slide show if the media contains pictures, viewing a video on the media, opening the drive in explorer, etc) and can also include an option, specified in the autorun.inf file in the root directory on the media, that can literally be anything (including launching of malware processes)... this optional entry would appear at the top of the list and be selected by default when the autoplay dialog opens...
should the option specified in the autorun.inf file present itself as something it's not, such as showing the icon and description identical to that for opening the drive in explorer when it actually runs malware, then that represents a form of social engineering as it's tricking the user into doing something s/he doesn't really want to do...
back to index
related to autorun malware, autoplay social engineering assists in getting the malware executed in situations where autorun doesn't automatically launch the malware as soon as the storage media is inserted into the machine... when the autoplay dialog is displayed it presents the user with a list of options for how the user can view the data on the storage media (such as viewing a slide show if the media contains pictures, viewing a video on the media, opening the drive in explorer, etc) and can also include an option, specified in the autorun.inf file in the root directory on the media, that can literally be anything (including launching of malware processes)... this optional entry would appear at the top of the list and be selected by default when the autoplay dialog opens...
should the option specified in the autorun.inf file present itself as something it's not, such as showing the icon and description identical to that for opening the drive in explorer when it actually runs malware, then that represents a form of social engineering as it's tricking the user into doing something s/he doesn't really want to do...
back to index
Thursday, March 26, 2009
failure rates and the law of truly large numbers
probably the best known metric for measuring the effectiveness of an anti-virus product is the detection rate... it's something that's been around for a long time and there are frequent attempts to measure it...
i'm not about to try and suggest something to supplant that metric, just so you know - the detection rate metric has served us well for many years, even if there's a bit of confusion of what actually constitutes a detection rate, and even though there's controversy over how it should be measured and who is qualified to do so...
no, although failure rates are much more straight forward to measure, i'm not about to suggest that they're better in any way - i only want to bring them up in order to provoke thought...
let's say you're an average user and you have anti-virus protecting your computer (possibly at many different levels, like a desktop client, an email gateway scanner run by your email provider, etc)... let's further say that on average your anti-virus product fails to prevent your computer from getting compromised once every 5 years...
now, since it is possible to have anti-virus protecting you at multiple layers and with different optimizations at each layer it's important to define a failure as a piece of malware slipping past all of those layers... maybe that means incident response is required, or maybe you've got some other preventative control that stopped it after (not before) it slipped past your final layer of av prevention (ex. maybe you're a little less than average and are actually running without admin privileges that the malware needed to do it's dirty deed)...
i know what you security practitioners are probably thinking - 'where can i get this magical av product that only fails once every 5 years?'... i'm sure that would make your lives easier, wouldn't it... well right now it's just a hypothetical av product but later on we'll see what we can do...
so now let's say you're a security practitioner, you're part of the IT department of some company... let's further say that at this company you and your immediate coworkers are supporting approximately 2,000 of those same average users and you're using the same anti-virus technology... guess what - you can now expect to see an anti-virus failure once a day! (by the way, when one compromised machine goes out and leads to 5/10/50 more machines on your network getting the same malware, i call that the same event - it's the same failure)...
did the av somehow magically become less effective? no, of course not, it's the same technology - but in this enterprise scenario there are 2,000 times as many opportunities to fail per unit of time than there were in the single user scenario because there are 2,000 times as many users... malware compromise depends in part on decisions made by the user (which should be equally good/bad between the two scenarios) but also on exposure to the malware in the first place which, while it may be regular or even frequent, is an inherently random event... that means even if you could guarantee perfectly predictable (not necessarily correct, just predictable) decision-making from the users (note: you can't actually guarantee this), anti-virus failure events are still at least partially random...
highschool level math tells us that a pair of flipped coins are more likely to have one turn up heads than a single flipped coin would, and the same principle applies to anti-virus failure events - more trials means higher overall probability of the failure event occurring, and more concurrent trials means less expected waiting time between failure events...
now let's think about this in the real world - you security practitioners out there are in a perfect position to know how often your company's anti-virus fails and how many people you're supporting so what's the per-person failure rate of your av?.. at my previous employer we had (to my knowledge) one notable failure in a period of 2 years for a company size of about 20 people (and i helped clean it up)... that's a per-person failure rate of once every 40 years!... now i'm willing to bet that we were an anomaly, a statistical outlier, that the true per-person failure rate is more than once in four decades, but i'm also willing to bet that larger companies with 2,000 people in them do not suffer a new failure every single day - which means their anti-virus has a per-person failure rate that is actually less (and therefore better) than the magical example of once every 5 years...
so take an honest look at how often your anti-virus really fails on a per-person basis... one of the things i've noticed is that a lot of the people who are convinced that av isn't doing a good job anymore are people who are using enterprise experience as their anecdotal evidence - not realizing that the more users you bring into the picture the more the law of truly large numbers works against you... it's not that av actually fails often, it's that failure scales up (and that's true for all failure, not just av failure)...
i'm not about to try and suggest something to supplant that metric, just so you know - the detection rate metric has served us well for many years, even if there's a bit of confusion of what actually constitutes a detection rate, and even though there's controversy over how it should be measured and who is qualified to do so...
no, although failure rates are much more straight forward to measure, i'm not about to suggest that they're better in any way - i only want to bring them up in order to provoke thought...
let's say you're an average user and you have anti-virus protecting your computer (possibly at many different levels, like a desktop client, an email gateway scanner run by your email provider, etc)... let's further say that on average your anti-virus product fails to prevent your computer from getting compromised once every 5 years...
now, since it is possible to have anti-virus protecting you at multiple layers and with different optimizations at each layer it's important to define a failure as a piece of malware slipping past all of those layers... maybe that means incident response is required, or maybe you've got some other preventative control that stopped it after (not before) it slipped past your final layer of av prevention (ex. maybe you're a little less than average and are actually running without admin privileges that the malware needed to do it's dirty deed)...
i know what you security practitioners are probably thinking - 'where can i get this magical av product that only fails once every 5 years?'... i'm sure that would make your lives easier, wouldn't it... well right now it's just a hypothetical av product but later on we'll see what we can do...
so now let's say you're a security practitioner, you're part of the IT department of some company... let's further say that at this company you and your immediate coworkers are supporting approximately 2,000 of those same average users and you're using the same anti-virus technology... guess what - you can now expect to see an anti-virus failure once a day! (by the way, when one compromised machine goes out and leads to 5/10/50 more machines on your network getting the same malware, i call that the same event - it's the same failure)...
did the av somehow magically become less effective? no, of course not, it's the same technology - but in this enterprise scenario there are 2,000 times as many opportunities to fail per unit of time than there were in the single user scenario because there are 2,000 times as many users... malware compromise depends in part on decisions made by the user (which should be equally good/bad between the two scenarios) but also on exposure to the malware in the first place which, while it may be regular or even frequent, is an inherently random event... that means even if you could guarantee perfectly predictable (not necessarily correct, just predictable) decision-making from the users (note: you can't actually guarantee this), anti-virus failure events are still at least partially random...
highschool level math tells us that a pair of flipped coins are more likely to have one turn up heads than a single flipped coin would, and the same principle applies to anti-virus failure events - more trials means higher overall probability of the failure event occurring, and more concurrent trials means less expected waiting time between failure events...
now let's think about this in the real world - you security practitioners out there are in a perfect position to know how often your company's anti-virus fails and how many people you're supporting so what's the per-person failure rate of your av?.. at my previous employer we had (to my knowledge) one notable failure in a period of 2 years for a company size of about 20 people (and i helped clean it up)... that's a per-person failure rate of once every 40 years!... now i'm willing to bet that we were an anomaly, a statistical outlier, that the true per-person failure rate is more than once in four decades, but i'm also willing to bet that larger companies with 2,000 people in them do not suffer a new failure every single day - which means their anti-virus has a per-person failure rate that is actually less (and therefore better) than the magical example of once every 5 years...
so take an honest look at how often your anti-virus really fails on a per-person basis... one of the things i've noticed is that a lot of the people who are convinced that av isn't doing a good job anymore are people who are using enterprise experience as their anecdotal evidence - not realizing that the more users you bring into the picture the more the law of truly large numbers works against you... it's not that av actually fails often, it's that failure scales up (and that's true for all failure, not just av failure)...
Saturday, March 21, 2009
choosing a good password
recently i've seen two separate videos talking about the problem of choosing a good password - one with michael santarchangelo and one with graham cluley... what bothers me, though, is that they're both repeating relatively old ideas with their pass-phrase method...
here's a different approach to the password choosing dilemma:
don't
you heard me, don't... don't choose a password... the primary reason for people choosing passwords is so that they can have a password that they can remember... this is an obsolete requirement - not because people's memories are that much better (they aren't, if anything the opposite is probably true) but because we now use so many things that need passwords that there's no way we can remember different passwords for all of them and have had to adapt... the poor way most people have adapted is to re-use passwords so that there's less to remember, but the smarter way is to store them so that you don't have to remember them at all...
let the computer generate a password for you using a program like password safe, it will be superior to anything you could choose manually... then store the password in password safe because computer memory is also superior to yours... if it's a password you need when the computer isn't on or a password you need in order to get into the computer in the first place, write it down and stick it in your wallet... if it's a password you need at many computers, you can carry the encrypted password database password safe creates around on a USB flash drive (in fact, password safe itself runs quite nicely from a flash drive without needing to be installed everywhere you need your passwords)...
stop following old password advice that hasn't kept up with the times, adapt to the realities of the today and start using technology (even low-tech technology like a pencil and paper) to make dealing with the password problem easier...
here's a different approach to the password choosing dilemma:
don't
you heard me, don't... don't choose a password... the primary reason for people choosing passwords is so that they can have a password that they can remember... this is an obsolete requirement - not because people's memories are that much better (they aren't, if anything the opposite is probably true) but because we now use so many things that need passwords that there's no way we can remember different passwords for all of them and have had to adapt... the poor way most people have adapted is to re-use passwords so that there's less to remember, but the smarter way is to store them so that you don't have to remember them at all...
let the computer generate a password for you using a program like password safe, it will be superior to anything you could choose manually... then store the password in password safe because computer memory is also superior to yours... if it's a password you need when the computer isn't on or a password you need in order to get into the computer in the first place, write it down and stick it in your wallet... if it's a password you need at many computers, you can carry the encrypted password database password safe creates around on a USB flash drive (in fact, password safe itself runs quite nicely from a flash drive without needing to be installed everywhere you need your passwords)...
stop following old password advice that hasn't kept up with the times, adapt to the realities of the today and start using technology (even low-tech technology like a pencil and paper) to make dealing with the password problem easier...
the best laid plans of mice and men often go awry
by now news of the bbc's botnet blunder has spread pretty far... the bbc's actions seem to have violated the law, and there's no question that they were unethical and that prevx's complicity also points to an ethics problem in that company...
many people have written about it already, but alex eckelberry's point about the potential for unintended consequences in taking down a botnet reminded me of a discussion at securosis that i had intended to revisit here but never got around to...
the securosis post in question involved a proposal to set up some system by which an authority could shut down botnets - basically to nullify the legal and ethical hurdles that currently keep most malware researchers from taking down the botnets they're studying...
my two comments on the subject were as follows:
currently, ethical malware researchers steer clear of tampering with botnets or the machines they're on - if we change the rules of engagement, if the forces (whatever they may be) that currently prevent us from tampering with botnets went away and we started behaving like the bbc did then the malware authors would have to adapt and self-destructing botnets are an obvious technical approach to regaining the tamper-resistance they currently enjoy thanks to the good behaviour that makes the good guys so 'good'...
many people have written about it already, but alex eckelberry's point about the potential for unintended consequences in taking down a botnet reminded me of a discussion at securosis that i had intended to revisit here but never got around to...
the securosis post in question involved a proposal to set up some system by which an authority could shut down botnets - basically to nullify the legal and ethical hurdles that currently keep most malware researchers from taking down the botnets they're studying...
my two comments on the subject were as follows:
#
kurt wismer Feb 17
you make a compelling argument - botted machines are a public security hazard and some hazards are grievous enough to warrant unauthorized intervention…
i instinctively rebelled against this notion because i don’t like the idea of authorities mucking around on my computer out of some potentially misguided notion that they know better than i do… but i can’t find any flaw in the applicability of your analogy…
the only problem i foresee is that if the bad guys can’t hide their creations behind legal red tape then they’ll hide them behind something equally compelling, like commands to self-destruct and wipe the host machines (to get rid of evidence and also to just be mean) if the network is tampered with… this switch from legal to technical controls may mirror anti-tampering efforts in other domains… if they can figure out a way to make killing the botnet do more harm than good then it will be equivalent to the situation we’re in now and no change in law will affect such a technological adaptation…
#
kurt wismer Feb 17
@rich:
i’m not sure the good it would do would outweigh the bad… when 1,000,000 people suddenly have no operating system, what do you think will happen? steve balmer is already balding, the rest of his hair would be gone the instant microsoft started receiving support calls from all the victims… and that’s just the home users…
what happens when some of those machines are in the enterprise? or in government or military? what if they’re part of critical infrastructure? worse still if it’s in such machines in other countries - taking down the botnet could cause an international incident…
self-destructing botnets are something i wouldn’t want to touch with a 10 foot pole…
currently, ethical malware researchers steer clear of tampering with botnets or the machines they're on - if we change the rules of engagement, if the forces (whatever they may be) that currently prevent us from tampering with botnets went away and we started behaving like the bbc did then the malware authors would have to adapt and self-destructing botnets are an obvious technical approach to regaining the tamper-resistance they currently enjoy thanks to the good behaviour that makes the good guys so 'good'...
Sunday, March 08, 2009
ethical hacker not so ethical when hacked
one of the posts to catch my eye during my absence was this post on cd-man's blog about ethicalhacker.net getting compromised...
what struck me about it was that the folks at ethical hacker waited months to inform their membership that they'd been compromised and that users should change their passwords...
now, i suspected some months ago that ethical hacker had either had some kind of breach or had significantly changed their MO when i started getting spam at the address i registered with, but to find out that user's credentials have been in the hands of attackers for 8 months before ethicalhacker.net decided to warn anyone is simply outrageous...
i understand that no site is impenetrable so a breach of this nature is inevitable - i don't have a problem with that... i also understand that most of their users are probably using good password hygiene - however i also know that a surprising number of security folks probably don't... there are many people in the security world who, although they will enforce security policies rigidly within the enterprise, do not take anywhere near the same measures with their own systems at home and so most likely reuse passwords... these people were put in harm's way when the folks at ethical hacker chose sneakiness over transparency...
it's events like this that make me glad i use a different randomly generated password for each site (in addition to the different randomly generated email address i use for each site)... ethical hacker's name is now ironic, much like 'little john' or 'tiny', because they definitely aren't putting their users first...
what struck me about it was that the folks at ethical hacker waited months to inform their membership that they'd been compromised and that users should change their passwords...
now, i suspected some months ago that ethical hacker had either had some kind of breach or had significantly changed their MO when i started getting spam at the address i registered with, but to find out that user's credentials have been in the hands of attackers for 8 months before ethicalhacker.net decided to warn anyone is simply outrageous...
i understand that no site is impenetrable so a breach of this nature is inevitable - i don't have a problem with that... i also understand that most of their users are probably using good password hygiene - however i also know that a surprising number of security folks probably don't... there are many people in the security world who, although they will enforce security policies rigidly within the enterprise, do not take anywhere near the same measures with their own systems at home and so most likely reuse passwords... these people were put in harm's way when the folks at ethical hacker chose sneakiness over transparency...
it's events like this that make me glad i use a different randomly generated password for each site (in addition to the different randomly generated email address i use for each site)... ethical hacker's name is now ironic, much like 'little john' or 'tiny', because they definitely aren't putting their users first...
ok, i'll draw a bunny
yes, this is a fluff post, you have now been warned...
some of you may have noticed i haven't posted in a while... in fact it's been over a month since i last posted anything - my post archive has no entries for february at all... as some of you may recall, anti-malware is not my job - in fact security itself isn't really my job unless you count implementing security features in other software (and even then the only reason i'm the one doing it is because i'm the one who's really familiar with the concepts), so security in general and anti-malware in particular isn't my day job but rather something i've just always had a natural affinity for... that being said, sometimes you need to step back for a while, smell the roses, and gain some perspective, even when it comes to something you're passionate about... ergo, i've been absent...
but today i got an email from cd-man, checking up on me and letting me know that he's tagged me in some internet meme about drawing bunnies... now, i must admit i have a fascination with memes (for purely pragmatic reasons) and how better to study a meme than from the inside by participating in it so i figure why not give it a shot... thus i dug out my highschool sketchbook, an appropriate pencil, found a worthy subject and threw this together (if only i also had a scanner and didn't have to use a crappy digital camera to put it on the web)...
so now i've got to tag 3 people... hmmm, 3 bloggers - jonathan poon, costin raiu, and aaron walters...
some of you may have noticed i haven't posted in a while... in fact it's been over a month since i last posted anything - my post archive has no entries for february at all... as some of you may recall, anti-malware is not my job - in fact security itself isn't really my job unless you count implementing security features in other software (and even then the only reason i'm the one doing it is because i'm the one who's really familiar with the concepts), so security in general and anti-malware in particular isn't my day job but rather something i've just always had a natural affinity for... that being said, sometimes you need to step back for a while, smell the roses, and gain some perspective, even when it comes to something you're passionate about... ergo, i've been absent...
but today i got an email from cd-man, checking up on me and letting me know that he's tagged me in some internet meme about drawing bunnies... now, i must admit i have a fascination with memes (for purely pragmatic reasons) and how better to study a meme than from the inside by participating in it so i figure why not give it a shot... thus i dug out my highschool sketchbook, an appropriate pencil, found a worthy subject and threw this together (if only i also had a scanner and didn't have to use a crappy digital camera to put it on the web)...
so now i've got to tag 3 people... hmmm, 3 bloggers - jonathan poon, costin raiu, and aaron walters...
Wednesday, January 21, 2009
does conficker have a silver lining?
don weber posted an intriguing thought about the massive conficker worm actually making the internet more secure...
he's got some sound logic - it does shine the spotlight on the problem and give people who know what to do an opportunity to convince decision makers to do the right thing and that could certainly make people more secure...
trouble is i made the mistake of saying something similar in the previous decade... technically it was more along the lines of 'it would be good if X were bigger/more damaging because then people would sit up and take notice'... as you can imagine then along came something that was bigger/more damaging and people did sit up and take notice... where's the trouble with that you say? i got what i wanted, right?
wrong... a lot of people were negatively affected for what turned out to be a temporary lesson... i'm sorry to say but one of the observations i've made over the past 19 years of following the malware problem is that people largely do not retain the lessons of the past and thus wind up repeating history over and over again...
this case is likely not going to be any different - while don suggests that the efforts put forth as a result of this mass infestation are going to make future mass infestations harder he neglects to mention that there have been plenty of mass infestations in the past whose cumulative effects should have made mass infestation darn near impossible by now if the effect had any kind of staying power...
but the effect doesn't have staying power, it's short lived... there certainly is a window of opportunity for people to push through smart policy/technology changes, but the window is not large - take advantage of it now while it's still open...
he's got some sound logic - it does shine the spotlight on the problem and give people who know what to do an opportunity to convince decision makers to do the right thing and that could certainly make people more secure...
trouble is i made the mistake of saying something similar in the previous decade... technically it was more along the lines of 'it would be good if X were bigger/more damaging because then people would sit up and take notice'... as you can imagine then along came something that was bigger/more damaging and people did sit up and take notice... where's the trouble with that you say? i got what i wanted, right?
wrong... a lot of people were negatively affected for what turned out to be a temporary lesson... i'm sorry to say but one of the observations i've made over the past 19 years of following the malware problem is that people largely do not retain the lessons of the past and thus wind up repeating history over and over again...
this case is likely not going to be any different - while don suggests that the efforts put forth as a result of this mass infestation are going to make future mass infestations harder he neglects to mention that there have been plenty of mass infestations in the past whose cumulative effects should have made mass infestation darn near impossible by now if the effect had any kind of staying power...
but the effect doesn't have staying power, it's short lived... there certainly is a window of opportunity for people to push through smart policy/technology changes, but the window is not large - take advantage of it now while it's still open...
test branding fail
another fail, but of a different variety... thanks to pedro bustamante for bringing total protection testing to my attention...
total protection is a snake oil term that sends the wrong message to people and makes them believe they can be totally protected (which obviously they can't)... this is something people in the anti-malware industry should know already...
of course, you could say the same thing about mcafee - who i'm surprised don't own the trademark on this particular instance of snake oil, since they've got a product named total protection...
total protection is a snake oil term that sends the wrong message to people and makes them believe they can be totally protected (which obviously they can't)... this is something people in the anti-malware industry should know already...
of course, you could say the same thing about mcafee - who i'm surprised don't own the trademark on this particular instance of snake oil, since they've got a product named total protection...
anti-virus usage fail
how do you top a virustotal usage fail? you attempt to commit virustotal usage fail but use samples that aren't even malware in the first place...
that's what john strand did in a video embedded in daniel miessler's post "Metasploit 3.2 Makes AV Look Silly | DiD is the Only Answer"...
the premise may sound ok - you can create executables using metasploit that won't be detected by the (perhaps severely) cut-down versions of anti-virus products that is used by virustotal... supposedly this points to a problem with anti-virus technology in general, but ask yourself this - is it really a problem that you can create executables that virustotal can't detect? and if so, why?
is the output from metasploit malware? if it is then hdmoore is a bad man and should be stopped (and it's not like we can't find him)... i don't see a lot of people calling him a bad man, though, or suggesting he needs to be stopped - that says to me that metasploit and it's output are not malware or at least occupy that gray area between malware and benign software... as such, if these things aren't malware then why are we expecting anti-malware programs to detect them? the av world knows that if it ain't bad then you shouldn't be catching it and if metasploit output is bad then why aren't we doing more about it?...
if it's not malware then stop expecting anti-malware apps to do anything about it... if it is malware then go after the root cause (isn't that bejtlich is always talking about being the more effective strategy dealing with the malware problem?)...
ultimately, the video and the post it's in make a good point - that you shouldn't be relying on av as your sole form of protection - but the argument would be better served by using a legitimate av failure as an example instead... better still would be to take an approach that doesn't seek to tear down a largely successful anti-malware control in the first place - you can promote defense in depth without erroneously trying to make av look like it's useless... tearing av down does not actually promote defense in depth, it promotes the search for the next great anti-malware hope that we can replace av with - and that's not going to help anybody because all preventative measures (even whatever people replace av with) fail...
that's what john strand did in a video embedded in daniel miessler's post "Metasploit 3.2 Makes AV Look Silly | DiD is the Only Answer"...
the premise may sound ok - you can create executables using metasploit that won't be detected by the (perhaps severely) cut-down versions of anti-virus products that is used by virustotal... supposedly this points to a problem with anti-virus technology in general, but ask yourself this - is it really a problem that you can create executables that virustotal can't detect? and if so, why?
is the output from metasploit malware? if it is then hdmoore is a bad man and should be stopped (and it's not like we can't find him)... i don't see a lot of people calling him a bad man, though, or suggesting he needs to be stopped - that says to me that metasploit and it's output are not malware or at least occupy that gray area between malware and benign software... as such, if these things aren't malware then why are we expecting anti-malware programs to detect them? the av world knows that if it ain't bad then you shouldn't be catching it and if metasploit output is bad then why aren't we doing more about it?...
if it's not malware then stop expecting anti-malware apps to do anything about it... if it is malware then go after the root cause (isn't that bejtlich is always talking about being the more effective strategy dealing with the malware problem?)...
ultimately, the video and the post it's in make a good point - that you shouldn't be relying on av as your sole form of protection - but the argument would be better served by using a legitimate av failure as an example instead... better still would be to take an approach that doesn't seek to tear down a largely successful anti-malware control in the first place - you can promote defense in depth without erroneously trying to make av look like it's useless... tearing av down does not actually promote defense in depth, it promotes the search for the next great anti-malware hope that we can replace av with - and that's not going to help anybody because all preventative measures (even whatever people replace av with) fail...
Wednesday, January 14, 2009
my thoughts on benevolent botnets
pete lindstrom recently penned a post on the idea of benevolent botnet... it's not the first time i've seen this topic come, up - martin mckeay posted about a related idea of battling botnets with botnets (presumably one side of that fight would be benevolent botnets)...
my thoughts run something like this - implicit in the idea of the botnet is that the computers that make up the botnet are being remotely controlled without authorization from their owners and therefore no botnet can be considered benevolent...
if the collection of connected computers are being controlled without authorization then you're stealing cycles at the very least, as well as a certain amount of bandwidth in order to communicate with the command and control server...
if the computers are being controlled WITH authorization from their owners then you have a distributed computing project, not unlike seti@home or distributed.net - and you can't really call either of those botnets...
so much like the very act of self-replication makes supposedly good viruses bad, the very act of unauthorized remote control makes supposedly benevolent botnets malicious...
my thoughts run something like this - implicit in the idea of the botnet is that the computers that make up the botnet are being remotely controlled without authorization from their owners and therefore no botnet can be considered benevolent...
if the collection of connected computers are being controlled without authorization then you're stealing cycles at the very least, as well as a certain amount of bandwidth in order to communicate with the command and control server...
if the computers are being controlled WITH authorization from their owners then you have a distributed computing project, not unlike seti@home or distributed.net - and you can't really call either of those botnets...
so much like the very act of self-replication makes supposedly good viruses bad, the very act of unauthorized remote control makes supposedly benevolent botnets malicious...
virustotal usage FAIL
from rich mogull's post There Are No Trusted Sites: Paris Hilton Edition:
yes, boys and girls - in spite of my prior warning on the matter, in spite of didier stevens' thoughtful post on the matter, and in spite of hispasec's own post on the matter, people still don't get that virustotal is for testing suspected malware not anti-malware...
it doesn't matter if your sample size is 1 or 1000, using bad virustotal results to bolster the argument that av sucks (when it's well known that virustotal's results don't/won't match av user experience) is a big fat FAIL...
rich isn't the only one failing here, though, he's just the most recent example... 'incident handlers' at the internet storm center do this on a regular basis, as do quite a few others...
the devil's in the details folks, start paying attention... since the detective capabilities displayed in the context of virustotal do not represent the real detective capabilities of the products used by virustotal, what point can there really be to posting the detection rates (as dancho danchev likes to call them)? that's right, basically none - not only do they bear no relationship to what is conventionally thought of as detection rates, but also they are NOT accurate...
now repeat after me: virustotal is for testing suspected malware, not anti-malware...
The best part? Only 12 of 37 tested AV vendors catch the trojan. All of who that give me crap for hammering on AV can go away now.
yes, boys and girls - in spite of my prior warning on the matter, in spite of didier stevens' thoughtful post on the matter, and in spite of hispasec's own post on the matter, people still don't get that virustotal is for testing suspected malware not anti-malware...
it doesn't matter if your sample size is 1 or 1000, using bad virustotal results to bolster the argument that av sucks (when it's well known that virustotal's results don't/won't match av user experience) is a big fat FAIL...
rich isn't the only one failing here, though, he's just the most recent example... 'incident handlers' at the internet storm center do this on a regular basis, as do quite a few others...
the devil's in the details folks, start paying attention... since the detective capabilities displayed in the context of virustotal do not represent the real detective capabilities of the products used by virustotal, what point can there really be to posting the detection rates (as dancho danchev likes to call them)? that's right, basically none - not only do they bear no relationship to what is conventionally thought of as detection rates, but also they are NOT accurate...
now repeat after me: virustotal is for testing suspected malware, not anti-malware...
Wednesday, January 07, 2009
suggested reading
geez, i need an alarm clock to remind me to do this or something...
- PC Got a Virus? Consider Getting Help Offline - Security Fix
well it just goes to show, if you can't trust a suspect machine to report it's own infection state (as the saying goes) then you certainly should trust it for making online purchases - Multi-Layering and User Education: a random thought from AVAR | ThreatBlog
one of my favourite topics - user education, and an interesting framing to boot... user education as simply another layer in a multi-layered defense... not only does that correctly imply that it's inherently an imperfect control just like all the others, it plants it squarely where it belongs - along side all the other controls, all working in unison... - hype-free: Actively working against security...
this sound eerily familiar, but lets not talk about where i've heard this before... all i can say is i've always known it was a bad idea, and i don't care if the customer's departments don't co-operate with each other - either get buy-in from IT or go over their heads to force co-operation, but don't surreptitiously bypass their security defenses just because it's an inconvenience for you... - Andrew Hay » Blog Archive » Tactics Must Evolve
security pros need to be students of military history and tactics? hear hear... i know security isn't really like warfare but strategy and tactics are a much bigger part of security than some people wish to admit - ThreatExpert Blog: How to Defeat Koobface
great post - i always like to see people identifying exploitable weaknesses in malware - Scammers Evade Spam Filters by using Email ‘From’ Fields | TrendLabs | Malware Blog - by Trend Micro
i almost laughed when i saw this - it seems so obvious now, why hasn't this happened sooner? (or has it?) - iSpy an iPhone Spy - F-Secure Weblog : News from the Lab
well what do you know - mobile malware for the iphone... i know some people don't count these sorts of tools as malware, but this is the very picture of spyware, just like neo-call's spyphone or vervata's flexispy... - Roger Thompson: Awww.... puppies!
scamming with puppies... the bad guys are sinking to new lows... - Major Web browsers fail password protection tests | Zero Day | ZDNet.com
i've always said it was better to use a password manager that was separate from the browser and unable to respond to content on webpages (because some 3rd party tools are just a little TOO integrated) but now i actually have figures to point to show why - Lois Lane and the Craigslist fake landlord scam - Graham Cluley's blog
a super(b) example of scamming a scammer - Most Abused Infection Vector | TrendLabs | Malware Blog - by Trend Micro
always interesting to find out which methods of attack are the most active... right now it seems to be downloads (though apparently not drive-bys) and droppers (not surprised at all about that one)... - Is there no end to the AutoRun madness? | Zero Day | ZDNet.com
a good comparison of the autorun infection vector across multiple versions of windows - Graham Cluley's blog - Facebook data loss fiasco
i got one of the same emails graham talks about here - yes folks, facebook is training their users to be phishing victims...
Subscribe to:
Posts (Atom)