Elastic Security

Two weeks ago, I attended the Solutions Linux french exhibition at Paris. I was proud to be part on a round table on cloud computing and I did a presentation on the security track about how to monitor an Amazon EC2 infrastructure with open source tools and specially nagios. Here are the slides as promised (in french).

Filed under: Uncategorized

I’ve read a very interesting and different post about security in cloud computing and more precisely IaaS (Infrastructure as a Service).

Tons of articles and surveys about security being the major obstacle to cloud computing and lots of FUD are current, but Andreas M. Antonopoulos dared to offer a new perspective of security as THE differentiator of IaaS offerings. I have especially like the part:

“Security is like a liquor license to a restaurant — an opportunity to up-sell each customer with a high-profit margin product to balance out the dismal or loss-leading margins of the core product. Security is the single most profitable differentiator that a service provider can add to IaaS to have any hope of making money. Security is brand-sensitive, labor-intensive, infinitely customizable and difficult to scale. That makes security the perfect differentiator that can add value to a bland IaaS offering.”

As a security provider for IaaS I’ve to strongly agree with this new perspective and we are currently working with hosting companies and IaaS providers in order to make this perspective come true.

For us, the main challenges ahead:

• Heterogeneity: There are several cloud stacks (AWS, OpenStack, VMWare, Nimbula, Eucalyptus just to name a few), so it is hard to build solutions for all and  moreover they offer different functionality
• Focus: Security is a real and hard problem (please check the guidelines of the Cloud Security Alliance if you want to go deeper), but we have to focus on customers needs with an incremental approach and try to build solutions for each need (there is no silver bullet)

What do you think about these challenges?

Thanks Andreas for the refreshing article

Filed under: Uncategorized

Foto: ShivashankarJ

The Problems

A veritable eco-system is starting to thrive around cloud infrastructure services such as AWS. Management and monitoring services (RightScale, Ylastic, CloudKick), security services (VPN Cube, Enstratus, Vordel), integration, migration, and deployment services (CloudSwitch, Makara, Elastra). Not to forget about storage solutions. In almost all cases, the services are offered in SaaS mode requiring to pass your access credentials of the cloud infrastructure provider (AWS, Rackspace, Linode) to the service provider that builds on top of it. Two major problems are inherent to service stack model.

• The first problem is a problem of trust. You share your key to access the center of your IT infrastructure, notably to your critical applications and your confidential data with several companies all around the world of which you 1) don’t know how they store and protect your credentials 2) don’t know how long they will exist and to whom they may belong one day. When we launched Cloudy_Scripts, we faced this problem and got the remark: “won’t use your site, only your code”.
• The second problem is related to the first one, but a pure technical one: credential management. You need to change your cloud infrastructure credentials? Don’t forget to log-in to replace the old credentials by the new ones for all your managing, monitoring, security, and deployment services that you use. Otherwise, they simply won’t work anymore.

These are two veritable problems. How can you deal with them? How to solve them? Some suggestions:

Solution 1: Trust Every Service Provider

Actually, that’s not really a solution, but rather ignoring the problem. Even when you fully trust all the service providers you subscribe to, changing the credentials of your cloud infrastructure provider requires you to update those credentials for each and every service.

Solution 2: Wait for Your Cloud Infrastructure Providers Role-based Credentials Support

Imagine your Cloud Infrastructure Provider (CIP) would allow you to generate credentials with limited access (limited in time, limited by location, limited by API calls) that can be given out to our Cloud Added-Service Providers (CASP). You would manage your credentials at a central place and be able to revoke them at any time you want. Even better: your CIP supports a standard protocol that allows to update the credentials for all your CASPs automatically. Dreams are today’s answers to tomorrow’s questions (E.Cayce)

Solution 3: Self-Service

This is a very pragmatic solution (and the one we took for Cloudy_Scripts). Instead of relying on a SaaS provider, run the service yourself within your infrastructure. In the case of Amazon EC2, this means: starting a preconfigured AMI yourself that manages the credentials (see Trusted Gateway pattern). Precondition: the service provider plays the game and delivers his solution as virtual appliance. Don’t know of a management console supporting this mode, but JumpBox and CohesiveFT offer lots of self-service images. Self-service, however, does not address the issue of managing credentials across different services.

Solution 4: Trusted Credentials Broker

Now this is my favorite one.  The idea is the same as for solution 2, but the solution is provided by a third party. The broker service could be a proxy that exposes the same API as the CIP does. It knows your security credentials for your CIP (if you don’t want this, then you might want to run the broker yourself like solution 3) and issues security credentials that are then given to the CASPs. The broker/proxy could even do even more useful things in addition to managing credentials and perform access control, e.g. it could provided detailed audit logs and usage information for your cloud infrastructure or accelerate HTTP access and reduce load (and thus costs) on the server by using caching techniques. Link-tip: The idea has been explained and discussed in detail here.

Any other solutions? How is your company dealing with the “crux with the creds”?

Filed under: Uncategorized