essential FUD

upon reading mike rothman's recent post on categorizing FUD i was struck with a rather surprising realization. not only has the much reviled APT suffered semantic dilution, but apparently so has the seemingly simple concept of FUD.

i say semantic dilution rather than semantic drift because, rather than taking on a new meaning, the apparent elimination of uncertainty and doubt from mike's description means that it's 2/3rds of the way to having no meaning at all. it seems that anything invoking fear is now some kind of FUD - but can that be true? are fear and FUD interchangeable? do we want to make them interchangeable? wouldn't we really only be saving a single keystroke in the process?

i don't agree with mike's characterization of FUD (which seems only fitting as mike doesn't agree with much i say). although i have tried to define FUD before, i've never gone into enough depth that it would contradict interpretations like mike's. that changes today.

if there is one part of fear, uncertainty, and doubt that could clear this all up if it weren't so often completely overlooked - one word that held a surprising amount of meaning - it would be:

AND

it's not fear, uncertainty, OR doubt, boys and girls, it's AND. we're talking about the intersection of the three, not the union. no single one of fear, uncertainty, or doubt qualifies as FUD on it's own. FUD requires the presence of all three. fear is only part of it. i'm tempted to say fear is only the beginning, but that's not true, something as yet unmentioned is the beginning and fear, uncertainty, and doubt are the consequences.

what's going on behind the scenes with FUD, what makes it such a bad thing beyond the simple fact that it's used as a manipulation, is that it introduces an inaccurate mental model that competes with superior ones and the results are rather insidious. mental models inform our actions. they allow us to predict outcomes and consequently allow us to make plans designed to control outcomes in our favour. they are a tool which allows us to effectively formulate strategies for satisfying our basic human needs.

unfortunately, mental models are never 100% complete. there are always holes, always missing pieces and weak points. these are what FUD models exploit in order to compete with existing mental models. obviously if someone's mental model is more complete and internally consistent they are less susceptible to FUD because they "know better" than to fall for it, but unfortunately many people have mental models that are largely incomplete so a FUD mental model has a good chance of taking hold and effectively competing with the model the person had.

that competition is a problem. it causes a person to be confused, to question what they thought they knew. this is the uncertainty - the U in FUD. subsequent to that a person would then logically start to distrust the sources that had informed them and helped them form their previous mental model. this makes it difficult for those or similar/consistent sources to fill in blanks in the original mental model and thus interferes with a person's ability to build a better mental model. this is the doubt - the D in FUD. finally comes the logical conclusion that if what one thought one knew was wrong then the steps one took based on that knowledge could also be wrong. the consequence of that being that the person is no longer prepared or capable of handling something they needed to handle and the emotional reaction to that is fear - the F in FUD.

recapping then, a more in-depth account of FUD is that it is a communicated inaccurate mental model that causes:

• uncertainty about what you know
• doubt in those whom you learned from or could learn from in the future
• fear that you're no longer going to be able to satisfy some need that you have

it should be noted that that same fear can result when you fill in some of the blanks of an incomplete mental model. what differentiates that from FUD, however, is that although fear can result in the short term, there's no uncertainty or doubt. building a better, more complete mental model results in a person being better able develop strategies to satisfy their needs in the long run and is thus beneficial, as compared with FUD which stymies a person's ability to develop effective strategies.

now the argument could be made that mike himself was spreading FUD about FUD (meta-FUD). a model of FUD that seemingly allowed for anything involving fear to be called FUD would certainly make people uncertain about what they previously knew about FUD and doubt the people that had previously informed their opinions about FUD. and since mike also opened the door for the possibility of good FUD and suggested that FUD was more widespread than one would have otherwise thought (as a consequence of dropping 2/3rd's of the requirements), there would certainly be room for people to be concerned that they no longer knew how to navigate the sea of FUD mike was depicting and thus be afraid of getting duped.

on the other hand, however, the argument could also be made that mike's model of FUD is simply incomplete (seemingly missing uncertainty and doubt) and that what might appear to be meta-FUD is actually inaccurate conclusions drawn as a result of missing pieces of that model.

i'm not going to accuse mike of spreading meta-FUD, primarily because i feel accusations of FUD spreading should be reserved for those who should know better than to believe the model they're communicating. those spreading inaccurate or inferior mental models unwittingly should certainly be notified, however.

it's not a detection rate

(this has been stewing for a little while now)

look, i realize that virustotal performs a series of detection tests in order to get it's results. i also know that it expresses those results as something that looks a lot like a rate. but as much as you may want to, as much intuitive sense as it may make, don't mistake those results for a detection rate.

first, let's deal with the elephant in the room. in the anti-malware world, the term "detection rate" has already been used for something else. traditionally a detection rate is arrived at by testing an anti-malware product against many malware samples in order to see how good the product is at detecting malware. this is what detection rate has meant for somewhere on the order of two decades, and it bares little relation to what virustotal does.

the inverse of that method, to test a single sample against many anti-malware products in order to see how bad anti-malware technology is, is in theory similar to what virustotal does but it differs in two very important ways:

1. the purpose of virustotal's test is to give the user an indication of whether the submitted sample is likely to be malware rather than to determine how bad anti-malware technology is
2. the way virustotal uses anti-malware products in it's testing does not lend itself to an accurate determination of whether a particular product can detect a particular sample (as i've discussed over and over again, and as hispasec themselves mention)

i mulled over the idea that even though it's not a detection rate, and it's not even an inverse detection rate, maybe it could at least represent the lower bound of an inverse detection rate since the most obvious methodological problems (if we were trying to interpret virustotal results the way some people seem to want) would lead to detection capabilities being under-reported. even if it could be called that, however, an inverse detection rate lower bound is so abstract that there's little benefit in using the term with the general population.

i'm tempted to suggest people just call the results a score, but when you compare "virustotal results" with "virustotal score" you realize you're not really saving much more than 2 keystrokes by using that term. there's no intuitive meaning to be had in either of them. it seems the kind of intuitive meaning that people hope to convey by calling it a detection rate simply can't be had.

as such, whether you're an recognized and well regarded expert like dancho danchev who explicitly calls it a detection rate, or brian krebs who tries to infer meaning about anti-malware technology by looking at the results, or even if you just someone who relies on such experts for their accurate analyses and informed opinions - remember that virustotal is for testing samples not anti-malware products. don't try to infer meaning from virustotal test results about something virustotal isn't meant to test. you will most likely fail.

why the epsilon breach shouldn't be an issue

the epsilon breach (where an email marketing company that does business with a veritable who's who of big name corporate brands and financial institutions lost the names and email addresses of the customers of those companies) seems to be on everyone's mind recently, and to tell the truth i find that kind of strange.

it's not as though i'm under any illusion about it not being able to affect me. a colleague of mine at work got a notification about the breach affecting him so while i haven't received one yet myself, the possibility of receiving one certainly exists. yet i find myself completely unconcerned about the possibility. why? because i took steps to protect myself proactively (steps my colleague knew he should have taken such that now wishes he'd been more vigilant).

i have been using disposable email addresses since the fall of 2004. with them i've managed to keep any email accounts i created after that point completely spam free for the past 6 1/2 years, i've come up with a sender authentication protocol to foil phishing, and as it happens i've recovered from email breaches in the past in mere moments.

and that's the reason a breach like epsilon is a non-issue to me. not only is it old hat, recovering is as simple as logging into the disposable email provider and clicking disable or delete (depending on the provider) for each compromised address, and then going on about the rest of your day.

it's dead simple to recover from the breach of something when that something happens to be disposable - you simply dispose of it. what i don't understand is, why aren't more people and especially more security practitioners doing the same thing? why hand out your real personal contact information like candy on halloween if you don't have to (and believe me, you don't have to)?  even if you decide you still want to do business with these companies who saw fit to hand your contact information over to a marketing company (hey, you're already their customer, why do they need to keep trying so hard to sell to you), it's a heck of a lot easier to make a replacement disposable email address than it is to make a replacement real email address. just a couple of clicks and some random typing (or just mash keys if you prefer); no captcha, no verifcation, no profile info, you filled that all out when you created an account at the disposable email provider in the first place.

cory doctorow gave a short talk about kids and privacy and he mentioned that they're being trained to not value their privacy, in part by over protective parents who prevent them from learning how to protect themselves. i don't think kids are the only ones who've been so trained. one of the most regrettable schools of thought that i've seen displayed from users all the way up to security pros is the one that says 'they are (or are supposed to be) protecting me'. there is a profound absence of self-reliance in favour of letting protection be the responsibility of someone else.

most people wouldn't hand their phone number out to every tom, dick, or harry they meet on the street, but when it comes to email addresses somehow people think the rules are different. they trust everyone who asks for it and expect everyone to protect it for them instead of protecting it themselves. this is an absurd position to take, but authorities (ie. people who are supposed to know better) have groomed the masses to systematically take just that position when it comes to anything that has to do with online protection.

i'm not holding my breath but, considering the scope of the epsilon breach, maybe some people will start to think

well if you're going to protect me from the bad guys, who's going to protect me from you?

i know, i'm probably being too optimistic, but surely some people out there will see this incident and realize how truly pervasive the mishandling of personal information is by the people we entrust it to. dozens of companies handed that data over to one completely unnecessary entity which then became a single point of failure, and because most people weren't protecting themselves from those companies (either their intentional bad acts or their ineptitude) many people are now at much greater risk of falling victim to targeted phishing and other related attacks.

a clever reader would probably realize that entrusting your real email address to a disposable email provider is still expecting that provider to protect it for you. the thing is, instead of trusting many entities with your data, under this model you're only trusting one. you also don't have to trust them with the same address you use for personal correspondence (which would be the hardest kind of address to change); i certainly don't.

community watch experiment

this is just a heads up about an experiment i'm trying out. i have no idea if it will prove useful; but if you were at all interested in the discovery that mcafee had partnered with a malware vendor, especially if you wanted to say something about it but felt like you couldn't, this experiment was cooked up with you in mind.

basically, if the industry can't police itself then it seems like the next logical group to shoulder that burden is the anti-malware community. i'm proposing something like a neighborhood watch, and if one of you sees something then please try and find a way to say something - i'm willing to help if i can.
 

the covenant is broken

one month ago i published a blog post excoriating mcafee for being involved with a firm that creates and sells malware. for one month i've been waiting - not for a reaction to my own post, but a parallel reaction from the industry to the revelation that mcafee was involved with malware creators. i have been underwhelmed by the response (or lack thereof), and somewhat overwhelmed by the implications.

take a moment to let the AV industry's silence on this matter sink in. what does it mean? does it mean that they can't say anything because they've all got similar skeletons in their closet? or does it mean they're just not interested in capitalizing on that sort of thing anymore?

you see, for a long time there's been a persistent rumour that AV vendors don't just partner with malware writing companies, they hire malware writers outright. the AV vendors, of course, claim that that doesn't happen - they claim to have a policy against hiring malware writers and they say not to just take their word for it because their competition would take advantage of such ethical lapses if they were ever to occur.

they weren't just blowing hot air, either. making an example of an anti-malware company that hired a virus writer has happened in the past (thank you f-secure), so we know that such self-correcting controls have previously been in place. we were supposed to trust AV companies because they were financially motivated to do the right thing. every company had something to lose if they misbehaved and every other company had something to gain if they caught someone misbehaving.

but now the revelation that mcafee works with a malware writing company comes along and nobody has anything to say. well, to be specific, no company has anything to say (since i know there are individuals who felt strongly about this but may not have been able to speak for their employers). it was the job, the duty, of every member company in the anti-malware industry to act as a watchdog for the industry in case things like this happened, and you all failed. each and every one. one month later is too late to strike - the opportunity has passed - the iron is no longer hot.

the industry was supposed to be policing itself, but that no longer seems to be happening. without that, all we have is their word that they should be trusted, but those are just words. nothing but sweet, sweet words that turn into bitter orange wax in my ears (to quote futurama's philip j. fry). without action it means nothing.

the industry's accountability is gone. we can't honestly believe they're still policing themselves now. they used to adhere to and enforce the anti-malware community's standard of ethical behaviour. it's important to draw a distinction between the anti-malware community and the anti-malware industry at this point. although there has always been significant overlap, there has also always been those who were part of one set but not the other. obviously i'm not in the anti-malware industry, and i can think of a number of people who were members of the community long before they became part of the industry. on the other side, do you think HR is staffed by anti-malware community members? the legal department? upper management may have a few here or there, but for the most part they're just ordinary business folks. increasingly, the anti-malware industry is representing business interests instead of the values and ideals of the anti-malware community. the community's influence in the industry has been gradually waning up to this point where there's no one left who can realistically hold them accountable for violations of the community's standard of ethical behaviour.

they can still be held accountable on technical grounds, i suppose, but for how long? anti-malware testing was in a bad state for a while - AMTSO has been helping to elevate the quality of testing, but does the anti-malware industry (which is increasingly losing touch with the anti-malware community) have too much influence over the goings-on there? ideally the inclusion of both the anti-malware industry and anti-malware testing industry should create a balance. the testing industry has an understandable bias towards the more practicable approaches to testing (they have limited resources, after all) and a strong motivation to not appear to be going to easy on the vendors. the vendors, on the other hand, have insights into the inner workings of their products which are sometimes necessary to understanding and eliminating certain sources of testing bias and a strong motivation to perform well on tests. this should create a balance that forces both sides to take harder but ultimately superior paths. as the industry moves away from ethical accountability in favour of business concerns, it stands to reason that they may start to move away from embracing technical accountability as well - and realizing their input in AMTSO feeds back into a system that enables technical accountability, they may try to game the system for their own ends.

this highlights yet another problem. not only does the industry itself become suspect, so does everything it touches. it's not just accountability that's gone, it's credibility as well, and that lack of credibility can be toxic to others.

when the anti-malware industry no longer represents the values and ideals of the anti-malware community, when the bottom line takes priority over everything else, the result is bad for everyone. it's bad for the users because they will eventually have little left but to choose between crappy products in pretty boxes. it's bad for the anti-malware community within the industry because their jobs will cease to be fulfilling and they will be increasingly disturbed by the actions of their employers. it's even bad for the anti-malware community outside the industry simply because of association and the failure of most people to recognize any distinction between the industry and community. this isn't something that happens overnight. this isn't something that started one month ago. it's been going on for a while and you community members in the industry are all frogs in a pot that is being slowly brought to a boil.

i don't know how to correct this. i don't even know if it can be corrected (damage has already been done, and you can't always go back to the way things were). i don't pretend to have those kinds of answers. if i had to guess, i would guess that turning the industry around and getting back on course would take as much influence as the community can muster. full recovery may not be possible, but is not trying really an option? an alternative may be to restore accountability through external sources, but given the particulars in play (a company that sells malware to a nation state), that would involve scrutiny from other nation states and being investigated by scores of foreign nations on an ongoing basis doesn't sound appealing.

there can be no credibility without accountability and there can be no accountability without consequences. that house of cards depends on consequences and as near as i can tell there have been none.

ethical conflict in the anti-malware domain

forgive my silence over the last little while. motivation to blog sometimes isn't easy to find. as time wears on, fewer and fewer things get under my skin enough to drive me to rant (is that what it means to mellow with age?). but since you're reading this i think you can guess what this post infers.

five years ago i wrote a post about what i perceived as an ethical conflict in the anti-'rootkit' domain. it detailed the actions of two of the most notorious names in stealthkit research, jamie butler and greg hoglund, and how they were profiting from making a particular niche of the malware problem more popular (and thus, inevitably a bigger problem).

one of the things i pointed out was that symantec was working with a start-up company (komoku) that had jamie butler (author of what was at one time one of the most widely deployed stealthkits around) as it's chief technology officer. i thought the fact that an anti-malware company was in bed with a company that hired such a high profile malware writer deserved at least a moment of reflection, considering the hard-line stance anti-malware companies take on hiring malware writers themselves. at the end of the day, mind you, that start-up was focused on prevention so maybe the argument could be made that mr. butler had or was trying to reform in some way. (mr. butler has since moved on to mandiant, along with his disciple {the FU2 to butler's FU} peter silberman)

when i read earlier this past week that another anti-malware company (mcafee) had been working with greg hoglund's company (hbgary) i thought it an interesting historical footnote but paid little attention to it beyond that (though, if i had remembered that mcafee had once been pointing fingers at rootkitDOTcom, maybe the hypocrisy would have stood out more). after all, little attention seemed to be paid to such connections five years ago so why should this time be any different? well, that was before i knew what hbgary was in to.

apparently, on top of the legitimate work that one can find out about by visiting the hbgary website (which of course i won't link to), it appears that hbgary also writes and sells malware for fairly large sums of money. the customers for their malware include the government/military but might not stop there. even if that set of customers does stop there, hbgary appears to be in the high-end commercial malware business.

so where does that leave mcafee? it leaves them in bed with commercial malware writers. while AV companies have been proclaiming for decades that they don't and won't hire malware writers, apparently they don't have to. they can simply partner with the boutique security shops that do. clearly they are not picking their business associates as carefully as they are their actual employees.

and then there's the claim that surfaces from time to time that AV companies won't make special provisions to keep malware deployed by the authorities from getting detected. what's the point of making such a claim if you're just going to turn around and do business with the company that may very well be making said malware?

how many other AV companies, besides mcafee, were or are in bed with hbgary? how many are in bed with companies LIKE hbgary? where's their ethical high horse when it comes to partnerships? why wasn't the "malware writers need not apply" policy updated when commercial malware became the norm and presented the loophole we see before us today?

some AV companies are rewarding malware writers financially. it may not be in the ways we traditionally thought of, but with the #2 company in the industry involved in this practice (and arguably the #1 company as well, depending on where you want to draw the line), the end result is AV companies contributing to the commercial success of malware writers, and that is not ok at all.

brain - a first in so many ways

i've seen a couple of articles now about this being the 25th anniversary of the computer virus known as brain.

brain was the first PC virus in the wild. it was the first bootsector infector. it was the first stealth virus.

supposedly it was created in the (somewhat hypocritical) hopes of attacking software piracy, so the history of intellectual property maximalism has a particularly odious chapter to add.

the thought occurred to me, however (and i'm probably not the first but i haven't seen this said anywhere that i can remember), that if the stated motivation behind the virus is correct then brain is, on top of everything else, the first commercially motivated malware. before zeus, before gpcode, before adware, before the porn dialers there was the brain virus intended to get people to contact the virus' manufacturer for support.

how do you get to the top?

so how do you get to the top? well, if you're an anti-virus company it stands to reason you get there through technical excellence (yes, i can hear you snickering from here). of course if you have technical excellence then it also stands to reason that your people know what it is they're talking about when they go and say something about malware in public.

specifically, what i and many other people expect is that people working for the #1 anti-virus company to at the very least know the difference between viral and non-viral malware. those kinds of basics seem like they should be prerequisites for achieving technical excellence in the anti-virus industry.

apparently that is expecting too much, since some people (in the industry, no less) are still using the term 'virus' as the umbrella term instead of the more accurate term 'malware'. i'm not sure exactly when it happened, but at some point i started hearing more terminology misuse from media sources within the industry than i hear from general media sources in the world at large.

to say that cancels out any willingness i might have had to suspend disbelief about the question of technical excellence is an understatement.

now one explanation i could entertain is that this is actually part of a very clever plot to keep the public confused and disoriented. governments long ago figured out that it was easier to control their subjects if they kept them stupid and uneducated. it doesn't seem unreasonable to suppose that corporations might make use of similar tactics. the foundation upon which greater understanding and ultimately greater self-reliance is built on is an accurate and consistent body of knowledge about the topic at hand. authoritatively using terms where they don't belong unquestionably undermines the process of developing that body of knowledge. it is precisely the type of tactic i would expect if corporations were trying to keep the masses easily manipulated.

that being said, i'm still prone to give the benefit of the doubt. never attribute to malice that which can easily be explained by incompetence. of course, since that reflects poorly on the possibility of technical excellence, that still leaves open the question of how one can get to the top and stay there.

without technical excellence being the driving force to keep the top players on top, we eliminate the possibility that the system is a meritocracy - or at least if there is a meritocracy, it's not the merits of the technology that are important but rather the merits of the efforts to manipulate people into thinking their technology has the most merit. that's called marketing. in essence, it's the best manipulator, not the best technology, that wins.

(though a system that rewards manipulation seems like it should eventually evolve into one that actively tries to keep people stupid in order to manipulate them more easily)

revisiting the 3 preventative paradigms

i've been thinking about the 3 preventative paradigms lately [actually i found this languishing in my drafts pile since jan '09].

framing the 3 preventative paradigms

in the ideal case:

1. a blacklist blocks access to a protected resource for things/actions that are bad
2. a whitelist blocks access to a protected resource for those things/actions that are not good
3. a sandbox blocks access to a protected resource unconditionally, offering a comparable low-value alternative resource as a surrogate

as you can see, this covers all conceivable options except the degenerate case of no prevention where access to the protected resource is not blocked under any circumstance (though realistically we can ignore this case when we're talking about prevention).

balancing the 3 preventative paradigms

the world is not an ideal place, however, and those cases cannot be implemented perfectly:

1. the halting problem prevents us from implementing a perfect blacklist and limits us to only blocking things/actions that are known to be bad, thus leading to the so-called reactive nature of blacklists
2. while the halting problem does affect whitelists in the same way, whitelists actually benefit in a way from being limited to only known things/actions. however the generality of interpretation prevents us from implementing perfect whitelists (as the security world is bound to discover when whitelisting finally crosses the chasm) because we will only ever be able to apply application whitelisting to known program types and thus will have to react whenever we discover a new program type being abused.
3. while the generality of interpretation may make it difficult to know when a sandbox needs to be used, what prevents sandboxes from being perfect when they are used (baring implementation failures that lead to unaided sandbox escape) is the need to share data (across the barrier erected by the sandbox) that is inherent to the division of labour, not to mention a variety of other useful and interesting things we do with computers.

thus with blacklists handling everything known to be bad, whitelists handling everything known to be good, and sandboxes handling everything in between, one might naively consider prevention to be a done deal; but with each one having problems that the others can't fully compensate for there will always be those edge cases that slip through and demonstrate that prevention is only the beginning of what a defender must consider.

expectations for 2011 and beyond

first, this is not prediction or forecast post. this is only a tribute.

no, seriously i hate those posts, they are annoying and i can't imagine being full enough of myself to actually try to prognosticate on what the future might bring.

that doesn't mean i don't have certain expectations for the future, however (though i can't really pin down time frames like those fortune-telling bloggers can).

as far as attackers go i expect that i'm going to disappoint you by not saying what i expect to be the next big thing. long time readers know i can be sensitive about giving the bad guys ideas and i certainly don't want to direct them towards new and annoying avenues of attack.

of course even if i did give them ideas, i'd still expect to mostly see more of what we've already seen - especially more of the things we started seeing this year. attackers seem to change in response to 5 basic influencers

1. changes in user behaviour: this can be either changes that are meant to thwart attacker (which happen at a truly glacial pace) or adoption of technologies (like twitter for example) that provide attackers with new opportunities.
2. new efforts by the security industry or authorities to thwart attackers: literally anything that disrupts the status quo for attackers fits in here. reputation systems that treat new unknown things as suspicious would be one example. new cooperative efforts to take down malware gangs would be another.
3. changes to the computing platform itself: this is pretty strongly related to user adoption of new technologies, but i felt with the way the dominant computing platform seems to be shifting away from personal computers and towards mobile computing devices, the opportunities this would afford attackers deserve be highlighted.
4. changes to the connectivity of devices: there's little doubt about how big an impact the broad adoption of the internet had on self-replicating malware like viruses and worms and later on distributed malicious computing like botnets. as connectivity continues to change and frankly increase between all sorts of devices it stands to reason new opportunities will present themselves to attackers.
5. motivational evolution: first it was fame, then fortune, and now we are starting to see a shift towards power being the motivating force behind attacks. there may even be something that comes after the fame/fortune/power triad but that would be too much like making a prediction.

all of those things happen at a pretty slow gradual pace, however, which is why i'm not expecting huge upheavals in the modus operandi of attackers. #2 is probably the only one with the potential to really be punctuated.

now while i may not be keen on giving the bad guys ideas, giving the good guys ideas i'm not nearly so shy about.

i expect to see facebook do something about all the scams. the scam pages and apps are turning facebook into an untrustworthy environment, and in an untrustworthy environment people are less apt to share, which means they're less apt get a real benefit out of facebook, which in turn means they're less apt to use it. i can't imagine how facebook could possible afford to just sit back and let that happen so i expect them to take some kind of action - i have no clue if it will be effective, however.

now that sandboxing and whitelisting are catching on (and in fact 1 well known company seems to have implemented all 3 of my 3 preventative paradigms; oh heck, let's not be coy, kudos to kaspersky internet security - i'm not a customer but at least somebody seems to have either been listening to me or thinking along the same lines) i expect that people will gradually start adopting these technologies in larger numbers (the sandboxes will probably have an advantage since they're getting embedded inside client apps) and maybe even start to realize that these technologies also are limited just like blacklists are. and THEN, maybe i'll have reason to start talking more about strategies for when prevention fails. we can only hope.

speaking of hope, now that at least one vendor has covered the 3 preventative paradigms in some fashion, would it be too much to hope that vendors start looking at the other parts of a proper defensive strategy? prevention is only the first part of the PDR (prevent, detect, recover) triad (which itself seems to me to be incomplete).

back to expectations, i expect to continue to see more examples of authority being exercised - both in official and unofficial capacities - in order to thwart and even arrest attackers. i hope (oh, am i diverging again?) to see greater appreciation for the fact that legislation on it's own has little value. rules mean little if they aren't enforced and enforcement requires detection of violations, attribution, and often (where official authorities are concerned at least) cross-jurisdictional cooperation. i expect at least someone will be highlighting the importance these things played in whatever successes we have and hopefully (there i go again) more attention will be paid to them.

i expect to see some more individual or community-based assistance given to those who exercise authority, probably in the form of detection and/or attribution, much like brian krebs has famously done on more than one occasion.

i also expect, unfortunately, to see people continuing to whine about how AV software isn't effective at anything anymore.  i expect i will continue to make jokes about driving screws with hammers in response.

i expect to see the heterogeneous nature of the threat landscape continue to be underestimated by such verbiage as "today's threats" and "yesterday's threats" (as if yesterday's threats weren't threats anymore).

i expect to hear more about stuxnet. maybe even something that doesn't stretch the limits of credulity (a worm, spreading stealthily for over a year, only managed to hit it's target after it's notoriety reached it's peak???).

i expect i'm going to be holding more people's feet to the fire over marketing bullshit and snake oil peddling.

finally, because these aren't predictions, i expect at least some of these expectations will not be met - at least not in the short term of the upcoming year.

getting the wrong message across

it's that time of year again, jack frost nipping at your nose and chestnuts roasting on an open fire. and while we have that fire handy, lets hold some feet to it, shall we?

see there was a post about our favourite type of malware (the virus) published on the panda security support blog by javier guerrero díaz that seems to have a number of issues that need addressing. let's jump right in.

to start with there's the issue of terminology misuse:

In fact, we still use today the term “virus” to refer to any type of malware in general, when reality shows that, except for the occasional surge, the number of viruses in circulation is much lower than that of Trojans, for example.

the public has already started to pick up the use of the term malware as an umbrella term, replacing it's previous misuse of the term virus. while javier did hint at the inaccuracy of calling all malware viruses, it would have been better to not suggest that "we" (meaning the folks at panda, including himself) still misuse terminology that way. it makes it seem ok to be sloppy with the terms (something which ultimately leads to confusion amongst those who don't know better). i would hope that technically oriented folks were more precise in their word choice.

next was some over-generalization about worms:

Computer viruses differ from other malware specimens like Trojans or worms in that the latter do not need a host to spread.

not all worms are free from the requirement of a host. win32/ska (also known as the happy99 worm) for example must infect the wsock32.dll in order to send itself over email.

there was also some over-generalization about the complexity of viruses:

Also, this characteristic makes them more complex to develop as a computer virus must know the internal structure of the file it tries to infect in order to be able to install on it.

not all viruses need to know the internal structure of the file they're infecting. overwriting infectors (which destroy the original file rather than trying to preserve it) and companion viruses (which don't actually alter the original file at all) have no such need, nor i think do macro viruses.

on top of complexity, there was also some over generalization about the scope of virus infection:

Finally, given that viruses affect all executable files on the system...

not all viruses affect all executable files on the system. some (perhaps many) are much more selective. lehigh, for example, only infected command.com. quite a few affect files that most people would not consider executable (macro viruses for example go after documents instead of executables).

i understand that the post was intended for those less familiar with the subject of viruses and malware, but the problem with over simplification is that there's no agreed upon degree to which things should be simplified. the consequence of this is that everyone presents different 'facts' and that confuses the people you're trying to explain things to. i genuinely believe it's possible to explain things to people in such a way that they can understand you without sacrificing technical accuracy. it takes effort, and i'm certainly not going to suggest that i succeed in reaching this goal in all circumstances, but at least i don't give up trying. if we accept the sacrifice then we have to accept that people will never really understand what we're talking about because we don't give them the power to do so.

finally there is the market-speak that makes me cringe every time i see it:

Any Panda Security solution will keep your computer free from viruses and other malware.

panda's *tools* (if it's really a solution, what problem does it solve?) will not keep users' systems virus free. they may keep them mostly virus/malware free, but there will always be exceptions capable of slipping through.

i've long despised the use of the term "solution" to describe things that are better presented as tools. it's a trick used by marketing to make people believe they're getting the impossible dream - perfect protection. to see these words written by someone in R&D makes me think somebody's been drinking the marketing koolaid.

worse than that, however, is the reference to keeping systems virus/malware free, without qualification or caveat. this is one of the hallmarks of snake-oil in the anti-malware industry; and guess what, when i went searching through my archives looking for examples of this i found one - involving panda! is there something in the water? is it a language thing? do i have to go looking through my archives for the intersection of panda and snake-oil to see if there's a pattern emerging?

short thought on sandboxing

jeremiah grossman recently penned a guest post for zdnet extolling the virtues of sandboxing. i've made no secret about the fact that i'm also a fan of sandboxing (though i'm not entirely on board with jeremiah's depiction of it with regards restricting things - that verges too close to behaviour blocking for liking) but the sandboxing jeremiah was referring too was the kind that is built into applications as a feature.

not too long ago posted about sandboxes being added to all sorts of apps and wondered (well, suggested) that such sandbox sprawl might not be the best way to go about things. jeremiah's observation that adding sandboxes to apps changes the game from a one exploit show to a two exploit show made me realize another reason why relying on the application's own sandbox is less than ideal - the attacker knows exactly which sandbox they have to escape from.

by contrast, with a separate stand alone sandbox, an attacker wouldn't necessarily know which sandbox is involved and would then need to develop escape exploits for multiple sandboxes and try the shotgun approach, firing them all at once and hoping for the best.

i do believe i'll be sticking with the stand alone sandbox. it seems to have the tactical advantage.

who knows what the future may bring?

who knows what the future may bring? well lots of people seem to think they do, and bruce schneier even goes so far as to predict what security will look like 10 years from now. much like long term weather forecasts, he is almost certainly wrong - at least i hope he is, because the picture he paints is distinctly dystopian.

no, that's not just an interpretation - a future where we the users are viewed as parasites living off the life-blood of corporations is not a happy shiny place to live. i can certainly see where he's coming from, though, as the beginnings of that are already visible with such schools of thought as the one that refers to users as product (i.e. we aren't facebook's customers, we're they're product). we are being increasingly objectified and devalued by corporate interests. the entertainment industry (and let's not forget their associated lobby, as the group is now as much a political force as they are a corporate one) is certainly leading the anti-consumer charge in the quest to justify their sense of corporate entitlement - but unlike bruce (who is himself part of the corporate machine) i have faith that society will eventually tip the scales back towards our favour.

we've already seen a time when businesses had all the power and the little guy was at their mercy. it happened during the industrial revolution. we fought back. we won. we outnumber them and they can't exist without us (while human history proves we can exist without them). to call us, rather than blood-sucking corporations, the parasites is to ignore nature in favour of business. that kind of backwards world view was not then and is not now a natural one and nature is something you cannot beat.

but beyond my faith in humanity, i also think schneier is wrong because he's misunderstanding the signs he's reading. for example, referring to iphones as special purpose computers instead of general purpose ones and citing them as evidence of the demise of the general purpose computer demonstrates that bruce hasn't the foggiest notion of what the distinction between a special purpose and general purpose computer really is. what we may well be witnessing is the end of the personal computer in favour of the mobile computing device, but that is an entirely different matter with entirely different repercussions. for one thing, a world without general purpose computers is a world without the world wide web. it is a world without iphone apps, a world without game consoles, a world without software. the iphone may exist in apple's walled garden, but i can (and do) get the same limitations on my PC using application whitelisting. that doesn't turn my PC into a special purpose computer any more than it does the iphone - it just makes it locked down.

so long as the computer is technically capable of running arbitrary code (which is exactly what happens when you install an iphone app or visit a website that has javascript or flash or any of the other wonderful interactive technologies out there) it is a general purpose computer (it satisfies what fred cohen referred to as the generality of interpretation). a world without general purpose computers is very, very hard to imagine. bruce, thinking the difference between special and general purpose computing can be illustrated as the difference between an iphone and a PC, sees a world that technically isn't much different from our own. but the difference between special and general purpose computers is more accurately illustrated as the difference between a cheap simple hand-held calculator and the fancier more expensive programmable variety. a world where computing devices are as inflexible as cheap hand-held calculators is a strange world indeed. you might think that there must be some sort of middle ground between the two that would allow for something more (and then surely the iphone inhabits that middle ground) but ed felton covered the fallacy of the almost general purpose computer a long time ago.

without the elimination of general purpose computing you cannot eliminate user choice. you cannot eliminate the emergence of technologies that empower us to throw off the yolk of corporate interests. the linuxes and firefoxes of the world will continue into the future, and the more anti-consumer that corporations become, the more consumers will choose those alternatives. we are not and never will be the parasites in the relationship with business. we are not facebook's product, we are their patrons. the advertisers are not their customers, they're more like the hotdog vendors at a stadium; they only make money so long as we show up and buy something and eventually we will stop showing up at the facebook stadium (just as we stopped showing up to friendster and myspace) and they'll have to chase us to our new favourite spot like the parasites they are.

the transparency delusion

prompted by lenny zeltser's recent post on usability (which itself may be a response to my previous post) and with an actual usability study on 2 pieces of security software [PDF](specifically 2 password managers) still fresh in my mind i've decided to take another look at the issue of usability and more importantly transparency.

the usability study i referred to makes an excellent point about security only paying lip-service to usability, and i don't think they mean because the security software they studied had too many clicks to get through each function or because the menus were non-intuitive. the study was a wonderful object lesson for just how badly things can go wrong when transparency is taken too far - and why. in the case of the software in the study, transparency didn't just make the software harder to use, it actually lead to compromised security.

the key problem of transparency is that it robs the user of important information necessary for the formulation and maintenance of a mental model of what's going on. as a result, the user invariably forms an incomplete/inaccurate mental model, which then leads them to make the wrong decisions when user decision-making is required (at some point a user decision is always required - you can minimize them but you can never eliminate them); not to mention making it more difficult to realize when and how the security software has failed to operate as expected (they all fail occasionally) and so robbing them of the opportunity to react accordingly.

the usability study in question serves as an adequate example of how transparency can go wrong for password managers, but what about more conventional security software like firewalls or scanners? mr. zeltser used the example of a firewall that alerts the user whenever an application tries to connect to the internet. let's turn that around - what if the firewall was 'intelligent' in the way mr. zeltser is suggesting? what if it never alerted the user because all of the user's applications happened to be in some profile the firewall vendor cooked up to prevent the user from facing so-called unnecessary prompts? and what if one day that firewall fails to load properly (i.e. windows thinks it's loaded but the process isn't really doing anything)? will the user know? will s/he be able to tell something is wrong? it seems pretty obvious that when something that never gave feedback on it's operation all of a sudden stops operating, there will be no difference in what the user sees and so s/he will think nothing is wrong.

how about a scanner? let's consider a transparent scanner that makes decisions for you. you never see any alerts from it because it's supposedly 'intelligent' and doesn't need input from you. what happens then is that you formulate an incorrect model, not just what the scanner is doing (because you have no feedback from the scanner to tell you what it's doing), but also an incorrect model of how risky the internet is (because your scanner makes the decisions for you). you come to believe the internet is safe; you know it's safe because you have AV, but any specifics beyond that are a mystery to you because you're just an average user. one day you download something and attempt to run it but nothing happens. you try again and again and nothing happens. then you realize that your AV may be interfering with the process, and since you've come to believe the internet is safe instead of risky you decide that your AV must be wrong by interfering with things so you disable it and try again. congratulations, your incorrect mental model (fostered by lack of feedback in the name of transparency) has resulted in your computer becoming infected.

we shouldn't beat too hard on the average users here, though. i have to confess that even i have been a victim of the effects of transparency. a few years ago, when i was starting to experiment with application sandboxing for the first time, i tried a product called bufferzone. in fact, i tried it twice, and both times i failed to formulate an accurate mental model of how it was operating. bufferzone tried to meld the sandbox and the host system together so that the only clue you had that something was sandboxed was the red border around it. not just running processes either, files on your desktop could have red added to their icons to indicate they were sandboxed. but since i was new to sandboxing at the time i didn't appreciate what that really meant; and as a result, each time i removed bufferzone i was left with a broken firefox installation and had to reinstall.

when we talk about transparency in government, we're talking about being able to see what's going on. for some reason, however, when we talk about transparency in security software we're talking about not seeing anything at all - we're talking about invisibility. invisible operation can only be supported if we can make the software intelligent enough to make good security decisions on our behalf. lenny zeltser offer's the church-turing thesis in support of this possibility but i'd like to quote turing here:

"It was stated ... that 'a function is effectively calculable if its values can be found by some purely mechanical process.' We may take this literally, understanding that by a purely mechanical process one which could be carried out by a machine. The development ... leads to ... an identification of computability † with effective calculability" († is the footnote above, ibid).

security decisions necessarily involve a user's intent and expectations - neither of which can be found by 'purely mechanical processes', and therefore neither of which can be used by security software making decisions on our behalf. the decisions made by software must necessarily ignore what you and i were trying to do or expected to happen. that kind of decision-making isn't even sophisticated enough to handle pop-up blocking very well (sometimes i'm expecting/wanting to see the pop-up) so i fail to see how we can reasonably expect to abdicate our decision-making responsibilities to an automaton of that calibre.

transparency in security software is not a pro-usability goal, it is an agenda put forward by the lazy who feel our usability needs would be better addressed if we all could be magically transported back to a world where we didn't have to use security software any more. designing things so that you don't actually have to use them doesn't make them more usable, it's just chasing after a pipe-dream. true usability would be better served by facilitating the harmonization of mental models with actual function, and that requires (among other things) visibility not transparency/invisibility.

security: it's almost like it isn't there

one of the ideas i continue to encounter over and over again throughout the years is the idea of liking a particular security product because it seems like it's not even there. it's amazing where one can find that idea being expressed. panda security's own luis corrons said the following about his wife's impression of panda's product:

My wife’s computer also have it, and she loves it, mainly because she doesn’t realize that it is installed :)

liking a security product because it seems like it's not even there strikes me as suggestive that the person in question likes to ignore security or not be bothered by security concerns. for most people this is going to be a recipe for eventual disaster. luis' wife, however, has luis on hand to take care of any malware incidents, so i guess for her it's ok. it's an interesting and probably effective strategy - well played, mrs. corrons, well played.

most people can't marry an anti-malware expert, however, so placing value in product's ability to shut up is the wrong way to think about things for most of us. don't get me wrong, if a security tool is too 'chatty' then certainly that poses a usability problem, but the quest for complete transparency is a symptom of mismatched expectations.

the predominant expectation among consumers is that if they install the 'right' product or combination of products then they can forget about all those nasty threats because they'll be protected. that's just not true, though, and it's never, ever going to be true.

people will actively defend this line of thinking, however, often they say they just want to do X and don't want security getting in the way. imagine if i said i just wanted to get to mcdonald's and didn't want traffic safety to get in the way - would that sound reasonable? not so much, i imagine. part of the reason for that is that most of us realize that following certain procedures on the road actually does keep us safer than we would otherwise be; but another part is that we also recognize that when others don't follow those procedures they put us and everyone else at risk, not just themselves.

what if i were to tell you the same principles apply in computer security? there are procedures you can follow that not only allow you to reach your goal in a reasonably secure way (whether that goal is getting work done or enjoying online entertainment or whatever else you use your computer for). not only that but by not following those procedures, by ignoring security, one actually does put other computer users at risk as well. i'm not just talking about other people who use the same computer, either. back in the days of viruses, when a virus infected a computer that computer joined the set of computers from which that virus could further it's spread. essentially it enlarged the platform from which the virus could attack still other systems. today, in the age of the botnet, the same principle applies. when a machine becomes compromised it get's added to the attack platform and assists in attacks on other systems, whether those attacks are simply sending out spam or sending out more malware or performing distributed denial of service attacks. by pretending like security isn't a concern a user puts not only themselves but all other computer users at risk as well.

now, likening secure computing practices to safe driving does not mean i'm trying to argue in favour of requiring users to have a license to operate a computer (though there are those who suggest that). the fact is that day to day life is full situations where you have to take precautions to increase your safety. just crossing the street calls for the precaution of looking both ways first. even toasters (which i bring up because some people literally think computers should be as simple to use as toasters) have safety precautions you need to follow - unplug the thing before you try to retrieve that piece of toast or bagel that's stuck inside.

i often criticize the security industry for perpetuating the myth of install-and-forget security, but the consumer shouldn't be thought of as blameless. people need to wake up and take responsibility for their own safety and security online, as well as being good online citizens and not putting others at undue risk. seriously, folks, computing without the need for taking active precautions is pure fantasy and it's time you started living in the real world. if you don't take responsibility for keeping yourself safe and secure, you won't be safe and secure - period.

another #sectorca has come and gone

[this is 2 weeks late now but better late than never]

i attended the sector conference for the 3rd year in a row this year and as with previous years i've chosen to write about the experience for the benefit of those who couldn't make it, or maybe have never gone and are looking for a reason to go in the future (by which i mean more of a reason than just because i said so). it just so happens i took quite a few notes this year (pen&paper style - i'm still not taking a computing device to a hacker conference - come on) so i've got plenty of material (perhaps too much) to draw from for this post

so jumping right into things - before the first talk even started i took a look at the materials that attendees were given. i have to agree with tyler reguly's twitter comment that there were an awful lot of pamphlets, and by extension and awful lot of dead trees. i'll tell you right now where my copies are almost certainly going to wind up: the garbage (or perhaps the blue box). no offense intended, but a big stack of papers i never asked for and have no interest in feels a lot like junk mail (the physical kind, not the electronic variety). i also noticed that the event programme seemed to be about twice as thick as last year's and the entire back half of it seemed to be advertizements. also there was apparently no puzzle/challenge/whatever like there has been in previous years' programmes.

the first keynote was "The Problem with Privacy is Security", given by Tracy Ann Kosa. in spite of my general disagreement with framing things as though there was a conflict between privacy and security - i stick by my previous position that the real conflict is between competing interests/concerns of disparate parties, usually the individual and the organization -  i found the exploration of what organizations interests are (personal information has become a commodity) and how they use security to protect them (at least so far as the integrity, usability, and reliability of the data is concerned) to be quite interesting. there were a number of other interesting things brought up in the walk-talk (for lack of a better term to describe a talk where the speaker wanders off the stage and amongst the room soon after starting) as well. one of the most salient, i think, is that we protect personal information (or try to) after we collect it rather than proactively by designing our systems to collect as little personal information as possible in the first place.

i also liked the fact that the topic of privacy is being taken more seriously, at least as a topic for discussion, by the sector conference organizers. if this trend continues then perhaps one day i'll be able to engage the vendors on the expo floor without the need to give away my personal information, including the non-obvious way whereby they get my name and contact info when they scan my RFID badge. just because i'm mildly curious in the here and now doesn't mean i care to hear anything more from a company in the future.

following the keynote i attended the "Malware Freakshow 2010" talk given by Nicholas Percoco and Jibram Ilyas. from my perspective it wasn't quite as good as their previous malware freakshow last year. that's not to say that it wasn't a great talk, mind you. it's just that last years' talk had a concept that was truly new to me and that doesn't happen all that often so it's kind of hard to top that - for me. for other people i imagine the memory parsing malware might be a new idea, though i suspect most of us have heard of keyloggers and packet sniffers. there were still some great stories, though, which is primarily what this sort of talk is about. it's the most interesting cases they've found in the field while investigating malware incidents. the data center that was literally in a barn is a good lesson to always visit your hosting company's data center in person to see what you're really getting for your money.

next up was Eldon Spickerhoff's "By The Time You've Finished Reading This Sentence, 'You're Infected'". at the moment i don't know if this has been done previous years but i came to realize this was a sponsored talk. it was only half as long as the normal technical talks, just 30 minutes long. i found myself agreeing with some of the things he said such as whitelisting being complementary to other techniques. other things not so much. for example i think he underestimates the value of botnets designed for sending spam (that spam can direct to drive-by download pages that install more malware, effectively growing the size of the attacker's launchpad - that's always valuable). i also don't agree with the notion that whitelists don't have false positives. i suppose it depends on how you define false positive in that context - false acceptance and false rejection probably are more intuitive terms when it comes to whitelists - but whitelists can certainly falsely accept programs (such as malware that has been erroneously whitelisted) and falsely reject programs (such as self-altering programs).

following that was the lunch keynote given by FBI agent Steve Kelly about "Today's Face of Organized Cyber Crime: A Paradign for Evaluating Threat". first of all i liked hearing about how an FBI agent prefers when he can bypass airport security - i hope that sort of thing filters up to the people who can actually affect change, but i won't hold my breath. one of the take-aways from this talk was that cybercrime organizations aren't necessarily organized, at least not in the sense one thinks of when one thinks of organized crime. i wonder though, if perhaps using the mob as your traditional crime model doesn't bias your thinking in a certain direction, but more to the point perhaps cybercrime doesn't really deserve to be called organized. the non-hierarchical network of people, each with their own criminal specialization, could simply be considered an example of criminal collaboration. even in traditional non-organized crime there are plenty of examples of collaboration between criminals with different areas of expertise. for example a thief specializing in high-end merchandise isn't necessarily going to move that merchandise himself after he's stolen it - instead he might well use the services of a fence, and perhaps he even goes back to the same fence over and over again. that kind of continuous criminal collaboration would look very much like the model the speaker presented for an online criminal enterprise but it certainly wouldn't fit what we would normally think of as organized crime.

another point of interest to me was that the FBI didn't want to treat cybercrime as just 'computer facilitated crime', even though as near as i can tell that's exactly what it is. i understand the reasons, though. when you've broken up your law enforcement efforts by type of crime (ie. one department for theft, another for fraud, etc) treating cybercrime as just computer facilitated crime puts the onus on each enforcement department to develop it's own expertise in dealing with the computer facilitated variant of the crime they focus on. computer facilitation, however, changes the nature of how the crime operates and how to combat it so profoundly, however, that spreading any expertise your organization can acquire so thinly across multiple departments just doesn't make practical sense. it's more logical to centralize that expertise into it's own department as the FBI has apparently done.

oh, and if you haven't guessed already, this speaker was much more interesting than the last law enforcement representative i recall giving a keynote.

after lunch (and the keynote that went with it) nature had to take it's course, and this is one place where i really wish things could be better. there's something like a thousand attendees at sector, most of them male, and we all get to share 4 urinals and 4 stalls in the washroom. no surprise, then, that the lineup stretched right out the washroom doors. really, though, when there's a line that long for the men's washroom, and when your security rockstar speaker has to beg people to let him jump to the head of the line so he can get to the talk he has to give in 4 minutes - that's when you know the washroom facilities are just not good enough. also, some of you security guys really need more fibre in your diet. there weren't any lineups for the sinks, now that i think of it, but i don't want to think about why.

there was some interesting things going on in the schedule for the talk that followed the lunch keynote on the first day. the talk that i really wanted to see, "Language Theoretic Security: An Introduction" by Len Sassaman and Meredith Patterson, was removed from the schedule entirely. on top of that, my second choice, Deviant Ollam's "Four Types of Locks", swapped times with Chris Hoff's "Cloudinomicon" - which is the talk i ultimately wound up seeing and had actually planned on seeing in it's original time-slot. much to everyone's surprise i'm sure, Hoff says you really can have security in the cloud, you just have to be prepared to make profound fundamental changes to pretty much everything or start over from scratch. there were some other really good observations that Hoff shared too, like the fact that companies don't make money by doing the right thing - they don't solve long term problems. while looking over my notes i also see something about survivability being about resist, recognize, and recover - perhaps i was paraphrasing him in my notes but in hindsight that sounds an awful lot like the old PDR triad (prevent, detect, recover) from malware defense.

the next talk i attended was Mohammad Akif's titled "Microsoft's Cloud Security Strategy". like Eldon Sprickerhoff's talk before lunch, this was one of the new half-hour sponsor talks and it was during this one that it really struck home that these half-hour sponsor talks kinda suck. i don't know if it's because of the time constraint (you can't get that much detail into 30 minutes) or if it's because of the fact that they were sponsored talks, but i really didn't get much out of this talk. then again it might have nothing to do with any of that, but rather more to do with an apparent disconnect between my concept of strategy and what most of the rest of the security community seems to think strategy means.

after that last talk i was feeling pretty unfocused and i knew i wasn't going to get much out of the next talk unless it really, really interested me. that meant i had to give up on Marisa Fagan's SDL talk in favour of  Brian Contos' "Dissecting the Modern Threatscape: Malicious Insiders, Industrialized Hacking, and Advanced Persistent Threats". the trick worked, it woke my brain right up. it was a very interesting talk and brian gave a very eloquent explanation of how industrial espionage causes harm (in case anyone thought copying was a victimless crime).

the final talk of the day, after being switched around with the Hoff's talk, was Deviant Ollam's "The Four Types of Lock". i've seen one of his talks previously and i enjoyed learning about locks and lock picking, but this talk was even better because instead of just focusing on the weaknesses (and sometimes strengths) of various locks, this one was geared towards aiding the decision making process when it comes to the procurement and usage of locks. i knew beforehand that the talk would be interesting simply because it was obviously presenting a classification system for locks, but this classification system was focused on strength against lock picking techniques. that was probably the most useful basis for a classification system for both attackers and defenders. Deviant (what a great name) is also a great educator, as someone else at the conference mentioned.

after all the first day talks were done it was time for the reception at Joe Bidali's. there i happened to meet David, Max, David (yes, 2 Dave's at the table) and Kevin. Max was happy to see a developer (myself) and a business analyst (David #2) taking an interest in security. Kevin had a decidedly different take on things, though he seemed to agree with Max that developers taking an interest in security was a good thing. Kevin had some very ... strongly held opinions about what developers need to start doing and how we need to work differently because the amount of time that others get to test things is so limited. of course the reality is that the time developers get to do their part is pretty limited too, and we're subjected to many of the same (or at least analogous) kinds of interference from business units that i often see IT folks complaining about, even when direct access between the two groups is severed. i would love to have the luxury to be able to do everything the right way the first time, but one of the things i've learned that sticks out most prominently in my mind is that even my job as a developer can involve a significant amount of compromise - and that's a hard lesson to learn when you're an uncompromising s.o.b. like me.

after the reception was the speakers dinner, which is now open to non-speakers. this was my first time at the speakers dinner, but it wasn't really all that eventful - other than the look on the waitress' face when i said i'd like my steak blue. i had to settle for rare (or at least what passed for rare there).

the morning keynote of day two was Greg Hoglund's talk titled "Attribution for Intrusion Detection". now i've had some choice words about Greg Hoglund before, but not wanting to make a scene i decided this was one of those people i don't want to introduce myself to (he's not unique in that regard, of course - last year i was careful to keep my distance from rsnake). anyways he had some interesting things to say during his talk. things like reverse engineering is dead (i'm sure that would go over real well at RECon) and malware analysis needs to be easy ("just show me the strings"). he also talks about making things harder for the bad guys, which is pretty rich considering he runs a site that helps the bad guys and not only does he know it, he's commented on the fact.

that being said, there was some legitimately interesting stuff too, such as the not particularly controversial idea that an organization is in a better position to know about the targeted threats it faces than security vendors. the consequence of which being the need for organizations to develop their own (rudimentary) malware analysis capabilities. that's where "show me the strings" comes in.

finally, one thing that really struck me was during the Q&A at the end. someone asked him if there was anything that could be done in the hardware architecture to make things more secure and he said that if we could solve the problem of how to prevent data from being turned into code we'd be more secure against malware (or something to that effect). it's not often that security folks approach what cohen describes as the generality of interpretation (the ability to interpret anything as an instruction) - now if he can just realize that the ability to turn data into code is a requirement of general purpose computing he can shorten future answers to such questions to a succinct "no".

following day 2's morning keynote i attended the presentation "What's old is new again: An overview of mobile application security" by Mike Zusman and Zack Lanier. in recent years mobile security has received a bit of attention but most of the attention i see focuses on mobile malware. this talk was more about finding vulnerabilities in legitimate mobile applications, including those required for operating the devices. there was some great information about the various platforms and one of the things i came away with (and perhaps what the presenters were trying to impress upon the audience) was that this new wave of mobile developers appear to have not learned the lessons from the mistakes previous waves of developers (such as web developers or more conventional application developers) have made in the past. it's as if with each new category of computing platform comes a new set of developers rather than a re-allocation of existing developers, and as such they miss out on the benefits of maturation in existing development communities.

following the mobile app security talk and just before the lunch keynote was another half-hour period for sponsor talks. since i had soured on the notion of such talks i took the opportunity to wander around the expo floor. unfortunately, due to my apparent increasing intolerance for marketing bullshit (if such an increase is even possible - i have long said i don't trust marketing people as far as i can throw them and i look forward to one day finding out how far that is) i found i couldn't bring myself to stop at any of the booths manned by suits. that just left the hardware hacking village which had a home-brew 3D printer and some amazing products of that printer, and the lockpick village where i learned how incredibly weak car locks are. do not leave valuables in your car - we're talking about locks that are easily opened with blank keys and may potentially be pick-able with popsicle sticks. doesn't that fill you with confidence?

the second day's lunch keynote was given by none other than Mike Rothman of Security Incite fame and now a part of Securosis. his talk "Involuntary Case Studies in Data Security" was about data breaches, most if not all being well publicized ones. Mike's talk didn't draw me in quite as much as Greg Hoglund's keynote earlier that day. perhaps it was because it had a business rather than technical focus. that said there was still a number of interesting points discussed during the talk. two that really got my attention the most were a) that there is still no known case of lost media resulting in fraud (even when encryption was absent), and b) companies don't notice their own breaches - they're always found by 3rd parties. the first one is actually a good thing, but it seems like a matter of luck to me; continued loss of media should eventually result in that media falling into the wrong hands and being used for fraud. the second one, where companies don't notice their own breaches, is obviously not good at all but i don't know that there's any way to improve the situation since, as Mike also said, even if you know the past you're still doomed to repeat it because other people who you work with don't understand it and will drag you down with them.

the talk i went to following lunch was Garry Pejski's "Inside the Malware Industry". what i seemed to have missed when reading the description for this talk was that it was going to be a first-hand account from someone who was actually in that industry. that's right, Garry admitted that he was a malware writer! i took more notes at this talk than any other - obviously "know your enemy" had a lot to do with that but also there were a lot of details about the malware, along with Garry's observations about the security countermeasures, the trustworthiness of employers in that industry, and the legality of the business. unlike Hoglund, Garry was repentant about the role he played in cybercrime, although he isn't convinced that the software was illegal because it had an EULA. my suggestion to him is to consider carefully how completely the EULA disclosed the actions of the malware and also to consider sections 342 and 430 of the Criminal Code of Canada (since that does appear to have been the proper jurisdiction).

after the malware industry talk was another half-hour period for sponsor talks. what was also being held during these periods were so-called turbo talks. they were called this because they held 2 back-to-back in the half-hour slot so each person only got 15 minutes.  Nick Owen did a short and sweet  presentation with a long name - "Securing Your Network With Open Source Technologies And Standard Protocols: Tips And Tricks". it came along with the premise (supported by a study apparently) that making better provisions for legitimate remote access results in fewer breaches. i think you can see where that's coming from - people are going to do something in order to work remotely, so it's better if you give them a secure way to do it.. following that, and without any sort of scheduled break for setting things up (thus causing the second turbo talk to run late) was Julia Wolf's presentation "OMG-WTF-PDF" which literally could not have been given a better name. i have a new appreciation for PDF, although i think appreciation is the wrong word. the format is jaw-droppingly bad and the fact that acrobat has 15 million lines of code (compared to NT4's 11 million) is amazing to me. it's amazing because i can't imagine how the programmers managed to put the drugs they were obviously taking down long enough to write so much code.

the final talk i attended (which, since the previous one ran late, i missed the beginning of) was Mike Kemp's "Into the Black: Explorations in DPRK". the title probably doesn't give away the fact that the talk is about the cyberwarfare capabilities of North Korea. that description doesn't really give away the fact that the talk is a debunking of the notion that North Korea has any cyberwarfare capabilities. Mike Kemp presented a hilarious juxtaposition between the purported North Korean superhackers and the internet black hole they live in. i don't want to give too much away, and i couldn't do it justice if i did.

this has been quite a long post (and it's taken me quite a while to finish it) but suffice to say i feel i learned a great deal from sector this year (far more than i've mentioned here) and would recommend it to anyone interested in security. i'm not sure if i'm going to go again next year, however. i've gone 3 years in a row now, and as security still isn't technically my job it kind of feels like self-indulgence to go to these things - and my tolerance for self-indulgence has limits. my employers have been quite generous in affording me this indulgence (and paying for it, no less), but i can't keep taking advantage of that generosity indefinitely.

pity the anti-virus naysayer

pity the anti-virus naysayer, for when one decries the failure of anti-virus one reveals the failure in oneself

i don't think it's necessarily all that interesting to talk about the AV is dead movement anymore - saying anti-virus (or anything else security-wise) is dead is a pretty obvious cry for attention. instead in this post i want to look at the popular notion of "the failure of AV".

when one talks about the failure of anti-virus, what has anti-virus failed to do in the most general sense? failed to stop malware XYZ? failed to protect the endpoint from a specific attack? no, those are all reasonable failures not really worthy of being harped on if you accept that no preventative measure is perfect. in the most general sense, when one talks about the failure of anti-virus one is talking about the failure of anti-virus to live up to one's own expectations.

but are those expectations reasonable? in all likelihood they aren't. they are expectations born not out of an understanding of AV, but rather out of listening to marketing (stop listening to marketing!). if you truly understood AV then your expectations would be a pretty close match to reality, so incidental failures wouldn't surprise you or be a cause for concern. if you really understand AV then those incidental failures should be anticipated and planned for.

therefore, when one decries the failure of AV, it is because one doesn't actually understand it, one hasn't anticipated the incidental failures and made plans for them. it is a failure of understanding that happens all too often, where one tries to use marketing bullshit as a substitute for actual knowledge but only winds up with mismatched expectations. actual knowledge has no substitute and can often be hard to come by. "the failure of AV" may get you brownie points in populist crowds, but it's too facile a conclusion to be useful in the larger scheme of things.

social networking vs. privacy

the privacy issues surrounding social networking sites are nothing new by any stretch of the imagination, but it seems to me that many people have mismatched expectations when it comes to privacy and social networks - and i'm not just talking about the people who are not yet aware of the issues. even those people who are actively criticizing the privacy implications of the technologies and policies in play at social networking sites seem to be experiencing a fundamental disconnect from the reality of social networking.

the fact of the matter is, no social networking site can be both socially useful and promote privacy in a meaningful way at the same time. if we ignore the practical concerns of how to get funding or similar topics that lead us to call social networking users products rather than customers - even an ideal social networking site must necessarily be a privacy failure.

before i explain why, i think it's important to understand what social networking sites are for and by extension what successful ones (including our ideal one) must do in order to be compelling. the core goal of a social networking site is to enrich our social experiences, either by allowing us to have rewarding social experiences with more convenience (like keeping up to date when you've got a spare moment, even if it's in the dead of night) and less expenditure of resources (time, energy, money, or some combination of the three) than we would otherwise be able to have, or by allowing us social experiences that wouldn't otherwise be possible at all (such as reconnecting with long lost friends).

to that end it should come as no surprise that social networking sites have to focus on facilitating the establishment, maintenance, and strengthening of social connections. it should also come as no surprise that social connections flounder in the absence of openness. that is a social network's undoing from a privacy perspective, because openness is incompatible with the guardedness engendered by the strategies we use to protect our privacy.

now there are a couple of specific complaints that i'm sure come to the reader's mind at this point, chief among them being that sites like facebook should still be able to use an opt-in model for information sharing instead of an opt-out one. you have to understand, however, that the opt-in model is essentially equivalent to being guarded-by-default (you could also liken it to default-deny or even whitelisting). no one can dispute that this would be a superior model from a privacy perspective, but as someone who is guarded-by-default in real life i can assure you that it is not a winning social strategy. by going with an opt-in model you put people in the position of having to make conscious decisions about what they need to be open about in order to get the most rewarding experience for themselves (where such calculating behaviour might be familiar only to a select few) as well as figuring out precisely how to go about being open about those things. in other words the opt-in model forces the user into a kind of simulated social awkwardness, which would not be a compelling user experience at all.

you could be thinking right now that even if an 100% opt-in model would scare users away, a more balanced model than 100% opt-out should be possible - and yes, it certainly is. privacy lobbyists (for lack of a better term) have certainly managed to pressure facebook (and i assume others) to change various features to be more privacy-friendly. that being said, without such pressures (representing a broadly held preference to the contrary), social networking sites should be expected to go with the opt-out model and let those who feel they need to protect the information in question actually make the conscious effort to opt-out. the reason for this is purely practical (and i don't mean in the making things easier for lazy programmers sort of way). there is no single sharing strategy that both optimally meets everyone's social needs and their privacy needs as well. that means any attempt at making more balanced sharing defaults amounts to trying to second-guess what's going to work best for users at the risk of making it more difficult to be open in a way they may have found rewarding. defaulting to opt-out is essentially erring on the side of caution with respect to not compromising the primary goal of an ideal social networking site.

all this being said, when it comes to sharing data with advertising partners or other third party organizations, that has nothing to do with enriching the social experiences of the user. those are entirely business-driven decisions, and while they make sense for the business, they provide no direct benefit to the user and so there is no reason to believe the user would appreciate that sort of openness being facilitated (or rather foisted on them) by default. those sharing practices rightly deserve to be made opt-in rather than opt-out, but i don't expect the business people running the social networking sites to draw this distinction between sharing that facilitates social connection and sharing that facilitates advertising revenue. at least not without a good swift kick in the arse on a regular basis.

(2010/10/21: edited to correct typo spotted by @ChetWisniewski)