Financial Cryptography

EV's green cert is breached (of course) (SNAFU)

Reading up on something or other (Ivan Ristić), I stumbled on this EV breach by Adrian Dimcev:

Say you go to https://addons.mozilla.org and download a popular extension. Maybe NoScript. The download location appears to be over HTTPS. ... (lots of HTTP/HTTPS blah blah) ... Today I had some time, so I’ve decided to play a little with this. ...

Well, Wladimir Palant is now the author of NoScript, and of course, I’m downloading it over HTTPS.

Boom! Mozilla's website uses an EV ("extended validation") certificate to present to the user that this is a high security site, or something. However, it provided the downloads over HTTP, and this was easily manipulable. Hence, NoScript (which I use) was hit by an MITM, and this might explain why Robert Hansen said that the real author of NoScript, Giorgio Maone, was the 9th most dangerous person on the planet.

What's going on here? Well, several things. The promise that the web site makes when it displays the green EV certificate is just that: a promise. The essence of the EV promise is that it is somehow of a stronger quality than say raw unencrypted HTTP.

EV checks identity to the Nth degree, which is why it is called "extended validation." Checking the identity is useful, but no more than is matched by a balance in overall security, so the difference between ordinary certs and EV is mostly irrelevant. In simple security model terms, that's not where the threats are (or ever were), so they are winding up the wrong knob. In economics terms, EV raises the cost barrier, which is classical price discrimination, and this results in a colourful signal, not a metric or measure. The marketing aligns the signal of green to security, but the attack easily splits security from promise. Worse, the more they wind the knob, the more they drift off topic, as per silver bullets hypothesis.

If you want to put it in financial or payments context, EV should be like PCI, not like KYC.

But it isn't, it's the gold-card of KYC. So, how easy is it to breach the site itself and render the promise a joke? Well, this is the annoying part. Security practices in the HTTP world today are so woeful that even if you know a lot, and even if you try hard to make it secure, the current practices are terrifically hard to secure. Basically, complexity is the enemy of security, and complexity is too high in the world of websites & browsers.

So CABForum, the promoters of EV, fell into the trap of tightening the identity knob up so much, to increase the promise of security ... but didn't look at all at the real security equation on which it is dependent. So, it is a strong brand over a weak product, it's green paint over wood rot. Worse for them, they won't ever rectify this, because the solutions are out of their reach: they cannot weaken the identity promise without causing the bureaucrats to attack them, and they cannot improve the security of the foundation without destroying the business model.

Which brings us to the real security question. What's the easiest fix? It is:

there is only one mode, and it is secure.

Now, hypothetically, we could see a possibility of saving EV if the CABForum contracts were adjusted such that they enforce this dictum. In practical measures, it would be a restriction that an EV-protected website would only communicate over EV, there would be no downgrade possible. Not to Blue HTTPS, not to white HTTP. This would include all downloads, all javascript, all mashups, all off-site blah blah.

And that would be the first problem with securing the promise: EV is sold as a simple identity advertisement, it does not enter into the security business at all. So this would make a radical change in the sales process, and it's not clear it would survive the transition.

Secondly, CABForum is a cartel of people who are in the sales business. It's not security-wise but security-talk. So as a practical matter, the institution is not staffed with the people who are going to pick up this ball and run with it. It has a history of missing the target and claiming victory (c.f., phishing), so what would change its path now?

That's not to say that EV is all bad, but here is an example of how CABForum succeeded and failed, as illustrative of their difficulties:

EV achieved one thing, in that it put the brand name of the CA on the agenda. HTTPS security at the identity level is worthless unless the brand of the CA is shown. I haven't seen a Microsoft browser in a while, but the mock-ups showed the brand of the CA, so this gives the consumer a chance to avoid the obvious switcheroo from known brand to strange foreign thing, and recent breaches of various low-end commercial CAs indicate there isn't much consistency across the brands. (Or fake injection attacks, if one is worried about MITB.)

So it is essential to any sense of security that the identity of who made the security statement be known to consumers; and CABForum tried to make this happen. Here's one well-known (branded) CA's display of the complete security statement.

But Mozilla was a hold-out. (It is a mystery why Mozilla fights against the the complete security statement. I have a feeling it is more of the same problem that infects CABForum, Microsoft and the Internet in general; monoculture. Mozilla is staffed by developers who apparently think that brands are TV-adverts or road-side billboards of no value to their users, and Mozilla's mission is to protect their flock against another mass-media rape of consciousness & humanity by the evil globalised corporations ... rather than appreciating the brand as handles to security statements that mesh into an overall security model.)

Which puts the example to the test: although CABForum was capable of winding the identity knob up to 11, and beyond, they were not capable of adjusting the guidelines to change the security model, and force the brand of the CA to be shown on the browser, in some sense. In these terms, what has now happened is that Mozilla is embarrassed, but zero fallback comes onto the CA. It was the CA that should have solved the problem in the first place, because the CA is in the sell-security business, Mozilla is not. So the CA should have adjusted contracts to control the environment in which the green could be displayed. Oops.

Where do we go from here? Well, we'll probably see a lot of embarrassing attacks on EV ... the brand of EV will wobble, but still sell (mostly because consumers don't believe it anyway, because they know all security marketing is mostly talk [or, do they?], and corporates will try any advertising strategy, because most of them are unprovable anyway). But, gradually the embarrassments will add up to sufficient pressure to push the CABForum to entering the security business. (e.g., PCI not KYC.)

The big question is, how long will this take, and will it actually do any good? If it takes 5-10 years, which I would predict, it will likely be overtaken by events, just as happened with the first round of security world versus phishing. It seems that we are in that old military story where our unfortunate user-soldiers are being shot up on the beaches while the last-war generals are still arguing as to what paint to put on the rusty ships. SNAFU, "situation normal, all futzed up," or in normal language, same as it ever was.

load up on Steel, and shoot it out! PCI and the market for silver bullets

Unusually, someone in the press wrote up a real controversy, called The Great PCI Security Debate of 2010. Exciting stuff! In this case, a bunch of security people including Bill Brenner, Ben Rothke, Anton Chuvakin and other famous names are arguing whether PCI is good or bad. The short story is that we are in the market for silver bullets, and this article nicely lays out the evidence:

Let's just look at the security market: I did a market survey when I was at IBM and there were about 70 different security product technologies, not even counting services. How many of those are required by PCI? It's a tiny subset. No one invests in all 70.

In this market, external factors are the driving force:

But the truth is, when someone determined they had to do something about targeted attacks or data loss prevention for intellectual property, they had a pilot and a budget but their bosses told them to cut it. The reason was, "I might get hacked, but I will get fined." That's a direct quote from a CIO and it's very logical and business focused. But instead of securing their highest-risk priority they're doing the thing that they'll get fined for not doing.

We don't "do security," rather, we avoid exposure to fingerpointing and other embarrassments. By way of hypotheses in the market for silver bullets, we then find ourselves seeking to reduce the exposure to those external costs; this causes the evolution of some form of best practices which is an agreed set that simply ensures you are not isolated by difference. In the case in point, this best practices is PCI.

In other words, security by herding , compliance-seeking behaviour:

One of the things I see within organizations is that there's a hurry-up-and-wait mentality. An organization will push really hard to get compliant. Then, the day the auditor walks out the door they say, "Thank goodness. Now I can wait until next year." So when we talk about compliance driving the wrong mindset, I think the wrong mindset was there to begin with.

It's a difficult proposition to say we're doing compliance instead of security when what I see is they're doing compliance because someone told them to, whereas if no one told them to they'd do nothing. It's like telling your kids to do their homework. If you don't tell them to do the homework they're going to play outside all day.

This is rational, we simply save more money doing that. What to do about it? If one is a consultant, one can sell more services:

There is security outside of PCI and if we as security counselors aren't encouraging customers to look outside PCI then we ourselves are failing the industry because we're not encouraging them to look to good security as opposed to just good PCI compliance. The idea that they fear the auditor and not the attacker really bothers me.

Which is of course rational for the adviser, but not rational for the buyer because more security likely reduces profits in this market. If on the other hand we are trying to make the market more efficient (generally a good goal, as this means it reduces the costs to all players) then the goal is simple: move the market for silver bullets into a market for lemons or limes.

That's easy to say, very hard to do. There's at least one guy who doesn't want that to happen: the attacker. Furthermore, depending on your view of the perversion of incentives in the payment industry, fraud is good for profits because it enables building of margin. Our security adviser has the same perverse incentive: the more fraud, the more jobs. Indeed, everyone is positive about it, except the user, and they get the bill, not the vote.

I see a bright future for PCI. To put it in literary terms:

Ben Rothke: Dan Geer is the Shakespeare of information security, but at the end of the day people are reading Danielle Steel, not Shakespeare.

In the market for silver bullets, you don't need to talk like Shakespeare. Load up on bullets of Steel, or as many other mangled metaphors as you can cram in, and you're good to shoot it out with the rest of 'em.

Phishing numbers

From a couple of sources posted by Lynn:

• A single run only hits 0.0005 percent of users,
• 1% of customers will follow the phishing links.
• 0.5% of customers fall for phishing schemes and compromise their online banking information.
• the monetary losses could range between $2.4 million and $9.4 million annually per one million online banking clients
• in average ... approximately 832 a year ... reached users' inboxes.
• costs estimated at up to $9.4 million per year per million users.
• based on data colleded from "3 million e-banking users who are customers of 10 sizeable U.S. and European banks."

The primary source was a survey run by an anti-phishing software vendor, so caveats apply. Still interesting!

For more meat on the bigger picture, see this article: Ending the PCI Blame Game. Which reads like a compressed version of this blog! Perhaps, finally, the thing that is staring the financial operators in the face has started to hit home, and they are really ready to sound the alarm.

Breaches not as disclosed as much as we had hoped

One of the brief positive spots in the last decade was the California bill to make breaches of data disclosed to effected customers. It took a while, but in 2005 the flood gates opened. Now reports the FBI:

"Of the thousands of cases that we've investigated, the public knows about a handful," said Shawn Henry, assistant director for the Federal Bureau of Investigation's Cyber Division. "There are million-dollar cases that nobody knows about."

That seems to point at a super-iceberg. To some extent this is expected, because companies will search out new methods to bypass the intent of the disclosure laws. And also there is the underlying economics. As has been pointed out by many (or perhaps not many but at least me) the reputation damage probably dwarfs the actual or measurable direct losses to the company and its customers.

Companies that are victims of cybercrime are reluctant to come forward out of fear the publicity will hurt their reputations, scare away customers and hurt profits. Sometimes they don't report the crimes to the FBI at all. In other cases they wait so long that it is tough to track down evidence.

So, avoidance of disclosure is the strategy for all properly managed companies, because they are required to manage the assets of their shareholders to the best interests of the shareholders. If you want a more dedicated treatment leading to this conclusion, have a look at "the market for silver bullets" paper.

Meanwhile, the FBI reports that the big companies have improved their security somewhat, so the attackers direct at smaller companies. And:

They also target corporate executives and other wealthy public figures who it is relatively easy to pursue using public records. The FBI pursues such cases, though they are rarely made public.

Huh. And this outstanding coordinated attack:

A similar approach was used in a scheme that defrauded the Royal Bank of Scotland's (RBS.L: Quote, Profile, Research, Stock Buzz) RBS WorldPay of more than $9 million. A group, which included people from Estonia, Russia and Moldova, has been indicted for compromising the data encryption used by RBS WorldPay, one of the leading payment processing businesses globally.

The ring was accused of hacking data for payroll debit cards, which enable employees to withdraw their salaries from automated teller machines. More than $9 million was withdrawn in less than 12 hours from more than 2,100 ATMs around the world, the Justice Department has said.

2,100 ATMs! worldwide! That leaves that USA gang looking somewhat kindergarten, with only 50 ATMs cities. No doubt about it, we're now talking serious networked crime, and I'm not referring to the Internet but the network of collaborating, economic agents.

Compromising the data encryption, even. Anyone know the specs? These are important numbers. Did I miss this story, or does it prove the FBI's point?

Denial of Service is the greatest bug of most security systems

I've had a rather troubling rash of blog comment failure recently. Not on FC, which seems to be ok ("to me"), but everywhere else. At about 4 in the last couple of days I'm starting to get annoyed. I like to think that my time in writing blog comments for other blogs is valuable, and sometimes I think for many minutes about the best way to bring a point home.

But more than half the time, my comment is rejected. The problem is on the one hand overly sophisticated comment boxes that rely on exotica like javascript and SSO through some place or other ... and spam on the other hand.

These things have destroyed the credibility of the blog world. If you recall, there was a time when people used blogs for _conversations_. Now, most blogs are self-serving promotion tools. Trackbacks are dead, so the conversational reward is gone, and comments are slow. You have to be dedicated to want to follow a blog and put a comment on there, or stupid enough to think your comment matters, and you'll keep fighting the bl**dy javascript box.

The one case where I know clearly "it's not just me" is John Robb's blog. This was a *fantastic* blog where there was great conversation, until a year or two back. It went from dozens to a couple in one hit by turning on whatever flavour of the month was available in the blog system. I've not been able to comment there since, and I'm not alone.

This is denial of service. To all of us. And, this denial of service is the greatest evidence of the failure of Internet security. Yet, it is easy, theoretically easy to avoid. Here, it is avoided by the simplest of tricks, maybe one per month comes my way, but if I got spam like others get spam, I'd stop doing the blog. Again denial of service.

Over on CAcert.org's blog they recently implemented client certs. I'm not 100% convinced that this will eliminate comment spam, but I'm 99.9% convinced. And it is easy to use, and it also (more or less) eliminates that terrible thing called access control, which was delivering another denial of service: the people who could write weren't trusted to write, because the access control system said they had to be access-controlled. Gone, all gone.

According to the blog post on it:

The CAcert-Blog is now fully X509 enabled. From never visited the site before and using a named certificate you can, with one click (log in), register for the site and have author status ready to write your own contribution.

Sounds like a good idea, right? So why don't most people do this? Because they can't. Mostly they can't because they do not have a client certificate. And if they don't have one, there isn't any point in the site owner asking for it. Chicken & egg?

But actually there is another reason why people don't have a client certificate: it is because of all sorts of mumbo jumbo brought up by the SSL / PKIX people, chief amongst which is a claim that we need to know who you are before we can entrust you with a client certificate ... which I will now show to be a fallacy. The reason client certificates work is this:

If you only have a WoT unnamed certificate you can write your article and it will be spam controlled by the PR people (aka editors).

If you had a contributor account and haven’t posted anything yet you have been downgraded to a subscriber (no comment or write a post access) with all the other spammers. The good news is once you log in with a certificate you get upgraded to the correct status just as if you’d registered.

We don't actually need to know who you are. We only need to know that you are not a spammer, and you are going to write a good article for us. Both of these are more or less an equivalent thing, if you think about it; they are a logical parallel to the CAPTCHA or turing test. And we can prove this easily and economically and efficiently: write an article, and you're in.

Or, in certificate terms, we don't need to know who you are, we only need to know you are the same person as last time, when you were good.

This works. It is an undeniable benefit:

There is no password authentication any more. The time taken to make sure both behaved reliably was not possible in the time the admins had available.

That's two more pluses right there: no admin de-spamming time lost to us and general society (when there were about 290 in the wordpress click-delete queue) and we get rid of those bl**dy passwords, so another denial of service killed.

Why isn't this more available? The problem comes down to an inherent belief that the above doesn't work. Which is of course a complete nonsense. 2 weeks later, zero comment spam, and I know this will carry on being reliable because the time taken to get a zero-name client certificate (free, it's just your time involved!) is well in excess of the trick required to comment on this blog.

No matter the *results*, because of the belief that "last-time-good-time" tests are not valuable, the feature of using client certs is not effectively available in the browser. That which I speak of here is so simple to code up it can actually be tricked from any website to happen (which is how CAs get it into your browser in the first place, some simple code that causes your browser to do it all). It is basically the creation of a certificate key pair within the browser, with a no-name in it. Commonly called the self-signed certificate or SSC, these things can be put into the browser in about 5 seconds, automatically, on startup or on absence or whenever. If you recall that aphorism:

There is only one mode, and it is secure.

And contrast it to SSL, we can see what went wrong: there is an *option* of using a client cert, which is a completely insane choice. The choice of making the client certificate optional within SSL is a decision not only to allow insecurity in the mode, but also a decision to promote insecurity, by practically eliminating the use of client certs (see the chicken & egg problem).

And this is where SSL and the PKIX deliver their greatest harm. It denies simple cryptographic security to a wide audience, in order to deliver ... something else, which it turns out isn't as secure as hoped because everyone selects the wrong option. The denial of service attack is dominating, it's at the level of 99% and beyond: how many blogs do you know that have trouble with comments? How many use SSL at all?

So next time someone asks you, why these effing passwords are causing so much grief in your support department, ask them why they haven't implemented client certs? Or, why the spam problem is draining your life and destroying your social network? Client certs solve that problem.

SSL security is like Bismarck's sausages: "making laws is like making sausages, you don't want to watch them being made." The difference is, at least Bismark got a sausage!

Footnote: you're probably going to argue that SSCs will be adopted by the spammer's brigade once there is widespread use of this trick. Think for minute before you post that comment, the answer is right there in front of your nose! Also you are probably going to mention all these other limitations of the solution. Think for another minute and consider this claim: almost all of the real limitations exist because the solution isn't much used. Again, chicken & egg, see "usage". Or maybe you'll argue that we don't need it now we have OpenID. That's specious, because we don't actually have OpenID as yet (some few do, not all) and also, the presence of one technology rarely argues against another not being needed, only marketing argues like that.

Man-in-the-Browser goes to court

Stephen Mason reports that MITB is in court:

A gang of internet fraudsters used a sophisticated virus to con members of the public into parting with their banking details and stealing £600,000, a court heard today.

Once the 'malicious software' had infected their computers, it waited until users logged on to their accounts, checked there was enough money in them and then insinuated itself into cash transfer procedures.

(also on El Reg.) This breaches the 2-factor authentication system commonly in use because it (a) controls the user's PC, and (b) the authentication scheme that was commonly pushed out over the last decade or so only authenticates the user, not the transaction. So as the trojan now controls the PC, it is the user. And the real user happily authenticates itself, and the trojan, and the trojan's transactions, and even lies about it!

Numbers, more than ordinarily reliable because they have been heard in court:

'In fact as a result of this Trojan virus fraud very many people - 138 customers - were affected in this way with some £600,000 being fraudulently transferred.

'Some of that money, £140,000, was recouped by NatWest after they became aware of this scam.'

This is called Man-in-the-browser, which is a subtle reference to the SSL's vaunted protection against Man-in-the-middle. Unfortunately several things went wrong in this area of security: Adi's 3rd law of security says the attacker always bypasses; one of my unnumbered aphorisms has it that the node is always the threat, never the wire, and finally, the extraordinary success of SSL in the mindspace war blocked any attempts to fix the essential problems. SSL is so secure that nobody dare challenge browser security.

The MITB was first reported in March 2006 and sent a wave of fear through the leading European banks. If customers lost trust in the online banking, this would turn their support / branch employment numbers on their heads. So they rapidly (for banks) developed a counter-attack by moving their confirmation process over to the SMS channel of users' phones. The Man-in-the-browser cannot leap across that air-gap, and the MITB is more or less defeated.

European banks tend to be proactive when it comes to security, and hence their losses are miniscule. Reported recently was something like €400k for a smaller country (7 million?) for an entire year for all banks. This one case in the UK is double that, reflecting that British banks and USA banks are reactive to security. Although they knew about it, they ignored it.

This could be called the "prove-it" school of security, and it has merit. As we saw with SSL, there never really was much of a threat on the wire; and when it came to the node, we were pretty much defenceless (although a lot of that comes down to one factor: Microsoft Windows). So when faced with FUD from the crypto / security industry, it is very very hard to separate real dangers from made up ones. I felt it was serious; others thought I was spreading FUD! Hence Philipp Güring's paper Concepts against Man-in-the-Browser Attacks, and the episode formed fascinating evidence for the market for silver bullets. The concept is now proven right in practice, but it didn't turn out how we predicted.

What is also interesting is that we now have a good cycle timeline: March 2006 is when the threat first crossed our radars. September 2009 it is in the British courts.

Postscript. More numbers from today's MITB:

A next-generation Trojan recently discovered pilfering online bank accounts around the world kicks it up a notch by avoiding any behavior that would trigger a fraud alert and forging the victim's bank statement to cover its tracks.

The so-called URLZone Trojan doesn't just dupe users into giving up their online banking credentials like most banking Trojans do: Instead, it calls back to its command and control server for specific instructions on exactly how much to steal from the victim's bank account without raising any suspicion, and to which money mule account to send it the money. Then it forges the victim's on-screen bank statements so the person and bank don't see the unauthorized transaction.

Researchers from Finjan found the sophisticated attack, in which the cybercriminals stole around 200,000 euro per day during a period of 22 days in August from several online European bank customers, many of whom were based in Germany....

"The Trojan was smart enough to be able to look at the [victim's] bank balance," says Yuval Ben-Itzhak, CTO of Finjan... Finjan found the attackers had lured about 90,000 potential victims to their sites, and successfully infected about 6,400 of them. ...URLZone ensures the transactions are subtle: "The balance must be positive, and they set a minimum and maximum amount" based on the victim's balance, Ben-Itzhak says. That ensures the bank's anti-fraud system doesn't trigger an alert, he says.

And the malware is making the decisions -- and alterations to the bank statement -- in real time, he says. In one case, the attackers stole 8,576 euro, but the Trojan forged a screen that showed the transferred amount as 53.94 euro. The only way the victim would discover the discrepancy is if he logged into his account from an uninfected machine.

Robert Garigue and Charlemagne as a model of infosec

Gunnar reports that someone called Robert Garigue died last month. This person I knew not, but his model resonates. Sound bites only from Gunnar's post:

"It's the End of the CISO As We Know It (And I Feel Fine)"...

...First, they miss the opportunity to look at security as a business enabler. Dr. Garigue pointed out that because cars have brakes, we can drive faster. Security as a business enabler should absolutely be the starting point for enterprise information security programs.
...

Secondly, if your security model reflects some CYA abstraction of reality instead of reality itself your security model is flawed. I explored this endemic myopia...

This rhymes with: "what's your business model?" The bit lacking from most orientations is the enabler, why are we here in the first place? It's not to show the most elegant protocol for achieving C-I-A (confidentiality, integrity, authenticity), but to promote the business.

How do we do that? Well, most technologists don't understand the business, let alone can speak the language. And, the business folks can't speak the techno-crypto blah blah either, so the blame is fairly shared. Dr. Garigue points us to Charlemagne as a better model:

King of the Franks and Holy Roman Emperor; conqueror of the Lombards and Saxons (742-814) - reunited much of Europe after the Dark Ages.

He set up other schools, opening them to peasant boys as well as nobles. Charlemagne never stopped studying. He brought an English monk, Alcuin, and other scholars to his court - encouraging the development of a standard script.

He set up money standards to encourage commerce, tried to build a Rhine-Danube canal, and urged better farming methods. He especially worked to spread education and Christianity in every class of people.

He relied on Counts, Margraves and Missi Domini to help him.

Margraves - Guard the frontier districts of the empire. Margraves retained, within their own jurisdictions, the authority of dukes in the feudal arm of the empire.

Missi Domini - Messengers of the King.

In other words, the role of the security person is to enable others to learn, not to do, nor to critique, nor to design. In more specific terms, the goal is to bring the team to a better standard, and a better mix of security and business. Garigue's mandate for IT security?

Knowledge of risky things is of strategic value

How to know today tomorrow’s unknown ?

How to structure information security processes in an organization so as to identify and address the NEXT categories of risks ?

Curious, isn't it! But if we think about how reactive most security thinking is these days, one has to wonder where we would ever get the chance to fight tomorrow's war, today?

trouble in PKI land

The CA and PKI business is busy this week. CAcert, a community Certification Authority, has a special general meeting to resolve the trauma of the collapse of their audit process. Depending on who you ask, my resignation as auditor was either the symptom or the cause.

In my opinion, the process wasn't working, so now I'm switching to the other side of the tracks. I'll work to get the audit done from the inside. Whether it will be faster or easier this way is difficult to say, we only get to run the experiment once.

Meanwhile, Mike Zusman and Alex Sotirov are claiming to have breached the EV green bar thing used by some higher end websites. No details available yet, it's the normal tease before a BlabHat style presentation by academics. Rumour has it that they've exploited weaknesses in the browsers. Some details emerging:

With control of the DNS for the access point, the attackers can establish their machines as men-in-the-middle, monitoring what victims logged into the access point are up to. They can let victims connect to EV SSL sites - turning the address bars green. Subsequently, they can redirect the connection to a DV SSL sessions under a certificates they have gotten illicitly, but the browser will still show the green bar.

Ah that old chestnut: if you slice your site down the middle and do security on the left and no or lesser security on the right, guess where the attacker comes in? Not the left or the right, but up the middle, between the two. He exploits the gap. Which is why elsewhere, we say "there is only one mode and it is secure."

Aside from that, this is an interesting data point. It might be considered that this is proof that the process is working (following the GP theory), or it might be proof that the process is broken (following the sleeping-dogs-lie model of security).

Although EV represents a good documentation of what the USA/Canada region (not Europe) would subscribe as "best practices," it fails in some disappointing ways. And in some ways it has made matters worse. Here's one: because the closed proprietary group CA/B Forum didn't really agree to fix the real problems, those real problems are still there. As Extended Validation has held itself up as a sort of gold standard, this means that attackers now have something fun to focus on. We all knew that SSL was sort of facade-ware in the real security game, and didn't bother to mention it. But now that the bigger CAs have bought into the marketing campaign, they'll get a steady stream of attention from academics and press.

I would guess less so from real attackers, because there are easier pickings elsewhere, but maybe I'm wrong:

"From May to June 2009 the total number of fraudulent website URLs using VeriSign SSL certificates represented 26% of all SSL certificate attacks, while the previous six months presented only a single occurrence," Raza wrote on the Symantec Security blogs.

... MarkMonitor found more than 7,300 domains exploited four top U.S. and international bank brands with 16% of them registered since September 2008.
.... But in the latest spate of phishing attempts, the SSL certificates were legitimate because "they matched the URL of the fake pages that were mimicking the target brands," Raza wrote.

VeriSign Inc., which sells SSL certificates, points out that SSL certificate fraud currently represents a tiny percentage of overall phishing attacks. Only two domains, and two VeriSign certificates were compromised in the attacks identified by Symantec, which targeted seven different brands.

"This activity falls well within the normal variability you would see on a very infrequent occurrence," said Tim Callan, a product marketing executive for VeriSign's SSL business unit. "If these were the results of a coin flip, with heads yielding 1 and tails yielding 0, we wouldn't be surprised to see this sequence at all, and certainly wouldn't conclude that there's any upward trend towards heads coming up on the coin."

Well, we hope that nobody's head is flipped in an unsurprising fashion....

It remains to be seen whether this makes any difference. I must admit, I check the green bar on my browser when online-banking, but annoyingly it makes me click to see who signed it. For real users, Firefox says that it is the website, and this is wrong and annoying, but Mozilla has not shown itself adept at understanding the legal and business side of security. I've heard Safari has been fixed up so probably time to try that again and report sometime.

Then, over to Germany, where a snafu with a HSM ("high security module") caused a root key to be lost (also in German). Over in the crypto lists, there are PKI opponents pointing out how this means it doesn't work, and there are PKI proponents pointing out how they should have employed better consultants. Both sides are right of course, so what to conclude?

Test runs with Germany's first-generation electronic health cards and doctors' "health professional cards" have suffered a serious setback. After the failure of a hardware security module (HSM) holding the private keys for the root Certificate Authority (root CA) for the first-generation cards, it emerged that the data had not been backed up. Consequently, if additional new cards are required for field testing, all of the cards previously produced for the tests will have to be replaced, because a new root CA will have to be generated. ... Besides its use in authentication, the root CA is also important for card withdrawal (the revocation service).

The first thing to realise was that this was a test rollout and not the real thing. So the test discovered a major weakness; in that sense it is successful, albeit highly embarrassing because it reached the press.

The second thing is the HSM issue. As we know, PKI is constructed as a hierarchy, or a tree. At the root of the tree is the root key of course. If this breaks, everything else collapses.

Hence there is a terrible fear of the root breaking. This feeds into the wishes of suppliers of high security modules, who make hardware that protect the root from being stolen. But, in this case, the HSM broke, and there was no backup. So a protection for one fear -- theft -- resulted in a vulnerability to another fear -- data loss.

A moment's thought and we realise that the HSM has to have a backup. Which has to be at least as good as the HSM. Which means we then have some rather cute conundrums, based on the Alice in Wonderland concept of having one single root except we need multiple single roots... In practice, how do we create the root inside the HSM (for security protection) and get it to another HSM (for recovery protection)?

Serious engineers and architects will be reaching for one word: BRITTLE! And so it is. Yes, it is possible to do this, but only by breaking the hierarchical principle of PKI itself. It is hard to break fundamental principles, and the result is that PKI will always be brittle, the implementations will always have contradictions that are swept under the carpet by the managers, auditors and salesmen. The PKI design is simply not real world engineering, and the only thing that keeps it going is the institutional deadly embrace of governments, standards committees, developers and security companies.

Not the market demand. But, not all has been bad in the PKI world. Actually, since the bottoming out of the dotcom collapse, certs have been on the uptake, and market demand is present albeit not anything beyond compliance-driven. Here comes a minor item of success:

VeriSign, Inc. [SNIP] today reported it has topped the 1 billion mark for daily Online Certificate Status Protocol (OCSP) checks.

[SNIP] A key link in the online security chain, OCSP offers the most timely and efficient way for Web browsers to determine whether a Secure Sockets Layer (SSL) or user certificate is still valid or has been revoked. Generally, when a browser initiates an SSL session, OCSP servers receive a query to check to see if the certificate in use is valid. Likewise, when a user initiates actions such as smartcard logon, VPN access or Web authentication, OCSP servers check the validity of the user certificate that is presented. OSCP servers are operated by Certificate Authorities, and VeriSign is the world's leading Certificate Authority.

[SNIP] VeriSign is the EV SSL Certificate provider of choice for more than 10,000 Internet domain names, representing 74 percent of the entire EV SSL Certificate market worldwide.

(In the above, I've snipped the self-serving marketing and one blatant misrepresentation.)

Certificates are static statements. They can be revoked, but the old design of downloading complete lists of all revocations was not really workable (some CAs ship megabyte-sized lists). We now have a new thing whereby if you are in possession of a certificate, you can do an online check of its status, called OCSP.

The fundamental problem with this, and the reason why it took the industry so long to get around to making revocation a real-time thing, is that once you have that architecture in place, you no longer need certificates. If you know the website, you simply go to a trusted provider and get the public key. The problem with this approach is that it doesn't allow the CA business to sell certificates to web site owners. As it lacks any business model for CAs, the CAs will fight it tooth & nail.

Just another conundrum from the office of security Kafkaism.

Here's another one, this time from the world of code signing. The idea is that updates and plugins can be sent to you with a digital signature. This means variously that the code is good and won't hurt you, or someone knows who the attacker is, and you can't hurt him. Whatever it means, developers put great store in the apparent ability of the digital signature to protect themselves from something or other.

But it doesn't work with Blackberry users. Allegedly, a Blackberry provider sent a signed code update to all users in United Arab Emirates:

Yesterday it was reported by various media outlets that a recent BlackBerry software update from Etisalat (a UAE-based carrier) contained spyware that would intercept emails and text messages and send copies to a central Etisalat server. We decided to take a look to find out more.

...
Whenever a message is received on the device, the Recv class first inspects it to determine if it contains an embedded command — more on this later. If not, it UTF-8 encodes the message, GZIPs it, AES encrypts it using a static key (”EtisalatIsAProviderForBlackBerry”), and Base64 encodes the result. It then adds this bundle to a transmit queue. The main app polls this queue every five seconds using a Timer, and when there are items in the queue to transmit, it calls this function to forward the message to a hardcoded server via HTTP (see below). The call to http.sendData() simply constructs the POST request and sends it over the wire with the proper headers.

Oops! A signed spyware from the provider that copies all your private email and sends it to a server. Sounds simple, but there's a gotcha...

The most alarming part about this whole situation is that people only noticed the malware because it was draining their batteries. The server receiving the initial registration packets (i.e. “Here I am, software is installed!”) got overloaded. Devices kept trying to connect every five seconds to empty the outbound message queue, thereby causing a battery drain. Some people were reporting on official BlackBerry forums that their batteries were being depleted from full charge in as little as half an hour.

So, even though the spyware provider had a way to turn it on and off:

It doesn’t seem to execute arbitrary commands, just packages up device information such as IMEI, IMSI, phone number, etc. and sends it back to the central server, the same way it does for received messages. It also provides a way to remotely enable/disable the spyware itself using the commands “start” and “stop”.

There was something wrong with the design, and everyone's blackberry went mad. Two points: if you want to spy on your own customers, be careful, and test it. Get quality engineers on to that part, because you are perverting a brittle design, and that is tricky stuff.

Second point. If you want to control a large portion of the population who has these devices, the centralised hierarchy of PKI and its one root to bind them all principle would seem to be perfectly designed. Nobody can control it except the center, which puts you in charge. In this case, the center can use its powerful code-signing abilities to deliver whatever you trust to it. (You trust what it tells you to trust, of course.)

Which has led some wits to label the CAs as centralised vulnerability partners. Which is odd, because some organisations that should know better than to outsource the keys to their security continue to do so.

But who cares, as long as the work flows for the consultants, the committees, the HSM providers and the CAs?

We don't fear no black swan!

Over on EC, Adam does a presentation on his new book, co-authored with Andrew Stewart. AFAICS, the basic message in the book is "security sucks, we better start again." Right, no argument there.

Curiously, he's also experimenting with Twitter in the presentations as a "silent" form of interaction (more. It is rather poignant to mix twitter and security, but I generally like these experiments. The grey hairs don't understand this new stuff, and they have to find out somehow. Somehow and sometime, the only question is whether we are the dinosours or the mammals.

Reading through the quotes (standard stuff) I came across this one, unattributed:

I was pretty dismissive of "Black Swan" hype. I stand by that, and don't think we should allow fear of a black swan out there somewhere to prevent us from studying white ones and generalizing about what we can see.

OK, we just saw the Black Swan over on the finance scene, where Wall Street is now turning into Rubble Alley. Why not on the net? Black swans are a name for those areas where our numbers are garbage and our formulas have an occasional tendency (say 1%) to blow up.

Here's why there are no black swans on the net, for my money: there is no unified approach to security. Indeed, there isn't much or anything of security. There are tiny fights by tiny schools, but these are unadopted by the majority. Although there are a million certs out there, they play no real part in the security models of the users. A million OpenPGP keys are used for collecting signatures, not for securing data. Although there are hundreds of millions of lines of security code out there, now including fresh new Vista!, they are mostly ignored or bypassed or turned off or any other of the many Kerckhoffsian modes of failure.

The vast majority of the net is insecure. We ain't got no security, we don't fear no black swan. We're about as low as we can get. If I look at the most successful security product of all time, Skype, it's showing around 10 million users right now. Facebook, Myspace, youtube, google, you name them, they *all* do an order of magnitude better than Skype's ugly duckling waddle.

Why is the state of security so dire? Well, we could ask the DHS. Now, these guys are probably authoritive in at least a negative sense, because they actually were supposed to secure the USA government infrastructure. Here's what one guy says, thanks to Todd who passed this on:

The official in charge of coordinating the U.S. government's cybersecurity operations has quit, saying the expanding control of the National Security Agency over the nation's computer security efforts poses "threats to our democratic processes."

"Even from a security standpoint," Rod Beckstrom, the head of the Department of Homeland Security's National Cyber Security Center, told United Press International, "it is unwise to hand over the security of all government networks to a single organization."

"If our founding fathers were taking part in this debate (about the future organization of the government's cybersecurity activities) there is no doubt in my mind they would support a separation of security powers among different (government) organizations, in line with their commitment to checks and balances."

In a letter to Homeland Security Secretary Janet Napolitano last week, Beckstrom said the NSA "dominates most national cyber efforts" and "effectively controls DHS cyber efforts through detailees, technology insertions and the proposed move" of the NCSC to an NSA facility at the agency's Fort Meade, Md., headquarters.

It's called "the equity debate" for reasons obscure. Basically, the mission of the NSA is to breach our security. The theory has it that the NSA did this (partly) by ensuring that our security -- the security of the entire net -- was flaky enough for them to get in. Now we all pay the price, as the somewhat slower but more incisive criminal economy takes its tax.

Quite how we get from that above NSA mission to where we are now is a rather long walk, and to be fair, the evidence is a bit scattered and tenuous. Unsurprisingly, and the above resignation does not quite "spill the beans," thus preserving the beanholder's good name. But it is certainly good to see someone come out and say, these guys are ruining the party for all of us.

What's missing in security: business

Those of us who are impacted by the world of security suffer under a sort of love-hate relationship with the word; so much of it is how we build applications, but so much of what is labelled security out there in the rest of the world is utter garbage.

So we tend to spend a lot of our time reverse-engineering popular security thought and finding the security bugs in it. I think I've found another one. Consider this very concise and clear description from Frank Stajano, who has published a draft book section seeking comments:

The viewpoint we shall adopt here, which I believe is the only one leading to robust system security engineering, is that security is essentially risk management. In the context of an adversarial situation, and from the viewpoint of the defender, we identify assets (things you want to protect, e.g. the collection of magazines under your bed), threats (bad things that might happen, e.g. someone stealing those magazines), vulnerabilities (weaknesses that might facilitate the occurrence of a threat, e.g. the fact that you rarely close the bedroom window when you go out), attacks (ways a threat can be made to happen, e.g. coming in through the open window and stealing the magazines—as well as, for good measure, that nice new four-wheel suitcase of yours to carry them away with) and risks (the expected loss caused by each attack, corresponding to the value of the asset involved times the probability that the attack will occur). Then we identify suitable safeguards (a priori defences, e.g. welding steel bars across the window to prevent break-ins) and countermeasures (a posteriori defences, e.g. welding steel bars to the window after a break-in has actually occurred4 , or calling the police). Finally, we implement the defences that are still worth implementing after evaluating their effectiveness and comparing their (certain) cost with the (uncertain) risk they mitigate5

(my emphasies.) That's a good description of how the classical security world sees it. We start by saying, "What's your threat model?" Then out of that we build a security model to deal with those threats. The security model then incorporates some knowledge of risks to manage the tradeoffs.

The bit that's missing is the business. Instead of asking "What's your threat model?" as the first question, it should be "What's your business model?" Security asks that last, and only partly, by asking questions like "what's are the risks?"

Calling security "risk management" then is a sort of nod to the point that security has a purpose within business; and by focussing on some risks, this allows the security modellists to preserve their existing model while tying it to the business. But it is still backwards; it is still seeking to add risks at the end, and will still result in "security" being just the annoying monkey on the back.

Instead, the first question should be "What's your business model?"

This unfortunately opens Pandora's box, because that implies that we can understand a business model. Assuming it is the case that your CISO understands a business model, it does rather imply that the only security we should be pushing is that which is from within. From inside the business, that is. The job of the security people is not therefore to teach and build security models, but to improve the abilities of the business people to incorporate good security as they are doing their business.

Which perhaps brings us full circle to the popular claim that the best security is that which is built in from the beginning.

Security is a subset of Reliability

From the "articles I wish I'd written" department, Chandler points to an article by Daniels Geer & Conway on all the ways security is really a subset of reliability. Of course!

I think this is why the best engineers who've done great security things start from the top; from the customer, the product, the market. They know that in order to secure something, they had better know what the something is before even attempting to add a cryptosec layer over it.

Which is to say, security cannot be a separate discipline. It can be a separate theory, a bit like statics is a theory from civil engineering, or triage is a part of medicine. You might study it in University, but you don't get a job in it; every practitioner needs some basic security. If you are a specialist in security, your job is more or less to teach it to practitioners. The alternate is to ask the practitioners to teach you about the product, which doesn't seem sensible.

Unwinding secrecy -- how to do it?

The next question on unwinding secrecy is how to actually do it. It isn't as trivial as it sounds. Perhaps this is because the concept of "need-to-know" is so well embedded in the systems and managerial DNA that it takes a long time to root it out.

At LISA I was asked how to do this; but I don't have much of an answer. Here's what I have observed:

• Do a little at a time.
• Pick a small area and start re-organising it. Choose an area where there is lots of frustration and lots of people to help. Open it up by doing something like a wiki, and work the information. It will take a lot of work and pushing by yourself, mostly because people won't know what you are doing or why (even if you tell them).
• What is needed is a success. That is, a previously secret area is opened up, and as a result, good work gets done that was otherwise inhibited. People need to see the end-to-end journey in order to appreciate the message. (And, obviously, it should be clear at the end of it that you don't need the secrecy as much as you thought.)
• Whenever some story comes out about a successful opening of secrecy, spread it around. The story probably isn't relevant to your organisation, but it gets people thinking about the concept. E.g., that which I posted recently was done to get people thinking. Another from Chandler.
• Whenever there is a success on openness inside your organisation, help to make this a showcase (here are three). Take the story and spread it around; explain how the openness made it possible.
• When some decision comes up about "and this must be kept secret," discuss it. Challenge it, make it prove itself. Remind people that we are an open organisation and there is benefit in treating all as open as possible.
• Get a top-level decision that "we are open." Make it broad, make it serious, and incorporate the exceptions. "No, we really are open; all of our processes are open except when a specific exception is argued for, and that must be documented and open!" Once this is done, from top-level, you can remind people in any discussion. This might take years to get, so have a copy of a resolution in your back pocket for a moment when suddenly, the board is faced with it, and minded to pass a broad, sweeping decision.
• Use phrases like "security-by-obscurity." Normally, I am not a fan of these as they are very often wrongly used; so-called security-by-obscurity often tans the behinds of supposed open standards models. But it is a useful catchphrase if it causes the listener to challenge the obscure security benefits of secrecy.
• Create an opening protocol. Here's an idea I have seen: when someone comes across a secret document (generally after much discussion ...) that should not have been kept secret, let them engage in the Opening-Up Protocol without any further ado. Instead of grumbling or asking, put the ball in their court. Flip it around, and take the default as to be open:

  "I can't see why document X is secret, it seems wrong. Therefore, in 1 month, I intend to publish it. If there is any real reason, let me know before then."

  This protocol avoids the endless discussions as to why and whether.

Well, that's what I have thought about so far. I am sure there is more.

Unwinding secrecy -- busting the covert attack

Have a read of this. Quick summary: Altimo thinks Telenor may be using espionage tactics to cause problems.

Altimo alleges the interception of emails and tapping of telephone calls, surveillance of executives and shareholders, and payments to journalists to write damaging articles.

So instead of getting its knickers in a knot (court case or whatever) Altimo simply writes to Telenor and suggests that this is going on, and asks for confirmation that they know nothing about it, do not endorse it, etc.

Who ya bluffin?

...Andrei Kosogov, Altimo's chairman, wrote an open letter to Telenor's chairman, Harald Norvik, asking him to explain what Telenor's role has been and "what activity your agents have directed at Altimo". He said that he was "reluctant to believe" that Mr Norvik or his colleagues would have sanctioned any of the activities complained of.

.... Mr Kosogov said he first wrote to Telenor in October asking if the company knew of the alleged campaign, but received no reply. In yesterday's letter to Mr Norvik, Mr Kosogov writes: "We would welcome your reassurance that Telenor's future dealings with Altimo will be conducted within a legal and ethical framework."

Think about it: This open disclosure locks down Telenor completely. It draws a firm line in time, as also, gives Telenor a face-saving way to back out of any "exuberance" it might have previously "endorsed." If indeed Telenor does not take this chance to stop the activity, it would be negligent. If it is later found out that Telenor's board of directors knew, then it becomes a slam-dunk in court. And, if Telenor is indeed innocent of any action, it engages them in the fight to also chase the perpetrator. The bluff is called, as it were.

This is good use of game theory. Note also that the Advisory Board of Altimo includes some high-powered people:

Evidence of an alleged campaign was contained in documents sent to each member of Altimo's advisory board some time before October. The board is chaired by ex-GCHQ director Sir Francis Richards, and includes Lord Hurd, a former UK Foreign Secretary, and Sir Julian Horn-Smith, a founder of Vodafone.

We could speculate that those players -- the spooks and mandarins -- know how powerful open disclosure is in locking down the options of nefarious players. A salutory lesson!

Unwinding secrecy -- how far?

One of the things that I've gradually come to believe in is that secrecy in anything is more likely to be a danger to you and yours than a help. The reasons for this are many, but include:

• hard to get anything done
• your attacker laughs!
• ideal cover for laziness, a mess or incompetence

There are no good reasons for secrecy, only less bad ones. If we accept that proposition, and start unwinding the secrecy so common in organisations today, there appear to be two questions: how far to open up, and how do we do it?

How far to open up appears to be a personal-organisational issue, and perhaps the easiest thing to do is to look at some examples. I've seen three in recent days which I'd like to share.

First the Intelligence agencies: in the USA, they are now winding back the concept of "need-to-know" and replacing it with "responsibility-to-share".

Implementing Intellipedia Within a "Need to Know" Culture

Sean Dennehy, Chief of Intellipedia Development, Directorate of Intelligence, U.S. Central Intelligence Agency

Sean will share the technical and cultural changes underway at the CIA involving the adoption of wikis, blogs, and social bookmarking tools. In 2005, Dr. Calvin Andrus published The Wiki and The Blog: Toward a Complex Adaptive Intelligence Community. Three years later, a vibrant and rapidly growing community has transformed how the CIA aggregates, communicates, and organizes intelligence information. These tools are being used to improve information sharing across the U.S. intelligence community by moving information out of traditional channels.

The way they are doing this is to run a community-wide suite of social network tools: blogs, wikis, youtube-copies, etc. The access is controlled at the session level by the username/password/TLS and at the person level by sponsoring. That latter means that even contractors can be sponsored in to access the tools, and all sorts of people in the field can contribute directly to the collection of information.

The big problem that this switch has is that not only is intelligence information controlled by "need to know" but also it is controlled in horizontal layers. For same of this discussion, there are three: TOP SECRET / SECRET / UNCLASSIFIED-CONTROLLED. The intel community's solution to this is to have 3 separate networks in parallel, one for each, and to control access to each of these. So in effect, contractors might be easily sponsored into the lowest level, but less likely in the others.

What happens in practice? The best coverage is found in the network that has the largest number of people, which of course is the lowest, UNCLASSIFIED-CONTROLLED network. So, regardless of the intention, most of the good stuff is found in there, and where higher layer stuff adds value, there are little pointers embedded to how to find it.

In a nutshell, the result is that anyone who is "in" can see most everything, and modify everything. Anyone who is "out" cannot. Hence, a spectacular success if the mission was to share; it seems so obvious that one wonders why they didn't do it before.

As it turns out, the second example is quite similar: Google. A couple of chaps from there explained to me around the dinner table that the process is basically this: everyone inside google can talk about any project to any other insider. But, one should not talk about projects to outsiders (presumably there are some exceptions). It seems that SEC (Securities and Exchange Commission in USA) provisions for a public corporation lead to some sensitivity, and rather than try and stop the internal discussion, google chose to make it very simple and draw a boundary at the obvious place.

The third example is CAcert. In order to deal with various issues, the Board chose to take it totally open last year. This means that all the decisions, all the strategies, all the processes should be published and discussable to all. Some things aren't out there, but they should be; if an exception is needed it must be argued and put into policies.

The curious thing is why CAcert did not choose to set a boundary at some point, like google and the intelligence agencies. Unlike google, there is no regulator to say "you must not reveal inside info of financial import." Unlike the CIA, CAcert is not engaging in a war with an enemy where the bad guys might be tipped off to some secret mission.

However, CAcert does have other problems, and it has one problem that tips it in the balance of total disclosure: the presence of valuable and tempting privacy assets. These seem to attract a steady stream of interested parties, and some of these parties are after private gain. I have now counted 4 attempts to do this in my time related to CAcert, and although each had their interesting differences, they each in their own way sought to employ CAcert's natural secrecy to own advantage. From a commercial perspective, this was fairly obvious as the interested parties sought to keep their negotiations confidential, and this allowed them to pursue the sales process and sell the insiders without wiser heads putting a stop to it. To the extent that there are incentives for various agencies to insert different agendas into the inner core, then the CA needs a way to manage that process.

How to defend against that? Well, one way is to let the enemy of your enemy know who we are talking to. Let's take a benign example which happened (sort of): a USB security stick manufacturer might want to ship extra stuff like CAcert's roots on the stick. Does he want the negotiations to be private because other competitors might deal for equal access, or does he want it private because wiser heads will figure out that he is really after CAcert's customer list? CAcert might care more about one than they other, but they are both threats to someone. As the managers aren't smart enough to see every angle, every time, they need help. One defence is many eyeballs and this is something that CAcert does have available to it. Perhaps if sufficient info of the emerging deal is published, then the rest of the community can figure it out. Perhaps, if the enemy's enemy notices what is going on, he can explain the tactic.

A more poignant example might be someone seeking to pervert the systems and get some false certificates issued. In order to deal with those, CAcert's evolving Security Manual says all conflicts of interest have to be declared broadly and in advance, so that we can all mull over them and watch for how these might be a problem. This serves up a dilemma to the secret attacker: either keep private and lie, and risk exposure later on, or tell all upfront and lose the element of surprise.

This method, if adopted, would involve sacrifices. It means that any agency that is looking to impact the systems is encouraged to open up, and this really puts the finger on them: are they trying to help us or themselves? Also, it means that all people in critical roles might have to sacrifice their privacy. This latter sacrifice, if made, is to preserve the privacy of others, and it is the greater for it.

What happened in security over the last 10 years?

I keep having the same discussion in various places, and keep coming back to this eloquent description of where we are:

Gunnar's full blog post is here ... it includes some other things, but nothing quite so poignant.

Web Security hasn't moved since 1995. Oh well.

Browser Security UI: the horns of the dilemma

One of the dilemmas that the browser security UI people have is that they have to deal with two different groups at the same time. One is the people who can work with the browser and the other is those who blindly click when told to. The security system known as secure browsing seems to be designed for both groups at the same time, thus leading to bad results. For example, Dan Kaminsky counted another scalp when finding back in April that ISPs are doing MITMs on their customers:

The rub comes when a user is asking for a nonexistent subdomain of a real website, such as http://webmale.google.com, where the subdomain webmale doesn't exist (unlike, say, mail in mail.google.com). In this case, the Earthlink/Barefruit ads appear in the browser, while the title bar suggests that it's the official Google site.

As a result, all those subdomains are only as secure as Barefruit's servers, which turned out to be not very secure at all. Barefruit neglected basic web programming techniques, making its servers vulnerable to a malicious JavaScript attack. That meant hackers could have crafted special links to unused subdomains of legitimate websites that, when visited, would serve any content the attacker wanted.

The hacker could, for example, send spam e-mails to Earthlink subscribers with a link to a webpage on money.paypal.com. Visiting that link would take the victim to the hacker's site, and it would look as though they were on a real PayPal page.

That's a subtle attack, one which the techies can understand but the ordinary users cannot. Here's a simpler one (hat-tip to Duane), a straight phish:

Dear Wilmington Trust Banking Member,

Due to the high number of fraud attempts and phishing scams, it has been decided to implement EV SSL Certification on this Internet Banking website.

The use of EV SSL certification works with high security Web browsers to clearly identify whether the site belongs to the company or is another site imitating that company’s site.

It has been introduced to protect our clients against phishing and other online fraudulent activities. Since most Internet related crimes rely on false identity, WTDirect went through a rigorous validation process that meets the Extended Validation guidelines.

Please Update your account to the new EV SSL certification by Clicking here.

Please enter your User ID and Password and then click Go.

(Failure to verify account details correctly will lead to account suspension)

This is a phish email seen in the wild. We here -- the techies -- all know what's wrong with this attack, but can you explain it to your grandma? What is being attacked here here is the brand of EV rather than the technology. In effect, the more ads that relate EV to security in a simplistic fashion, the better this attack works.

To evade this, the banks have to promote better practices amongst their clients, and they have to include the user into the protocol. But they are not being helped, it seems.

On the one hand, a commonly held belief with the security developers is that the user cannot be bothered with security, ignore any attempts, and therefore it is best to not bother them with it. Much as I like the mantra of "there is only one mode, and it is secure," it isn't going to work in the web case unless we do the impossible: drop HTTP and make HTTPS mandatory, solve the browser universality issue (note chrome's efforts), and unify the security models end-to-end. As the group of Internet people who can follow that is vanishingly small, this is a non-starter.

On the other not-so-helpful hand, the pushers of certificates often find themselves caught between the horns of pushing more product (at a higher price) and providing the basic needs of the customers. I recently came across two cases at both extremes of the market: at the unpaid end of the market, the ability of a company to conveniently populate 50,000 desktops is, it is claimed, more important than meeting expectations about verification of contents. The problem with this approach is if people see strong expectations on one side, and casual promises on another equivalent side, the entire brand suffers.

And, at the expensive EV extreme of the market, the desire to sell a product can sometimes lead to exaggerated claims, as seen in a recent advertisement, seen above (hat-tip to Philipp). This advert in the German paper press includes perhaps over-broad or over-high claims. Translating from German to English as:

The latest and best in terms of online security. And also the greens.

Visible security for your site from a company where your customers trust.

It is quite simple: a green address bar means that your site is secure.

These claims are easy to make, and they may help sell certs. But they also help the above phishing attack, as they clearly make simple connections between security and EV.

"EV means security, gotta get me some of that! Click!" FTR, check the translator.

What would be somewhat more productive than sweeping marketing claims is to decide what it is that the green thing really meant.

I have heard one easy answer: EV means whatever the CA/Browser Forum Guidelines says it means. OK, but not so fast: I do not recall that it said anywhere that your site has to be secure! I admit to not having read it for a while, but the above advert seems entirely at odds with a certificate claim.

Further, because that document is long and involved, something clearer and shorter would be useful if there are any pretensions in saying anything to customers.

If you don't want to say anything to customers, then the Guidelines are fine. But then, what is the point of certs?

The above is just about EV, but that's just a foil for the wider problem: no CA makes this easy, as yet. I believe it to be an important task for certificate authorities to come up with a simple claim that they can make to users. Something clear, something a user can take to court.

Indeed, it would be good for all CAs and all browsers to have their claims clearly presented to users, as the users are being told that there is a benefit. To them. Frequently, for years and years now. And now they are at risk, both of losing that benefit and because of that benefit.

What is that benefit? Can you show it? Can you state it? Can you present it to your grandma? And, will you stand behind her, in court, and explain it to the judge?

Builders v. Breakers

Gunnar lauds a post on why there are few architects in the security world:

Superb post by Mark on what I think is the biggest problem we have in security. One thing you learn in consulting is that no matter what anyone tells you when you start a project about what problem you are trying to solve, it is always a people problem. The single biggest problem in security is too many breakers not enough builders. Please understand I am not saying that breakers are not useful, we need them, and we need them to continue to get better so we can build more resilient systems. But the industry is about 90% breaking and 10% building and that's plain bad.

It’s still predominantly made up of an army of skilled hackers focused on better ways to break systems apart and find new ways to exploit vulnerabilities than “security architects” who are designing secure components, protocols and ultimately secure systems.

Hear hear! And why is this? One easy answer: breaking something is a solid metric. It's either broken or not, in general. Any journo can understand it.

On the other hand, building it is too difficult a signal. There is no easy number, there is no binary result. It takes a business focus over decades to understand that one architecture delivers more profits for users and corporates alike than another, and by then, the architects have moved on, so even, then the result may not be clear.

Let's take an old example. Back around 1996, a couple of bored uni students cracked Netscape's secure browsing. The first time was by crunching the 40 bit crypto using the idle lab computers, and the second time was by predicting the less-than-random numbers injected into the protocol. These students were lauded in the press for having done something grand.

They then went on to a much harder task, and were almost never heard of again. What was that harder task? Building secure and usable systems. One of them tried to build a secure communications platform, another is trying to build a secure computing platform. So far, they have not succeeded at either task, but these are much harder tasks.

The true heroes back in the mid-1990s were the Netscape engineers who got something going and delivered it to the public, not the kids who scratched the paint off it. The breaches mentioned above were jokes, and bad ones at that, because they distracted attention on what was really being built. Case in point, is that, even today, if we had twice as much 40 bit crypto as we do 128 bit crypto, we'd probably be twice as secure, because the attack of relevance simply isn't the bored uni student, it is the patient phisher.

If you recall names in this story, recall them for what they tried to build, and not for what they broke.

Macs for security (now, with new improved NSA hardening tips!)

Frequent browsers will recall that the top tip number 1 for every user out there is to buy a Mac. That's for several reasons:

• the security engineering is solid, based on a long history of around 15 years of security programming tradition in Unix
• Apple have also maintained a security tradition, from well before OSX
• it remains a "smaller market share" so benefits from the monoculture bounty

Now there is another reason: hardening tips from the NSA (or here with disclaimers).

Well, this isn't exactly a reason but more a bonus (likely there is a hardening tips for other popular operating systems as well). However, it is a useful resource for those people who really want more than a standard user install, without the compromises!

(Note, many of the hardening tips are beyond normal users, so seek experienced advice before following them slavishly.)

Yet more evidence: your CISO needs an MBA

I have in the past presented the strawman that your CISO needs an MBA. Nobody has yet succeeded in knocking it down, and it is proving surprisingly resilient. Yet more evidence comes from Bruce Schneier's blog post of yesterday:

Return on investment, or ROI, is a big deal in business. Any business venture needs to demonstrate a positive return on investment, and a good one at that, in order to be viable.

It's become a big deal in IT security, too. Many corporate customers are demanding ROI models to demonstrate that a particular security investment pays off. And in response, vendors are providing ROI models that demonstrate how their particular security solution provides the best return on investment.

It's a good idea in theory, but it's mostly bunk in practice.

Bunk is wrong. Let's drill down. It works this way: NPV (net present value) and ROI (its lesser cousin) are a mathematical tool for choosing between alternate projects. Keep the notion of comparison tightly in your mind.

The tools measure the money going in versus the money going out in a neutral way. They are entirely neutral between projects because NPV is just mathematics, and the same mathematics is used for each project. (See the top part of Richard's post.)

Obviously, any result from the model depends totally on the inputs, so there is a great deal of care and theory needed supply those proper inputs. And, it is here that security projects have the trouble, in that we don't have a good view as to how to predict attack costs. To be clear, there is no controversy about the inputs being a big problem.

But, assuming we have the theory, the process and the inputs, we can, again in principle, measure fairly across all projects.

That's how it works. As you can see above, we do not make a distinction between investment, savings, costs, returns or profits. Why not? Because NPV model and the numbers don't, either.

What then goes wrong with security people when they say ROI doesn't apply to security?

Before I get into the details, there's one point I have to make. "ROI" as used in a security context is inaccurate. Security is not an investment that provides a return, like a new factory or a financial instrument. It's an expense that, hopefully, pays for itself in cost savings. Security is about loss prevention, not about earnings. The term just doesn't make sense in this context.

Or, or here:

The bottom line is that security saves money; it does not create money.

It seems to be that they seize on the words investment and returns, etc, and realise that the words differ from costs and savings. In conceptual or balance sheet terms, they do differ, but here's the catch: to the models of NPV and ROI, it's all the same. In this sense, we could say that the title of ROI is a misnomer, or that there are several meanings to the word "investment" and you've seized on the wrong one.

If you are good at maths, consider it as simply a model that deals equally well with negative numbers as well as positive numbers. To a model, savings are just negatives of returns.

Now, if your security director had an MBA, she would know that the purpose of NPV is to compare projects, and not anything else, like generating returns. She would also know that the model is neutral, and that the ability to handle negative numbers mean that expenses and savings can be compared as well. She would further know that the problems occur in the inputs and assumptions, not in the model.

Finally, she would know how to speak in the language of finance, which is the language that the finance people use. This might sound obvious, but it isn't so clear. As a generalism, it is this last point that is probably most significant about the MBA concept: it teaches you the language of all the other specialities. It doesn't necessarily make you a whizz at finance, or human resources, or marketing. But it at least lets you talk to them in their language. And, it reminds you that the other professions do have some credibility, so if they say something, listen first before teaching them how to suck eggs.

Should a security professional have a legal background?

Graeme points to this entry that posits that security people need a legal background:

My own experience and talking to colleagues has prompted me to wonder whether the day has arrived that security professionals will need a legal background. The information security management professional is under increasing pressure to cope with the demands of the organization for access to information, to manage the expectations of the data owner on how and where the information is going to be processed and to adhere to regulatory and legal requirements for the data protection and archiving. In 2008, a number of rogue trader and tax evasion cases in the financial sector have heightened this pressure to manage data.

The short, sharp answer is no, but it is a little more nuanced than that. First, let's take the rogue trader issue, being someone who has breached the separation of roles within a trading company, and used it to bad effect. To spot and understand this requires two things: an understanding of how settlement works, and the principle of dual control. It does not require the law, at all. Indeed, the legal position of someone who has breached the separation, and has "followed instructions to make a lot of money" is a very difficult subject. Suffice to say, studying the law here will not help.

Secondly, asking security people to study law so as to deal with tax evasion is equally fruitless but for different reasons: it is simply too hard to understand, it is less law than an everlasting pitched battle between the opposing camps.

Another way of looking at this is to look at the FC7 thesis, which says that, in order to be an architect in financial cryptography, you need to be comfortable with cryptography, software engineering, rights, accounting, governance, value and finance. The point is not whether law is in there or not, but that there are an awful lot of important things that architects or security directors need before they need law.

Still, an understanding of the law is no bad thing. I've found several circumstances where it has been very useful to me and people I know:

• Contract law underpins the Ricardian contract.
• Dispute resolution underpins the arbitration systems used in sensitive communities (such as WebMoney and CAcert).
• The ICANN dispute system might have an experienced and realises that touching domains registries can do grave harm. In the alternate, a jurist looking at the system will not come to that conclusion at all.

In this case, the law knowledge helps a lot. Another area which is becoming more and more an issue is that of electronic evidence. As most evidence is now entering the digital domain (80% was a recent unreferenced claim) there is much to understand here, and much that one can do to save ones company. The problem with this, as lamented at the recent conference, is that any formal course of law includes nothing on electronic evidence. For that, you have to turn to books like those by Stephen Mason on Electronic Evidence. But that you can do yourself.

wheretofore Vista? Microsoft moves to deal with the end of the Windows franchise

Since the famous Bill Gates Memo, around the same time as phishing and related frauds went institutional, Microsoft has switched around to deal with the devil within: security. In so doing, it has done what others should have done, and done it well. However, there was always going to be a problem with turning the super-tanker called Windows into a battleship.

I predicted a while back that (a) Vista would probably fail to make a difference, and (b) the next step was to start thinking of a new operating system. This wasn't the normal pique, but the cold-hearted analysis of the size of the task. If you work for 20 years making your OS easy but insecure, you don't have much chance of fixing that, even with the resources of Microsoft.

The Economist brings an update on both points. Firstly, on Vista's record after 18 months in the market:

To date, some 140m copies of Vista have been shipped compared with the 750m or more copies of XP in daily use. But the bulk of the Vista sales have been OEM copies that came pre-installed on computers when they were bought. Anyone wanting a PC without Vista had to order it specially.

Meanwhile, few corporate customers have bought upgrade licences they would need to convert their existing PCs to Vista. Overwhelmingly, Windows users have stuck with XP.

Even Microsoft now seems to accept that Vista is never going to be a blockbuster like XP, and is hurrying out a slimmed-down tweak of Vista known internally as Windows 7. This Vista lite is now expected late next year instead of 2010 or 2011.

It's not as though Vista is a dud. Compared with XP, its kernel—the core component that handles all the communication between the memory, processor and input and output devices—is far better protected from malware and misuse. And, in principle, Vista has better tools for networking. All told, its design is a definite improvement—albeit an incremental one—over XP.

Microsoft tried and failed to turn it around, security+market-wise. We might now be looking at the end of the franchise known as Windows. To be clear, while we are past the peak, any ending is a long way off in the distant future.

Classical strategy thinking says that there are two possible paths here: invest in a new franchise, or go "cash-cow". The latter means that you squeeze the revenues from the old franchise as long as possible, and delay the termination of the franchise as long as possible. The longer you delay the end, the more revenues you get. The reason for doing this is simple: there is no investment strategy that makes money, so you should return the money to the shareholders. There is a simple example here: the music majors are decidedly in cash-cow, today, because they have no better strategy than delaying their death by a thousand file-shares.

Certainly, with Bill Gates easing out, it would be possible to go cash-cow, but of course, we on the outside can only cast our augeries and wonder at the signs. The Economist suggests that they may have taken the investment route:

Judging from recent rumours, that's what it is preparing to do. Even though it won't be in Windows 7, Microsoft is happy to talk about “MinWin”—a slimmed down version of the Windows core. It’s even willing to discus its “Singularity” project—a microkernel-based operating system written strictly for research purposes. But ask about a project code-named “Midori” and everyone clams up.

By all accounts, Midori (Japanese for “green” and, by inference, “go”) capitalises on research done for Singularity. The interesting thing about this hush-hush operating system is that it’s not a research project in the normal sense. It's been moved out of the lab and into incubation, and is being managed by some of the most experienced software gurus in the company.

With only 18 months before Vista is to be replaced, there's no way Midori—which promises nothing less than a total rethink of the whole Windows metaphor—could be ready in time to take its place. But four or five years down the road, Microsoft might just confound its critics and pleasantly surprise the rest of us.

Comment? Even though I predicted Microsoft would go for a new OS, I think this is a tall order. There are two installed bases in the world today, being Unix and Windows. It's been that way for a long time, and efforts to change those two bases have generally failed. Even Apple gave up and went Unix. (The same economics works against the repeated attempts to upgrade the CPU instruction set.)

The flip-side of this is that the two bases are incredibly old and out-of-date. Unix's security model is "ok" but decidedly pre-PC, much of what it does is simply irrelevant to the modern world. For example, all the user-to-user protection is pointless on a one-user-one-PC environment, and the major protection barrier has accidentally become a hack known as TCP/IP, legendary for its inelegant grafting onto Unix. Windows has its own issues.

So we know two things: a redesign is decades over-due. And it won't budge the incumbents; both are likely to live another decade without appreciable change to the markets. We would need a miracle, or better, a killer-app to budge the installed base.

Hence the cold-hearted analysis of cash-cow wins out.

But wait! The warm-blooded humanists won't let that happen for one and only one reason: it is simply too boring to contemplate. Microsoft has so many honest, caring, devoted techies within that if a decision were made to go cash-cow, there would be a mass-defection. So the question then arises, what sort of a hybrid will be acceptable to shareholders and workers? Taking a leaf from recent politics, which is going through a peak-energy-masquerade of its own these days, some form of "green platform" has appeal to both sides of the voting electorate.

DNS rebinding attack/patch: the germination of professional security cooperation?

Lots of chatter is seen in the security places about a patch to DNS coming out. It might be related to Dan's earlier talks, but he also makes a claim that there is something special in this fix. The basic idea is that DNS replies are now on randomised ports (or some such) and this will stop spoofing attempts of some form. You should patch your DNS.

Many are skeptical, and this gives us an exemplary case study of today's "security" industry:

Ptacek: If the fix is “randomize your source ports”, we already knew you were vulnerable. Look, DNS has a 16 bit session ID… how big is an ASPSESSIONID or JSESSIONID? When you get to this point you are way past deck chairs on the titanic, but, I mean, the web people already know this. This is why TLS/SSL totally doesn’t care about the DNS. It is secure regardless of the fact that the DNS is owned.

Paraphrased: "Oh, we knew about that, so what?" As above, much of the chatter in other groups is about how this apparently fixes something that is long known, therefore insert long list of excuses, hand-wringing, slap-downs, and is not important. However, some of the comments are starting to hint at professionalism. Nathan McFeters writes:

I asked Dan what he thought about Thomas Ptacek’s (Thomas Ptacek of Matasano) comments suggesting that the flaw was blown out of proportion and Dan said that the flaw is very real and very serious and that the details will be out at Black Hat. Dan mentioned to me that he was very pleased with how everything has worked with the multi-vendor disclosure process, as he said, “we got several vendors together and it actually worked”. To be honest, this type of collaboration is long overdue, and there’s a lot of folks in the industry asking for it, and I’m not just talking about the tech companies cooperating, several banking and financial companies have discussed forums for knowledge sharing, and of course eBay has tried to pioneer this with their “eBay Red Team” event. It’s refreshing to here a well respected researcher like Dan feeling very positive about an experience with multiple vendors working together (my own experience has been a lot of finger pointing and monkey business).

Getting vendors to work together is quite an achievement. Getting them to work on security at the same time, instead of selling another silver bullet, is extraordinary, and Dan should write a book on that little trick:

Toward addressing the flaw, Kaminsky said the researchers decided to conduct a synchronized, multivendor release and as part of that, Microsoft in its July Patch Tuesday released MS08-037. Cisco, Sun, and Bind are also expected to roll out patches later on Tuesday.

As part of the coordinated release, Art Manion of CERT said vendors with DNS servers have been contacted, and there’s a longer list of additional vendors that have DNS clients. That list includes AT&T, Akamai, Juniper Networks, Inc., Netgear, Nortel, and ZyXEL. Not all of the DNS client vendors have announced patches or updates. Manion also confirmed that other nations with CERTs have also been informed of this vulnerability.

Still, for the most part, the industry remains fully focussed on the enemy within, as exemplified by Ptacek's comment above. I remain convinced that the average "expert" wouldn't recognise a security fix until he's been firmly wacked over the head by it. Perhaps that is what Ptacek was thinking when he allegedly said:

If the IETF would just find a way to embrace TLS/X509 instead griping about how Verisign is out to get us we wouldn’t have this problem. Instead, DNSSEC tried to reinvent TLS by committee… well, surprise surprise, in 2008, we still care about 16 bit session IDs! Go Internet!

Now, I admit to being a long-time supporter of TLS'ing everything (remember, there is only one mode, and it is secure!) but ... just ... Wow! I think this is what psychologists call the battered-wife syndrome; once we've been beaten black and blue with x.509 for long enough, maybe we start thinking that the way to quieten our oppressor down is to let him beat us some more. Yeah, honey, slap me with some more of that x.509 certificate love! Harder, honey, harder, you know I deserve it!

Back to reality, and to underscore that there is something non-obvious about this DNS attack that remains unspoken (have you patched yet?), the above-mentioned commentator switched around 540 degrees and said:

Patch Your (non-DJBDNS) Server Now. Dan Was Right. I Was Wrong.

Thanks to Rich Mogull, Dino and I just got off the phone with Dan Kaminsky. We know what he’s going to say at Black Hat.

What can we say right now?

1. Dan’s got the goods. ...

Redeemed! And, to be absolutely clear as to why this blog lays in with slap after slap, being able to admit a mistake should be the first criteria for any security guy. This puts Thomas way ahead of the rest of them.

Can't say it more clearly than that: have you patched your DNS server yet?

German court finds Bank responsible for malwared PC

Spiegel reports that a German lower court ("Amtsgerichts Wiesloch (Az4C57/08)") has found a bank responsible for malware-driven transactions on a user's PC. In this case, her PC was infected with some form of malware that grabbed the password and presumably a fresh TAN (German one-time number to authenticate a single transaction) and scarfed 4000 euros through an eBay wash.

Unfortunately only in German, and so analysis following is highly limited and unreliable. It appears that the court's logic was that as the transaction was not authenticated by the user, it is the bank's problem.

This seems fairly simple, except that Microsoft Windows-based PCs are difficult to keep clean of malware. In this case, the user had a basic anti-virus program, but that's not enough these days (see top tips on what helps).

We in the security field all knew that, and customers are also increasingly becoming aware of it, but the question the banking and security world is asking itself is whether, why and when the bank is responsible for the user's insecure PC? Shouldn't the user take some of the risk for using an insecure platform?

The answer is no. The risk belongs totally to the bank in this case, in the opinion of the Wiesloch court, and the court of financial cryptography agrees. Consider the old legal principle of putting the responsibility with the party best able to manage it. In this case, the user cannot manage it, manifestly. Further, the security industry knew that the Windows PC was not secure enough for risky transactions, and that Microsoft software was the dominant platform. The banking industry has had this advice in tanker-loads (c.f. EU "Finread"), and in many cases banks have even heeded the advice, only to discard it later. The banking industry decided to go ahead in the face of this advice and deploy online banking for support cost motives. The banks took on this risk, knowing the risk, and knowing that the customer could not manage this risk.

Therefore, the liability falls completely to the bank in the basic circumstances described. In this blog's opinion ! (It might have been different if the user had done something wrong such as participate in a mule wash or had carried on in the face of clear evidence of infection.)

There is some suggestion that the judgment might become a precedent, or not. We shall have to wait and see, but one thing is clear, online banking has a rocky road ahead of it, as the phishing rooster comes home to roost. For contrary example, another case in Cologne (Az: 9S195/07) mentioned in the article put the responsibility for EC-card abuse with the customer. As we know, smart cards can't speak to the user about what they are doing, so again we have to ask what the Windows PC was saying about the smart card's activities. If the courts hold the line that the user is responsible for her EC-card, then this can only cause the user to mistrust her EC-card, potentially leading to yet another failure of an expensive digital signing system.

The costs for online banking are going to rise. A part of any solution, as frequently described by security experts, is to not trust widely deployed Microsoft Windows PCs for online banking, which in effect means PCs in general. A form of protection is fielded in some banks whereby the user's mobile phone is used to authenticate the real transaction over another channel. This is mostly cheap and mostly effective, but it isn't a comprehensive or permanent solution.

H4.2 -- Usability Determines the Number of Users

Last week's discussion (here and here) over how there is only one mode, and it is secure, brought forth the delicious contrast with browsing and security: yes, you can do that but it doesn't work well. No, I'm not talking about the logos being cross-sited, but all of the 100 little flaws that you find when you try and do a website for secure purposes.

So why bother? Financial cryptography eats its own medicine, but it doesn't do it for breakfast, lunch and desert. Which reminds me to introduce another of the sub-hypes for critique:

#4.2 Usability Determines the Number of Users

Ease of use is the most important determinant to the number of users. Ease of implementation is important, ease of incorporation is also important, and even more important is the ease of use by end-users. This reflects a natural subdivision into several classes of users: implementors, integrators and end-users, each class of which can halt the use of the protocol if they find it ... unusable. As they are laid out serially between you and the marketplace, you have to consider usability to all of them.

The protocol should be designed to be easy to code up, so as to help implementors help integrators help users. It should be designed to be easy to interface to, so as to help integrators help users. It should be designed to be easy to configure, so as to help users get security.

If there are any complex or tricky features, ask yourself whether the benefit is really worth the cost of coder's time. It is not that developers cannot do it, it is simply that they will not do it; nobody has all the time in the world, and a protocol that is twice as long to implement is twice as likely to not get done.

Same for integrators of systems. If the complexity provided by the protocol and the implementation causes X amount of work, and another protocol costs only X/2 then there is a big temptation to switch. Regardless of absolute or theoretical security.

Same for users.

The Dutch show us how to make money: Peace and Cash Foundation

Sometime around 3 years back, banks started to respond to phishing efforts by putting in checks and controls to stop people sending money. This led to the emergence of a new business model that promised great returns on investment by arbitraging the controls, and has led to the enrichment of many! Now, my friends in NL have alerted me to the NVB's efforts to sell the Dutch on the possibilities.

A fun few minutes, and even though it is in Dutch, the symbology should be understood. Does anyone have an English translation?

(Okay, you might not see the Peace and Cash Foundation by the time you click on the site, but another generation will be there to help you to well-deserved riches...)

Case study in risk management: Debian's patch to OpenSSL

Ben Laurie blogs that downstream vendors like Debian shouldn't interfere with sensitive code like OpenSSL. Because they might get it wrong... And, in this case they did, and now all Debian + Ubuntu distros have 2-3 years of compromised keys. 1, 2.

Further analysis shows however that the failings are multiple, are at several levels, and they are shared all around. As we identified in 'silver bullets' that fingerpointing is part of the problem, not the solution, so let's work the problem, as professionals, and avoid the blame game.

First the tech problem. OpenSSL has a trick in it that mixed in uninitialised memory with the randomness generated by the OS's formal generator. The standard idea here being that it is good practice to mix in different sources of randomness into your own source. Roughly following the designs from Schneier and Ferguson (Yarrow and Fortuna), modern operating systems take several random things like disk drive activity and net activity and mix the measurements into one pool, then run it through a fast hash to filter it.

What is good practice for the OS is good practice for the application. The reason for this is that in the application, we do not know what the lower layers are doing, and especially we don't really know if they are failing or not. This is OK if it is an unimportant or self-checking thing like reading a directory entry -- it either works or it doesn't -- but it is bad for security programming. Especially, it is bad for those parts where we cannot easily test the result. And, randomness is that special sort of crypto that is very very difficult to test for, because by definition, any number can be random. Hence, in high-security programming, we don't trust the randomness of lower layers, and we mix our own [1].

OpenSSL does this, which is good, but may be doing it poorly. What it (apparently) does is to mix in uninitialised buffers with the OS-supplied randoms, and little else (those who can read the code might confirm this). This is worth something, because there might be some garbage in the uninitialised buffers. The cryptoplumbing trick is to know whether it is worth the effort, and the answer is no: Often, uninitialised buffers are set to zero by lower layers (the compiler, the OS, the hardware), and often, they come from other deterministic places. So for the most part, there is no reasonable likelihood that it will be usefully random, and hence, it takes us too close to von Neumann's famous state of sin.

Secondly, to take this next-to-zero source and mix it in to the good OS source in a complex, undocumented fashion is not a good idea. Complexity is the enemy of security. It is for this reason that people study the designs like Yarrow and Fortuna and implement general purpose PRNGs very carefully, and implement them in a good solid fashion, in clear APIs and files, with "danger, danger" written all over them. We want people to be suspicious, because the very idea is suspicious.

Next. Cryptoplumbing involves by its necessity lots of errors and fixes and patches. So, bug reporting channels are very important, and apparently this was used. Debian team "found" the "bug" with an analysis tool called Valgrind. It was duly reported up to OpenSSL, but the handover was muffed. Let's skip the fingerpointing here, the reason it was muffed was that it wasn't obvious what was going on. And, the reason it wasn't obvious looks like the code was too clever for its own good. It tripped up Valgrind (and Purify), it tripped up the Debian programmers, and the fix did not alert the OpenSSL programmers. Complexity is our enemy, always, in security code.

So what in summary would you do as a risk manager?

1. Listen for signs of complexity and cuteness. Clobber them when you see them.
2. Know which areas of crypto are very hard, and which are "simple". Basically, public keys and random generation are both devilish areas. Block ciphers and hashes are not because they can be properly tested. Tune your alarm bells for sensitivity to the hard areas.
3. If your team has to do something tricky (and we know that randomness is very tricky) then encourage them to do it clearly and openly. Firewall it into its own area: create a special interface, put it in a separate file, and paint "danger, danger" all over it. KISS, which means Keep the Interface Stupidly Simple.
4. If you are dealing in high-security areas, remember that only application security is good enough. Relying on other layers to secure you is only good for medium-level security, as you are susceptible to divide and conquer.
5. Do not distribute your own fixes to someone else's distro. Do an application work-around, and notify upstream. (Or, consider 4. above)
6. These problems will always occur. Tech breaks, get used to it. Hence, a good high-security design always considers what happens when each component fails in its promise. Defence in depth. Systems that fail catastrophically with the failure of one component aren't good systems.
7. Teach your team to work on the problem, not the people. Discourage fingerpointing; shifting the blame is part of the problem, not the solution. Everyone involved is likely smart, so the issues are likely complex, not superficial (if it was that easy, we would have done it).
8. Do not believe in your own superiority. Do not believe in the superiority of others. Worry about people on your team who believe in their own superiority. Get help and work it together. Take your best shot, and then ...
9. If you've made a mistake, own it. That helps others to concentrate on the problem. A lot. In fact, it even helps to falsely own other people's problems, because the important thing is the result.

[1] A practical example is that which Zooko and I did in SDP1 with the initialising vector (IV). We needed different inputs (not random) so we added a counter, the time *and* some random from the OS. This is because we were thinking like developers, and we knew that it was possible for all three to fail in multiple ways. In essence we gambled that at least one of them would work, and if all three failed together then the user deserved to hang.

Phishing faceoff - Firefox 3 v. the market for your account

Dria writes up a fine intro to the new Firefox security UI, the thing that forms the front line for phishing protection.

Basically, the padlock has been replaced with a button that shows a "passport" icon in multiple colours and with explanatory text. Pretty good, although as far as I can see, this means you can no longer *look* and tell what is going on. OK, I'll run with that as an experiment! For now, there are 4 colours: grey, blue, green and yellow. Grey is for no identity, and I guess that also means no TLS although it isn't that clear as encryption edge-cases are not shown. Blue is Good, being the conventional browser security level, and Green is the EV colour for their new enhanced "better than before" identity verification.

One minus: yellow is now a confusing colour. Before it was the colour of success, now it is the colour of failure (although that failure is easily rectified by clicking to add an exception). As I commented before, we do need the colours to be re-aligned after a period of experimentation. Kudos to Firefox team for taking that one on the chin, if only others were prepared to clearly unwind some well-meaning ideas...

Second Minus: As many said in comments, the "invalid identity verification" isn't always that, sometimes it is a non-third-party verification. This needs to be distinguished between "identity not 3rd-party verified" and "self-verified."

Indeed, our old friend, the self-identified or self-signed certificate, is widely used in technical community for local and small scale security systems, so we can see the message "not trusted" and "invalid" are simply wrong. Now, Jonath says that Firefox is planning to do Key Continuity Management, so it may be that the confusing messages get cleaned up then. (I don't know if anyone else has spotted the nexus, but when we take KCM and combine it with 3rd party verifications, sometimes called variously TTP or CVP or certificate authorities, then we get the best of both worlds. It will eventually come, because it is so sensible.)

One Good Plus: the CA is displayed in all cases where the certificate information is available. This is exceedingly important because it is the CA that does the verification of identity; Firefox only repeats it (which is why the "trusted" message is soooo wrong). Slowly but surely, we have to move the browser UI to pin the assertation on the CA, and we have to move the user to thinking about CAs as competing, branded entities that stand behind their statements. Publically. At least, Firefox has not made the mistake that Microsoft has made with the new IE, which displays the name of the authority in some circumstances, but not others.

It is important to realise: we can take a few missteps along the way, such as Gerv's noble attempt with the colour yellow. It is very costly to get these UIs built, trialled and tuned, so any experiments have to be taken with an expectation of more improvement in the future. As long as we're moving forward, things are getting better.

What's all this about? Why is it important? Pop over to Francois' post on stolen accounts to see the real reason:

(Hat tip to Gunnar again.) Them's hard numbers! A quick eyeball calculation over Francois's numbers reveals that the going price of a well-funded account is 8% of the value. This makes some sense, because getting access to the account details is easy, it's done in bulk, given that the security systems of online banks are so fundamentally and hopelessly flawed. What is more difficult is getting the money out, because, since the arisal of phishing, and the sticking of some of the liability, occasionally, to the banks, the online security teams have done some things to make it a little trickier. So the lion's share goes to the money launderer, who needs to pay a lot more in direct costs to get his hard-stolen loot out.

How does this relate to Firefox? Phishing arose as an attack on the browser's security UI, so the Firefox team are working to address that issue with KCM, better displays of the CA name that makes the claim, and more clear symbols. The first 2 images above may help you to avoid the 3rd image.

Unfortunately, the big picture overtook the browser world, so the work is only just starting. Phishing caused massive funds to flow into the attackers, so they invest in any attacks that might return more value. Especially, the attack profile now includes MITM and trojans, so hardening of the browser against inside attacks will be increasingly necessary.

Remember, the threat is on the node, not on the wire; which gives us an answer to the question that Jonath was posing: Hardening against inside attacks should be on the agenda for future Firefox.

Paypal -- Practical Approaches to Phishing -- open white paper

Paypal has released a white paper on their approach to phishing. It is mostly good stuff. Here are their Principles:

1. No Silver Bullet -- We have not identified any one solution that will single-handedly eradicate phishing; nor do we believe one will ever exist. ...

2. Passive Versus Active Users -- When thinking about account security, we observe two distinct types of users among our customers. The first and far more common is the “passive” user. Passive users expect to be kept safe online with virtually no involvement of their own. They will keep their passwords safe, but they do not look for the “s” in https nor will they install special software packages or look for digital certificates. The active user, on the other hand, is the “see it/touch it/use it” person. They want two-factor authentication, along with every other bell and whistle that PayPal or the industry can provide. Our solution would have to differentiate between and address both of these groups.

3. Industry Cooperation -- PayPal has been a popular “target of opportunity” for criminals due to our large account base of over 141 million accounts2 and the nature of our global service. However, while we may be an attractive target, we are far from the only one. Phishing is an industry problem, and we believe that we have a responsibility to help lead the industry toward solutions that help protect consumers – and the Internet ecosystem as a whole.

4. Standards-based -- A preference for solutions based on industry standards could be considered a facet of industry cooperation, but we believe it’s important enough to stand on its own. If phishing is an industry problem, then industry standard solutions will have the widest reach and the least overhead – certainly compared to proprietary solutions. For that reason, we have consistently picked industry standard solutions.

(Slightly edited.) That's a good start. The white paper explores their strategy, walks through their work with email signing. Short message: tough! No mention of the older generation technologies such as OpenPGP or S/MIME, but instead, they create plugins to handle their signatures:

To reach the active users who do not access their email through a signature-rendering email client, PayPal started working with Iconix, which offers the Truemark plug-in for many email clients. The software quickly and easily answers the question of “How do I know if a PayPal email is valid?” by rewriting the email inbox page to clearly show which messages have been properly signed.

That's by way of indicating how poorly tools designed in the early 90s from poor security analysis and wrong threat models are coping with real threats.

Next part is their work with the browser. It starts:

4.1 Unsafe browsers

There is of course, a corollary to safer browsers – what might be called “unsafe browsers.” That is, those browsers which do not have support for blocking phishing sites or for Extended Validation Certificates (a technology we will discuss later in this section). In our view, letting users view the PayPal site on one of these browsers is equal to a car manufacturer allowing drivers to buy one of their vehicles without seatbelts. The alarming fact is that there is a significant set of users who use very old and vulnerable browsers, such as Microsoft’s Internet Explorer 4 or even IE 3. ...

Unsafe Browsers are a frequent complaint here and in other places. Some good stuff has been done, but it was too little, too late, and we now see the unfortunate damage that has been done. One of these effects was that it is now up to the big website operators, in this case PayPal, to start policing the browsers. Old versions of IE are to be blocked, and a recent warning shot indicates that browsers that don't support EV will be next.

Next point: Paypal worked through several strategies. Three years ago, they pushed out a Toolbar (similar to the one listed on this blog). However this only works for those who download toolbars, a complaint frequently mentioned. So then Paypal, shifted to working with Microsoft to adopt the technology into IE7, and now they have ridden the adoption curve of IE7 for free.

Again this is exactly what should have been done: try it in toolbars then adopt it in the browser core. A cheap hint was missed and an expensive hit was scored:

4.4 Extended Verification SSL Certificates

Blocking offending sites works very well for passive users. However, we knew we needed to provide visual cues for our active users in the Web browser, much like we did with email signatures in the mail client.
Fortunately, the safer browsers helped tremendously. Taking advantage of a new type of site certificate called ‘Extended Validation (EV) SSL Certificates,’ newer browsers such as IE 7 highlight the address bar in green when customers are on a Web site that has been determined legitimate. They also display the company name and the certificate authority name. So, by displaying the green glow and company name, these newer browsers make it much easier for users to determine whether or not they’re on the site that they thought they were visiting.

This is a mixture of misinformation and danger for PayPal. The good part is that the browser, which is the authority on the CAs, now states definitively "Which Site" and also "Who says!" Green is a nice positive colour, too.

So, when this goes wrong, as it will, the user has more information in order to seek solutions. This shifting of the information back to the user (whether they want it or not) will do much more to causing the alignment of liabilities.

The bad part is that the browsers did not need a proprietary solution dressed up in a consortium in order to do this. They had indeed added the colour yellow (Firefox) and company name themselves, and the CA name has been an idea that I pushed repeatedly. For the record, Verisign asked for it early on as well. There's nothing special in the real business world about asking for "who says so?"

So we now have a structural lock-in placed in the browsers which they could have done for free, on their own initiative. Where does this go from here? Well, it certainly helps PayPal in the short term (in the same way that they could have said to users "download Firefox, check the yellow bar and company name"). But beyond that, I see dangers. As I have frequently written about the costs of the security approach before, I'll skip it now.

Overall, though, I'm pleased with the report. They have recognised that the industry has no solutions (no "silver bullets") and they have to do it themselves. They've implemented many different strategies, discarded some and improved others. Did it work? Yes, see the graph.

Best of all, they've taken the wraps off and published their findings. One of the clear indications from recent research and breach laws is that opening up the information is critical to success, and that starts with the website people. It's your job, do it, but that doesn't mean you have to do it alone! You can help each other by sharing industry-validated results, which are the only ones of any value.

To conclude, there are some other strategies that I'll suggest, and if PayPal are reading this, then they too can ask what's going on here:

a. Get TLS/SNI into Apache and IIS. Why? So that virtual hosted sites -- the 99% -- can use TLS. This will lead grass-roots-style to an explosion in the use of TLS.

Why's that helpful? (a) it will raise the profile of TLS work enourmously, and that includes server-side and browser-side practices. It will help to re-direct all these resources above into security work in the browser. Right now, 1% of activity is in TLS. Priorities will change dramatically when that goes to 10%, and that means we can count on the browser teams to spend a whole lot more time on it. And (b) if all traffic goes over TLS, this reduces the amount of security work quite considerably because everything is within the TLS security model. Paypal already figured this as "more or less all" their stuff is now under TLS, including the report!

All browsers have already done their bit for TLS/SNI. Webservers are the laggards. Ask them.

b. Hardened browser. Now that Firefox, IE and others have done some work to push attacks away from the user, the phishers are attacking the browsers from the inside. So there is a need to really secure the inside against attacks. Indeed Paypal already noted it in the report.

c. Hardened website. This means *reducing the tech.* The more you please your users, the more you please your attackers.

d. 2-channel authentication over the transaction. Okay, that's old news, but it bears repeating, because my online payment provider can only give me one of those old RSA fobs.

e. The browser website interface is here to stay. Which means we are stuck with a pretty poor combination. What's the long term design path? Here's one view: it starts with client-side certificates and opportunistic cryptography. Why? Because otherwise, transactions are naked and vulnerable, and your efforts are piecemeal.

Which means, don't replace the infrastructure wholesale, but re-tune it in the direction of security. Read the literature on secure transactions, none of it was ever employed in ecommerce, so it means there are lots of opportunities left for you :)

(Firefox and IE are both doing early components in this area, so ask them what it's about!)

f. Finally, bite the bullet and understand that your users will revolt one day, if you continue to keep fees high through industry-wide cooperation on lackadaisical fraud practices. High fraud and high loss means high fees which means high profits. One day the users will understand this, and revolt against your excuse. The manner this works is already well known to PayPal and it will happen to you, unless you adopt a competitive approach to fraud and to fees.

Fair Disclosure via blogs? Anyone listening to Pow, Splat, Blech?

Another message via the medium, this time from someone who knows how to use a remailer, and is therefore anonymous:

Don't try this at home! (without an anonymizing proxy, anyway)

Google willingly gives anyone a list of highly vulnerable US Government websites. Just write the following into the search box:

gimme pow that do some splat

These are sites that construct blah directly from blech. Most of them would respond to blah that are not supported by the blech-based interface, leaking sensitive information left and right. But quite a few would let you splat the splotches as well, up to and including blamming entire ker-blats.

You didn't hear it from me.

OK, that was fun. Problem now is, how does someone I don't know that won't hear it from me get it from someone I didn't hear it from?

Here's the rest of the message. I think we should all try it. Safety in numbers.

Just write the following into the search box:

allinurl:.gov select from where

These are websites that construct SQL queries directly from the URL. Most of
them would respond to queries that are not supported by the web-based UI of
the website, leaking sensitive information left and right. But quite a few
would let you modify the databases as well, up to and including dropping
entire tables.

The only question left is whether I'm not hearing from one anonymous or two? But you're not asking that.

Proving that you know something about security...

I recently received an (anonymous) comment on the 'silver bullets' paper that ran like this:

Sellers most certainly still have more information than the vast majority of buyers based on the fact that they spend all of their time making security software.

That's an important statement, and deserves to be addressed. How can we check that statement? Well, one way is that we could walk over to the world's biggest concentration of sellers and perhaps buyers, and test the waters? The RSA conference! Figuratively, blog-wise, Gunnar does just that:

I went to RSA to speak with Brian Chess on Breaking Web Services. First time for me to RSA, I generally go to more geek-to-geek conferences like OWASP. It is a little weird to be in such a big convention. There were soooo many vendors yet most of the products in the massive trade show floor would have as much an impact on the security in your system as say plumbing fixtures. What is genuinely strange to me is that every other area in computers improves and yet security stagnates. For years the excuse that security people gave for their field's propensity to lameness is that "no one invests a nickel in security." However, that ain't the case any more and yet most of the products teh suck. This doesn't happen in other areas of computing - databases are vastly better than a decade ago, app servers same, OS same, go right down the list. What gives in security? Where is the innovation?

This is more or less similar to the paper's selection of quotes. Anecdotally, evidence exists that insiders don't think sellers know enough, on both sides of the fence. However, surveys can be self-selecting (as was my sample of quotes in the paper), and opinions can be wrong. So it is important to realise that we have not proven one way or another, we've simply opened the door to an uncertainty.

That is, it could be true that sellers don't know enough! How we then go on to show this, one way or another, is a subject for other (many) posts and possibly much more academic research. I don't for a moment think it is reasonable nor scientifically appropriate to prove this in one paper.

another way to track their citizens

Passports were always meant to help track citizens. According to lore, they were invented in the 19th century to stop Frenchmen evading the draft (conscription), which is still an issue in some countries. BigMac points to a Dutch working paper "Fingerprinting Passports," that indicates that passports can now be used to discriminate against the bearer's country of issue, to a distance of maybe 25cm. Future Napoleons will be happy.

Because terrorising the reader over breakfast is currently good writing style by governments and media alike, let's highlight the dangers first. The paper speculates:

Given that we can remotely detect the presence of a passport of a particular country, how could this functionality be abused? One abuse case that has been suggested is a passport bomb, designed to go off if someone with a passport of a certain nationality comes close. One could even send such a bomb by post, say to an embassy. A less spectacular, but possibly more realistic, use of this functionality would by passport thieves, who can remotely check if someone is carrying passport and if it is of a ‘suitable’ nationality, before they decide to rob them.

From the general fear department, we can also add that overseas travellers sometimes have a fear of being mugged, kidnapped, hijacked or simply shot because of their mere membership of a favourable or unfavourable country.

Now that we have the FUD off our chest, let's talk details. The trick involves sending a series of commands (up to 4) to the RFID in the passport, each of which are presumably rejected by the passport. The manner of rejection differs from country to country, so a precise fingerprint-of-country can be formed simply by examining each rejection, and then choosing a different command to further narrow the choices.

How did this happen? I would speculate that the root failure is derived from bureaucrats' never-ending appetite for complex technological solutions to simple problems. In this case, the first root cause is the use of the RFID, being by intention and design something that can be read from up to 10 cm.

It is inherently attackable, and therefore by definition a very odd choice for security. The second complexity, then, involved implementing something to stop the attackers reading off the RFIDs without permission. The solution to an active read-off attack is encryption, of course! Which leads to our third complexity, a secret key, which is written inside the passport, of course! Which immediately raises issues of brute-forcing (of course!) and, as the paper references, it turns out, brute forcing attacks work on some countries' passports because the secret key is .. poorly chosen.

All of this complexity, er, solution, means something called Basic Access Control is added to the RFID in order to ensure the use of the secret key. Which means a series of commands meant to defend the RFID. If we factor in the tendency for each country to implement passports entirely alone (because they are more scared of each other than they are of their citizens), we can see that each solution is proprietary and home-grown. To cope with this, the standard was written to be very flexible (of course!). Hence, it permits wide diversity in response to errors.

Whoops! Security error. In the world of security, we say that one should be precise in what we send, and precise in what we return.

From that point of view, this is poor security work by the governments of the world, but that's to be expected. The US State Department can now derive some satisfaction from earlier blunders; because of their failure to implement any form of encryption or access control, American passports can be read by all (terrorists and borderists alike), which apparently forced them to add aluminium foil into the passport cover to act as a Faraday cage. Likely, the other countries will now have to follow suit, and the smugness of being sophisticated and advanced in security terms ("we've got BAC!") will be replaced by a dawning realisation that they should have adopted the simpler solutions in the first place.

Pogo reports: big(gest) bank breach was covered up?

An anomoly surfaces on the breach scene. Lynn reports in comments via dark reading to Pogo:

With the exception of the Birmingham News, what may be the largest bank breach involving insider theft of data seems to have flown under the mainstream media radar. ...

In light of the details now available, the breach appears to be the largest bank breach involving insider theft of data in terms of number of customers whose data were stolen. The largest incident to date for insider theft from a financial institution involved the theft of data on 8.5 million customers from Fidelity National Information Services by a subsidiary's employee.

It is not clear at the time of this writing whether Compass Bank ever notified the more than 1 million customers that their data had been stolen or how it handled disclosure and notification. A request for additional information from Compass Bank was not immediately answered.

I would guess that the Feds agreed to keep it quiet. And gave the institution a get-out-of-jail card for the disclosure requirement. It would be curious to see the logic, and I'd be skeptical. On the one side, the damage is done, and the potential for a sting or new information would not really be good enough to compensate for a million victims.

On the other side, maybe they were also able to satisfy themselves that no more damage would be done? It still doesn't cut the mustard, because once identity victims get hit, they need the hard information to clear their credit records.

But, in the light of yesterday's post, let's see this as an exception to the current US flavour of breach disclosure, and see if it sheds any light on costs of non-disclosure.

Trojan with Everything, To Go!

more literal evidence of ... well, everything really:

Targeting over 400 banks (including my own :( ! ) and having the ability to circumvent two-factor authentication are just two of the features that push Trojan.Silentbanker into the limelight. The scale and sophistication of this emerging banking Trojan is worrying, even for someone who sees banking Trojans on a daily basis.

This Trojan downloads a configuration file that contains the domain names of over 400 banks. Not only are the usual large American banks targeted but banks in many other countries are also targeted, including France, Spain, Ireland, the UK, Finland, Turkey—the list goes on.

The ability of this Trojan to perform man-in-the-middle attacks on valid transactions is what is most worrying. The Trojan can intercept transactions that require two-factor authentication. It can then silently change the user-entered destination bank account details to the attacker's account details instead. Of course the Trojan ensures that the user does not notice this change by presenting the user with the details they expect to see, while all the time sending the bank the attacker's details instead. Since the user doesn’t notice anything wrong with the transaction, they will enter the second authentication password, in effect handing over their money to the attackers. The Trojan intercepts all of this traffic before it is encrypted, so even if the transaction takes place over SSL the attack is still valid. Unfortunately, we were unable to reproduce exactly such a transaction in the lab. However, through analysis of the Trojan's code it can be seen that this feature is available to the attackers.

The Trojan does not use this attack vector for all banks, however. *It only uses this route when an easier route is not available*. If a transaction can occur at the targeted bank using just a username and password then the Trojan will take that information, if a certificate is also required the Trojan can steal that too, if cookies are required the Trojan will steal those....

(spotted by JPM) MITB, MITM, two-factor as silver bullets for online banks, the node is insecure, etc etc.

About the only thing that is a bit of a surprise is the speed of this attack. We first reported the MITB here around 2 years back, and we are still only seeing reports like the above. Although I said earlier that a big problem with the banking world was that the attacker can spin inside your OODA loop, it would appear that he does not take on every attack.

See above for some limits: the attacker is finding and pursuing the attacks that are easiest, first. Is this finally the evidence that cryptographers cannot ignore? Crypto alone has proven to not work. It may be theoretically strong, but it is practically brittle, and easily bypassed. A more balanced, risk-based approach is needed. An approach that uses a lot less crypto, and a lot more engineering and user understanding, would be far more efficacious to deliver what users need.

Principle of Redundancy

In software engineering, it is important to remember the principle of redundancy. Not because it is useful for software, but because it is useful for humans.

Human beings work continuously with redundancy because most human information processing is soft and fuzzy. How does a system deal with soft, fuzzy results? It takes readings from different sources, as little correlated as possible, and compares them. If three readings from independent sources all suggest the same conclusion, then we are good. If 2 out of 3 say good, then the human brain says "take care," and if 1 out 3 is good, then it is discarded.

In comments on the last post, Peter G explored the direct question of whether anyone checked the fingerprint of the SSH server:

I tried to get some data a while back on SSH key checking in response to SSH fuzzy fingerprints (if you're not familiar with fuzzy fingerprints, they create a close-enough fingerprint to the actual target to pass muster in most cases). Because human-subject experimentation requires a lot of paperwork and scrutiny, I thought I'd first try and establish a base rate for SSH fingerprint checking in general. In other words if you set up a new server with a totally different key from the current one, how many people will be deterred?

So I tried to establish the fingerprint-check rate in a population of maybe a few thousand users.

It was zero.

No-one had ever performed an out-of-band check of an SSH fingerprint when it changed.

Given a base rate of zero, I didn't consider it worthwhile doing the fuzzy fingerprint check :-).

What is going on here? Three things. For some reason that has never been explained, SSH has never made it easy to check the fingerprint. Like OpenPGP to some extent, the fingerprints have been delivered in incompatible formats across different channels. E.g., my known_hosts file says that a server I know is AAAAB3N.... and the only way to easily see the fingerprint is to simulate a compromise by clearing the cache.

Secondly, and the point of this post: the fingerprint is only one of the datums that is being displayed. In the last post, I talked about two other pieces of data: One was the failure of server-key matching, and the other was the fallback to password-request.

The key lesson here is that SSH delivers enough information to do the job: it isn't the fingerprint per se, but the whole package of fingerprint, server-key matching, and precise mode.

Three data points, albeit rather poorly presented. Which brings us to another point: In practice, this is only good enough in rare and experienced situations. That breach was only picked up because of the circumstances and a good dose of luck.

This leads us to conclude that SSH is only just good enough, sometimes. Why? Because it is only just good enough for the job; it's circular, because since it has done the job well enough all these years, the security model has not been much improved against the theoretical concept that knocked the theoretical MITM on the head. The third thing is then lack of attacks -- now, however, circumstances are changing, and improvements should take place. (Indeed, if you have a longer perspective, you'll notice that the distros of SSH have been upgrading the security model over the last few years.)

But, the important upgrades do not want to be in forcing the fingerprint down the throats of the user. Instead, they want to be in the area of redundancy: more uncorrelated soft and fuzzy signals to the user, that work with the brain, not with the old 1990s computer textbooks.

Hence, and to complete the response to Peter G, this is why the PKI apologists are looking in the wrong area:

So there is a form of data available, but because it's not very interesting it'll never be written up in a conference paper (there's a longer discussion of fuzzy fingerprints and related stuff in my perpetual-work-in-progress http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf). I've seen this type of authentication referred to as leap-of-faith authentication in a few recent usability papers, and that seems to be a reasonable name for it. That's not saying it's a bad thing, just that you have to know what it is you're getting for your money.

Yeah, we can all see "leap of faith" as a sort of mental trick to avoid really examining why SSH works and why PKI doesn't or didn't. That is, "oh, but because you make this 'leap of faith' you're not really secure, according to our models. So I don't have to think any more about it."

The real issue here is again, it worked, enough, for the job. Now the SSH people will think more, and upgrade it, because it is being attacked. I hope, at least!

The PKI people cannot say that. What they can say is "use TLS/SRP" or some other similar RFC acrophiliac verbage which doesn't translate to anything a user can eat or drink. Hence, the simple answer is, "come back when I can use it."

Say it ain't so? MITM protection on SSH shows its paces...

For a decade now, SSH has successfully employed a simple opportunistic protection model that solved the shared-key problem. The premise is quite simple: use the information that the user probably knows. It does this by caching keys on first sight, and watching for unexpected changes. This was originally intended to address the theoretical weakness of public key cryptography called MITM or man-in-the-middle.

Critics of the SSH model, a.k.a. apologists for the PKI model of the Trusted Third Party (certificate authority) have always pointed out that this simply leaves SSH open to a first-time MITM. That is, when some key changes or you first go to a server, it is "unknown" and therefore has to be established with a "leap of faith."

The SSH defenders claim that we know much more about the other machine, so we know when the key is supposed to change. Therefore, it isn't so much a leap of faith as educated risk-taking. To which the critics respond that we all suffer from click-thru syndrome and we never read those messages, anyway.

Etc etc, you can see that this argument goes round and round, and will never be solved until we get some data. So far, the data is almost universally against the TTP model (recall phishing, which the high priests of the PKI have not addressed to any serious extent that I've ever seen). About a year or two back, attack attention started on SSH, and so far it has withstood difficulties with no major or widespread results. So much so that we hear very little about it, in contrast to phishing, which is now a 4 year flood of grief.

After which preamble, I can now report that I have a data point on an attack on SSH! As this is fairly rare, I'm going to report it in fullness, in case it helps. Here goes:

Yesterday, I ssh'd to a machine, and it said:

zhukov$ ssh some.where.example.net
WARNING: RSA key found for host in .ssh/known_hosts:18
RSA key fingerprint 05:a4:c2:cf:32:cc:e8:4d:86:27:b7:01:9a:9c:02:0f.
The authenticity of host can't be established but keys
of different type are already known for this host.
DSA key fingerprint is 61:43:9e:1f:ae:24:41:99:b5:0c:3f:e2:43:cd:bc:83.
Are you sure you want to continue connecting (yes/no)?

OK, so I am supposed to know what was going on with that machine, and it was being rebuilt, but I really did not expect SSH to be effected. The ganglia twitch! I asked the sysadm, and he said no, it wasn't him. Hmmm... mighty suspicious.

I accepted the key and carried on. Does this prove that click-through syndrome is really an irresistable temptation and the archilles heel of SSH, and even the experienced user will fall for it? Not quite. Firstly, we don't really have a choice as sysadms, we have to get in there, compromise or no compromise, and see. Secondly, it is ok to compromise as long as we know it, we assess the risks and take them. I deliberately chose to go ahead in this case, so it is fair to say that I was warned, and the SSH security model did all that was asked of it.

Key accepted (yes), and onwards! It immediately came back and said:

iang@somewhere's password:

Now the ganglia are doing a ninja turtle act and I'm feeling very strange indeed: The apparent thought of being the victim of an actual real live MITM is doubly delicious, as it is supposed to be as unlikely as dying from shark bite. SSH is not supposed to fall back to passwords, it is supposed to use the keys that were set up earlier. At this point, for some emotional reason I can't further divine, I decided to treat this as a compromise and asked my mate to change my password. He did that, and then I logged in.

Then we checked. Lo and behold, SSH had been reinstalled completely, and a little bit of investigation revealed what the warped daemon was up to: password harvesting. And, I had a compromised fresh password, whereas my sysadm mates had their real passwords compromised:

$ cat /dev/saux
foo@...208 (aendermich) [Fri Feb 15 2008 14:56:05 +0100]
iang@...152 (changeme!) [Fri Feb 15 2008 15:01:11 +0100]
nuss@...208 (43Er5z7) [Fri Feb 15 2008 16:10:34 +0100]
iang@...113 (kash@zza75) [Fri Feb 15 2008 16:23:15 +0100]
iang@...113 (kash@zza75) [Fri Feb 15 2008 16:35:59 +0100]
$ 

The attacker had replaced the SSH daemon with one that insisted that the users type in their passwords. Luckily, we caught it with only one or two compromises.

In sum, the SSH security model did its job. This time! The fallback to server-key re-acceptance triggered sufficient suspicion, and the fallback to passwords gave confirmation.

As a single data point, it's not easy to extrapolate but we can point at which direction it is heading:

• the model works better than its absence would, for this environment and this threat.
• This was a node threat (the machine was apparently hacked via dodgy PHP and last week's linux kernel root exploit).
• the SSH model was originally intended to counter an MITM threat, not a node threat.
• because SSH prefers keys to passwords (machines being more reliable than humans) my password was protected by the default usage,
• then, as a side-effect, or by easy extension, the SSH model also protects against a security-mode switch.
• it would have worked for a real MITM, but only just, as there would only have been the one warning.
• But frankly, I don't care. The compromise of the node was far more serious,
• and we know that MITM is the least cost-effective breach of all. There is a high chance of visibility and it is very expensive to run.
• If we can seduce even a small proportion of breach attacks across to MITM work then we have done a valuable thing indeed.

In terms of our principles, we can then underscore the following:

• We are still a long way away from seeing any good data on intercept over-the-wire MITMs. Remember: the threat is on the node. The wire is (relatively) secure.
• In this current context, SSH's feature to accept passwords, and fallback from key-auth to password-auth, is a weakness. If the password mode had been disabled, then an entire area of attack possibilities would have been evaded. Remember: There is only one mode, and it is secure.
• The use of the information known to me saved me in this case. This is a good example of how to use the principle of Divide and Conquer. I call this process "bootstrapping relationships into key exchanges" and it is widely used outside the formal security industry.

All in all, SSH did a good job. Which still leaves us with the rather traumatic job of cleaning up a machine with 3-4 years of crappy PHP applications ... but that's another story.

• turn all PHP to secure settings. throw out all old PHP apps that can't cope.
• find an update for your Linux kernel quickly
• watch out for SSH replacements and password harvesting
• prefer SSH keys over passwords. The compromises can be more easily cleaned up by re-generating and re-setting the keys, they don't leapfrog so easily, and they aren't so susceptible to what is sometimes called "social engineering" attacks.

Rumours of Skype + SSL breaches: same old story (MITB)

Skype is the darling child of cryptoplumbers, the application that got everything right, could withstand the scrutiny of the open investigators, and looked like it was designed well. It also did something useful, and had a huge market, putting it head and shoulders of any other crypto application, ever.

Storms are gathering on the horizon. Last year we saw stories that Skype in China was shipping with intercept plugins. 3 months ago I was told by someone who was non-technical that the German government was intercepting Skype. Research proved her wrong ... and now leaks are proving her right: Slashdot reports on leaked German memos:

James Hardine writes "Wikileaks has released documents from the German police revealing Skype interception technology. The leaks are currently creating a storm in the German press. The first document is a communication by the Ministry of Justice to the prosecutors office, about the cost splitting for Skype interception. The second document presents the offer made by Digitask, the German company secretly developing Skype interception, and holds information on pricing and license model, high-level technology descriptions and other detail. The document is of global importance because Skype is used by tens or hundreds of millions of people daily to communicate voice calls and Skype (owned by Ebay, Inc) promotes these calls as being encrypted and secure. The technology includes interception boxes, key forwarding trojans and anonymous proxies to hide police communications."

Is Skype broken? Let's dig deeper:

[The document] continues to introduce the so-called Skype Capture Unit. In a nutshell: a malware installed on purpose on a target machine, intercepting Skype Voice and Chat. Another feature introduced is a recording proxy, that is not part of the offer, yet would allow for anonymous proxying of recorded information to a target recording station. Access to the recording station is possible via a multimedia streaming client, supposedly offering real-time interception.

Nope. It's the same old bug: pervert your PC and the enemy has the same power as you. Always remember: the threat is on the node, the wire is safe.

In this case, Mallory is in the room with you, and Skype can't do a darn thing about it, given that it borrows the display, keyboard, mike and speaker from the operating system. The forthrightness of the proposal and the parties to the negotiations would be compelling evidence that (a) the police want to infect your PC, and (b) infecting your PC is their preferred mechanism. So we can conclude that Skype itself is not efficiently broken as yet, while Microsoft Windows is or more accurately remains broken (the trojan/malware is made for the market-leading Microsoft Windows XP and 2000 only, not the market-following Linux/MacOSX/BSD/Unix family, nor the market-challenging Vista).

No change, then. For Skype, the dream run has not ended, but it has crossed into that area where it has to deal with actual targetted hacks and attacks. Again, no news, and either way, it remains the best option for us, the ordinary people. Unlike other security systems:

Another part of the offer is an interception method for SSL based communication, working on the same principle of establishing a man-in-the-middle attack on the key material on the client machine. According to the offer this method is working for Internet Explorer and Firefox webbrowsers. Digitask also recommends using over-seas proxy servers to cover the tracks of all activities going on.

MITB! Now, normally we make a distinction between demos, security gossip, rumours and other false signals ... but the offer of actual technology by a supplier, with a hard price, to a governmental intercept agency indicates an advanced state of affairs:

The licensing model presented here relates to instances of installations per month for a minimum of three months. Each installation of the Skype Capture Unit will cost EUR 3500, SSL interception is priced at EUR 2500. A one-time installation fee of EUR 2500 is not further explained. The minimum cost for any installation on a suspect computer for a comprehensive interception of both SSL and Skype will be EUR 20500, if no more than one one-time installation fee are required.

This is the first hard evidence of professional browser-interference of SSL website access. Rumours of this practice have been around since 2004 or so, from commercial attacks, but nobody dared comment (apparently NDAs are stronger than crimes in the US of A).

What reliable conclusion can we draw?

• the cost of an intercept is 2500 and climbing.
• the "delivery time" taken is a month or so, perhaps indicating the need to probe and inject into Windows.
• MacOSX and Linux are safe for now, due to small market share and better security focus
• Vista is safe today, for an unknown brew of market share, newness and "added security" reasons.
• Skype itself is fine. So install your Skype on a Mac (if human) or a Linux box (if a hardcore techie).

Less reliably, we can suggest:

• All major police forces in rich countries will have access to this technology.
• Major commercial attackers will have access, as well as major criminal attackers.
• Presumably the desire of the police here is to not interfere with ordinary people's online banking, which they now can do because most banking systems are still stuck on dual factor (memo to my bank: your super-duper advanced dual factor system is truly breached by the MITB).
• Nor, presumably, do they care about your reading of this blog nor wikileaks, both being available in cleartext as well. Which means the plan to install *TLS/SSL everywhere to protect all browsing* is still a good plan, and is only held up by the slowness at Apache and Microsoft. (Guys, one million phishing victims every year beg you to hurry up.)
• Police are more interested in breaching the online chat of various bad guys. So, SSL email and chat forums, Skype chat and voice.

Of course the governance issue remains. The curse of governance says that power will be used for bad. When the good guys can do it, then presumably the bad guys can do it as well, and who's to say the good guys are always good? People who have lots of money should worry, because the propensity for well-budgetted but poorly paid security police in 1st world countries to manipulate their pensions upwards is unfortunately very real. Get a Mac, guys, you can afford it.

In reality, it simply doesn't matter who is doing it: the picture is so murky that the threat level remains the same to you, the user: you now need to protect your PC against injection of trojans for the purpose of attacking your private information directly.

Final questions: how many intercepts are they doing and planning, and did the German government set up a cost-sharing for payoffs to the anti-virus companies?

#4.2 Simplicity is Inversely Proportional to the Number of Designers

Still reeling at the shock of that question, it feels like time to introduce another hypothesis:

#4.2 Simplicity is Inversely Proportional to the Number of Designers

Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. Margaret Mead

Simplicity is proportional to the inverse of the number of designers. Or is it that complexity is proportional to the square of the number of designers?

Sad but true, if you look at the classical best of breed protocols like SSH and PGP, they delivered their best work when one person designed them. Even SSL was mostly secure to begin with, and it was only the introduction of PKI with its committees, models, digital signature laws and accountants that sent it into orbit around Pluto.

Sometimes a protocol can survive a team of two, but we are taking huge risks (remember the biggest failure mode of all is failing to deliver anything). Either compromise with your co-designer quickly or kill him, your users will thank you for either. They do not benefit if you are locked in a deadly embrace over the pernickety benefits of MAC-then-encrypt over encrypt-then-MAC.

It should be clear by now that committees are totally out of the question. They are like whirlpools, great spiralling sinks of talent, so paddle as fast as possible in the other direction. On the other hand, if you are having trouble shrinking your team or agreeing with them, a committee over yonder can be useful as a face saving idea. Point them in that direction of the whirlpool, give them a nudge, and then get back to work.

What good are standards?

Over at mozo, Jonath asks the most surprising question:

My second question is this: as members of the Mozilla community, is this an effort that you want me (or people like me) participating in, and helping drive to final publication?

Absolutely not, on several grounds. Here's some reasons, off the top of my head.

Committees can't make security, full stop. Committees can write standards shaped like millstones around the neck, though.

Standards are *not* indicated (in medical sense) for UI because the user is *not* a computer and does not and cannot follow precise rules like protocols.

UI and security, together, probably requires skills that are not available, easily, to your committee. Branding doesn't sit well with coding, architecture can't talk to lawyers. Nobody knows what a right is, and the number of people who can bring crypto to applications is so small that you won't find them in your committee.

Security UI itself is an open research area, not an understood discipline that needs further explanation. Standards are indicated if you want to kill research, and move to promulgation of agreed dogma. This is sometimes useful, but only when the problems are solved; which is not indicated with phishing, now, is it?

Although I have my difficulties with some of the research done, if you take away the ability to research from the community ("that's not standard!"), you've got nothing to tell you what to do, and the enemy has locked you down to a static position. (Static defence stopped around the time of the invention of the canon, so we are looking at quite some history here...)

Anybody got any other reasons? Is there a positive reason here, anywhere?

UK data breach counts another coup!

The UK data breach a month or two back counted another victim: one Jeremy Clarkson. The celebrated British "motormouth" thought that nobody should really worry about the loss of the disks, because all the data is widely available anyway. To stress this to the island of nervous nellies, he posted his bank details in the newspaper.

Back in November, the Government lost two computer discs containing half the population's bank details. Everyone worked themselves into a right old lather about the mistake but I argued we should all calm down because the details in question are to be found on every cheque we hand out every day to every Tom, Dick and cash and carry.

Unfortunately, some erstwhile scammer decided to take him to task at it and signed him up for a contribution to a good charity. (Well, I suppose it's good, all charities and non-profits are good, right?) Now he writes:

I opened my bank statement this morning to find out that someone has set up a direct debit which automatically takes £500 from my account. I was wrong and I have been punished for my mistake.

Contrary to what I said at the time, we must go after the idiots who lost the discs and stick cocktail sticks in their eyes until they beg for mercy.

What can we conclude from this data point of one victim? Lots, as it happens.

1. Being a victim of the *indirect* nature continues to support the thesis that security is a market for silver bullets. That is, the market is about FUD, not security in any objective sense.
2. (writing for the non-Brit audience here,) Jeremy Clarkson is a comedian. Comments from comedians will do more to set the agenda on security than any 10 incumbents (I hesitate to use more conventional terms). There has to be some pithy business phrase about this, like, when your market is defined by comedians, it's time for the, um, incumbents to change jobs.
3. Of course, he's right on both counts. Yes, there is nothing much to worry about, individually, because (a) the disks are lost, not stolen, and (b) the data is probably shared so willingly that anyone who wants it already has it. (The political question of whether you could trust the UK government to tie its security shoelaces is an entirely other matter...)

   And, yes, he was wrong to stick his neck out and say the truth.



4. So why didn't the bank simply reverse the transaction? I'll leave that briefly as an exercise to the reader, there being two good reasons that I can think of, after the click.

b. because he asked them not to reverse the transaction, as now he gets an opportunity to write another column. Cheap press.

Hat-tip to JP! And, I've just noticed DigitalMoney's contribution for another take!

Entire UK security industry is sent to Pogo's Swamp

One of the enduring threads that has been prevalent on this blog but not other places is that the problem starts with ourselves. Without considering our own mistakes, our own frauds, indeed, our own history, it is impossible to understand the way security, FC, and the Internet are going.

Compelling evidence presented over at LightBlueTouchpaper. Not that their Wordpress blog was hacked (there but for the grace of God, etc etc) but where Richard Clayton asks why did the Government reject all the recommendations of the House of Lords report of a while back? Echoed over at Ianb's blog, probably throughout the entire British IT and security industry. Why?

Richard searches for an answer: Stupidity? Vested Interests? (On the way, he presents more evidence about how secrecy of big companies is part of the problem, not part of the solution, but that's a distraction.)

We have good news: The lack of reflective thought is slowly diminishing. Over the last month I've seen an upsurge of comments: 1Raindrop's Gunnar Peterson says "One of the sacred cows that need to gored is the notion that we in the People's Republic of IT Security have it all figured. We don't." Elsewhere Gunnar says "in many cases, they are spending $10 to protect something worth $5, and in other cases they are spending a nickel to protect something worth $1,000."

Microsoft knows but isn't saying: Vista fails to clear up the security mess. Which means that they spent the last 5 years and got ... precisely nowhere. Forget the claim that Vista bombed in the security department ("short M$ ! buy Apple!") and consider the big picture: if Microsoft can throw their entire company at the issue of security, and fail, what hope the rest?

Chandler (again) points to the Inquirer:

Whose interests are really threatened by cybercrime? Well, certainly not the software makers, the chip makers, the hard disk makers, the mouse makers, and least of all the virus busters and security firms which daily release news of the latest “vulnerabilities” plaguing the web.

No, the victims are the poor users. Not that they’re likely to have their identity stolen or their bank account plundered or their data erased by some malicious bot or other. The chances of that happening are millions to one.

No, what they are forced to do is continually fork out for spam-busting protection, for “secure” operating systems, for funky firewalls, malware detectors or phish-sniffing software. All this junk clogs up their spanking new PC so that they continually have to upgrade to newer chippery clever enough to have a processing core dedicated to each of the bloatsome security routines keeping them safe while they surf.

It’s a con, gentlemen. A big fat con.

No one has a business interest in catching identity thieves or malware writers. There’s no money in it, so no-one’s bothered.

Chandler then goes on to identify where the solution isn't but let's not get distracted on that, today. Some people including John Q pointed to Linus who said:

... But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: [scheduling] is "hard science". The other one is "people wanking around with their opinions".

Which rudeness strangely echoes the comment in 2004 or so by a leading security expert who stopped selling for a microsecond and was briefly honest about the profession.

When I drill down on the many pontifications made by computer security and cryptography experts all I find is given wisdom. Maybe the reason that folks roll their own is because as far as they can see that's what everyone does. Roll your own then whip out your dick and start swinging around just like the experts.

I only mention it because that dates my thinking on this issue. As I say, I've seen an upsurge in this over the last few months so I can predict that around now is the time that the IT security sector realises that not only do they not have a solution to security, they don't know how to create a solution for security, and even if they accidentally found one, nobody would listen to them anyway.

If you have followed this far, then you can now see why the UK Government can happily ignore the Lords' recommendations: because they came from the security industry, and that's one industry that has empirically proven that their views are not worth listening to. Welcome to Pogo's swamp.

Storm Worm signals major new shift: a Sophisticated Enemy

I didn't spot it when Peter Gutmann called it the world's biggest supercomputer (I thought he was talking about a game or something ...). Now John Robb pointed to Bruce Schneier who has just published a summary. Here's my paraphrasing:

• Patience ...
• Separation of Roles ...
• Redundant Roles ...
• No damage to host ...
• p2p communications to control nodes ...
• morphing of standard signatures (DNS, code) ...
• probing (in military recon terms) past standard defences ...
• knowledge of the victim's weaknesses ...
• suppression of the enemy's recon ...

Bruce Schneier reports that the anti-virus companies are pretty much powerless, and runs through a series of possible defences. I can think of a few too, and I'm sure you can as well. No doubt the world's security experts (cough) will spend a lot of time on this question.

But, step back. Look at the big picture. We've seen all these things before. Those serious architects in our world (you know who you are) have even built these systems before.

But: we've never seen the combination of these tactics in an attack .

This speaks to a new level of sophistication in the enemy. In the past, all the elements were basic. Better than script kiddie, but in that area. What we had was industrialisation of the phishing industry, a few years back, which spoke to an increasing level of capital and management involved.

Now we have some serious architects involved. This is in line with the great successes of computer science: Unix, the Internet, Skype all achieved this level of sophistication in engineering, with real results. I tried with Ricardo, Lynn&Anne tried with x9.59. Others as well, like James and the Digicash crew. Mojo, Bittorrent and the p2p crowd tried it too.

So we have a new result: the enemy now has architects as good as our best.

As a side-issue, well predicted, we can also see the efforts of the less-well architected groups shown for what they are. Takedown is the best strategy that the security-shy banks have against phishing, and that's pretty much a dead duck against the above enemy. (Banks with security goals have moved to SMS authentication of transactions, sometimes known as two channel, and that will still work.)

But that's a mere throwaway for the users. Back to the atomic discussion of architecture. This is an awesome result. In warfare, one of the dictums is, "know yourself and win half your battles. Know your enemy and win 99 of 100 battles."

For the first time in Internet history, we now have a situation where the enemy knows us, and is equal to our best. Plus, he's got the capital and infrastructure to build the best tools against us.

Where are we? If the takedown philosophy is any good data point, we might know ourselves but we know little about the enemy. But, even if we know ourselves, we don't know our weaknesses, and our strengths are useless.

What's to be done? Bruce Schneier said:

Redesigning the Microsoft Windows operating system would work, but that's ridiculous to even suggest.

As I suggested in last year's roundup, we were approaching this decision. Start re-writing, Microsoft. For sake of fairness, I'd expect that Linux and Apple will have a smaller version of the same problem, as the 1970s design of Unix is also a bit out-dated for this job.

On the downside of the MBA-equiped CSO...

There is always the downside to any silver bullet. Last month I proposed that the MBA is the silver bullet that the security industry needs, and this caused a little storm of protest.

Here's the defence and counter-attack. This blog has repeatedly railed against the mostly-worthless courses and certifications that are sold to those "who must have a piece of paper." The MBA also gets that big black mark, as it is, at the end of the day, a piece of paper. Saso said in comments:

In short, I agree, CISO should have an MBA. For its networking value, not anything else.

Cynical, but there is an element of wisdom there. MBAs are frequently sold on the benefits of networking. In contrast to Saso, I suggest that the benefits of networking are highly over-rated, especially if you take the cost of the MBA and put it alongside the lost opportunity of other networking opportunities. But people indeed flock to pay the entrance price to that club, and if so, maybe it is fair to take their money, as better an b-school than SANS? Nothing we can do about the mob.

Jens suggests that the other more topical courses simply be modified:

From what I see out there when looking at the arising generation of CSO's the typical education is a university study to get a Master of Science in the field of applied IT security. Doesn't sound too bad until we look into the topics: that's about 80% cryptography, 10% OS security, 5% legal issues and 5% rest.

Well, that's stuffed up, then. In my experience, I have found I can teach anyone outside the core crypto area everything they need to know about cryptography in around 20 minutes (secret keys, public keys, hashes, what else is there?), so why are budding CSOs losing 80% on crypto? Jens suggests reducing it by 10%, I would question why it should ever rise above 5%?

Does the MBA suffer from similar internal imbalance? I say not, for one reason: it is subject to open competition. There is always lots of debate that one side is more balanced than others, and there is a lot of open experimentation in this, as all the schools look at each other's developments in curricula. There are all sorts of variations tuned to different ideas.

One criticism that was particularly noticeable in mine was that they only spent around 2 days in negotiation, and spent more than that on relatively worthless IT cases. That may be just me, but it is worth noting that b-schools will continue to improve (whereas there is no noticeable improvement from the security side). Adam Shostack spots Chris Hoff who spots HBR on a (non-real) breach case:

I read the Harvard Business Review frequently and find that the quality of writing and insight it provides is excellent. This month's (September 2007) edition is no exception as it features a timely data breach case study written by Eric McNulty titled "Boss, I think Someone Stole Out Customer Data."

The format of the HBR case studies are well framed because they ultimately ask you, the reader, to conclude what you would do in the situation and provide many -- often diametrically opposed -- opinions from industry experts.
...
What I liked about the article are the classic quote gems that highlight the absolute temporal absurdity of PCI compliance and the false sense of security it provides to the management of companies -- especially in response to a breach.

What then is Harvard suggesting that is so radical? The case does no more than document a story about a breach and show how management wakes up to the internal failure. Here's a tiny snippet from Chris's larger selection:

Sergei reported finding a hole—a disabled firewall that was supposed to be part of the wireless inventory-control system, which used real-time data from each transaction to trigger replenishment from the distribution center and automate reorders from suppliers.

“How did the firewall get down in the first place?” Laurie snapped.

“Impossible to say,” said Sergei resolutely. “It could have been deliberate or accidental. The system is relatively new, so we’ve had things turned off and on at various times as we’ve worked out the bugs. It was crashing a lot for a while. Firewalls can often be problematic.”

Chris Hoff suggests that the managers go through classic disaster-psychological trauma patterns, but instead I see it as more evidence that the CISO needs an MBA, because the technical and security departments spun out of corporate orbit so long ago nobody can navigate them. Chris, think of it this way: the MBAs are coming to you, and the next generation of them will be able to avoid the grief phase, because of the work done in b-school.

Lynn suggests that it isn't just security, it isn't just CSOs, and is more of a blight than a scratch:

note that there have been a efforts that aren't particularly CSO-related ... just techies ... in relatively the same time frame as the disastrous card reader deployments ... there were also some magnificent other disastrous security attempts in portions of the financial market segment.

My thesis is that the CSO needs to communicate upwards, downwards, sideways, and around corners. Not only external but internal, so domination of both sides is needed. As Lynn suggests, it is granted that if you have a bunch of people without leadership, they'll suggest that smart cards are the secure answer to everything from Disney to Terrorism. And they'll be believed.

The question posed by Lynn is a simple one: why do the techies not see it?

The answer I saw in banking and smart card monies, to continue in Lynn's context, was two-fold. Firstly, nobody there was counting the costs. Everyone in the smart card industry was focussed on how cheap the smart card was, but not the full costs. Everybody believed the salesmen. Nobody in the banks thought to ask what the costs of the readers were (around 10-100 times that of the card itself...) or the other infrastructure needed, but banks aren't noted for their wisdom, which brings us to the second point.

Secondly, it was pretty clear that although the bank knew a little bit about transactions, they knew next to nothing about what happened outside their branch doors. Getting into smart card money meant they were now into retail as opposed to transactions. In business terms, think of this as similar to a supermarket becoming a bank. Or v.v. That's too high a price to pay for the supposed security that is entailed in the smart card. Although Walmart will look at this question differently, banks apparently don't have that ability.

It is impossible to predict whether your average MBA would spot these things, but I will say this: They would be pass/fails in my course, and there would not be anything else on the planet that the boss could do to spot them. Which you can't say for the combined other certifications, which would apparently certify your CSO to spot the difference between 128 bit and 1024 bit encryption ... but sod all of importance.

Threatwatch: US-SSNs melt for $50 in MacArthur Park

So, having read the HBR case I just wrote about ("nobody else reads the original material they quote, why should I?"), I discovered this numbers gem on the very last page:

Perhaps the most worrying indicator is that the criminal industry for information is growing. I can go to MacArthur Park in Los Angeles any day of the week and get $50 in exchange for a name, social security number, and date of birth. If I bring a longer list of names and details, I walk away a wealthy man.

$50 for ID sets seems very high in these days of phishing, but that may be the price for hand-to-hand delivery and a guarantee of quality. Either way, a data point.

What also strikes is the mention of a physical marketplace. Definitely a novelty! The only thing I know about that place is that it melts in the dark, but it could be that MacArthur Park is simply too large to shut down.

Learning from Iraq and Failure

Financial Cryptographers are interested in war because it is one of the few sectors where we face an aggressive attacker (as opposed to a statistical failure model). For this reason, current affairs like Iraq and Afghanistan are interesting, aside from their political aspects (September is crunch time!).

John Robb points to an interview with Lt. Col. John Nagl on how the New Turks in Iraq (more formally known as General Petraeus and his team) have written a new manual for the theater, known as the Counterinsurgency Field Manual.

We last had a counter guerrilla manual in 1987 but as an army we really avoided counterinsurgency in the wake of Vietnam because we didn't want to fight that kind of war again. Unfortunately the enemy has a vote. And our very conventional superiority in war-fighting is driving our enemy to fight us as insurgents and as guerrillas rather than the kind of war we are most prepared to fight, which is conventional tank-on-tank type of fighting.

...

You still have to be able to do the fighting. A friend of mine when he found out i was writing [the book] wrote to me from Iraq and said

"remember, Nagl, counterinsurgency is not just the thinking man's war ... It's the graduate level of war."

Because you still have to be able to do the war fighting stuff. When I was in [Iraq] I called in artillery strikes and air strikes, did the fighting stuff. But I also spent a lot of time meeting with local political leaders, establishing local government, working on economic development.

You really have to span the whole spectrum of human behavior. We had cultural anthropologists helping on the book, economists, information operation specialists. It's a very difficult type of war, it's a thinking person's kind of war. And it's a kind of war we are learning and adapting and getting better at fighting during the course of the wars in Iraq and Afghanistan.

I copied those parts in from the interview because they stressed what we see in FC, but check out the interview as it is refreshing. Here's the parallels:

• The Gung-ho warriors enter the field.
• And are defeated.
• Institutions are not able to respond to the new threats until they have shown themselves incapable of forcing old threat models on the enemy.
• The battle is won, or at least fought, with brains, not brawn.
• Still, the "warfighting" or general security stuff never goes away.
• When we are dealing with an asymmetric or "new" attack, multiple disciplines enter into the discussion to analyse the balance between fighting and other strategies.
• The new strategy emerges, but only after the losses to both our ground forces and our old generals.

The parallels with today's Internet situation seem pretty clear. How long do we go on fighting the attackers before the New Turks come in and address the battle from a holistic, systemic viewpoint?

Threatwatch: Numbers on phishing, who's to blame, the unbearable loneliness of 4%

Jonath over at Mozilla takes up the flame and publishes lots of stats on the current state of SSL, phishing and other defences. Headline issues:

• Number of SSL sites: 600,000 from Netcraft
• Cost of phishing to US: $2.1 billion dollars.
• Number of expired certs: 18%
• Number of users who blame a glitch in the browser for popups: 4%

I hope he keeps it up, as it will save this blog from having done it for many years :) The connection between SSL and phishing can't be overstressed, and it's welcome to see Mozilla take up that case. (Did I forget to mention TLS/SNI in Apache and Microsoft? Shame on me....)

Jonath concludes with this odd remark:

If I may be permitted one iota of conclusion-drawing from this otherwise narrative-free post, I would submit this: our users, though they may be confused, have an almost shocking confidence in their browsers. We owe it to them to maintain and improve upon that, but we should take some solace from the fact that the sites which play fast and loose with security, not the browsers that act as messengers of that fact, really are the ones that catch the blame.

You, like me, may have read that too quickly, and thought that he suggests that the web sites are to blame, with their expired certs, fast and loose security, etc.

But, he didn't say that, he simply said those are the ones that *are* blamed. And that's true, there are lots and lots of warnings out there like campaigns to drop SSL v2 and stop sites doing phishing training and other things ... The sites certainly catch the blame, that's definately true.

But, who really *deserves* the blame? According to the last table in Jonath's post, the users don't really blame the site as much as might be expected: 24%. More are unsure and thus wise, I say: 32%. And yet more imagine an actual attack taking place: 40%.

That leaves 4% who suspect a "glitch" in the browser itself. Surely one lonely little group there, I wonder if they misunderstood what a "glitch" is... What is a "glitch," anyway, and how did it get into their browsers?

DNS Rebinding, and the drumroll of SHAME for MICROSOFT and APACHE

Tonight, we have bad news and worse news. The bad news is that the node is yet again the scene of imminent collapse of the Internet as we know it. The worse news is that the fix that could have fixed it ... is still not deployed. The no-news is that we warned about years ago. It's still not done.

Dan Kaminsky, a hacker of some infamy and humour, gave a son-of-black-hat talk on DNS Rebinding. What this means is that when you go to a site that has a malicious applet or Flash or something, then your node becomes controlled (that's your PC, desktop, laptop, etc) for attacks on other nodes.

Now, I don't fully understand the deal ... and details were difficult to follow ... but it is something to do with weird things with DNS that allow a malicious site to download bad code into your applet/flash/javascript weakened browser. Then, that code literally takes over and turns your node -- your PC -- into an internal attack-dog under someone else's whistle. Dan uses the example of the printer down the hall, but in finance circles this is the internal derivatives accounting system down the hall, already smoking from too much recent attention.

Yes, Firefox and IE are both victims.

The DNS details were scary and voluminous but rest on a basically sound claim: DNS isn't secure, and that we know. It is possible to hand the requestor all sorts of interesting information, and that interesting information can then be used to trick through firewalls, IDS, etc, and compromise the machine, because it is "authoritive" and it comes from the right machine, your machine, your soon-to-be-owned machine.

Curiously, the object of Dan's project is much more grandiose than that. He's looking to do a bunch of weird measurements on TCP, using this DNS rebinding to bootstrap in and take over the TCP connection. Yeah, MITM, if you spotted the clue.

(I'll repeat that, Dan claims to be doing MITMs on TCP!)

To summarise the raw claims (again, given my limited understanding):

• attack bypasses all firewalls,
• can be used to own your router,
• bypasses IDS
• your browser needs to strike a malicious Flash, Java applets or javascript in some variants (needs sockets, Firefox delivers sockets through javascript??)
• Works on the 2 major browsers
• A simplified version has been seen in the wild, by bad guys
• No DNS fix, but there are some short term patches?

Fixes: No easy fixes, just temporary patches. DNS is operating as normal, it never was secure anyway, and the modes and tricks used are essential for a whole lot of stuff. Likewise, Flash, etc, which seem to have no more security than windows did in 2002, isn't going to be fixed fully, any time soon. (Dan mentioned he is waiting on Adobe to fix something before full disclosure, but that runs out as someone else is about to publish the same results.)

• The systemic fix: There is only one mode, and it's secure. Ok, I just had to add that in...
• The practical fix: Go TLS, everywhere.
• Timeframe: 3 years.
• Excuse: read on...

Here's the old worse news: Dan stated, as near as I can recall it:

"TLS solves the problem completely, but TLS does not scale to the net, because it does not indicate the host name. This puts more of an indictment on the standards process and on TLS than anything else, we've had TLS for years now, and we still can't share virtual hosts on TLS."

Yes, it's our old friend TLS/SNI (ServerNameIndication), a leprechaun-like extension that converts TLS from a marginal marketing differentiator at ISPs into a generally deployable solution.

• old friend 1
• old friend 2
• old friend 3
• old friend 4

SNI is available in Firefox, 2.0 and later. Thanks to Mozilla, they did actually started a project on this called SSL v2 MUST DIE because of its ability to help in phishing (same logic, same fix, same sad sorry story). It is fixed in IE7, but only in Vista, so that's short thanks to Microsoft. Opera's got it, and they might have been the first.

Yet...

TLS/SNI is not available in Apache's httpd nor in Microsoft's IIS.

Indeed, I tried last year to contact the httpd team and plead for it. Nothing, it's as if they don't exist. Mozilla were even prepared to pay these guys to fly & fix, but we couldn't find anyone to talk to. Worse, they have had the code for yonks. The code builds, at least the gnutls version. The code works:

• Apache-could-have-SNI, SITE ONE: https://dave.sni.velox.ch/
• Apache-could-save-the-net, SITE TWO: https://sni.velox.ch/

I got proof that Microsoft's team exists, and that they also have no plans to secure the Internet this year.

Shame, the very shame! Apache's httpd team and Microsoft's IIS team are now going to watch 3 years of pain and suffering, for the want of little fix that is so old that nobody can recall when it was added to the standard.

(OK, that's the last I heard. There might be updates in the shame. You understand that it isn't my day job to get you to save the net. It is however your day job, Microsoft team, and night job, Apache team, and you can point out current progress in the comments or on your blog or in the very code, itself. Please, we beg you. Save our net.)

Addendum: a rebinding patch! and some more from the department of snails.

Susan Landau on threats to the USA: don't forget Pogo

The Washington Post, in the person of Susan Landau, lays out in more clear terms where USA cyber-defence is heading

The immediate problem is fiber optics. Until recently, telecommunication signals came through the air. The NSA used satellites and antennas to pick up conversations of foreigners talking to other foreigners. Modern communications, however, use fiber; since conversations don't go through the air, the NSA wants to access communications at land-based switches.

Because communications from around the world often go through the United States, the government can still get access to much of the information it seeks. But wiretapping within the United States has required a FISA search warrant, and the NSA apparently found using FISA too time-consuming, even though emergency access was permitted as long as a warrant was applied for and granted within 72 hours of surveillance.

Avoiding warrants for these cases sounds simple, though potentially invasive of Americans' civil liberties. Most calls outside the country involve foreigners talking to foreigners. Most communications within the country are constitutionally protected -- U.S. "persons" talking to U.S. "persons." To avoid wiretapping every communication, NSA will need to build massive automatic surveillance capabilities into telephone switches. Here things get tricky: Once such infrastructure is in place, others could use it to intercept communications.

Grant the NSA what it wants, and within 10 years the United States will be vulnerable to attacks from hackers across the globe, as well as the militaries of China, Russia and other nations.

Landau choses the evil foreign hacker as her bogeyman. This is is understandable if we recall who her audience is. The threat however is closer to home; to paraphrase Pogo, Americans have not yet met their enemy, but he is you.

A basic assumption of security was that the NSA was historically no threat to any person, only to nations. Intel info was closely guarded, and breaches of this info was a national security breach, we the people were far better protected by the battle against foreign spies than anything else. No chinese wall, then, more a great wall-of-china around secret tracts of Maryland.

Now that wall-of-china has been torn down and replaced by trade-grade chinese walls. Breaching chinese walls simply requires the right contact, the right excuse, the right story. Since 9/11, intel info and trade info are all one and the same, and it is now reasonable, expected even, that hundreds of thousands of new readers of data can trawl through criminal databases, intel summaries, background reports and the like.

For illumination, see the SWIFT battle. The problem wasn't that the NSA was reading the SWIFT traffic, it had been doing that for decades. The problem was the burgeoning spread of the data, as highlighted by events: the Department of Justice now felt it reasonable, indeed required, to get in on the act. Pundits will argue that it was a governed programme, but its secret governance was a setup for more breaches. It wasn't the first, nor the second, and it wasn't going to be the last. If we had to choose between the evil chinese hacker and the enemy-who-is-us, I for one would take the evil chinese hacker every time. We can deal with the external enemy, we know how. But the internal enemy, the enemy who is us, he is the destruction of civil society, and there is no army to fight that threat.

Mozilla gets proactive about browser security?

This article reports that Mozilla are now proactive on security. This is good news. In the past, their efforts could be described as limited to bug patching and the like. Reactive security, in other words, which is what their fuzzer is:

Mozilla has been using an open-source application security testing tool, known as a fuzzer, for JavaScript to detect and fix dozens of security bugs in Firefox, Mozilla director of ecosystem development Window Snyder said Thursday at the Black Hat USA 2007 conference in Las Vegas. The JavaScript fuzzer found 280 bugs in Firefox, 27 of which were exploitable.

Now Mozilla is making that JavaScript fuzzer available to anyone who wants to use it, and it'll be followed later this year by fuzzers for the HTTP and FTP protocols.

"The FTP and HTTP protocol fuzzers act like fake servers that send bad data to sites," Snyder told InformationWeek.The HTTP fuzzer emulates an HTTP server to test how an HTTP client handles unexpected input. The FTP fuzzer likewise tests how an FTP client handles unexpected data.

Now however there is at least one person employed directly on thinking about security in a proactive sense:

Expect Firefox 3 to include new phishing and malware protection, extended validation certificates, improved password management, and a security user interface.

One could criticise this all as too little, too late, too "interests-driven". But changing cultures to think, really think about security is hard. It doesn't happen overnight, and it at least takes years. Consider that Microsoft has been working since 2003 to make this change, and the evidence is not here that their product is secure, yet, shows how hard it is.

Shock of new Security Advice: "Consider a Mac!"

From the where did you read it first? department here comes an interesting claim:

Beyond obvious tips like activating firewalls, shutting computers down when not in use, and exercising caution when downloading software or using public computers, Consumer Reports offered one safety tip that's sure to inflame online passions: Consider a Mac.

"Although Mac owners face the same problems with spam and phishing as Windows users, they have far less to fear from viruses and spyware," said Consumer Reports.

Spot the difference between us and them? Consumer Report is not in the computing industry. What this suggests about being helpful about security will haunt computing psychologists for years to come.

For amusement, count how many security experts will pounce on the ready excuse:

"Because Macs are less prevalent than Windows-based machines, online criminals get less of a return on their investment when targeting them."

Of course if that's true, it becomes less so with every Mac bought.

Can you say "monoculture!?"

U.S. consumers lost $7 billion over the last two years to viruses, spyware, and phishing schemes, according to Consumer Report's latest State of the Net survey. The survey, based on a national sample of 2,000 U.S. households with Internet access, suggests that consumers face a 25% chance of being victimized online, which represents a slight decline from last year.

Computer virus infections, reported by 38% of respondents, held steady since last year, which Consumer Reports considers to be a positive sign given the increasing sophistication of virus attacks. Thirty-four percent of respondents' computers succumbed to spyware in the past six months. While this represents a slight decline, according to Consumer Reports, the odds of a spyware infection remain 1 in 3 and the odds of suffering serious damage from spyware are 1 in 11.

Phishing attacks remained flat, duping some 8% of survey respondents at a median cost of $200 per incident. And 650,000 consumers paid for a product or service advertised through spam in the month before the survey, thereby seeding next year's spam crop.

Perversely, insecurity means money for computer makers: Computer viruses and spyware turn out to be significant drivers of computer sales. According to the study, virus infections drove about 1.8 million households to replace their computers over the past two years. And over the past six months, spyware infestations prompted about 850,000 households replace their computers.

Verisign reminder of what data security really means

From the 'poignant reminder' department, Verisign lost a laptop with employee data on it.

The employee, who was not identified, reported to VeriSign and to local police in Sunnyvale, Calif. that she had left her laptop in her car and had parked her car in her garage on Thursday, July 12. When she went out the next morning, she found that her car had been broken into and the laptop had been stolen.

Possibly a targetted theft?

The thing is, this can happen to anyone. Including Verisign, or any CA, or any security company. This can happen to you, and probably will, regardless of your policies (which in this case includes no employee data on laptops and using encrypted drives).

The message to take away from this is not that Verisign is this week's silly sausage, or that their internal security is lax. This can and will happen to anyone. Instead, today's message is that the there is a gap between security offerings and security needs so large that crooks are driving trucks through it every day, and have been for 4 years.

I estimated a billion dollars in 2004 or so from phishing alone, and now conservative estimates in other post today say it is around 3bn per year. (I say conservative because Lynn posts other numbers that are way higher.) That truck is at least 10 million dollars a day!

Still not convinced? Consider this mistake that the company made:

In its employee letter, VeriSign offered a year of free credit monitoring from Equifax for any affected individual, and recommended placing fraud alerts on credit accounts to watch for signs of fraud or identity theft.

If Verisign can offer a loss-leader zero-margin recovery product to the victims of their own failure, what hope has the rest of the computing industry?

Doom and Gloom spreads, security revisionism suggests "H6.5: Be an adept!"

The doom and gloom in the security market spreads. This time it is from Richard Bejtlich who probably knows his stuff as well as any (spotted at Gunnar's 1raindrop). After a day at Black Hat, the expensive high-end "shades of illegal" conference in security, he concludes:

• Existing defenses are absolutely ineffective against current attacks....
• Detecting current attacks in "real time" is increasingly difficult, if not impossible....
• The average Web developer and security professional will never be able to counter these attacks....

Note how he includes the security professional in there. Yup. The problem is that the knowledge space has ballooned and nobody can keep up; Internet security is now a game that is way to broad for anyone to really cover it all.

Even before the current "war on everyone" you still had several problems with the security industry: lack of understanding of the business, which fed into poor choices being generally too expensive, and a tendency to "best practices:" purchased products because brands deliver CYA as well as high prices, etc etc. Over time, industry discovered they made more money if they didn't hand it over to security ... until 2003 that is, when phishing found its lure.

If then, you can't find someone to do it for you, you have to do it yourself. This is what I called Hypothesis #6 "It's your job. Do it." But exactly what does that mean?

#6.5 You need to be an adept in many more aspects

In all probability you will need to be adept -- well versed if not expert -- in all aspects, right up to user activity. This will stretch you away from the deep cryptographic and protocol tricks that you are used to as you simply won't have time for all that. But an ability to bridge from user needs all the way across to business needs, and then down to crypto bits is probably much more valuable than knowing yet another crypto algorithm in depth.

The FC7 thesis is that you need to know Rights, Accounting, Governance, Value and Finance as well as Software Engineering and Cryptography. You need to know these things in some depth not to use them but to avoid using them! And, more particularly, avoid their hidden costs, by asking the difficult questions about the costs that nobody else dare recognise.

Perhaps the best example was the decision by Microsoft to stop coding and start training all their coders in security practices. Not just some of them, all of them!

Where this leaves the conventional security professional is perhaps an open question. I would prefer to say that instead of prescribing solutions and sometimes supplying them, he would shift to training and guiding. This would involve a different emphasis: if you assess that an IDS might help, in the past you sold an IDS. Now, however, you would assess whether the team leader could cope with an IDS, pointed her in that direction, and mentored the assessment of the tool by the entire team. If they aren't up to that, then you have another problem.

National insecurity - all your packets are belong to US

A secret court ruled the US Government's wiretapping programme illegal, and the US Government claimed that revealing this fact released confidential activity. So illegality is OK if confidential? No, not before the courts, last I heard, but we'd need a lawyer to explain why the courts will not rely on illegality as a defence, and why we should not?

In similar news, it was revealed that then-Attorney General, Ashcroft, stated unequivocably that the programme was illegal, from his sickbed. He was immediately replaced with incumbent, Alberto Gonzalez, who some in Congress wonder if his testimony amounts to perjury.

Other news suggested that what was going on was the desire to start wiretapping (read: real-time direct feed to the NSA) of all the trans-US traffic. FISA, apparently, "requires a warrant to monitor calls intercepted in the United States, regardless of where the calls begin or end." A fair enough metric, 30 years ago.

Yet, if I call from Britain to Japan, chances are fair that the call is routed through the US, because that's where most of the fibre is. The hub & spoke effect is much more important for the Internet, where a much higher percentage of traffic is routed through the USA. Indeed, pretty much everything Internet-related is spoked around the US hub: Hosting, IP#s, startups, skills, etc.

Why not tap that, as it doesn't involve the inconvenience of US citizens? A good question, from an intelligence point of view, it's just another Black Chamber operation, updated for the 21st century, and it's easy pickings.

There are many reasons to oppose this, such as "We just can't suspend the Constitution for six months," but the one I like best is the simplest: if the NSA gets direct feeds of all fibre communications trans-shipping through the US, then two things will happen: Firstly, by laws of economics not Congress, this tapping will eventually include all US-terminated conversations.

Secondly, it might kick the rest of the world into gear and start responding to the basic threat of aggressive and persistent listening. Perversely, one might suggest that we shouldn't oppose the US, as we need a validated threat to focus our security efforts.

Indeed, if one surmises that the US government have been told their programmes are illegal, one can question whether the NSA is not already tapping all trans-shipped traffic, and is probably not adequately filtering the locally terminated traffic.

All your packets are belong to US. You have been warned: Deploy more crypto, guys.

more on firing your MBA-less CSO

BTW, if you think firing the CSO's boss is harsh, then consider that others do not think so:

The United Kingdom's information commissioner is calling on chief executives to take the security of customer and staff information more seriously.

"The roll call of banks, retailers, government departments, public bodies and other organizations which have admitted serious security lapses is frankly horrifying," Richard Thomas wrote in a report. "How can laptops holding details of customer accounts be used away from the office without strong encryption? How can millions of store card transactions fall into the wrong hands?"

The Information Commissioner's Office (ICO) received almost 24,000 inquiries and complaints concerning personal information, and it prosecuted 16 individuals and organizations in the past 12 months, according to its annual report for 2006 and 2007.

Another way of thinking of this is to look at these sorts of questions:

• does security have ROI, and so what?
• what other part of the business has the same problem with ROI?
• What is the difference between marketing, sales, and strategy, and which should the CSO be involved in?
• Should HR use automated psych tests for job interviews for security consultants, and why?
• Does the security group prefer product placement, endorsement, word-of-mouth, or straight superbowl ... and why?

Click on if you want some answers. Now, it's not necessary to be able to answer these right off, but you do need to know what they mean.

Answers:

• Yes, but it suffers from GIGO -- too hard to predict what the attacker will do to the security product, so not possible to predict the results with any accuracy.
• advertising.
• That depends on how robust the security is. If highly robust, then strategy. If not robust, then marketing and sales, to ensure careful disclaimers.
• No, because they aren't sufficiently accurate, and require feedback the individual to be meaningful. Who you haven't employed as yet. If they are used, it means HR will operate as a filter for diversity and the company will suffer from group think. This will then create security blind spots.
• Word-of-mouth contributes security advantages, others have little effect on security directly, but will probably work faster in mainstream markets for standard products.

OK, so all of those are debateable. But that's the point, unless you can debate them on the same turf as your other managers, your lost. You can't contribute security if you don't understand her area enough to contribute.

Know Your Enemy: Scott McNealy on security theater

People who don't know about security, but talk about it, are dangers to security. Those who are in the security field can determine the difference between 'security theater' and real security ... but unfortunately those outside are often swayed by simple and easy sales messages.

Scott McNealy did the privacy world a huge favour by saying "Privacy is dead, get over it." Perhaps he's also doing another favour by issuing a wake-up call to the world:

McNealy said that to overcome the "efficiency tax" travelers are facing at airports with long lines, it will make sense to begin adopting identity cards that are smart-card-enabled. These can be supplemented by biometric identification such as a thumbprint scanner, all of which can be done more efficiently than "50 security guards."

...

McNealy said it would be better to know who is on a plane or in a mall where a terrorist strikes, adding that it wouldn't be necessary to know who is buying what.
He said he realizes that his views might be interpreted as a way to sell more hardware and software at Sun. But, "I'm a parent, and I care about my kids," he said.

McNealy said he envisions the day when parents implant smart chips behind the ears of their children for identification purposes. "My dog has a chip [implant], and it's interesting [that] we treat a dog better than our kids," he said.
Several attendees said they thought implants seemed extreme or at least something that Americans won't want to consider for years to come. But they all agreed that technology will have to play a bigger role in security, especially at airports.

After his talk, McNealy met briefly with reporters and was asked if he seriously intended to endorse chip implants. "We are going to move to smart cards and chips ... so we feel safe," he said.

It sounds more like a DHS press release than anything else. Te detailed problem with all that McNealy says is that we know smartcards and chips do not deliver security (again, see Lynn in comments on rollouts of smartcard systems) but they can dramatically destroy privacy .. which is a reduction of security. Yet, high-profile organisations like Sun and DHS will continue to press security theater as it is good for their growth.

If your CSO lacks an MBA, fire one of you

Thinking a bit about the theme of security v. management [1,2, 3], here is today's thesis:

The CSO should have an MBA.

As a requirement! Necessary (but maybe not sufficient) for the Chief Security Officer job.

That being a slightly contentious issue, as most of y'all CSOs out there don't have an MBA, the onus is on me now to prove it, or swallow humble pie. Well, this is the blog for being years ahead of the trends, so let's get on with it then.

Consider some factors.

1. No understanding. Frequently heard are the brickbats that accuse managers of doing stupid things. See if you can find a non-security guy doing or saying something sensible! It's quite simple for us to state why this happens: non-security people don't understand what the security guys are talking about.
2. No Voice. It's been grudgingly accepted for some years now that security people are not listened to. In the sense that your chief security dude can rabbit about any threat or any project and get nowhere.
3. Failure. It is a no-brainer that today's security field is a mess. Windows botnets, Linux attack platforms, spam and phishing, MITBs, unholy virus company alliances... these things run rampant and we can't do much about them. Worse, those that predicted it were ignored, those that sold stuff did well, those that rode the wave from flavour to favour did best. We now have a permanent and industrialised degree of fraud that belongs to the security industry, in place, which Lynn suggests in comments is better than drugs. Oh happy day, full employment for the CSO.

Maybe, 1 and 2 are opposite sides to the same coin, and spending that coin got us to 3. Which brings us to this point: we can pretty much assume that there is a huge gulf of understanding between the security world and the business world.

In order to fix all this, we have to generate understanding.

(Either that, or switch of the systems. Now, the security guys sometimes say exactly that, but the business guys don't listen, so we're back to looking at the real problem.)

Assume then the basic failure is one of understanding. We can do one of several things: train all the managers in security, train all the security people in business, or put in the middle a liaison who knows both security and business.

Let's kill the two easy options: Managers by definition know a little of everything, enough to be dangerous, and do not get trained up much in anything except whatever their original skill was. And for your average manager, those days of early skill training are over.

The second easy option is training the security people. But, that's a hopeless task. Firstly, where they come from, they have little background in business (generally, from IT. Worse is cryptography, better is military, for business exposure at least.). Secondly, it's a full-time job keeping up with just security, let alone learning stuff about business. The reverse difficulty could apply to managers, option 1 above.

Which leaves option #3: the liaison. Now, we can pretty easily see by process of elimination that the liaison has to be the CSO. So the question reduces to: what does the CSO need to be a successful liaison between security and business?

He needs the full capability to talk to the managers, and the security people. The latter means he *is* a security person, because by the law of guruism, to gain the respect of the gurus, you have to be one of them. The former means he *is* a manager.

But we need to go one step further. Because security cuts across all areas of the business in the way that HR, marketing, auditing, customer support does ... and transport, printing, sales, cleaning do not ... then the security honcho needs to understand a lot more of the business areas than the average manager does.

See the difference? Because security is against an aggressive attacker, because attacks can occur anywhere, the problems are broad and complex, and because the solutions strike across all areas, then .... if our CSO hasn't the skills to talk each manager, at her level, on her turf, not his, then he's lost.

There are only two ways that I can think of to get the knowledge to be able to talk at the same level as all of the other managers: Either you go fast-track, which means being shoved from department to department, 1-2 years each one, or you can pick it up in a condensed package called an Masters of Business Administration. The former is done, but it takes decades of time in either a very large corporation or the military. Scratch that as an option, as it also means our CSO won't be up to scratch as a security person. Hence, we are left with one option:

The CSO needs an MBA.

QED.

(Which will still cost you minimum one year; full time MBAs are generally 10 to 22 months, part time ones are up to 36 months ... but that's implementation details).

(Addendum, for scoring easy points against the above logic, Disclosure: I have an MBA :-) )

Threatwatch: how much to MITM, how quickly, how much lost

It costs $500 for a kit to launch an MITM phishing attack. (Don't forget to add labour costs at 3rd world rates...)

David Franklin, vice president for the Europe, Middle East and Africa told IT PRO that these sites are proliferating because they are actually easier for hackers to set up than traditional 'fake' phishing sites because they don't even have to maintain a fake website. He also said man-in-the-middle attacks defeat weak authentication methods including passwords, internet protocol (IP) geolocation, device fingerprinting, cookies and personal security images and tokens, for example.

"A lot of the attacks you hear about are just the tip of the iceberg. Banks often won't even tell an affected customer that they have been a victim of these man-in-the-middle attacks," said Franklin, adding that kits that guide cybercriminals through setting up a man-in-the-middle attack are now so popular they can be bought for as little as $500 (£250) on the black market now.

He also said "man-in-the-browser" attacks are emerging to compete in popularity with middleman threat.

A couple of interesting notes from the above: it is now accepted that MITM is what phishing is (in the form mentioned above, the original email form, and the DNS form). These MITMs defeat the identity protection of SSL secure browsing, a claim made hereabouts first. and one that is still widely misunderstood: This is significant because SSL is engineered to defeat MITMs, but it only defeats internal or protocol MITMs, and can not stop the application itself being MITM'd. This typical "bypass attack" has important economic ramifications, such that SSL is now shown to be too heavy-weight to deliver value, unless it is totally free of cost and setup.

Secondly, note that the mainstream news has picked up the MITB threat (also reported and documented here first). It's still rare, but in the next 6 months, expect your boss to ask what it's about, because he read it in Yahoo.

More juicy threat modelling numbers:

Analysts at RSA Security early last month spotted a single piece of PHP code that installs a phishing site on a compromised server in about two seconds,

And....

Despite efforts to quickly shut sites down, phishing sites averaged a 3.8-day life span in May, according to the Anti-Phishing Working Group, which released its latest statistics on Sunday.

Data from market analyst Gartner released last month showed that phishing attacks have doubled over the last two years.

Gartner said 3.5 million adults remembered revealing sensitive personal or financial information to a phisher, while 2.3 million said that they had lost money because of phishing. The average loss is US$1,250 per victim, Gartner said.

In the past (June 2004: 1, 2), I've reported that phishing costs around one billion per year. Multiply those last two numbers above from Gartner, and we get around a billion over the last three years. Still a good rule of thumb then.

SWIFT breach -- class action suit, can we rely on government for privacy of financial data?

It's been a while since SWIFT was in the news, but they're back! Chris points out that a class action suit has been permitted against them in Federal court:

In his 20-page opinion, Judge Holderman rejected SWIFT's defense that it acted in good faith by relying on government subpoenas. Any claim to "unfettered government access to the bank records of private citizens" is "constitutionally problematic", the court said.

In refusing to dismiss the case, Judge Holderman noted reports that "SWIFT officials were aware that their disclosures were legally suspect, but they nevertheless continued to supply database information to the U.S. government."

This might follow the progress of the illegal wiretapping case before Judge Diggs. There, the state said "state secrets" and the Judge responded "it's not a secret anymore..."

Which means illegal behaviour can be tried. Why are we so interested? Behaviour that is "probably illegal" and "definately deceptive" behaviour needs to be documented because that might suggest a finding that the US government cannot be expected to secure the privacy of any data. This applies more easily to that of foreigners and their SWIFT data, but customarily, what applies to foreigners soon then applies to locals (laws aside).

For example, Todd reports that the French are having trouble stopping their parliamentarians from passing their secrets across on Blackberries:

Members of the new French cabinet have been told to stop using their BlackBerries because of fears that the US could intercept state secrets. The SGDN, which is responsible for national security, has banned the use of the personal data assistants by anyone in the president’s or prime minister’s offices on the basis of “a very real risk of interception” by third parties.

The ban has been prompted by SGDN concerns that the BlackBerry system is based on servers located in the US and the UK, and that highly sensitive strategic information being passed between French ministers could fall into foreign hands. A confidential study carried out two years ago by Alain Juillet, the civil servant in charge of economic intelligence, found that the BlackBerry posed “a data security problem”.

Mr Juillet noted that US bankers would prove their bona fides in meetings by first placing their Black­Berries on the table and removing the batteries.

Some older notes.

Military intel is now accessing bank accounts of US persons. Now, this falls somewhat in the bucket of "expected" so why comment? Two possible reasons. Firstly, because we have a number:

Military intelligence officials have used the letters in about 500 investigations over the past five years, while the CIA issues a 'handful' of such letters every year, The Times wrote on its website late Saturday. Civil rights experts and defence lawyers were critical of the practice.

In comparison, the domestic law enforcement agency, the Federal Bureau of Investigation (FBI), makes much more frequent use of the letters to get financial information, and served about 9,000 such letters in 2005 alone, said justice officials.

( old dead link.) With numbers, we can calculate risk scenarios for financial cryptography applications. (It might be more interesting to some for example to look at total Internet intercepts; but we could hazard a guess that this is the same order of magnitude.)

The Times cited two examples where the military used the letters - one was a government contractor with unexpected wealth, another was a Muslim chaplain at Guantanamo Bay prison for terrorist suspects.

Secondly, because of the above privacy question. Concentrate on the first case: this is a clear suggestion of fraud. That's a regular crime. There are courts, judges, prosecutors, defence attorneys, and PIs lined up from coast to coast in the US for that sort of thing. So why did the military bypass normal chains of investigation and prosecution, and use the nuclear option?

Because it could. There is no climate of fear of prosecution for overstepping the bounds. There is no particular climate that tools should be limited in use. This would support a finding that data will be misused.

Caveat: we probably need to verify those statements before getting too confident.

PKI moving to adopt the plugin model -- realignment to security based on user-needs?

One of the things that occurred in the early days of phishing was the realisation that the browser (and its manufacturer) was ill-suited to dealing with the threat, even though it was the primary security agent (c.f., from the SSL promise to defeat the MITM). One solution I pushed a lot was plugin security -- adding the authentication or authorisation logic into plugins so that different techniques could experiment and evolve.

In hindsight, this will appear obvious. 99% of the client-side security work involved plugins -- Trustbar, Netcraft, Petname, Ping's design, and many others. But it required a mindshift from "this is a demo" to "this is where it should be." This became poignant in the discussions of what to do about EV -- if Mozilla adopted EV into the browser, that opened a huge can of worms. Hence, putting EV in the plugin was the logical conclusion.

Now it seems to have happened:

Verisign Inc. has [...snip] released a Firefox plugin that will show the same type of green address bar that is displayed by Internet Explorer 7 when it lands on certain highly trusted Web sites that use Extended Validation Secure Sockets Layer (EV SSL) certificates.

Before companies like Verisign will issue an EV SSL certificate, they take extra steps to make sure that it is going to a legitimate organization. For example, they will make sure that the business in question is registered with local authorities, has a real address, and actually has control over the Web domain in question.

Earlier, I suggested that understanding EV in terms of security is futile. More, look to structural issues:

Verisign's Tim Callan says that more than 500 Web sites, including sites run by eBay's PayPal division and ING Group, have now completed EV SSL certification. Nearly 90 percent of them are certified by Verisign, said Callan, a director of product marketing with the company's SSL group.

That was the plan. Consider how much value there is in the other CAs scrabbling around the crumbs of 10% of the market, versus the costs of the EV programme. Even more to the point:

That's an important point because Verisign's Firefox plugin doesn't identify sites that are certified by its competitors. Callan said it would have been too much work to maintain a list of legitimate EV SSL providers. "At that point, we're creating a whole new simultaneous real-time checking system," he said. "We were willing to invest in this one-off code development, but we didn't want to inherit this legacy of constantly maintaining this service, especially because this is a stop-gap measure. At the end of the year, this will be built into Firefox proper."

Can you say barriers to entry ? Once a site has been EV'd by Verisign, it is unlikely to shift, and that's what they wanted. If that doesn't work, ask Callan to say OCSP, which is written large into the EV draft (!) specification ...

Leaving aside the industry structural games, let's get back to PKI. There is a silver lining: EV means that it now becomes Verisign's responsibility to authenticate these sites to the user.

The *only* way to do that is in a way that is clearly expressed as "by Verisign" and the plugin makes this clear. If the browser takes on that responsibility, it breaks the statement, and therein lies the future breach of EV and the past failure of the security model.

Since long ago, we have hammered on one of the failures of the SSL server certificate market: "all CAs are alike." They were not, are not, and cannot be, and why the developers hung on to this blatantly and obviously false myth was mystifying to me.

Verisign has now broken it, and broken it good. For that we should all be thankful, and in time, we will see a differentiated CA market, which allows new products and new security postures to meet the divergent needs of users.

No such thing as provable security?

I have a lot of skepticism about the notion of provable security.

To some extent this is just efficient hubris -- I can't do it so it can't be any good. Call it chutzpah, if you like, but there's slightly more relevance to that than egotism, as, if I can't do it, it generally signals that businesses will have a lot of trouble dealing with it. Not because there aren't enough people better than me, but because, if those that can do it cannot explain it to me, then they haven't got much of a chance in explaining it to the average business.

Added to that, there have been a steady stream of "proofs" that have been broken, and "proven systems" that have been bypassed. If you look at it from a scientific investigative point of view, generally, the proof only works because the assumptions are so constrained that they eventually leave the realm of reality, and that's particularly dangerous to do in security work.

Added to all that: The ACM is awarding its Godel prize for a proof that there is no proof:

In a paper titled "Natural Proofs" originally presented at the 1994 ACM STOC, the authors found that a wide class of proof techniques cannot be used to resolve this challenge unless widely held conventions are violated. These conventions involve well-defined instructions for accomplishing a task that rely on generating a sequence of numbers (known as pseudo-random number generators). The authors' findings apply to computational problems used in cryptography, authentication, and access control. They show that other proof techniques need to be applied to address this basic, unresolved challenge.

The findings of Razborov and Rudich, published in a journal paper entitled "Natural Proofs" in the Journal of Computer and System Sciences in 1997, address a problem that is widely considered the most important question in computing theory. It has been designated as one of seven Prize Problems by the Clay Mathematics Institute of Cambridge, Mass., which has allocated $1 million for solving each problem. It asks - if it is easy to check that a solution to a problem is correct, is it also easy to solve the problem? This problem is posed to determine whether questions exist whose answer can be quickly checked, but which require an impossibly long time to solve.

The paper proves that there is no so-called "Natural Proof" that certain computational problems often used in cryptography are hard to solve. Such cryptographic methods are critical to electronic commerce, and though these methods are widely thought to be unbreakable, the findings imply that there are no Natural Proofs for their security.

If so, this can count as a plus point for risk management, and a minus point for the school of no-risk security. However hard you try, any system you put in place will have some chances of falling flat on its face. Deal with it; the savvy financial cryptographer puts in place a strong system, then moves on to addressing what happens when it breaks.

The "Natural Proofs" result certainly matches my skepticism, but I guess we'll have to wait for the serious mathematicians to prove that it isn't so ... perhaps by proving that it is not possible to prove that there is no proof?

Is this Risk Management's Waterloo?

So why can't we do it? In short, we do know that all security is really about risk management. So we just do risk management, right?

Igor says we can do it, in comments. Chandler says it is hard. He lists a dozen or so reasons why.

To which I'll add one: the attacker is aggressive. Whatever we measure, the attacker actively perverts. So, unlike insurance models, security doesn't work well with just statistics. Much as we say we need more data, if we had all the data in the world, and fixed what we could see, the attacker would simply move faster than we could.

A trio of notes:

• Note that this isn't to say that he is the uber-attacker, the Superman recently much discussed. He's just us, on the other side. Or, better yet, pick the middling competent programmer down the hall. We fix the bugs, why can't they? The point being to stop thinking about the bipolar choice of attacker as dense as mould, or as smart as Moriarty.
• Another thing that Lynn has pointed out is that the attacker can outspend the defender, sometimes as much as by 100:1. Indeed, recently, the USG agencies were reported to receive $10m in funding ... for an attacker that is causing losses of more than a billion per year.
• On the question of "more data," a meme that is somewhat current: the paper that Igor mentioned pointed to http://phishtank.com/ which is some sort of volunteer group to validate URLs, and provide data. They are the same people as http://openDNS.com/ which provide DNS with a phishing filter. Nice twist, but note the perversion.

So, there are some issues here. Are there limits to the risk management approach, beyond the fact that it seems to be beyond the capabilities of the industry? Has it reached its Waterloo, against the active, mildly competent attacker with 100 times the spend?

The Myth of the Superuser, and other frauds by the security community

The meme is starting to spread. It seems that the realisation that the security community is built on self-serving myths leading to systemic fraud has now entered the consciousness of the mainstream world.

Over on the Volokh Conspiracy, Paul Ohm, exposes the Myth of the Superuser. His view is that too often, the sense of the Superuser is one of an overpowering ability of this uber-attacker. Once this sense enters the security agenda, the belief that there is this all-powerful evil criminal mastermind out there, watching and waiting, leads us into dangerous territory.

Ohm does not make the case that they do not exist, but that their effect or importance is greatly exaggerated. I agree, and this is exactly the case I made for MITM. In brief, the Man-in-the-middle is claimed to be out there lurking, and we must protect, at any costs. Wrong on all counts, and the result is a security disaster called phishing, which in itself is an MITM.

Then, phishing can be interpreted as a result of our obsession with Ohm's Superuser, the uber-attacker. In part, at least, and I'd settle for running the experiment without the uber-obsession. Specifically, Ohm points at some bad results he has identified:

Very briefly, in addition to these two harms — overbroad laws and civil liberties infringements — the other four harms I identify are guilt by association (think Ed Felten); wasted investigative resources (Superusers are expensive to catch); wasted economic resources (how much money is spent each year on computer security, and is it all justified?); and flawed scholarship (See my comment from yesterday about DRM).

All of which we can see, and probably agree on. What makes this essay stand out is that he goes the extra mile and examines what the root causes might be:

I have essentially been saying that we (policymakers, lawyers, law professors, computer security experts) do a lousy job calculating the risks posed by Superusers. This sounds a lot like what is said elsewhere, for example involving the risks of global warming, the safety of nuclear power plants, or the dangers of genetically modified foods. But there is a significant, important difference: researchers who study these other risks rigorously analyze data. In fact, their focus on numbers and probabilities and the average person’s seeming disregard for statistics is a central mystery pursued by many legal scholars who study risk, such as Cass Sunstein in his book, Laws of Fear.

In stark contrast, experts in the field of computer crime and computer security are seemingly uninterested in probabilities. Computer experts rarely assess a risk of online harm as anything but, “significant,” and they almost never compare different categories of harm for relative risk. Why do these experts seem so willing to abdicate the important risk-calculating role played by their counterparts in other fields?

Does that sound familiar? To slide into personal anecdote, consider the phishing debate (the real one back in 2004 or so, not the current phony one).

When I was convinced that we had a real problem, and people were ignoring it, I reasoned that the lack of scientific approach was what was holding people back from accepting the evidence. So I started collecting numbers on costs, breaches, and so forth (you'll see frequent posts on the blog, also mail postings around). I started pushing these numbers out there so that we had some grounding in what we were talking about.

What happened? Nothing. Nobody cared. I was able around 2004 to state that phishing already cost the USA about a billion dollars a year, and sometime shortly after that, that basically all data was compromised. In fact, I'm not even sure when we passed these points, because ... it's not worth my trouble to even go back and identify it!

Worse than nobody caring, the security field simply does not have the conceptual tools to deal with this. A little bit like "everyone was in denial" but worse, there is a collective glazed view to the whole problem.

What's going on? Ohm identifies 4 explanations (in point form here, but read his larger descriptions):

1. Pervasive secrecy...
2. Everyone is an Expert...
3. Self-Interest...
4. The Need for Interdisciplinary Work...

No complaint there! Readers will recognise those frequent themes, and we could probably collectively get it to a list of 10 explanations without too much mental sweat.

But I would go further. Deeper. Harsher.

I would suggest that there is one underlying cause, and it is structural. It is because security is a market for silver bullets, in the deep and economic sense explained in that long paper. All of the above arise, in varying degrees, in the market first postulated by Michael Spence.

The problem with this is that it forces us to face truths that few can deal with. It asks us to choose between the awful grimness of helplessness, and the temptation to the dark side of security fraud, before we can enter any semblance of a professional existance. Nobody wants to go there.

Threatwatch: Still searching for the economic MITM

One of the things we know is that MITMs (man-in-the-middle attacks) are possible, but almost never seen in the wild. Phishing is a huge exception, of course. Another fertile area is wireless lans, especially around coffee shops. Correctly, people have pointed to this point as a likely area where MITMs would break out.

Incorrectly, people have typically confused possibility with action. Here's the latest "almost evidence" of MITMs, breathtakingly revealed by the BBC:

In a chatroom used to discuss the technique, also known as a 'man in the middle' attack, Times Online saw information changing hands about how security at wi-fi hotspots – of which there are now more than 10,000 in the UK – can be bypassed.

During one exchange in a forum entitled 'T-Mobile or Starbucks hotspot', a user named aarona567 asks: "will a man in the middle type attack prove effective? Any input/suggestions greatly appreciated?"

"It's easy," a poster called 'itseme' replies, before giving details about how the fake network should be set up. "Works very well," he continues. "The only problem is,that its very slow ~3-4 Kb/s...."

Another participant, called 'baalpeteor', says: "I am now able to tunnel my way around public hotspot logins...It works GREAT. The dns method now seems to work pass starbucks login."

Now, the last paragraph is something else, it is referring to the ability to tunnel through DNS to get uncontrolled access to the net. This is typically possible if you run your own DNS server and install some patches and stuff. This is useful, and economically sensible for anyone to do, although technically it may be infringing behaviour to gain access to the net from someone else's infrastructure (laws and attitudes varying...).

So where's the evidence of the MITM? Guys talking about something isn't the same as doing it (and the penultimate paragraph seems to be talking about DNS tunnelling as well). People have been demoing this sort of stuff at conferences for decades ... we know it is possible. What we also know is that it is not a good use of your valuable time as a crim. People who do this sort of thing for a living search for techniqes that give low visibility, and high gathering capability. Broadcasting in order to steal a single username and password fails on both counts.

If we were scientists, or risk-based security scholars, what we need is evidence that they did the MITM *and* they committed a theft in so doing it. Only then can we know enough to allocate the resources to solving the problem.

To wrap up, here is some *credible* news that indicates how to economically attack users:

Pump and dump fraudsters targeting hotels and Internet cafes, says FBI Cyber crooks are installing key-logging malware on public computers located in hotels and Internet cafes in order to steal log-in details that are used to hack into and hijack online brokerage accounts to conduct pump and dump scams.

The US Federal Bureau of Investigation (FBI) has found that online fraudsters are targeting unsuspecting hotel guests and users of Internet cafes.

When investors use the public computers to check portfolios or make a trade, fraudsters are able to capture usernames and passwords. Funds are then looted from the brokerage accounts and used to drive up the prices of stocks the frudsters had bought earlier. The stock is then sold at a profit.

In an interview with Bloomberg reporters, Shawn Henry, deputy assistant director of the FBI's cyber division, said people wouldn't think twice about using a computer in an Internet cafe or business centre in a hotel, but he warns investors not to use computers they don't know are secure.

Why is this credible, and the other one not? Because the crim is not sitting there with his equipment -- he's using the public computer to do all the dangerous work.

WSJ: Soft evidence on a crypto-related breach

Unconfirmed claims are being made on WSJ that the hackers in the TJX case did the following:

1. sat in a carpark and listened into a store's wireless net.
2. cracked the WEP encryption.
3. scarfed up user names and passwords ....
4. used that to then access centralised databases to download the CC info.

The TJX hackers did leave some electronic footprints that show most of their break-ins were done during peak sales periods to capture lots of data, according to investigators. They first tapped into data transmitted by hand-held equipment that stores use to communicate price markdowns and to manage inventory. "It was as easy as breaking into a house through a side window that was wide open," according to one person familiar with TJX's internal probe. The devices communicate with computers in store cash registers as well as routers that transmit certain housekeeping data.

After they used that data to crack the encryption code the hackers digitally eavesdropped on employees logging into TJX's central database in Framingham and stole one or more user names and passwords, investigators believe. With that information, they set up their own accounts in the TJX system and collected transaction data including credit-card numbers into about 100 large files for their own access. They were able to go into the TJX system remotely from any computer on the Internet, probers say.

OK. So assuming this is all true (and no evidence has been revealed other than the identity of the store where it happened), what can we say? Lots, and it is all unpopular. Here's a scattered list of things, with some semblance of connectivity:

a. Notice how the crackers still went for the centralised database. Why? It is validated information, and is therefore much more valuable and economic. The gang was serious and methodical. They went for the databases.

Conclusion: Eavesdropping isn't much of a threat to credit cards.

b. Eavesdropping is a threat to passwords, assuming that is what they picked up. But, we knew that way back, and that exact threat is what inspired SSH: eavesdroppers sniffing for root passwords. It's also where SSL is most sensibly used.

c. Eavesdropping is a threat, but MITM is not: by the looks of it, they simply sat there and sucked up lots of data, looking for the passwords. MITMs are just too hard to make them economic, *and* they leave tracks. "Who exactly is it that is broadcasting from that car over there....?"

(For today's almost evidence of the threat of MITMs see the BBC!)

d. Therefore, SSL v1 would have been sufficient to protect against this threat level. SSL v2 was overkill, and over-expensive: note how it wasn't deployed to protect the passwords from being eavesdropped. Neither was any other strong protocol. (Standard problem: most standardised security protocols are too heavy.)

TJX and 45 million americans say "thanks, guys!" I reckon it is going to take the other 255 million americans to lose big time before this lesson is attended to.

e. Why did they use a weak crypto protocol? Because it is the one delivered in the hardware.

Question: Why is hardware often delivered with weak crypto?

f. And, why was a weak crypto protocol chosen by the WEP people? And why are security observers skeptical that the new replacement for WEP will last any longer? The solution isn't in the "guild" approach I mentioned earlier, so forget ranting about how people should use a good security expert. It's in the institutional factors: security is inversely proportional to the number of designers. And anything designed by an industry cartel has a lot of designers.

g. Even if they had used strong crypto, could the breach have happened? Yes, because the network was big and complex, and the hackers could have simply plugged into some place elsewhere. Check out the clue here:

The hackers in Minnesota took advantage starting in July 2005. Though their identities aren't known, their operation has the hallmarks of gangs made up of Romanian hackers and members of Russian organized crime groups that also are suspected in at least two other U.S. cases over the past two years, security experts say. Investigators say these gangs are known for scoping out the least secure targets and being methodical in their intrusions, in contrast with hacker groups known in the trade as "Bonnie and Clydes" who often enter and exit quickly and clumsily, sometimes strewing clues behind them.

Recall that transactions are naked and vulnerable . Because the data is seen in so many places, savvy FCers assume the transactions are visible by default, and thus vulnerable unless intrinsically protected.

h. And, even if the entire network had been protected by some sort of overarching crypto protocol like WEP, the answer is to take over a device. Big stores means big networks means plenty of devices to take over.

i. Which leaves end-to-end encryption. The only protection you can really count on is end-to-end. WEP, WPA and IPSec and other such infrastruction-level systems are only a hopeful answer to an easy question, end-to-end security protocols are the real answer to application level questions.

(e.g., they could have used SSL for protecting the password access to the databases, end to end. But they didn't.)

j. The other requirement is to make the data insensitive to breaches. That is, even if a crook gets all the packets, he can't do anything with them. Not naked, as it were. End-to-end encryption then becomes a privacy benefit, not a security necessity.

However, to my knowledge, only Ricardo and AADS deliver this, and most other designers are still wallowing around in the mud of encrypted databases. A possible exception to this is the selective disclosure approach ... but for various business reasons that is even less likely to field than Ricardo and AADS were.

k. Why don't we use more end-to-end encryption with naked transaction protocols? One reason is that they don't scale: we have to write one for each application. Another reason is that we've been taught not to by generations: "you should use a standard security product." ... as seen by TJX, who *did* use a standard security product.

Conclusion: Security advice is "lowest common denominator" grade. The best advice is to use a standard product that is inapplicable to the problem area, and if that's the best advice, that also means there aren't enough FC-grade people to do better.

l. "Oh, we didn't mean that one!" Yeah, right. Tell us how to tell? Better yet, tell the public how to tell. They are already being told to upgrade to WPA, as if improving 1% of their network from 20% security to 80% security is going to help.

m. In short, people will seize on the encryption angle as the critical element. It isn't. If you are starting to get to the point of confusion due to the multiplying conflicts, silly advice, and sense of powerless the average manager has, you're starting to understand.

This is messy stuff, and you can pretty much expect most people to not get it right. Unfortunately, most security people will get it wrong too in a mad search for the single most important mistake TJX made.

The real errors are systemic: why are they storing SSNs anyway? Why are they using a single number for the credit card? Why are retail transactions so pervasively bound with identity, anyway? Why is it all delayed credit-based anyway?

Dr Geer goes to Washington

To round out this weekend's security hubris special, "Dr. Geer goes to Washington." To tell them how much trouble the net is in, seemingly. His points were 5-fold:

Summary

• We need a system of security metrics, and it is a research grade problem.
• The demand for security expertise outstrips the supply,and it is a training problem and a recruitment problem.
• What you cannot see is more important than what you can, and so the Congress must never mistake the absence of evidence for the evidence of absence, especially when it comes to information security.
• Information sharing that matters does not and will not happen without research into technical guarantees of non-traceability.
• Accountability is the idea whose time has come, but it has a terrible beauty.

Yes to his points 1,3,4,5, and we should read them. Which leaves:

Priority number two: The demand for security expertise outstrips the supply.

Information security is perhaps the hardest technical field on the planet. Nothing is stable, surprise is constant, and all defenders work at a permanent, structural disadvantage compared to the attackers. Because the demands for expertise so outstrip the supply,the fraction of all practitioners who are charlatans is rising. Because the demands of expertise are so difficult, the training deficit is critical. We do not have the time to create, as if from scratch, all the skills required. We must steal them from other fields where parallel challenges exist. The reason cybersecurity is not worse is that a substantial majority of top security practitioners bring other skills into the field; in my own case, I am a biostatistician by training. Civil engineers, public health practitioners, actuaries, aircraft designers, lawyers, and on and on — they all have expertise we can use, and until we have a training regime sufficient to supply the unmet demand for security expertise we should be both grateful for the renaissance quality of the information security field and we should mine those other disciplines for everything we can steal. If you can help bring people into the field, especially from conversion, then please do so. In the meantime, do not believe all that you hear from so-called experts. Santayana had it right when he said that “Skepticism is the chastity of the intellect; it is shameful to give it up too soon, or to the first comer.”

Well! An alternate but not radically diverging opinion.

Thanks to Gunnar

Security Expertise from Cryptographers: the Signals of Hubris

Over on the crypto forum, an old debate restarted where some poor schmuck made the mistake of asking why CBC mode should not have an IV of all zeros?

For the humans out there, a "mode" is way of using a block cipher ("encrypts only a block") to encrypt a stream. CBC mode chains each block to each next block by feeding the results from the last to the next ("cipher-block-chaining"). But, we need an initial value (IV) to start the process. In the past, zeros were suggested as good enough.

The problem surfaces that if you use the same starting key, and the user sends the same packet, then the encrypted results will be the same (a block cipher being deterministic, generally). So we use a different IV for every different use of the secret key, in order to cause different results, and hide the same packet being sent. (There are also some other difficulties, but these are not only much more subtle, they are beyond my ability to write about, so I'll skip past them blithely.)

Back to the debate. Predictably, there was little controversy over the answer ("you can't do that!"), some controversy over the fuller answer (what to do), but also more controversy over the attitude. In short, the crypto community displayed what might be considered a severe case of hubris:

"If you don't know, then you had better employ a security expert who does!"

There are many problems with this. Here's some of them:

1. At a guess, designing secure protocols is 50% business, 40% software, 10% crypto. So when you say "employ a security expert" we immediately have the problem that security is many disciplines. A security expert might know a lot about cryptography, or he might know very little. What we can't reasonably expect is that a security expert knows a lot about everything.

We have to be cut some out, and as security -- the entire field -- only rarely and briefly depends on cryptography, it seems reasonable that your average security expert only knows the basics of cryptography.

Adi Shamir said in his misconceptions in cryptography:

By implementers: Cryptography solves everything, but:

• only basic ideas are successfully deployed
• only simple attacks are avoided
• bad crypto can provide a false sense of security

What then are the basics? Block ciphers are pretty basic. Understanding all the ins and outs of modes and IVs however is not. Where we draw the line is in knowing our own limitations, so therefore the original question ("what's wrong with IV of all zeros?") indicates quite good judgement.

2. But what about software? We can see it in the cryptographers' view:

"Just use a unique IV."

Although this sounds simple, it is a lot harder to implement than to say, and the person who gets to be responsible for the reality is the programmer. In glorious, painful detail.

Consider this: say you choose to put random numbers in the IV, and then you specify that the protocol must have a good RNG ("random number generator"). Then, how do you show that this is what actually happens? How can you show that the user's implementation has a good RNG? Big problem: you can't. And this has been an ignored problem for basically the entire history of Internet cryptography.

Dilbert on Randomness

This would suggest that if you are doing secure protocols, what you want is someone who knows more about software than cryptography, because you want to know the costs of those choices more than you want to know the snippety little details.

3. Unfortunately, cryptography has captured the attention as a critical element of security. Software on the other hands is less interesting; just ask any journalist.

Because of this, crypto has become a sort of rarified unchallengeable beast in technological society, an institution more displaying of religious beliefs than cold science. Mere software engineers can rarely debate the cryptographers as peers, even the most excellent ones (like Zooko, Hal Finney and Dani Nagy) who can seriously write the maths.

So while I suggest that software is more important to the end result than cryptography, the programmers still lose in the face of assumed superiority. "Employ someone better than you" smacks of false professionalism, guildmaking. It's simple enough economics; if we as a group can create an ethos like the medical industry, where we could become unchallenged authorities, then we can lock out competitors (who haven't passed the guild exam), and raise prices.

Unfortunately, this raises the chance to near certainty that we also lock out people who can point out when we are off the rails.

4. And, we can forget about the business aspects completely. That is, a focus on requirements is just not plausible for people who've buried themselves in mathematics for a decade, as they don't understand where the requirements come from. Talking about risk is a vague hand-wavy subject, better left alone because of its lack of absolute provability.

By way of example, one of the questions in the recent debate was

"you haven't heard of anyone breaking SD cards have you?"

From a business perspective this makes complete sense, it is a completely standard risk perspective with theory to back it up (albeit a simplification); from a cryptographer's perspective it is laughable.

Who's right? Actually, both perspectives have merit, and choosing the right approach is again the subject of judgement.

5. Hence, a strong knee-jerk tendency to fall-back to the old saws like the CIA of confidentiality, integrity and authentication. But, it is generally easy to show that CIA and similar things are nice for crypto school but a bad start in real life.

E.g., in the above debate, it turns out that the application in question is DRM -- Digital Rights Management. What do we know about DRM?

If anything has been learnt at massive cost over the last 10 years of failed efforts, it is that DRM security does not have to be strong. Rather it has to create a discrimination between those who will pay and those who won't. This is a pure business decision. And it totally blows away the C, confidentiality, in CIA.

Don't believe me? Buy an iPod. The point here is that if one analyses the market for music (or ringtones, or cell phones, apparently) then the last thing one cares about is being able to crack the crypto. If one analyses the market for anything, CIA turns out to be such a gross simplification that you can pretty much assume it to be wrong from the start.

6. If you've subscribed to the above, even partly, you might then be wondering how we can tell a good security expert from a bad one? Good question!

Even I find it difficult, and I design the stuff (not at the most experienced level, but way more than for the hobby level). It is partly for that reason that I name financial cryptographers on the blog: to develop a theory of just how to do this.

How is a manager who has no experience in this going to do pick from a room full of security experts, who mostly disagree with each other? Basically, you're stuffed, mate!

So where does that leave us? Steve Bellovin says that when we hire a security expert, we are hiring his judgement, not his knowledge of crypto. Which means knowing when to worry, and especially _when not to worry_, and I fully agree with that! So how then do we determine someone's judgement in security matters?

Here's a scratched-down emerging theory of signals of security judgement:

BAD: If someone says "you need to hire a security expert, because you don't know enough, and that could be dangerous" that's a red-flag.

GOOD: If they ask what the requirements are, that's good.

BAD: If they assume CIA before the requirements, that's bad.

GOOD: If they ask what the application is, then a big plus.

BAD: If they say "use a standard protocol" then that's bad.

GOOD: If they say "this standard protocol may be a good starting point" then that's good.

BAD: If they know what goes wrong when an IV is not perfect, that's a danger sign.

GOOD: If they know enough to say "we have to be careful of the IV" then that's good.

BAD: If they don't know what risk is, they cannot reduce your risk.

GOOD: If they know more software than crypto, that's golden.

Strongly oriented to weeding out those who know too much about cryptography, it seems.

Sadly, the dearth of security engineers who don't subscribe to the hubristic myths leaves us with an unfortunate result: the job is left up to you. This has been the prevalent result of so many successful Internet ventures that it is a surprise that it hasn't been more clear. I'm sufficiently convinced that I think it has reached the level of a Hypothesis:

"It's your job. Do it."

Hubris? Perhaps! It's certainly your choice to either do it yourself, or hand it over to a security expert, so let's hear your experiences!

Breached *and* sued -- is TJX the tipping point to liability alignment?

TJX is to be sued. The huge data breach by the US retailer is news covered elsewhere, as it is just a big one in a series of other like ones.

The suit will argue that TJX failed to protect customer data with adequate security measures, and that the Framingham, Mass.-based retail giant was less than honest about how it handled data.

What is interesting is that this could be the first time that someone big says "boo!" If the banks are now getting together to sue TJX for doing the wrong thing, this sets an interesting precedence: the banks say (presumably) that TJX was negligent and has done damages.

If the courts can show this is worth remedy, then the reverse is possible too. There are other suits possible. If the banks lose the data, then maybe they should be sued? If Microsoft's OS is shown to be insecure and susceptible to lost data, then maybe it should be sued? Or the banks that quite happily permitted it to be used, again? If someone pushes a particular product for commercial purposes (such as a firewall, a secure token, an encryption protocol, or just advice...) and it is shown to be materially involved in a breach, maybe the pusher needs to be sued?

What would this mean? A lot of suits, is one thing, such as is being readied against Paypal. A lot of money wasted, and the lawyers get richer. Some banks, some suppliers, some pushers and some users might modify their behaviour. Others might just get more defensive.

That may be bad ... but what's our alternative?

Suppliers and sellers of bad products have not been punished. Neither have buyers of bad products. Leaving aside the sense of blame and revenge, where is the feedback loop that tells a company that "buying that was wrong, that hurts?" Where is the message that says "you shouldn't use that software for online banking" to the user?

To address this lack of feedback, lack of confirmed danger, many have suggested government action. But, other than the spectacular exception of the SB1386 data breach disclosure law, most government laws and interventions have made matters worse, not better.

Economists like those going to WEIS2007 have suggested many things: Align the incentives, share more breach information amongst victims, make software vendors liable, etc etc. I suspect that one common rejoinder here is that the very economics that explains the problem often gives clues as to why it isn't solved.

Some mad crypto people have even suggested designing security into the system in the first place. Yet other fruitcakes have said that designing the wrong security in was what got us to where we are now...

What doesn't seem clear from an outside, global, society perspective is ... what to do?! None of those approaches are going to "just work," even if they are adopted.

However, the liabilities (growing) and the interests (diverging) are going to be balanced and aligned, one way or another. The Internet security world today is out of balance, unsustainable in its posture.

Here's my prediction: At some point we do reach a tipping point, and at that point the suits start.

However, predicting re-balancing-by-suits has been a little like predicting the collapse of the dollar in the new not-quite-global-currency regime: when it did happen, we were caught by surprise. And then it bounced back again...

So, no dates on that prediction. Let's watch for TJX copies.

On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?

Two separate comments on the blog from a few days ago reach into the nub of the security mess. Adam comments:

It's not that we're unable to propose solutions, it's that they're hard to compare. My assertion is that once we overcome the desire to hide our errors, we can learn to compare in better ways.

And Lynn writes:

Two separate studies recently reached conflicting conclusions: While one found that identity theft is on the rise significantly, the other reported that it is on the decline.

So which is it?

Addressing these in reverse order, we can expect two professionally-prepared scientific reports on the same subject to reach the same conclusion, unless there are some other factors involved.

Firstly, it could be that we don't know enough (c.f., silver bullets). Secondly, it could be that we are not using scientific rigour, and the report is instead some for-profit advertisement. Or, thirdly, we could always simply be making a mistake.

All reasons are plausible... but now look at Adam's comment. If we apparently have a desire to hide our errors, what does that say? Are we all snake-oil salesmen? Are we not scientists? Is security only sales and hype, and there no professionalism in the field at all?

If we were talking about a science, and/or conducted by professionals, then we could assume that while Lynn's case was possible, it would be infrequent: professionals would not conclude if they did not know enough. Scientists wouldn't write for-profit advertisements, and although professionals might, they would be careful to disclose and disclaim. At the least, we would expose our data and ask for alternate analyses for the purpose of eliminating errors and mistakes.

If we were scientists, we recognise that the goal is knowledge, and the elimination of our own mistakes is the only way to advance knowledge. Having any desire whatsoever to cover our mistakes is incompatible with scientific method, indeed, it should be a joy to uncover our mistakes, as this is the only way to advance! And, even professionals know that recognition and correction of mistakes is a core professional duty.

This suggests then that security is not science and it is not a profession.

Is security only the marketing of ephemeral goods and services?

There is no moral difficulty in security being only, mere marketing. We humans have the right to make money, and spend it on what we like. If companies buy hype then let us sell them hype.

However, even in marketing there are limits. Even in marketing, we say that statements must be true. Even in marketing, professionalism exists.

Why is this? Perhaps it is time to consider a dramatic alternate to the true statement: Fraud.

Under common law, three elements are required to prove fraud: a material false statement made with an intent to deceive (scienter), a victim’s reliance on the statement and damages.

In today's Internet security world, we have damages, in Lynn's above-mentioned reports, whether up or down. We also have reliance by users on browsers, operating systems, CAs and server security. The intent to deceive is easy to show in the context of sales.

Do we have material false statements?

If the security industry was brought before the court of common law, I'd suggest that there's a pretty good chance that it would be found guilty of fraud!

Which is why Adam's assertion is so pertinent. Once we have committed fraud, we have also committed to covering it up. Fraud practitioners know that a strong signal of fraud is hiding the results, a desire to hide errors.

Fraud practitioners also know that fraud is a trap; once a small fraud is committed, we have to commit another and another, bigger and bigger. And each becomes easier, mentally speaking, than the first.

The security industry is caught in the trap of fraud: we are perpetually paying for the material false statements of our past, with bigger and bigger frauds. Where does this end?

Our security sucks. Why can't we change? What's wrong with us?

Adam over at EC joined the fight against the disaster known as Internet Security and decided Choicepoint was his wagon. Mine was phishing, before it got boring.

What is interesting is that Adam has now taken on the meta-question of why we didn't do a better job. Readers here will sympathise. Read his essay about how the need for change is painful, both directly and broadly:

At a human level, change involves loss and and the new. When we lose something, we go through a process, which often includes of shock, anger, denial, bargaining and acceptance. The new often involves questions of trying to understand the new, understanding how we fit into it, if our skills and habits will adapt well or poorly, and if we will profit or lose from it.

Adam closes with a plea for help on disclosure :

I'm trying to draw out all of the reasons why people are opposed to change in disclosure habits, so we can overcome them.

I am not exactly opposed but curious, as I see the issues differently. So in a sense, deferring for a moment a brief comment on the essay, here are a few comments on disclosure.

1. Disclosure is something that is very hard to isolate. SB1386 was a big win, but it only covered the easy territory: you, bad company, know the victim's name, so tell them.
2. Disclosure today doesn't cover what we might call secondary disclosure, which is what Adam is looking for. As discussed Schechter and Smith, and in my Market for Silver Bullets:

   Schechter & Smith use an approach of modelling risks and rewards from the attacker's point of view which further supports the utility of sharing information by victims:

   Sharing of information is also key to keeping marginal risk high. If the body of knowledge of each member of the defense grows with the number of targets attacked, so will the marginal risk of attack. If organizations do not share information, the body of knowledge of each one will be constant and will not affect marginal risk. Stuart E. Schechter and Michael D. Smith "How Much Security is Enough to Stop a Thief?", Financial Cryptography 2003 LNCS Springer-Verlag.

   Yet, to share raises costs for the sharer, and the benefits are not accrued to the sharer. This is a prisoner's dilemma for security, in that there may well be a higher payoff if all victims share their experiences, yet those that keep mum will benefit and not lose more from sharing. As all potential sharers are joined in an equilibrium of secrecy, little sharing of security information is seen, and this is rational. We return to this equilibrium later.

3. Disclosure implies the company knows what happens. What if they don't?
4. Disclosure assumes that the company will honestly report the full story. History says they won't.
5. Disclosure of the full story is only ... part of the story. "We lost a laptop." So what? "Don't do that again..." is hardly a satisfactory, holistic or systemic response to the situation.

   (OK, so some explanation. At what point do we forget the nonsense touted in the press and move on to a real solution where the lost data doesn't mean a compromise? IOW, "we were given the task of securing all retail transactions......")

So, while I think that there is a lot to be said about disclosure, I think it is also a limited story. I personally prefer some critical thought -- if I can propose half a dozen solutions to some poor schmuck company's problems, why can't they?

And it is to that issue that Adam's essay really speaks. Why can't we change? What's wrong with us?

What to do about responsible disclosure?

A slight debate has erupted over Adam's presentation "Security Breaches are good for you" which makes it a success. Of course, Adam means good for the rest of us, not the victims. One can consider two classes of beneficiaries to breach information:

1. The direct Individuals concerned. They can work out how their risks change from past events. In order for them to do anything to protect themselves, they have to be told; a company can't do it for them because it doesn't understand their situation.
2. Companies that have similar setups. They can work out better how to defend against future events. This comes from both understanding the weaknesses and exploits, and also the risks and costs. This viewpoint is due to Stuart E. Schechter and Michael D. Smith, "How Much Security is Enough to Stop a Thief?", Financial Cryptography 2003, LNCS Springer-Verlag. At least that's where I first saw a rational explanation, even though I have been thinking about the "secrecy is bad for you" angle for many years.

SB1386 and copies address the first case, but what about the second case? Kenneth F. Belva simply doesn't agree with it. He blogs that we can't release all this information for security reasons; we don't release security-sensitive info because it gives an attacker an advantage.

This I claim is a facade. I believe that when people say "cannot release that for security sensitive reasons," there are generally other real reasons. Primarily, this is the safety of the people doing the job in that they can do their job much more happily if they can avoid the scrutiny that disclosure forces. Adam says (PDF):

So, why can’t we share? There are four reasons usually given: liability, embarrassment, customers would flee, and we might lose our jobs.

I quote Dan Geer as saying “No CSO on Wall Street has the authority to share even firewall logs because no General Counsel can see the point.”

Beyond all the excuses, I think there is a much bigger danger: that security people can do their jobs much more badly when protected by secrecy. Disclosure forces all of us to defend our position and to be judged by our peers, and trotting out the "secrecy" argument is IMO almost always used to cover bad work, not a real security risk.

That's not to say that any particular professional is bad, but that the profession as a whole, as a guild, promotes bad professional behaviour, behind the curtain of secrecy. That said, there is an element of truth in the issue. We don't disclose the root password, so where is the line drawn? Kenneth says:

Just as we have and understanding of responsible disclosure now for technical information security vulnerabilities, we need the same for breach disclosure.

If not through a centralized (not necessarily government) body Adam, what do you propose that would allow for better, more accurate and confidential disclosure that does not leak sensitive information?

Disclosures are not possible if done via some "controlled" channel. As Adam points out and as economic theory has it (since Stiglitz or Stigler, I forget which), all closed channels become controlled, stifled and then neutered (and what happens after is sometimes even worse). This is as true in the infosec world as any other.

So maybe we need a law to force public disclosure? Right?

I call it wrong. SB1386 was a big win because it forced 1. above. This was in no small part because the issue was simple: just write to the victims and tell them what was lost. The harm was clear, the victims were directly known, and they just needed to be told.

Part 2 is much harder. I doubt a law can do it, and I further doubt a law can do any good there at all. There is no victim being targetted, there is no simple harm, and there is indeed no direct or contractual relationship here at all.

We simply have no guidance to make such a law. SB1386 was a lucky break, it spotted a precise niche, and filled it. We should *not* take SB1386 as anything but an extraordinarily lucky break, and we should not expect to repeat it.

So where does that leave us with respect to responsible disclosure ? It will then fall to the companies to decide what to do ... and obviously it is far far safer to say nothing than say something. That doesn't make it right, just safer for those who's jobs are at risk.

I talk about solutions in silver bullets. Adam dares:

I am challenging everyone to face those fears, and work to overcome them. I believe that there's tremendous value waiting to be unlocked.

Lack of solid info on breaches is one cause in what makes it so hard to defend against real risks; e.g., why phishing was able to develop unimpeded: nobody dared to talk about it when it happened to them, and anyone who did was poo-pooed by those who hadn't figured it out yet.

(Quick quiz -- what's your defence against MITB? is it (a) never heard about it, in which case you are a victim of the secrecy myth, (b) have one but can't say, in which case you are perpetuating unsafety through secrecy, or (c) something else?)

Feelings about Security

In the ongoing saga of "what is security?" and more importantly, "why is it such a crock?" Bruce Schneier weighs in with some ruminations on "feelings" or perceptions, leading to an investigation of psychology.

I think the perceptional face of security is a useful area to investigate, and the essay shines as a compendium of archtypical heuristics, backed up by experiments, and written for a security audience. These ideas can all be fed in to our security thinking, not to be taken for granted, but rather as potential explanations to be further tested. Recommended reading, albeit very long...

I would however urge some caution. I claim that buyers and sellers do not know enough about security to make rational decisions, the essay suggests a perceptional deviation as a second uncertainty. Can we extrapolate strongly from these two biases?

As it is a draft, requesting comment, here are three criticisms, which suggest that the introduction of essay seems unsustainable:

THE PSYCHOLOGY OF SECURITY -- DRAFT

Security is both a feeling and a reality. And they're not the same.

The reality of security is mathematical, based on the probability of different risks and the effectiveness of different countermeasures.

Firstly, I'd suggest that "what security is" is not yet well defined, and has defied our efforts to come to terms with it. I say a bit about that in Pareto-secure but I'm only really looking at one singular aspect of why cryptographers are so focussed on no-risk security.

Secondly, both maths and feelings are approximations, not the reality. Maths is just another model, based on some numeric logic as opposed to intuition.

What one could better say is that security can be viewed through a perceptional lens, and it can be viewed through a mathematical lens, and we can probably show that the two views look entirely different. Why is this?

Neither is reality though, as both take limited facts and interpolate a rough approximation, and until we can define security, we can't even begin to understand how far from the true picture we are.

We can calculate how secure your home is from burglary, based on such factors as the crime rate in the neighborhood you live in and your door-locking habits. We can calculate how likely it is for you to be murdered, either on the streets by a stranger or in your home by a family member. Or how likely you are to be the victim of identity theft. Given a large enough set of statistics on criminal acts, it's not even hard; insurance companies do it all the time.

Thirdly, insurance is sold, not bought. Actuarial calculations do not measure security to the user but instead estimate risk and cost to the insurer, or more pertinently, insurer's profit. Yes, the approximation gets better for large numbers, but it is still an approximation of the very limited metric of profitability -- a single number -- not the reality of security.

What's more, these calculations cannot be used to measure security. The insurance company is very confident in its actuarial calculations because it is focussed on profit; for the purpose of this one result, large sets of statistics work fine, as well as large margins (life insurance can pay out 50% to the sales agent...).

In contrast, security -- as the victim sees it -- is far harder to work out. Even if we stick to the mathematical treatment, risks and losses include factors that aren't amenable to measurement, nor accurate dollar figures. E.g., if an individual is a member of the local hard drugs distribution chain, not only might his risks go up, and his losses down (life expectancy is generally lowered in that profession) but also, how would we find out when and how to introduce this skewed factor into his security measurement?

While we can show that people can be sold insurance and security products, we can also show that the security they gain from those products has no particular closeness to the losses they incur (if it was close, then there would be more "insurance jobs").

We can also calculate how much more secure a burglar alarm will make your home, or how well a credit freeze will protect you from identity theft. Again, given enough data, it's easy.

It's easy to calculate some upper and lower bounds for a product, but again these calculations are strictly limited to the purpose of actuarial cover, or insurer's profit.

They say little about the security of the user, and they probably play as much to the feelings of buyer as any mathematical model of seller's risks and losses.

It's my contention that these irrational trade-offs can be explained by psychology.

I think that's a tough call, on several levels. Here's some contrary plays:

• Peer pressure explains a lot, and while that might feel like psychology; I'd suggest it is simple game theory.
• Ignorance is a big factor (c.f., insufficient information theory).
• Fear of being blamed also plays its part, which is more about agent/principal theory and incentives. It may matter less whether you judge the risk well than if you lose your job!
• Transaction cost economics (c.f., Coase, Williamson) has a lot to say about some of the experiments (footnotes 16,17,51,52).
• Marketing feeds into security, although perhaps marketing simply uses psychology -- and other tools -- to do its deeds.

If we put all those things together, a complex pattern emerges. I look at a lot of these elements in the market for silver bullets, and, leaning heavily on the Spencarian theory of symmetrically insufficient information, I show that best practices may emerge naturally as a response to costs of public exposure, and not the needs for security. Some of the experiments listed (24,38) may actually augment that pattern, but I wouldn't go so far as to say that the heuristics described are the dominating factor.

Still, in conclusion, irrationality is a sort of code word in economics for "our models don't explain it, yet." I've read the (original) literature of insufficient information (Spence, Akerlof, etc) and found a lot of good explanations. Psychology is probably an equally rewarding place to look, and I found the rest of the article very interesting.

On starting afresh with Security...

The gut-wrenching fight with who we want to be continues over at Mozilla. In a status update, Mitchell posts on the evolving Principles:

SPECIFICITY: There were a set of comments about the Manifeto not being specific, either about the nature of the goal or the steps we might take to get there. This was intentional on my part. With regard to specificity of the goals, I’m not sure we know now. And I’m pretty sure that interpretations will change. For example, what does security mean? We know it means security vulnerabilities -- problems with code that allow malicious actors too much room to move. More recently, “phishing” has become a serious problem. It’s not a classic code vulnerability though, so any definition of security that focused solely on code would be too limited. There will undoubtedly be other types of problems that will come up. So if we try to define “security” today it may be incomplete and it will undoubtedly be incomplete in the future.

My hope is that the Manifesto sets a stake in the ground that the broad topic of security is fundamental. Then a variety of groups can engage in more detailed discussions of what this means for them and what steps they will take. The Mozilla Foundation will clearly focus on products, technology and user interaction. Other groups can set out other specific tasks that contribute to improved Internet security.

That's just what I wanted to say ...

The recognition that security has failed has tracked the rise of phishing, growing through the years 2003-2004, but has been reinforced by data breaches, DDOS, botnets, etc. Those who saw the widening dichotomy between actual breaches and peacock strutting of the security industry started to ask questions. Is there one security or two? Is it possible to be secure and and not secure at the same time? Is there any point in talking about security at all, or is it all risk management? Who should we be securing, and what are we paying for?

Certainly, the discussion can only start with a fairly brave admission: We certainly stuffed that up, didn't we! Until we get over that barrier, until we recognise the awful gut-twisting fact that as a discipline, we said we could do it and we didn't, we won't ever be able to address the problems.

Mozilla makes the point above; has your organisation declared the failure insecurity to the public lately?

EV - what was the reason, again?

A debate is bubbling over in securityland about the (shock, horror) service of typing in your SSN to get a seen-in-the-wild check. You can try yourself

I tried typing in 123 456 789 and it told me to p**s off ... drats, it's clever!

But meanwhile, I spotted down at the bottom that there is a "Verisign secured" seal at the bottom. Oh, that means something, doesn't it? So I clicked it. It took me to Verisign. (Don't believe me ... click on the seal yourself ... PLEASE... and spot the <ahem> slight flaw :)

But anyways, ==> Verisign <== then says:

1/2/2007 23:02 www.stolenidsearch.com uses VeriSign services as follows:

SITE NAME: www.stolenidsearch.com

SSL CERTIFICATE
STATUS: Valid (13-Jan-2007 to 13-Jan-2008)

COMPANY/
ORGANIZATION: TRUSTEDID INC
Redwood City
California, US

Encrypted Data Transmission This Web site can secure your private information using a VeriSign SSL Certificate. Information exchanged with any address beginning with https is encrypted using SSL before transmission.
Identity Verified TRUSTEDID INC has been verified as the owner or operator of the Web site located at www.stolenidsearch.com. Official records confirm TRUSTEDID INC as a valid business.

For your best security while visiting sites, always make sure the address of the visited site matches the address you are expecting to see. Make sure that the URL of this page begins with "https://seal.verisign.com"
>>REPORT SEAL MISUSE

(highlighting the interesting bit there ...)

So, there we have it. Verisign says that TrustedId Inc, d.b.a. "StolenIdSearch" are a valid business. If they misuse your SSN, go after them.

What was the need for EV then, again?

Addendum: The site responds to criticism.

More on why Security isn't working -- it's in your Brain?

The push to rethink security is gaining momentum. Last week I posted the abstract of pending keynote from FC2007, which commented on the desire to let the bad guys direct your security thinking. This week, I see a curious remark concerning Bruce Schneier in a DDJ article, who's been seen more and more around the economics circles:

His latest work is on brain heuristics and perceptions of security, and he'll be doing a presentation on that topic at the RSA Conference next month. "I'm looking at the differences between the feeling and reality of security," he says. "I want to talk about why our perceptions of risk don't match reality, and there's a lot of brain science that can help explain this."

I await with interest, because although I am skeptical, I find I can't dismiss it and it is a new direction that at the least may make us think about the possibilities. There is some support for this from the economics of irrationality, an emerging view in economics that suggests that rationality has been overdone, and irrationality, somtimes a.k.a. emotions, plays more of a part than we think. From the Economist report on tests of price versus product decision making:

The researchers found that different parts of the brain were involved at different stages of the test. The nucleus accumbens-known from previous experiments to be involved in processing rewarding stimuli such as food, recreational drugs and monetary gain, as well as in the anticipation of those rewards-was the most active part when a product was being displayed. Moreover, the level of its activity correlated with the reported desirability of the product in question.

When the price appeared, however, fMRI reported more activity in other parts of the brain. Excessively high prices increased activity in the insular cortex, a brain region linked to expectations of pain, monetary loss and the viewing of upsetting pictures. The researchers also found greater activity in this region of the brain when the subject decided not to purchase an item.

Price information activated the medial prefrontal cortex, too. This part of the brain is involved in rational calculation, and is known from previous experiments using trading games to be involved in balancing the expected and actual outcomes of monetary decisions. In this experiment its activity seemed to correlate with a volunteer's reaction to both product and price, rather than to price alone. Thus, the sense of a good bargain evoked higher activity levels in the medial prefrontal cortex, and this often preceded a decision to buy.

OK, but that's economics and in particular behaviour during buying. What's that got to do with security? Maybe the link is that which I speculate on in the market for silver bullets; in that model, I claim that the buyer and seller knows less than needed to make a rational decision (classical 2x2 description). Then, silver bullets arise because silver bullets act as rational signals shared across the market place. (You too can speculate in the FC++ edition.)

What I glossed over was the mechanism by which each device is selected for the hallowed status of silver bullet -- I felt that the means was less relevant than the result. However, maybe economics, psychology and brain patterns can tell us something about how this happens:

His hypothesis is that rather than weighing the present good against future alternatives, as orthodox economics suggests happens, people actually balance the immediate pleasure of the prospective possession of a product with the immediate pain of paying for it.

If you read the entire article, you like I might ponder if we can avoid pain and pleasure when testing innocent victims with boxes of chocolates?

Now, *that's* how to do security...

Some good articles on how to do security. Firstly, the Security Bloke at Skype talks.

And secondly, someone in the USG reveals willingness to "know thy enemy," something generally out of favour in bureaucratic circles, and so immoral in some that it's probably illegal.

I've written before about the necessity to understand the conundrum of the hacker as essential to our security.

That is .. without actually endorsing the actions of our enemy, knowing him is your only way forward to victory. That's also the message at the end of this article, which while full of contradictions like "throw out your prejudices" and "trust your gut" it did have some good thoughts.

Changing the Mantra -- RFC 4732 on rethinking DOS

A couple of years ago I wrote that we should stop thinking about DOS -- denial of service attacks -- as something we don't do anything about in design phases simply because we can't stop it. The net community had adopted a sort of "institutional defeatism" which was causing problems because we weren't properly thinking through the ramifications of some of our choices.

I proposed that for a security protocol, it should make DOS no worse than it was without the security protocol, which at least theoretically removes the temptation for the user to turn off the security. That eliminates the easy attack against the user's security. Further, we help the popularity of the security protocol, and hopefully just thinking about this objective gets the designer looking for ways to reduce DOS.

Lynn now points to a new RFC on DOS, which primarily aims at the same thing: getting people to think about DOS when they build their systems:

4732 I Internet Denial-of-Service Considerations, Handley M., IAB, Rescorla E., 2006/12/22 (38pp)

This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.

A quick skim through indicates that it includes a good list of the many classical DOS techniques, and also a useful list of defences.

ATS and the death of a thousand tiny cuts

If I was a terrorist, this would be great news. The US has revealed yet another apparently illegal and plainly dumb civilian spying programme, called ATS or Automated Targeting System. Basically, it datamines all passenger info, exactly that which they were told not to do by Congress, and flags passengers according to risk profile.

Those who are responsible for US Homeland Insecurity had this to say:

Jayson Ahern, an assistant commissioner of the Department of Homeland Security's Customs and Border Protection Agency, told AP: "If (the ATS programme) catches one potential terrorist, this is a success.

From an FC perspective it is useful to see how other people's security thinking works. Let's see how their thinking stacks up. I think it goes like this:

1. If we catch lots of terrorists we are winning the war on terror, so vote us back in.
2. If we catch one terrorist, it's a success, so we must reinforce our efforts.
3. If we catch no terrorists, we must try harder, so we need more data and programmes.

See the problem? There's no feedback loop, no profit signal, no way to cull out the loss-making programmes. The only success criteria is in the minds of the people who are running the show.

Meanwhile, let's see how a real security process works.

1. Identify the objectives of the enemy.
2. Figure out which of those objectives are harmful to us, and which are benign.
3. Figure out how to make the harmful objectives loss-making to the enemy, and acceptable to us.
4. Redirect the enemy's attention to objectives that do us no harm.
5. Wait.

Approximately, the objectives of the terrorists are to deliver the death of a thousand tiny cuts to the foreign occupiers, to draw from the Chinese parable. In other words, to cause costs to the US and their hapless friends, until they give up (which they must eventually do unless they have some positive reward built in to their actions).

So let's examine the secret programme from the point of view of the terrorist. Obviously, it was no real secret to the terrorists ("yes, they will be monitoring the passenger lists for Arab names and meals....") and it is relatively easy to avoid ("we have to steal fresh identities and not order meals"). What remains is a tiny cut magnified across the entire flying public, and a minor inconvenience to the terrorist. Because it is known, it can be avoided when needed.

We can conclude then that the ATS is directly aligned with the objectives of the terrorists. But there's worse, because it can even be used against the USA as a weapon. Consider this one again:

"If (the ATS programme) catches one potential terrorist, this is a success."

Obviously, one basic strategy is for the terrorists to organise their activities to avoid being caught. Or, a more advanced strategy is to amplify the effect of the US's own weapon against them. As the results of the ATS are aligned with objectives of the terrorists -- death by a thousand tiny cuts -- they can simply reinforce it. More and deeper cuts...

Get it? As a terrorist campaign, what would be better than inserting terrorists into the passenger lists? The programme works, so catching some terrorists causes chaos and costs to the enemy (e.g., the recent shampoo debacle). The programme works, so it is a success, therefore it must be reinforced. And it works predictably, so it is easy to spoof.

Even if the terrorist fails to get caught, he wins with some minor panic at the level of exploding shoes or shampoo bottles. And, if the suicide bomber is anything to go by, there is only a small cost to the terrorists as an organisation, and a massive cost to the enemy: consider the cost of training one suicide bomber (cheap if you want him to be caught, call it $10k) versus the cost of dealing with a terrorist that has been caught (publically funded defence, decades of appeals, free accomodation for life, private jets and bodyguards..., call it $10m per "success").

Not to mention the megaminutes lost in the entire flying public removing their shoes. For the terrorist, ATS is the perfect storm of win-wins -- there is no lose square for him.

On the other hand, if our security thinking was based on risk management, we'd simply use any such system for tracking known targets and later investigation of incidents. Or turn it off, to save the electricity. Far too many costs for minimal benefit.

Luckily, in FC, we have that feedback loop. When our risk management programmes show losses, or our capital runs out, the plug is pulled. Maybe it is time to float the DHS on the LSE?

CFP - Computer Security Foundations

Twan says of WEIS: "Darn, why did I miss this workshop!? ... interesting stuff" Me too. Here's another one:

CSF20 website: http://www.dsi.unive.it/CSFW20/
CSF home page: http://www.ieee-security.org/CSFWweb/
CSF CFP: http://www.cs.chalmers.se/~andrei/CSF07/cfp.html

The IEEE Computer Security Foundations Workshop (CSF) series brings together researchers in computer science to examine foundational issues in computer security. Over the past two decades, many seminal papers and techniques have been presented first at CSF. The CiteSeer Impact page lists CSF as 38th out of more than 1200 computer science venues in impact (top 3.11%) based on citation frequency. There is a possibility of upgrading CSF to an IEEE symposium already in 2007.

New theoretical results in computer security are welcome. Also welcome are more exploratory presentations, which may examine open questions and raise fundamental concerns about existing theories. Panel proposals are welcome as well as papers. Possible topics include, but are not limited to:

   Authentication    Access control    Distributed systems
   Information flow  Trust and trust   security
   Security          management        Security for mobile
   protocols         Security models   computing
   Anonymity and     Intrusion         Executable content
   Privacy           detection         Decidability and
   Electronic voting Data and system   complexity
   Network security  integrity         Formal methods for
   Resource usage    Database security security
   control                             Language-based
                                       security

Proceedings published by the IEEE Computer Society Press will be available at the workshop, and selected papers will be invited for submission to the Journal of Computer Security.

Important Dates

Papers due:                   Monday, February 5, 2007
Panel proposals due:          Thursday, March 15, 2007
Notification:                 Monday, March 26, 2007
Camera-ready papers:          Friday, April 27, 2007
Workshop:                     July 6-8, 2007

Workshop Location

The 20th IEEE Computer Security Foundations Workshop will be held in the facilities of Venice International University, located on the island of San Servolo, about 10 minutes by water ferry from the Piazza San Marco.

More details: http://www.cs.chalmers.se/~andrei/CSF07/cfp.html

Who has a Core Competency in Security?

A debate over at Ravichar, McKeay, EC asks whether a core competency in security could make a difference. Some notes.

Core competencies are much misunderstood. They are things that by definition almost are very strong, uncopiable, and rather rare. For example, most auto manufacturers make good engines, but Honda has a core competency in building small petrol engines with efficient profiles -- that was the opinion of Porsche, no slouch in engine design themselves.

Most ordinary companies will do well just using security as a competency (non-core) which means they can do it for most purposes and reasonably well.

For example, one could suggest that Apple has security as a competency; they've always been reasonable at it, and have never really drifted far from a relatively secure product. We could also suggest that Microsoft are working on a decade long project to add a security competency.

But for some sectors, something more is needed. For a CORE competency in security we'd have to look further; the tiny word has more significance than it seems.

I'd pick IBM in the heyday, back in the 70s and 80s. IBM was the one always chosen by the banks to do the really difficult stuff in security. They had the people to build entire new systems. E.g., before public key was fashionable, IBM built it all with secret keys, and that included the systems to deliver the secret keys! They were the ones who had the strength to create DES, in the days when nobody much could spell cryptography, let alone understand its market purpose. In the 90s, the core competency lived on as banks chose IBM to do SET (something that a lot of companies discovered to their horror...) because IBM was it in security systems.

Who has a core competency in security these days? Nothing obvious springs to mind.

What is the point of encrypting information that is publicly visible?

The Grnch asks, in all honesty:

> What is the point of encrypting information that is publicly visible?

To which the answer is:

To remove the security weakness of the decision.

This weakness is the decision required to determine what is "publicly visible" or not. Or, more generally, what is sensitive or not.

Unfortunately, there is no algorithm to determine those two sets. Software can't make that decision, so it falls to humans. Unfortunately, humans have no good algorithm either -- they can make quick value judgements, they can make bad value judgements, or they can turn the whole thing off. Worse, even, it often falls to software engineers to make the decision (e.g., HTTPS) and not only are engineers poor at making such judgements, they don't even have local contextual information to inform them. That is, they have no clue what the user wants protected.

The only strategy then is to encrypt everything, all the time. This feeds into my third hypothesis:

There is only one mode, and it is secure.

I'm being very loose here in the use of the word "secure" but suffice to say, we include encryption in the definition. But it also leads feeds into another hypothesis of mine:

Only end-to-end security is secure.

For the same reasons ... if we introduce a lower layer security mechanism, we again introduce a decision problem. Following on from the above, we can't trust the software to decide whether to encrypt or not, because it has no semantic wisdom with which to decide. And we can't trust the user...

Which brings rise to the knowledge problem. Imagine a piece of software that has a binary configuration for own-security versus rely-on-lower-layers. A button that says "encrypt / no-encrypt" which you set if the lower layer has its own security or not, for example. There is, so the theory goes, no point in encrypting if the lower layer does it.

But, how does it know? What can the software do to reliably determine whether the lower layer has encryption? Consider IPSec ... how do we know whether it is there? Consider your firewall sysadmin ... who came in on the weekend and tweaked the rules ... how do we know he didn't accidentally open something critical up? Consider online account access through a browser ... how do we know that the user has secured their operating system and browser before opening Internet Explorer or Firefox?

You can't. We can't, I can't, nobody can rely on these things. Security models built on "just use SSL" or similar are somewhere between fatally flawed and nonsense for these reasons; for real security, security models that outsource the security to some other layer just don't cut the mustard.

But, the infrastructure is in place, which counts for something. So are there some tweaks that we can put in place to at least make it reasonably secure, whatever that means? Yes, they include these fairly minor tweaks:

• put the CA's name on the chrome of the browser
• implement SNI (in everywhere but Opera :)
• encrypt -- HTTPS -- everything all the time
• utilise naming theory (add petnames to certs)

Spread the word! This won't stop phishing, but it will make it harder. And, it gets us closer to doing the hard re-engineering ... such as securing against MITB.

CFP: 6W on the Economics of Information Security (WEIS 2007)

How much should we spend on security? What incentives really drive privacy decisions? What are the trade-offs that individuals, firms, and governments face when allocating resources to protect data assets? Are there good ways to distribute risks and align goals when securing information systems?

The 2007 Workshop on the Economics of Information Security builds on the success of the previous five Workshops and invites original research papers on topics related to the economics of information security and the economics of privacy. Security and privacy threats rarely have purely technical causes. Economic, behavioral, and legal factors often contribute as much as technology to the dependability of information and information systems. Until recently, research in security and dependability focused almost exclusively on technical factors, rather than incentives. The application of economic analysis to these problems has now become an exciting and fruitful area of research.

We encourage economists, computer scientists, business school researchers, law scholars, security and privacy specialists, as well as industry experts to submit their research and attend the Workshop. Suggested topics include (but are not limited to) empirical and theoretical economic studies of:

- Optimal security investment
- Software and system dependability
- Privacy, confidentiality, and anonymity
- Vulnerabilities, patching, and disclosure
- DRM and trusted computing
- Trust and reputation systems
- Security models and metrics
- Behavioral security and privacy
- Information systems liability and insurance
- Information threat modeling and risk management
- Phishing and spam

**Important dates**

- Submissions due: March 1, 2007
- Notification of acceptance: April 10, 2007
- Workshop: June 7-8, 2007

For more information visit http://weis2007.econinfosec.org/.

Tracking Threats - how whistleblowers can avoid tracking by cell/mobile

Someone's paying attention to the tracking ability of mobile phones. Darrent points to Spyblog who suggests some tips to whistleblowers (those who sacrifice their careers and sometimes their liberty to reveal crimes in government and other places):

8. Do not use your normal mobile phone to contact a journalist or blogger from your Home Office location, or from home. The Cell ID of your mobile phone will pinpoint your location in Marsham Street and the time and date of your call. This works identically for Short Message Service text messages as well as for Voice calls.

Such Communications Traffic Data does not require that a warrant be signed by the Home Secretary, a much more junior official has the power to do this, e.g. the Home Office Departmental Security Unit headed by Jacqueline Sharland.

9. Buy a cheap pre-paid mobile phone from a supermarket etc..

• Do not buy the phone or top up phone credit using a Credit Card or a make use of a Supermarket Loyalty Card.
• Do not switch on or activate the new mobile at home or at work, or when your normal mobile phone switched on (the first activation of a mobile phone has its physical location logged, and it is easy to see what other phones are active in the surrounding Cells at the same time.
• Do not Register your pre-paid mobile phone, despite the tempting offers of "free" phone credit.
• Do not store any friends or familiy or other business phone numbers on this disposable phone - only press or broadcast media or blogger contacts.
• Set a power on PIN and a Security PIN code on the phone.
• Physically destroy the phone and the SIM card once you have done your whistleblowing. Remember that your DNA and fingerprints will be on this mobile phone handset.
• Do not be tempted to re-use the SIM in another phone or to put a fresh SIM in the old phone, unless you are confident about your ability to illegally re-program the International Mobile Equipment Electronic Identity (IMEI).

Just in case you think this is excessive paranoia, it recently emerged that journalists in the USA and in Germany were having their phones monitored, by their national intelligence agencies, precisely to try to track down their "anonymous sources".

Why would this not happen here in the UK ?

See Computer Encryption and Mobile Phone evidence and the alleged justification for 90 days Detention Without Charge - Home Affairs Select Committee Oral Evidence 14th February 2006

...

25. If you decide to meet with an alleged "journalist" or blogger (who may not always be who they claim to be), or if a journalist or blogger decides to meet with an "anonymous source" (who also might not be who they claim to be), then you should switch off your mobile phones, since the proximity of two mobile phones in the same approximate area, at the same time, is something which can be data mined from the Call Data Records, even if no phone conversations have taken place. Typically a mobile phone will handshake with the strongest Cell Base Station transmitter every 6 to 10 minutes, and this all gets logged, all of the time.

Read the whole thing if it is important to you. Personally, I'd say that's a difficult list. If you are suspect, don't use a cellphone. Not that I have a better idea (although I think Spyblog's comments on Skype are perhaps a little weak.)

Why security training is really important (and it ain't anything to do with security!)

Lynn mentioned in comments yesterday:

I guess I have to admit to being on a roll.

:-) Lynn grasped the nexus between the tea-room and the systems room yesterday:

One of the big issues is inadequate design and/or assumptions ... in part, failing to assume that the operating environment is an extremely hostile environment with an enormous number of bad things that can happen.

What I didn't stress was the reasons behind why security training was so important -- more important than your average CSO knows about. Lynn spots it above: reliability.

The reason we benefit from teaching security (think Fight Club here not the American Football) is that it clearly teaches how to build reliable systems. The problem addressed here is that unreliable systems fall foul of statistical enemies, and they are weak, few and far between. But when you get to big systems and lots of transactions, they become significant, and systems without reliability die the death of a thousand cuts.

Security training solves this because it takes the statistical enemy up several notches and makes it apparent and dangerous even in small environments. And, once a mind is tuned to thinking of the attack of the aggressor, dealing with the statistical failure is easy, it's just an accidental case of what an aggressor could do.

I would even assert that the enormous amounts of money spent attempting to patch an inadequate implementation can be orders of magnitude larger than the cost of doing it right in the first place.

This is the conventional wisdom of the security industry -- and I disagree. Not because it doesn't make sense, and because it isn't true (it makes sense! and it's true!) but because time and time again, we've tried it and it has failed.

The security industry is full of examples where we've spent huge amounts of money on up-front "adequate security," and it's been wasted. It is not full of examples where we've spent huge amounts of money up front, and it's paid off...

Partly, the conventional security industry wisdom fails because it is far too easy for us to hang it all out in the tea-room and make like we actually know what we are talking about in security. It's simply too easy to blather such received wisdom. In the market for silver bullets, we simply don't know, and we share that absence of knowledge with phrases and images that lose meaning for their repitition. In such a market, we end up selling the wrong product for a big price -- payment up front, please!

We are better off -- I assert -- saving our money until the wrong product shows itself to be wrong. Sell the wrong product by all means, but sell it cheaply. Live life a little dangerously, and let a few frauds happen. Ride the GP curve up and learn from your attackers.

But of course, we don't really disagree, as Lynn immediately goes on to say:

Some of this is security proportional to risk ... where it is also fundamental that what may be at risk is correctly identified.

Right.

To close with reference to yesterday's post: Security talk also easily impresses the managerial class, and this is another reason why we need "hackers" to "hack", to use today's unfortunate lingo. A breach of security, rendered before our very servers, speaks for itself, in terms that cut through the sales talk of the silver bullet sellers. A breach of security is a hard fact that can be fed into the above risk analysis, in a world where Spencarian signals abound.

How the Classical Scholars dropped security from the canon of Computer Science

Once upon a time we all went to CompSci school and had lots of fun.

Then it all stopped. It stopped at different times at different places, of course, but it was always for the same reason. "You can't have fun," wiggled the finger of some professor talking a lot of Greek.

Well, it wasn't quite like that, but there is a germ of truth in the story. Have a look over at this post (spotted on EC) where the poster declares -- after a long-winded description of the benefits of a classical education -- that the computer science schools should add security to their canons, or core curricula. (Did I get the plurals right? If you know the answer you will have trouble following the rest of this post...)

Teaching someone to validate input is easy. Teaching someone why they need to be rabid about doing it every single time - so that they internalize the importance of security - is hard. It's the ethics and values part of secure coding I really hate having to retrofit, not the technical bit. As it says in Proverbs 22:6, "Train a child in the way he should go, and when he is old he will not turn from it."

This poster has it wrong, and I sense years in the classroom, under the ruler, doing verbs, adverbs and whatnots. No fun at all.

Of course, the reason security is hard is because they -- the un-fun classical scholars -- don't provide any particular view as to why it is necessary, and modern programmers might not be able to eloquently fill in the gap, but they do make very economic decisions. Economics trumps ethics in all known competitions, so talking about "ethics and values of secure coding" is just more Greek.

So what happened to the fun of it all? I speak of those age-old core skills now gone, the skills now bemoaned in the board rooms of just-hacked corporations the world around, as they frown over their SB1386s. To find out happened to them, we have to go back a long time, to a time where titles mattered.

Time was, a junior programmer didn't have a title, and his first skills were listening, coding and frothing.

He listened, he coded and frothed, all under close supervision, and perchance entered the world's notice as a journeyman, being an unsupervised listener, coder and frother.

In those days, the journeyman was called a hacker, because he was capable of hacking some bits and pieces together, of literally making a hack of something. It was a bit of a joke, really, but our hacker could get the job done, and it was better to be known as one than not being known at all. (One day he would aspire to become a guru or a wizard, but that's another story.)

There was another lesser meaning to hacker, which derived from one of the journeyman's core classes in the canon -- breaching security. He was required to attack others' work. Not so as to break it but so as to understand it. To learn, and to appreciate why certain odd things were done in very certain but very odd ways.

Breaching security was not only fun, it was a normal and necessary part of computer science. If you haven't done it, you aren't well rounded, and this is partly why I muck around in such non-PC areas such as poking holes in SSL. If I can poke holes in SSL, so the theory of secure protocols goes, then I'm ready -- perhaps -- to design my own.

Indeed breaching security or its analogue is normal and essential in many disciplines; cryptology for example teaches that you should spend a decade or so attacking others' designs -- cryptanalysis -- before you ever should dare to make your own -- cryptography. Can you imagine doing a civil engineering course without bending some beams?

(Back to the story.) And in due course, when a security system was breached, it became known as being hacked. Not because the verb was so intended, but by process of elimination some hacker had done it, pursuant to his studies. (Gurus did not need to practice, only discuss over cappuccinos. Juniors listened and didn't do anything unless told, mostly cleaning out the Atomic for another brew.)

You can see where we are going now, so I'll hit fast-forward. More time passed ... more learning a.k.a. hacking ... The press grasped the sexy term and reversed the senses of the meaning.

Some company had its security breached. Hacking became annoying. The fun diminishes... Then the viruses, then the trojans, the DDOS, the phishing, the ....

And it all got lumped together under one bad name and made bad. Rustication for some, "Resigned" for others, Jail for some unfortunates.

That's how computer science lost the security skills from the canon. It was dropped from the University curricula by people who didn't understand that it was there for a reason. Bureaucrats, lawmakers, police, and especially corporates who didn't want to do security and preferred to blame others, etc etc, the list of naysayers is very long.

Having stripped it from computer science, we are now in a world where security is not taught, and need to ask: what they suggest in its place:

There are some bright security spots in the academic environs. For example, one professor I talked to at Stanford in the CS department - in a non-security class, no less - had his students "red team" and blue team" their homework, to stress that any and all homework had to be unhackable. Go, Stanford! Part of your grade was your homework, but your grade was reduced if a classmate could hack it. As it should be.

Right, pretend hacking exercises. Also, security conferences. Nice in spirit, but the implementation is a rather poor copy of the original. Indeed, if you think about the dynamics of hacking games and security conferences ("Nobody ever got hacked going to Blue Hat??") we aren't likely to sigh with relief.

And then:

One of my colleagues in industry has an even more draconian (but necessary) suggestion for enforcing change upon universities. ... He decided that one way to get people's attention was to ask Congress to tie research funds to universities to changing the computer science curriculum. I dare say if universities' research grants were held up, they might find the extra time or muster the will to change their curricula!

Heaven help us! Are we to believe that the solution to the security training quandary is to ask the government to tell us how to do security training? Tell me this is a joke, and the Hello Kitty People haven't taken over our future:

The Hello Kitty people are those teenagers who put their personal lives on MySpace and then complain that their privacy is being violated. They are the TV viewers who think that the Hurricane Katrina rescue or the Iraq war were screwed up only because we don't, they belatedly discover, have actual Hello Kitties in political power. When inevitably some of world's Kitties, unknown beyond their cute image, turn out to be less than fully trustworthy, the chorus of yowling Kitty People becomes unbearable cacophony.

(We've written before about how perhaps the greatest direct enemy of Internet security is the government, so we won't repeat today.)

Here is a test. A corporation such as Oracle could do this, instead of blaming the government or the hackers or other corporations for its security woes. Or Microsoft could do it, or anyone, really.

Simply instruct all your people to breach security. Fill in the missing element in the canon. Breach something, today, and learn.

Obviously, the Greeks will complain about the errant irresponsibility of such support for crime ... but just as obviously, if they were to do that, their security knowledge would go up by leaps and bounds.

Sadly, if this were taken seriously, modern corporations such as Oracle would collapse in a heap. It's far cheaper to drop the training, blame "the hackers" and ask the government for a subsidy.

Even more sadly, we just don't have a better version of training than "weapons free." But let's at least realise that this is the issue: you classicals, you bureaucrats, you Sonys and Oracles and Suns, you scared insecure corporations have brought us to where we are now, so don't blame the Universities, blame yourselves.

And, in the name of all that is sacred, *don't ask the government for help!*

The Last Link of Security

Vlad Miller writes from Russia (translated by Daniel Nagy):

We can invent any algorithm, develop any protocol, build any system, but, no matter how secure and reliable they are, it is the human taking the final decision that remains the last link of security. And, taking into account the pecularities of human nature, the least reliable link, at that, limiting the security of the entire system. All of this has long been an axiom, but I would like to share a curious case, which serves as yet another confirmation of this fact.

We all visit banks. Banks, in addition to being financial organizations attracting and investing their clients' funds, are complex systems of informational, physical and economic defenses for the deposited cash and account money. Economic defenses are based on procedures of confirming and controlling transactions, informational defenses -- on measures and procedures guarding the information about transactions, personal, financial and other data, while physical defenses comprise the building and maintenance of a secure physical perimeter around the guarded objects: buildings, rooms and valuable items.

Yet, regardless of the well-coordinated nature of the whole process, final decisions are always taken by humans: the guard decides whether or not to let the employee that forgot his ID through the checkpoint; the teller decides whether a person is indeed the owner of the passport and the account he claims to own; the cashier decides whether or not there is anything suspicious in the presented order. A failure can occur at any point, and not only as a consequence of fraudulent activities, but also due to carelessness or lack of attention on the part of the bank's employee, a link of the security system.

Not too long ago, I was in my bank to deposit some cash on my account. The teller checked my passport, compared my looks to the photo within, took my book and signed a deposit order for the given amount. The same data were duplicated in the bank's information system and the order with my book were passed on to the cashier. Meanwhile, I was given a token with the transaction number, which I should have presented to the cashier so that she could process the corresponding order. Everybody is familiar with this procedure; it may differ a bit from bank to bank, but the general principles are the same.

Walking over to the cashier, I have executed my part of the protocol by handing over the token to the cahsier (but I did not put the cash into the drawer before having been asked to do so). She looked at my order, affixed her signature to it and to my book and ... took a few decks of banknotes out of the safe and started feeding them to the counting machine. I got curious how long it would take for the young lady to realize the error in her actions, and did not interrupt her noble thrust. And only when she turned around to put the cash into the drawer did I delicately remark that I did not expect such a present for March 8 and that I came to deposit some cash, not to withdraw. For a few seconds, the yound lady gave me a confused look, then, after looking at the order and crossing herself, thanked me for saving her from being fired.

The banking system relies a great deal on governmental mechanisms of prevention, control and reaction. Had I not, in computer-speak, interrupted the execution of the miscarried protocol, but instead left the bank with the doubled amount of money, it would not have lead to anything except for the confiscation of the amount of my "unfounded enrichment". The last link of security is unreliable: it fails at random and is strongly vulnerable to various interferences and influences. This is why control and reaction are no less important than prevention of attacks and failures.

Mozilla moves on security

There are already a couple of improvements signalled at Mozilla in security terms since the appointment of Window Snyder as single security chair, for those interested (and as Firefox has 10-20% of the browser market, it is somewhat important). Check out this interview.

1. Understanding of what the word 'security' means:

   What is the key rule that you live by in terms of security?
   Snyder: That nothing is secure. ...

   ( Adi Shamir says that absolutely secure systems don't exists. Lynn's version: "can you say security proportional to risk?" I say Pareto-secure ... Of course, to risk practitioners, this is just journeyman stuff. )



2. Avoidance of battle on the plain of "most secure browser":

   So the answer, in one word: Is Firefox more secure than Internet Explorer?
   Snyder: I don't think there is a one-word answer for that question.

   If ever there was a battle that was unwinnable, that was it. It quite possibly needed someone who had extensive and internal experience of MS to nail that one for Mozo.



3. Here's the one I was curious about:

   You dealt with security researchers at Microsoft and will deal with them at Mozilla. How do you see the community? There have been several cases where researchers have gone public with Firefox flaws.
   Snyder: The security research community I see as another part of the Mozilla community. There's an opportunity for these people, if they get excited about the Mozilla project, to really contribute. They can contribute to secure design, they can suggest features, they can help us identify vulnerabilities, and they can help us test it. They can help us build tools to find more vulnerabilities. The spectrum is much broader (than with commercial products) in ways the research community can contribute to this project.

   Earlier, Snyder said:

   Snyder: There has been a lot of great work done. I think there is a great opportunity to continue that work and make the entire process available externally.

   Is this a move towards opening Mozilla's closed security process? If so, that would be most welcome.

And in other news, Firefox 2.0 is almost here:

Version 2.0 of the software will still feature a raft of new features including an integrated in-line spell checker, as well as an anti-phishing tool (a must-have accessory that's in Opera 9 and will be included in IE 7),...

Hopefully someone will get a chance to review it the anti-phishing tool (!) and compare it to the efforts of the research community over the last few years.

Mozilla now has a "Chief Security Something"

One of the big problems with Mozilla was that they didn't have a Security Czar. This lack meant that far-reaching threats such as phishing failed to be addressed because the scope was too broad for the existing specialists, and as Firefox now takes the teens in browser market share, that's a big issue.

Now they do! Excellent news, reported over on "schrep's blog":

Window has joined MozCorp recently as our new "Chief Security Something" (that's a working title :-)). She'll be the public voice of Mozilla Corporation on security issues and helping to drive our long-term security strategy.

Congrats! Also, article at eWeek

Spotted by Adam.

Fraudwatch - how much a Brit costs, how to be a 419-er, Sarbanes-Oxley rises as fraud rises, the real Piracy

A BBC programme reported the cost of Brit identities as extracted from recycled PCs:

Bank account details belonging to thousands of Britons are being sold in West Africa for less than £20 each, the BBC's Real Story programme has found.

Which comes as the EU moves to total passenger tracking:

BIOMETRIC testing is set to be introduced at European airports under plans for stringent new security measures revealed yesterday in the wake of last week's alleged terror plot. Passengers would have their fingerprint or iris scanned under the measures proposed by EU interior ministers, which would also use passenger profiling to try to identify potential terrorists.

Here's some stats on Nigerian 419 scams, another deception with higher risks for the consumer but not the retailer:

He sent 500 e-mails a day and usually received about seven replies. Shepherd would then take over. "When you get a reply, it's 70% sure that you'll get the money," Samuel said. ... By 2003, Shepherd was fleecing 25 to 40 victims a month, Samuel said. Samuel never got the 20%, but still made a minimum of $900 a month, three times the average income here. At times, he made $6,000 to $7,000 a month.

Samuel said Shepherd employs seven Nigerians in America, including one in the San Francisco Bay Area, to spy on maghas and threaten any who get cold feet. If a big deal is going off track, he calls in all seven.

"They're all graduates and very smart," Samuel said. "Four of them are graduates in psychology here in Nigeria. If the white guy is getting suspicious, he'll call them all in and say, 'Can you finish this off for me?'

"They'll try to scare you that you're not going to get out of it. Or you're going to be arrested and you will face trial in Nigeria. They'll say: 'We know you were at Wal-Mart yesterday. We know the D.A. He's our friend.' "

"They'll tell you that you are in too deep - you either complete it or you'll be killed."

Anyone want to hazard when crooks will be able to buy European biometric data in Africa? More from the BBC.

Once in a blue moon, using dodgy identity cards seems not to work (dead link):

A Toronto man who wanted a fraudulent driver's licence added to his collection of counterfeit ID was foiled by a sharp-eyed employee with the Ministry of Transportation in Hamilton. .... The convicted man provided a Canadian citizenship card in the name of Rohan Omar Kelly when he showed up with a friend on June 12 to write a driver's exam at the ministry's Kenilworth Avenue office.

The employee took a long, hard look at his identification and discreetly slipped away to call the police.

Meanwhile, his friend presented a credit card to pay for the fictitious Kelly's fee. The card, as it would turn out when the pair was arrested a short time later, was a pirated copy. The same was true for a Canadian social insurance card seized from Thomas and a second citizenship card that police found on the dash of the friend's Chev Malibu parked outside.

I wouldn't suggest you do that at home, folks! Fraud responds well to natural selection; the dumb crooks get caught, leaving the smart ones. Actually, the smart ones get caught too, but not before training two more up.

Laws on fraud enjoy no such control, they just get bigger and dumber. CompliancePipeline reports on the anti-climax of Sarbanes-Oxley:

The top-level findings show that even in the more heavily regulated business environment, the incidence of fraud continues to increase. Sixty-seven percent of the respondents indicated that institutional fraud is more prevalent today than five years ago, and another 27 percent said there has been no change level of fraud activity.

Probably, Sarbanes-Oxley supporters will say that they just need to try harder, write more rules, bust more companies, etc etc. Perhaps they should create identity trails as part of their data? New figures suggest identity theft is becoming more valuable, but that's no reason not to store massive amounts of identity information:

Nearly 10 million consumers were victimized by some form of identity theft in 2004 alone. That equals 19,178 people per day, 799 per hour and 13.3 per minute. Consumers have reportedly lost over US$5 million, and businesses have lost an estimated $50 billion or more.

A few years back the accepted figure for identity theft in the USA was around $10bn; maybe it is being revised upwards to 50bn or more (?) with inclusion of internal (unreported) corporate costs.

And, let's close with a curious comparison: Cubicle reports on stats on the real Piracy!

…there is very little financial incentive for both governments and shippers to deal with this crime. Piracy is costing shippers $.32 for every $10,000 of goods shipped estimates David N. Kellerman of Maritime Security. Not only is the economic cost inconsequential to companies, so it is to some governments.

Sound familiar? If I’m the corporate owner, the cost is inconsequential. If I’m a sailor on one of these ships, though, the cost is a little more significant:

Merely one year before, in September of 1998, a smaller Japanese-owned freighter named the Tenyu had gone missing soon after departing from the same port of Kuala Tanjung with a similar load of aluminum, and a crew of fifteen. Three months later the Tenyu was discovered under a changed name and flag in a Chinese port, but the cargo was missing, as was the original crew, all of whom are presumed to have been killed.

Ship owners can transfer the risk of Piracy with insurance, but sailors only have two options. They can either avoid the risk by finding a new vocation (not sailing on vessels which travel through pirate-prone regions is not really an option) or hope that the shipowners mitigate it by implementing anti-piracy safeguards such as anti-boarding defenses or armed guards, at least for passing through piracy-prone areas.

Somehow, identity theft seems a little more comfortable.

Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts

First some good news from PaymentNews:

APACS, the UK payment association, has announced that six months after "PIN day" (Valentine’s Day 2006, February 14th), the UK is the world's first chip and PIN success story - with more than 99.8% of all chip and PIN card transactions are now PIN-verified and more than 150 chip and PIN transactions take place every second. (compared with 125 a second six months ago and 85 a second a year ago).

The UK’s banks and card companies have now issued 130 million chip and PIN cards representing 92% of a total of 141 million cards. Approximately 850,000 tills have been upgraded to chip and PIN, representing 87 per cent of all tills in the UK - and retailers have reported that "transaction times have become quicker with queues in shops shorter." In addition, in 2005 there was a reduction of nearly £60m in counterfeit and fraud on lost and stolen cards (a drop of 24%) compared to 2004.

Said Sandra Quinn of chip and PIN: “Britain is now a truly mature chip and PIN nation. Millions of people have adapted to the change with no problems at all. This means that we are all a lot safer when we go shopping, and that fraudsters have been denied millions of pounds of stolen money. Of course it hasn’t eradicated fraud, it never could, as fraudsters will continue to target us and our money. But it is a fact that chip and PIN has made our cards safer than they were two years ago and banks and retailers will continue to work together to keep it this way. Now we need to remain vigilant, as fraudsters will always try to find other ways to get hold of our money. That is why we are constantly reminding cardholders how to protect themselves from fraud.”

Now, readers will recall recent trouble when the new chip and PIN cards suffered some fraud. What we see above is the success story but only a mention of the failure story, leaving us unsure what to make of the numbers. Last year, APACS reported that Internet fraud now accounts for one quarter of all fraud losses in the UK, so they are certainly capable of reporting fraud.

Here's an older story giving some indication (again from APACS):

The Scotsman reports on the impact on card fraud from the introduction of chip and PIN technology in the UK, reducing credit and debit card losses by 13 percent in the first six months of 2005.

The figures showed counterfeit card fraud fell by 31%, fraud on lost or stolen cards dropped by 27%, losses on cards that went missing in the mail was 37% lower and identity theft on payment cards was down by 16%

Not quite as rosy as the chip&PIN story would have us believe, and others are skeptical. More tarnished image for the US banks for deceptive practices:

The Office of the Comptroller of the Currency has issued new guidance on disclosure and marketing issues associated with gift cards - focusing on "the need for national banks that issue gift cards to do so in a manner in which both purchasers and recipients are fully informed of the product's terms and conditions." ... Basic information that is most essential to a gift card recipient's decisions about when and how to use the card should be provided on the gift card itself, or on a sticker or tape affixed to the gift card. Disclosures should generally tell consumers:

• The expiration date of the card (which should appear on the front of the card);
• The amount or the existence of any monthly maintenance, dormancy, usage or similar fees;
• How to obtain additional information about their cards or other customer service (for example, by providing a toll free number or website address).

The OCC's new guidance also advises national banks to avoid practices that could be misleading to consumers. For example, issuers should not advertise a gift card with "no expiration date" if monthly service or maintenance fees, dormancy fees or similar charges can consume the card balance. Similarly, if fees may consume the card balance before the stated expiration date, disclosures related to that expiration date should explain that possibility. Issuers should also avoid describing gift cards as if they are gift certificates or other payment instruments more familiar to consumers, or as products that carry federal deposit insurance.

This is bad news because it indicates that deceptive behaviour is prevalent in the gift card business. (Note that the pre-paid / gift card business is exploding, as Dave Birch reports and as I mooted last year in bull #4. E.g. this is a significant sector for financial cryptographers to track. From PN, see also WSJ and Teenage spending.)

One would expect that banks would not engage in such ... but the need for guidance suggests otherwise. Indeed, is the following deceptive behaviour by APACS, in the aforementioned press release?

The consumer continues to be protected from card fraud losses by The Banking Code. Nothing changes for the consumer. Just as now, cardholders do need to be responsible in protecting their cards and keep their PIN a secret.

Right. But what about the retailers and any liability shift in chip & PIN? And, to underscore the ability of the banks to shift liability:

The survey of 2,000 net users found that five per cent had fallen victim to scams and had lost out financially. Half of victims received no compensation from their banks while one in ten is still waiting for the matter to be resolved.

Here's more evidence on how easy it is to fool people when someone ran a random survey for ID theft bait:

• More than 70% of respondents gave up their mother's maiden name
• More than 90% of people provided both their date and place of birth
• Nearly 55% explained how they devise their online passwords
• Nearly 85% of respondents provided their full name, current street address, and email address

Is card fraud going up or down? Visa says down:

Visa says fraud accounts for about 7 cents of every $100 spent on its credit cards, an all-time low and about half the rate of 10 years ago.

And APACS says up:

Last year, credit card fraud was equivalent to £12 for every cardholder in the UK. The amount lost every year has jumped by a massive 600 percent over the last six years. Last year, the Which? survey had found that six percent of current account holders and five percent of credit card holders had been a victim of fraud at some point of time. The Association of Payment Clearing Services (APACS) says that UK card fraud hit over £500 million last year, a 20 percent rise from the figures in 2003.

CyberSource says up, for retailers (but original Yahoo source is lost):

CyberSource has announced the results of its 7th annual CyberSource Fraud Survey. Among the survey's findings, the estimate for ecommerce fraud losses increased to more than $2.8 billion for 2005, an 8% increase over the year before. Although the overall rate of fraud loss remained relatively constant at 1.6% of revenue, mid-to-large merchants selling $5-$25 million annually online reported fraud losses increasing from 1.5% to 1.8% of revenue while those selling over $25 million reported losses increasing from 1.1% to 1.2% of revenue.

So maybe we can suspect that the banks are becoming more successful in shifting the fraud losses away from themselves and on to consumers and/or retailers. JPM reports that it's ever present:

Retail operations have "slippage" (shop lifting) ... it is just built right in to the figures. They expect that slippage will be 4% on an ongoing basis, but 3% in video stores, but 5% in candy stores, 0.05% in petrol stations ("drive offs"), etc.

Plenty of room to shift out some bank liabilities then! The problem with shifting the liabilities is that the consumer pays in the end, regardless of how the cut is taken. So our objective should not be for any one party to just reduce their own liabilities -- they can always pass it on -- but instead to identify the most efficient place to accept and pay for the frauds.

Where is that place, then? And, where is the debate about how payment systems operators, retailers and consumers create that efficient sharing?

Firefox as a mainstream security risk - three threats

As predicted, Firefox is now a member of that unenviable club -- "fair game" for crackers:

Upon successful execution, FormSpy hooks mouse and keyboard events in the Mozilla Firefox web browser. It can then forwards information such as credit card numbers, passwords and URLs typed in the browser to a malicious website hosted at IP address 81.95.xx.xx.

And, a bunch of reports on a security advisory 1, 2, 3, 4.

Also, a very strange one where PrivSoft, security firm labelled a root key as viral from the Bermudan certificate authority QuoVadis:

On Saturday, July 22, 2006 we added a "signature" to BOClean called "QUOVADIS" based upon a submission to us by one of our external malware research partners. The submission was reviewed by one of our own malware analysts and was determined to be extremely suspicious because it modified the Windows registry "trusted certificates" store and that's always a "no-no." The fact that it was submitted out of context to its origin unfortunately lead us to believe by its design and nature that it was a Mozilla hijacker since it appeared to be legitimate and yet didn't pass the "smell test" because of its internal contents and behavior. We encounter similar "infections" often. The decision was "unfortunately" made to err on the side of caution and INCLUDE it in BOClean's update of that day.

Within a little over an hour, based upon numerous complaints of a "false positive," we removed detection for the NSSCKBI.DLL file as QUOVADIS malware. Now, we're not quite sure if there actually isn't an issue there, though apparently not one that rises to the level of an actual piece of malware since Mozilla's browsers are "trusted." As is the case with any "surprise" here, a post mortem remains in progress on our end to bring closure and internal policy changes to prevent any future "unfortunate events" such as this.

Mozilla's NSSCKBI.DLL file contains a number of "secure sockets layer" (SSL) certificates, including certificates from several unknown and possibly dubious "certifying authorities." ...

I don't fully understand that, but it reads as though someone complained about the Quovadis root key (which I understand to be a valid CA), and the security firm blocked the whole root list in the DLL? Either way, "privsoft" seems to have been disconnected from the net as we know it; the information on who is a valid CA or not is widely available on Mozilla's pages. And an email to Frank would have sorted it out...

It will be interesting to see just what this complaint really was -- an enterprising CA engaged in corporate provocation? Bad security firms dropping the bundle like they did with Sony? Or is the Quovadis root really involved in some sense in a malicious change the windows registry? Keep it up, guys, us ignorant journos and our readers want scandal, intrigue, and see if you can do something about spies and tits for us too, please!

What else? Well, I've also seen a demo of the latest generation attacks against Firefox (if you read the blog, you know what I mean). Unfortunately, when it was shown around, the banks said "oh-my-god, who have you shown this to? you can't reveal this..."

This is a direct case of fear of fingerpointing, which I outline in my paper on "The Market for Silver Bullets."

Should such things be published? The answer is YES! Firstly, the attackers already have this, they are smarter and more focussed, and if they only appear not to have attacked it is because they have other things to do that make them money. Focus, ROI, two easy words. (As if to underscore this point, first reports have it that European banks are being attacked with an innovative MITB that asks for two TANS, so far targetted at IE only.)

Did I say that the attackers were smarter than the banks? Yes, I did. Get used to it.

Secondly, consider the *user* community, which includes all Alices and Bobs, all Grandmas, all banks in countries where they haven't figured it out yet (e.g., the US of A), and all the other non-bank suppliers who are about to be surprised at how far this threat reaches.

They ... heck ... *we all need this information* so that they can assess risks in going forward. It may surprise the banks, but it is their customers' right to know when it is unsafe to engage in online banking.

Why this discrepancy? The banks do not carry the costs of risks to others, so they don't care. They only care about their own costs, which in the end are surprisingly limited, surprisingly manageable, even in the American phishing epidemic.

Why then are the banks so fiercely protective of their security weaknesses? Because embarrassment in the press is far more costly than any mere security breach! As they bear these costs themselves, directly, and the costs spread contagiously through the industry, they are vulnerable to what I call fingerpointing. This then drives them to render all security issues under a secrecy order, industry wide. For more understanding of why banks are not particularly concerned about the user's risks, read the paper.

Which leaves me wondering where Firefox is heading, market-wise. If anything, things like GreaseMonkey and the spectacular plugins market are making Firefox a more likely target for security concerns. I've also noticed a bit of a ground shift in talk over at Mozilla -- they no longer refer to Firefox as more secure than IE. That is wise, as it seems that Microsoft are doing more in that area. If the IE and Vista teams succeed in making a difference, Firefox can expect to be hammered into the ground.

Which isn't necessarily bad. Mozilla are leaning towards a mission of "choice" in tools, which is no bad mission. It's simply not necessary or smart to be all things to all people, it is better to concentrate on where we can make a difference.

But it does leave a hole in the market for a security browser. And it raises the question for the FC blog of revising our top tips for security. Any call?

Case Study: Thunderbird's brittle security as proof of Iang's 3rd Hypothesis in secure design: there is only one mode, and it's secure.

In talking with Hagai, it was suggested that I try using the TLS/IMAP capabilities of Thunderbird, which I turned on (it's been a year or two since the last time I tried it). Unfortunately, nothing happened. Nothing positive, nothing negative. Cue in here a long debate about whether it was working or not, and how there should be a status display, at least, and various other remedies, at most.

A week later, the cleaning lady came in and cleaned up my desk. This process, for her, also involves unpowering the machine. Darn, normally I leave it on for ever, like a couple of months or so.

On restarting everything, Thunderbird could not connect to the mail servers. Our earlier mystery is thus resolved - the settings don't take effect until restart. Doh!

So, how then did Thunderbird handle? Not so well, but it may have got there in the end. This gives me a change to do a sort of case study in 1990s design weaknesses, a critique in (un)usability, leading to design principles updated for this decade.

To predict the punch line, the big result is that there should only be one mode, and it should be secure. To get there more slowly, here's what I observed:

Firstly, Thunderbird grumbled about the certificate being in the wrong name. I got my negative signal, and I knew that there was something working! Hooray!

But, then it turned out that Thunderbird still could not connect, because "You have chosen secure authentication, but this server does not offer it. Therefore you cannot log in..." Or somesuch. Then I had to go find that option and turn it off. This had to be done for all mail accounts, one by one.

Then it worked. Well, I *guess* it did... because funnily enough it already had the mail, and again had not evidenced any difference.

Let's break this up into point form. Further, let's also assume that all competing products to be as bad or worse. I actually *choose* Thunderbird as my preferred email client, over say Kmail. So it's not as bad as it sounds; I'm not "abandoning Thunderbird", I'm just not getting much security benefit from it, and I'm not recommending it to others for security purposes.

1. No caching of certs. There is no ability to say "Yes, use that cert for ever, I do know that the ISP is not the same name as my domain name, dammit!!!!" This is an old debate; in the PKI world, they do not subscribe to the theory that the user knows more than any CA about her ISP. One demerit for flat earth fantasies.
2. No display anywhere that tells me what the status of the security is. One demerit. (Keep in mind that this will only be useful for us "qualified cryptoplumbers" who know what the display means.)
3. I can choose "secure authentication" and I can choose "secure connection." As a dumb user, I have no idea what that means, either of them. One demerit.
4. If I choose one of those ON, and it is not available, it works. Until it doesn't -- it won't connect at some later time and it tells me to turn it off. So as a user I have a confusing choice of several options, but ramifications that do not become clear until later.

   Another demerit: multiple options with no clear relationship, but unfortunate consequences.

5. Once it goes wrong, I have to navigate from a popup telling me something strange, across to a a series of boxes in some other strange area, and turn off the exact setting that I was told to, if I can remember what was on the popup. Another demerit.
6. All this took about 5 minutes. It took longer to do the setting up of some security options than it takes to download, install, and initiate an encrypted VoIP call over Skype with someone who has *never used Skype before*. I know that because the previous night I had two newbies going with Skype in 3 minutes each, just by talking them through it via some other chat program.
7. Normal users will probably turn it all off, as they won't understand what's really happening, and "I need my mail, darnit!"

   (So, we now start to see what "need" means when used by users... it means "I need my email and I'll switch the darned security rubbish off and/or move to another system / supplier / etc.)

8. This system is *only useable by computer experts.* The only reason I was able to "quickly" sort this out was because I knew (as an experienced cryptoplumber) exactly what it was trying to do. I know that TLS requires a cert over the other end, *and* there is a potential client-side cert. But without that knowledge, a user would be lost. TLS security as delivered here is a system is not really up to use by ordinary people - hence "brittle."

We can conclude that this is a nightmare in terms of:

• usability.
• implementation.
• design.
• standards.

Let's put this in context: when this system was designed, we didn't have the knowledge we have now. Thunderbird's security concept is at least 3 years old, probably 8-10 years old. Since those years have passed, we've got phishing, usability studies, opportunistic crypto, successful user-level cryptoapps (two, now), and a large body of research that tells us how to do it properly.

We know way more than we did 3 years ago - which was when I started on phishing. (FTR, I suggested visit counts! How hokey!)

Having got the apologies off our chest, let's get to the serious slamming: If you look at any minor mods to the Thunderbird TLS-based security, like an extra popup, or extra info or displays, you still end up with a mess. E.g., Hagai suggested that there should be an icon to display what is going on - but that only helps *me* being an experience user who knows exactly what it is trying to tell me. I know what is meant by 'secure authentication' but if you ask grandma, she'll offer you some carrot cake and say "yes, dear. now have some of this, I grew the carrots myself!"

(And, in so doing, she'll prove herself wiser than any of us. And she grows carrots!)

Pigs cannot be improved by putting them in dresses - this security system is a pig and won't be improved by frills.

The *design* is completely backwards, and all it serves to do is frustrate the use of the system. The PKI view is that the architecture is in place for good reasons, and therefore the user should be instructed and led along that system path. Hence,

"We need to educate the users better."

That is a truly utterly disastrous recommendation. No! Firstly, the system is wrong, for reasons that we can skip today. Secondly, the technical choices being offered to the users are beyond their capabilities. This can never be "educated." Thirdly, it's a totally inefficient use of the user's time. Fourthly, the end effect is that most users will not ever get the benefit.

(That would be a mighty fine survey -- how many users get the benefit of TLS security in Thunderbird? If it is less than 10%, that's a failure.)

The system should be reversed in logic. It should automatically achieve what it can achieve and then simply display somewhere how far it got:

1. Try for the best, which might be secure auth, and then click into that. Display "Secure Auth" if it got that far.
2. If that fails, then, fallback to second best: try the "Secure Conn" mode, and display that on success.
3. Or finally, fall back to password mode, and display "Password only. Sorry."

The buttons to turn these modes on are totally unneccessary. We have computers to figure that sort of nonsense out.

Even the above is not the best way. Fallback modes are difficult to get right. They are very expensive, brittle even. (But, they are better - far far far cheaper - than asking the user to make those choices.) There is still one way to improve on this!

Hence, after 5 demerits and a handful of higher-level critiques, we get to the punchline:

To improve, there should only be one mode. And that mode is secure. There should be only one mode, because that means you can eliminate the fallback code. Code that falls back is probably twice as large as code that does not fallback. Twice as brittle, four times as many customer complaints. I speak from experience...

The principle, which I call my 3rd Hypothesis in Secure Protocol Design, reads like this:

There is only one mode, and it is secure.

If you compare and contrast that principle with all the above, you'll find that all the above bugs magically disappear. In fact, a whole lot of your life suddenly becomes much better.

Now, again, let's drag in some wider context. It is interesting that email can never ever get away from the fact that it will always have this sucky insecure mode. Several of them, indeed. So we may never get away from fallbacks, for email at least.

That unfortunate legacy should be considered as the reality that clashes with the Hypothesis. It is email that breaches the Hypothesis, and it and all of us suffer for it.

There is no use bemoaning the historical disaster that is email. But: new designs can and will get it right. Skype has adopted this Hypothesis, and it took over - it owns VoIP space in part because it delivered security without the cost. SSH did exactly the same, before.

In time, other communication designs such as for IM/chat and emerging methods will adopt Hypothesis #3, and they will compete with Skype. Some of the mail systems (Start/TLS ?) have also adopted it, and where they do, they do very well, allegedly.

(Nobody can compete with SSH, because we only need one open source product there - the task is so well defined there isn't any room for innovation. Well, that's not exactly true - there are at least two innovations coming down the pipeline that I know of but they both embrace and extend. But that's topic drift.)

Apple to help Microsoft with "security neutrality"?

Peter points to news that Apple are moving (back) to a proprietary OS. It's not entirely clear as yet, but it looks like the Intel Mac OSX will go proprietary.

Apple still publishes the source code for OS X's commands and utilities and laudably goes several extra miles by open sourcing internally developed technologies such as QuickTime Latest News about QuickTime Streaming Server and Bonjour zero-config networking.

The source code required to build a customized OS X kernel, however, is gone. Apple says that the state of an OS X-compatible open source x86 Darwin kernel is "in flux."

The article waxes on about performance and tuning and the like, but I worry about security. The reason this blog's "Top Tip #1" for your security is to buy a Mac is not because I like them, but because they are relatively secure. Relative being the operative word here -- for best user-bang-for-buck, they are the way to go if security is your need.

The marketing people will likely waffle on about how they can be just as secure with a proprietary OS as without. "Honest Injun!"

Nonsense. Here's what happens. Once the public scrutiny goes, the internal food fights start. Once the OS team no longer has the easy excuse of "that's insecure and _someone will notice_," all of the application teams' marketing directors will be lining up to throw old eggs and rotten tomatoes at the OS team.

Going open source doesn't make it secure -- you've still got to do the hard work. It only makes it possible to go secure. And without it, it is unlikely that you can be secure in a complex, multi-application, mammoth user base scenario like Apple's, no matter how good your people are. Open source works like governance in security, it's the feedback mechanism that keeps you honest.

If Apple withdraws the committment to open, honest security, I'd give it five years, and they won't be able to open it again. They'll have caught up with Microsoft, the OS will be riddled inside with strange and scary artifacts, and that nice shiny apple will be skin, only, the worms having eaten the core away.

Still, one supposes that the other guys needs a "level playing field." Or perhaps we should call it "security neutrality" to use the current inanity. There's a thought -- Adam is going to work for Microsoft security. Wouldn't it be ironic if Microsoft were to announce an open source policy ... beyond the Chinese government that is ... and take another bite out of the apple?

Sealand - more pictures

Fearghas points to more graphical evidence of risk practices from the Lifeboat station in Harwich.

For those bemused by this attention -- a brief rundown of "Rough Towers," a.k.a. Sealand. Some 5 or so years ago, some colourful libertarian / cypherpunk elements started a "data haven" called Havenco running in this "claimed country". Rumour has it that after the ISP crashed and burnt, all the servers were moved up the Thames estuary to London.

Not wishing to enter into the discussion of whether this place was *MORE* risky or less risky ... Chandler asks:

What kind of country doesn’t have a fire department? One that doesn’t plan on having a fire, as evidenced by the fact that Sealand/HavenCo didn’t have fire insurance.

Well, as they were a separate jurisdiction, they probably hadn't got around to (ahem) legislating an insurance act? Or were you thinking of popping into the local office in Harwich and picking up a home owner's policy?

:) More pictures on site.

FC++3 - Concepts against Man-in-the-Browser Attacks

This emerging threat has sent a wave of fear through the banks. Different strategies have been formulated and discussed in depth, and just this month the first roll-outs have been seen in Germany and Austria. This information cries out for release as there are probably 10,000 other banks out there that would have to go through and do the work again.

Philipp Gühring has collected the current best understanding together in a position paper entitled "Concepts against Man-in-the-Browser Attacks."

Abstract. A new threat is emerging that attacks browsers by means of trojan horses. The new breed of new trojan horses can modify the transactions on-the-fly, as they are formed in in browsers, and still display the user's intended transaction to her. Structurally they are a man-in-the-middle attack between the the user and the security mechanisms of the browser. Distinct from Phishing attacks which rely upon similar but fraudulent websites, these new attacks cannot be detected by the user at all, as they are use real services, the user is correctly logged-in as normal, and there is no difference to be seen.

The WYSIWYG concept of the browser is successfully broken. No advanced authentication method (PIN, TAN, iTAN, Client certificates, Secure-ID, SmartCards, Class3 Readers, OTP, ...) can defend against these attacks, because the attacks are working on the transaction level, not on the authentication level. PKI and other security measures are simply bypassed, and are therefore rendered obsolete.

If you are not aware of these emerging threats, you need to be. You can either get it from sellers of private information or you can get it from open source information sharing circles like FC++ !

FC++3 - The Market for Silver Bullets

In this paper I dip into the esoteric theory of insufficient markets, as pioneered by Nobel Laureate Michael Spence, to discover why security is so difficult. The results are worse than expected - I label the market as one of silver bullets. Yes, there are things that can be done, but they aren't the things that people have been suggesting.

This paper is a bit tough - it is for the serious student of econ & security. Far from being the pragmatic "fix this now" demands of Philipp Gühring and the "rewrite it all" diagnosis of Mark Miller, it offers a framework of why we need this information out there in the public sphere.

What is security?

As an economic `good' security is now recognised as being one for which our knowledge is poor. As with safety goods, events of utility tend to be destructive, yet unlike safety goods, the performance of the good is very hard to test. The roles of participants are complicated by the inclusion of agressive attackers, and buyers and sellers that interchange.

We hypothesize that security is a good with insufficient information, and reject the assumption that security fits in the market for goods with asymmetric information. Security can be viewed as in a market where neither buyer nor seller has sufficient information to be able to make a rational buying decision. These characteristics lead to the arisal of a market in silver bullets as participants herd in search of best practices, a common set of goods that arises more to reduce the costs of externalities rather than achieve benefits in security itself.

Does it really show that the security market is one of silver bullets, and best practices are bad, not good? You be the judge! That's what we do in FC++, put you in the peer-review critic's seat.

Security Absurdity: The Complete, Unquestionable, And Total Failure of Information Security

Mark points to Noam Eppel. If you haven't subscribed to the "total collapse of security and humanity as we know it" theory, then I'd encourage you to read "Security Absurdity: The Complete, Unquestionable, And Total Failure of Information Security." Even just skimming the list of headline failures will help :)

They say if you drop a frog in a pot of boiling water, it will, of course, frantically try to clamber out. But if you place it gently in a pot of tepid water and turn the heat on low, it will float there quite placidly. As you turn up the heat, the frog will sink into a tranquil stupor and before long, with a smile on its face, it will unresistingly allow itself to be boiled to death. The security industry is much like that frog; completely and uncontrollably in disarray - yet we tolerate it since we are used to it.

It is time to admit what many security professionals already know: We, as security professionals, are drastically failing ourselves, our community, and the people we are meant to protect. ...

You may not agree with the central claim, but at least the article clearly lays out the evidence, from top to bottom. It is important to understand the claim and its foundations, even if you don't agree, because much of the new work that is being done is based on the complete replacement of large chunks of old wisdom. This only makes sense if we can claim that the old ways were wrong.

(If you want more, here's a reference: I broached this subject in a recent JIBC article l wherein I assumed security was a failure, and went on to list some of the open areas of research.)

Black Helicopter #2 (ThreatWatch) - It's official - Internet Eavesdropping is now a present danger!

A group of American cryptographers and Internet engineers have
criticised the FCC for issuing an order that amounts to a wiretap instruction for all VoIP providers.

For many people, Voice over Internet Protocol (VoIP) looks like a nimble way of using a computer to make phone calls. Download the software, pick an identifier and then wherever there is an Internet connection, you can make a phone call. From this perspective, it makes perfect sense that anything that can be done with a telephone, including the graceful accommodation of wiretapping, should be able to be done readily with VoIP as well.

The FCC has issued an order for all ``interconnected'' and all broadband access VoIP services to comply with Communications Assistance for Law Enforcement Act (CALEA) --- without specific regulations on what compliance would mean. The FBI has suggested that CALEA should apply to all forms of VoIP, regardless of the technology involved in the VoIP implementation.

In brief the crypto community's complaint is that it is very difficult to implement such enforced access, and to do so may introduce risks. I certainly agree with the claim of risks, as any system that has confused requirements becomes brittle. But I wouldn't bet on a company not coming out with a solution to these issues, if the right way to place the money was found. I've previously pointed out that Skype left in a Centralised Vulnerability Party (CVP, sometimes called a TTP), and last week we were reminded of the PGP Inc blunder by strange and bewildering news over in Mozilla's camp.

So where are we? The NSA has opened up the ability to pen-trace all US phones, more or less. Anyone who believes this is as far as it goes must be disconnected from the net. The EFF's suit alleges special boxes that split out the backbone fibre and suck it down to Maryland in real time. The FBI has got the FCC to order all the VoIP suppliers into line. Mighty Skype has been brought to heel by the mighty dollar, so it's only a phone call away.

Over in other countries - where are they, again? - there is some evidence that police in European countries have routine access to all cellphone records. There is other evidence that the EU may already have provided the same call records to the US (but not the other way around, how peculiar of those otherwise charming Europeans) in much the same way as last week the EU were found to be illegally passing private data on air travellers. To bring this into perspective, China of course leads the *public* battle for most prominent and open eavesdropper with their Cisco Specials, but one wonders whether they would be actually somewhat embarrassed if their capabilities were audited and compared?

If you are a citizen of any country, it seems, you need not feel proud. What can we conclude?

1. Eavesdropping has now moved to a real threat for at least email and VoIP, in some sense or other.
2. Can we say that it is a validated threat? No, I think not. We have not measured the frequency and cost levels so we have no actuarial picture. We know it is present, but we don't know how big it is. I'll write more on this shortly.
3. The *who* that is doing it is no longer the secure, secret world of the spooks who aren't interested in you. The who now includes the various other agencies, and they *are* interested in you.
4. Which means we are already in a world of widespread sharing across a wide range of government agencies. (As if sharing intel has not been a headline since 9/11 !)
5. it is only one step from open commercial access. Albeit almost certainly illegal, there isn't likely to be anything you can do about illegally shared data, because it is the very agents of the law which are responsible for the breach, and they will utter the defence of "national security," to you, and the price, to your attacker.
6. An assault on crypto can't be that far off. The crypto wars are either already here again, or so close we can smell them.
7. We are not arguing here, today, whether this is a good thing for the mission to keep us safe from terrorists, or a bad thing. Which is just as well, because it appears that when they are given the guy's head on a plate, the law enforcement officers still prefer to send out for takeaway.

My prediction #1for 2006 that government will charge into cyberspace in a big way is pretty much confirmed at this stage. Obviously this was happening all along, so it was going to come out. How important is this to you the individual? Here's an answer: quite important. And here's
some evidence:

What is Political Intelligence?Political intelligence is information collected by the government about individuals and groups.
Files secure under the Freedom of Information Act disclose that government officials have long been
interested in all forms of data. Information gathered by government agents ranges from the most personal data about sexual liaisons and preferences to estimates of the strength of groups opposing U.S. policies. Over the years, groups and individuals have developed various ways of limiting the collection of information and preventing such intelligence gathering from harming their work.

It has now become routine for political activists -- those expressing their rights under democracy -- to be investigated by the FBI. In what is a blowback to the days of J.Edgar Hoover, these activists now routinely advising their own people on how to lawfully defend themselves.

Hence the pamphlet above. There are two reasons for gathering information on 'sexual liasons and preferences.' Firstly, blackmail or extortion. Once an investigator has secret information on someone, the investigator can blackmail -- reveal that information -- in order to extort the victim to turn on someone else. Secondly, there may be some act that is against the law somewhere, which gives a really easy weapon against the person. Actually, they are both the same reason.

If there is anyone on the planet who thinks that such information shouldn't be protected then, I personally choose not to be persuaded by that person's logic ("I've got nothing to hide") and I believe that we now have a danger. It's not only from the harvesting by the various authorities:

Peter G, 41, asked for a divorce from his wife of six years, Lori G, 38, in March 2001. ... Lori G filed a counterclaim alleging the following: <snip...> and wiretapping. The wiretapping charges are what make this unfortunate case relevant to Police Blotter. ... But Peter admitted to "wiretapping" Lori's computer.

The description is general: Peter used an unspecified monitoring device to track his wife's computer transactions and record her e-mails. Lori was granted $7,500 on the wiretapping claim. ...

This is hardly the first time computer monitoring claims have surfaced in marital spats. As previously reported by CNET News.com, a Florida court ruled last year that a wife who installed spyware on her husband's computer to secretly record evidence of an extramarital affair violated state law.

Some hints on how to deal with that danger. Skype is probably good for the short term in talking to your loved one while he still loves you, notwithstanding their CVP, as that involves an expensive, active aggressive act which incurs a risk for the attacker. However, try and agree to keep the message history off - you have to trust each other on this, as the node and your partner's node remain at greater danger. Email remains poor because of the rather horrible integration of crypto into standard clients - so use Skype or other protected chat tools.

Oh, and buy a Mac laptop. Although we do expect Macs to come under increased attention as they garner more market share, there is still a benefit in being part of a smaller population, and the Mac OS is based on Unix and BSD, which has approximately 30 years of attention to security. Windows has approximately 3 years, and that makes a big difference.

(Disclosure: I do not own a Mac myself, but I do sometimes use one. I hate the GUI, and the MacMini keyboards are trash.)

Microsoft - will they bungle the security game?

I suspect Microsoft are going to blow the security game. Here's the evidence:

A recent Microsoft update to Windows XP, which modifies the tool that verifies the "validity" of XP installations to ensure that they are not illicit, may itself be considered to be spyware under commonly accepted definitions.

The new version of the "Microsoft Genuine Advantage" tool reportedly will repeatedly nag users of systems it declares to be invalid, and will then apparently deny such users various "non-critical" updates. Apparently various parties have already found ways to bypass this tool, though the effects of this on later updating capabilities remain to be seen.

However, I've noted a much more serious issue on local XP systems, all of which are legit and pass the MS validity tests with flying colors. It appears that even on such systems, the MS tool will now attempt to contact Microsoft over the Internet *every time you boot*. At least, I'm seeing these contacts on every boot after the tool update so far, and I've allowed them to proceed to completion each time. Perhaps it stops after some number of boots, but there's no indication of such a limit so far. The connections occur even if you do not have Windows "automatic update" enabled. ...

That's about XP, their older product. Here's what what they are trying to address:

Microsoft (Nasdaq: MSFT) Latest News about Microsoft on Monday revealed the results of a 15-month test of its Malicious Software Removal Tool. The utility that seeks out and destroys malware reported malicious programs, or bots, on six out of 10 Windows computers it examined.

And here's the problem. Microsoft are responsible for the old mess, and to their credit, they are in some sense or other recognising the size of the problem by reporting on it, above. (They can't go too far, otherwise they'll be dealing with the MOACAS - mother of all class action suits.)

So they are doing what others -- Symantec, Kapersky, etc -- have developed over decades to fix the product: putting in anti-virus tools and pretending that these are the latest must-have fashion accessories.

Can you say conflict of interest ? On the superficial level, we have these problems:

1. they are making money off the problems they delivered last time. Well, sometimes that is good, but not always, not when everyone knows it.
2. any problem they fix is subject to approval and re-interpretation by the publicity arms. That is, you can't fix a problem if you have to reveal it, and the PR people say it's too dangerous to reveal.
3. their efforts to fix these problems are subject to capture by the sales arm. So this is why you are seeing efforts like the above. It's not that the sales arm says "you must make the product sell more Vista..." No, it is more subtle than that. It is as if a thousand helping hands turn up to help if the solution helps Vista sales, and those same thousand hands hold little razors that take little nicks out of you if your solution slows down sales of Vista.

But even deeper than that, we have the dangers of feedback loops generating perverse solutions. The anti-virus companies had at least the market to keep them honest. They were symbiotes, feeding of the host, like those little fish that follow sharks. The rewards and punishments were fairly clear.

Microsoft will not have the market to keep itself honest: it is the market for the OS, it is the owner of the user's computer, it owns the mess, and it is now the fixer of the mess. That's not to say that they won't get it right, but that there is no negative feedback force in this "I'm my own symbiote" market to stop perverse solutions and kill them before they do too much damage.. And there are positive feedback forces, as listed above.

Not to mention brittle. These complicated systems could result in quite serious DOS attacks. Seen on Risks / slashdot:

An anonymous Slashdot user gives virus writers a worrying idea: "A virus could use one of the 'Product-Key Changer' scripts ... to install a pirated product key on every infected computer (wiping all traces of the original key). This would render millions of genuine installations indistinguishable from pirated installations. What a mess for Microsoft! They would have to immediately 'kill forever' the WGA helper, and maybe even remove the WGA check on Windows Update. Such a virus would be a hard lesson to learn for the writers of all kinds of automated 'genuine' checks."

What about Vista? Well, the signs are that Vista is constructed along the same lines. Same thinking, same techniques. So at the same time as Microsoft are swallowing the little cleaner fish in the old XP market, they are bringing out a new shark with no cleaning fish.

If I was responsible for a doze network, I'd be terrified of being the first penguin. I'd really want some other penguin over on the other side of town to play with the shark for a year or so.

Mike Nash, who was security czar over at Microsoft for the period of the Vista development now steps aside, and here's what incoming Ben Fathi says when probed on the future (which is post Vista):

Q: Is there's anything that you can tell us about what's on the horizon when it comes to security at Microsoft.

We are concentrating on what Bill Gates talked about in February at the RSA Conference. There are four areas to our security vision: a trust ecosystem; engineering for security; simplicity; and fundamentally secure platforms. We have done a lot of investments in all of those areas, and I'm going to continue those investments.

Look at, for example, the trust ecosystem, the first step in that was delivering Active Directory Federation Services in Window Server 2003 R2. The next step, and we've done some of this in Vista, is adding things like certificate lifecycle management, so enterprises can manage digital certificates. InfoCard is also an example.

In terms of engineering for security, that's all about the Security Development Lifecycle. It applies to all of our products, not just Windows, obviously. But what we're finding is that we need to make the SDL (Security Development Lifecycle) more agile with things like MSN and Windows Live having very short development cycles and needing quick updating.

Well, at least Microsoft has a Security Czar - many organisations do not. And, he's been brave (foolhardy?) enough to state what he's aiming for:

Finally, a fundamentally secured platform, that's the part I feel I will be reviewed on. It is about taking a lot of our investments in the platform itself and Windows and improving them.

I think I predicted a while back that Microsoft would have to adopt another OS in order to save their security situation. Like Apple did. Microsoft are also betting big on CardSpace (was InfoCard) saving their security bacon. I wrote long and probably scathingly about that a few months back. Here's some more skepticism:

Microsoft is emphasizing the ease of adoption for CardSpace, which is a nice way of saying that they're begging developers to get involved. For a proof of concept project, says Turner, all it takes to use the technology is to embed a bit of XML in your Web site, and to update the sign-in page. A three-line code change is all that's necessary to change from self-issued to managed infocards.

And, they stress, all this can be done with non-Microsoft technologies, including Java and Linux. "The only Microsoft bit here is Infocard," said Turner.

CardSafe will be built into Windows Vista, and will be available for Windows XP and Windows Server 2003, the company says. (Betas and CTPs are available here.) According to Turner, Microsoft is pushing for a CardSafe RTM (Release to Manufacturing) "in just a few months."

For CardSafe to succeed, it will need buy-in from more than site developers. The company is exhorting financial firms and other such organizations — pleading might be a better word — to participate in the managed card program as Indentity Providers.

It's probably fair to guess that companies are not going to sign up with gay abandon like they did with the last lot. It's also a no-brainer that anyone who suggests that it only takes a three-line code change in a website is someone who's never actually done it. And allowing Microsoft to manage the Identity that closely is not something that financial providers are going to be comfortable with.

Unfortunately, the bottom line is that it doesn't actually solve the problem we are currently looking at. The emerging threat is one of authorisation, not authentication -- Identity is the wrong problem. So unless CardSpace can address authorisation in some compelling way, it's back to the old game of rolling out those SecureId tokens and discovering that the attacker bypasses them as well. That's not out of the question, but given the complexity of understanding what all that means, I don't have high hopes.

So my call for the moment - CardSpace is version 3 of this story, and the only benefit will be if it takes Microsoft closer to version 4.

But given the number of cards they have stacked up in their hands at the moment, CardSpace could be overwhelmed even if it does work out. Unfortunately for Microsoft, others are waiting, this time, and they've had their 3 years of re-write opportunity.

Naked Payments III - the well-dressed bank

Bigmac writes: The next levels in scams (sorry, it's in single Dutch, translations welcome):

A very well setup advance fee scam where they not only had a fake ING website but actually two complete ING offices, next to real ING offices; one on schiphol, one close to the old headquarters (? don't know where).

Did you hear the one about the fake NEC factory in Taiwan? They just pretended to be NEC but actually sold product, did R&D, everything.

(The fake NEC factory was written up on Bruce Schneier's blog, I'll chase the link when I get back. Back in times long past, the Japanese went one better - they named a region Usa so they could stamp "MADE IN USA" on their packages. Life goes on in the IP theft department...)

• Naked Payments I - New ISO standard for payments security - the Emperor's new clothes?
• Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
• Naked Payments III - the well-dressed bank
• Naked Payments IV - let's all go naked

How much is all my email worth?

I have a research question. How much is all my email worth? As a risk / threat / management question.

Of course, that's a difficult thing to price. Normally we would price a thing by checking the market for the thing. So what market deals with such things?

We could look at the various black markets but they are more focussed on specific things not massive data. Sorry, bad guys, not your day.

Alternatively, let's look at the US data brokers market. There, lots and lots of data is shared without necessarily concentrating on tiny pickings like credit theft identifiers. (Some of it you might know about, and you may even be rewarded for some of it. Much is just plain stolen out of sight. But that's not today's question.) So how much would one of those data broker's pay for *full* access to my mailbox?

Let's assume I'm a standard boring rich country middle class worker bee.

Another way to look at this is to look at google. It makes most of the money in advertising, and it does this on the tiny hook of your search query. It is also experimenting with "catalogue your hard drive" products (as with Apple's spotlight and no doubt Microsoft and Yahoo are hyperventilating over this already). So it must have a view as to the value of *everything*.

So, what would it be worth to those companies to *sell* the entire monitoring contents of my email, etc, for a year to Yahoo, Google, Microsoft, or Apple? Imagine a market where instead of credit card offers to my dog clogging up mailbox, I get data sharing agreements from the big friendly net media conglomerates.