Lynn was there at the beginning of SSL, and sees where I'm going with this. He writes in Comments:
> I have a similar jaundiced view of a lot of the threat model stuff in the mid-late 90s ... Lots of parties had the solution (PKI) and they were using the facade of threat models to narrowly focus in portion of problem needing PKI as solution (they had the answer, now they needed to find the question). The industry was floating business plans on wall street $20B/annum for annual $100 digital certificates for individuals. We had been called in to help wordsmith the cal. state electronic signature legislation ... and the industry was heavily lobbying that the legislation mandate (annual, individual) digital certificates.
Etc, etc. Yes. this is the thing that offends - there is a flaw in pure threat modelling, and that flaw was enough to drive an industry through. We're still paying the dead-weight costs, and will be for some time.
The question is whether the flaw in threat modelling can be repaired by patches like "oh, you should consider the business" or whether we need to recognise that nobody ever does. Or can. Or gets paid to.
In which case we need a change in metaphor. A new paradigm, as they say in the industry.
I'm thinking the latter. Hence, Risk Analysis.
Over on New School, my threat-modelling-is-for-birds rant last month went down like a lead balloon.
Now, I'm gonna take the rap for this one. I was so happy to have finally found the nexus between threat modelling and security failure that has been bugging me for a decade, that I thought everyone else would get it in a blog post. No such luck, schmuck. Have another go!
Closest pin to the donkey tail went to David, who said:
Threat modeling is yet another input into an over all risk analysis.
Right. And that's the point. Threat modelling by itself is incomplete. What's the missing bit? The business. Look at this gfx, risk'd off some site. This is the emerging 31000 risk management typology (?) in slightly cut down form.
The business is the 'context' as shown by the red arrow. When you get into "the biz" you discover it's a place of its own, a life, a space, an entire world. More pointedly, the biz provides you with (a) the requirements and (b) a list of validated threats. E.g., history, as we already deal with them.
The biz provides the foundation and context for all we do - we protect the business, without which we have no business meddling.
(Modelling distraction: As with the graphic, the source of requirements is often painted at the top of the diagram, and requirements-driven architecture is typically called top-down. Alternatively and depending on your contextual model, we can draw it as a structural model: our art or science can sit on top of the business. We are not lifting ourselves up by our bootstraps; we are lifting the business to greater capabilities and margins. So it may be rational and accurate to call the business a bottom-up input.)
Either way, business is a mess, and one we can't avoid. We have to dive in and absorb, and in our art we filter out the essence of the problem from the business into a language we call 'requirements'.
Then, the "old model" of threat modelling is somewhere in that middle box. For sake of this post, turn the word risk into threat. Follow the blue arrow, it's somewhere in there.
The point then of threat modelling is that it is precisely the opposite of expected: it's perfect. In more particular words, it lives without a context. Threat modelling proceeds happily without requirements that are grounded in a business problem or a customer base, without a connection to the real world.
Threat modelling is perfect by definition, which we achieve by cutting the scope off at the knees.
Bring in the business and we get real messy. Human, tragic. And out of the primordial swamp of our neighbors crawls the living, breathing, propogating requirements that make a real demand on us - survival, economy, sex, war, whatever it is that real people ask us for.
Adam talks about Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege... which sounds perfect. And I'd love to play the game :)
But real life is these things: insider trading, teenager versus teenager versus parent versus parent, revolutions of colour, DVD sharing, hiding in plain sight, movement tracking of jealous loved ones, don't ask, don't tell, whistleblowing, revenge,...
Which philosophy of business context first and foremost also explains a lot of other things. Just by way of one example, it gives an essential clue as to why only end-to-end security is worth anything. Application security automatically has a better chance of including the business; point-to-point designs like IPSec, SSL, DNSSec, etc have no chance. They've already handwaved anything past the relevant nodes into utter obscurity.
In what is a development redolent with history, Paypal have developed a way to turn your phone into a credit card register:
Much like Square, PayPal Here will have a card reader that plugs into your mobile phone via the headset jack on your handset. While Square's reader comes in the form of a white square device, PayPal's will instead be a blue triangle. The encrypted reader will be available for free to small business owners and can be used to accept credit card payments. ... While the PayPal Here app is designed to be used hand in hand with the card reader, the app can also be used to accept checks, keep track of cash transactions, and accept credit card transactions in situations where you might not have your card reader present.Credit card and check transactions can be accepted by capturing a photo of the check or card in question, and customers select a tip amount and sign for the transaction directly on the phone's screen.
Much of the post correctly points out that Paypal are playing catchup against Square which does the same thing.
What older readers will find amusing is the sense of deja vu - Paypal was originally an application on a Palmtop. And the use of sound to transmit the credit card information to the phone is also quite evocative of the old days of phone-coupling models.