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.

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...

chrome plated security

seems like everyone is talking about google's new browser called chrome... google even made a comic book about the product...

the comic describes a lot of what went into chrome and it sounds like google made some very interesting design decisions, like making it a multi-process application instead of simply multi-threaded, or their new javascript engine... it also captures the google aesthetic quite well...

those aren't enough to make me switch browsers however... i enjoy a certain level of security with my current setup and would like at least an equivalent level from any alternative browser but it doesn't seem like i'd be able to get that from chrome...

chrome implements two of the three preventative paradigms i've written about before... specifically it implements blacklisting of sites (both sites known to host malware and sites known to be phishing pages) and it implements sandboxing... what it doesn't seem to implement (at least the comic made no mention of it and i saw no sign when i tested it out) is whitelisting...

there are a couple of reasons why whitelisting may have been left out of the mix... the most simplistic of which being they simply weren't familiar with the concept - indeed, website blacklists are in most modern browsers now so they're well known, and there was a mini boom of browser sandboxing tools (enough that google actually acquired one called greenborder last year) so they should be on google's radar too... as far as whitelisting active web content goes, however, there aren't a lot of players - noscript stands out as the only one i can think of (other than IE's trusted zone which almost no one uses because it's not user friendly)...

if we assume google was familiar with whitelisting active web content in general and noscript in particular then another possible reason for it's exclusion emerges - when you look at the frequency of noscript updates (updates that are more than just a new list as you'd get with a blacklist update, updates to the codebase itself) you come away with the impression that technology like noscript is far better off as a plugin than built into the browser... i don't think anyone wants to update their entire browser that often...

finally, a thought that formed while commenting on michael farnum's blog - there seems to be a fundamental philosophical conflict between the default-deny paradigm that whitelists represent and organic growth of application ecosystems... the way web content is developed can be considered to be the very embodiment of organic growth and google makes it pretty clear that they want to help that along, not get in it's way, so it could very well be that whitelisting simply doesn't fit in their security vision...

it's a rather important part of mine, however, so at the very least i won't be switching to chrome until someone makes a noscript-like plugin for it... things won't be all sunshine and lollipops when that happens, though... as i mentioned earlier, the browser is supposed to have sandboxing built in and on the surface that sounds great... unfortunately they haven't figured out how to sandbox plugins... this seems like a pretty big deal to me because flash is a plugin and shockwave is a plugin and quicktime is a plugin, etc... the very active content that isn't being controlled by way of a whitelist is apparently not being contained by their sandboxing technique either... this seems a little backwards because i'm fairly sure that back in the days when greenborder was still around if you ran your browser in that sandbox the plugins stayed in the sandbox too... no worries, we'll just run chrome inside another sandbox like sandboxie - right? try it and you too may be greeted with the "sad tab"...

i've no idea why (i'm no sandboxie power-user) but all pages lead to sad inside a second sandbox and the helpful reload advice sometimes leads to the frozen tab (and boy does he look cold)...
from the looks of things in process explorer, each tab process runs in a sandboxed process with the unsandboxed browser process as the parent but when the browser process is sandboxed it doesn't appear to be able to create it's own sandboxed children (even though a sandboxed firefox can launch vlc in the sandbox without trouble)...

so there's no whitelist and not only is the built in sandboxing insufficient, it appears to kill the option of using a 3rd party sandbox to make up for it's deficiencies... it's pretty, don't get me wrong, i like the look of it - i also like the idea of faster javascript, but i get more security with my current browser setup and when legitimate sites like yahoo mail or cnn are sometimes found to be serving malicious content that security becomes pretty important...

why proactive anti-malware controls are dumb

no, i'm not trying to insult proponents of proactive techniques... i'm not trying to say that using proactive controls is dumb, but rather that the controls themselves are dumb...

the diametrical relationship between proactive and reactive preventative controls can be considered equivalent to the one between generic and malware-specific (aka known-malware) techniques respectively... to be truly proactive means to be able to do something about or block a piece of malware before anyone knows anything about it - therefore it can't be malware-specific because a malware-specific control can't be built until after knowledge of the malware is acquired...

therefore proactive/generic controls lack the knowledge component that reactive/malware-specific techniques have and so are stupid... by extension, built-in knowledge is a luxury only reactive/malware-specific techniques can have... of course it is entirely possible to have a little bit of both and provide some shades of gray between these black and white polar opposites...

being stupid isn't necessarily a bad thing in a control, mind you... sharks are often referred to as being perfect killing machines but you won't catch anyone accusing them of being unusually intelligent... so using a dumb control can still be smart if the control is effective... in fact, one could even say that using a dumb control effectively requires intelligence because it doesn't come with any of it's own...

i know there's no panacea but i still want one, darnit!

have you read this post by lonervamp about the silver bullet syndrome? forgetting his specific example of jericho forums for the moment, i agree whole-heartedly with his observation that although we all seem to agree that there is no panacea people still seem to talk and act as though they expect their to be one...

need an example besides the jericho one? well anton chuvakin has been kind enough to provide us with one this evening that involves anti-virus... he's abandoned known-malware scanning completely after a friend of his had to rebuild their system despite being 'protected' by a major brand av....

now i'm not going to debate the merits of the decision itself, if he wants to use a whitelist instead of a blacklist, that's his decision and it's certainly a workable one... the problem is the motivation - getting fed up because of an instance of av failing (or even many instances) points to (as mike rothman would put it) mismatched expectations... if you know and agree that there is no panacea then you shouldn't be overly bothered by instances of failure, you should be expecting failure...

so what's going on here? i think that although we more or less all agree that there is no panacea, people don't seem to appreciate what that really means... i suspect that the use of the term panacea itself may be obscuring the real implications so i'm going to put it in simple terms that everyone, expert and novice alike, can understand:

all preventative measures fail

that's right, each and every single last one of them... that is what it means to truly accept that there is no panacea, you have to accept that there will be failures... getting fed up with the failures is an emotional rather than rational reaction, and if you base your decisions on it you are likely to be disappointed in the future when it turns out that the next big thing fails too...

people don't like failure, however, and they certainly don't want to accept it... this is a shame because if you're going to develop a successful security strategy you have to not only accept failure, you have to anticipate it... anticipating failure is really a cornerstone of strategic thinking, without it there would be no impetus to devise contingency plans, and without those a strategy is nothing more than a basic plan and a lot of poorly founded hope... in short you need to learn to succeed by planning for failure rather than running blindly from it...

the three preventative paradigms

something i've had circling around in my head for a while now is a fundamental division between malware prevention techniques... i'm moderately certain i've missed something (because three just comes up way too often in security) but it seems to me that everything falls into one (or more) of three broad categories: blacklisting, whitelisting, and sandboxing...

i know, right now you're probably saying "kurt! you missed a whole bunch of stuff - what about heuristics? what about behavioural techniques?"... well, lets look at that - what does behaviour-based malware detection do anyways? it monitors behaviours, sure, but how does it decide something is bad? what's going on is that it's actually comparing the behaviours (or combinations thereof) to a list of known bad behaviours (or behaviour combinations) which means it's a type of behavioural blacklist... likewise, heuristics compares properties (like the presence of certain familiar routines) of the program being scanned to a list of properties known to be used in bad programs and so also represents a type of blacklist... the blacklist technique is not the exclusive domain of signature scanning... anything that tries to identify something as bad (basically anything that tries to algorithmically answer the question "is this bad?") must do so by comparing it or some aspect of it to a list of known bad things of a similar type - and that makes it a blacklist...

"but kurt," you say, "that's not the only kind of behavioural technique out there. what about ones where you define what behaviour different programs are allowed to perform such as provided by various HIPS products?"... well, you'd be right, that behavioural technique is not a blacklist... besides being a process-centric access control system, it is more generally a behavioural whitelist... just as the blacklist technique is not exclusive to signature-based virus scanning, the whitelist technique is not so narrowly defined as to only specify application launch whitelists and/or the preferred paradigm for deploying firewalls... if it tries to block everything that isn't good/allowed/authorized (rather than everything that is bad/not allowed/unauthorized) then it must first be able to answer the question "is this good/allowed/authorized?" and to do that it must have a list of known good/allowed/authorized things - and that is a whitelist...

so if it answers the "is it bad?" question it's a blacklist and if it answers the "is it good?" question it's a whitelist - what's left? you might think it's some combination of the two but in fact it's not answering any question at all... the truth is our ability to answer either of those questions is limited so we need to take care of the case where we can't answer either of them and that's what a sandbox does... rather than blocking things outright based on knowledge of what's good or what's bad, sandboxing prevents malware intrusion to the host system by misdirection... the software which may or may not be malware is given a sandboxed environment to work in rather than the host environment and barring any ability to escape sandboxes, what happens in the sandbox (good or bad) stays in the sandbox... it doesn't necessarily prevent extrusion (leaking) of sensitive data you enter into applications running in the sandbox, mind you, and in that sense is a lesser form of prevention - but preventing malware from affecting the host system without any knowledge of or ability to decide on what's good or bad is no small feat...

if we could just assume everything that a blacklist doesn't alert on was good then life would be simple, but unfortunately that's not the case... likewise, assuming everything that isn't on a whitelist must be bad isn't very useful either (at least not unless you're dealing with very restrictive environments and even then there are complications)... once again, these three approaches are complementary and are best used together...

defensive lines in end-point anti-malware security

some comments on my post about anti-malware tests have inspired me to examine what the various defensive lines are for end-point anti-malware security... this isn't going to include things like network intrusion detection/prevention systems because those are in the network rather than on the end-point...

as such, the first line of defense happens just as content is coming off the wire and into the system... this is before it gets written to disk (assuming the content ever does get written to disk, which sometimes is not a valid assumption) and is represented by things like exploit scanning network proxies (one might also consider the inbound traffic filter of a personal firewall as working at this stage of the defense)... i say this is the first line of defense because (assuming you have defenses here) this is the first one that malware would encounter when traveling to your system... this hasn't always been a defensive line however; before the internet became ubiquitous, malware tended to be passively shared either on removable media like floppy disks or over the telephone line when downloading from bulletin board systems - both of which happened to suit the second line of defense quite well...

the second line of defense (which used to be the first line of defense) starts just after content has been written to disk and continues for as long the content persists on the disk... this is traditionally the point at which new incoming materials would be screened against a blacklist (anti-virus product, generally)... content shared on removable media is suited to this defensive line because the media is just another disk to check... content shared via BBSes were similarly suited to this defensive line because the content had to be saved to disk before you could do anything risky with it (like try to execute it)...

the third line of defense happens just before the content is executed... this is where application whitelisting comes in (though on-access scanning with anti-virus will also trigger here since accessing the content is usually a prerequisite for executing it)... this of course assumes that the content is executable or otherwise interpretable in some way as instructions for the computer to follow (basically that it's some sort of program)... if not then it's not really malware (even exploit code is a program of sorts, though it tends to be executed in an unconventional way)...

the last line of defense happens after the content is executed... this is where behaviour-based protection (sandboxes, behaviour blockers, some/most types of HIPS, immunization, change-detection, outbound traffic filtering, etc.) comes into play, obviously, because at this point the defenses are looking for bad behaviour from the running programs... there's no later stage than while the malware is executing to prevent the malware from doing it's bad deed - if the defenses at this stage fail to detect/stop the malware's bad behaviour then prevention has failed...

there's more to security than just prevention

thanks to richard bejtlich for drawing my attention to this (because i find dark reading to be impenetrably dull)...

it appears that joanna rutkowska is trying to get the message across that there's more to security than prevention, that there's always some way around preventative measures and so you have to worry about detection as well... i can't pass up the two-fold irony here... first, joanna became a household name in security precisely because of her claim of making 100% undetectable malware, which should mean that focusing on detection is wasted effort... second and regarding the same claim, her undetectable malware is implicitly preventing detection... if she wants to bang the drum of no perfect prevention then more power to her, but she's going to need to eat her own dog food, as the saying goes...

richard echoes her sentiments though, and although there's a really good reason for all the focus on prevention (come on, say it with me now, an ounce of prevention is worth a pound of cure) i'll chime in with my own support for them too... security doesn't start and end with prevention (well, it might start there, but it definitely doesn't end there)... all preventative measures fail under some circumstances so it becomes important to try and detect preventative failures... i've written about the limits of prevention in an anti-virus context before (what i wrote applies equally well outside of the malware field) and when i did i made it clear that security doesn't end with detection either... it's all well and fine to detect a preventative failure, but then what?... after detection comes remediation - when you've discovered that your attempts to prevent bad things from happening have failed then you need to remedy the situation... in security one often will hear of the CIA triad; confidentiality, integrity, and availability are all things that security aims to maintain... well prevention, detection, and remediation form a triad too - they're the stages one goes through in the process of trying to protect something...

at this point you might be thinking that if security doesn't end with prevention and it doesn't end with detection then it must end with remediation because there aren't any elements left is this triad... one would be wrong for thinking that, however... remediation feeds back into prevention - since you don't want to have to keep applying the remedy over and over again you need to augment the preventative measures to help prevent what you failed to prevent before... prevention, detection, and remediation are a 3 stage cycle; they keep going indefinitely and each pass through the cycle makes security a little bit better/stronger....