Trend Cloud Security Blog – Cloud Computing Experts

The Cloud’s Shared Risk Model

People who drive recklessly to the airport, at a high rate of speed while clutching a cellphone to their ear, only to then board the plane and pray it does not crash, often bewilder me. Don’t they realize they bear some responsibility for arriving safely at their destination?

Trend Micro’s webinar on the new PCI DSS Cloud Computing guidelines is a reminder that while the cloud represents an enormous opportunity for offloading the data center burden; your security responsibility doesn’t necessarily follow. (Miss this popular webinar with Amazon and Accuvant? Click here to watch the replay).

When organizations host applications within their own datacenters, they control – and are responsible for – the physical, network and application security. When organizations host their applications in the cloud, they cannot absolve themselves of all responsibility for securing their applications by saying “its in the cloud, the cloud provider is responsible.” Thus the concept of “shared responsibility” or shared risk is born. The public cloud provider and cloud customer share responsibility for securing applications hosted in the cloud.

AWS details their specific responsibilities as the cloud provider versus what you, the customer, must do.

The public cloud provider, such as AWS, will usually provide the following:

• Secure premises and datacenters
• Perimeter network firewalls
• Redundant and highly available storage (S3), database and networking infrastructure
• Failover (Amazon availability zones)

You, the cloud customer, are responsible for:

1. Identity Management and Access Control. AWS customers should use AWS role-based access control to ensure that anyone accessing an AWS instance only has those privileges consummate with their role. For example, an instance administrator may have all rights and privileges accessing an AWS instance, while an auditor may only have view privileges to settings or log files. In addition, it behooves customers to secure AWS access and secret keys used to connect to AWS instances, so that only users who are allowed to access and instance, have the appropriate keys.
2. Encrypt sensitive data both in-transit and on-disk. Customers should encrypt all communication using SSL and encrypt AWS volumes/disks. This ensures that, should any network communication be intercepted or disks/volumes access by non-authorized people, the data is secure and cannot be read.
3. Intrusion detection and firewalls on AWS instances. Customers should implement firewalls and intrusion detection on AWS instances. The firewall and intrusion rules are controlled by the customer. These rules can even be automatically applied based on the operating system and applications installed on the AWS instance.
4. Ensure applications and operating systems are patched and updated.  While automatic patch update services for most software applications and operating systems, often these cause downtime for end-users and disruption to your business. To reduce this disruption and mitigate exposure, intrusion detection systems can deflect hacker attacks aimed at exploiting software vulnerabilities.

To help put these principles into practice, we’ve started a detailed examination of best practices in securing your AWS cloud deployments. You can read our first and second articles with AWS tips, and stay tuned for more in the future.

Share your experience and lessons learned! We’d love to hear from you in the comments below. And, if you’re interested in easily securing your AWS EC2 application, please request a trial of Trend Micro’s new Deep Security on Demand service for cloud servers like Amazon EC2. Currently in Beta, we’d love you feedback on this new service that allows you to add intrusion prevention, anti-virus, virtual patching and more to all your EC2 instances in less then 15 minutes!

Share/Bookmark