Cloud Security

One of the slides I added to my Black Hat presentation at the last minute can be seen below:

Introducing the slide, I remarked that its important to differentiate the two:

• “Cloud Security”: this refers to the security of “the Cloud”, or more usefully, of a given cloud.  Stepping back, we can use the term to refer to the general security aspects of Cloud Computing.
• “Security in the Cloud”: this is about delivering security services via “the cloud”.

Back in April 2008, when I was naming this blog, I initially planned to call it ‘Security in the Cloud’ but after 30 minutes of Googling and reading, it became evident that I was mistaken as this term had already been adopted to refer to services delivered via the Internet (primarily Security MSSPs).  Hence cloudsecurity.org was born.

Having said all that, I’m now seeing newer “security in the Cloud” providers referring to themselves as ‘the Cloud Security Leader’ which only serves to add to the confusion.

[This post was inspired by "The Real Meaning of Cloud Security Revealed" by Lori MacVittie]

Got concerns about Cloud Computing Security?

Now’s your chance to express them…

ENISA (the European Network and Information Security Agency) is conducting a security risk assessment of cloud computing.

If ENISA is unfamiliar to you, here’s how they describe themselves:

• Is a Centre of Expertise for the EU Member States and EU Institutions in Network and Information Security, giving expert advice and recommendations
• Is a switchboard of information for best practices
• Facilitates contacts between the EU-institutions, the Members States and the private business & industry actors

For the Cloud Risk Assessment, the group (of which I’m a member) will focus on three scenarios:

1. A user perspective on Cloud Computing (i.e. Small and Medium Enterprises)
2. Cloud Computing in a eGovernment environment (i.e. national health service)
3. Cloud Computing and Resilience

In pursuit of the first scenario, ENISA is seeking feedback:

“…aimed at giving advice to (among others) SME’s on the most important risks in adopting cloud computing technologies, as well as ways to address those risks.

As part of this study, we want to look in detail at the perspective of SME end-users of cloud computing infrastructures and applications (either current users or those considering adoption). As a first step, we have decided to base our study on a survey of the actual needs, requirements and expectations for cloud computing infrastructures.”

Take the 10 minute survey here (results will be shared).

Regular readers will know I recently extended an invitation to give feedback from an enterprise IT security perspective to any startup that got accepted to present at Under The Radar on April 24th in Mountain View, California.

This post is a summary of a very interesting call I had with George Reese, CTO of enStratus and author of the forthcoming “Cloud Application Architectures” book.  Please note: this isn’t a comprehensive review of the full service, rather it reflects the pieces that we delved into based on some of the common concerns we have around Cloud Security (to give you some idea, we spoke for over 90 minutes…).

enStratus offers cloud infrastructure management tools “aimed at the needs of enterprise IT”.  Today, they support Amazon EC2, with support for other clouds to follow.

Their tag line is ‘Confidence in the Cloud’ and their offering focuses on 3 key areas addressing the twin cloud adoption barriers of security and reliability:

• protecting cloud based data through encryption
• offering service levels above that of the underlying cloud provider (99.9999% for EC2)
• achieving Recovery Time and Recovery Point Objectives “in the face of the most extreme disasters”.

George outlined 3 concerns his customers have about cloud providers such as Amazon:

• Amazon controls the physical systems on which the data resides, meaning Amazon malfeasance, Amazon misfeasance, or even 3rd party subpoenas put that data at risk.
• The complexity of resource orchestration in the context of credential management; i.e. when do your credentials need to be in the cloud versus when their presence is just a security risk
• User management, even via traditional identity management systems, can be dysfunctional.

The enStratus Approach to Cloud Key Management

One of my pet peeves with AWS is the “one key to rule them all” security model (the dysfunctional user management George alluded to).  Any disclosure of that key results in an attacker gaining access to all your infrastructure.  But to make privileged API calls, every developer must have a copy of the key…

Its not unknown for AWS users bundling an AMI (creating a virtual machine image) for public consumption to leave their AWS credentials in the AMI itself.  Oops. This is obviously a Bad Thing ™ as a malicious user that opts to use that AMI can steal their access key, gain access to their Amazon hosted infrastructure and run up bills in their name.

One of the things I really like about the enStratus offering, is the relentless focus on controlling the use and hence exposure of a customers’ ‘cloud masterkeys’. Their implementation keeps the keys away from the AMI, and therefore the cloud, PLUS out of the hands of an org’s IT/dev people.

enStratus acts as a trust broker. After signing up for the service, the customer loads their “all powerful” Amazon credentials via a shared enStratus Provisioning Server into a Credentials Server (no direct internet connectivity).

From that point forward, the customers’ IT people access the enStratus service and manage their cloud infrastructure via named user accounts assigned specific privilege levels.

Permissions include;

• administrator
• start/stop servers
• uptime retrieval and
• audit trail review.

Non-administrative users have no direct access to the AWS keys.

Here’s a peek at the architecture of enStratus.

When an authorised enStratus user issues cloud infrastructure management requests via the Web Services and Console server, the Provisioning server issues the cloud API calls on behalf of the users.  This eliminates the need for every user needing a copy of the key to sign requests.  Given they are mediating API requests, adding logging functionality was a no-brainer and means the next time you need to know ‘who spun up that unpatched AMI image with an allow-all security group?’, you can find out.

Its important to note that there is nothing preventing anyone with your AWS key from just making API calls directly to the AWS API endpoint - totally bypassing the enStratus infrastructure.  Therefore, careful key lifecycle management is still necessary; i.e. load fresh AWS credentials straight into enStratus and follow a “no sharing” policy.

I should point out that the EC2 ecosystem players can’t do anything about this as the AWS platform doesn’t offer a mechanism to tie IP level controls to AWS key usage or EC2 (yet).  One way Amazon could implement this (nothing announced) is with their new JSON based Access Policy Language.  Despite this, enStratus can still detect new EC2 instances spun-up by API calls they didn’t mediate, through telemetry used for operational monitoring - they just won’t be able to tell you who started it.

enStratus can help customers build their AMIs, including bundling in HIDS (Host based Intrusion Detection) via ossec, with centralised agent reporting.  Another example of how they protect the AMI key is through error checking in their scripted AMI builds to ensure key material is not left in an AMI accidently.  In addition, users are prevented from accessing partially provisioned AMIs (to eliminate potential key snarfing shenanigans).

Root access to EC2 images is disabled by default (unlike with vanilla EC2).  Privileged access is granted via sudo.

Filesystem Encryption

enStratus offers optional filesystem encryption through a checkbox.  Keys are temporarily passed into the EC2 instance when required; i.e. mounting.

Encrypted filesystem support is implemented via 2 block volumes configured as RAID 0.  2 sets of encryption keys are used.  One for encrypting and remounting the ephemeral drive (this is a “non-persistent store” automagically attached by EC2 to each running AMI).  The second key pair is used to encrypt and mount filesystems attached as Elastic Block Storage (EBS).  EBS is off-instance, persistent storage.  To avoid potential exposure of key material, the 2nd set of keys are stored on the encrypted ephemeral drive during mount.

Worth noting is that in testing, George found that 2 EBS volumes, configured as RAID 0 with an encrypted XFS filesystem  offers similar performance to a single, unencrypted EBS volume with an ext3 filesystem.

George is keen to stress that enStratus is not looking to control both customers data and their keys.  So whilst he recommends and can help customers make use of the EBS snapshot feature to clone/backup storage volumes to Amazon S3 (Simple Storage Service), he isn’t offering a hosted backup service (to avoid a potential conflict).  Of course, an evil and privileged enStratus employee could access your live data as the keys are stored in their Credential server.  Today though, enStratus is a small company so figuring out ‘who dunnit’ would not require the services of Sherlock Holmes.

Futures

Today, the enStratus management infrastructure sits outside of the cloud (at a colo) for cloud monitoring and isolation reasons.  George is exploring the possibility of also offering an on-premise offering for customers wishing for more control.

I offered a few short and medium term suggestions around additional integrity checks, encryption ideas, assurance processes (source code security reviews, penetration testing) and consideration to using a Hardware Security Module (HSM) for key storage to further bolster both security and trust.  George seemed genuinely open and receptive to these ideas and also shared a few interesting customer requests they are actively working on today.  Some of the more expensive line items would become practical if they can attract additional funding.

Overall, I have to say I’m impressed with their approach, technology and attitude.  Definitely worth a hands-on evaluation if current Cloud controls don’t fall within your risk tolerance.

Good luck to George and the rest of the enStratus team as they prepare to present at Under The Radar!

Attending Under The Radar?

As a special offer to cloudsecurity.org readers, the organisors of Under The Radar are offering $100 off the list price for VIP tickets.  To claim yours, click here.

Positive news from the Amazon camp today as Jeff Barr from the AWS team announces a new access control policy.  Right now, its applicable to the Simple Queue Service (SQS).

A Quick SQS Reminder

For those unfamiliar with SQS, here’s the elevator pitch from Amazon:

Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly scalable, hosted queue for storing messages as they travel between computers. By using Amazon SQS, developers can simply move data between distributed components of their applications that perform different tasks, without losing messages or requiring each component to be always available. Amazon SQS makes it easy to build an automated workflow, working in close conjunction with the Amazon Elastic Compute Cloud EC2 and the other AWS infrastructure web services.

Amazon SQS works by exposing Amazon’s web-scale messaging infrastructure as a web service. Any computer on the Internet can add or read messages without any installed software or special firewall configurations. Components of applications using Amazon SQS can run independently, and do not need to be on the same network, developed with the same technologies, or running at the same time.

So, a very handy data structure that makes perfect sense in distributed programming.  However, access control options were limited…until today.

The New Secret Sauce

AWS is also introducing additional permission features that control access to Amazon SQS and to each of its fundamental actions on a very fine-grained basis. You can exercise this control at two levels:

* At the higher level you can use the new AddPermission and RemovePermission functions to set and remove particular access rights for each queue. Access rights, including the ability to send, receive, or delete messages, change message visibility, or to retrieve queue attributes, can be granted to any AWS user via their AWS account number.
* At the lower level you can use our new Access Policy Language. This expressive language makes its debut as part of this SQS release; over time, we plan to employ this Access Policy Language with our other services. The Access Policy Language enables the creation of complex rules to enable access to queues based on identity (AWS account number), source IP address, date, time, and more.

With this new permission system you can now use Amazon SQS queues to connect non-AWS applications to AWS applications and to connect AWS applications from different organizations. You could use an open, public queue as a drop box, allowing outside applications to submit work items for processing. This could be a fully public drop box, or it could be limited to requests from a single country by using a policy based on an IP address or address range. Communication between organizations can be established based on IP addresses or AWS accounts, as appropriate.

For me, the most significant news is not so much that SQS now has fine grained access control, but that Amazon have introduced a Access Policy Language and they plan to apply it to other AWS services.  This is a very positive development and could be the mechanism they use to overcome some of the longstanding security concerns I blogged about recently.

Architectural Overview

For the visually inclined (source):

Where:

1. You, the resource owner.

2. Your resources (contained within the AWS service; e.g., SQS queues).

3. Your policies.  Typically you have one policy per resource, although you could have multiple. The AWS service itself provides an API you use to upload and manage your policies. For information about the content of the policies, see How to Write a Policy.

4. Requesters and their incoming requests to the AWS service.

5. The access policy language evaluation code.

This is the set of code within the AWS service that evaluates incoming requests against the applicable policies and determines whether the requester is allowed access to the resource. For information about how the service makes the decision, see Evaluation Logic (Ed: note there are soft and hard denials).

An Example

Here’s an example from the developer docs showing a simple IP based control (multiple controls can be applied to a single resource):

The following example policy gives all users permission to use all possible SQS actions that can be shared for the queue named 987654321098/queue1, but only if the request comes from the 192.168.143.0/24 range.

{
  "Version": "2008-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement":
     {
        "Sid":"Queue1_AnonymousAccess_AllActions_WhitelistIP",
        "Effect": "Allow",
        "Principal": {
           "AWS": "*"
         },
        "Action": "SQS:*",
        "Resource": "/987654321098/queue1",
        "Condition" : {
            "IpAddress" : {
               "SourceIP":"192.168.143.0/24"
            }
     }
}

Conclusion

Notice the values for the ‘Action’ and ‘Resource’ tags.  Now imagine those with different AWS service identifiers and resource types and things start to get really interesting.

Now all we need is an user-friendly, hard-to-shoot-yourself-in-the-foot policy generator/front-end to open this feature up to the masses.

All in all, its great to see the introduction of a consistent policy language from the cloud pioneer.

I’m off to learn more about the language…

Update: in case it isn’t obvious from the example, the policy language is expressed using JSON (thanks @lmacvittie for the prompt)

A lightning post to highlight a recent change to the Google App Engine Terms of Service.

Clause 2.2 just had some text added to it:

“You agree not to use the Service in the design, development, production, or use of missiles or the design, development, production, stockpiling, or use of chemical or biological weapons.”

I’m glad they cleared that up - now all the bad guys know to use Amazon AWS or Microsoft Azure.

P.S I can’t help feeling the irony, given the App Engine logo…