Elastic Security

Icon

Security for the Cloud

CloudCamp in the Cloud

Last week I attended the CloudCamp in the Cloud. Apart from the fact that the around 70 attendees were connected via a public webinar, the program was similar to a normal CloudCamp: 5-Minutes-Lightning-Talks, an Unpanel (questions to a dynamically formed group of Panelists), and Break-Out-Sessions for deeper discussions on certain topics. In fact, the difference between the Unpanel and the Break-Out-Session was not noticeable since most people (including me) remained on the main channel of the web-conference and the sessions were as unstructured as the Unpanel-session itself. Maybe next time we could simply remain on the same channel and fix time-slots of let’s say 30 minutes to concentrate on pre-defined topics (topic propositions could be sent in by mail the days before the conference). Everybody interested in a specific topic could join at the right time. Those sessions could even be linked to the Lightening-Talks (when we can avoid having masqueraded sales pitches), which would allow some discussions around the talks and direct feedback for the speaker.

Here are my notes during the conference. They reflect some of the most important questions and concerns around Cloud Computing. I will classify them by topic proposed for the break-out sessions during the conference.

  • Cloud Computing Definition, Introduction
    • How can we better educate adopters of cloud computing to know what they’re getting into?
  • Cloud Computing Providers and Market
    • How does Amazon compare to its competitors (like SliceHost, GoGrid, Rackspace) with regard to features and cost?
    • When economies of scale are necessary to reduce the computing costs, aren’t we heading to a market with very few players, which are then able to keep costs high?
    • What are the growth numbers of providers?
    • How do I get more “nines” from my application in the cloud?
    • Interoperability between cloud vendors – what is the state of the art?
    • What will be the role of channels/VARs in the cloud eco system?
    • Will there be a market for AMIs? Are AMIs the right abstraction to sell?
  • Security and Legal
    • Does the patriot act put constraints on the usage of cloud computing?
    • Multi-tenancy is the principal for a good ROI on cloud services, but isn’t that a bad maneuver for security and client (secure) isolation
    • What additional security issues do I need to consider when moving to the cloud?
    • Questions about cloud provider security and trust are legitimate. But how do these question apply to internal systems? Are people putting more security requirements on the provider than on themselves?
    • If trust into your provider is indispensable, how can trust be created?
  • Hands-On Experience and Technical
    • Do I need to make changes to my application to have it scale-out in the cloud?
    • How do KVM vs Xen compare to each other?
    • Is Hadoop highly suitable for cloud deployments?

Reuven Cohen recently posted Recap and Video of the conference here. Slides of the lightning talks can be found here.

Filed under: CloudCamp, Discussions

Quick Notes on the RSA Conference Europe 2009

Good conference, a lot of interesting sessions and discussions during the 3 days.

I will try to give you my quick impressions on the trends of this year conference:

  • Data leakage protection (DLP). Finally, IMO  the products are mature and comprehensive. Maybe not yet ready for widespread adoption by SMBs, but very interesting propositions for when the security budgets will be on the rise.
  • Compliance. This is the real driver of today’s security market. Products to help enterprises getting compliant with major regulations, typically Security Information Management (SIM) solutions are getting much attention in spite of not being a new market.
  • Virtualization security. The hot concrete topic of this year conference. IMO, security professionals were again a bit late reacting to this trend but are now actively developing guidelines and services to addressing virtualization. The first results of these efforts are coming out. I strongly recommend the session of Dennis Moreau of EMC “Attacking and Defending Virtual Infrastructure” for a nice overview on the subject.
  • Cloud security. The buzzword was the real HOT topic. Several tracks were addressing it but it was on every coffee discussions as well. I would like to thank Graig Balding of the cloudsecurity.org for many interesting discussions on the subject. My own conclusion from the conference is that security professionals are really skeptical about the subject, especially concerning compliance and SLAs. A very good illustration was the RANT session by Hugh Thompson. Interestingly enough, one of the only positive voices about cloud security was Philippe Courtot, the CEO of Qualys.

Sorry not to refer to many others’ interesting sessions, i’ll try to get back to them in a later post. Anyway, good conference and i hope that these first notes fuel some more feedback from the other participants or from other people as well. Please add yours thoughts.

Filed under: Discussions, RSA Europe

EC2 Design Patterns (2): Trusted Gateway

Second pattern from our series about EC2 Design Patterns.

Intent

Give API access to an EC2 instance created from a publically available virtual image (AMI) without the help of external services or applications.

Motivation

The motivation is the same as for the External Console pattern: a EC2 server instance needs access to the EC2 API for reasons of configuration, automation, or monitoring of other instances. Any access to the API requires the EC2 credentials. Those credentials allow complete control over the whole platform of an Amazon account and must therefore be stored and communicated in a secure and reliable manner.  Amazon EC2 provides a console via a web-interface that allows to deploy and startup Amazon Machine Images, but it does not allow to pass AWS credentials to the upstarting image.

Since the image is public and can be instantiated by many different accounts, the credentials cannot be stored on the image itself.

Applicability

Use TrustedGateway when

  • you want to apply an AMI that needs access to the EC2 API
  • you want to facilitate deployments and especially minimize manual interventions for the user who deploys the image  (e.g. avoid starting the image using API command line tools, edit configuration files on the image, etc.)
  • you want no other external service to manage your credentials. All credentials should be managed within EC2

Participants

  • Trusted Gateway: EC2 instance that needs the EC2 credentials for configuration or monitoring purpose
  • Controlled Instance(s): virtual instances resulting from AMI instantiation and supposed to be controlled by the Trusted Gateway
  • Admin: a person or organism that deploys the AMI and manages AMI instances
  • Trusted EBS: An instance of Amazon’s elastic block storage that is encrypted and used by the Trusted Gateway

Collaborations

  • Initial Startup
    • The Admin deploys the Trusted Gateway as any other AMI
    • The Admin connects securely (SSH/HTTPS) to the Trusted Gateway and passes the EC2 credentials to the Trusted Gateway
    • The Trusted Gateway stores the EC2 credentials encrypted with any locally stored key-pair
    • The Trusted Gateway connects to the EC2 API and retrieves all relevant information about Controlled Instances to perform his tasks
    • The Trusted Gateway uses the EC2 credentials to encrypt the Trusted EBS storage and store all relevant information needed to perform his tasks
  • Reboot
    • The Trusted Gateway retrieves and decrypts the EC2 credentials stored locally
    • The Trusted Gateway connects to the EC2 API and retrieves all relevant information about Controlled Instances to perform its tasks
  • Recover
    • When the Trusted Gateway instance was completely destroyed (due to termination or a fatal AWS error), a new instance without the stored EC2 credentials is instantiated by the Admin
    • The Admin connects securely (SSH/HTTPS) to the Trusted Gateway, passes the EC2 credentials to the Trusted Gateway, and selects the EBS that was used before
    • The Trusted Gateway stores the EC2 credentials encrypted with any locally stored key-pair
    • The Trusted Gateway recovers by using the information on the Trusted EBS and continues his tasks

Consequences

The Trusted Gateway offers the following benefits:

  • No external service is needed to manage the platform and the security credentials; thus no additional security risk
  • User does not need to intervene when the Trusted Gateway is rebooted (that is in normal operation)

At the other hand, it may have the following drawbacks:

  • Initially and for recovery, the user needs to provide the credentials
  • No strong security: the credentials are stored on the instance and encrypted with a key on the machine itself (security by obscurity)

Known Uses

  • An Amazon User wrote a Script to mount EBS at startup that includes that pattern
  • Shlomo Swidler describes a couple of techniques of passing EC2 credentials securely to instances including this pattern (“How to Put AWS Credentials on EC2 Instance”, point 6)

Note: this is work in progress. Any feedback, questions, or corrections is welcome and might be integrated in an updated version. If you use the pattern, let me know!

Filed under: AWS, Discussions, Solutions

AMI Marketplace?

Foto: Digital Cat

Foto: Digital Cat

SensePost showed in a video how easy it was to make Amazon EC2 users to instantiate malicious images. After thousands of automated trials, they managed to register their own AMI with a small ID and thus have it a prominent place in the Amazon AMI catalogue. Several thousand EC2 Users instantiated it within a short time-interval without any verification.

Amazon does not provide any certification or validation of images. It doesn’t even provide an outbound filtering option in its firewall feature (security groups) that would limit the impact of malicious instances starting any kind of attacks. Hoff suggests to instantiate only images you created yourself. But that would also mean another ugly and awkward little thing to do before being able to start, another technical obstacle to use the cloud. And it doesn’t protect you necessarily against glitches in the official and generally trustworthy images of Amazon itself, neither.

One solution to his problem could be an AMI Marketplace, a simple web-portal that would provide relevant information about any AMI. That information would be retrieved by running scanning software that identifies server-processes on that AMI, open ports, scheduled tasks, integrity checks on kernel files and packages, and that generates warnings about potential viruses/rootkits/malware. In addition, user generated information like ratings and comments could be added – users of the same AMI could be easily connected. Such a portal would solve a couple of today’s issues with AMIs:

  • Lack of Integrity: the problem described above. How can I be sure that the AMI I want to use does not contain any malware? How can I be sure that the AMI contains really what its description promises?
  • Lack of Trust: How can I trust small and unknown providers? The portal could help microISVs to build a reputation in the AMI market
  • Lack of Transparency: How can I find the appropriate image for my needs? Many images contain similar software, misleading names, or insufficient subscriptions (Test: try to search for images yourself on Amazon’s AMI Catalogue).
  • Lack of Support: Often other users are the best sources to discuss issues concerning a certain AMI. How can I reach them and get feedback from them?

Isn’t there a business opportunity? Well, maybe. If the problem would be so pressing, Amazon itself would have probably already released such a portal. I suspect that the people who instantiated SensePost’s malicious AMI were simply playing around a bit with the EC2 platform. Any sensible IT administrator intending to do something serious with EC2 would either get an AMI directly from Amazon or other well-known and trusted providers like Alestic or create an image himself based on an original and official AMI created by Amazon. Maybe AMIs are not considered as a kind of DVD that simply needs to be plugged in and played, but just as a basis to work with and install other software on top. Will there be such an AMI market? What do you think?

P.S. Here is a web-service that provides more transparency than the Amazon AMI Catalogue, but still not addressing most of the problems I noted above.

Filed under: AWS, Discussions, Solutions

Cloud Security: New Problem or New Context?

Here is our presentation on CloudCamp Frankfurt. The complete set of videos can be found here.

[Slides]

Filed under: CloudCamp, Discussions

Follow

Get every new post delivered to your Inbox.