This is the first article in an ongoing series covering cloud security best practices. We hope that this set of AWS best practices will assist you and your business as you manage risk in the cloud.
Over the last 18-months we have seen more and more of our clients turn to IaaS (Infrastructure-as-a-Service) providers to support their enterprise infrastructure needs. While there are obvious benefits to utilizing these types of services, such as reducing the complexity associated with managing an enterprise infrastructure, moving to the cloud can also introduce new security concerns. Most often these concerns arise as a result of misconfigured cloud instances.
While most IaaS providers ensure that the cloud infrastructure as a whole is secure, when it comes to your own instance(s), it is generally your responsibility to ensure that they meet your company’s security policies. At Praetorian, as information security experts, we understand the importance of following good security practices. We have outlined below a set of best practices to help better secure your Amazon Web Service (AWS) instance(s).
Is your cloud environment secure? Praetorian offers services designed to help protect the confidentiality, integrity, and availability of your organization’s systems and data in the cloud under a shared security responsibility model.
Learn more about Praetorian’s Cloud Security Services »
AWS Account Management
ONE MAIN ACCOUNT, BUT MANY TO RULE THEM ALL
The primary AWS account credentials should never be shared, especially as a means to provide access to multiple users. Instead, account managers should use AWS Identity and Access Management (IAM) to generate unique credentials for individual users. Once created, an account manager can more easily manage the resources and services available to IAM users within the account. If properly implemented, this results in users having access only to those areas of AWS that are necessary to complete their job (see “Principle of Least Privileges”).
ROLE UP
Define user roles within your AWS account. User roles enable you to grant temporary access to AWS services and resources. This reduces the need to provide and manage long term access given to temporary users.
ONE CHECK, TWO CHECK
Enable multi-factor authentication for both the primary AWS account and IAM accounts. Multi-factor authentication can also be enabled for service APIs. AWS currently supports both hardware tokens and virtual MFA devices (smartphones). Though virtual MFA devices might provide a lower level of security than traditional hardware tokens, any form of multi-factor authentication is better than one.
WHERE ARE MY KEYS?
Change your keys and certificates frequently. Rotating your keys frequently can reduce your risk exposure if your keys ever become compromised. Depending on your risk tolerance, Praetorian recommends changing these items every 3 – 12 months. The need for key rotation can also arise in reaction to new vulnerabilities being publicized (Can you say “Heartbleed”?). AWS allows for multiple concurrent keys and certificates to reduce the possibility of downtime when switching keys and certificates.
General AWS Instance Management
SSL FOR ALL
Use SSL for all AWS interactions. AWS has SSL-protected endpoints that will protect your data in transit when connecting to AWS APIs.
SSSH, SOMEONE IS LISTENING
Encrypt your data, in transit and at rest. Data in transit can be protected during upload/download via SSL-encrypted endpoints. At rest, you can encrypt data yourself before transit, or you can utilize S3 Server Side Encryption (SSE), which enables you to encrypt data upon upload simply by adding an additional request header when writing the object. Decryption happens automatically when data is retrieved.
RESTRICT PORTS
Limit open ports. AWS restricts access to ports except those that you explicitly open, as defined in your security group. Overly-permissive security groups expose your instance to port scanners. Run vulnerability scans (after requesting permission) on accessible ports to ensure your site meets your specific security needs.
DISTRIBUTE WIDELY
Ensure that your site takes advantages of the multiple regions and availability provided by AWS. This will ensure that your site remains available during downtimes, such as a system failure.
EC2
As previously stated, you are responsible for managing the security of your EC2 instance. Below is a short checklist of items to follow when deploying your EC2 instance:
- Generate your own key pair and do not share it with other customers or with AWS. Even if they ask nicely.
- Disable password-only access for your guests
- Utilize multi-factor authentication
- Enable key-based SSHv2
- Disable remote root login
- Use command-line logging
- Employ a privilege escalation mechanism (i.e. ‘sudo’)
- Update and patch your OS, including security updates
AWS S3
BUCKET LISTS
Restrict access to buckets/objects in AWS S3 through the use of IAM policies, access control lists and bucket policies. By default, all Amazon S3 resources (buckets, objects, and related sub-resources) are private and can only be accessed by the AWS account that was used to upload it. If resources are made public, be aware that anyone on the Internet would be able to access your data. With that said, be sure that sensitive data is locked down and private. In addition, as stated above, make sure that all data is transferred over SSL and is also encrypted at rest.
AWS Trusted Advisor
Utilize the AWS Trusted Advisor. The AWS Trusted Advisor will notify you of misconfigurations that create a security concern (i.e. open ports, lack of IAM accounts, public access to S3 buckets, lack of MFA for root account). For detailed tracking, you can also use Netflix’s Security Monkey. In addition to providing alerts regarding security misconfigurations, it can provide a historical view of AWS configuration changes.
We hope that this set of AWS best practices will assist you and your business as you make the transition into the cloud. For additional AWS security related information please see Amazon’s AWS Security whitepaper.
