Message-ID: <032201caaa84$9c770050$d56500f0$@wright@Information-Defense.com>
Date: Thu, 11 Feb 2010 06:09:38 +1100
From: "Craig S. Wright" <craig.wright@...ormation-Defense.com>
To: "'Sunnet Beskerming'" <info@...kerming.com>,
	"'Thor \(Hammer of God\)'" <thor@...merofgod.com>
Cc: 'full-disclosure' <full-disclosure@...ts.grok.org.uk>,
	pen-test@...urityfocus.com, security-basics@...urityfocus.com
Subject: Re: SMS Banking

" 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."
Please show how they are not.

" the probability of compromise of the system prior to the transaction
commencing"
Not at all. This is nothing to do with what I am stating.

".  The problem is that the full failure model is not taken into account, "
You have presumed this, and this is not the case.

" 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?
"
Where do you get this in my model shoot down part. As an ASCI, my model of
failure for SMS alone is:

	|      -------
	|     -
	|   -
	|===____________

That is, it becomes less secure over time and as users are added.

" even though it has just been shown to only affect a very small section of
the overall product lifecycle "
Actually, you have taken one small example and extrapolated this into what
you believe my model is. 

Regards,
...
Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
Information Defense Pty Ltd



-----Original Message-----
From: Sunnet Beskerming [mailto:info@...kerming.com] 
Sent: Wednesday, 10 February 2010 11:43 PM
To: Thor (Hammer of God); craig.wright@...ormation-Defense.com
Cc: pen-test@...urityfocus.com; full-disclosure;
security-basics@...urityfocus.com
Subject: Re: [Full-disclosure] 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