Home > Cloud Computing, Cloud Security > Dear Santa: All I Want For Christmas On My Amazon Wishlist Is a Straight Answer…

Dear Santa: All I Want For Christmas On My Amazon Wishlist Is a Straight Answer…

A couple of weeks ago amidst another interesting Amazon Web Services announcement featuring the newly-arrived Relational Database Service, Werner Vogels (Amazon CTO) jokingly retweeted a remark that someone made suggesting he was like “…Santa for nerds.”

All I want for Christmas is my elastic IP...

All I want for Christmas is my elastic IP...

So, now that I have Werner following me on Twitter and a confirmed mailing address (clearly the North Pole) I thought I’d make my Christmas wish early this year.  I’ve put a lot of thought into this.

Just when I had settled on a shiny new gadget from the bookstore side of the house, I saw Amazon’s response to Eran Tromer’s (et al) research on Cloud Cartography featured in this Computerworld article written by my old friend Jaikumar Vijayan titled “Amazon downplays report highlighting vulnerabilities in its cloud service.”

I feature Eran and his team’s work in my Cloudifornication presentation.  You can read more about it on Craig’s blog here.

I quickly cast aside my yuletyde treasure list and instead decided to ask Santa (Werner/AWS) for a most important present: a straight answer from AWS that isn’t delivered by a PR spokeshole that instead speaks openly, transparently and in an engaging fashion with customers and the security community.

Here’s what torqued me (emphasis is mine):

In response, Amazon spokeswoman Kay Kinton said today that the report describes cloud cartography methods that could increase an attacker’s probability of launching a rogue virtual machine (VM) on the same physical server as another specific target VM.

What remains unclear, however, is how exactly attackers would be able to use that presence on the same physical server to then attack the target VM, Kinton told Computerworld via e-mail.

The research paper itself described how potential attackers could use so-called “side-channel” attacks to try and try and steal information from a target VM. The researchers had argued that a VM sitting on the same physical server as a target VM, could monitor shared resources on the server to make highly educated inferences about the target VM.

By monitoring CPU and memory cache utilization on the shared server, an attacker could determine periods of high-activity on the target servers, estimate high-traffic rates and even launch keystroke timing attacks to gather passwords and other data from the target server, the researchers had noted.

Such side-channel attacks have proved highly successful in non-cloud contexts, so there’s no reason why they shouldn’t work in a cloud environment, the researchers postulated.

However, Kinton characterized the attack described in the report as “hypothetical,” and one that would be “significantly more difficult in practice.”

“The side channel techniques presented are based on testing results from a carefully controlled lab environment with configurations that do not match the actual Amazon EC2 environment,” Kinton said.

“As the researchers point out, there are a number of factors that would make such an attack significantly more difficult in practice,” she said.

So while the Amazon spokesperson admits the vulnerability/capability exists, rather than rationally address that issue, thank the researchers for pointing this out and provide customers some level of detail regarding how this vulnerability is mitigated, we get handwaving that attempts to have us not focus on the vulnerability, but rather the difficulty of a hypothetical exploit.  That example isn’t the point of the paper. The fact that I could deliver a targeted attack is.

Earth to Amazon: this sort of thing doesn’t work. It’s a lousy tactic.  It simply says that either you think we’re all stupid or you’re suffering from a very bad case of incident handling immaturity. Take a look around you, there are plenty of companies doing this right. You’re not one of them.  Consistently.

Tromer and crew gave a single example of how this vulnerability might be exploited that was latched on to by the AWS spokesperson as a way of defusing the seriousness of the underlying vulnerability by downplaying this sample exploit.  There are potentially dozens of avenues to be explored here.  Craig talked about many of them in his blog (above.)  What we got instead was this:

At the same time, Amazon takes all reports of vulnerabilities in its cloud infrastructure very seriously, she said. The company will continue to investigate potential exploits thoroughly and continue to develop features bolster security for users of its cloud service, she said.

Amazon Web Services has already rolled out safeguards that prevent potential attackers from using the cartography techniques described in the paper, Kinton said without offering any details.

She also pointed to the recently launched Amazon Web Service Multi-Factor Authentication (AWS MFA) as another example of the company’s continuing effort to bolster cloud security. AWS MFA is designed to provide an extra layer access control to a customer’s Web services account, Kinton said.

Did you catch “…without offering any details” or were you simply overwhelmed by the fact that you can use a token to authenticate your single-key driven AWS console instead?

I’m not interested in getting into a “full disclosure” battle here, but being dismissive, not providing clear-cut answers and being evasive without regard for transparency about issues like this or the DDoS attacks we saw with Bitbucket, etc. are going to backfire.  I posted about this before in previous blogs here and here.

If you want to be taken seriously by large enterprises and government agencies that require real answers to issues like this, you can engage with the security community or ignore us and get focused on by it (and me) until you decide that it’s a much better idea to do the former.  You’ll gain much more credibility and an eagerness to work with you instead of against you if you choose to use the force wisely ;)

Until then, may I suggest this?  I found it in the Amazon.com bookstore:

beinghonest…you can download it to your Kindle in under a minute.

/Hoff

  1. October 31st, 2009 at 10:26 | #1

    Amazon AWS has a large and growing set of services, available, on demand, by the drink. It sure seems to me that there is a large set of potential security services that Amazon could make available, on demand, and by the drink.

    Craig Balding has already made several suggestions in this direction. See http://cloudsecurity.org/2009/06/16/stop-the-madn

    As part of selling these services these services Amazon would necessarily need to be more forthcoming about them.

    So, what I am looking for is not a gift from Santa. Rather what I want is for Amazon to be the kind of aggressively priced, thoughtful company we know them to be. I want them to

    expand their service offerings in the security area where I can buy them or not, depending on my particular application needs.

  2. October 31st, 2009 at 10:41 | #2

    @Doug Neal

    Doug, that is what I meant in this post: Cloud Providers and Security “Edge” Services – Where’s The Beef? -> http://www.rationalsurvivability.com/blog/?p=1407

    Also, as I have been organizing around the A6 API, I already have two large Cloud providers who are going to participate. AWS would be an outstanding candidate…

    /Hoff

  3. Gary Mazz
    November 4th, 2009 at 06:18 | #3

    It sounds like Kinton is challanging someone to prove her wrong. :-)

    Although an audit interface would be a good thing to have, don't you think it only going to give the user community a "false sense of security" ?

    After all, there is no technology to detect whether information has leaked between spaces, at least no technology that can be deployed cost effectively.

    Today, we experience low cost compute and application costs as "bare bones" systems. Kind of buying a car without brakes. As demand for best practices and interfaces like audit become an offering by providers, won't deploying adversely impact the costs for cloud providers and increase the price of offerings ?

    Auditablity doesn't "have to"stop at security, don't you think it should be extended to practices and custodial care? Maybe then "Danger" like data loses would not have occured. If you are company, what is worse, having some of you data compomised or losing it all.

    Then there is the idenity issues….

  4. Rob Lewis
    November 14th, 2009 at 10:07 | #4

    @Gary Mazz,

    An audit interface would be a good thing to have, especially extended to practices and custodial care, but can't logs cause a “false sense of security” at any time?

    As Chris says, " if the chief concern in Cloud environments is security around multi-tenancy and isolation, giving customers more comfort besides “trust us” has to be a good thing. If I knew where and by whom my data is being accessed or used, I would feel more comfortable."

    This seems to be the bottom line in both security and compliance and audit logs would have to be immutable to be prove due diligence that custodial providers or other tenents have not violated trust agreements, nor tampered with the logs. Sure this might impact offering cost, but it could enable the whole thing to take off as well.

    " After all, there is no technology to detect whether information has leaked between spaces, at least no technology that can be deployed cost effectively."

    For your information, there is a technology that acts as a kernel level policy enforcer to prevent information from leaking between spaces in the first place. Rather than try and move network security to the cloud, this solution provides digital domain separation at the kernel level to provide doc level caveated access control for all users of the system, governing data flow and user access and use of information even while being used in clear text form.

    I won't bother pitching it, cause Hoff is right. One wouldn't recognize Godot even if it hit him right between the eyes of a blog post.

  1. No trackbacks yet.