Category: Cloud

Some random cloudy thinking

Thanks to the announcement of Apple’s iCloud, I’ve been forced to answer several inquiries about The Cloud this week.  Now, I’m coming out of hiding to subject all of you to some of it…

The thing that you must never forget about The Cloud is that once information moves to The Cloud, you’ve inherently ceded control of that information to a third party and are at their mercy to protect it appropriately–usually trusting them to do so in an opaque manner.

What does that mean?  Well, start with the favored argument for The Cloud, the mighty “cost savings.”  The Cloud is not cheaper because the providers have figured out some cost savings magic that’s not available to your IT department.  It’s cheaper because their risk tolerances are not aligned to yours, so they accept risks that you would not merely because the mitigation is expensive.

Argument #2 is that it’s faster to turn up capability in the cloud–also a self-deception.  For anything but the most trivial application, the setup, configuration, and roll-out is much more time consuming than the infrastructure build.  Even when avoiding the infrastructure build produces non-trivial time savings, those savings are instead consumed by contract negotiations, internal build-vs-rent politics and (hopefully) risk assessments.

Finally, The Cloud introduces a new set of risks inherent in having your information in places you don’t control.  This morning, for example, Bruce Schneier again mentioned the ongoing attempts by the FBI to convince companies like Microsoft/Skype, Facebook and Twitter to provide backdoor access to unencrypted traffic streams from within their own applications.  These risks are even more exaggerated in products where you’re not the customer, but rather the product being sold (e.g. Facebook, twitter, Skype, etc.).  There, the customer (i.e. the Person Giving Them Money) is an advertiser or the FBI, et. al.  Your privacy interests are not (at least in the eyes of Facebook, et. al.) Facebook’s problem.

For those of you that like metaphors, in the physical world, I don’t (usually) choose to ride a motorcycle without full safety gear (helmet, jacket, pants, gloves, boots, brain).  I do, however, drive a car with only a minimum of safety gear (seatbelt, brain) because the risk profile is different.  In the Information Security world, I don’t usually advocate putting information whose loss or disclosure would impact our ability to ship products or maintain competitive advantage in the cloud (unless required by law, a Problem I Have) for the same reason.

That’s not to say that I’m opposed to the cloud–I’m actually a fan of it where it makes sense.  That means that I use the cloud where the utility exceeds the risk.  Cost is rarely a factor, to be honest.  But just like any other high-risk activities I engage in, I think it’s important to make honest, informed choices about the risks I’m accepting and then act accordingly.

Cloudiots on Parade

UPDATE: Should have known Chris Hoff would have been all over this already. From the Twitter Conversation I missed last night:

Chris, I award you an honorary NewSchool diploma for that one.

From:  Amazon Says Cloud Beats Data Center Security where Steve Riley says, “in no uncertain terms: it’s more secure there than in your data center.”  Groovy.  I’m ready to listen.  Steve’s proof?

AWS is working on an Internet protocol security (IPsec) tunnel connection between EC2 and a customer’s data center to allow a direct, management network to EC2 virtual machines.

Well, bad guys might as well give up their metasploit now, huh?  Pack it in fellas, Amazon’s got IPSec tunnels!

Any virtual machine generating communications traffic is forced to route the traffic off the host server and onto the data center’s physical network, where it can be inspected. A virtual machine’s attempt to communicate with another virtual machine on the same server is refused. “We prohibit instance-to-instance communication,” another security measure, Riley said.

“inspection” “refused” “prohibit instance-to-instance communication”.  These are all relatively soothing words to some, and granted, it’s kind of *all* we can do – but to outright say”cloud is more secure” that’s a pretty big claim.  And one that needs to be substantiated by, oh, what’s the word I’m looking for…. data?  Or even a logical model, would be interesting, really.

Sorry Steve, I’m NewSchool, I can’t just take your word for it.

The problem is that our current ability to inspect rarely prevents any significant threat, and is very difficult to operate efficiently as a detective control.  Refusing/prohibiting non-specified intra VM communication is great.  Happy to hear about it.  And I’m thrilled that there’s never, ever been any vulnerability and any associated code and that it’s the bestest-estest ever and will never ever have any other vulnerabilities in them.

Look, I’m not saying that using the cloud can’t meet your risk tolerance.  I’m cool with cloud computing.  I’m not saying “run away from the cloud ahhhhhhhh” or any such nonsense.

What I am saying is that from what we know about software and network security, I find it hard to believe that adding (non-security) computing functions and complexity makes things *more* secure than an exact similar environment *without* that extra computing.

Information Security is not “there’s a weak girder in a bridge so architect a solution to reinforce the bridge”.  But unfortunately I have this sinking feeling that as long as the “cloud security” discussion is dominated by IT architects with half a security clue presenting these sorts of engineering solutions with that sort of mindset, we’re just going to have to live with them missing the point.

Dear CloudTards: "Securing" The Cloud isn't the problem…

@GeorgeResse pointed out this article from @DavidLinthicum today.  And from a Cloud advocate point of view I like four of the assertions.  But his point about Cloud Security is off:

“While many are pushing back on cloud computing due to security concerns, cloud computing is, in fact, as safe as or better than most on-premises systems. You must design your system with security, as well as data and application requirements in mind, then support those requirements with the right technology. You can do that in both public or private clouds, as well as traditional systems.”

In a sense, David is right, the ability to develop a relatively secure computing architecture in a cloud environment, in theory, may be reasonably similar to “traditional” computing.  But there’s two things I hate about this paragraph.  First, it seems to reflect this naive notion that systems are deployed secure until vulnerability happens. Second, it completely misses the issue facing security management.  The problems facing management re: The Cloud have nothing to do with ability to architect “secure”.  They have to do with the ability to manage risk.

A Primer About Information Security and Risk Management

Security, at its fundamental core, is not problem of poor network architecture development or poor software development practices.  Security is a problem of behaviors, those having to do with the interrelation of systems and people.  Managing risk is related, but very different in it’s nature.  Information risk management is a problem of information quality and decision making around those behaviors.  Information risk management requires:

  • Knowledge about the asset landscape – Data from what studies we do have about data breaches and successful IT operations strongly correlate visibility (even the degree of visibility) and variability in the asset landscape to success and failure in IT and IT security.
  • Knowledge about the threat landscape – types, frequency, strength, capability, and adaptability of the threat agents are among the bits of information required to know and understand risk.
  • Knowledge about the controls landscape – control information is the ability to resist threats, so not just the technical feasibility of resistance, but also the operational (human skills/resources) contributions to that ability to resist.
  • Knowledge about the impact landscape – impact information from pressures within the organization (things like response costs, downtime, and productivity losses) and from outside the organization (compliance fines, legal judgments, the consequences of IP loss, brand damage…).

In addition, there’s knowledge we synthesize when we consider one landscape in the context of another (vulnerability might be said to be the a state we develop when we consider threat, asset, and control landscape information, risk is what we  understand when we consider the information we have from all four).  In the diagram, it’s where the circles overlap.

I’m sorry if this is basic for many of you readers out there, but I thought this content was necessary – because it’s obvious cloud architect types are obsessing over the ability to build a similar technical environment without understanding the basics of managing risk.

What Really Bugs Security Managers About Cloud Computing

So the issue with moving to “the cloud” for a CISO has to do with two basic things:

  1. Information quality
  2. Responsibility (data ownership in CISSP terms).

For information quality, we are concerned with:

  • A – The ability to get reasonably similar information for the technical behavior information of our systems, and
  • B – The human behavior information from both the threat and the controls landscape.

For Responsibility, we are concerned with:

  • If the information is bad news, who is repsonsible for what actions?
  • Given threat execution (the bad news isn’t just an attack, it’s a compromise) When a data breach occurs, where will the buck ultimately stop?

For that last bullet, PCI is sort of establishing a “case law” for us already.  The lesson to take away from the experiences of others is this:  Following the suggestions of CSA documents and Cloud Audit information (excellent, necessary, and as useful as that documentation is/will be) isn’t going to be enough to manage risk in the cloud with the same quality as “traditional” architectures for many people.  And it looks like you will be left as “custodians” of the data regardless of who is paying the W-2 of the guy at the SEIM console.  More colloquially, “Crap will continue to run downhill, you’ve just diverted it a ways upstream.”


The objections to cloud adoption from an information risk management standpoint have nothing to do with the ability to engineer “secure”.   It is about an ability to manage risk.  There’s a significant difference there that this sort of advocacy continues to gloss over.  Of course, given how nascent information security and information risk managent are as disciplines, however, if you can transfer full responsibility to a cloud provider who is stupid enough to believe things like “we can secure your systems better than you can”, I say go for it!