[Full-disclosure] FW: SMS Banking

Why exactly are we still talking about the 100 packages? To assist you in changing the "model" to "predict code vulnerabilities" as opposed to "calculating the risk of compromise?"

You are the only one who came back with the "code vulnerabilities are just one part of risk" backstroke. Go through my replies, and my initial challenge to you. You said "risk of compromise." Propensity of code vulnerabilities means nothing here, so stop trying to weasel into that. Contract. $100,000. Your reputation is on the line, sir.

" You are changing the bet in mid-stream "
Not at all. This was and is the bet. The initially proposed 2 tasks
remain
unchanged.

The statement on SMS was that this is a time degrading risk function.
That
is, the proposed SMS solution would become less secure over time. The
longer
it ran, the more attacks. It would also be a function of users, the
more
users, the less secure. In case you cannot understand what the SMS
quote you
have means, it simply means that adding an independent 2nd factor
lowers the
inherently high risk of a purely SMS based system.

"The risk of deploying any given solution takes into account FAR too
many
real-world elements than any formula can address. "
The SMS formula is not the be all - it was a simple extrapolation

based

on a
highly insecure proposal. My model as I have put it is an expert
system. The
risk associated with each application on a system is derived as with
dependence and path.

First and foremost, the most important question, followed by a
subsequent
statement addresses this:

Code vulnerabilities is but a single risk measure (see below for

where

this > fits). My Question to Tim is are you implying that you

cannot

do
this?

Knowing the likelihood of code vulnerabilities and the rate comes

to

patching and hence implementation issues. I am stating that I can

model

this. I will put my reputation etc on the line (as well as a large
quantity of cash) on the assertion that I can model the risk of

software
within

a set > confidence bound given the a prior information on the

product,
user

base and such other information against a qualitative

determination.

You are changing the bet in mid-stream. You are now saying you can
model
likelihood of code vulnerabilities based on past discoveries.

Several

points:

Code vulnerabilities does not equal risk. They are code
vulnerabilities.
You said you could predict the "risk" of an SMS banking solution with
your
formula. I say that you, unequivocally, cannot, and that such a
statement
is ridiculous. Hence the bet.

The risk of deploying any given solution takes into account FAR too
many
real-world elements than any formula can address. For instance -
Let's take a system; any system that allows unencrypted login via the
internet. Your formula cannot determine "risk" in any way. If the
system
is storing the names of the Seven Dwarfs, then there is not much

risk.

If
the same system allows one to shut of grid power to NYC, then the

risk

is
increased. To the point of you being able to "predict" what future
code
vulnerabilities are, I'm even dubious on that. You can indeed create

a

model, but will it be accurate? No - you have no idea what
vulnerabilities
lie in wait. Will it be statistically accurate based on math? I

don't

know, and more importantly, I don't care. Whatever "number" you come
up
with will be worthless in its application to risk without other
factors.

My $100,000 bet, that I accept, is based on the fact that your

results,

whatever they are, will be WRONG when ascertaining true risk, which
this is
all about. I am extremely gratified that this has gotten the

attention

that
I desired it would, because it brings to light the true dangers of
having
people with your mindset involved in critical infrastructure

protection

-
the OTHER reason I got involved with this. If you are so eager to

give

away
(which you will) $100,000 of your money to support such a foolhardy
stance
such as calculating risk based on past software vulnerabilities, what
would
you do when making the same decisions that protect water and power
systems?
To that end, I am happy to see not just your money, but your
"reputation" as
you put it, at stake here.

The results I generate will have nothing to do with whatever numbers
your
model spits out. The bet is not if you can come up with a formula

that

produces numbers. The bet is that THOSE NUMBERS will be proven

wrong.

You
cannot gauge risk with the "simple formula" you posted on your site.
Period. THAT sir, is the bet, and that is the bet that you already
accepted, in writing.

Breaching the system that you put up further has nothing to do with

you

calculating risk. But that's fine with me. A few questions to the
board on
SANS before I get into that. I'm assuming that Craig's enlistment of
your
input is sanctioned? Craig speaks for you in regard to having your
students
be the ones that set up a system that gets hacked into and $100,000
lost?
Am I to understand that SANS endorses Craig's Magic Risk Formula, and
that
this is something you recommend your clients/customers use to

determine

risk? I need to know this in order to ensure that all the parties

are

properly referenced in my acceptance speech. I further suppose it
would be
rude not to extend invitations to the parties involved to the party
following.

Since SANS is involved, at least by proxy and extension, shall I

assume

that
you (Craig) will embrace SANS' raison d'être when building this

system?

I
ask because this is where the "Thor can do whatever he wants" again,
that is
already in writing, comes in. SANS's exists to help companies
determine
risk and analyze the security of systems in the "real world." If
people
didn't configure systems incorrectly, deploy unpatched systems, and
write
poor code, SANS wouldn't exist. I'm assuming that the historical

data

you
presume to include in your Magic Number will be extended to this
installation? Meaning, one can expect to see the typical
vulnerabilities
found in deployments present in this system? Or do you intend to
create an
uber-hack-proof system to substantiate your reputation, thus

obviating

the
usefulness that SANS as an organization provides? Clearly, if all
systems
in the world were set up how one might assume you will set up yours,
there
would not be a need for SANS anymore (if that idea is taken to the
extreme).
In fact, the need to calculate risk would be obviated. But I

supposed

that
is another story.

Not only will I take your money, and ruin your reputation in this

bet,

but
I'll tell you how I will do it UP FRONT. Will that be fair enough?

Go

ahead. Set up your system. If I have someone show up at the door

with

a
shotgun and ask for the hardware, do I win? Or will you cry "Hey,
that's
not fair. Do over!" Do you not think the criminals of the world do
things
like that? Where in your formula do you plug that in? Do you even
know
what the majority of the breaches in the world are from? What about
when I
call a student and say "Hey dude. There's $25,000 cash in it for you
if you
give me the admin password." Would you cry foul? Where in your
formula do
you plug that eventuality in? Don't forget that you said "Thor can

do

whatever he wants."

We don't need to bother with the 100 packages. Bring in your SANS
students,
assuming you speak for SANS since you looped them in on the Full
Disclosure
list, and presumably trust you enough to weather the backlash of

their

students being the ones to configure the system that will be hacked,
configure your system, and put it up. Hell, Craig - I don't even

care

if
you turn it on; just leave the check taped to the hard drive (I'm

being

facetious of course on that part - I just can't help but have fun

with

this.)

To keep it even more simple, and so everyone here sees, this is what

I

will
disprove beyond a shadow of a doubt. I quote you directly:

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

That is the "probability of compromise." COMPROMISE. Not "model

that

just
might predict software code vulnerabilities." I will PROVE that your
figure
is WRONG and in the process, PROVE that your formula cannot be used

Hi Again Thor/Tim and now others,
I have added a few people to this email. As a summary to those

joining,

"Thor" (really Tim) has the notion that you cannot quantitatively
measure
information system risk and thinks Bayesian statistics,

computational

chaos
and heteroscedastics (my fields) cannot measure risk.

From the "discussion" that has ensued, Tim and I have ended in a

gamble

where I shall be using the my skills in math and those of both
practical
experience and importantly all I have learnt from SANS over the

many

years
against anything he wishes to being to the table.

There is some information included below, but as a summary, myself

and

another party will measure the risk of software and systems. This

will

be
100 software products and 50 systems to be independently deployed.

Code vulnerabilities is but a single risk measure (see below for

where

this
fits). My Question to Tim is are you implying that you cannot do

this?

Knowing the likelihood of code vulnerabilities and the rate comes

to

patching and hence implementation issues. I am stating that I can

model

this. I will put my reputation etc on the line (as well as a large
quantity
of cash) on the assertion that I can model the risk of software

within

a set
confidence bound given the a prior information on the product, user
base and
such other information against a qualitative determination.

I have stated an independent third party will configure systems.
Neither Tim
nor I will set the systems up. This will be done correctly without
bias. I
have added Stephen to this discussion as I will be proposing an
exercise for
SANS Students. I will elaborate this later. The basic gist is that

SANS

conference attendees and students generally could be involved. The

idea

is
that neither party to the test will have an insight or knowledge

that

exceeds the others from any unfair means.

I will up the bet to the 100k amount if this is Tim's desire. We

will

set
this as an escrow. That is, an independent party (merchant bank)

will

hold
the money. We each pay in advance. The money will be held earning
interest
until this exercise is complete. Ben is included in this email as

he

is

one
of the most IT savvy and security knowledgably attorneys around. He

is

NOT
my attorney, but he knows more than enough to (for valid

consideration

that
I will fund) set the escrow conditions.

Tim states below, "they will be 100% vulnerable to immediate
"exploitation"
My question to him is are you stating that the systems will be 100%
vulnerable? Is this your response or would you like to actually

test

the
system?

I will give Tim an out or at least an advantage if he wishes. I

will

still
do all I have stated, but I will also give him an additional

option.

This
is, I will configure a server running a BI (Business Intelligence)
application and Database accessed over the web with an SSH server

for

admin
access and management. If either I fail to predict risk within a

95%

confidence interval OR you breach this system in the time period (a
whole 6
months), I lose the bet.

As stated, the money will be escrowed. Once started, we each put

our

money
where our mouth is so to speak. If you EITHER predict correctly OR
compromise a single system - you (Thor/Tim) win. Otherwise - Tim

has

to

admit error.

This has escalated to a US$ 100,000 bet. The contract will be
formalised,
but this is an offer (in fact, the other offers are also accepted

at

lower
values, but we each have too much testosterone).

There are two components;

1 A selection of software products are tested using both

processes,

that is I use a model for the risk of these products, and "Thor"

can

make up
whatever guesses he wishes. We model (or "Thor" guesses, pulls from

a

hat...) the vulnerabilities over a time period. The number of bugs

in

software as well as the risk are to be presented as a monthly

estimate.

2 We model a few systems (say 50). We can use Honeypots (real
systems
set to log all activity without interference) run by an independent
party to
each of us. I use probabilistic models to calculate the risk.

"Thor"

does
whatever he wants to test these, audit them etc and predict risk.

These

systems are to be logged and all the data recorded. The full rules

and

restrictions, setup processes etc will be incorporated into the
contract.

I put my knowledge from Bayesian Statistics, Computational Chaos,
financial
modelling and heteroscedastics that is coupled with around 30 SANS
courses/certifications and all the other bits against Tim's

arsenal.

Part 1
Tim has to select 100 commonly deployed software products. I will

not

intervene, but I will have these challenged if they are NOT

commonly

deployed. Hence CC'ing the SANS Advisory Board. I propose these
individuals
as the people who can veto a choice if the software is obscure.

Now you're talking. But first let's work up an actual contract.
Neither of
your components define anything. When you say that you are going

to

predict
"risk" with your magic formula, do you mean if the software has
vulnerabilities? That it can be hacked, or will be hacked?

Be sure to define this properly and definitively - if you end up

saying

that
a system has a 1% change of being hacked, and I (or my auditors)

hack

it,
would you claim you were "right"? I question if you can even

define

the
parameters of this bet, much less apply your formulas, but we'll

see.

I also want to know what "scale" you plan to use. So far, even

though

I've
asked, you've not provided what the "answer" to your formula is, or

how

it
will be applied. I'm assuming, unless you are going to change

your

tune
which I wouldn't doubt, that you won't look at the software code or
threat
models, but rather apply your formulas. I further assume that the
"loser"
will be financially responsible for the "audits" done my way.

I'm more than happy to take your money, and I look forward to doing
so.
Since one of your masters degrees is in law, I'm assuming you can
clearly
define the terms of the contract. I will, of course, insist upon

scientific method of determining truth.
"Thor" wants a challenge, let's have one - a real one and not one

based

on
verbalisations, abuse and unfounded assertions.
I suggest two components;
1 A selection of software products are tested using both
processes,
that is I use a model for the risk of these products, and "Thor"

can

make up
whatever guesses he wishes. We model (or "Thor" guesses, pulls from

a

hat...) the vulnerabilities over a time period. The number of bugs

in

software as well as the risk are to be presented as a monthly

estimate.

2 We model a few systems (say 50). We can use Honeypots (real
systems
set to log all activity without interference) run by an independent
party to
each of us. I use probabilistic models to calculate the risk.

"Thor"

does
whatever he wants.
Each of the predictions is published by all parties. The one who is
most
accurate wins. Fairly simple?
I will even give a handicap to "Thor", I will offer to predict

within

a

95%
confidence interval and that for me to win, at least 90 of the 100
software
products and 45 of the 50 systems have to lie within my predicted

range

that
I calculate and release. "Thor" has to simply guess better than I

do

no

matter how far out he is.
I will put up $10,000 Au for my side. Let's see if "Thor" has

Relevant Pages

[Full-disclosure] FW: SMS Banking... looks like SANS has dumped you Craig. ... Subject: [Full-disclosure] SMS Banking... The statement on SMS was that this is a time degrading risk function....(Full-Disclosure)

Re: [Full-disclosure] SMS Banking... And now before the contract is written these need to be selected? ... Subject: [Full-disclosure] SMS Banking... I stated Tim can breach a system I build in ANY way. ...(Full-Disclosure)

Re: [Full-disclosure] SMS Banking... And the SMS model is also inherently unreliable. ...risk my way, you assess risk with your calculator. ... Subject: SMS Banking... "And just how do you come up with the probability of compromising...(Full-Disclosure)

Re: [Full-disclosure] SMS Banking... AFAIC, this entire exchange has been worth it for a number of reasons - I'll highlight for those with a life, and I'll move on to engage in things that actually matter. ... Subject: [Full-disclosure] SMS Banking... brought to my attention that drafting a contract with Dr. Wright ...(Full-Disclosure)