December 30, 2007
Why Security Modelling doesn't work -- the OODA loop of today's battle
Editor's note: now with a Chinese translation
I've been watching a security modelling project for a while now, and aside from the internal trials & tribulations that any such project goes through, it occurs to me that there are explanations of why there should be doubts. Frequent readers of FC will know that we frequently challenge the old wisdom. E.g., a year ago I penned an explanation of why, for simple money reasons, you cannot build security into the business from the early days.
Another way of expressing this doubt surrounding Security Modelling is by reference to Col. Boyd's OODA loop. That stands for Observe, Orient, Decide, Act and it expresses Boyd's view of fighter combat. His thesis was that this was a loop of continuous cycles that characterised the fighter pilot's essential tactics.
Two things made it more sexy: firstly, as a loop, he was able to suggest that the pilot with the tighter OODA loop would turn inside the other. This was a powerful metaphor because turning inside the enemy in fighter combat is as basic as it gets; every schoolboy knew how Spitfires could turn inside Messerschmitt 109s, and thus was won the Battle of Britain.
Obviously things aren't quite so simple, but this made it easy to understand what Boyd was getting at. The second thing that made the concept sexy was that he then went on to show it applied to just about every form of combat. And, that's true: I recall from early soldiering lessons on soviet army doctrine, that the russkies could turn their defence into a counter-attack faster than our own army could turn our attack into a defence. At all unit sizes, the instructors pointed out.
Taking a leaf from Sun Tzu's Art of War, the OODA loop concept may also be applied to other quasi-combat scenarios such as security and business. If we were to translate it to security modelling, we can break the process simply into four phases:
- threat modelling
- security modelling
- architecture
- implementation & deployment
To do it properly, each of these phases is important. You can't skip them, says the classical wisdom. We can agree with that, at a simple level. Which leaves us a problem: each of those phases costs time and effort.
A proper threat model for a medium sized project should take a month or so. A proper security model, I'd suggest 3 months and up. The other two phases are also 3 months and climbing, with overruns. So, for anything serious, we are talking a year, in total, for the project.
Now consider the attacker. Today's aggressor appears very fast. So-called 0-day viruses, month-long migration cycles, etc. A couple of days ago, there was this report that talked about the ability of Storm and Son-of-Storm's ability to migrate dynamically: "what emerges is a picture of a group of skilled, professional software developers learning from their mistakes, improving their code on a weekly basis and making a lot of money in the process."
Which means that the enemy is turning in his OODA loop in less than a month, sometimes as quickly as a day. Either way, the enemy today is turning faster than any security model-driven project is capable of doing.
What to do? Adolf Galland apocryphally told Reichsmarschall Göring that he could win the Battle of Britain with a squadron of Spitfires, but he was only behind by a few percentage points. In security terms we are looking at an order of magnitude, at least, which seems to lead to two possible conclusions: either your security model results in perfect security, there are no weaknesses, and it matters not how fast the enemy spins on his own dime. Or, classical security modelling is simply and utterly too slow to help in today's battle.
We need a new model. Now, this isn't to say "stop all security modelling." Even in the worst case, if the technique is completely outdated, it will remain a tremendously useful pedagogical discipline.
Instead, what I am suggesting is that the conventional wisdom doesn't hold scrutiny; something has to break. Whatever it is, security modelling is likely to have to change its practices and wisdoms, if it is to survive as the wisdom of the future.
Quite dramatically, indeed, as it possibly needs to achieve a 10-100 fold increase in its OODA loop performance in order to match the current enemy. In other words, a revolution in security thinking.
Editor's note: now with a Chinese translation
Posted by iang at December 30, 2007 08:59 PM | TrackBackfirst, a disclaimer, in the past, I sponsored Boyd for a number of presentations ... and applying OODA-loops to other kinds of competitive situations ... some past posts mentioning Boyd and/or OODA-loops
http://www.garlic.com/~lynn/subboyd.html#boyd
and various Boyd references from around the Web
http://www.garlic.com/~lynn/subboyd.html#boyd2
the other factor ... specifically with respect to payment transaction paradigm ... is related to old "security proportional to risk" ... and part of the justification behind aspects of x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#x959
aka ... with the current paradigm, attackers can afford to outspend the defenders by possibly 100:1 ...
http://www.garlic.com/~lynn/2007v.html#86
and
http://www.garlic.com/~lynn/2007v.html#87
and for a slightly different tact ... post on "Death of antivirus software imminent"
http://www.garlic.com/~lynn/aadsm28.htm#2
There is a crucial step before "threat modelling": business goals, step which can't be separated from security.
One can't start a financial service without considering security. Its implementation may be delayed, or implemented in steps, but it must be considered from the start.
A financial service has intrinsic security requirements. Such a service can't start on the idea that "we're gonna transfer money from A to B". The crucial requirement here is "we're gonna transfer money from A to B, SECURELY", where "securely" means something specific only in the context set by the business goals.
"We want to make an online account based financial service which transfers money from A to B" is something like, say, EGold.
"We want to make an online account based financial service which transfers money from A to B, where non-generalized insider attacks can't physically succeed" is something which doesn't yet exist (but can).
The business goals above precede and thus define the framework of the future security modeling.
We have come to a similar conclusion, and started to design deployable structures that businesses can adapt and have that "instant" security design they were looking for. So far we have designed anonymous tech support with secure authentication, some disassociated databases, and most recently we designed a system called VAULTS which allows KYC but authenticated and anonymized goods/service delivery.
We work on a theory of least needed information. If we don't store or have access to juicy data, it isn't there to be compromised. Neither internally or externally. Databases don't need to be together, accounts don't need to be linked, data doesn't need to be stored plaintext, servers don't need access to each other, systems don't need knowledge of each other, or dependencies, and most importantly, neither to admins or engineers.
We go to some length to disincentivise attacks throughout the system by bleeding out unnecessary rewards to security attacks, and setting up defense in depth tactics while employing leveraged unpredictability in our structures inbetween these modules.
The idea is instead of designing a system that can fail if one gear gets trashed, you design your business security in cells that are deployable with difficult to compromise structures. This essentially turns a walnut with a hard shell but delicious core, into a rather unpalatable sack of dried rice.
These strategies can be employed even by small businesses, as they are modular components. It only takes someone to write an open-source library for the implementation and then everyone can begin to incorporate these things. So with only a few hours of coding by competent coders and sec minds, even a startup can open it's doors with a staggering amount of security infrastructure.
Posted by: Steve T at December 31, 2007 05:49 PMre:
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modeling doesn't work -- the OODA-loop of today's battle
I had become acquainted with John Boyd in the early 80s and sponsored him for a number of corporate conferences. He was retired and giving talks for just his out-of-pocket expenses.
despite enormous contributions in numerous areas, much of the establishment preferred to act as if he didn't exist ... possibly because he had low tolerance for numerous things. He made the F15, F16, F18 and whole generation of airplane design what they are today ... but the air force almost acts as if he wasn't there. he was eventually adopted by the marines (adapting aerial dog fights and ooda-loops to ground warfare).
some recent long-winded posts in financial transaction related subthread ... that much of the current "risk" isn't because the information is so easy for the crooks to obtain ... but the fundamental "risk" is that the crooks can use the obtained information for fraudulent transactions.
http://www.garlic.com/~lynn/2008.html#4
http://www.garlic.com/~lynn/2008.html#5
http://www.garlic.com/~lynn/2008.html#7
http://www.garlic.com/~lynn/2008.html#8
http://www.garlic.com/~lynn/2008.html#9
this is also the previous comment that the crooks (attacking the information) can outspend (by possibly 100:1) the merchants (attempting to prevent information access).
the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
rather than attempting to prevent all possible access to the information ... changed the paradigm and made the information useless to crooks for generating fraudulent transactions (eliminated the risk). this is somewhat the thread here this summer about the naked transaction metaphor
http://www.garlic.com/~lynn/subintegrity.html#payments
re:
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#5 Why Security Modelling doesn't work -- the OODA loop of today's battle
taking a slightly different "Boyd" perspective
http://www.garlic.com/~lynn/subboyd.html#boyd
some of the current problems could be attributed to not having a strong defensive position ... which gives the attackers an enormous advantage ... referenced in this thread/post
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software imminent
my wife's father graduated from west point (and then got a engineering graduate degree from berkeley) ... however, one of the things that typically is taught is how to choose your defensive position. he had been engineers for patton and frequently was ranking officer into enemy territory ... and acquired a collection of officer (silver, gold, platinum) daggers in surrenders. he also was involved in liberating some number of camps.
Posted by: Lynn Wheeler at January 2, 2008 02:26 PMYes, I think it is curious, but people are very slow to wake up and realise there are systemic flaws in our security situation. All those things that we ignored because they were too tough in the past are now starting to haunt us.
I find Boyd to be interesting for 2 reasons: one is that his theory & concepts are relatively easy to understand, unlike most other war-like academics. The second is more snippety; in that it seems that Americans have finally found a recent academic military hero. In the past, most of the history of warfare has been written by other countries, and all countries have always tended to promote their own academics. But Americans didn't really have someone who stood out alongside Sun Tzu, Klauswitz, Fuller, Guderian, etc.
So for that reason, he's very popular, and worth using as an example. Whether we can make a dent in the "security modelling" practice remains to be seen, but something has to be done.
Posted by: iang at January 3, 2008 09:58 AMBoyd characterized US WW2 strategy as massive logistics (overwhelming enemy by 10:1 resources) and extremely rigid command and control. Part of this was claim that US entered the conflict with very few professional soldiers and quickly fielded a large number of rapidly mobilized citizens. Part of the extremely rigid command and control was to leverage the experience of the few professional soldiers and part of it was to manage the enormous logistics operation.
As a contrast, he would quote Guderian, on the eve of the blitzkrieg "verbal orders only". This is related to the definition of auditors as the people that go around the battlefield after the war, stabbing the wounded. The claim was that Guderian wanted the professional "on the spot" to make decisions and not have to worry about any monday afternoon quarterbacks.
In the early 80s, Boyd claimed that the rigid command and control structure with underlying assumption that the majority of people were unskilled ... were adversely affecting US business, as the young WW2 officers came to major executive positions (and they reflected their WW2 training).
This theme was also behind his briefing "Organic Design For Command and Control". I have a copy of the original version and some subsequent copies as it evolved over time.
Posted by: Lynn Wheeler at January 3, 2008 12:12 PMIt was interesting to read your notes on soviet military doctrine (btw, you've got it quite well), granted it is my past and I have to identify myself more with "the other side" ;)
Posted by: A.T. at January 8, 2008 03:15 AMDid everybody get it? A picture of Me-262 - the first jet fighter - right under a call for a "revolution in security thinking"?
Posted by: Anton Chuvakin at January 11, 2008 11:42 AMMe-262: lol, I'm glad someone got it :)
A.T.: tell us more! I always wondered if it was true ... and what did they tell you about the other armies that left you worried?
Posted by: iang at January 11, 2008 12:08 PM