Message-Id: <0B06CB68-9F9E-477F-B69F-3F681FEB8A0A@beskerming.com>
Date: Wed, 10 Feb 2010 23:13:30 +1030
From: Sunnet Beskerming <info@...kerming.com>
To: "Thor (Hammer of God)" <thor@...merofgod.com>,
	craig.wright@...ormation-Defense.com
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>,
	pen-test@...urityfocus.com, security-basics@...urityfocus.com
Subject: Re: SMS Banking

Hi all,

I don't normally weigh into mailing list arguments, especially not those spammed across multiple mailing lists (yeah, I know this reply does that, too), and it's hard to find the appropriate point to interject comments, but this exchange has stirred the blood and irritated me to the point of throwing out my own point of view.  I'm not sure if we have all just been trolled expertly, but it seems serious enough to reply.

Thor, the following isn't really directed at you, I just chose your message as the one to reply to.

First, some background.  It has been a number of years since I formally studied statistics and failure modelling, though I am fairly current on James Reason's human failures modelling as it applies to aviation and at least one variant of risk management modelling and mitigation (even if it is largely a crock the way it is implemented).  As a result, there may be some errors in my arguments below.

I read through the post that Craig has placed online and there are a couple of seemingly critical faults in the model that have a massive effect on the overall reliability / strength against attack / resilience / number of kittens per square inch saved that a system displays.

It looks like Craig has defined parts of his model too narrowly, claiming that the probability of compromise is only a factor of the risk of compromise of the SMS system and the user authentication methods, which he claims are independent.

They are, to a point, and this is where I think Thor has the edge and will ultimately triumph in any real world test.  The factors are related, since most SMS systems are utilised as a second channel of authentication, but ultimately all the critical communications for a transaction session pass through the user's web session, where they have already provided their static user authentication (it doesn't really matter if we talk about pRNGs, it's static for the purpose of the transaction session).  It also doesn't matter whether the SMS is provided as transaction authentication, second channel authentication, or whatever, it ultimately provides the financial institution with a means to try and make the user liable for any subsequent breach.

The common weak point is the computer system.

It could be argued that the system is really part of the user authentication method, being critical to the method actually working, but it doesn't really fit into Craig's formuala.  The P(compromise) he puts forward is more the probability of compromise of the system prior to the transaction commencing, since it can be considered completely independent from the computer system at this stage.

If the user has had their mobile stolen and the thief also happens to know their authentication details, the compromise is complete, and the thief can then authenticate happily and Craig's formula holds up.

The downfall is that if this doesn't take place and the system being used for the transaction has been compromised, then the model has failed.  It doesn't matter what the original probabilities were for the user authentication or the SMS system were, the fact that the computer system is compromised means that the probability of compromise is now 1. 

Pushing past this probability, the modelling used for expected system life (failure modelling) doesn't seem to match with what reality seems to indicate.  To fit an exponential failure density function, it implies that any system is secure when initially released, rapidly becoming more insecure, to an inflection point whereupon the rate of insecurity increase tapers off over time, never becoming completely insecure.

Again, this is true to a point.  The problem is that the full failure model is not taken into account, merely the introduction of the lifecycle when the product comes out of Beta testing.  The system starts inherently insecure, gradually increasing in security during development, until at release, it is relatively secure.  Immediately following release, glaring errors are quickly found and this represents the exponential failure density function Craig puts forward.  This may or may not be a significant jump, but it does baseline the security of the system into the longer term.

A system that is maintained displays more of a sawtooth curve along this long-term period, ideally improving reliability following maintenance, but history has shown that the curve can trend towards more security or less, each time maintenance is applied.  If the system is not maintained, and even if it is, then it may be a significant period of time before its security is fundamentally broken.  At the point that security is broken, it can be considered that the system is completely failed.  With the key requirement to enact failure being knowledge and system accessibility, the moment that knowledge is public, or shared, then the system is inherently insecure.  Taking the overall system lifecycle (including development) into account, this gives a bathtub curve, with a sawtooth following system release and following maintenance activity.

The ASCII Insecurity vs Time curve.  

\                   /
 \  ____  ___|\----/
  \/    |/
 1 2    3     4    5

1 - Development and release - one of the most secure points in the product lifespan
2 - Craig's failure model - immediately post release, insecurity jumps as obvious issues are found, but then tapers off into maintenance mode
3 - System maintenance - system security is improved, but bugs are introduced that are found over time, returning security to previous levels
4 - System maintenance - reactive maintenance to a security problem (the uptick at the start), however the baseline system security is now more insecure
5 - Inherent Insecurity - security is fundamentally broken and either no maintenance is possible, or it is no longer maintained.  Sharing of knowledge makes any system implementation after this time inadvisable without other protections.

The problem faced is how do you know when the curve is going to tick up (or in Craig's models shoot down) at the end of the viable secure lifespan?  Thor's argument is that you don't.  It is effectively impossible to reliably predict when this will take place, but until it does it makes the modelling Craig puts forward seem relatively viable.  The downside is that it doesn't work as a reliable predictor, and you're going to be left stuck when the uptick takes place, having been encouraged to place faith in a model that doesn't appear to replicate the overall lifecycle effectively.

The slanging match that evolved has seemed to hinge on this.  Craig argues that he can reliably predict system security using his models, while Thor says he can't.  In the testing proposed, Craig asserts that his model will work (even though it has just been shown to only affect a very small section of the overall product lifecycle), while Thor's goal is to bring the end of the bathtub curve (the uptick) as far forward as he can.  With the vagaries and difficulties associated with development, and the problem that no one really understands the security domain well enough to have a really secure product that is actually usable, backing Thor and his team would be a very safe bet.  Even if the bathtub curve can't be completely shortened, enough of an uptick can be caused (the sawtooth bits) to exceed any threshold set by Craig.

Ad hominem attacks aside, I think Thor definitely has the upper hand in this particular case.  It is not possible to effectively predict when these upticks in insecurity are going to take place, nor how significant they are going to be, only that they will take place (the old when, not if argument) and this has a real, definite effect on system security predictability.  For all the fudge factors involved, you might as well use the Drake Equation as a quantitative predictor of system security.

Just some discussion points, that's all.

Carl

info@...kerming.com
 

Since we're spamming internet posts, the following discuss some of the issues with trusting SMS details just a little too much:
[1] - http://www.beskerming.com/commentary/2005/10/31/65/'Tis_a_Fragile_Thing
[2] - http://www.beskerming.com/commentary/2006/01/02/74/An_Inauspicious_Start
[3] - http://www.beskerming.com/commentary/2007/05/25/96/Free_Flight_Deal_Exposes_Customer_Data

On 10/02/2010, at 4:09 AM, Thor (Hammer of God) wrote:

> I'm looping in the FD list because often my replies don't make it to Pen-Test, and this has hit a nerve with me.
> 
> I've looked over your post at:
> 
> http://gse-compliance.blogspot.com/2010/02/modelling-risk.html .
> 
> Once I was able to get past the overwhelming egoism and self-substantiating claims of your contributions to the industry, I arrived at the conclusion that the only portion of the aforementioned page that is not complete drivel and even laughable to anyone who has actually worked towards ascertaining actual risk in production environments, is where you describe your own words as "ravings."  Ravings, of course, means "delirious, irrational speech."  
> 
> I'm fine with you sitting back and gloating about the Security Hero award you got from Northcutt, but when I see that you are actually contributing to ANY level of Critical Infrastructure Protection, it makes me fear for anyone who might be counting on your presumed skillset to actually make intelligent decisions about risk where human safety is at stake.  Your "risk formula" is ridiculous.  What number would your formula have yielded 2 weeks before SQL Slammer was released?  Where is the variable for unpatched systems?  What number do we plug in for malicious employee factorization?   More importantly, where is the calculation for self absorbed snake-oil selling academics with no real experience using their calculator to come up with magic numbers that represent the risk of a nuclear power plant being hacked?
> 
> Since you are (self-described) as "currently the only GIAC GSE (Compliance) holder globally and the most highly accredited Global Information Security Professional" and thus (presumably, if only in your mind) the greatest security mind in the world, how about accepting a challenge to an open debate on the subject at Defcon?  People like you are dangerous and need to be exposed before someone in a position of power actually believes that you know what you are talking about.  Bring your abacus.  
> 
> t
> 
> 
> 
> 
>> -----Original Message-----
>> From: Craig S. Wright [mailto:craig.wright@...ormation-Defense.com]
>> Sent: Monday, February 08, 2010 3:40 PM
>> To: Thor (Hammer of God); pen-test@...urityfocus.com; security-
>> basics@...urityfocus.com
>> Subject: RE: SMS Banking
>> 
>> " And just how do you come up with the probability of compromising the SMS function and the user authentication method?"
>> 
>> Actually, fairly simply using Bayes' formula.
>> 
>> I have posted on this at:
>> http://gse-compliance.blogspot.com/2010/02/modelling-risk.html
>> 
>> The comment was that GSM itself can be made more secure if it is coupled with another means of securing the transmission.
>> 
>> "if one can position one's self anywhere in the transmission chain."  This is a select number of locations. It is not everywhere. Though the number of locations may be large - it is not infinite. It is also not all points on the globe.
>> 
>> As can be seen in the post, what the effect of an SMS only based solution is a time degrading function. This is, the longer that the SMS application runs (alone), the greater the risk until eventually, the risk is maximised at certain failure.
>> 
>> Adding a second function, such as a non-SMS based sub-function can help to mitigate this, but a well chosen sub-function is more effective alone without the addition of the SMS measure and hence a better option.
>> 
>> The SMS function alone can befit from a second function, but this is only warranted if the SMS function is an essential process for some reason.

... irrelevance cut for brevity ...

>>> 
>>> Where a system uses an SMS response with a separate system (such as a web page), the probability that the banking user is compromised and a fraud is committed, P(Compromise), can be calculated as:
>>> 	P(Compromise) =  P(C.SMS) x P(C.PIN)
>>> 
>>> 
>>> Where: 	P(C.SMS) is the probability of compromising the SMS function and P(C.PIN) is the compromise of the user authentication method
>>> 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists