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...
Showing posts with label defense in depth. Show all posts
Showing posts with label defense in depth. Show all posts
Wednesday, May 06, 2009
Sunday, July 13, 2008
if i have a whitelist, do i still need AV?
on reading this dark reading article about a texas bank dumping AV in favour of application whitelisting technology i was reminded of an email conversation i had with a reader who was dealing with almost the exact same issue only days earlier... i've come to realize this is a question more and more people are going to be wrestling with as time goes on so instead of expecting them to contact me privately i'm going to answer the question of whether you need AV software if you have a whitelist here... the glib answer is no you don't need it...
of course that answer continues with: you don't need the whitelist either, or your computer for that matter - people survived perfectly fine before any of that stuff existed...
clearly, the glib answer isn't all that useful...
the real answer is that i can't decide for anyone whether they need AV... in practice security has a lot to do with making trade-offs and which trade-off is right for any particular person or organization is best decided by those who would have to live with the consequences of that decision... what i can do, however, is point out weaknesses in both individual technologies and describe some of the benefits of using them together...
it's no secret that known-malware scanners are ill-suited to detection of new/unknown malware, updates can be a hassle for large organizations, and the ongoing subscription fees have in the past seemed like a necessary evil but are increasingly seeming less necessary as application whitelisting works it's way into the mainstream...
of course, as we know from figures provided by bit9, the set of good software is larger and growing faster than the set of malware so a vendor-supplied whitelist will almost certainly be worse from an update point of view (and maybe subscription-wise too)... the customer-editable whitelist is much more palatable in that regard because you only put on it those things you actually need in your production environment... coming up with the initial whitelist (not to mention modifying it if/when the needs of that environment change or when software needs updating) puts the customer in the position of having to decide what's safe or not... certainly one should only trust software from known, reputable sources but those sources aren't perfect (even microsoft has accidentally distributed malware in the past) so the first benefit of continuing to use known-malware scanner even though you've chosen to use a whitelist is that you can check the software you intend to whitelist (as whitelist vendors often do for whitelists they provide)... this is an example of the axiom "trust but verify"...
that alone may not seem like it's enough to warrant keeping the desktop av, however, so consider this: just as known-malware scanners don't recognize everything that's malware, application whitelist software doesn't recognize everything that's a program... will the whitelist software block office macros if the office binaries are on the whitelist? will it block batch, perl, kixstart, etc. scripts if their respective interpreter is on the whitelist? will it block javascript from the myriad of ways it can be launched on the system? as an example, i use the application launch control functionality of sunbelt personal firewall as a whitelist and i discovered quite by accident recently that it does not block individual batch files... a known-malware scanner would detect known malware in a batch file, however, and in an office macro, etc... that's a second benefit of keeping known-malware scanners around in a whitelist deployment, and it's one that applies even at the desktop level...
that's not all though... there's also the issue of exploit code that exploits vulnerabilities in whitelisted applications... if the exploit needs to launch additional applications that aren't on the whitelist then the whitelisting software will have interfered with and potentially blocked the exploit, but what if all the applications it needs are on the whitelist? the whitelisting software would be helpless to stop it but a known-malware scanner might still have at least some chance to do so...
known-malware scanners are weak against that which is novel while application whitelists (assuming no malware gets whitelisted) are weak against that which is exotic... together they're only weak against that which is both novel and exotic... this is the essence of what defense in depth means when it comes to the anti-malware world - not using multiple different scanners but rather using multiple and entirely different types of technology so that the second (or third, or fourth, etc) line of defense can stop at least some of what gets through the cracks in the previous line(s) of defense... it's still up to the people affected to decide whether the benefits of a multi-layered strategy warrant the cost but they should definitely consider it as no technology is an island, perfect unto itself...
of course that answer continues with: you don't need the whitelist either, or your computer for that matter - people survived perfectly fine before any of that stuff existed...
clearly, the glib answer isn't all that useful...
the real answer is that i can't decide for anyone whether they need AV... in practice security has a lot to do with making trade-offs and which trade-off is right for any particular person or organization is best decided by those who would have to live with the consequences of that decision... what i can do, however, is point out weaknesses in both individual technologies and describe some of the benefits of using them together...
it's no secret that known-malware scanners are ill-suited to detection of new/unknown malware, updates can be a hassle for large organizations, and the ongoing subscription fees have in the past seemed like a necessary evil but are increasingly seeming less necessary as application whitelisting works it's way into the mainstream...
of course, as we know from figures provided by bit9, the set of good software is larger and growing faster than the set of malware so a vendor-supplied whitelist will almost certainly be worse from an update point of view (and maybe subscription-wise too)... the customer-editable whitelist is much more palatable in that regard because you only put on it those things you actually need in your production environment... coming up with the initial whitelist (not to mention modifying it if/when the needs of that environment change or when software needs updating) puts the customer in the position of having to decide what's safe or not... certainly one should only trust software from known, reputable sources but those sources aren't perfect (even microsoft has accidentally distributed malware in the past) so the first benefit of continuing to use known-malware scanner even though you've chosen to use a whitelist is that you can check the software you intend to whitelist (as whitelist vendors often do for whitelists they provide)... this is an example of the axiom "trust but verify"...
that alone may not seem like it's enough to warrant keeping the desktop av, however, so consider this: just as known-malware scanners don't recognize everything that's malware, application whitelist software doesn't recognize everything that's a program... will the whitelist software block office macros if the office binaries are on the whitelist? will it block batch, perl, kixstart, etc. scripts if their respective interpreter is on the whitelist? will it block javascript from the myriad of ways it can be launched on the system? as an example, i use the application launch control functionality of sunbelt personal firewall as a whitelist and i discovered quite by accident recently that it does not block individual batch files... a known-malware scanner would detect known malware in a batch file, however, and in an office macro, etc... that's a second benefit of keeping known-malware scanners around in a whitelist deployment, and it's one that applies even at the desktop level...
that's not all though... there's also the issue of exploit code that exploits vulnerabilities in whitelisted applications... if the exploit needs to launch additional applications that aren't on the whitelist then the whitelisting software will have interfered with and potentially blocked the exploit, but what if all the applications it needs are on the whitelist? the whitelisting software would be helpless to stop it but a known-malware scanner might still have at least some chance to do so...
known-malware scanners are weak against that which is novel while application whitelists (assuming no malware gets whitelisted) are weak against that which is exotic... together they're only weak against that which is both novel and exotic... this is the essence of what defense in depth means when it comes to the anti-malware world - not using multiple different scanners but rather using multiple and entirely different types of technology so that the second (or third, or fourth, etc) line of defense can stop at least some of what gets through the cracks in the previous line(s) of defense... it's still up to the people affected to decide whether the benefits of a multi-layered strategy warrant the cost but they should definitely consider it as no technology is an island, perfect unto itself...
Saturday, February 09, 2008
the state of anti-virus
there have been some posts and discussions recently about anti-virus that i thought were interesting (and not just because my name was invoked) and rather that split my thoughts between multiple sites i've opted to combine everything here... thankfully most involved welcome open debate on the subject, though others not so much - but refusing to believe malware and vulnerabilities are orthogonal to one another kinda limits where the discussion can go, so oh well...
so i'm going to start with michael's post over at mcwresearch.com... now i hope michael doesn't take this the wrong way, but i quite enjoyed the irony of his post's title - "AV must innovate or die"... michael of course comes from a behaviour-based HIPS background and behaviour-based HIPS (or at the very least it's precursor) began it's life in an anti-virus product...
furthermore, as i've mentioned before, anti-virus isn't just blacklist-based scanners... rather it's an archaic term for anti-malware and since HIPS is itself a type of anti-malware technology, HIPS is fundamentally part of the same industry that michael is criticizing - which means he himself is making that innovation happen and making sure 'anti-virus' doesn't die...
of course, when michael used the term anti-virus, he really was just talking about known-malware scanners and criticizing them for not being able to do what is totally outside the scope of a known-malware scanner - block unauthorized behaviour... that's actually a pretty unfair criticism since he's only considering the scanner technology itself and no technology (not scanners or HIPS) is perfect, they all do different things and they all have their limitations... he's mentioned in the past that anti-virus needs to get it's peanut butter mixed in with IPS's chocolate so i'm going to give michael a treat... symantec has HIPS, mcafee has HIPS, trend micro has HIPS, sophos has HIPS, kaspersky has HIPS built into KIS, f-secure has HIPS, panda has HIPS, etc... perhaps in the future michael will consider all the technologies that traditional av vendors make available so that he doesn't have to compare apples to oranges anymore...
the other post that caught my eye was this one by lonervamp (he's also a michael but let's not get ambiguous) about where he sees the state of anti-virus being... he also refers to anti-virus in a strictly known-malware scanning context and discusses the role it's supposed to play in a defensive strategy and how it's benefits have waned with the development of procedural and technological layers that complement it's use... i would actually tend to agree with that observation, but i'd also note that being complementary is a commutative property - known-malware scanning complements those other layers as well... could you go without scanning entirely? sure, just like you could use only scanning, but they're better together than they are on their own... that the benefits of known-malware scanning wane in the presence of complementary layers is entirely understandable and expected as the layers in a multi-layered defense will generally partially overlap each other... it's because of that overlap that the benefits of any individual layer may wane, but a layer isn't redundant or useless unless it's completely overlapped by the other layers...
so a question that is perhaps of interest to both posters is at what point does known-malware scanning become entirely redundant?... personally, i don't think it ever does... any given technology has an achilles heel that can allow a piece of malware to get past it... for known-malware scanning this achilles heel is novelty - new/unknown malware is clearly not something known-malware scanning can deal with... other technologies have their own weaknesses too but as weaknesses go novelty is unique because it's the only one that wears off... the media makes quite a big deal out of all the new malware being created and how it keeps getting past known-malware scanners, and at the same time it rarely mentions cases of malware incidents involving old malware... this leads to the erroneous impression that one needn't worry about old malware... old malware still pops up for a variety of different reasons and although it may use tricks that can still allow it to get past other technologies, by the time it gets old it's not going to be getting past a known-malware scanner anymore...
lonervamp also made a distinction between home use and business use, suggesting that known-malware scanning was more likely to be displaced in the business than in the home... i can certainly see that - one of the strengths of known-malware scanning is that the expertise that makes it work is embedded in the product so that the user is relieved of having that burden... many other technologies require knowledge and skill from the customer that may or may not be there... in a business you're much more likely to have trained, knowledgeable individuals (the IT staff) who can make the intelligent decisions necessary for products with more client side configuration to work effectively... that means that alternative technologies become a more feasible option in that environment...
that isn't to say i'd suggest dropping known-malware scanning though... even in a business i think it has it's place... i don't think it should be the only type of technology used, mind you - there are many types of technology available (sometimes even from a single vendor) and they're just waiting to be used... if i were going to suggest anything it would be more comprehensive layering, not simply different layers... the goal should be better overall coverage and substituting one layer for another isn't necessarily the way to get there...
so i'm going to start with michael's post over at mcwresearch.com... now i hope michael doesn't take this the wrong way, but i quite enjoyed the irony of his post's title - "AV must innovate or die"... michael of course comes from a behaviour-based HIPS background and behaviour-based HIPS (or at the very least it's precursor) began it's life in an anti-virus product...
furthermore, as i've mentioned before, anti-virus isn't just blacklist-based scanners... rather it's an archaic term for anti-malware and since HIPS is itself a type of anti-malware technology, HIPS is fundamentally part of the same industry that michael is criticizing - which means he himself is making that innovation happen and making sure 'anti-virus' doesn't die...
of course, when michael used the term anti-virus, he really was just talking about known-malware scanners and criticizing them for not being able to do what is totally outside the scope of a known-malware scanner - block unauthorized behaviour... that's actually a pretty unfair criticism since he's only considering the scanner technology itself and no technology (not scanners or HIPS) is perfect, they all do different things and they all have their limitations... he's mentioned in the past that anti-virus needs to get it's peanut butter mixed in with IPS's chocolate so i'm going to give michael a treat... symantec has HIPS, mcafee has HIPS, trend micro has HIPS, sophos has HIPS, kaspersky has HIPS built into KIS, f-secure has HIPS, panda has HIPS, etc... perhaps in the future michael will consider all the technologies that traditional av vendors make available so that he doesn't have to compare apples to oranges anymore...
the other post that caught my eye was this one by lonervamp (he's also a michael but let's not get ambiguous) about where he sees the state of anti-virus being... he also refers to anti-virus in a strictly known-malware scanning context and discusses the role it's supposed to play in a defensive strategy and how it's benefits have waned with the development of procedural and technological layers that complement it's use... i would actually tend to agree with that observation, but i'd also note that being complementary is a commutative property - known-malware scanning complements those other layers as well... could you go without scanning entirely? sure, just like you could use only scanning, but they're better together than they are on their own... that the benefits of known-malware scanning wane in the presence of complementary layers is entirely understandable and expected as the layers in a multi-layered defense will generally partially overlap each other... it's because of that overlap that the benefits of any individual layer may wane, but a layer isn't redundant or useless unless it's completely overlapped by the other layers...
so a question that is perhaps of interest to both posters is at what point does known-malware scanning become entirely redundant?... personally, i don't think it ever does... any given technology has an achilles heel that can allow a piece of malware to get past it... for known-malware scanning this achilles heel is novelty - new/unknown malware is clearly not something known-malware scanning can deal with... other technologies have their own weaknesses too but as weaknesses go novelty is unique because it's the only one that wears off... the media makes quite a big deal out of all the new malware being created and how it keeps getting past known-malware scanners, and at the same time it rarely mentions cases of malware incidents involving old malware... this leads to the erroneous impression that one needn't worry about old malware... old malware still pops up for a variety of different reasons and although it may use tricks that can still allow it to get past other technologies, by the time it gets old it's not going to be getting past a known-malware scanner anymore...
lonervamp also made a distinction between home use and business use, suggesting that known-malware scanning was more likely to be displaced in the business than in the home... i can certainly see that - one of the strengths of known-malware scanning is that the expertise that makes it work is embedded in the product so that the user is relieved of having that burden... many other technologies require knowledge and skill from the customer that may or may not be there... in a business you're much more likely to have trained, knowledgeable individuals (the IT staff) who can make the intelligent decisions necessary for products with more client side configuration to work effectively... that means that alternative technologies become a more feasible option in that environment...
that isn't to say i'd suggest dropping known-malware scanning though... even in a business i think it has it's place... i don't think it should be the only type of technology used, mind you - there are many types of technology available (sometimes even from a single vendor) and they're just waiting to be used... if i were going to suggest anything it would be more comprehensive layering, not simply different layers... the goal should be better overall coverage and substituting one layer for another isn't necessarily the way to get there...
Monday, November 19, 2007
defense in depth revisited
so as a result of my previous post on the use of multiple scanners as a supposed form of defense in depth i was pointed towards this set of slides for a presentation by sergio alvarez and thierry zoller at n.runs:
http://www.nruns.com/ps/The_Death_of_AV_Defense_in_Depth-Revisiting_Anti-Virus_Software.pdf
the expectation was that i'd probably agree with it's contents, and some of them i do (ex. some of those vulnerabilities are taking far too long to get fixed) my blog wouldn't be very interesting if all i did was agree with people so thankfully for the reader there's a number of things in the slides i didn't agree with...
the first thing is actually in the filename itself - did anyone catch that death of av reference in there? obviously this is qualified to be specific to a more narrow concept but the frame of reference is still fairly clear...
i'm not going to harp on that too much because that's just a taste of what's in store, actually... the main thrust of the presentation these slides are for seems to be that defense in depth as it's often implemented (ie. with multiple scanners at multiple points in the network) is bad because of all the vulnerabilities in scanners that malware could exploit to do anything from simply bypassing the scanner to actually getting the scanner to execute arbitrary code...
this says to me that instead of recognizing that you can't build defense in depth using multiple instances of essentially the same control, the presenters would rather call the construct a defense in depth failure and blame the failure on the scanners and the people who make them (and make no mistake, there certainly is some room for blame there)... the fact is that it was never defense in depth in the first place and if you want to assign blame, start with the people who think it is defense in depth because they clearly don't understand the concept... in a physical security context, if my only defensive layer is a wall and i decide to add a second wall (and maybe even a third) i add no depth to the defense... an attack that can be stopped by a wall will be stopped by the first one and one that can't be stopped by the first wall probably won't be stopped by subsequent walls...
the slides also have some rather revealing bullet points, such as the one that lists "makes our networks and systems more secure" as a myth... this goes back to the large surface area of potential vulnerabilities; the argument can be made that using such software increases the total number of software vulnerabilities present on a system or in a network - however this is true for each and every piece of software one adds to a system... i've heard this argument used in support of the idea that one shouldn't use any security software and instead rely entirely on system hardening, least privileged usage, etc. but it's no more convincing now than it has been in the past... yes the total number of vulnerabilities increase but there's more to security than raw vulnerability counts... the fact is that although the raw vulnerability count may be higher, the real world risk of something getting through is much lower because of the use of scanners... there aren't legions of malware instances exploiting these scanner vulnerabilities, otherwise we'd have ourselves an optimal malware situation...
another point, and one they repeat (so it must be important) is the paradox that the more you protect yourself the less protected you are... this follows rather directly from the previous point, using multiple scanners is bad because of all the vulnerabilities... the implication, however, is that if using more scanners makes you less secure then using fewer scanners should make you more secure and thus using no scanners would make you most secure... i don't know if that was the intended implication, i'm tempted to give the benefit of the doubt and suggest it wasn't, but the implication remains... again, there's more to security than what they're measuring - they're looking at one part of the change in overall security rather than the net change...
yet another point (well set of points, really) had to do with how av vendors handle vulnerability reports... as i said earlier, some of the vendors are taking far too long but some of the other things they complain about are actually quite reasonable in my eyes and i find myself in agreement with the av vendors... things like not divulging vulnerability details when there is neither a fix nor a work around ready yet (no point in giving out details that only the bad guys can actually act on), condensing bugs when rewriting an area of code (i develop software myself, it makes perfect sense to me that a bunch of related bugs with a single fix would be condensed into one report), fixing bugs silently (above all else, don't help the bad guys), and spamming vulnerability info in order to give credit to researchers (if you're in it for credit or other rewards you'll get no sympathy from me)...
finally, and perhaps the most novice error in the whole presentation was the complaint that scanners shouldn't flag archive files as clean if they're unable to parse them... there is a rather large difference between "no viruses found" and "no viruses present"... scanners do not flag things as clean (at least not unless the vendor is being intellectually dishonest) because a scanner cannot know something is clean - all a scanner can do is flag things that aren't clean and the absence of such flags cannot (and should not, if you know what you're talking about) be interpreted to mean a thing is clean... scanners tell you when they know for sure something is bad, not when they don't know for sure that something isn't bad... if you want the latter behaviour then you want something other than a scanner...
all this being said, though, i did take away one important point from the slides: not only is using multiple scanners not defense in depth, using multiple scanners in the faux defense in depth setup that many people swear by comes with security risks that most would never have considered...
http://www.nruns.com/ps/The_Death_of_AV_Defense_in_Depth-Revisiting_Anti-Virus_Software.pdf
the expectation was that i'd probably agree with it's contents, and some of them i do (ex. some of those vulnerabilities are taking far too long to get fixed) my blog wouldn't be very interesting if all i did was agree with people so thankfully for the reader there's a number of things in the slides i didn't agree with...
the first thing is actually in the filename itself - did anyone catch that death of av reference in there? obviously this is qualified to be specific to a more narrow concept but the frame of reference is still fairly clear...
i'm not going to harp on that too much because that's just a taste of what's in store, actually... the main thrust of the presentation these slides are for seems to be that defense in depth as it's often implemented (ie. with multiple scanners at multiple points in the network) is bad because of all the vulnerabilities in scanners that malware could exploit to do anything from simply bypassing the scanner to actually getting the scanner to execute arbitrary code...
this says to me that instead of recognizing that you can't build defense in depth using multiple instances of essentially the same control, the presenters would rather call the construct a defense in depth failure and blame the failure on the scanners and the people who make them (and make no mistake, there certainly is some room for blame there)... the fact is that it was never defense in depth in the first place and if you want to assign blame, start with the people who think it is defense in depth because they clearly don't understand the concept... in a physical security context, if my only defensive layer is a wall and i decide to add a second wall (and maybe even a third) i add no depth to the defense... an attack that can be stopped by a wall will be stopped by the first one and one that can't be stopped by the first wall probably won't be stopped by subsequent walls...
the slides also have some rather revealing bullet points, such as the one that lists "makes our networks and systems more secure" as a myth... this goes back to the large surface area of potential vulnerabilities; the argument can be made that using such software increases the total number of software vulnerabilities present on a system or in a network - however this is true for each and every piece of software one adds to a system... i've heard this argument used in support of the idea that one shouldn't use any security software and instead rely entirely on system hardening, least privileged usage, etc. but it's no more convincing now than it has been in the past... yes the total number of vulnerabilities increase but there's more to security than raw vulnerability counts... the fact is that although the raw vulnerability count may be higher, the real world risk of something getting through is much lower because of the use of scanners... there aren't legions of malware instances exploiting these scanner vulnerabilities, otherwise we'd have ourselves an optimal malware situation...
another point, and one they repeat (so it must be important) is the paradox that the more you protect yourself the less protected you are... this follows rather directly from the previous point, using multiple scanners is bad because of all the vulnerabilities... the implication, however, is that if using more scanners makes you less secure then using fewer scanners should make you more secure and thus using no scanners would make you most secure... i don't know if that was the intended implication, i'm tempted to give the benefit of the doubt and suggest it wasn't, but the implication remains... again, there's more to security than what they're measuring - they're looking at one part of the change in overall security rather than the net change...
yet another point (well set of points, really) had to do with how av vendors handle vulnerability reports... as i said earlier, some of the vendors are taking far too long but some of the other things they complain about are actually quite reasonable in my eyes and i find myself in agreement with the av vendors... things like not divulging vulnerability details when there is neither a fix nor a work around ready yet (no point in giving out details that only the bad guys can actually act on), condensing bugs when rewriting an area of code (i develop software myself, it makes perfect sense to me that a bunch of related bugs with a single fix would be condensed into one report), fixing bugs silently (above all else, don't help the bad guys), and spamming vulnerability info in order to give credit to researchers (if you're in it for credit or other rewards you'll get no sympathy from me)...
finally, and perhaps the most novice error in the whole presentation was the complaint that scanners shouldn't flag archive files as clean if they're unable to parse them... there is a rather large difference between "no viruses found" and "no viruses present"... scanners do not flag things as clean (at least not unless the vendor is being intellectually dishonest) because a scanner cannot know something is clean - all a scanner can do is flag things that aren't clean and the absence of such flags cannot (and should not, if you know what you're talking about) be interpreted to mean a thing is clean... scanners tell you when they know for sure something is bad, not when they don't know for sure that something isn't bad... if you want the latter behaviour then you want something other than a scanner...
all this being said, though, i did take away one important point from the slides: not only is using multiple scanners not defense in depth, using multiple scanners in the faux defense in depth setup that many people swear by comes with security risks that most would never have considered...
Saturday, November 10, 2007
using multiple scanners is not defense in depth
i often come across nuggets of information that i want to respond to (often because they represent fundamental assumptions that i think are wrong) that don't really have anything to do with the main point of the article, so i'll leave it as an exercise for the reader to guess who mentioned using 2 different scanners as being a part of defense in depth...
that post didn't have anything to do with av and this post doesn't really have anything to do with that post but the idea that using one vendor's scanner at the gateway and a different vendor's scanner on the desktops qualifies as defense in depth is actually fairly old and oft-repeated so this really goes out to a fairly broad audience...
using multiple scanners is NOT defense in depth... at best it's defense in breadth... known malware scanners all have essentially the same strengths and weaknesses, they all look for and block essentially the same sorts of things, there's going to be very little caught by one that isn't also caught by the other so they don't really complement each other...
the premise of defense in depth is that any given defensive technique has both strengths and weaknesses and overall defense can be stronger if that technique is combined with one or more other defensive techniques that are strong where the first one is weak... no layer in the defense is impenetrable but in combination the layers together approach much closer to impenetrability...
so defense in depth requires complementary techniques/technologies and in so far as av companies are increasingly providing that in their suites, using similar products from multiple vendors doesn't get you any more defense in depth than you could have gotten with a single product because similar products are not complementary... what it can get you, however, is best of breed - some scanners may have features that make them better suited to gateway usage than others...
of course one could argue that they regard defense in depth as having defenses at multiple perimeters (the gateway and the host machines) but again, if those defenses are mostly the same then the inner layers of defense won't really be adding that much more to the overall defense... so using multiple similar products at different perimeters doesn't really add to the depth of your defenses, instead it adds redundancy which is the primary ingredient of fault tolerance...
that post didn't have anything to do with av and this post doesn't really have anything to do with that post but the idea that using one vendor's scanner at the gateway and a different vendor's scanner on the desktops qualifies as defense in depth is actually fairly old and oft-repeated so this really goes out to a fairly broad audience...
using multiple scanners is NOT defense in depth... at best it's defense in breadth... known malware scanners all have essentially the same strengths and weaknesses, they all look for and block essentially the same sorts of things, there's going to be very little caught by one that isn't also caught by the other so they don't really complement each other...
the premise of defense in depth is that any given defensive technique has both strengths and weaknesses and overall defense can be stronger if that technique is combined with one or more other defensive techniques that are strong where the first one is weak... no layer in the defense is impenetrable but in combination the layers together approach much closer to impenetrability...
so defense in depth requires complementary techniques/technologies and in so far as av companies are increasingly providing that in their suites, using similar products from multiple vendors doesn't get you any more defense in depth than you could have gotten with a single product because similar products are not complementary... what it can get you, however, is best of breed - some scanners may have features that make them better suited to gateway usage than others...
of course one could argue that they regard defense in depth as having defenses at multiple perimeters (the gateway and the host machines) but again, if those defenses are mostly the same then the inner layers of defense won't really be adding that much more to the overall defense... so using multiple similar products at different perimeters doesn't really add to the depth of your defenses, instead it adds redundancy which is the primary ingredient of fault tolerance...
Subscribe to:
Posts (Atom)