Message-ID: <optid.065717d79d.A876923A2C9CD44BA76505F58ECF089D03FEE63A@gandalf.optimum.bm>
Date: Wed, 10 Feb 2010 19:39:19 +0000
From: "Thor (Hammer of God)" <Thor@...merofgod.com>
To: "craig.wright@...ormation-Defense.com"
	<craig.wright@...ormation-Defense.com>, 'full-disclosure'
	<full-disclosure@...ts.grok.org.uk>
Cc: "pen-test@...urityfocus.com" <pen-test@...urityfocus.com>,
	"security-basics@...urityfocus.com" <security-basics@...urityfocus.com>
Subject: Re: 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@...ormation-Defense.com]
> Sent: Wednesday, February 10, 2010 11:27 AM
> To: Thor (Hammer of God); 'full-disclosure'
> Cc: pen-test@...urityfocus.com; security-basics@...urityfocus.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@...merofgod.com]
> Sent: Thursday, 11 February 2010 2:54 AM
> To: craig.wright@...ormation-Defense.com; 'full-disclosure'
> Cc: pen-test@...urityfocus.com; security-basics@...urityfocus.com;
> stephen@...s.edu; 'Jeff Frisk'; advisory-board-open@...ts.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@...ormation-Defense.com]
> > Sent: Wednesday, February 10, 2010 12:22 AM
> > To: Thor (Hammer of God)
> > Cc: pen-test@...urityfocus.com; 'full-disclosure'; security-
> > basics@...urityfocus.com; stephen@...s.edu; 'Jeff Frisk'; advisory-
> > board-open@...ts.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@...merofgod.com]
> > Sent: Wednesday, 10 February 2010 5:42 PM
> > To: craig.wright@...ormation-Defense.com; Valdis.Kletnieks@...edu
> > Cc: pen-test@...urityfocus.com; 'full-disclosure';
> > security-basics@...urityfocus.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@...ormation-Defense.com]
> > Sent: Tuesday, February 09, 2010 10:28 PM
> > To: Thor (Hammer of God); Valdis.Kletnieks@...edu
> > Cc: pen-test@...urityfocus.com; 'full-disclosure';
> > security-basics@...urityfocus.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@...merofgod.com]
> > Sent: Wednesday, 10 February 2010 3:59 PM
> > To: craig.wright@...ormation-Defense.com; Valdis.Kletnieks@...edu
> > Cc: pen-test@...urityfocus.com; 'full-disclosure';
> > security-basics@...urityfocus.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@...ormation-Defense.com]
> > Sent: Tuesday, February 09, 2010 7:41 PM
> > To: Valdis.Kletnieks@...edu; Thor (Hammer of God)
> > Cc: pen-test@...urityfocus.com; 'full-disclosure';
> > security-basics@...urityfocus.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@...edu [mailto:Valdis.Kletnieks@...edu]
> > Sent: Wednesday, 10 February 2010 7:03 AM
> > To: Thor (Hammer of God)
> > Cc: pen-test@...urityfocus.com; full-disclosure;
> > craig.wright@...ormation-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/

Powered by blists - more mailing lists