Things I've seen that are encouraging. Bruce Schneier in Q&A: Q: We've also seen Secure Sockets Layer (SSL) come under attack, and some experts are saying it is useless. Do you agree? A: I'm not convinced that SSL has a problem. After all, you don't have to use it. If I log-on to Amazon without SSL the company will still take my money. The problem SSL solves is the man-in-the-middle attack with someone eavesdropping on the line. But I'm not convinced that's the most serious problem. If someone wants your financial data they'll hack the server holding it, rather than deal with SSL. Right. The essence is that SSL solves the "easy" part of the problem, and leaves open the biggest part. Before the proponents of SSL say, "not our problem," remember that AADS did solve it, as did SOX and a whole bunch of other things. It's called end-to-end, and is well known as being the only worthwhile security. Indeed, I'd say it was simply responsible engineering, except for the fact that it isn't widely practiced. OK, so this is old news, from around March, but it is worth declaring sanity: Q: But doesn't SSL give consumers confidence to shop online, and thus spur e-commerce? A: Well up to a point, but if you wanted to give consumers confidence you could just put a big red button on the site saying 'You're safe'. SSL doesn't matter. It's all in the database. We've got the threat the wrong way round. It's not someone eavesdropping on Eve that's the problem, it's someone hacking Eve's endpoint. Which is to say, if you are going to do anything to fix the problem, you have to look at the end-points. The only time you should look at the protocol, and the certificates, is how well they are protecting the end-points. Meanwhile, the SSL field continues to be one for security researchers to make headlines over. It's BlackHat time again: "The point is that SSL just doesn't do what people think it does," says Hansen, an security researcher with SecTheory who often goes by the name RSnake. Hansen split his dumptruck of Web-browsing bugs into three categories of severity: About half are low-level threats, 10 or so are medium, and two are critical. One example... Many observers in the security world have known this for a while, and everyone else has felt increasingly frustrated and despondent about the promise: There has been speculation that an organization with sufficient power would be able to get a valid certificate from one of the 170+ certificate authorities (CAs) that are installed by default in the typical browser and could then avoid this alert .... But how many CAs does the average Internet user actually need? Fourteen! Let me explain. For the past two weeks I have been using Firefox on Windows with a reduced set of CAs. I disabled ALL of them in the browser and re-enabled them one by one as necessary during my normal usage.... On the one hand, SSL is the brand of security. On the other hand, it isn't the delivery of security; it simply isn't deployed in secure browsing to provide the user security that was advertised: you are on the site you think you are on. Only as we moved from a benign world to a fraud world, around 2003-2005, this has this been shown to matter. Bruce goes on: Q: So is encryption the wrong approach to take? A: This kind of issue isn't an authentication problem, it's a data problem. People are recognising this now, and seeing that encryption may not be the answer. We took a World War II mindset to the internet and it doesn't work that well. We thought encryption would be the answer, but it wasn't. It doesn't solve the problem of someone looking over your shoulder to steal your data. Indeed. Note that comment about the World War II mindset. It is the case that the entire 1990s generation of security engineers were taught from the military text book. The military assumes its nodes -- its soldiers, its computers -- are safe. And, it so happens, that when armies fight armies, they do real-life active MITMs against each other to gain local advantage. There are cases of this happening, and oddly enough, they'll even do it to civilians if they think they can (ask Greenpeace). And the economics is sane, sensible stuff, if we bothered to think about it: in war, the wire is the threat, the nodes are safe. However, adopting "the wire" as the weakness and Mallory as the Man-In-The-Middle, and Eve as the Eavesdropper as "the threat" in the Internet was a mistake. Even in the early 1990s, we knew that the node was the problem. Firstly, ever since the PC, nodes in commercial computing are controlled by (dumb) users not professional (soldiers). Who download shit from the net, not operate trusted military assets. Secondly, observation of known threats told us where the problems lay: floppy viruses were very popular, and phone-line attacks were about spoofing and gaining entry to an end-point. Nobody was bothering with "the wire," nobody was talking about snooping and spying and listening [*]. The military model was the precise reverse of the Internet's reality. To conclude. There is no doubt about this in security circles: the SSL threat model was all wrong, and consequently the product was deployed badly. Where the doubt lies is how long it will take the software providers to realise that their world is upside down? It can probably only happen when everyone with credibility stands up and says it is so. For this, the posts shown here are very welcome. Let's hear more!...

Seen on the net, by Dan Geer: The design goal for any security system is that the number of failures is small but non-zero, i.e., N0. If the number of failures is zero, there is no way to disambiguate good luck from spending too much. Calibration requires differing outcomes. Ive been trying for years to figure out a nice way to describe the difference between 0 failures, and some small number N0 like 1 or 2 or 10 in a population of a million. Dan might have said it above: If the number of failures is zero, there is no way to disambiguate good luck from spending too much. Has he nailed it? Its certainly a lot tighter than my long efforts ... Once we get that key piece of information down, we can move on. As he does: Regulatory compliance, on the other hand, stipulates N==0 failures and is thus neither calibratable nor cost effective. Whether the cure is worse than the disease is an exercise for the reader. An insight! For regulatory compliance, Id substitute public compliance, which includes all the media attention and reputation attacks....

And, only because I wrote it in the same thread as Zookos post, here is a retrospective on how the 1990s payments startup guys saw life, as compared to the 2000s p2p generation. On 18/06/10 12:27 PM, Serguei Osokine wrote: In fact, I thought that this was exactly the hint that Zooko was dropping with his question about MN history. Was kind of surprised to read all the serious history descriptions that followed - though enjoyed them anyway... :) :) Maybe to add to your surprise, there was a serious history! Perhaps a little more background will help. In the late 1980s, a guy called David Chaum invented a cryptographic form of cash which he called digital cash. His invention was a variation of the RSA formula that allowed a transfer of something from one person to another, that a third party could prove as valid, but not track the transfer. This allowed the third party to be an issuer of value, and users to transfer coins without being traced....

Editors note: Zooko writes in p2p-hackers forum, and editor gladly copies: That there is also a new generation of interesting payment systems including The Love Machine and Flattr. I think Flattr is very interesting. Founded by founders of The Pirate Bay, they do several things that are very promising: 1. The marginal cost to you of clicking on someones flattr me button is zero. This is due to the scheme of subscribing to Flattr.com with a monthly fee and then at the end of the month your money gets split among everyone whom your clicked on. This is the most promising solution to the problem of mental transaction costs. 2. The pitch is that this is a way to express love to people. #9829; $ 3. Look: content! It is very easy to find things to love on the flattr.com web site. This has a lot in common with the tipping feature that we advertised as a future feature of Mojo Nation (e.g. it features prominently in the write-up of Mojo Nation in The Economist). (Inside Evil Geniuses For A Better Tomorrow we called that feature the Pay Lars button, in honor of a certain musician who had publicly criticized Napster for depriving him of well-earned income.) From a historical perspective Flattr is a fascinating example of the evolution of ideas. The founders of The Pirate Bay are probably intimately familiar with BitTorrent, but as far as I know, they are unfamiliar with anonymous Chaumian digital cash. I wouldnt be surprised if they got the idea for Flattr from their experience with BitTorrent and basically observing that there was a hole in BitTorrent where micropayments could go. :-) Does anyone know the inside story on how they got the idea for Flattr? Regards, Zooko...

Back in 1997 I wrote about task markets, where people would propose an idea, collect funds, and when 100% was reached, the contract would be made. Now Kickstarter is more or less doing it. Heres one of their contracts: A year ago, I began writing poems to strangers on the internet. I would keep a specific person in mind: a blogger, a penpal, a sort-of-lover. Then Id set a timer for 5 minutes and let the thoughts pour out, unfiltered. The 5 Minute Poems were sent through email, published immediately on my blog or written in Gchat. They were slices of mind. Internet Intimacy. Poetry as communication. Some of the people I corresponded with were also living in New York City, but some of them were in Texas, Paris, Melbourne, London. The poems filled the hours at the height of insomnia when my head was stuck in strange frequencies. The year-long experiment amassed enough poems to fill a chapbook. Instead of traditional publishing methods, I want to do something more organic. I want to get the book into the hands of the readers, friends and strangers who inspired it. I am using Kickstarter to raise the funds needed to self-publish the book and get it the hands of the people who want to read it. Now, when I did it, I also built the software and tested it out. The reason I stopped was because of the money. It wasnt that I didnt have enough, but the money -- whichever money one had -- wasnt efficient enough. Transactions cost too much money, and innovative ideas like this used several transactions ... and often had to be unwound. People dont like losing money that way. So several of these ideas popped up and faded away (it seems). My guess is that the payments ate away at them like a cancer. Consider using credit card, and hitting the CC 6 months after the transaction... whos picking up the cost of mistakes there? This site however solves the problem by just collecting pledges. So it is entirely a credit operation. When is my credit card charged? If this project is fully funded on August 11, 01:00am EDT your credit card will be charged along with all the other backers of this project. So my card is only charged if funding succeeds? Yes! Thats part of what makes Kickstarter special. If a project isnt fully funded, no one pays anything. And therefore likely works by assuming that pledges can disappear at the end of the day, but as long as a good percentage come through, the margins can make the rest work. Our fee is 5%. Kickstarter collects 5% from the project creator if a project is successfully funded. Why has it taken so long? Well, the money system is so damn inefficient over the net that everything else has to be very good. If we had efficient monies, wed have done this 10 years ago, and another 1000 ideas as well. Big question then is, why is the money so damn inefficient? Well, you know the answer to that already, otherwise you wouldnt be here :)...

One for the gold crowd: Today one of 5 massive 100kg gold coins goes under the hammer in Vienna: The largest gold coin in the world — measuring 53 centimetres (21 inches) in diameter and weighing 100 kilograms (220 pounds) — will go on sale on June 25 in Vienna, auction house Dorotheum said on Friday. The Maple Leaf coin, which is listed in the Guinness Book of World Records and carries a face value of one million Canadian dollars (800,000 euros, 970,000 dollars), was minted in Canada in 2007. The auction price is expected to comfortably exceed the face value due to the current high price of gold. If mettled down, the gold would be worth around 3.9 million dollars (3.2 million euros). One side of the coin carries the carries the image of Queen Elizabeth II, the official head of state of Canada, while the other side bears three maple leafs, the national symbol. The coin was owned by Austrian investment firm AvW, which entered bankruptcy proceedings in May....

Last year, a spate of attacks on AES caused the shine to come off. Vincent Rijmen, one of the designers, has now announced an attack on AES that reduces the key strength from 128 bits to 32 bits. Ouch! But theres a catch: This attack clearly endangers all practical applications where an attacker can halt the computer in the middle of the execution of an encryption routine , apply the specific difference #948; to the state, and roll back the interrupted encryption and obtain the modified plaintext p*. Which is to say, the attacker must have something else. He must be able to stop the encryption, inject some different values, and then restart it. Is this a worry? Well, no. If the attacker has that ability -- stop, inject, restart -- then the attacker probably has lots of other powers too. Yes, in that the result seems to again undermine the strength of the algorithm. As they say in cryptoland, the attacks only get better. In sum, I wouldnt be too worried. If this attack breaks you, then youve got another problem: cant be too careful about those environmental factors! But we might start to think about the replacement of AES somewhat sooner than expected (e.g., last year, Bruce Schneier suggested simply increasing the rounds of AES128 from 10 to 16) and whether we need to incorporate specific environmental defences in the next design competition. As more information comes in, especially analysis by real cryptographers rather than cryptography realists, Ill update the post. Hat tip to Alfonso De Gregorio who spotted it and added his own variant....

Somebody asked me how I do Architecture, and it wasn't a question I could easily answer. Darn! I am one, but what is one, and how do I do it? Since then, I've been doing a bit of reading, and I think I have the answer. Here it is, by way of an anecdote called Rafi's, which was a project, and also a ribs & beer place. Crack open a beer, order in some ribs, and settle in. In 2000 or thereabouts, my team and I were sitting on the most sophisticated and working Internet payments system around. Having got it in place, we were then faced with the problem that bedevilled most all payment systems: people don't do payments, so much as, they do trade. This was a conundrum, one I wrote about in FC7, in where I claim that a financial cryptography system without a "financial application" is approximately worthless. Some slight context. To answer the obvious question here, we already had our application, being the swapping of financial instruments for cash, and back again. Good as it was, I was looking for more. A wider complication is that many obvious applications have beartraps in them lurking for unwitting payment systems, so there wasn't an easy answer such as copy amazon or google or expedia or Rafi's ribs place. And, finally, luckily, no customer was demanding this, it was an internally-generated strategic demand, so I could take my time. In trying to do more payments, then, the problem evolved into figuring out what trade people did, and trying to participate in more of that. In order to get a grounding in that, I surveyed how payments integrated into life. Initially, I thought about invoice cycles, because a payment is generated out of such a cycle. This seemed fairly tractable, but I wasn't comfortable with the variations. I went wider, and thought about trading of all form, the wider business exchange that goes on that generates an invoice cycle, and finally a payment. In principle, as we'd already done financial trades, and it was simply a matter of substituting finance with some other business, walking the transaction, architecting it and implementing it. Or so I initially thought, but it wasn't to be. Take a hotel check-in, an example I sometimes used to convince people *not* to get into the retail payments business. When you finally get to the hotel, and walk in the door, you start the process, something like this: "I'm after a room…" "We have singles, doubles, and the presidential suite …" How much is the double? "100 per night" OK, I'd like three nights. "We only have doubles available for 2 nights, but we have the singles." OK, and do you have a room at the back, not facing the highway? "Ah, yes you'll be wanting the presidential suite then…" And on and on it goes. The point is that, while invoicing cycles include some variability, trade cycles are all variability, to the point of arbitrary, unpredictable chaos. Examining such a process and trying to automate it presents rather special challenges. It is somewhat clear that we can create an ontology to capture all the probable paths of the hotel reception cycle. And indeed, this is what many projects tried to do: define the process, automate the use-cases. Consider flight booking systems. It's also possible to define an exceptions protocol, to catch those tricky "backside room," special meal requests or the more prosaic desire for a welcoming Carib. But it's hard. And risky, as having built it, how do we know the customers will agree with the ontology? Building such things only makes sense if they work, guaranteed, and that's unlikely in this case. But the real killer is that having done all that, ones grand structure is almost useless for the next business problem. That is, a flight booking system won't translate so easily to a hotel process, even though we want to offer both of them together (and many do). And it certainly doesn't have much relationship to a book drop-shipping business. Unless, that is, one believes that there is all-powerful super-meta-hyper methodology that can capture all interactions between all humans. An AP-SMH-UML, if you like, or perhaps the über-SAP. If you believe in that, just let me know how many decades you'll finance the building of it, and I'm willing to take your money :) if I can get to the head of the queue... In the alternate, it is possible to understand the essence of trade, approximate, and find some benefits. And this is where my months of thinking started to pay out some small glimmers of inspiration. The first thing I realised is that, a payment is but a tiny part. A bigger part is the invoicing process, which often involves a bill being delivered, checked, paid for, and confirmed. On both sides. This is an application in and of itself, it is probably 5 times bigger than a payment. And we still haven't given it any semantics, any meaning for the end-user. Intuitively, we have to deliver meaning in order to make it reach a customer (or, academically, recall the FC7 hypothesis above). But as soon as I tried to add some sort of semantics around the invoicing, I ended up with the killer issue above: a mess of interactions of no real structure surrounding an already challenging invoicing protocol, with a payment or three tacked on. What started out as simple modelling revealed an intractable mess, which by size dominated the original mission. My finger-in-the-air estimate is this: 1% payment, 4% invoice, 95% the messages of chaos. Logic therefore said to me that I if I could improve the 95% and reduce the chaos as it were, then this would likely dominate any efforts to improve the 4%, at a ratio of around 20 to 1! And, following this logic, the payment was now almost optional, almost vestigial. The less I thought about payments, the better. My next glimmer was to treat trade as a series of requests and responses, back and forth. But, that didn't quite work out because many of the so-called requests were unanticipated, and unresponded. Think of advertising's part in trade, and the request-response model is dead, which may explain why so many billing systems layered over HTTP look so ghoulish. So eventually I was led to treating interaction as a somewhat arbitrary series of messages, showing patterns of no particular import to us. The inspiration was then to flip the architecture system around: trade is messages, and to improve trade, improve the messaging capability. I didn't want semantics, I wanted freedom from semantics. I wanted a messaging system, with payments tacked on, rather than a payments system based on messaging. Indeed, I wanted a messaging system that could support arbitrary messages, and payments were just a trivial example of a message, within the full set of possible messages. (Trivial, because we already had them, and trivial, to focus the mind on the full possible set. Not trivial just from being payments, as these are anything but trivial.) So the mission became to convert our payments-system-built-over-messaging into a messaging-system-with-payments. It seemed elegant enough, so over several nights at Rafi's, over ribs and beer, I outlined the story for my team: we want more transactions, payments business derives from trade … trade is really messages, with a payment tacked on, we have a payment system, built on great messaging principles, we just need to switch the emphasis of our system architecture a little, to:messaging-with-payments, not payments-over-messaging. That's how Project Rafi's was born. I sold it to my team through beer & ribs, toasted the name, and commissioned a demo. Of course, when people talk of messaging as an application, they think chat or Instant Messaging or SMS. So I seized that metaphor, and turned it into the popular expression of the mission. We were adding IM to our payment system, or so we said. Which was a subtly different subset to what I wanted, but close enough to be easy to sell, easy to discuss, and easy to tune in the detailed requirements and later implementation. Sounds simple! Let's look back to the meat on the ribs of the original question: how did I do the architectural part? Looking at the above, the serial or static view is like this: define the business problem that I am trying to solve research the business context extract requirements build a virtual or model solution using some random classical technique or tools to hand But this assumes too much omniscience, reality is far rougher, full of errors, omissions, unknowns. So, we need an error-correcting overlay, a feedback cycle. The dynamic view is then cyclical: e. at each step, I test my results & conclusions against the earlier parts. E.g., test the solution against the requirements .. then test against the known business variations … then similar business problems … then the business statement. e-bis. something breaks. f. Out of which breach, identify the broken part (solution, requirements, research, problem). f-bis. Jump back to a,b,c or d, depending. Evolve and re-state the broken input. g. keep doing it until elegance strikes me on the forehead and I can't shake it off! Now, this might be special, but it's not unique, Indeed, you can find this on the net if you look around. Here's one from Malan and Bredemeyer: A 9 word summary might be set the mission, start high, go deeper, test, iterate. Or, if you want the 1 word secret, it is Iterate! Those with a sense of military history will see Boyd's OODA loop in there, with the problem being the enemy, the enemy being the problem, and the challenge to spin faster than the problem spins you :) And those with appetite will appreciate now why there are always so many ribs on the plate, and why architecture and fast food don't go well together. What might offend some people is that it is so simple. I think the response to simplicity is that this easy model hides a lot, but that which it hides is not the essence of Architecture. Rather, the hidden part is the essence of something else, which the Architect is able to successfully integrate without spoiling the secret. And as this post is about Architecture, and is already long enough, I'll stop right there. THEthe secretthe secret of software                        the secret of software architecture the secret of software architecture is . . . i t e r a t i o n ! Hence that age-old complaint of the frustrated architect, "there aren't enough ribs on my plate!"...

Gunnar posts on the continuing sad saga of infosec: Theres been a lot of threads recently about infosec certification, education and training. I believe in training for infosec, I have trained several thousand people myself. Greater knowledge, professionalism and skills definitely help, but are not enough by themselves. We saw in the case of the Great Recession and in Enron where the skilled, certified accounting and rating professions totally sold out and blessed bogus accounting practices and non-existent earning. Right. And this is an area where the predictions of economics are spot on. In Akerlofs seminal paper the Market for Lemons, he predicts that the asymmetry of information can be helped by institutions. In the economics sense, institutions are non-trading, non-2-party market contractual arrangements of long standing to get stuff happening. Professionalism, training, certifications, etc all are slap-bang in the recommendations. So why dont they help? Theres a simple answer: we arent in the market for lemons! Theres one key flaw: Lemons postulates that the seller knows and the buyer doesnt, and that simply doesnt apply to infosec. (Criteria #1) In the market for security, the seller knows about his tool, but he doesnt know whether it is fit for the buyer. In contrast, the salesman in Akerlofs market assumed correctly that a car was good for the buyer, so the problem really was sharing the secret information from the seller to the buyer. Used car warranties did that, by forcing the seller to reveal his real pricing. The buyer doesnt really know what he wants, and the seller has no better clue. Indeed, it may be that the buyer has more of a clue, and at least sometimes. So professionalism, certification, training and warranties isnt going to be the answer. Another way of looking at this is that in infosec, in common with all security markets (think defence, crime) there is a third party: the attacker. This is the party that really knows, so knowledge-based solutions without clear incorporation of the aggressors knowledge arent going to work. This is why buying the next generation stealth fighter is not really helpful when your attacker is a freedom fighter in an Asian hell-hole with an IED. But its a lot more exciting to talk about. Which leads me to one controversial claim. If we cant get useful information from the seller, then the answer is, youve got to find it by yourself. Its your job, do it. And thats really what we mean by professionalism -- knowing when you can outsource something, and knowing when you cant. Thats controversial because legions of infosec product suppliers will think theyre out of a job, but thats not quite true. It just requires a shift in thinking, and a willingness to think about the buyers welfare, not just his wallet. How do we improve the ability of the client to do their job? Which leads right back to education: it is possible to teach better security practices. Its also possible to teach better risk practices. And, it can be done on an organisation-wide basis. Indeed, this is one of the processes that Microsoft took in trying to escape their security nightmare: get rid of the security architecture silos and turn the security groups into education groups [1]. So from this claim, why the flip into a conundrum. Why arent certifications the answer? Its because certifications /are an institution/ and institutions are captured by one party or another. Usually, the sellers. Again a well-known prediction from economics: institutions to protect the buyer are generally captured by the seller in time (if not in the creation). I think this was by Stiglitz or Stigler (?), pointing to finance market regulation, again. A supplier of certifications needs friends in industry, which means they need to also sell the product of industry. Its hard to make friends selling contrarian advice, it is far more profitable selling middle-of-the-road advice about your partners [2]. Lets start with SSL + firewalls ... Nobodys going to say boo, just pass go, just collect the fees. In contrast: In short, the biggest problem in infosec is integration. Education around security engineering for integration would be most welcome. Thats tough, from an institutional point of view....

Nelson spotted it, too late for yesterdays post of old predictions come true: Symantec Corp. is paying $1.28 billion in cash to buy a division of VeriSign Inc. that sells security technology to websites. The deal, announced Wednesday, represents VeriSigns most aggressive move yet to slim down and concentrate on its core business: managing traffic to websites with addresses ending in .com and .net, and collecting fees for registering those domain names. VeriSign has been purging divisions for the past three years, after realizing it was spread too thin following a buying binge designed to insulate it from the kinds of problems it had after the dot-com collapse a decade ago. Prior to Wednesdays deal with Symantec, VeriSign had sold more than a dozen businesses since 2007 for a total of nearly $1 billion. What Symantec gets out of the deal is one of the Webs best-known brand names for security. Back in 2005 (!) I predicted this would happen, because of complexity and the fear of litigation arising out of the phishing threat. The too-many-business-lines aspect is there in the above article. As it happened, the litigation has not emerged as yet, although if the Australian Bank Fees case pans out positively (for the fee payers not the payees), there might be more enthusiasm. Where does this leave the market for CAs? Well, Symantec probably has a very different outlook and approach. But its also a complex company in its own right, so the problem of complexity will need to be fixed there as well. And, it has another very close buyout of recent times: PGP Inc. Yes, the company famous for its version of OpenPGP, which is perhaps the bright shining light opposing the CA business, has been sold to Symantec for some $300bn. Leading light Jon Callas then left the company and went to Apple, which is an interesting move in a buyout phase. Meanwhile, I saw a recent comment that PGP Inc also has PKI and CA business, which makes me wonder. Is this true? If so, Symantec will have even more work to do rationalising of lines. Others muse on these issues too: One strength of PGP is its server-side encryption and security offerings, which compete with products from vendors such as nuBridges, Voltage, Vormetrics and RSA with its BSafe toolkit. Demand is growing for server-side encryption because of the Payment Card Industry data security requirements, Pescatore says. Symantec says PGP counts 100,000 enterprise customers with more than 1,000 employees, and 1 million small-to-midsized customers with fewer than 1,000 employees. For its part, Symantec says it sees PGP and its public-key encryption technology as its ticket to innovations making use of key management. Symantec is a market leader in the data loss prevention (DLP) product arena, and for complete use of DLP, encryption is an important part, Symantec CEO Enrique Salem told financial-industry analysts earlier this morning on a conference call to announce the acquisitions. The PGP platform for key-management will contribute to Symantecs focus on creating a policy-based approach in security, Salem said. In addition, a start-up acquired by PGP, called ChosenSecurity, offers another path into identity management related to establishing trust among users and sites, he noted. We will standardize on the PGP key-management platform, says Francis deSouza, senior vice president, Enterprise Strategy group, Symantec. (For what it is worth, I am strongly related to CAcert these days, which is an open community supplier of x.509 signatures and OpenPGP signatures, you should think about conflicts of interest in the above post.)...

Some things Ive seen that match predictions from a long time back, just werent exciting enough to merit an entire blog post, but were sufficient to blow the trumpet in orchestra: Chris Skinner of The Finanser puts in his old post written in 1997, which says that retailers (Tesco and Sainsburys) would make fine banks, and were angling for it. Yet: Thirteen years later, we talk about Tesco and Virgin breaking into UK banking again. A note of caution: after thirteen years, these names have not made a dent on these markets. Will they in the next thirteen years? Answer: in 1997, none of these brands stood a cat in hell’s chance of getting a banking licence. Today, Virgin and Tesco have banking licences. Exactly. As my 1996 paper on electronic money in Europe also made somewhat clear, the regulatory approach of the times was captured by the banks, for the banks, of the banks. The intention of the 1994 directive was to stop new entrants in payments, and it did that quite well. So much so that they got walloped by the inevitable (and predicted) takeover by foreign entrants such as Paypal. However regulators in the European Commission working groups(s) seemed not to like the result. They tried again in 2000 to open up the market, but again didnt quite realise what a barrier was, and didnt spot the clauses slipped in that killed the market. However, in 2008 they got it more right with the latest eMoney directive, which actually has a snowballs chance in hell. Banking regulations and the PSD (Payment Services Directive) also opened things up a lot, which explains why Virgin and Tesco today have their licence. One more iteration and this might make the sector competitive... Then, over on the Economist, an article on task markets Over the past few years a host of fast-growing firms such as Elance, oDesk and LiveOps have begun to take advantage of “the cloud”—tech-speak for the combination of ubiquitous fast internet connections and cheap, plentiful web-based computing power—to deliver sophisticated software that makes it easier to monitor and manage remote workers. Maynard Webb, the boss of LiveOps, which runs virtual call centres with an army of over 20,000 home workers in America, says the company’s revenue exceeded $125m in 2009. He is confidently expecting a sixth year of double-digit growth this year. Although numerous online exchanges still act primarily as brokers between employers in rich countries and workers in poorer ones, the number of rich-world freelancers is growing. Gary Swart, the boss of oDesk, says the number of freelancers registered with the firm in America has risen from 28,000 at the end of 2008 to 247,000 at the end of April. Back in 1997, I wrote about how to do task markets, and I built a system to do it as well. The system worked fine, but it lacked a couple of key external elements, so I didnt pursue it. Quite a few companies popped up over the next decade, in successive waves, and hit the same barriers. Those elements are partly in place these days (but still partly not) so it is unsurprising that companies are getting better at it. And, over on this blog by Eric Rescorla, he argues against rekeying in a cryptographically secure protocol: Its IETF time again and recently Ive reviewed a bunch of drafts concerned with cryptographic rekeying. In my opinion, rekeying is massively overrated, but apparently Ive never bothered to comprehensively address the usual arguments. Which I wholly concur with, as Ive fought about all sorts of agility before (See H1 and H3). Rekeying is yet another sign of a designer gone mad, on par with mumbling to the moon and washing imaginary spots from hands. The basic argument here is that rekeying is trying to maintain a clean record of security in a connection; yet this is impossible because there will always be other reasons why the thing fails. Therefore, the application must enjoy the privileges of restarting from scratch, regardless. And, rekeying can be done then, without a problem. QED. What is sad about this argument is that once you understand the architectural issues, it has far too many knock-on effects, ones that might even put you out of a job, so it isnt a *popular argument* amongst security designers. Oh well. But it is good to see some challenging of the false gods.... An article Why Hawks Win, examines national security, or what passes for military and geopolitical debate in Washington DC. In fact, when we constructed a list of the biases uncovered in 40 years of psychological research, we were startled by what we found: All the biases in our list favor hawks. These psychological impulses -- only a few of which we discuss here -- incline national leaders to exaggerate the evil intentions of adversaries, to misjudge how adversaries perceive them, to be overly sanguine when hostilities start, and overly reluctant to make necessary concessions in negotiations. In short, these biases have the effect of making wars more likely to begin and more difficult to end. Its not talking about information security, but the analysis seems to resonate. In short, it establishes a strong claim that in a market where there is insufficient information (c.f., the market for silver bullets), we will tend to fall to a FUD campaign. Our psychological biases will carry us in that direction....

Well.... as frequent readers know, I collect data on how much it costs to purchase a set of Identity documents. I do this so that we know what the rough barrier to totally breaching the so-called Identity Requirement costs. So that we can feed that number into our construction of security models, and not get caught out. In short, my research suggests strongly that the cost is about a thousand, in any of the major currencies. Some reader in that business has just fed a comment into a post, advertising exactly that. My first thought was to remove it, as I dont like spam and adverts on the site ... but it is precisely on topic! In the spirit of research and data collection, I went to the site (which is at fake passports dot eu) and it has these prices, in Euros:...

Daniel wrote in comments a month or so back about the need to put the CAs brand on the chrome, so all can see who makes the statement: Assume for the moment that there is a real interest in fixing this issue (there isnt, but Ill play along). Andy is right that it isnt going to do much good because, in essence, users dont care. The fundamental problem with this security scheme is that it requires some action of the part of the consumer. But consumers arent interested in the bother. This is the accepted wisdom of the community that builds these tools. Unfortunately it is too simple, and the sad reality is that this view is dangerously wrong, but self-perpetuating. Absence of respect is not evidence that the actors are stupid. For a longer discussion, see this paper: So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users. The title is maybe self-referential; if it takes you a while to work out what it is saying, youll appreciate how consumers feel :-) In short, it is not that consumers arent interested in the bother, its that they reject bad advice. And theyre right to do so. So there are two paths here, one is to improve the advice /up to the point where it is rational for users to pay attention/ which youll recognise is a very hard target. Or, remove the advice entirely and fix the model so that it represents a better trade-off (e.g., there is only one mode, and it is secure). As far as the secure browser architecture goes, that second path is pretty much impossible because it relies on too many external components, ones which will not move unless weve also figured out how to start and stop earthquakes, volcanoes and tsunamis at whim. So we are left with improving the advice, itself a very hard target. Lets try that: Imagine the following situation. You walk into your local bank but in order to withdraw any money you needed to do the following: interview the guard at the door to make sure he really worked for the bank, interviewed the teller to make sure he really worked for the bank, and then set at least 10% of the money you withdrew from the bank on fire so you could watch it burn and see if it was fake or not. Right, this is a common problem. The mistake you are making is that the majority view is how to design the product. In this case, if the majority ignore the information, we dont need to follow their view in order to redesign the product. The reason for this is that the minority can have a sufficient effect to achieve the desired result. This is what we call Open Governance: the information is put out there, but only a small minority look at any particular subset. The crowd in aggregate looks at all, but individually, specialisation takes root and becomes the norm. Lets step outside that context and try another. Consider a police officers badge. Its got a number on it. Often a name, as well. When the police officer busts some trouble maker, likely the perp does not notice the badge, nor the number. 99% likely, because the perp doesnt need to know, hes busted, and it matters little by whom. So whats the point? The point is, 1% will notice the badge number! And thats enough to cause the police -- that officer and all others -- to be cautious. To follow the rules. They dont know beforehand whos noting these things down, or not, and they dont need to. The just need to know that bad behaviour can be spotted, and as we get closer to routine bad behaviour, it is more likely that the number will be noted. Same with your bank guard. You dont have to interview him because the teller will. And if not, someone else in the branch. And if not them, some other customer will look. Welcome to Open Governance. This is a concept where the governance of the thing, whatever it be (a CA, a bank, a government, a copper) is done by all of us, the world, not by some special agency. Each of us on the net has the same chance to play in this game -- to govern the big bad player -- but only a very few of us actually govern any particular thing in question. Lets go back closer into context and consider CAs. How are these governed? Well, they publish CPSs, they get audited by auditors, and they audit is checked over by third party vendors. For example, weve seen audit reports that totally exclude important issues from consideration. And, nobody noticed beforehand! Which indicates that whatever is being done, whatever is being written, it isnt being verified nor understood. Which more or less casts in doubt all the prior due diligence done over CAs. This is one reason why Mozilla decided to bring in more open governance ideas. There was a recognition that the old mid-1990s CA audit model wasnt providing a reliably solid answer. There was at least some smoke and mirrors, some criticism of abuse, and these criticisms werent getting answered. More was needed, but not more of the same, more alternate governance. So Mozilla put in place an open list (you can join), published all new requests from CAs, and proposed them for open review (section 16 of the policy). There are a few people who read these things. Not many, because it is hard work, and it takes a lot of time. But its a start, we cant grow these things on trees. A forest starts with a single tree. The brand name on the chrome is the same thing. We might predict that 99% of the users wont look at it. But 1% will. And, we also know that most all computer users have someone experienced they turn to for help, and those people have a shot at knowing what the brand is about. The effect of the brand on the chrome as a security feature is then highly dependent on that effect: the CA doesnt know who is looking, but it knows that it is now totally tied to the results in the minds of those who are looking. This is powerful. Any marketing person will tell you that a threat to the brand is far more important than a deviation from a policy. CAs will fiddle their policies and practices in a heartbeat, but theyll not fiddle their brand. There is an old saying trust but verify. The problem is that this is a contradiction in terms. Trust means precisely that I dont have to verify. If I have to verify every transaction to see if the money is good, thats not trust. If I have to spy on my wife all the time to see if shes cheating, thats not trust. Asking the user to verify, when what the user wants to do is trust, is design failure that no amount of coding is going to fix. Actually, the expression is dead-right; trust can only come from verification, and repeated verifications at that. However, those verifications will have happened in the past; we might for example point to the fact that 99.999999% of all certificates issued have never caused a problem. Thats a million verifications, right there. When you say you dont have to verify, youre really saying you can take a risk this time. But there will come a time when that will rebound. Trust without verification is naïveté. But, what we can do is outsource and share who does the verifying. And thats what Brand on the Chrome is about; outsourcing and sharing the verification of the CAs business practices to the crowd....

Sometime in 1995 I needed a high performance database to handle transactions. Dont we all have these moments? Like everyone, I looked at the market, which was then Oracle, Informix and so forth. But unlike most, I had one advantage. I had seen the dirty side of that business because Id been called in several times to clean up clagged scrunted databases for clients who really truly needed their data back up. From that repetitive work came an sad realisation that no database is safe, and the only safe design is one that records in good time a clean, unchangeable and easily repairable record of what was happening, for the inevitable rebuild. At any one time. Recovery is the key, indeed, it is the primary principle of database design. So, for my transaction database, I knew Id have to do that with Oracle, or the rest, and thats where the lightbulb came on. The work required to wrap a reliability layer around a commercial database is approximately as much as the work required to write a small, purpose-limited database. I gambled on that inspiration, and it proved profitable. In one month, I wrote a transaction engine that did the work for 10 years, never losing a single transaction (it came close once though!). My design process also led me to ponder the truism that all fast stuff happens in memory, and also, that all reliance stuff happens at the point of logging the transaction request. Between these two points is the answer, which SAP seems to have stumbled on: ... As memory chips get cheaper, more and more of them are being packed into servers. This means that firms, instead of having to store their data on separate disks, can put most of them into their servers’ short-term memory, where they can be accessed and manipulated faster and more easily. The software SAP is releasing next week, a new version of Business ByDesign, its suite of online services for small companies, aims to capitalise on this trend, dubbed “in-memory”. SAP also plans to rewrite other programs along similar lines. ... The answer is something almost akin to a taboo: the database is only in memory, and the writes to slow storage are only transaction logging, not database actions. Which leads to the conclusion that when it crashes, all startups are recoveries, from the disk-based transaction log. If this were an aphorism, it would be like this: There is only one startup, and it is a recovery. In-memory technology is already widespread in systems that simply analyse data, but using it to help process transactions is a bigger step. SAP’s software dispenses with the separate “relational databases” where the data behind such transactions are typically stored, and instead retains the data within the server’s memory. This, says Vishal Sikka, the firm’s chief technologist, not only speeds up existing programs—it also makes them cheaper to run and easier to upgrade, and makes possible real-time monitoring of a firm’s performance. In its space, an in-memory database will whip the standard SQL-based database in read-times, which is the majority usage, and it doesnt have to be a slouch in write times either, because a careful design can deliver writes-per-transaction on par with the classical designs. Not only in performance but in ROI, because the design concept forces it into a highly-reliable, highly-maintainable posture which reduces on-going costs. But this inversion of classical design is seen as scary by those who are committed to the old ways. Why such a taboo? Partly because, in contrast to my claim that recovery is the primary principle of database design, it has always been seen as an admission of failure, as very slow, as fraught with danger, in essence, something to be discriminated against. And, it is this discrimination that Ive seen time and time again: nobody bothers to prove their recovery, because it never happens to them. Recovery is insurance for databases, and is not necessary except to give your bosses a good feeling. But thats perception. Reality is different. Recovery can be very fast for all the normal reasons, the processing time for recovering each individual record is about the same as reading in the record off-disk anyway. And, if you really need your data, you really need your recovery. The failure and fall-back to recovery needs to be seen in balance: you have to prove your recovery, so you may as well make it the essence not the fallback. That said, there are of course limitations to what SAP calls the in-memory approach. This works when you dont mind the occasional recovery, in that always-on performance isnt really possible. (Which is just another way of re-stating the principle that data never fails, because the transaction integrity takes priority over other desires like speed). Also, complexity and flexibility. It is relatively easy to create a simple database, and it is relatively easy to store a million records in the memory available to standard machines. But this only works if you can architecturally carve out that particular area out of your business and get it to stand alone. If you are more used to the monolithic silos with huge databases, datamining, data-ownership fights and so forth, this will be as irrelevant to you as a McDonalds on the Moon. Some observers are not convinced. They have not forgotten that many of SAP’s new products in the past decade have not been big successes, not least Business ByDesign. “There is healthy scepticism as to whether all this will work,” says Brent Thill of UBS, an investment bank. Existing customers may prefer not to risk disrupting their customised computer systems by adopting the new software. And dont forget that 3 entire generations of programmers are going to be bemused, at sea, when they ask for the database schema and are told there isnt one. For most of them, there is no difference between SQL and database. On a closing note, my hats off to the Economist for picking up this issue, and recognising the rather deeper questions being asked here. It is rare for anyone in the media to question the dogma of computing architecture, let alone a tea-room full of economists. Another gem: These efforts suggest that in-memory will proliferate, regardless of how SAP will fare. That could change the way many firms do business. Why, for example, keep a general ledger, if financial reports can be compiled on the fly? Swoon! If they keep this up, theyll be announcing the invention of triple entry bookkeeping in a decade, as that is really what theyre getting at. I agree, there are definitely many other innovations out there, waiting to be mined. But that depends on somewhat adroit decision-making, which is not necessarily in evidence. Unfortunately, this in-memory concept is too new idea to many, so SAP will need to plough the ground for a while. Larry Ellison, the boss of Oracle, which makes most of its money from such software, has ridiculed SAP’s idea of an in-memory database, calling it “wacko” and asking for “the name of their pharmacist”. But, after theyve done that, after this idea is widely adopted, well all be looking back at the buggy whip crowd, and voting who gets the Ken Olsen of the 21st Century Award....

NYT suggests that the SEC changes mentioned yesterday are approved: The proposed changes, approved in a 5-0 vote despite misgivings expressed by two commissioners, now enter a 90-day period for public comment before coming back to the commission for revision and final approval. but more importantly, The bond issuers would also be required to keep a chunk of the securities in their own portfolios so that they retain some of the bonds’ risk, under the S.E.C.’s plan. ... The changes would “represent a fundamental revision to the way in which the asset-backed securities market would be regulated,” the S.E.C.’s chairwoman, Mary L. Schapiro, said. “I think changes are both necessary and critical components of restoring investor confidence.” Aha! Someone knows the definition of banking: Banking is the borrowing of /demand deposits/ from the public, and the lending of those same deposits, /at term/ to the public. Banking is special for one and only one reason. Because the funds are borrowed as deposits, they can be returned today, immediately. Thats what on demand means, and also thats what deposits mean. Yet the loans are at term or to be repaid in the future. 30 years away, in the case of modern western mortgages. And that is the crux of banking. The loans out on houses cant be called in under normal circumstances, but the public can call in its deposits now, today. Ordinarily this would be called fraud, because the bank is entering into a contract that it knows it is impossible to guarantee. For this reason, a bank charter is like a specialised permission to undergo a certain sort of fraud, or more kindly, to turn this specialised contract into something that isnt a fraud. This arrangement is delicate. Change one word above and it is no longer banking (and in this statement you can find much of the ills of modern banking). Which leads us to securitization. Securitization is the process of creating the at-term loans, with demand deposits, and then packaging them and selling them onto the bond market. A bond issue might collectively handle thousands of similar properties, and gets sold into the market maybe 100 days after the mortgages are sold. Securitization breaks banking. It breaks banking because the loans are no longer at term, or they are, but they are no longer in the hands of the banks, they are on the market! So the investors in the bond market are lending at term to the house owners, and the magic link of banking has been broken. Regulators say the financial companies that created the bonds had little incentive to ensure that the bonds were backed by reliable loans. When large portions of the borrowers began to default on the loans, the holders of the securities had big losses. Right, exactly. As, in theory the banks no longer owned the bonds, having sold them on the market, they no longer had an incentive to manage the loans. And this is the implicit, unwritten corollary in the definition of banking: in order to get the charter, you have to look after the loans for their entire term. Thats what it means, to be a bank, guard the deposited funds, out on loan, for their entire life! The proposed rules, which would affect a large portion of new offerings in the $9.5 trillion market for securities backed by consumer loans, would in many cases require financial companies to retain 5 percent of each offering, a move that Ms. Schapiro said would “better align” the interests of investors and the securities firms. Financial reform bills winding their way through Congress contain similar requirements that financial companies “keep skin in the game,” as the commission put it. So does a proposal by the Federal Deposit Insurance Corporation, which regulates some asset-backed securities originated by banks. Skin in the game! Which the Python can only shed, as it outgrows model after model, leaving investors more and more confused. Models can only approximate risks of defaulting borrowers, and arent a substitute for attentive bankers. The big message to take away is this: Securitization breaks the fundamental law of banking. Is this good or bad? We should probably know this, because practically everything is done with securitization these days. And why not? It is decidedly more efficient, saving the occasional global meltdown. The answer is, that securitization is decidedly good, but it renders banking no longer special. This has a lot of ramifications: it means we no longer need banks. But weve got banks, so there is going to be a huge hangover period while society shifts from banking to market-oriented facilitation. And likely a few more crises. It also means we dont need central banks; or at least partly, we dont need that part which regulates the banks, because standard competition and exchange regulators should be able to do the job. Its all consumer products called bonds, after all. Yeah, sure, I hear you say, we dont need banks... chortle chortle. Admittedly the hangover from the century of central banking will be with us for a long time, and we can only move forward slowly. But watch: slowly but surely the move will be to open the market for loans origination. Under the new rules, bond underwriters would not be required to receive a credit rating; rather, the chief executive of the bond issuer would have to certify that the assets were likely to produce the expected cash flows. ... Moody’s, in a statement, said, “We believe the market benefits when ratings agencies compete on the basis of the quality of their credit analysis, and we have long supported the removal of ratings from regulation.” Baby step by baby step, the business of banking is moving over to the marketplace....

Twan points to an odd thing from the Securities and Exchanges Commission in USA: We are proposing to require that most ABS issuers file a computer program that gives effect to the flow of funds, or “waterfall,” provisions of the transaction. We are proposing that the computer program be filed on EDGAR in the form of downloadable source code in Python. … (page 205) Under the proposed requirement, the filed source code, when downloaded and run by an investor, must provide the user with the ability to programmatically input the user’s own assumptions regarding the future performance and cash flows from the pool assets, including but not limited to assumptions about future interest rates, default rates, prepayment speeds, loss-given-default rates, and any other necessary assumptions … (page 210) An ABS or asset backed security is a basically a financial instrument that has or "owns" a lump of property. In short, instead of owning the property yourself, you own a security (or instrument or contract) that has an interest in the property. At the simplest, trivial level of own house, one instrument, this is mostly meaningless, because the instrument owns the property so you may as well own it directly. But it allows for more complexity. What they are talking about here is securitized home loans and the like, essentially the instruments that blew up in the recent financial crisis. In this case, your instrument has an interest in 1000 properties, but also this is the same interest that another 10,000 instruments have. So you don't own a house, or a tenth of a house, you own a share in the revenues of a combined 1000 houses. What is that revenue? Well, it is probably the mortgage payments on the 1000 houses. Every month, the mortgage payments are collected, aggregated, fees taken, then the payments out are sent to the instrument holder. So what the SEC is on about is complicated formulas. Also, they change. If 10 of the houses are delinquent this month, then 20 next month, the money changes. If interest rates go up, again it changes. If fees change, more change. Indeed, it's pretty clear that there is much more complexity and change than there is stability. So the SEC is seeking to encourage the manager to show the formulas. In a computer program, so we can plug in the numbers, and investors can play around to isolate their preferred situations. On the surface it is a good idea. It gives the investor more power, and it sets up a key disclosure which can likely be challenged in the event of trouble. But it is unlikely to work as a mandated thing. There are several things against this. Complexity is the enemy here. There are two ways of looking at it, as too complex, and as not complex enough. Initially, the models will be simple, but this will just set the scene for disputes, and the models will get more complex. And then more complex again because the hidden-by-complexity bug will strike -- managers will realise that if they make the models so complex that nobody can deal with them except real experts, then they'll be both compliant and impenetrable, and can get back to their normal games. If you look long enough at the financial crisis, you'll see that one important factor is complexity, and worse, deliberate complexity. This is an old game. Further, there is a bit of a trap for young players here (as explained to me by Jim). The model will display the "flow of funds" which is in turn dictated by the instrument (the contract). Servicing and pooling provisions in the contract will mandate the manager's actions, and therefore the cash flow. So measuring & comparing the cash flow in this way tells us the manager is meeting targets, etc, *but it tells us nothing about the underlying collateral* which is the true asset in the picture. Recall, again, the financial crisis: meeting targets and bonuses was part of the problem, not the solution. These agreements are written to provide plenty of scope for this sort of trouble, and the SEC's invention runs the risk of making this worse, not better. What's the solution? Well, the real health of the fund to which your instrument draws on is based on the collateral, and the revenues from it. That is, the real information you want is detailed income, not aggregated outgoings. So if the SEC were to want to make a difference, what it should do is mandate that the anonymised income transactions be made available (FCers will know what that means). That is, any time a house-owner makes a payment into the fund, that transaction be published to the fund investors. By tracking month to month the payments, and matching that to what the investors get, we have some data of value. Would they do this? The SEC is not going to propose this, because of the complexity argument. The industry will not give up any of its treasured complexity, because that's how it makes money. If you could see what was going on, the prices would be beaten down. But it could be done voluntarily. A private player could set this up; we have all the tech and understanding to do this. So what could the SEC do? Expand its proposal slightly, and create a format for a fund to reveal the anonymised flow of incomes from the collateral. And provide a program to deal with that. And see if anyone bites... Meanwhile, two postcripts on spotted observations. One: a group of language specialists think the SEC are trying to give formal definition to the instrument; by means of Python. No, they're on the wrong track. Firstly, that isn't what the SEC is trying to do. Secondly, it won't work because bonds by their nature are contracts, and formal proofs of contracts are the domain of the courts, not compilers. Although this concept has been explored, real world bonds still have more to do with my Ricardian Contract form than esoterica like Nick Szabo's smart contracts. Two: another group of developers are arguing whether Python is the right language. No need to comment :) And Three, added from next post, maybe this is to happen: The companies selling the bonds would also have to give the government extensive information, in a form that is easily searchable, on all of the individual loans that make up the portfolio behind the bond offering, and update it on a continuing basis. Previously, reports were required only on the overall credit quality of the pool of loans, and for some bonds, updates were suspended after about a year. .... Ms. Casey also expressed concerns about the impact of the rules on personal privacy, asking whether “data miners” might be able to use the information on individual loans to determine the identification of loan holders. Spotted in NYT article....

In an influential paper, Prof Ross Anderson proposes that the _Market for Lemons_ is a good fit for infosec. I disagree, because that market is predicated on the seller being informed, and the buyer not. I suggest the sellers are equally ill-informed, leading to the Market for Silver Bullets. Microsoft and RSA have just published some commissioned research by Forrester that provides some information, but it doesnt help to separate the positions: CISOs do not know how effective their security controls actually are. Regardless of information asset value, spending, or number of incidents observed, nearly every company rated its security controls to be equally effective — even though the number and cost of incidents varied widely. Even enterprises with a high number of incidents are still likely to imagine that their programs are “very effective.” We concluded that most enterprises do not actually know whether their data security programs work or not. Buyers remain uninformed, something we both agree on. Curiously, it isnt an entirely good match for Akerlof, as the buyer of a Lemon is uninformed before, and regrettably over-informed afterwards. No such for the CISO. Which leaves me with an empirical problem: how to show that the sellers are uninformed? I provide some anecdotes in that paper, but we would need more to settle the prediction. It should be possible to design an experiment to reveal this. For example, and drawing on the above logic, if a researcher were to ask similar questions of both the buyer and the seller, and be able to show lack of correlation between the suppliers claims, and the incident rate, that would say something. The immediate problem of course is, who would do this? Microsoft and RSA arent going to, as they are sell-side, and their research was obviously focussed on their needs. Which means, it might be entirely accurate, but might not be entirely complete; they arent likely to want to clearly measure their own performance. And, if there is one issue that is extremely prevalent in the world of information security, it is the lack of powerful and independent buy-side institutions who might be tempted to do independent research on the information base of the sellers. Oh well. moving on to the other conclusions: Secrets comprise two-thirds of the value of firms’ information portfolios. Compliance, not security, drives security budgets. Firms focus on preventing accidents, but theft is where the money is. The more valuable a firm’s information, the more incidents it will have. The second and third were also predicted in that paper. The last is hopefully common sense, but unfortunately as someone used to say, common sense isnt so common. Which brings me to Matt Blazes rather good analysis of the threats to the net in 1995, as an afterword to Applied Cryptography, the seminal red book by Bruce Schneier: One of the most dangerous aspects of cryptology (and, by extension, of this book), is that you can almost measure it. Knowledge of key lengths, factoring methods, and cryptanalytic techniques make it possible to estimate (in the absence of a real theory of cipher design) the work factor required to break a particular cipher. Its all too tempting to misuse these estimates as if they were overall security metrics for the systems in which they are used. The real world offers the attacker a richer menu of options than mere cryptanalysis; often more worrisome are protocol attacks, Trojan horses, viruses, electromagnetic monitoring, physical compromise, blackmail and intimidation of key holders, operating system bugs, application program bugs, hardware bugs, user errors, physical eavesdropping, social engineering, and dumpster diving, to name just a few. Right. It must have not escaped anyone by now that the influence of cryptography has been huge, but the success in security has been minimal. Cryptography has not really been shown to secure our interactions that much, having missed the target as many times as it might have hit it. And with the rise of phishing and breaches and MITBs and trojans and so forth, we are now in the presence of evidence that the institutions of strong cryptography have cemented us into a sort of Maginot line mentality. So it may be doing more harm than good, although such a claim would need a lot of research to give it some weight. I tried to research this a little in Pareto-secure, in which I asked why the measurements of crypto-algorithms received such slavish attention, to the exclusion of so much else? I found an answer, at least, and it was a positive, helpful answer. But the far bigger question remains: what about all the things we cant measure with a bit-ruler? Matt Blaze listed 10 things in 1996: The sorry state of software. Ineffective protection against denial-of-service attacks. No place to store secrets. Poor random number generation. Weak passphrases. Mismatched trust. Poorly understood protocol and service interactions. Unrealistic threat and risks assessment. Interfaces that make security expensive and special. No broad-based demand for security. In 2010, today more or less, he said not much has changed. We live in a world where if MD5 is shown to be a bit flaky because it has less bits than SHA1, the vigilantes of the net launch pogroms on the poor thing, committees of bitreaucrats write up how MD5-must-die, and the media breathlessly runs around claiming the sky will fall in. Even though none of this is true, and there is no attack possible at the moment, and when the attack is possible, it is still so unlikely that we can ignore it ... and even if it does happen, the damages will be next to zero. Meanwhile, if you ask for a user-interface change, because the failure of the user-interface to identify false end-points has directly led to billions of dollars of damages, you can pretty much forget any discussion. For some reason, bit-strength dominates dollars-losses, in every conversation. I used to be one of those who gnashed my teeth at the sheer success of Applied Cryptography, and the consequent generation of crypto-amateurs who believed that the bit count was the beginning and end of all. But thats unfair, as I never got as far as reading the afterword, and the message is there. It looks like Bruce made a slight error, and should have made Matt Blazes contribution the foreword, not the afterword. A one-word error in the editorial algorithm! I must write to the committee......