Date: Wed, 10 Feb 2010 19:47:30 +0000
From: Benji <me@...ji.com>
To: craig.wright@...ormation-defense.com
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>,
	pen-test@...urityfocus.com, security-basics@...urityfocus.com,
	"Thor \(Hammer of God\)" <Thor@...merofgod.com>
Subject: Re: SMS Banking

Sorry to butt in, but may I also have a contract to be the agent for the
tickets for this comedy show?

Thanks

BenjiManagementCo - Sending Your (Security) Theatre GLOBAL

On Wed, Feb 10, 2010 at 7:27 PM, Craig S. Wright <
craig.wright@...ormation-defense.com> wrote:

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

Content of type "text/html" skipped

_______________________________________________
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