So, looks like SANS has dumped you Craig. Anyone else you want to get to set the system up for you?
t > -----Original Message----- > From: Stephen Northcutt [mailto:[email protected]] > Sent: Wednesday, February 10, 2010 10:56 AM > To: [email protected]; Thor (Hammer of God) > Subject: RE: [Full-disclosure] SMS Banking > > Sorry, I do not have time for this, please do not let this spill over > into > our advisory board list either. > > Stephen Northcutt, President > The SANS Technology Institute (www.sans.edu) > 808.823.1375 > > Register today! Over 30 infosec courses at SANS 2010 - March 6-15, > Orlando > FL http://www.sans.org/info/51269 > > "This is the way you need to learn: roll up your sleeves, dig in to the > fundamentals and the nitty-gritty technical details, and then go > 'hands-on' > to practice and reinforce what you've been taught." - Joseph Price, DoD > > > -----Original Message----- > From: Craig S. Wright [mailto:[email protected]] > Sent: Wednesday, February 10, 2010 1:54 PM > To: 'Thor (Hammer of God)'; 'full-disclosure' > Cc: [email protected]; [email protected]; > [email protected]; 'Jeff Frisk'; 'Ben Wright' > Subject: RE: [Full-disclosure] SMS Banking > > " You are changing the bet in mid-stream " > Not at all. This was and is the bet. The initially proposed 2 tasks > remain > unchanged. > > The statement on SMS was that this is a time degrading risk function. > That > is, the proposed SMS solution would become less secure over time. The > longer > it ran, the more attacks. It would also be a function of users, the > more > users, the less secure. In case you cannot understand what the SMS > quote you > have means, it simply means that adding an independent 2nd factor > lowers the > inherently high risk of a purely SMS based system. > > "The risk of deploying any given solution takes into account FAR too > many > real-world elements than any formula can address. " > The SMS formula is not the be all - it was a simple extrapolation based > on a > highly insecure proposal. My model as I have put it is an expert > system. The > risk associated with each application on a system is derived as with > dependence and path. > > Please as stated, choose the 100 software applications. > > 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/
