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 < [email protected]> 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:[email protected]] > Sent: Thursday, 11 February 2010 2:54 AM > To: [email protected]; 'full-disclosure' > Cc: [email protected]; [email protected]; > [email protected]; 'Jeff Frisk'; [email protected]; '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:[email protected]] > > Sent: Wednesday, February 10, 2010 12:22 AM > > To: Thor (Hammer of God) > > Cc: [email protected]; 'full-disclosure'; security- > > [email protected]; [email protected]; 'Jeff Frisk'; advisory- > > [email protected]; '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:[email protected]] > > Sent: Wednesday, 10 February 2010 5:42 PM > > To: [email protected]; [email protected] > > Cc: [email protected]; 'full-disclosure'; > > [email protected] > > 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:[email protected]] > > Sent: Tuesday, February 09, 2010 10:28 PM > > To: Thor (Hammer of God); [email protected] > > Cc: [email protected]; 'full-disclosure'; > > [email protected] > > 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:[email protected]] > > Sent: Wednesday, 10 February 2010 3:59 PM > > To: [email protected]; [email protected] > > Cc: [email protected]; 'full-disclosure'; > > [email protected] > > 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:[email protected]] > > Sent: Tuesday, February 09, 2010 7:41 PM > > To: [email protected]; Thor (Hammer of God) > > Cc: [email protected]; 'full-disclosure'; > > [email protected] > > 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: [email protected] [mailto:[email protected]] > > Sent: Wednesday, 10 February 2010 7:03 AM > > To: Thor (Hammer of God) > > Cc: [email protected]; full-disclosure; > > [email protected] > > 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/ >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
