Lots being written about the Cloud, most of it quite dark and gloomy.  In fact I’m surprised, that Hoff hasn’t got a preso spooled up called “The Toxic Cloud” or something similarly ominous for his next speaking tour.
That said, the Economist does a great job distilling the issue into a simple statement -

Cloud computing is a trade-off between sovereignty and efficiency.

Let me ask you -  if you had to put your money on one of those horses, considering your average profit-preoccupied business, which would it be?  I’d put my bottom dollar on the thoroughbred named “Cost Center Reduction”, to place.

WHO ARE WE TO STAND IN THE WAY OF “PROGRESS”?

I’m always fond of Jack’s rule that the role of information risk management boils down to three deceptively simple premises:

• Reduce Risk.
• Reduce Loss.
• Create Operational Efficiencies.

So it would seem antithetical to the charter of the Chief Security Officer to stand in the way of progress as embodied by “cloud computing” (not to mention dangerous to long-term job security).  And I think that this presents opportunities to discuss strategies for managing risk, strategies that aren’t too theoretical and have practical application (though actual “cloud” use by enterprises may be rare at this point).

ON RISK REDUCTION IN THE CLOUD (or, How To Learn From the Shortcomings of PCI DSS)

The good news is, there’s already a well-established model for managing the risk around outsourcing the processing of “confidential” information.  The bad news is, that model kinda sucks it.

The Payment Card Industry, known as the “PCI” or “meal ticket” to many in the industry, faced a similar problem with the introduction of GLBA.  As I see it (and I’m not at all close to the PCI, at all, so this is all just abstract soliloquy) the PCI had one of two choices when faced with the prospect of other people managing their sensitive information:

1. Accept the *massive* amount of GLBA risk their business creates and spend a TON of money to build out the infrastructure (both process and IT) to manage the consumer data themselves (in conjunction with the banks, of course) and never have it grace the computing systems of the retailer.  Or,
2. Transfer the GLBA risk down to the retailer and have them bear the majority of the risk (and cost of reducing risk to a level that might be tolerable to the US Government).

(Martin, you may recall our Twittering about PCI a while back.  This is the crux of my view on the subj.)

Now fortunately, the CSO’s of the world are going to be a little more “invested” in protecting the information they are stewards over, and unlike the PCI, will remain primarily responsible for the C, I, & A of the data in the Cloud.  The cool thing is, this actually presents a great opportunity to start building a meaningful model for co-management of risk!  In fact, we can take the PCI model of contractual risk transference but modify where it goes all wrong, and start working to create something better.  And we can start by euthanizing some faulty assumptions.

JUST HOW INFORMATIVE IS PCI DSS?

What might be the.greatest.mistake of the standards compliance mentality is the assumption of value for the past-state measurement.  That is, I believe that the CSO needs more than some “past-state” assurance in order to understand their risk.    If you look at the concept of “PCI compliance” it really is an examination of a past state of nature that is assumed to be relevant to current and future states.   Many people (myself included) are not at all convinced that this past-state is nearly as informative as those who mandate it’s measurement believe it to be.

That’s not to condemn past-state measurements as completely non-informative,  they most certainly are useful.  It’s just that no self-respecting CSO sleeps well because they were deemed “PCI compliant” 10 months ago.  They sleep well because they have good visibility into current-state information and confidence in their strategy concerning future-state (based on that visibility and the outcomes of sound IRM models).

MOVING PAST THE VULNERABILITY SCANNER INTO INTELLIGENCE AND WISDOM

So realizing this new importance (to me, at least) concerning visibility and IRM models, I’m lead to the conclusion that if we are to manage risk in the Cloud, we’ll have to move beyond “PCI Compliance” or the concept that some regular “audit” of controls in place at the host is all we need to understand our ability to manage risk.  No, the CSO must have good information concerning current and probable future states.   This is that “visibility” I spoke of above.  In fact, we’ll need significant amounts of piercing, transparent visibility.  And in order to gain that visibility, our insight into Cloud Risk Management must include significant provisions for understanding a joint ability to Prevent/Detect/Respond as well as provisions for managing the risk that one of the participants won’t provide that visibility or ability via SLA’s and penalties . These SLA’s must be expressed in measurable terms (more visibility), and those metrics must have their roots in the things that help understand how we manage risk (those aforementioned IRM models).

THE CLOUD COMPUTING SECURITY SILVER LINING (sorry couldn’t resist)

As I mentioned earlier, I do see an opportunity to create insight.  The need for visibility and IRM models would allow us to create a “guidance” if you’ll allow me to use the term.  Not a standard or a “best practice” to audit by, but simply a reference document that says “if you’re going to put information on somebody else’s systems and still hold some significant responsibility for that information, here’s the considerations, why they are considerations, and how you might go about collaborating on the management of risk”.

And I think that if we undertake this journey, there is going to be a lot of growth and risk management innovation along the way.  But keen insights into what it means to manage risk will be necessary, and secure and forthright collaboration will be of absolute importance.

I say that last bit because, if these pundits are right about the utility of a hosted computing model - the Cloud will happen regardless of the CSO’s ability or desire to manage it.

I’d like to give everyone the benefit of the doubt here; perhaps Dell was using it in a much narrower sense. Perhaps the term has really only been used more commonly since the time Dell first applied for the trademark back in March 2007 and now. BUT…

- Dell’s definition is quite broad and certainly not Dell-specific. “The design of computer hardware for use in datacenters and mega-scale computing environments for others; customization of computer hardware for use in data centers and mega-scale computing environments for others; design and development of networks for use in data centers and mega-scale computing environments for others.” Strike One.

- And according to the Wall Street Journal’s research, “cloud computing” has been in regular use since 2001. Strike Two.

So now the “case” has been returned to examination and hopefully the PTO will follow up on everyone else’s research on this and decide that yes, cloud computing is one of those broad, ubiquitous terms that should NOT be trademarked by a single company.

In particular, SSL certificates (as used to identify https websites) might contain one of these weak keys — and so it would be possible for an attacker to successfully impersonate a secure website. Of course the attacker would need to persuade you to mistakenly visit their site — but it just so happens that one of the more devastating attacks on DNS has recently been discovered; so that’s not as unlikely as it must have seemed back in May.

Anyway, my old friend Ben Laurie (who is with Google these days) and I have been trawling the Internet to determine how many certificates there are containing these weak keys — and there’s a lot: around 1.5% of the certs we’ve examined.

But more of that another day! because earlier this week, Ben spotted that one of the weak certs was for Sun’s “OpenID” website, and that two more OpenID sites were weak as well (by weak we mean that a database lookup could reveal the private key!)

OpenID, for those who are unfamiliar with it, is a scheme for allowing you to prove your identity to site A (viz: provide your user name and password) and then use that identity on site B. There’s a queue of people offering the first bit, but rather less offering the second : because it means you rely on someone else’s due diligence in knowing who their users are — where “who” is a hard sort of thing to get your head around in an online environment.

The problem that Ben and I have identified (advisory here), is that an attacker can poison a DNS cache so it serves up the wrong IP address for openid.sun.com. Then, even if the victim is really cautious and uses https and checks the cert, their credentials can be phished. Thereafter, anyone who trusts Sun as an identity provider could be very disappointed. There’s other attacks as well, but you’ve probably got the general idea by now.

In principle Sun should make a replacement certificate and that should be it (and so they have — read Robin Wilton’s comments here). Except that they need to put the old certificate onto a Certificate Revocation List (CRL) because otherwise it will still be trusted from now until it expires (a fair while off). Sadly, many web browsers, and most of the OpenID codebases haven’t bothered with CRLs (or they don’t enable their checking by default so it’s as if it wasn’t there for most users).

One has to conclude that Sun (and the other two providers) should not be trusted by anyone for quite a while to come. But does that matter ? Since OpenID didn’t promise all that much anyway, does a serious flaw (which does require a certain amount of work to construct an attack) make any difference? At present this looks like the modern equivalent of a small earthquake in Chile.

Take a look at the following list and ask yourself which of the following would be labeled “vulnerable”:

• An eight -character password made up of alpha and numeric characters
• A six-character password made up solely of alphabetic characters
• A four-character PIN made up solely of numbers
• A fourteen-character password made up of alpha, numeric, and special characters

Actually, there are a couple of rational answers — 1) “it depends”, and 2) “all of them, to some degree”. As I think about it, maybe these are both the same answer stated from slightly different perspectives.

It Depends
The “it depends” answer comes from the fact that we haven’t identified the threat agent we’re up against. If we’re talking about a threat agent who isn’t particularly skilled, isn’t leveraging a toolset that makes up for their lack of skill, and/or doesn’t have much time in which to carry out their attack, then even the four-character numeric PIN might be more than they’re capable of defeating. On the other hand, if the threat agent is highly skilled, has powerful tools, and has lots of time, then even the fourteen-character password can be defeated. This, it seems, also supports the “all of them” answer. The point is, everything is potentially vulnerable under the right (or wrong) circumstances.

Unfortunately, we tend to use the term vulnerability as if it’s a binary condition. Something is vulnerable or it’s not. But whether we realize it or not, what we’re really doing when we say that something is or isn’t vulnerable, is making unstated assumptions and generalizations about threat capability relative to the control in question.

Of course, some folks insist that we have to rate controls against the “most capable” threat agent. A couple of problems with that include:

• Who’s to say what the most capable threat agent is capable of?

• If we’re judging against the most capable threat agent, then everything is theoretically vulnerable (given enough skill, resources, and motivation)

The fact is, when someone calls something vulnerable (or not vulnerable) they’re consciously or subconsciously quantifying the threat capability as well as the control condition, comparing the two, and then making a judgment about the degree of vulnerability. Or, I suppose, they may just be blindly following someone else’s proclamation that “this is vulnerable” and “that isn’t”.

So, if we’re performing subconscious quantification and comparison when we rate the vulnerability of something, is there any reason we can’t/shouldn’t be more conscious about it? What’s the downside? And is there any reason to believe conscious analysis would be less accurate than the subconscious one? Think about it. Subconscious assessment is at least as exposed (and arguably much more exposed) to errors of omission, errors in estimation, and personal bias/gaming, which means conscious analysis can be no worse and has the opportunity to be much better.

Next week — “Measuring Vulnerability”

The idea is that advertisers can be more picky in who they serve adverts to… you’ll get travel ads if you’ve been looking to go to Pamplona for the running of the bulls, car adverts if you’ve been checking out the prices of Fords (the intent is that Phorm’s method of distilling down the ten most common words on the page will allow them to distinguish between a Fiesta and a Fiesta!)

I’ve now written up the extensive technical details that they provided (10 pages worth) which you can now download from my website.

Much of the information was already known, albeit perhaps not all minutiae. However, there were a number of new things that were disclosed.

Phorm explained the process by which an initial web request is redirected three times (using HTTP 307 responses) within their system so that they can inspect cookies to determine if the user has opted out of their system, so that they can set a unique identifier for the user (or collect it if it already exists), and finally to add a cookie that they forge to appear to come from someone else’s website. A number of very well-informed people on the UKCrypto mailing list have suggested that the last of these actions may be illegal under the Fraud Act 2006 and/or the Computer Misuse Act 1990.

Phorm also explained that they inspect a website’s “robots.txt” file to determine whether the website owner has specified that search engine “spiders” and other automated processing systems should not examine the site. This goes a little way towards obtaining the permission of the website owner for intercepting their traffic — however, in my view, failing to prohibit the GoogleBot from indexing your page is rather different from permitting your page contents to be snooped upon, so that Phorm can turn a profit from profiling your visitors.

Overall, I learnt nothing about the Phorm system that caused me to change my view that the system performs illegal interception as defined by s1 of the Regulation of Investigatory Powers Act 2000.

Phorm argue, with some justification, that their system does not permit them to identify individuals and that they meet and exceed all necessary Data Protection regulations — producing a system that is superior to other advertising platforms that profile Internet users.

Mayhap, but this is to mix up data protection and privacy.

The latter to me includes the important notion that other people, even people I’ll never meet and who will never meet me, don’t get to know what I do, they don’t get to learn what I’m interested in, and they don’t get to assume that targeting their advertisements will be welcomed.

If I spend my time checking out the details of a surprise visit to Spain, I don’t want the person I’m taking with me to glance at my laptop screen and see that its covered with travel adverts, mix up cause and effect, and think — even just for a moment — that it wasn’t my idea first!

Phorm says that of course I can opt out — and I will — but just because nothing bad happens to me doesn’t mean that the deploying the system is acceptable.

Phorm assumes that their system “anonymises” and therefore cannot possibly do anyone any harm; they assume that their processing is generic and so it cannot be interception; they assume that their business processes gives them the right to impersonate trusted websites and add tracking cookies under an assumed name; and they assume that if only people understood all the technical details they’d be happy.

Well now’s your chance to see all these technical details for yourself — I have, and I’m still not happy at all.

In fact, I found the article to be rather upsetting. Not because of the article’s thesis that strong authentication through a national ID program would not necessarily pose a threat to privacy; but rather, because of their naive (and irresponsible) handling of the realities of the biometric authentication challenge. They gloss over the real security challenges with creating a national biometric infrastructure. Here are the two quotes that are most misleading:

• “Confusing privacy with anonymity has delayed implementation of robust, virtually tamper-proof biometric authentication to replace paper-based forms of ID that neither assure privacy nor reliably prove identity.”
• “This emerging technology makes it virtually impossible to assume someone else’s unique identity.”

The problem that the authors are glossing over is that no such technology exists today, and it is unlikely to ever exist. Now, to be fair, I am assuming that a critical success factor for any national biometric program, as described, would be that the authentication devices have to be available, and usable, anyplace paper-based IDs can be used today. This of course implies that the authenticator must be an inexpensive, commodity device, easy to purchase, maintain, and operate. Such a device would have to be even more ubiquitous than the electronic credit card machine.

The problem is that the authenticator itself may be in the possession of the attacker (Perhaps after you authenticate your legitimate purchase the clerk desires to use your identity herself…). In the history of security controls, when the attacker has unsupervised at-will physical access, the attacker wins. Here are a few examples:

• Defeated copy protection on DVDs ( more & more info)
• Cold Boot Crypto Attack on hard disk encryption (more info)
• MiFare RFID Cards (more info)
• Skimming devices attached to ATM machines to steal card and PIN data (more info)

Of course, all of these systems worked in the lab. But when a security system is widely deployed, it has to withstand an enormous amount of scrutiny, and minor flaws will be exploited. And of course, the greater the financial gain, the greater the time and energy attackers invest in trying to defeat the system. The authors of the article ignore these issues, idealistically assuming biometrics will just work.

Now, of course there are lots of examples where biometrics work very effectively. But I would propose that biometric authentication is most useful when the authentication device is physically secure and the authentication itself is supervised. The MiFare example above also demonstrates two other issues:

• The system chose not to implement a reviewed and standard cryptographic algorithm - always a bad idea
• MiFare was able to sell 1 billion cards and authenticators before the system failed

The cost of investing in a national biometric authentication program, and then having the security fail, is enormous. Can you imagine deploying a biometric authentication infrastructure to every bank, police car, restaurant, shop, etc. and then having video on YouTube of it being defeated ?

- Erik

BTW, Maybe the attacker doesn’t even need to tamper with the device -> ftp://ftp.ccc.de/pub/video/Fingerabdruck_Hack/fingerabdruck.mpg

Art of Information Security would love your feedback !

What do the Cold Boot Crypto Attack, DVD Players, and MiFare tell us about the Future of Biometrics?