AWS Security Myths Part 1 - Data Security

Whilst catching up with AWS Re: Invent this month, I came across the AWS myth busting session. The talk itself really attempts to dispel or disprove common misconceptions regarding the security of the public cloud. This blog is intended to address security myths, in general.

There will always be industries and specific use cases that it may not be suitable for, such as industrial control system environments and at the highest government classification levels. However, cloud providers are addressing these areas with specialist service offerings, dedicated architectural patterns and cloud service lines assured to higher government security levels.

Before I try to summarise the key elements of the talk, I think it’s important to understand the concept of a shared responsibility model relating to the cloud provider and consumers of the cloud.

The Main Takeaway

Put simply the cloud provider will always be responsible for the security of the cloud. This can range from the physical security of the underlying data centres, to the logical security, management and maintenance of underlying hardware and virtualisation technologies that underpin the services and technologies available to consumers of the cloud.

Consumers of cloud services will always be responsible for some elements of the security in the cloud. In AWS this may include patching of EC2 instances, user identity and access management (IAM), and ensuring customer data is protected. However, depending on the types of cloud services consumed, responsibilities can vary; an example being serverless technologies, where consumers can leverage additional security and resilience from the cloud provider.

This is the first of a two-part series that attempts to dispel myths associated with public cloud usage and security. The following section aims to address myths regarding your data within AWS.

"I lose ownership and control of my data in the cloud, and it could be transferred to different countries without my knowledge"

Firstly, you retain responsibility and full ownership of your data and AWS is fully committed to fulfilling their responsibilities to process your data. AWS allows you to retain control of your data in the cloud, including providing the capability for you to determine which region your data resides in. AWS will also protect your data from unauthorised access for the areas they are responsible for.

"I can’t put my sensitive personal data in the public cloud"

The security of the cloud responsibilities placed upon AWS includes maintaining the privacy/confidentiality of your data at the layers which they are responsible for. Outside of this AWS provide their customers with the tools to secure their data within the cloud.

A good example of this is the ability to encrypt your data in transit and at rest throughout the AWS service line. This can be achieved using ubiquitous technologies, using well established services such as AWS Key Management Service (KMS) or AWS Cloud Hardware Security Modules (HSM).

I can’t control of how my data is deleted, and no verification of disposal

During equipment’s usable life, AWS uses techniques such as zeroing and removal of logical pointers to sanitise media and render customer data unreadable. At the point equipment is ready to be physically destroyed, AWS will securely destroy media within the secure area of their data centres. Customers can seek independent verification that data is sanitised and destroyed appropriately, by reviewing documents within the AWS the Artefact service such as SOC2 reports.

Other customers can see my data when using serverless technologies

Serverless services within AWS inherit the security controls built into the underpinning services; for example, Lambda which is underpinned by EC2 and containers. These services are secured following AWS best practices, which provide strong isolation, ensuring code from different AWS accounts always run in separate EC2 instances. Logging mechanisms also ensure visibility of what is happening within the serverless environment.

Customer responsibilities within serverless include securing identity and access into your own serverless applications

Governments can access my data within AWS

AWS understands customer privacy is extremely important and will only disclose customer content where they are compelled to do so by law and have received a legally binding court order. This includes where there may be a clear indication of criminal activity.

AWS reviews requests by law enforcement and will not facilitate access where requests are deemed to be over reaching or inappropriate. Where possible, AWS will notify you of any such requests, providing there is no legal requirement to delay or withhold notification

AWS employees can view my data

Administrative access within AWS is based on the philosophy of “keeping humans away from data”.  AWS predominantly utilises automation to manage, maintain and scale their cloud offerings. Occasionally, human access is required, but it is governed by robust controls, including:

• Employees with physical access to AWS customer assets do not get logical access rights to your data and vice versa
• The corporate network and services networks are segregated and use separate identity providers
• Access is governed by use of a VPN, multifactor authentication, device certificates and the use of bastion hosts. All access is logged
• Employees with administrative access are subjected to an enhanced level of screening
• All administrative access is logged via ticket, and actions are evaluated and taken to fix the root cause, and to develop automation to prevent similar issues in the future.

Virtualisation technology can be bypassed to access other customers data

AWS has over a decade of experience in building virtualisation technologies to build and scale their business. They are heavily involved with the Zen hypervisor community which is used within their services, and this enables them to stay informed of security or functionality issues.

AWS also limit the features they use within their Zen hypervisors, which reduces the attack surface further and, in many cases, vulnerabilities effecting Zen hypervisor software. AWS have started to move software components into hardware within their Nitro system, which provides further virtualisation isolation and other security benefits.

The cloud is dangerous for storing sensitive data, everyone has access to it

It’s true there has been many a story about unprotected S3 storage buckets leaking sensitive data, such as access keys or customer personal information. However, AWS S3 and many other services are secure by default. Like many of today’s incidents and subsequent breaches, the root cause can usually be attributed to a lack of security awareness and training, and/or security misconfigurations

When creating a bucket within S3, it is set to private by default. This means it cannot be viewed publicly. In scenarios where you want to share buckets publicly there are several controls that can achieve this in a secure manner.

• The first of these is IAM policies, which can be used to restrict users, groups and roles from altering settings, and to also provide the ability to access buckets.
• The second line of defence is S3 bucket policies; these are bucket level policies that can be used to restrict access to buckets.
• Finally, through utilising CloudTrail and CloudWatch you can monitor and alert on discovery of public buckets and/or overly permissive bucket permissions. Lambda can then be used to create functions to automate incident response and remediation of insecure S3 buckets.

Summary

AWS and cloud providers, in general, do a good job at securing your data for the layers they are responsible for within the shared responsibility model. They also provide the tools and support to enable cloud consumers to effectively secure their data on the public cloud. It’s important to understand that the cloud allows organisations to rapidly scale their infrastructure and applications to respond to internal and customer demand.

These features can also contribute to the success or failure of data security within the cloud. Prior to placing your data in the cloud, the same care should be taken to identify, classify and protect your data as with any asset under your control. It’s clear that the cloud can help with this and in many cases can expedite implementation of controls, such as encryption and auditing with minimal impact to business processes when compared to traditional on-premise infrastructure.

Read  ‘AWS Security Myths Part 2 - Cloud Security’