For those contemplating using Amazon Web Services (AWS), their compliance page is quite assuring. With a who’s who of compliance standards from SSAE-16, ISO 27001, PCI DSS, to CSA, MPAA, FEDRamp, FIPS 140-2, HIPAA and more; it’s more than enough to give an auditor a warm and fuzzy feeling.
Note that in this article, AWS is used broadly to refer to a wide set of Amazon services such as Elastic Compute Cloud (EC2), Simple Storage Service (S3), Relational Database Service (RDS), Redshift, Elastic MapReduce, and more. Also, while this focuses on Amazon, the approach is the same for any cloud service, be it from Microsoft, Rackspace, Terremark and the rest. Also, while this article centers more on IaaS, for PaaS and SaaS, the responsibilities are generally less.
Finally, if you have a significant investment in AWS, it’s prudent to have internal staff purely dedicated to the various aspects of the Amazon relationship. It’s very easy to get lost in the Amazon jungle, and in the process, your security, privacy and compliance will suffer.
Make no mistake about it, if you want for example 100 instances of a Windows SQL backend, PCI compliance and a petabyte of storage, AWS could provide that in minutes. But that is the easy part. The beauty of IaaS providers such as AWS is that it is so easy, uncomplicated and relatively straightforward. You get a cloud-facing virtual machine and life is good.
The hard part, which might not be so obvious, is that anything you build on top of AWS is not necessarily compliant. It’s critical that if you use AWS, that security must be seen as a shared responsibility between your company and Amazon.
While Amazon makes it quite clear about this division of labor, far too many firms focus on the AWS infrastructure without thinking of what they have to do. If you want to get AWS security right, you have to understand where the demarcation is and where you must take over.
Consider this; AWS is not a hospital for your sick data or badly design application. If your infrastructure is broken, any migration to AWS or the cloud will simply result in your data being run in the cloud, but it will be sick nonetheless.
What is AWS?
AWS is a collection of web services of which Amazon is responsible for the following:
- facilities
- physical security
- compute infrastructure
- storage infrastructure
- network infrastructure
- virtualization layer
- disaster recovery
AWS provides a secure co-location infrastructure in which to build your application. They are providing a strong foundation. But if you build an insecure application off AWS, you get the weakest link and all of the attestations from the AWS compliance page quickly go up in smoke.
As noted, one is hard-pressed to find a stronger foundation than AWS with a world-class level of administrative, physical and logical controls. But even though that may create a highly secure and resilient foundation, choose your analogy – it’s like great ingredients without a good chef, a Maserati without a good driver, or a football without a good quarterback.
Even with all AWS does, it still demands that you have to take an active role in the overall security. Taking a passive approach when moving to the cloud is a sure sign for data insecurity. And that is precisely one of the biggest problems around the cloud; that the cloud consumer often thinks they are handing off all responsibilities to the cloud provider. Not comprehending the notion of a shared services model means security, privacy and compliance will certainly fail.
How good of a job does Amazon do? If your relationship with them enables you to view their SSAE-16 SOC 1 Type 2 report, you will see an impressive array of security functionality and controls.
But even with all that, you need to determine the demarcation where their security responsibility ends and yours begin. For the most part, the hypervisor is the demarcation point. Everything up to and including the hypervisor is AWS responsibility, everything on top of it is yours.
With AWS, the customer is still responsible for a significant amount of security responsibilities. The following table details some of the primary areas, but don’t consider it a comprehensive list. What your specific responsibilities will be in part depends on the scope of Amazon services used, how your application is configured, SLA and more.
|
Topic |
Responsibility |
| Operating system configuration and security controls | AWS will do the patching, but you are responsible for the O/S settings and configuration. |
| Applications and application security | You build the application and all security around it. The importance of application security can’t be overemphasized.
Consider resources such as OWASP, SANS and Rugged Software to ensure the security of your code. |
| Security groups | A security group acts as a virtual firewall that controls the traffic for one or more AWS instance. |
| Firewalls | Firewalls by default are set in a deny-all mode and you have to open any ports needed to allow inbound traffic. |
| Identity, account, authentication, access management | AWS Identity and Access Management (IAM) enables you to securely control access to AWS services and resources for your users. Using IAM, you can create and manage AWS users and groups and use permissions to allow and deny their access to AWS resources. |
| Data security | It’s up to you to encrypt your data. AWS has to listen to any court order for whichever jurisdiction it’s in. Encrypt your data to obviate this threat. |
| Monitoring, auditing and logging | Consider Amazon CloudWatch, a monitoring service for AWS cloud resources and the applications you run on AWS. CloudWatch collects and track metrics, collect and monitors log files, and set alarms. |
| Disaster recovery | The way you design your AWS application through Amazon availability zones can make disaster recovery much quicker for you. All the SLA guarantees in the world won’t help if AWS goes down. But you can mitigate AWS downtime via a resilient design. |
| Vulnerability assessments / penetration testing | Just because your application runs on AWS, don’t forget that performing vulnerability assessments and penetration testing is still part of your security requirements. |
The table above requires a significant amount of work. There are many other AWS security features and controls that have to be implemented; and it’s assumed that the customer has a documented list of how they want to do that.
Conclusions
Securely using AWS is a big deal. With that, the following 3 steps can be used to ensure that your move to the cloud is a secure one, and not a debacle:
- Understand AWS security – understanding AWS security is a huge endeavor. The Amazon set of cloud services is continuously expanding in offerings, capabilities and complexity. There are myriad security controls offered by AWS; know what they are and know how to use them. Make sure you have internal staff dedicated to AWS. Doing that shows you are sincere about securing your infrastructure and not simply shifting your problems to AWS.
- Mind the gap – understand where Amazon controls and responsibilities end and yours begin. Amazon has tens of thousands of customers, but you have 1 customer; your own firm. At the end of the day, you can outsource responsibility, but not liability.
- Compliance testing – nothing can break compliance (PCI, SoX, HIPAA, etc.) quicker than moving to the cloud. Ensure your compliance group understands how to audit the cloud. Follow that up with consistent vulnerability scans and application testing.
Ben Rothke CISSP (@benrothke) works in the information security field, writes the Security Reading Room blog and is the author of Computer Security: 20 Things Every Employee Should Know (McGraw-Hill).