Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: SMS Banking
From: "Thor (Hammer of God)" <Thor () hammerofgod com>
Date: Wed, 10 Feb 2010 21:14:27 +0000

Give me a draft as if they are included. Write "draft" on it.

Define what risk is and what the number means.  You've yet to do this (because you can't).  By the "risk," include in 
your definition what you said at the start:  "The probability of compromise." Not "new vulnerabilities discovered" as 
you've repeatedly tried to change it to.

That has nothing to do with risk.  You said, and I quote, "I will define scale here first."  Do that.  Show us, in 
writing, that you are going to predict the probability of compromise.  Not "new code vulnerabilities discovered," not 
"square inches per kitten," and "the number of times I try to weasel out."

This is "strike-two" for you.  You can't change what you've already written.  Coming back after the fact with the "list 
this first" won't work anymore.  Or you could just do everyone here a favor, and come back with "No, I want my list 
before I define anything of meaning because that's what is buying me time."  Tell us what you will be measuring and how 
things get qualified, and we (I) can come up with a list of software packages.  "Calc" is a common program, but I'm 
sure that shouldn't be on the list.  Last chance, genius.

t


-----Original Message-----
From: Craig S. Wright [mailto:craig.wright () Information-Defense com]
Sent: Wednesday, February 10, 2010 12:34 PM
To: Thor (Hammer of God); 'full-disclosure'
Cc: pen-test () securityfocus com; security-basics () securityfocus com
Subject: RE: [Full-disclosure] SMS Banking

The single system you have to breach is one I setup.

There will also be 50 systems setup to a standard and deployed. The
statement was to predict the risk associated with these. We each have
to do
this, you can if you wish say that this is 100%.

" Contract.  Contract.  Contract."
As I have requested, choose the 100 products. These need to be included
in
the contract. I would have thought this a simple task.

Point 1 is:
"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."

I will address points 2 and 3 in order. Provide the products for point
1 and
then we can move to point 2.

Contracts require definition. You have to supply the products as a
list.
This is not I would think a difficult task. As stated, I have a 95%
confidence interval set for this.

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



-----Original Message-----
From: Thor (Hammer of God) [mailto:Thor () hammerofgod com]
Sent: Thursday, 11 February 2010 7:22 AM
To: craig.wright () Information-Defense com; 'full-disclosure'
Cc: pen-test () securityfocus com; security-basics () securityfocus com
Subject: RE: [Full-disclosure] SMS Banking

Oh, now I have to obtain a file from your BI app from an encrypted
drive and
field?  Do you mean "a file" or do you now want to throw any other
"after
the fact" stipulations to cover your butt?  Shall you deploy the system
on
the moon, Craig?

Breach means breach. The passage that you continue to reference says
50.
Are you officially changing that?  And now before the contract is
written
these need to be selected?  Why?  Write up "50 to be determined."

Stop adding things on.  Be a man, and own up to the consequences of
your
ignorance.  Stop putting additional conditions on things and trying to
tell
me what YOU'VE decided the next step is.  Your technical competence is
already in question (notice how I spelled "technical," feel free to use
that
as a guide when you fix the spelling on your CV).  Please let's not
bring
your honor and integrity into question here.

You've totally failed to even answer the question on what you are going
to
DO with the software packages or answer the questions I've posed.

I will explicitly clear on this - I'm calling you out publically.  I am
calling your methods ignorant and not applicable.  Answer the questions
posed to you; don't continue to add things on about your now "encrypted
drive" and "encrypted fields."  The world is the witness here "Dr."
Put up
or shut up.  You bore me now.  Anything beyond this that you don't
produce a
contract for will be taken as more sidestepping.  Even the people you
got
your "only certified whatever in the world" from dumped you - isn't
that
enough?  Anyone who ever reads this, which is already all over the
internet
is going to see that you've just weaseled out.

Contract.  Contract.  Contract.

t


-----Original Message-----
From: Craig S. Wright [mailto:craig.wright () Information-Defense com]
Sent: Wednesday, February 10, 2010 12:03 PM
To: Thor (Hammer of God); 'full-disclosure'
Cc: pen-test () securityfocus com; security-basics () securityfocus com
Subject: RE: [Full-disclosure] SMS Banking

" Plain and simple.  Produce the contract, here, publically.  I'll
produce
my $100,000 that you match, in escrow.  If the system gets breached,
any way
I choose, I win and you lose your money and your reputation.  If it
doesn't,
you get my $100,000 and your number theory still goes unproven (and
wrong.)"

I stated Tim can breach a system I build in ANY way. He has this
option
as
well.

My system, web, database, ssh and a Business intelligence
application.
All
open source. If you wish to breach this physically, I shall not stop
you,
but the disk and key database fields will be encrypted. Your goal is
to
obtain a file from the BI app. You can have up to 6 months to do
this.

The selection of 100 software products to be modelled remains
outstanding.

I have this as Tim's first task. So that I can get the contract
authored, he
needs to make this selection.

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



-----Original Message-----
From: Thor (Hammer of God) [mailto:Thor () hammerofgod com]
Sent: Thursday, 11 February 2010 6:39 AM
To: craig.wright () Information-Defense com; 'full-disclosure'
Cc: pen-test () securityfocus com; security-basics () securityfocus com
Subject: RE: [Full-disclosure] SMS Banking

Yes, you SUGGESTED.  I retorted:

[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?]

You replied "anything can be hacked."  Brilliant non-answer to the
question.

I go on to say:
[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.]

No answer.

YOU then try to bring in yet another "condition" which was never
agreed
to,
saying "Code vulnerabilities is but a single risk measure (see below
for
where this fits)."

I say forget about the 50, so you change it to 100.  Nice.

Let's get to the meat:

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

This is all we need to do.  Stick to this.  The 100 software packages
don't
matter - you'll just lose anyway and there is nothing for you to gain
with
the inclusion.  Put on your system.  You fail to predict OR the
system
gets
breached at my direction.  If that happens, I win.

And "Thor can do whatever he wants."  Don't forget that you included
THAT in
your original soon-to-be-rescinded-by-you bet.

Plain and simple.  Produce the contract, here, publically.  I'll
produce my
$100,000 that you match, in escrow.  If the system gets breached, any
way I
choose, I win and you lose your money and your reputation.  If it
doesn't,
you get my $100,000 and your number theory still goes unproven (and
wrong.)

So again, I ask, contract please.

t





-----Original Message-----
From: Craig S. Wright [mailto:craig.wright () Information-Defense com]
Sent: Wednesday, February 10, 2010 11:27 AM
To: Thor (Hammer of God); 'full-disclosure'
Cc: pen-test () securityfocus com; security-basics () securityfocus com
Subject: RE: [Full-disclosure] SMS Banking

Please do not misquote. The bet was:
" I have a simple answer to this. Forget the debate, rhetoric is
not
a
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
something
real
to offer."

You stated acceptance of this, have you changed your mind?

" You won't wiggle out of this one, sir.  You've bet $100,000 that
you
can
put up a system that can't be hacked.  You've staked your
reputation
on
the
fact that you can use a calculator to determine the probability of
a
system
being compromised. Please note that *I* don't even have to hack it.
In
fact, I plan on being on a beach somewhere after offering $10,000
for
someone to hack it for me.  There are about 1 billion people in
China
would
could use $10,000.  But that's another story. "
I also offered you the chance to compromise the system I put up.

"calculating the risk of compromise?"
The second part is 50 systems that are setup and run. I model risk
and
we
see if this matches the systems as predicted.

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



-----Original Message-----
From: Thor (Hammer of God) [mailto:Thor () hammerofgod com]
Sent: Thursday, 11 February 2010 2:54 AM
To: craig.wright () Information-Defense com; 'full-disclosure'
Cc: pen-test () securityfocus com; security-basics () securityfocus com;
stephen () sans edu; 'Jeff Frisk'; advisory-board-open () lists sans org;
'Ben
Wright'
Subject: RE: [Full-disclosure] SMS Banking

Outstanding.  Things to take into account while drafting the
contract:

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
in
any
meaningful way,  Period.

Please let me know when you've got the contract ready.

T


-----Original Message-----
From: Craig S. Wright [mailto:craig.wright () Information-
Defense.com]
Sent: Wednesday, February 10, 2010 12:22 AM
To: Thor (Hammer of God)
Cc: pen-test () securityfocus com; 'full-disclosure'; security-
basics () securityfocus com; stephen () sans edu; 'Jeff Frisk';
advisory-
board-open () lists sans org; 'Ben Wright'
Subject: RE: [Full-disclosure] SMS Banking

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.

I shall be listing these in the contract that we will each sign
as
a
deed.

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


From: Thor (Hammer of God) [mailto:Thor () hammerofgod com]
Sent: Wednesday, 10 February 2010 5:42 PM
To: craig.wright () Information-Defense com; Valdis.Kletnieks () vt edu
Cc: pen-test () securityfocus com; 'full-disclosure';
security-basics () securityfocus com
Subject: RE: [Full-disclosure] SMS Banking

See my follow up email first.

Are you asserting that your entire basis for what "risk" is
comprised
of is
the number of new vulnerabilities found in code?   Risk=code
vulnerabilities?  Please tell me you know more about this
industry
than
that.   Actually, DON'T tell me that.  I don't want to start to
feel
more
sorry for you than I already do.

We don't need six months.  Pick whatever 100 you want.  Come up
with
your
risk factor.  I'll deploy them, and they will be 100% vulnerable
to
immediate "exploitation" and I'll laugh at your "risk figures"
all
the
way
to the bank.    This is getting better by the minute.

Care to up your bet?  I'll wager 4:1 for you.  Let's make it my
$100k
to
your $25k, even though you've already set the terms and the
amount
in
writing previously.  I'm happy to amend this.

t

From: Craig S. Wright [mailto:craig.wright () Information-
Defense.com]
Sent: Tuesday, February 09, 2010 10:28 PM
To: Thor (Hammer of God); Valdis.Kletnieks () vt edu
Cc: pen-test () securityfocus com; 'full-disclosure';
security-basics () securityfocus com
Subject: RE: [Full-disclosure] SMS Banking

I will happily do this.

"That it can be hacked, or will be hacked"
Anything CAN be hacked.

Software first. Choose 100 common software products. I will
define
scale
here first. This will be number of vulnerabilities (new) that are
found
in
each piece of software each month. This will also be related to
the
common
metrics for the level of the vulnerability. This will be for 6
months.
Choose the number of vulnerabilities and the impact of each of
these
for 6
months. It has to be commonly run software with a user base that
I
cannot
count on one hand.

My predictions will be for these products and will have a
confidence
bound
set at 95% (or alpha=5%).

"I further assume that the "loser" will be financially
responsible
for
the
"audits" done my way."
Are you saying that you will pay MY fees when you lose?

"won't look at the software code"
When you can get MS to give me their code this may be an issue,
but
it
is
not as yet.

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


From: Thor (Hammer of God) [mailto:Thor () hammerofgod com]
Sent: Wednesday, 10 February 2010 3:59 PM
To: craig.wright () Information-Defense com; Valdis.Kletnieks () vt edu
Cc: pen-test () securityfocus com; 'full-disclosure';
security-basics () securityfocus com
Subject: RE: [Full-disclosure] SMS Banking

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
a
contract, and I hope you won't mind that I have my own attorney
look
it
over.    I'm not immediately trusting of the competence of one
with
a
doctorate degree and multiple masters degrees who can't spell
"technology"
or "experience" correctly on his on-line CV.

You are officially "on."  And I'm looking forward to it.

t



From: Craig S. Wright [mailto:craig.wright () Information-
Defense.com]
Sent: Tuesday, February 09, 2010 7:41 PM
To: Valdis.Kletnieks () vt edu; Thor (Hammer of God)
Cc: pen-test () securityfocus com; 'full-disclosure';
security-basics () securityfocus com
Subject: RE: [Full-disclosure] SMS Banking

I have a simple answer to this. Forget the debate, rhetoric is
not
a
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
something
real
to offer.
Regards,
...
Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
Information Defense Pty Ltd
_____________________________________________
From: Valdis.Kletnieks () vt edu [mailto:Valdis.Kletnieks () vt edu]
Sent: Wednesday, 10 February 2010 7:03 AM
To: Thor (Hammer of God)
Cc: pen-test () securityfocus com; full-disclosure;
craig.wright () Information-Defense com
Subject: Re: [Full-disclosure] SMS Banking
* PGP Signed by an unknown key
On Tue, 09 Feb 2010 17:39:39 GMT, "Thor (Hammer of God)" said:
how about accepting a challenge to an open debate on the
subject
at
Defcon?
"Alright folks just make yourself at home, Have a snow cone and
enjoy
the
show"
                                -- Webb Wilder

* Unknown Key
* 0xB4D3D7B0

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]