making sense of the cyberwar debate

if you follow the security blogs you've probably realized that there's some considerable disagreement about the subject of cyberwar. while i did touch on the subject once before, i don't think that really served to clear up anything.

making things more clear is actually rather important because, although us average folks may not be directly targeted in the course of a cyberwar, the consequences of one would affect us as surely as the consequences of a regular war would. sorting out the cyberwar debate is important because we need to know whether we have cause to be afraid, so that we can act accordingly.

there are basically two opposing viewpoints to this debate. on the one hand you have people like richard bejtlich saying cyberwar is real, and on the other hand you have people like bruce schneier saying the threat of cyberwar has been grossly exaggerated or robert graham who outright says that cyberwar is fiction.

the difficult thing is that both sides actually make excellent, compelling arguments - and if you're like me you probably feel like both are correct. but how can they be when they seem to be contradicting each other?

evidence is usually a good determining factor in a debate and bejtlich presents some compelling evidence in the form of online attacks (repeated security breaches of the joint strike fighter program) probably leading to a military outcome (advantage of the military hardware in question being lost and then the US scaled back their plans for it). that seems pretty convincing to me.

schneier expresses the doubt about cyberwar the most eloquently in a video of a debate he participated in - in order to have cyberwar you need regular war. cyberwar doesn't make sense without regular war. that's really hard to argue against, it makes a lot of intuitive sense.

the schneier debate video is interesting to me because as i watched it something seemingly obvious struck me and i was amazed that none of the participants seemed to come to the same conclusion i did. schneier himself came closest when he wrote about two different meanings of 'war'. later, as i read yet another cyberwar post from bejtlich, specifically the quotes from the DoD joint publication 1, the idea that i was on the right track was reinforced.

the reason both sides can seem to be right is because they're talking about two different things. i mentioned that schneier pointed to two different meanings for 'war', and i suppose you could leave it at simple ambiguity of the term (though it seems strange to think of 'war' as being ambiguous), but sometimes ambiguity arises from the fact that there's actually a better/more accurate term.

it turns out there is a word that is similar to 'war', that describes a concept very much related to 'war', that is often used interchangeably with 'war', and often is replaced with the word 'war' simply as a mental/verbal shortcut; and yet a word that actually means something different than 'war. can you guess what that word is?

warfare

as closely related as 'war' and 'warfare' are, there are important distinctions to make between them, and in this context specifically it's that warfare can exist outside the strict confines of a formally declared state of hostilities between two or more nation states (aka. a war).

warfare is going on all the time in the form of activities meant to prepare for war - and not even necessarily a specific war, but just war in general. espionage is one example; though it's not generally considered an act of war, the use of spies is so critical to warfare that sun tzu dedicated an entire chapter of "the art of war" to that very subject. there are any number of military exercises that also qualify as warfare, as does the development of new/better tools, techniques, and means of attack. peace-time cyberwarfare could reasonably be understood to include the ongoing enumeration of weaknesses, probing, and (hopefully) non-disruptive breaches and theft of secrets in a wide variety of one's adversaries' networks and systems. war-time cyberwarfare would, by extension, be the disruption of those systems and networks using what was previously found at times that are most advantageous.

from a north american perspective there is no currently ongoing cyberwar because there is no accompanying war to associate it with (at least none where there's compelling evidence that the adversary has included the 'cyber' theatre of combat). furthermore there's nothing i'm aware of to suggest that such a war is anywhere on the horizon. as such the threat of cyberwar can be considered to not be credible at this time. that said, there's no reason to believe that peace-time cyberwarfare isn't going on right now. nation states that intend to enter the 'cyber' theatre during war-time at some unspecified point in the future need to first be prepared to do so, which means gathering information on weaknesses and gaining access beforehand (ie. now). should we be concerned about that? sure, but only to the extent that we would be concerned about any military build-up, and even then we should temper that with the realization that at least part of the build-up is due to the new-ness of this sort of offensive capability (ie. they'll be starting more or less from scratch as opposed to a build-up above and beyond some established baseline) and not take it as a sign of impending attack.

we don't want an opposing nation state to be able to launch a debilitating attack successfully and so finding and eliminating the weaknesses they would try to take advantage of is certainly important, as is developing the abilities to detect attacks and recover from them. but there's no reason to believe they'll be trying to disrupt critical infrastructure anytime soon. as such our reaction shouldn't be characterized by fear, but rather by purpose and informed direction. being prepared is always preferable to the alternative.

offensive full disclosure

in my previous post about full disclosure i came up with some pretty restrictive guidelines for when full disclosure was ok. that was specific to disclosure of vulnerabilities in legitimate software/services. some time ago richard bejtlich published a post about about performing full disclosure for vulnerabilities found in attack tools - in other words the sort of software used by the bad guys to victimize innocent users.

while there is admittedly some gray area where legitimate software and attack tools might conceivably overlap, the tools richard described aren't anywhere near being legitimate - they are geared to exploit vulnerable systems and there's virtually no legitimate reason for doing that.

obviously that changes the ethical landscape a lot with respect to full disclosure. the users of such software are not innocent by definition, so actions that put them in harm's way aren't nearly so poorly regarded as those that put innocent users in harm's way. in fact, when cybercriminals are subjected to the same sorts of digital attacks as those they might otherwise perpetrate on others, some might even consider it poetic justice.

richard doubts the tactical efficacy of full disclosure against attack tools for 2 basic reasons:

1. it will alert the attack tool developers to the problem and ultimately result in the vulnerability being fixed
2. white hats have to follow rules that prevent them from forming waves of attacks against black hats the way black hats would do if a vulnerability in IE were disclosed

while reason #1 is certainly true, there's still a window of opportunity between the disclosure and the fix during which attackers could be successful. furthermore, there is an undefined window of opportunity between release of the fix and deployment of the fix when attacks could also be successful. remember that security fixes aren't necessarily applied as soon as they're available, and in the case of attack tools specifically there are a number of users of those tools who are not using the most recent versions because they don't want to pay for the product or for support. those using pirated versions of the attack tools are unlikely to get a fix and may not even be aware of a need for one - if they can't be bothered to pay for black hat software it's possible they don't care to invest in developing their own expertise in this field either (otherwise they could just build their own attack tools) and so probably wouldn't be paying attention to security advisories for the attack tools.

reason #2 is also true, but it assumes that the only people interested in attacking the black hats are the white hats and that simply isn't true. taking into account the low risks of getting caught that cybercriminals face, if i were a cybercriminal then the idea of letting some other poor shmuck run a criminal campaign and then simply breaking in and stealing their loot actually seems pretty appealing to me. there's less work involved, less visibility (and so even less risk than the poor shmuck who did things the hard way), etc. stealing from other thieves after they've already done all the hard work of collecting and aggregating whatever it is they were after just seems like the smarter way to go.

furthermore, from a white hat perspective having the black hats attacking each other is also appealing. the more they focus on each other the less they focus on the rest of us. of course, the point richard made about white hats no longer being able to use the vulnerability for their own operations against the attackers would still be true but only if full disclosure were followed in the case of all vulnerabilities. since that isn't the case for vulnerabilities in legitimate software, since only some of the vulnerabilities people know about get disclosed, i see no reason to worry about that happening in the case of offensive full disclosure. some vulnerabilities will no doubt be held back for precisely those sorts of operations.

frankly, i really like the idea of offensive full disclosure - it seems like a win-win proposition to me.

now read this!

there was a while there where i was posting links to other peoples blogs to help drive traffic to what i thought were good posts. i fell out of that habit, however, as it became forced and formulaic.

that doesn't mean i don't still come across good posts, but good just isn't really good enough - the criteria of "good" is too nebulous, it gets watered down and loses all meaning.

so now the fact that i'm pointing out a good post again actually means something because it's not just good - it's good enough that i felt moved to do this:

richard bejtlich's post on obama's cybersecurity speech (despite our philosophical disagreement over the classification of malware as a threat) was an excellent bit of creative re-writing of the original speech. for a moment i almost thought i was reading sun tzu again (yes, i am one of those people who reads and re-reads the art of war). if only such insight could have really come from the top like that (or at least been repeated by the guy at the top for everyone to hear).

availability > confidentiality + integrity?

umm, no...

chris hoff makes a valiant attempt at arguing for availability being more important that confidentiality and integrity combined (alluding to a previous discussion on the matter) using the example of the recent conflict between youtube and pakistan that left youtube offline for an hour over the weekend...

unfortunately, what he doesn't mention is that the availability problem that youtube suffered was as a direct result of the corruption of the routing information for youtube... in other words, unavailability was a symptom of an integrity problem...

which reminds me (because anton brought it back to the surface) of another recent article concerning the CIA triad... richard bejtlich posted his observation on the attack trends over the years and from his perspective availability (in the form of bandwidth) was the first to fall victim back in the mid 90's...

i don't think it would be unfair to suggest that richard comes from a network security background and views things through that lens, and i can certainly see where he's coming from given that... once again, though, this looks at a symptom rather than a cause...

causative agents don't generally reside in the network, they reside on devices (though sometimes they are the devices) and when they don't belong on the device they usually qualify as malware... malware goes back quite a bit further than the mid 90's and malware intrusion has always been fundamentally an integrity problem... this is why generic detection was traditionally performed using integrity checking, and even today many current generic controls have an integrity validation component...

of course that's just the lens that i see things through, but i'm not about to turn things around and say that integrity is a bigger deal than availability and confidentiality (especially since i can envision a third perspective where confidentiality is key)... ultimately i think the notion that availability trumps other aspects of security comes from the notion of aligning security with business... the alignment is often one-sided (security changes but management doesn't) and availability (and it's affect on the bottom line) is the thing that management understands best so that's what business-aligned security focuses on most... i wonder what it would be like if aligning security and business was a 2-way street...

why X is insecure - and probably always will be

about 2 weeks ago (old i know) you may have come across these two articles (by drazen drazic and lonervamp respectively) about why businesses are insecure (the 7 reasons why businesses are insecure and more reasons why businesses are insecure)...

i'm sure they're very good business reasons for why businesses are insecure, but i'm also sure that a business that addressed all of these problems would still be insecure for reasons that have nothing to do with that business or businesses in general or business security in general...

the fact is there's a technical reason why virtually any non-trivial thing (of which anything computer related would definitely fall under) we'd want to secure is almost certainly not secure and probably never will be... i'm not talking about the fact that there is no such thing as secure, rather i'm talking about the asymmetric relationship between attack and defense... if you're trying to defend something you have to try to defend it from all possible attacks, but if you're trying to attack something you only need to find one successful attack vector...

clearly defense takes a lot more work and that's a problem, but it's not clear that we can ever really change that... if we were going to try to change it, though, how would we go about it? the two obvious answers are: 1) make defense easier (presumably by reducing the amount of possible attacks we need to defend against), or 2) make finding that one successful attack vector harder...

making defense easier sounds good but it's easier said than done... sun tzu talked about this very thing when he said that one should force the enemy to engage in an environment of one's own choosing and thus choose what one has to defend and what the enemy can attack (art of war, part 6: weak points and strong)... now you might be tempted to limit the scope of your analysis to an arbitrarily narrow frame of reference (as schneier does here when he refers to cryptography to the exception to the rule of asymmetry between attack and defense) but in reality that doesn't actually get us any closer to our goal of reducing the amount of defenses we need... what we would really need to do is reduce the pool of potential attack vectors, to literally remove things from systems that could be used as an avenue of attack... that means fewer hosts on our networks, less diversity amongst the hosts on our networks (gasp! yes, i said it - diversity is great for minimizing the overall effect a successful attack has on a given population of hosts but it increases the pool of potential attack vectors and so makes compromising assets on the network easier; in essence, what's good for availability may not be so good for confidentiality), fewer services running on those hosts, fewer system components exposed to incoming content (ie. browsers, email clients and other network clients/servers that can do less/have less functionality), less potentially sensitive data stored on those hosts, etc... unfortunately this is completely backwards when viewed through the lens of technological progress, and while minor efforts in this area are no doubt considered beneficial, it would take extreme measures (perhaps even beyond the realm of the realistic given the complexity of modern operating systems) to actually make a significant change in the asymmetry between attack and defense for a system...

making it harder to find that one successful attack vector isn't necessarily a piece of cake either... there's one fairly well known school of thought that posits that reducing the number of vulnerabilities will shrink the pool of potentially successful attack vectors... this school of thought may be right, in a theoretical sense, but in practice it's starting to look like the total number of vulnerabilities is high enough that patching vulnerabilities at the rate we're going right now isn't really having that big an impact on the difficulty of finding a successful attack vector... another well known approach is to devise a system where the attacker has to successfully defeat multiple defenses in order to be successful on the whole... this is, of course, defense in depth... naively one might think this could put attacker and defender on more or less equal footing because now not only does the defender have to defend against a large number of possible attacks, the attacker has to breach a large number of possible defenses... unfortunately, there are only so many defenses one can reasonably deploy and, even with all of them deployed, the amount of work an attacker has to do still won't compare to the amount of work required for defense - nevermind the fact that all those defenses carry with them potential vulnerabilities which could themselves be used in an attack...

that said, it isn't necessarily true that we can't use the asymmetry to our benefit... we can, we just can't do it as a defender... richard bejtlich would i'm sure suggest what he likes to call threat-centric security but which, in the context of this post, i'll call offensive security - that is where we (who have things that need defending) go and 'attack' (as in track down, identify, charge, and imprison) those who would attack us... to quote sandi hardmeier:

Also - I have a special warning for the bad guys - you can hide from some of us, but you can't hide from all of us, and you most certainly cannot hide from your victims.

alas, this too is a kind of defense, and although we can turn the asymmetry around for individual cases, to actually protect our systems this way we'd need to go after all potential attackers (which is an unknowable set of people) whereas the attackers realistically only need to worry about the actual organizations/people they attacked (which is a much smaller and more knowable set of people)... ultimately, reducing the pool of attackers is much the same as reducing the pool of vulnerabilities - for each one you remove there's more where that came from...

so there really doesn't seem to be a good way to turn the asymmetry around and make defending easier than attacking... there are things that can improve the situation to some extent but it can be a real balancing act sometimes...

threat centric reality check

readers of richard bejtlich's tao security blog are no doubt familiar with a concept he frequently promotes called threat centric security... this is a security paradigm that tries to eliminate threats as opposed to vulnerability centric security which aims to eliminate vulnerabilities...

he's mentioned it in a number of posts and i've often gotten the feeling that there was something that wasn't quite right but i could never really put my finger on it until i read this article on bad guys last week where he said:

It's important to remember that we're fighting people, not code. We can take away their sticks but they will find another to beat us senseless. An exploit or malware is a tool; a person is a threat.

when i read that it suddenly became crystal clear to me, the underlying problem i had with what he was saying about threat centric security was rooted in his classifications....

on the one hand i can see where he's coming from; just about every negative security consequence we can think of can be traced back to a person or group of people... whatever the attack, there's always a person who initiated it and as the saying goes kill the head and the body dies... this is why one would say malware is just at tool, because one sees it as nothing more than an extension of the attacker and hypothesizes that if you take the attacker out of the equation the malware will become irrelevant...

there are a number of problems with this and the first is that malware is more than just a tool... a hammer is a tool and a person has to physically swing it each and every time s/he wants to strike a nail... malware, on the other hand, is an agent and has the ability to be far more autonomous... the most fundamental benefit an attacker receives by employing malware is automation; s/he may only need to press a button to start the malware doing a complex and time consuming set of tasks and it's not going to stop just because the attacker has been put in jail, it doesn't need the attacker at that point, it will just keep going until either it's programming or it's controller tell it to stop...

generally speaking viruses and worms have neither a built-in stop condition nor a controller interface that would allow someone to tell them to stop, so putting the person responsible in jail isn't going to have any affect on the spread of that virus or worm... this is part of the reason why old viruses never die and why there are still people out there trying to remove 15 year old boot sector viruses... once a virus or worm starts self-replicating in the wild, the person responsible is already out of the picture...

in spite of the fact that old viruses never die, some would likely argue that viruses aren't really a big issue anymore... fine, then let's talk about what has replaced them as the scourge of the internet - botnets... botnets do have a controller interface, but what good is that if the person doing the controlling is put in jail? maybe part of his/her sentence could be to instruct the bot software to uninstall itself from all the victim machines but that assumes that someone else hasn't already taken control of the botnet... just as thugs employed by a crime boss find a new crime boss to work for when the existing one is busted by the cops, so too can an existing botnet be used by a new crook when the old one is taken out of the picture... in this case it's not kill the head and the body dies, it's kill the head and a new head will come along and take it's place... ultimately the same is true of virtually all non-replicative malware in some sense - take one attacker out of action and another one steps in and continues using the malware... this is why it's important to consider malware as more than just a tool or extension of the attacker, it's an agent operating on behalf of an attacker and once it's been put into action taking the person responsible out of action doesn't change what it can do...

that leads us to the second problem - the conceit that fighting people can replace fighting code... at the end of the day the threat centric security that focuses on people is called law enforcement because the people in question are criminals... we all know how effective law enforcement has been at eliminating crime in the physical world so it shouldn't be too much of a surprise to realize that it will probably be no more effective at eliminating cyber-crime... a sword on the battlefield stops being able to cause you harm only when there's no one left to wield it; and so too with non-replicative malware, it only stops being able to cause harm when there are no more cyber-criminals left to employ it - and since there's a seemingly endless supply of criminals the malware will continue to be capable of causing harm in spite of our effects to put the criminals behind bars...

finally, on a historical note, in case anyone is thinking that the threat centric security that richard bejtlich talks about is something we need to start doing, it's actually been going on for rather a long time now... remember christopher pile aka the black baron? how about david l. smith aka vicodines? then there's mike calce aka mafiaboy and kim vanvaeck aka gigabyte... even robert morris jr. faced legal repercussions for the morris worm... that's going back nearly 20 years and it's just the tip of the iceberg as far as sheer numbers go...

don't get me wrong, i'm not knocking threat centric security, i think it's important, but there's more to it than just fighting people... malware in general has nothing to do with vulnerabilities so anti-malware security can't be said to fall under the umbrella of vulnerability centric security... even encarta says that things can be threats too... malware is a threat agent (or threat as those who prefer more ambiguous terms would say), it may not be in charge but it is a thing that acts to cause harm, and taking out those instances that come your way qualifies as a type of threat centric security...

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

why 'wipe and reinstall' is wrong-headed

there's been a long running debate about the best way to handle malware... some say using malware removal tools is best while others make a strong argument for wiping the drive and reinstalling from backups or even from original media...

richard bejtlich is a wipe and reinstall from original media proponent*... this is odd because you basically have the guy who popularized the awareness of extrusion in the security context advocating a method that makes determining the extent of extrusion of sensitive data from a malware incident impossible...

you see, historically people have thought of the malware problem as being simply a type of intrusion ('something bad got into my system/network') and that all you needed to do was get rid of the intruder, but now-a-days with the criminally oriented malware (crimeware) out there extrusion of sensitive data ('my passwords/credit info/banking info/etc got out') is increasingly becoming a very real possibility... while prevention is still just concerned about what might get in, recovery must now be concerned both with what got in and what might have gotten out...

back in the day, the one advantage a wipe and reinstall had over the more surgical malware removal was expedience - though never actually necessary, sometimes it was faster/easier to just nuke the drive and rebuild from scratch... no, certainty was not one of it's benefits, certainty was not there - just as richard points out that backups could have been compromised, so too can original media be compromised (it's happened in the past and it will happen again in the future)... as such, certainty in malware recovery is unattainable...

as technology has marched forward, the expedience offered by a wipe and reinstall (or similar methods like restoring drive images) relative to surgical malware removal has only increased but it comes at the cost of masking compromises to assets both on and remote from the affected machine... further, that expedience is very tempting to the lazy and/or ill-informed, it becomes the knee-jerk reaction to even a suspected compromise - after all, why bother with anything else if a wipe and reinstall will make it right regardless? why bother even getting a diagnosis?

the answer to that question, of course, is that without a diagnosis (literally, thorough knowledge) of the malware you can't hope to address the consequences of the malware... you need to know what the malware is, what it can do, how it got in, what it might have leaked out, etc... the wipe and reinstall advice that is generally bandied about trains people not to worry about or even think about those things, it implies that all you need to worry about is getting the intruder out... with thorough knowledge, on the other hand, surgical malware removal (preferably by replacing affected software objects with known clean copies from original media or backups where available, or using a removal tool dedicated to that one malware or it's family, or as a last resort using general purpose removal functionality built into most known-malware scanners) is possible, as is determining the likely entry vector and assets compromised...

admittedly, diagnosis and surgical removal may not be a speedy process... while home user machines are generally not mission critical, businesses/organizations often can't necessarily afford to have a production machine out of commission for the length of time it takes to find out everything you need to know... even then, wipe and reinstall is not the answer - instead create an image of the drive from the compromised system (or remove the physical drive itself and replace it with a fresh one) and then rebuild the system so that it can go back into production while retaining all the information necessary to complete the diagnosis after the fact... this has to be done with the awareness that one is putting the machine back into a potentially compromising situation before figuring out how to prevent subsequent/additional compromise, however...

[*update: apparently, richard bejtlich didn't mean what i thought he meant when he said the safest method of malware removal was reinstallation from original media... apparently richard was talking about the process of actually removing malware abstracted from the broader concept of malware incident response procedures - my apologies for the mix-up, but let the following sink in and you'll understand how the confusion occurred... for most people the process of actually removing malware is their malware incident response procedure - so much so that malware removal has become synonymous with malware incident response (to the point that it's used in preference of malware incident response simply because it's a more familiar term and because it's less jargon-laden)... no one really talks about literal malware removal abstracted from the larger context of malware incident response either because they don't recognize the difference between them or they do but the removal part by itself just isn't that interesting...

so i misinterpreted richard when he actually did talk about the removal part by itself, but i'm fairly certain he in turn misinterpreted the use of malware removal that he was responding to - malware removal certification will almost certainly include more than just getting the bad stuff out...]