Manage Learn to apply best practices and optimize your operations.

Managing data security and shared responsibility in AWS

In this security tip, Amy Reichert reviews how best to avoid data breaches and explains the importance of shared responsibility in AWS.

Amazon Web Services is a secure cloud platform, and since 2011 has not experienced a security breach. However, many vendors using AWS have experienced significant data security problems, including the use of AWS to conduct security attacks. Large public data breaches, such as the problem with MongoHQ, were the result of inadequate security measures at the vendor level. There was also an incident where hackers used AWS to launch a cyberattack. Organizations must understand the shared responsibility portion of working with the AWS system and what it requires. In 2011, AWS fixed internal security issues that exposed the system to signature wrapping and cross-site scripting attacks.

An organization's data is only as secure as it makes it. Even if the public cloud being used is secure, data may be exposed from development errors in coding or configuring security functionality. Organizations need to plan and secure their data to prevent security problems and verify their security code functions as expected. Planning includes defining security measures or policies within the code itself and securing endpoints or any other open connections. Organizations may also consider hiring a third-party security firm to test the system and flush out problem areas.

AWS security brief

AWS provides a scalable, reliable platform for deploying data and applications rapidly and securely. User data and application security are the user's responsibility. Amazon is responsible only for the platform security, and users have a shared responsibility to secure their own products.

AWS offers a vast array of tools, configuration, functionality and documents, including a blog dedicated to security issues to assist users in properly managing their security responsibilities. The security blog discusses common security configuration errors and gives suggestions on where and how to secure user data and applications properly. AWS provides the following services for its users to secure their applications and data:

  • Securing API endpoints using HTTPS
  • Securing communication sessions with AWS services using SSL
  • Controlling settings on firewalls
  • Controlling settings within a VPC subnet for egress and ingress
  • Identity management to control infrastructure access
  • Multifactor authentication for both an organization's AWS account and accounts within the organization's application base
  • Adding private subnets, IPsec and VPN tunnels between an organization's network and their AWS VPC
  • Encrypted data storage
  • Security logs for data on all user activity within an organization's AWS account

The AWS platform infrastructure includes several compliance standards for developers, which are listed on the Amazon Web Services website. The infrastructure meets the needs of U.S. government-regulated industries like healthcare (HIPAA), banking and finance (PCI DSS), and the DOD (FedRAMP).

Amazon's data centers are clustered globally and are always online with disaster recovery and full application backup, so an organization's application and data are not affected by a data center failure. Data during transfer and storage is encrypted from individually encrypted endpoints. Amazon has security systems in place to detect changes in the redundancy of stored data, as well as the ability to repair data. The data system detects data corruption and logs network traffic around the clock.

Shared responsibility

The problem remains that all of the default security systems are configurable and subject to human error. For nearly each and every default security system available within AWS, there are several options that users choose or should choose to configure. The shared responsibility clause within AWS means organizations are responsible for securing their own operating system, data and applications within the system. Organizations still need security understanding, knowledge, expertise and dedicated resources to keep up with changes and understand the impact of configuration settings.

Securing your data and customer information

The AWS platform is a target for security threats. There are tools designed to exploit Amazon's default infrastructure that have found significant flaws. These vulnerabilities exist because of errors in configuring the platform for an application. The flaws are coding errors coming from a user application.

These tools have shown many AWS accounts are not maintained and expose sensitive information in data storage. AWS launched its security blog after a security management vendor found thousands of visible public data files containing sensitive information. It wasn't an AWS platform failure, but rather the organization's failure to secure and manage its data. The purpose of the AWS Security Blog is to communicate security and configuration best practices, and the importance of system maintenance.

Independent security professionals have found security weakness in AWS accounts with authentication and encryption keys using self-created security applications. Vulnerabilities have also been found in poorly configured or open API endpoints that leave the data transfer for applications using those API endpoints accessible to unauthorized users. These weaknesses allow hackers to bypass access keys and authentication in order to access code to execute malware or destroy data. 

One such AWS user was a company named Code Spaces, whose AWS account was compromised as part of an alleged blackmail scheme. The majority of all their data was destroyed within 12 hours, including most of their Apache subversion repositories and their Elastic Block Store volumes. Code Spaces closed down almost immediately, as nearly all its customers' -- and its own data -- was destroyed.

The attack happened in the AWS platform, but it was the vendor's "shared responsibility" to secure their applications and data. It is in an organization's best interest to secure its applications and data running on the AWS platform. One method of ensuring security of a user's application and data is reviewing and implementing the OWASP guidelines. Another option is hiring a third-party security firm to test security. Without a proper security system, an organization could suffer data, access or code breaches, and could face significant financial penalties.

Dig Deeper on AWS security

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What has been your biggest challenge with shared responsibility in AWS?
The biggest persistent challenge with shared responsibility  in AWS is the lack of transparency about the way security is implemented within AWS public cloud at the IaaS, and PaaS layers of service. The current AWS SLA has several provisions where the customer is not offered enough information and insight to accurately determine what specific security controls the AWS service implements and how to work around the AWS management panel to get access to the logs and other security data specific to your section of the cloud. 

The AWS approach to shared security is one of the 'lowest common denominator', meaning the SLA provisions for security focus more on the providers ideas of where the line of shared responsibility should be and what the provider believes is the most effective, most cost effective way to establish, implement, and monitor security controls 
@ PRO221 -- this is all to be done by the marketplace AWS has built out (not the actual marketplace, which is a pain to find anything in, but the ecosystem).

Want transparency of AWS Security Controls? Use
Want transparency of your host security in EC2? Use Illumio, CloudPassage, etc.
Want transparency of your network data flows? Use SourceFire, AlertLogic, etc.

It's a layered approach. AWS gave you the fabric and thread, you have to build the garment. The vendors mentioned above can help you build it right.

A third, and sensible option, is to work with Security vendors (Alert Logic, CloudPassage,, etc) to plug the gaps traditional security solutions leave when companies leverage cloud infrastructures. AWS, specifically, has so much that can be done by next-generation solution providers that it's unforgivable for CodeSpaces-like events to happen.

Work with cloud-native security organizations who really understand what you are doing in AWS. Don't buy into the promises that academic research or legacy security products can be made to effectively protect your cloud footprint -- go get solutions from the wave of influencers who suffered through the first wave of cloud adoption, and learn from their mistakes. They're sharing a blessing with you in the form of cloud-ready products that would have saved their bacon... and in turn will protect you from traversing the same painful journey they had to take.

Remember -- protect the network (Alert Logic), the host (CloudPassage), and then the cloud infrastructure ( It's a layered approach, it's not a one-solution answer. This is still infinitely better than the datacenter world, which requires about 15 vendors to get to the same capability, and 10x the effort.