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.
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.